Hello,
Samuel Thibault, le dim. 24 nov. 2024 15:18:31 +0100, a ecrit:
> Andreas Schwab, le dim. 24 nov. 2024 15:15:43 +0100, a ecrit:
> > On Nov 24 2024, Sergey Bugaev wrote:
> > > So are you saying that we always must mark any asm statement that
> > > might transfer
actually need to jump to any of the C-level labels?
>
> An ordinary asm is not allowed to change flow control.
I was suggesting on IRC to rather move the asm bit outside any function
and just call it as a function (with attribute noreturn).
Samuel
Samuel Thibault, le dim. 24 nov. 2024 12:44:00 +0100, a ecrit:
> Sergey Bugaev, le dim. 24 nov. 2024 14:35:33 +0300, a ecrit:
> > Reduced further:
> >
> > --8<--
> > struct hurd_sigstate;
> >
> > typedef struct
> > {
>
> [... the
atile ("movq %0, %%rsp\n"
> "retq $128" :
> : "rm" (usp));
>
> __builtin_unreachable ();
> }
> >8---
Could it be simply because __builtin_unreachable tells gcc that the
function is not supposed to actually execute, just because it doesn't
know that the retq asm snippet is indeed a noreturn? Can we tell gcc
that?
Samuel
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: samuel at sholland dot org
Target Milestone: ---
GCC 8.3.0 warns for some calls to strncpy where n == sizeof(dest). It appears
to only happen if src is anything more complex than a char*, such as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #1 from Samuel Holland ---
Created attachment 45563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45563&action=edit
Output of gcc -v
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: samuel at sholland dot org
Target Milestone: ---
Created attachment 45562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45562&action=edit
Slightly simplified reproducer -- derived from Net::SSLeay cons
t gnu dot org
ReportedBy: samuel dot rodal at nokia dot com
GCC build triplet: arm-none-linux-gnueabi-gcc
GCC host triplet: arm-none-linux-gnueabi-gcc
GCC target triplet: arm-none-linux-gnueabi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43118
--- 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
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
Stat
--- 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
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
Stat
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
Stat
--- 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
sion before «>» token
test.cpp:7: erreur: expected primary-expression before «)» token
--
Summary: Template parameter refused as a template parameter.
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component:
--- 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
-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&#x
--- 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
?
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
Lese selbst:
http://www.my-rocknord.de/viewtopic.php?t=1018&sid=3ce6385b1dee88cb02447f566a2da68d
.. damit Sie nicht als der erste Kanzler in die deutsche Geschichte eingehen,
der Untertanen verboten hat, aus ihren Fenstern auf die Strasse zu gucken -
selbst Nazis und Stalinisten haben niemals ei
54 matches
Mail list logo
