«

"jacob navia" wrote in message news:ihu7rl$3fh$...
>OK, I could spend hours "fixing" that warning and detecting that the
>pointers are different because of the inline attribute and NOT because
>of a _stdcall attribute or _noreturns or others.
>
>Maybe one day I will do it, but before I have to do the correction for
>the bad code generation that you pointed out. I am working already
>6 hours in that problem and there is no solution in sight. I discovered
>that if you write
>
>dp = !dp;
>ptr = table[dp];
>
>the bug disappears. It is only when you write
>
>ptr = table[dp = !dp];
>
>that the bug manifests itself (only when optimizations are on).
>
>And I will have for X hours more, I do not know.

[snip]

>Well, yes. I would have to detect when a function pointer is being
>used. Then, realize that it is a pointer to an inline function. Then
>I would have to add some annotation to the inline function pointer symbol
>to generate ts code anyway.
>
>WITHOUT INTRODUCING ANY NEW BUGS...
>
>This is something like 1 day of work...
>
>> I prefer ISO C compilers, though.
>>
>I have been working for this project for 12 years or more. I have
>financed all expenses and all my work. But I can't do more than what I
>do now. If you would buy a maintenance contract you would be served
>quickly. But you didn't.

And I won't. I am just a hobby programmer and my primary development
environment is MinGW + SciTE. I don't need lccwin32, I just like to test
my code with different compilers.

I never said that I *demand* that you fix these bugs/issues, because
as you pointed out I didn't pay a dime for this after all. I just reported
them.
Feel free to leave things as they are, by all means.

Le 28/01/11 13:13, copx a écrit :
>> I have been working for this project for 12 years or more. I have
>> financed all expenses and all my work. But I can't do more than what I
>> do now. If you would buy a maintenance contract you would be served
>> quickly. But you didn't.
>
> And I won't.

OK.

> I am just a hobby programmer and my primary development
> environment is MinGW + SciTE. I don't need lccwin32, I just like to test
> my code with different compilers.
>
> I never said that I *demand* that you fix these bugs/issues, because
> as you pointed out I didn't pay a dime for this after all. I just
> reported them.

Thank you for your bug reports.
I just notice that never any customer asked for C99 or standards
compliance or similar stuff. Only people in this forum.

> Feel free to leave things as they are, by all means.
>

I will fix the bugs and ignore any "standard compliance" issues.

jacob navia <> writes:
> Le 28/01/11 08:54, Ian Collins a ecrit :
>> On 01/28/11 08:37 PM, jacob navia wrote:
>>> Le 27/01/11 16:20, copx a ecrit :
>>>> ========
>>>>
>>>> gcc -Wall -Wextra -std=c99 -pedantic -O2 test.c
>>>> No warnings, compiles and runs as expected.
>>>>
>>>> I suspect the compiler who chokes on this is buggy, but I am not
>>>> sure. Here's the output:
>>>>
>>>> ===
>>>> Warning d:\dev\test\test.c: 28 assignment of pointer to inline
>>>> function(pointer to pointer to unsigned char) to pointer to
>>>> void function(pointer to pointer to unsigned char)
>>>>
>>>
>>> Assigning function pointers with different characteristics will
>>> always produce a warning.
>>
>> But they don't have different types.
>>
> Yes but they have different characteristics: one is inline and the other
> is not inline.

But the standard doesn't require a diagnostic when the pointers
have different *characteristics*. It requires a diagnostic
when they have different *types*. And in this case, they don't.

Of course a diagnostic is permitted, but it's not required -- and if a
compiler that rejects a program because of it (not the case here) would
be non-conforming.

> This warning is crucial when you have _stdcall functions. And
> _stdcall is a similar attribute like inline.

The major difference being that _stdcall is non-standard, so of course
the language standard says nothing about it.

[...]

> Yes, and I do not generate the code for it. Changing it is around
> 4-5 hours work including testing. I will do it when the next standard
> appears, to be sure that inline is not declared optional.

Seriously, I don't think you need to worry about that; inline is
too generally useful to be made optional. (Not speaking for the
committee, of course.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

jacob navia <> writes:
[...]
> Yes, they have the same type.
>
> But
>
> int _stdcall fn(void);
> and
> int fn(void);
>
> have also the same type but if you mix pointers to one with pointers to
> the other a crash is guaranteed. So I always warn.
>
> OK, I could spend hours "fixing" that warning and detecting that the
> pointers are different because of the inline attribute and NOT because
> of a _stdcall attribute or _noreturns or others.
[...]

Issuing warnings that aren't required is not a conformance issue.

(It sounds like you're internally associating the "inline"
characteristic with the function type; logically, it belongs with
the function itself.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

jacob navia <> writes:
> Le 28/01/11 13:13, copx a ecrit :
[...]
>> I never said that I *demand* that you fix these bugs/issues, because
>> as you pointed out I didn't pay a dime for this after all. I just
>> reported them.
>
> Thank you for your bug reports.
> I just notice that never any customer asked for C99 or standards
> compliance or similar stuff. Only people in this forum.

Speaking only for myself, I don't believe I've ever *asked* you
for C99 compliance; I've merely commented on how closely lcc-win32
does or doesn't appear to conform to the standard, based on your
statements. You've certainly made an issue of C99 conformance
yourself, at least in discussions here.

>> Feel free to leave things as they are, by all means.
>
> I will fix the bugs and ignore any "standard compliance" issues.

That's entirely up to you, of course.

I'll just mention in passing that you've falsely accused me of
fighting against C99 because I've pointed out that implementations
are not universally available. Now you're making direct decisions
that will reduce that availability even further. I find that
interesting.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 01/28/11 11:43 PM, jacob navia wrote:
> Le 28/01/11 08:54, Ian Collins a écrit :
>> On 01/28/11 08:37 PM, jacob navia wrote:

>>> static inline functions generate no function address.
>>> If you want the function address eliminate the static...
>>
>> Says who?
>>
>
> Me.
>
>> All the standard says is "Making a function an inline function suggests
>> that calls to the function be as fast as possible".
>>
> Yes, and I do not generate the code for it. Changing it is around
> 4-5 hours work including testing. I will do it when the next standard
> appears, to be sure that inline is not declared optional.

Hang on, so you don't do any checking to see if a function should be
inlined? Say someone declared a 2000 line function 'inline', would you
still inline it?

--
Ian Collins

Ian Collins <ian-> writes:
> On 01/28/11 11:43 PM, jacob navia wrote:
>> Le 28/01/11 08:54, Ian Collins a écrit :
>>> On 01/28/11 08:37 PM, jacob navia wrote:
>>>> static inline functions generate no function address.
>>>> If you want the function address eliminate the static...
>>>
>>> Says who?
>>>
>>
>> Me.
>>
>>> All the standard says is "Making a function an inline function suggests
>>> that calls to the function be as fast as possible".
>>>
>> Yes, and I do not generate the code for it. Changing it is around
>> 4-5 hours work including testing. I will do it when the next standard
>> appears, to be sure that inline is not declared optional.
>
> Hang on, so you don't do any checking to see if a function should be
> inlined? Say someone declared a 2000 line function 'inline', would you
> still inline it?

It seems to me that if you explicitly mark a function inline, you can't
reasonably complain if the compiler actually inlines it. It could even
make sense if there's only one call to it.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 01/29/11 09:24 AM, Keith Thompson wrote:
> Ian Collins<ian-> writes:
>> On 01/28/11 11:43 PM, jacob navia wrote:
>>> Le 28/01/11 08:54, Ian Collins a écrit :
>>>> On 01/28/11 08:37 PM, jacob navia wrote:
>>>>> static inline functions generate no function address.
>>>>> If you want the function address eliminate the static...
>>>>
>>>> Says who?
>>>>
>>>
>>> Me.
>>>
>>>> All the standard says is "Making a function an inline function suggests
>>>> that calls to the function be as fast as possible".
>>>>
>>> Yes, and I do not generate the code for it. Changing it is around
>>> 4-5 hours work including testing. I will do it when the next standard
>>> appears, to be sure that inline is not declared optional.
>>
>> Hang on, so you don't do any checking to see if a function should be
>> inlined? Say someone declared a 2000 line function 'inline', would you
>> still inline it?
>
> It seems to me that if you explicitly mark a function inline, you can't
> reasonably complain if the compiler actually inlines it. It could even
> make sense if there's only one call to it.

Maybe, but it goes against the spirit of "calls to the function be as
fast as possible".

--
Ian Collins

Ian Collins <ian-> writes:
> On 01/29/11 09:24 AM, Keith Thompson wrote:
>> Ian Collins<ian-> writes:
>>> On 01/28/11 11:43 PM, jacob navia wrote:
>>>> Le 28/01/11 08:54, Ian Collins a écrit :
>>>>> On 01/28/11 08:37 PM, jacob navia wrote:
>>>>>> static inline functions generate no function address.
>>>>>> If you want the function address eliminate the static...
>>>>>
>>>>> Says who?
>>>>
>>>> Me.
>>>>
>>>>> All the standard says is "Making a function an inline function suggests
>>>>> that calls to the function be as fast as possible".
>>>>>
>>>> Yes, and I do not generate the code for it. Changing it is around
>>>> 4-5 hours work including testing. I will do it when the next standard
>>>> appears, to be sure that inline is not declared optional.
>>>
>>> Hang on, so you don't do any checking to see if a function should be
>>> inlined? Say someone declared a 2000 line function 'inline', would you
>>> still inline it?
>>
>> It seems to me that if you explicitly mark a function inline, you can't
>> reasonably complain if the compiler actually inlines it. It could even
>> make sense if there's only one call to it.
>
> Maybe, but it goes against the spirit of "calls to the function be as
> fast as possible".

How so? It still saves the overhead of the call and return. And it
could introduce more opportunities for optimizations, as the code inside
the function can be optimized along with the code in the caller.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 01/29/11 09:58 AM, Keith Thompson wrote:
> Ian Collins<ian-> writes:
>> On 01/29/11 09:24 AM, Keith Thompson wrote:
>>> Ian Collins<ian-> writes:
>>>> On 01/28/11 11:43 PM, jacob navia wrote:
>>>>> Le 28/01/11 08:54, Ian Collins a écrit :
>>>>>> On 01/28/11 08:37 PM, jacob navia wrote:
>>>>>>> static inline functions generate no function address.
>>>>>>> If you want the function address eliminate the static...
>>>>>>
>>>>>> Says who?
>>>>>
>>>>> Me.
>>>>>
>>>>>> All the standard says is "Making a function an inline function suggests
>>>>>> that calls to the function be as fast as possible".
>>>>>>
>>>>> Yes, and I do not generate the code for it. Changing it is around
>>>>> 4-5 hours work including testing. I will do it when the next standard
>>>>> appears, to be sure that inline is not declared optional.
>>>>
>>>> Hang on, so you don't do any checking to see if a function should be
>>>> inlined? Say someone declared a 2000 line function 'inline', would you
>>>> still inline it?
>>>
>>> It seems to me that if you explicitly mark a function inline, you can't
>>> reasonably complain if the compiler actually inlines it. It could even
>>> make sense if there's only one call to it.
>>
>> Maybe, but it goes against the spirit of "calls to the function be as
>> fast as possible".
>
> How so? It still saves the overhead of the call and return. And it
> could introduce more opportunities for optimizations, as the code inside
> the function can be optimized along with the code in the caller.

For larger function the overhead is noise.

Determining which functions are suitable for inline is an increasingly
complex optimisation. In the days before caches, it was a size/space
trade off. With modern processors and operating systems, over
aggressive inlining can force a function out of the cache, or force
unnecessary page faults. So the inline heuristic isn't trivial which is
one reason compilers employ techniques like profile feedback
optimisation to determine the best combination.

--
Ian Collins