--- Comment #3 from samuel dot thibault at ens-lyon dot org 2009-08-12
08:46 ---
*** Bug 41042 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2009-08-12
08:46 ---
*** This bug has been marked as a duplicate of 41041 ***
--
samuel dot thibault at ens-lyon dot org changed:
What|Removed |Added
us: 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=41042
--- 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=18343&action=view)
fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2009-08-12
08:45 ---
Created an attachment (id=18342)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18342&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
us: 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=41041
us: 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
--- 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
--- 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 in
--- 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
--- 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=16643&action=view)
better patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
--- 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 ch
--- 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
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
t: 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
--- 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_
--- 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
--- 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
--- 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=13945&action=view)
GNU/Hurd fixups
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32846
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
--- 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=13746&action=view)
yet better translation
Sorry for reposting a patch so soon, but someone told me "en
--- 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=13745&action=view)
better translations for strict aliasing -related warnings
--
http://gcc.gnu.org/b
: 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
--- 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
--- 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=13139&action=view)
Fix -ffast-math
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31035
tatus: 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
--- 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
--- 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
--- 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
--- 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
--- 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
: 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
--- 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
--- 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
--- 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
--- 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=12622&action=view)
braindead patch
Just a small braindead patch, not tested at all, just adds testing flag
27;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
--- 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
--- 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=10416&action=view)
Testcase with linker script
This testcase uses a linker script. The proposed pat
--- 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 se
--- 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, the
--- 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
--- 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
dot gnu dot org
ReportedBy: samuel dot thibault at ens-lyon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
44 matches
Mail list logo
