[Bug ada/41040] New: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

2009-08-12 Thread samuel dot thibault at ens-lyon dot org
Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41040

[Bug ada/41041] -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

2009-08-12 Thread samuel dot thibault at ens-lyon dot org
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2009-08-12 08:45 --- Created an attachment (id=18343) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18343action=view) fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041

[Bug target/36793] x86-64 does not get __sync_synchronize right

2008-11-22 Thread samuel dot thibault at ens-lyon dot org
--- Comment #8 from samuel dot thibault at ens-lyon dot org 2008-11-22 19:41 --- Ah, well, by nop, I was thinking about things like what Linux does: lock; addl $0,0(%%esp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793

[Bug target/36793] x86-64 does not get __sync_synchronize right

2008-11-21 Thread samuel dot thibault at ens-lyon dot org
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2008-11-21 11:16 --- Just to confirm the bug: the gcc doc says it follows the Intel itanium binary interface. The Intel documentation says « Associated with each instrinsic are certain memory barrier properties that restrict

[Bug target/36793] x86-64 does not get __sync_synchronize right

2008-11-21 Thread samuel dot thibault at ens-lyon dot org
--- Comment #5 from samuel dot thibault at ens-lyon dot org 2008-11-21 23:20 --- We do already know which x86 memory barrier instruction we need, that's not the problem, no need to give us pointers to documentations. The problem is that we'd like to not use explicit x86 instructions

[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

2008-11-09 Thread samuel dot thibault at ens-lyon dot org
--- Comment #7 from samuel dot thibault at ens-lyon dot org 2008-11-09 23:50 --- libiberty actually already has its own powerful getpwd () Attaching patches currently fails, I'll try to submit later if I remember (else remind me). -- samuel dot thibault at ens-lyon dot org changed

[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

2008-11-09 Thread samuel dot thibault at ens-lyon dot org
--- Comment #8 from samuel dot thibault at ens-lyon dot org 2008-11-09 23:52 --- Created an attachment (id=16643) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16643action=view) better patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706

[Bug c/35515] New: asm() makes gcc forget about conditionally initialized values

2008-03-09 Thread samuel dot thibault at ens-lyon dot org
AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35515

[Bug c/35515] asm() makes gcc forget about conditionally initialized values

2008-03-09 Thread samuel dot thibault at ens-lyon dot org
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2008-03-09 17:02 --- Erf, sorry, asm constraint problem. -- samuel dot thibault at ens-lyon dot org changed: What|Removed |Added

[Bug ada/35503] New: Warning about restricted pointers?

2008-03-07 Thread samuel dot thibault at ens-lyon dot org
at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503

[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

2007-11-04 Thread samuel dot thibault at ens-lyon dot org
--- Comment #24 from samuel dot thibault at ens-lyon dot org 2007-11-04 16:42 --- It's rather the converse: Linux is much like Hurd, since they're both GNU-based, so quite logically they should share most of the configuration stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug target/5212] [Hurd] profiling support for i386-gnu specs file

2007-08-14 Thread samuel dot thibault at ens-lyon dot org
--- Comment #10 from samuel dot thibault at ens-lyon dot org 2007-08-14 23:30 --- This should have been fixed by svn commit 127290 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5212

[Bug libgcj/21821] MAXPATHLEN usage in libjava

2007-08-04 Thread samuel dot thibault at ens-lyon dot org
--- Comment #10 from samuel dot thibault at ens-lyon dot org 2007-08-04 22:02 --- It got fixed in CVS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug java/32846] New: GNU/Hurd fixups

2007-07-21 Thread samuel dot thibault at ens-lyon dot org
Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32846

[Bug java/32846] GNU/Hurd fixups

2007-07-21 Thread samuel dot thibault at ens-lyon dot org
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2007-07-21 18:52 --- Created an attachment (id=13945) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13945action=view) GNU/Hurd fixups -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32846

[Bug translation/32428] New: odd french translation of strict aliasing -related warnings

2007-06-20 Thread samuel dot thibault at ens-lyon dot org
: normal Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32428

[Bug translation/32428] odd french translation of strict aliasing -related warnings

2007-06-20 Thread samuel dot thibault at ens-lyon dot org
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2007-06-20 15:09 --- Created an attachment (id=13745) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13745action=view) better translations for strict aliasing -related warnings -- http://gcc.gnu.org/bugzilla

[Bug translation/32428] odd french translation of strict aliasing -related warnings

2007-06-20 Thread samuel dot thibault at ens-lyon dot org
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2007-06-20 15:15 --- Created an attachment (id=13746) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13746action=view) yet better translation Sorry for reposting a patch so soon, but someone told me enfreindre is better

[Bug c/31035] New: GNU/Hurd needs crtfm and dfprules too

2007-03-04 Thread samuel dot thibault at ens-lyon dot org
: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31035

[Bug c/31035] GNU/Hurd needs crtfm and dfprules too

2007-03-04 Thread samuel dot thibault at ens-lyon dot org
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2007-03-04 12:36 --- Created an attachment (id=13139) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13139action=view) Fix -ffast-math -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31035

[Bug target/31035] x86 GNU/Hurd should include crtfm and dfprules because it uses linux.h

2007-03-04 Thread samuel dot thibault at ens-lyon dot org
--- Comment #4 from samuel dot thibault at ens-lyon dot org 2007-03-04 17:54 --- Ok, but more generally, isn't the crtfastmath.o helper needed for what -ffast-math permits anyway? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31035

[Bug libgomp/30471] New: OpenMP with static linking fails in fortran on amd64

2007-01-15 Thread samuel dot thibault at ens-lyon dot org
at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471

[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64

2007-01-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2007-01-15 13:23 --- Ah, though gdb fails when directly running a.out, it works via the core file: (gdb) bt #0 0x in ?? () #1 0x00405dd6 in get_external_unit () #2 0x00404abd

[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64

2007-01-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2007-01-15 13:28 --- Note: line 16 of the program is program launch, and line 19 of the program is the write call -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471

[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64

2007-01-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #3 from samuel dot thibault at ens-lyon dot org 2007-01-15 13:32 --- Note: line 16 of the program is program launch, and line 19 of the program is the write call -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471

[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64

2007-01-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #5 from samuel dot thibault at ens-lyon dot org 2007-01-15 20:12 --- glibc 2.3.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471

[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64

2007-01-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #6 from samuel dot thibault at ens-lyon dot org 2007-01-15 20:28 --- I tried to upgrade to glibc 2.5 and gcc svn snapshot of 20070105, with same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471

[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode

2006-11-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #3 from samuel dot thibault at ens-lyon dot org 2006-11-15 09:33 --- Mmm, if I have to use another target for avoiding my default target's specific stuff, what is the use of -ffreestanding? Does that mean that we will have to add a linux-kernel target (as opposed to linux

[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode

2006-11-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #6 from samuel dot thibault at ens-lyon dot org 2006-11-15 10:30 --- So you are saying that gcc now imposes (whatever the kernel) kernel-land and user-land to use the same TLS scheme, and now requires people to build a cross-compiler before building a kernel from another

[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode

2006-11-15 Thread samuel dot thibault at ens-lyon dot org
--- Comment #9 from samuel dot thibault at ens-lyon dot org 2006-11-15 11:01 --- About not using -fstack-protector, the problem is that it is the default on ubuntu for instance. That would mean we have to explicitely use -fno-stack-protector, but only for recent versions of gcc, so

[Bug c/29838] New: -fstack-protector shouldn't use TLS in freestanding mode

2006-11-14 Thread samuel dot thibault at ens-lyon dot org
in freestanding mode Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http

[Bug c/29838] -fstack-protector shouldn't use TLS in freestanding mode

2006-11-14 Thread samuel dot thibault at ens-lyon dot org
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2006-11-15 01:16 --- Created an attachment (id=12622) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12622action=view) braindead patch Just a small braindead patch, not tested at all, just adds testing flag_hosted

[Bug c++/24745] unpleasant warning for if (NULL)

2006-01-24 Thread samuel dot thibault at ens-lyon dot org
--- Comment #5 from samuel dot thibault at ens-lyon dot org 2006-01-24 18:35 --- But still an unpleasant behavior :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24745

[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol

2005-12-06 Thread samuel dot thibault at ens-lyon dot org
--- Comment #19 from samuel dot thibault at ens-lyon dot org 2005-12-06 11:15 --- Created an attachment (id=10416) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10416action=view) Testcase with linker script This testcase uses a linker script. The proposed patch http://gcc.gnu.org

[Bug middle-end/24556] gcc can't inline functions using setjmp

2005-10-28 Thread samuel dot thibault at ens-lyon dot org
--- Comment #8 from samuel dot thibault at ens-lyon dot org 2005-10-28 08:27 --- Subject: Re: gcc can't inline functions using setjmp pinskia at gcc dot gnu dot org, le Fri 28 Oct 2005 01:39:59 -, a écrit : So this is not a bug. Yes this is a bug. The docs for setjmp are really

[Bug regression/24556] New: gcc can't inline functions using setjmp

2005-10-27 Thread samuel dot thibault at ens-lyon dot org
ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556

[Bug regression/24556] gcc can't inline functions using setjmp

2005-10-27 Thread samuel dot thibault at ens-lyon dot org
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2005-10-27 13:45 --- Subject: Re: gcc can't inline functions using setjmp pinskia at gcc dot gnu dot org, le Thu 27 Oct 2005 13:37:32 -, a écrit : This is not a bug as if you inline it, the place setjmp goes to could

[Bug regression/24556] gcc can't inline functions using setjmp

2005-10-27 Thread samuel dot thibault at ens-lyon dot org
--- Comment #4 from samuel dot thibault at ens-lyon dot org 2005-10-28 00:21 --- Well, there is indeed an issue: the address of some local variables might be passed to other functions and then be modified in an external way between setjmp() and longjmp(), and if some local variables

[Bug regression/24556] gcc can't inline functions using setjmp

2005-10-27 Thread samuel dot thibault at ens-lyon dot org
--- Comment #6 from samuel dot thibault at ens-lyon dot org 2005-10-28 00:47 --- Subject: Re: gcc can't inline functions using setjmp pinskia at gcc dot gnu dot org, le Fri 28 Oct 2005 00:37:47 -, a écrit : Let me look into why setjmp was caused not to inline, there was a reason