X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient:	djgpp-workers AT delorie DOT com
RazorGate-KAS:	Status: not_detected
RazorGate-KAS:	Rate: 0
RazorGate-KAS:	Envelope from:
RazorGate-KAS:	Version: 5.5.3
RazorGate-KAS:	LuaCore: 80 2014-11-10_18-01-23
	260f8afb9361da3c7edfd3a8e3a4ca908191ad29
RazorGate-KAS:	Lua profiles 69136 [Nov 12 2014]
RazorGate-KAS:	Method: none
Subject:	Re: Test build of gcc-6.0.1-20160415
To:	djgpp-workers AT delorie DOT com
References:	<5713789D DOT 8070708 AT iki DOT fi> <57152494 DOT 6040808 AT gmx DOT de>
From:	"Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp-workers AT delorie DOT com]" <djgpp-workers AT delorie DOT com>
Message-ID:	<57154DC1.2080907@iki.fi>
Date:	Tue, 19 Apr 2016 00:12:33 +0300
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.7.1
MIME-Version:	1.0
In-Reply-To:	<57152494.6040808@gmx.de>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 04/18/2016 09:16 PM, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-workers AT delorie DOT com] 
wrote:
> Am 17.04.2016 13:50, schrieb Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp-workers AT delorie DOT com]:
>> gcc-6.1.0 should not be very far any more:
>>
>> https://gcc.gnu.org/ml/gcc/2016-04/msg00103.html
>> https://gcc.gnu.org/ml/gcc/2016-04/msg00109.html
>>
>> I built DJGPP port based on SVN revision r235040 (the same used for release candidate sources) 
>> checked out from git mirror (see https://gcc.gnu.org/wiki/GitMirror for details). Of course 
>> DJGPP related additional changes are merged.
>>
>> Files (both i686 and x86_64 rpms and native DJGPP build are available for testing at:
>>
>> http://ap1.pp.fi/djgpp/gcc/test/6.0.1-20160415/
>>
>> Andris
>>
>
>
> I have tried to build libc from repository using g[cc|pp]601_20160415b.zip.
> It fails with the following error message:
>
> gcc ... -c strlen.c
> strlen.c: In function 'strlen':
> strlen.c:10:6: error: nonnull argument 'str' compared to NULL [-Werror=nonnull-compare]
>    if (str == NULL)
>       ^
> cc1.exe: all warnings being treated as errors
> ../../../makefile.inc:89: recipe for target 'strlen.o' failed
> make.exe[3]: *** [strlen.o] Error 1
> makefile.sub:2: recipe for target 'all_subs' failed
> make.exe[2]: *** [all_subs] Error 2
> ../makefile.lib:6: recipe for target 'all' failed
> make.exe[1]: *** [all] Error 2
> makefile:39: recipe for target 'subs' failed
> make.exe: *** [subs] Error 2
>
> Inspecting the strlen code, it is clear that the offending code segment is:
>
>   if (str == NULL)
>     return 0;
>
> It seems to be that for some reason, the compiler does assume that the passed
> argument to the function can never be NULL.  If I understood correctly, this
> should only be the case if the function is specified like this:
>
> size_t    strlen(const char *_s) __attribute__ ((__nonnull__ (1)));
>
> specifying that _s is never NULL, but this is certainly not the case in the
> current versions of string.h.
>
> So the question arises if we have to remove all NULL pointer check from our
> code and if this measure is really wise?  IMHO, we should adjust the compiler
> checks in such a way that NULL pointer checks are still possible.
> BTW I have inspected http://pubs.opengroup.org/onlinepubs/009695399/functions/strlen.html
> and I have seen no indication that a NULL pointer check is prohibited, but
> also I have seen no indication that a NULL pointer check is allowed.
>
GCC new versions are known to be too wise for its own good when it commes to builtin functions.

We have already had similar problem with cmalloc() in nmalloc.c where GCC infinite wisdom told it 
to recognize source as implementation of __builtin_cmalloc() and over-optimize it to infinite tail 
recursion. Specifying -fno-builtin-cmalloc for nmalloc.c work-arounded the problem then (present in 
DJGPP v2.05). See:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618

(it was NOT DJGPP specific and could easily be reproduced on Linux)

It seems that gcc current version recognizes DJGPP implementation of strlen as __builtin_strlen and 
assumes that __builtin_strlen should never have passed NULL argument with following messages.
Specifying

strlen.o: EXTRA_CFLAGS += -fno-builtin-strlen

in src/libc/ansi/string/makefile causes error to disappear.

Same problem with:

libc/c99/math/nan*.c
libc/compat/string/stpcpy.c
libc/compat/string/stpncpy.c
libc/compat/string/strdup.c

and more (same approach as with strlen() works also for these).

There are also other warnings interpreted as errors. Some examples:

i586-pc-msdosdjgpp-gcc -pipe ... -c k_rem_pio2.c
k_rem_pio2.c: In function '__kernel_rem_pio2':
k_rem_pio2.c:190:6: error: this 'for' clause does not guard... [-Werror=misleading-indentation]
       for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw;
       ^~~
k_rem_pio2.c:190:54: note: ...this statement, but the latter is misleadingly indented as if it is 
guarded by the 'for'
       for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw;
                                                       ^
cc1: all warnings being treated as errors

i586-pc-msdosdjgpp-gcc -pipe ... -c s_scalbn.c
s_scalbn.c:69:1: error: 'huge' defined but not used [-Werror=unused-const-variable=]
  huge   = 1.0e+300,
  ^~~~
cc1: all warnings being treated as errors

And some similar...

I'm not going to fix these now immediately (in late evening).

About -Wmisleading-indentation: I guess it would be best to disable it for gcc-6+

Andris

- Raw text -