https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651
U.Mutlu changed:
What|Removed |Added
CC||um at mutluit dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
--- Comment #5 from U.Mutlu ---
I have to correct myself in #2 and #3.
The code is correct, and should return n=6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
--- Comment #4 from U.Mutlu ---
gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) gives the same result as v9:
p=123456 n=6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
--- Comment #3 from U.Mutlu ---
I just tested it with v9:
#include
static const char a[3][8] = { "1234", "12345", "123456" };
int main ()
{
volatile int i = 1;
const char* p = *(&a[1] + i);
int n = __builtin_strlen (p);
printf("p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
U.Mutlu changed:
What|Removed |Added
CC||um at mutluit dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045
--- Comment #6 from U.Mutlu ---
Another difference is:
the passing normal compiler was built with itself (so to say, ie. built with
v9),
whereas the failing cross compiler was built with the default system compiler:
$ gcc -v
Using built-in spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045
--- Comment #5 from U.Mutlu ---
I just see a difference:
Target: x86_64-linux-gnu
Target: x86_64-linux
The pr68264 fails in the latter case (built as a crosscompiler).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045
--- Comment #4 from U.Mutlu ---
(In reply to Eric Gallager from comment #3)
> (In reply to Oleg Endo from comment #2)
> > (In reply to Kazumoto Kojima from comment #1)
> > > (In reply to Oleg Endo from comment #0)
> > > > Kaz, do you know what's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #8 from U.Mutlu ---
If one activates -Werror then it won't build as it then treats the warnings as
error. And there are many warnings currently suppressed.
That means -Werror is deactivated by default, and IMO never activated by any o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #6 from U.Mutlu ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error,
ie. if user se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #5 from U.Mutlu ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error,
ie. if user se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #3 from U.Mutlu ---
As said in the Remarks, the bug originally was triggered in this file in the
trunk:
../gcc_trunk/libiberty/pex-common.c:28
#include
#ifdef NEED_DECLARATION_ERRNO
extern int errno;
#endif
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: um at mutluit dot com
Target Milestone: ---
Created attachment 44344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44344&action=edit
The output file o
: normal
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: um at mutluit dot com
Target Milestone: ---
If warnings are treated as error (I think that's the default, or gets
implicitly activated if -Wall -Wextra has been
Severity: normal
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: um at mutluit dot com
Target Milestone: ---
when building the languages=c,c++ with "-g0 -DNDEBUG", then the following err
15 matches
Mail list logo
