--- Comment #21 from stsp at users dot sourceforge dot net 2006-05-13
08:27 ---
Hi guys.
A question: are there any hopes to get this to work with -fpic?
I mean, even the "i"(&var) doesn't work with -fpic.
The "info gcc" says that all the constant addresse
--- Comment #9 from stsp at users dot sourceforge dot net 2008-12-28 09:40
---
OK, Andrew, why do you do this?
Mark have confirmed the existance of
the bug here, yet you resolve it as
a duplicate of an INVALID bug.
Why not to fix the -g3 instead of
always closing this?
Anyway, this is
--- Comment #11 from stsp at users dot sourceforge dot net 2008-12-28
12:33 ---
> but I wouldn't
> want you to expect Mark, nor anyone else, to actually implement that.
Is this because it would be too
much work to implement, or is it
really undesireable?
Just wondering.
--- Comment #13 from stsp at users dot sourceforge dot net 2008-12-28
13:03 ---
The problem is that -g and -g3 do
behave differently. You can't break any
code by making -g3 to behave similar to
-g, or can you?
Its exactly the opposite. -g3 breaks
the code that otherwise works
--- Comment #14 from stsp at users dot sourceforge dot net 2008-12-28
13:04 ---
And what Mark says, is:
---
But, we could make sure that we always pop back from the debug section to
whatever the preceding section was after emitting debug information. That
seems reasonable to me, as I
--- Comment #17 from stsp at users dot sourceforge dot net 2008-12-28
13:54 ---
> Which part of "...as I don't think people are trying to..." gives you the
> certainty that really "people don't"?
What gives me that certainty is the
fact that this
--- Comment #21 from stsp at users dot sourceforge dot net 2008-12-29
22:16 ---
> I agree with Steven that there are some cases (like -ffunction-sections) where
> even popping back from the debug section after generating it doesn't work.
Can this possibly be solved by
--- Comment #25 from stsp at users dot sourceforge dot net 2006-10-05
19:29 ---
> "i"(&var) of course can't work with -fpic,
I tried it on an x86_64 today, and it seems to work.
If I use -m32, then it doesn't. Why?
> it would only work at the expense
&g
--- Comment #1 from stsp at users dot sourceforge dot net 2008-01-17 18:24
---
Created an attachment (id=14961)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14961&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34832
--- Comment #1 from stsp at users dot sourceforge dot net 2008-01-17 18:16
---
Created an attachment (id=14960)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14960&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34830
--- Comment #1 from stsp at users dot sourceforge dot net 2008-01-17 18:39
---
Created an attachment (id=14962)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14962&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
"i"(&var) with -fpic -m32
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stsp at users dot sourceforge d
IRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stsp at users dot sourceforge dot net
GCC host triplet: x86_64, i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34830
--- Comment #35 from stsp at users dot sourceforge dot net 2008-01-17
18:43 ---
(In reply to comment #34)
> We should possibly split this bug into two, one for the inconsitencies that
> can be observed with accepted asms comparing -O0 to -O and one for the
Done.
I opened Bug 3483
IRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stsp at users dot sourceforge dot net
GCC host triplet: x86_64, i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34832
--- Comment #3 from stsp at users dot sourceforge dot net 2008-01-19 08:25
---
Yes, I know, but... without -m32 it compiles.
So either way it might be a bug - maybe it
should not compile without -m32 too? Why does
-m32 make the difference here?
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from stsp at users dot sourceforge dot net 2008-01-19 08:35
---
Yes, but the point was that the same
code should not compile/reject depending
only on an optimizer options.
If this code is invalid, then with -O2 it
should give the error as well, or at least
a warning.
The
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-19 12:47
---
OK, I understand, thank you.
Closing it then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stsp at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stsp at users dot sourceforge dot net
GCC host triplet: i686-linux-gnu
GCC target triplet: sh4-linux-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
--- Comment #1 from stsp at users dot sourceforge dot net 2010-01-18 09:10
---
Created an attachment (id=19645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19645&action=view)
test-case
untar and type "make"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
--- Comment #2 from stsp at users dot sourceforge dot net 2010-01-18 09:15
---
boost is 1.39.0, other versions may not trigger
that problem is seems...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
sion: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stsp at users dot sourceforge dot net
GCC host triplet: x86_64, i386
GCC target triplet: x86_64, i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
--- Comment #1 from stsp at users dot sourceforge dot net 2007-10-28 18:55
---
Created an attachment (id=14428)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14428&action=view)
the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
--- Comment #3 from stsp at users dot sourceforge dot net 2007-10-28 19:25
---
Ohh... thanks for taking a look.
But is it documented anywhere that the
inline asm _must_ specify the section?
I thought the asm code, as well as the
C code, will utilize the .text, unless
the opposite is
--- Comment #4 from stsp at users dot sourceforge dot net 2007-10-29 17:49
---
> Also, even if the asm code is put into
> another section, why it cannot be called
> from there?
This section does not seem to have "a",
so that's why...
But its still nasty that the
--- Comment #33 from stsp at users dot sourceforge dot net 2007-11-22
17:27 ---
> For -O0 expecting
> int i = 1;
> asm ("" :: "i" (i));
> to work is certainly bad assumption
Btw, even the
static const int i = 1;
asm ("" :: "i" (i));
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-11 20:14
---
Actually I don't believe it is not a bug.
The properly functional code cannot be
miscompiled that easily only because of
the different -g option.
Adding Mark to CC for the final judgement
on
--- Comment #7 from stsp at users dot sourceforge dot net 2008-01-11 22:02
---
Thank you for the prompt reply!
I also think simply changing to the previous
section is the good fix because the main problem,
as I see it, is that the -g3 currently has the
different behaveour than the
--- Comment #37 from stsp at users dot sourceforge dot net 2008-07-05
05:28 ---
But I only tried to open the new bugs about
the _other_ -O0 vs -O2 differences that popped
up in this thread.
The original bug is still here I believe.
At least it seems people think it should work
with -O0
30 matches
Mail list logo
