[Bug ada/41040] New: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16
Hello, the manual page says `Set the wide execution character set, used for wide string and character constants. The default is UTF-32 or UTF-16, whichever corresponds to the width of wchar_t.' This should read UCS-4 or UCS-2 instead. See attached program behavior when compiled without -fwide-exec-charset and with -fwide-exec-charset=UTF-32 , UTF-16, UCS-4 or UCS-2. Attached patch fixes it. Samuel -- Summary: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF- 32/UTF-16 Product: gcc Version: 4.3.0 Status: UNCONFIRMED 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
--- 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
--- 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
--- 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 the movement of memory references to visible data across the intrinsic operation (by either the compiler or the processor). » Not including the mfence instruction would let the processor move references across the instruction, so it is mandatory. And that is not only for x86_64, but also x86, on which you can use e.g. a locked nop if you don't know the arch, or a mfence when using -march= (IIRC it appeared with SSE2) -- samuel dot thibault at ens-lyon dot org changed: What|Removed |Added CC||samuel dot thibault at ens- ||lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- 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 but rather rely on the portability of gcc's __sync_synchronize. If your answer is sync_foobar is not specified for baz, all these __sync_foobar become useless, since the user can't assume what their are supposed to achieve. From what the documentation says, I had assumed that gcc would implement for other archs what Intel documents for ia64, but it happens not to be the case at least for sync_synchronize. So in short, if that's your answer to the bug, then I'll have to tell people _not_ to use gcc's __sync_* at all except on ia64, since that would be the only arch on which we would have any semantic guarantee... (and then the documentation needs to be fixed). Of course, that's not an option I'd like, and actually I believe there may be SMP bugs in libgc such that use it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c
--- 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: What|Removed |Added CC||samuel dot thibault at ens- ||lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c
--- 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
I'll attach a testcase. -- Summary: asm() makes gcc forget about conditionally initialized values Product: gcc Version: 4.3.0 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=35515
[Bug c/35515] asm() makes gcc forget about conditionally initialized values
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35515
[Bug ada/35503] New: Warning about restricted pointers?
I've again seen some code like this: sprintf(buf, %s-%s, buf, to_add); and gcc doesn't complain, even though the declaration of sprintf is extern int sprintf (char *__restrict __s, __const char *__restrict __format, ...); Wouldn't it be possible for gcc to check the enforcement of restricted pointer, at least in the trivial cases like this one? -- Summary: Warning about restricted pointers? Product: gcc Version: 4.3.0 Status: UNCONFIRMED 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=35503
[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- 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=28102
[Bug target/5212] [Hurd] profiling support for i386-gnu specs file
--- 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
--- 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
Here are some fixups for GNU/Hurd, where neither MAXHOSTNAMELEN nor MAXPATHLEN are defined since there is no such hard limit. gcj can also use_libgcj_bc on GNU/Hurd. -- Summary: GNU/Hurd fixups Product: gcc Version: 4.1.3 Status: UNCONFIRMED 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
--- 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
French translations for strict aliasing -related warnings are a bit odd, here is a patch. -- Summary: odd french translation of strict aliasing -related warnings Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: 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
--- 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/show_bug.cgi?id=32428
[Bug translation/32428] odd french translation of strict aliasing -related warnings
--- 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 for rules. -- samuel dot thibault at ens-lyon dot org changed: What|Removed |Added Attachment #13745|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32428
[Bug c/31035] New: GNU/Hurd needs crtfm and dfprules too
Currently, on the GNU/Hurd target, gcc doesn't built crtfastmath.o, which is needed whenever one compiles with -ffast-math. The attached patch fixes this. -- Summary: GNU/Hurd needs crtfm and dfprules too Product: gcc Version: 4.2.0 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=31035
[Bug c/31035] GNU/Hurd needs crtfm and dfprules too
--- 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
--- 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
I'm trying to use Fortran OpenMP on AMD64 with static linking: simple.f90: program launch !$OMP PARALLEL write (*,*) foo !$OMP END PARALLEL end program launch $ gfortran-4.2 simple.f90 -fopenmp -static -lgomp $ ./a.out zsh: segmentation fault (core dumped) ./a.out ¤ gfortran-4.2 simple.f90 -fopenmp -lgomp ¤ ./a.out foo foo foo foo ¤ gfortran-4.2 simple.f90 -static -lgomp ¤ ./a.out foo This happens with fortran and on amd64 only, C or i386 work fine, so it looks like this is the combination of fortran+openmp+static+amd64. -- Summary: OpenMP with static linking fails in fortran on amd64 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp 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=30471
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- 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 in data_transfer_init () #3 0x004002f8 in MAIN__.omp_fn.0 (.omp_data_i=0x0) at simple.f90:19 #4 0x004002aa in MAIN__ () at simple.f90:16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- 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
--- 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
--- 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
--- 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
--- 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-user target) and build a cross-compiler before building a linux kernel? (replace linux with whatever kernel you want). And x86_64 Linux just poses the same problem: it emits %fs:0x28 instead of %gs:0x14, but it's just the same issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- 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 kernel's userland? I thought -ffreestanding was precisely meant to escape such considerations... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- 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 we'll have to detect that, etc... Not counting all such new options that may arise which we'd have to disable... Please answer this, at least by just yes/no: you're saying that -ffreestanding doesn't mean an OS kernel (as manual says), but the kernel of the target, so that people working on other kernels will have to first build a cross-compiler? (the bug is a documentation bug then) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug c/29838] New: -fstack-protector shouldn't use TLS in freestanding mode
Hi,
On some architectures, when given -fstack-protector (which is the default on
ubuntu), gcc generates a TLS reference for the stack guard. For instance, on
linux x86 with a fairly recent version of glibc:
echo 'void f (void) { volatile char a[8]; a[3]; }' | gcc -S -x c -O2
-fstack-protector - -o -
generates a %gs:0x14 reference.
In freestanding mode, this poses problem because the target (typically an OS
kernel) does not necessarily have TLS. In such case, gcc should default back
to referencing __stack_chk_guard.
Samuel
--
Summary: -fstack-protector shouldn't use TLS 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug c/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug c++/24745] unpleasant warning for if (NULL)
--- 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
--- 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/ml/gcc-patches/2005-05/msg00391.html does fix the issue in that case too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/24556] gcc can't inline functions using setjmp
--- 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 clear about the fact automatic variables of the callee might be thrashed, but that doesn't entail that the callee can't be inlined. Gcc doesn't implement anything for getting semantic right, but it is feasible, I explained how. So it is a bug. But you don't want to fix it. Too bad for us. I thought that An Inline Function is As Fast As a Macro. It is not. grin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
[Bug regression/24556] New: gcc can't inline functions using setjmp
Hi,
We have a thread library which can't be optimized as much as before, because
-starting from gcc 3.4- functions calling setjmp can not be inlined. Our
problem is with our switchto function:
void switchto(task_t *cur, task_t *next) {
if (cur!=next) {
if (setjmp(cur-buf) == 1)
return;
longjmp(next-buf, 1);
}
}
We would really prefer _not_ to have to define this as a macro for getting it
correctly inlined in every function that calls it.
Is there a really strong reason for not inlining such function ?
Regards,
Samuel
--
Summary: gcc can't inline functions using setjmp
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
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=24556
[Bug regression/24556] gcc can't inline functions using setjmp
--- 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 be not
where you want to goto.
I don't understand that. I did google before submitting the bug and couldn't
find anything that would prevent our code from working. Something I could find
is
jmp_buf buf;
inline f() {
if (setjmp(buf));
}
g() {
f();
longjmp(buf);
}
Of course _this_ is wrong, since f() is terminated when longjmp occurs.
But in our code, switch_to() is _never_ terminated when longjmp goes to it, so
I don't see any issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
[Bug regression/24556] gcc can't inline functions using setjmp
--- 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 are still in registers when setjmp is executed, longjmp will restore the value they had _before_ setjmp. This is expected when using sjlj. Now, inlining a function makes the caller be hit by this issue too, which is no good. But gcc might check that at the time setjmp() is called no caller automatic variables are in registers, or it might even automatically consider them as volatile in the callee (just like it does for extern variables, I guess, since these _must_ have the value as of the time longjmp() was called). So yes, inlining functions that use sjlj makes sense and can be implemented, this is a opened bug, not a feature (btw, the error message is sorry, unimplemented: function 'switchto' can never be inlined because it uses setjmp, not go read longjmp() documentation). -- samuel dot thibault at ens-lyon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
[Bug regression/24556] gcc can't inline functions using setjmp
--- 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. It seems that historically, the How inlined are inlined functions? thread starting at 03 Dec 1999 http://gcc.gnu.org/ml/gcc/1999-12n/msg00056.html triggered the patch http://gcc.gnu.org/ml/gcc-patches/1999-12n/msg00142.html but that's the issue I just explained -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
