[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)
--- 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 addresses are resolved
by the dynamic linker if -fpic is used. So I wonder, why can't
it resolve also the addresses that are used inside the asm() block?
Am I missing something obvious, or it is a bug too?
--
stsp at users dot sourceforge dot net changed:
What|Removed |Added
CC| |stsp at users dot
| |sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 the last time I am reopening, so you can do whatever you want. -- stsp at users dot sourceforge dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 fine (dosemu). What breakage do you foresee if -g3 will just behave similar to -g? What breakage is that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 don't think people are trying to implicitly put stuff into the debug section. (If they want to do that, they explicitly use a ".section" directive.) That would fix this case and probably avoid the problem in general. --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 happens only with -g3. Do you think someone depended himself on -g3 and is not compiling his programs with -g[012], so that this gcc behaveour is worth keeping? > The real bug here, IMHO, is that it works at all for -g1 and -g2. > The compiler should probably warn about top-level asm blocks without > explicit section switches. OK, that explains a bit, thanks! It also works without -g at all, so some people depended on that for some reasons (dosemu breaks with -g3), but I understand such a warning is not possible to implement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 emitting a warning if the asm in global scope is used with -ffunction-sections? I think the asm in global scope and the -ffunction-sections is a bad combination, so maybe a warning can help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)
--- 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 > of text relocations, but those are not allowed on some architectures and > highly undesirable on the rest of architectures. Is this to always keep the .text section r/o? > In position independent code, > &var typically means you need to load that address from global offset table So, as I understand your answer, the relocation at dynamic-link time is not implemented at all (even on the arches where it is possible)? > into a register, and a register of course can't satisfy "i" constraint. Thanks for the hint. It looks like the things like "a"(&var) do work with -fpic, which should be fine for my needs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug inline-asm/34832] rejects "i"(static_const_var) without -O2
--- 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
[Bug inline-asm/34830] rejects "i"(const_var) without -O1
--- 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
[Bug inline-asm/34833] rejects "i"(&var) with -fpic -m32
--- 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
[Bug inline-asm/34833] New: rejects "i"(&var) with -fpic -m32
Hi.
Opening per suggestion in Bug 23200.
Not entirely sure if this is really a bug,
but it looks like the one.
The following program:
---
static char var;
int main()
{
asm volatile ("" :: "i"(&var));
return 0;
}
---
gives this when compiled with -fpic -m32:
---
asvar1.c: In function 'main':
asvar1.c:4: warning: asm operand 0 probably doesn't match constraints
asvar1.c:4: error: impossible constraint in 'asm'
---
Without -m32 it compiles.
On what targets the relocations are supported?
--
Summary: rejects "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 dot net
GCC host triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
[Bug inline-asm/34830] New: rejects "i"(const_var) without -O1
Hi.
Opening per suggestion in Bug 23200.
The following program:
---
int main()
{
const int i = 1;
asm volatile ("" :: "i"(i));
return i;
}
---
gives this when compiled without -Ox:
---
asc.c: In function 'main':
asc.c:4: warning: asm operand 0 probably doesn't match constraints
asc.c:4: error: impossible constraint in 'asm'
---
Turning on the optimization makes it to compile.
--
Summary: rejects "i"(const_var) without -O1
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 dot net
GCC host triplet: x86_64, i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34830
[Bug inline-asm/23200] [4.1/4.2/4.3 Regression] rejects "i"(&var + 1)
--- 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 34830, Bug 34832, and, just in case, Bug 34833 (the later is probably not a bug). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug inline-asm/34832] New: rejects "i"(static_const_var) without -O2
Hi.
Opening per suggestion in Bug 23200.
The following program:
---
int main()
{
static const int i = 1;
asm volatile ("" :: "i"(i));
return i;
}
---
gives this when compiled without -O2:
---
asc1.c: In function 'main':
asc1.c:4: warning: asm operand 0 probably doesn't match constraints
asc1.c:4: error: impossible constraint in 'asm'
---
Using -O2 makes it to compile.
--
Summary: rejects "i"(static_const_var) without -O2
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 dot net
GCC host triplet: x86_64, i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34832
[Bug inline-asm/34833] rejects "i"(&var) with -fpic -m32
--- 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/show_bug.cgi?id=34833
[Bug inline-asm/34830] rejects "i"(const_var) without -O1
--- 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 optimizer can not silently turn the wrong code into the right code and vice versa. Also, g++ compiles it even without an optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34830
[Bug inline-asm/34833] rejects "i"(&var) with -fpic -m32
--- 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
[Bug inline-asm/23200] New: [4.0 regress] rejects "i"(&var + 1)
Hi.
The following code, that used to compile on the older gcc,
now rejects:
---
static char var;
int main()
{
asm volatile ("" :: "i"(&var + 1));
return 0;
}
---
with the following message:
---
asc.c:5: warning: asm operand 0 probably doesnt match constraints
asc.c:5: error: impossible constraint in asm
---
Changing "+1" to "+0" makes it to compile again.
Here is the info on my gcc:
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=i386-redhat-linux
Thread model: posix
gcc version 4.0.1 20050714 (Red Hat 4.0.1-3)
--
Summary: [4.0 regress] rejects "i"(&var + 1)
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: 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
[Bug target/42789] New: undefined reference to `__sync_fetch_and_add_4'
When I try to compile the program that
ueses boost, for sh4 target, I am getting
the undefined reference errors.
I'll attach the test-case for that, you
just type "make" to see the errors.
The makefile greps the output because there
are much more undefined references to the
other components of the program that I have
not included in the archive, hope it is enough
for testing.
$ sh4-linux-gcc -v
Using built-in specs.
Target: sh4-linux
Configured with: ../configure --host=i686-pc-linux-gnu --target=sh4-linux
--prefix=/opt/STM/STLinux-2.2/devkit/sh4
--exec-prefix=/opt/STM/STLinux-2.2/devkit/sh4
--bindir=/opt/STM/STLinux-2.2/devkit/sh4/bin
--sbindir=/opt/STM/STLinux-2.2/devkit/sh4/sbin
--sysconfdir=/opt/STM/STLinux-2.2/devkit/sh4/etc
--datadir=/opt/STM/STLinux-2.2/devkit/sh4/share
--includedir=/opt/STM/STLinux-2.2/devkit/sh4/include
--libdir=/opt/STM/STLinux-2.2/devkit/sh4/lib
--libexecdir=/opt/STM/STLinux-2.2/devkit/sh4/libexec
--localstatedir=/opt/STM/STLinux-2.2/devkit/sh4/var
--sharedstatedir=/opt/STM/STLinux-2.2/devkit/sh4/share
--mandir=/opt/STM/STLinux-2.2/devkit/sh4/man
--infodir=/opt/STM/STLinux-2.2/devkit/sh4/info --program-prefix=sh4-linux-
--with-local-prefix=/opt/STM/STLinux-2.2/devkit/sh4
--with-sysroot=/opt/STM/STLinux-2.2/devkit/sh4/target --enable-languages=c,c++
--enable-threads=posix --enable-nls --enable-c99 --enable-long-long
--with-system-zlib --enable-shared --enable-multilib --enable-symvers=gnu
--enable-__cxa_atexit
--with-gxx-include-dir=${prefix}/target/usr/include/c++/4.1.1
Thread model: posix
gcc version 4.1.1 (STMicroelectronics/Linux Base 4.1.1-23)
--
Summary: undefined reference to `__sync_fetch_and_add_4'
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
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
[Bug target/42789] undefined reference to `__sync_fetch_and_add_4'
--- 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
[Bug target/42789] undefined reference to `__sync_fetch_and_add_4'
--- 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
[Bug inline-asm/33932] New: miscalculation of asm labels with -g3
The following test program will
print "OK" if compiled without -g3
(-g1, -g2 are fine), and Segfaults
with -g3.
---
#include
asm (
"__tst:\n"
"movl $1, %eax\n"
"ret\n");
int tst(void) asm ("__tst");
int main()
{
if (tst() == 1)
printf("OK\n");
else
printf("Segmentation fault\n");
return 0;
}
---
With -g3, tst() will call to the wrong
address.
gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)
--
Summary: miscalculation of asm labels with -g3
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 dot net
GCC host triplet: x86_64, i386
GCC target triplet: x86_64, i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 specified. And now, since it is not the case only with -g3, maybe it is a bug after all? Is it really wise to have the default section for asm to depend on -g switch? dosemu seems to be miscompiled because of this. Also, even if the asm code is put into another section, why it cannot be called from there? (unless the section is NX, of course) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 current section depends on the -g option and I fail to see anything in the docs that would make this code invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)
--- 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));
doesn't work with both -O0 and -O1. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 this. :) -- stsp at users dot sourceforge dot net changed: What|Removed |Added CC||stsp at users dot ||sourceforge dot net, ||mmitchel at gcc dot gnu dot ||org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- 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 other -gX options. The fact that asm() doesn't automatically change to .text is, as you say, not really a bug. But the erratic behaveour of -g3 certainly is. I guess the problem is that currently it is not officially documented what section is used by default, so the one may say any random section is OK. But IMHO it would be much better to have a particular section be a default, and have it documented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug inline-asm/23200] [4.1/4.2/4.3/4.4 Regression] rejects "i"(&var + 1)
--- 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 too, which right now it does not. -- stsp at users dot sourceforge dot net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
