ram' '-v' '-c'
--
Summary: missed optimisation: function referenced through unused
function pointer not removed
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
ram' '-v' '-c'
--
Summary: missed optimisation: function referenced through unused
function pointer not removed
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #2 from patrick at motec dot com dot au 2008-12-03 02:03
---
It seems my searching skills need improving.
Sorry for the duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38378
ted `('
fp_montgomery_reduce.s:647: Error: junk at end of line: `,4'
fp_montgomery_reduce.s:650: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:650: Error: junk at end of line: `,4'
fp_montgomery_reduce.s:660: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:660: Error: junk at end of line: `,7'
fp_montgomery_reduce.s:663: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:663: Error: junk at end of line: `,7'
fp_montgomery_reduce.s:673: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:673: Error: junk at end of line: `,5'
fp_montgomery_reduce.s:676: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:676: Error: junk at end of line: `,5'
fp_montgomery_reduce.s:686: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:686: Error: junk at end of line: `,21'
fp_montgomery_reduce.s:689: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:689: Error: junk at end of line: `,21'
fp_montgomery_reduce.s:700: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:700: Error: junk at end of line: `,20'
fp_montgomery_reduce.s:703: Error: syntax error; found `,' but expected `('
fp_montgomery_reduce.s:703: Error: junk at end of line: `,20'
--
Summary: Assembler failure: Error: syntax error; found `,' but
expected `('
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrick at motec dot com dot au
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: powerpc-eabispe-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
--- Comment #1 from patrick at motec dot com dot au 2008-10-06 23:06
---
Created an attachment (id=16468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16468&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
--- Comment #2 from patrick at motec dot com dot au 2008-10-06 23:10
---
The problem appears to be that the loop
for (; y < pa; y++) {
asm(" mullw16,%3,%4 \n\t"
" mulhwu 17,%3,%4 \n\t"
"
--- Comment #4 from patrick at motec dot com dot au 2008-10-06 23:31
---
I'm not personally responsible for this code, it is part of the LibTomMath
library.
Changing the constraint to either =o or =g appears to resolve the problem (will
need to test).
--
patrick at motec do
pe/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.3.2/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/:/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.3.2/../../../../powerpc-eabispe/bin/
LIBRARY_PATH=/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabis
--- Comment #1 from patrick at motec dot com dot au 2008-10-07 05:07
---
Created an attachment (id=16472)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16472&action=view)
preprocessed source
after compiling, evstdd and evldd instructions are emitted even though the
-mno-s
able checksum: c30b16423d0b6addaa52d5eb1153852d
ecu_table.c: In function 'find_index_f32':
ecu_table.c:63: error: unrecognizable insn:
(insn 104 103 105 13 ecu_table.c:43 (set (reg:CCFP 193)
(unspec:CCFP [
(reg:CCFP 191)
(reg:CCFP 192)
] 1018)) -1 (nil))
ecu_table.c:63: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: internal compiler error: in extract_insn, at
recog.c:1990
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrick at motec dot com dot au
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: powerpc-eabispe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37760
--- Comment #1 from patrick at motec dot com dot au 2008-10-07 05:49
---
Created an attachment (id=16473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16473&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37760
--- Comment #3 from patrick at motec dot com dot au 2008-10-07 22:14
---
Created an attachment (id=16477)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16477&action=view)
preprocessed source
Setting -mabi=no-spe corrects the the first example.
The new prexeth.i exampl
--- Comment #4 from patrick at motec dot com dot au 2008-10-07 22:15
---
Forgot to add -v output:
powerpc-eabispe-gcc -DLWIP_DEBUG -Iprex/include -Ilwip/src/include
-Ilwip/src/include/ipv4 -I/home/patrick/src/e7/prex
-I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex
--- Comment #5 from patrick at motec dot com dot au 2008-10-07 23:00
---
This looks like an option parsing problem.
Building with the deprecated -mspe=no option suppresses all SPE instructions,
which is what I expect/want. There seems to be no need to specify -mabi=no-spe
if -mspe=no
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrick at motec dot com dot au
GCC build triplet: x86_64-unknown-linux-gnu
GCC
--- Comment #2 from patrick at motec dot com dot au 2010-04-20 00:02
---
Happens while linking my program.
Where in libc are they intended to live? Looking through the source it looks
like they may be part of libgcc.a but for powerpc-eabispe they aren't built.
--
--- Comment #3 from patrick at motec dot com dot au 2010-04-20 01:28
---
I've just done a fresh gcc build and crtsavgpr.asm crtresgpr.asm and friends
definitely aren't being assembled.
Am I expected to provide these functions in the library layer of my operating
system?
--- Comment #5 from patrick at motec dot com dot au 2010-04-20 23:01
---
Running
powerpc-eabispe-objdump -t `powerpc-eabispe-gcc --print-libgcc-file-name` |grep
_save
shows no symbols so I assume something in the build process has gone wrong.
Do you need me to attach my libgcc.a or
--- Comment #9 from patrick at motec dot com dot au 2010-04-30 06:57
---
Khem,
Your libgcc.a looks fine. As far as I know, libgcc.a is supposed to be the last
library listed when linking so the behaviour you are seeing is normal.
My problem is that libgcc.a does not contain _savegpr_
--- Comment #12 from patrick at motec dot com dot au 2010-05-19 22:58
---
(In reply to comment #10)
> See comment #4. I believe this is a pilot error.
>
Richard,
Are you referring to my original bug report or to Khem's link problem.
I don't think (unless I
ion-constant -fno-strict-aliasing -fno-stack-protector
-fno-omit-frame-pointer -o test_xcp_eth.s
GNU C (GCC) version 4.3.0 (powerpc-eabispe)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compil
--- Comment #1 from patrick at motec dot com dot au 2008-05-06 12:46
---
Created an attachment (id=15586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15586&action=view)
preprocessed source
preprocessed source for the file that causes the bug, as required by bug
22 matches
Mail list logo
