[Bug c/58892] New: ICE in combine.c when using -Os on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58892
Bug ID: 58892
Summary: ICE in combine.c when using -Os on alpha
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mcree at orcon dot net.nz
Target: alpha
Created attachment 31096
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31096&action=edit
Preprocessed C source that causes ICE.
While compiling linux kernel for Alpha get ICE in combine.c:711 when compiling
drivers/media/dvb-core/dvb-demux.c.
Attached preprocessed source from that compilation. Established that it is the
use of -Os that leads to the ICE. Namely running:
gcc-4.8 -nostdinc -Os -c ices.c
generates the following output:
In file included from
/home/mjc/debian/linux/linux-3.11.5/include/linux/thread_info.h:54:0,
from
/home/mjc/debian/linux/linux-3.11.5/include/linux/preempt.h:9,
from
/home/mjc/debian/linux/linux-3.11.5/include/linux/spinlock.h:50,
from
/home/mjc/debian/linux/linux-3.11.5/include/linux/seqlock.h:29,
from
/home/mjc/debian/linux/linux-3.11.5/include/linux/time.h:5,
from
/home/mjc/debian/linux/linux-3.11.5/include/uapi/linux/timex.h:56,
from
/home/mjc/debian/linux/linux-3.11.5/include/linux/timex.h:56,
from
/home/mjc/debian/linux/linux-3.11.5/include/linux/sched.h:17,
from
/home/mjc/debian/linux/linux-3.11.5/drivers/media/dvb-core/dvb_demux.c:24:
/home/mjc/debian/linux/linux-3.11.5/arch/alpha/include/asm/thread_info.h:52:30:
warning: call-clobbered register used for global register variable [enabled by
default]
register struct thread_info *__current_thread_info __asm__("$8");
^
/home/mjc/debian/linux/linux-3.11.5/drivers/media/dvb-core/dvb_demux.c: In
function ‘dvb_dmx_swfilter_packet’:
/home/mjc/debian/linux/linux-3.11.5/drivers/media/dvb-core/dvb_demux.c:474:1:
internal compiler error: in do_SUBST, at combine.c:711
}
^
Compilation is sucessful without -Os option or with -O1. ICE reappears if
compile with -O2. ICE only occurs with gcc-4.8 (Debian 4.8.2-1) but not
gcc-4.6 or gcc-4.7 so looks like a regression.
[Bug rtl-optimization/84123] New: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:908, alpha linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84123 Bug ID: 84123 Summary: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:908, alpha linux. Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mcree at orcon dot net.nz Target Milestone: --- Target: alpha Created attachment 43286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43286&action=edit Preprocessed source The attached preprocessed source (modified from the libcgns project) leads to an ICE at optimisation level -O2 but compiles fine at -O1 or -O0. I have trimmed the source substantially from its original but trimming it further loses the ICE. ICE seen with Debian alpha-linux-gnu-gcc version 7.3.0-1 and also with gcc recently compiled from the trunk (8.0.1 20180129). alpha-linux-gnu-gcc -O2 -c test-preprocessed.c /home/mjc/debian/libcgns/libcgns-3.3.0/src/adf/test.c: In function ‘ADFI_ID_2_file_block_offset.part.0’: /home/mjc/debian/libcgns/libcgns-3.3.0/src/adf/test.c:619:1: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:908 Recent gcc prints out more information: ./toolchain/gcc-install/bin/gcc -mcpu=ev4 -O2 -c test-preprocessed.c during RTL pass: combine /home/mjc/debian/libcgns/libcgns-3.3.0/src/adf/test.c: In function ‘ADFI_ID_2_file_block_offset.part.0’: /home/mjc/debian/libcgns/libcgns-3.3.0/src/adf/test.c:619:1: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1010 0x12041b91f gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>) ../../gcc.git/gcc/emit-rtl.c:1010 0x120f7057f change_zero_ext ../../gcc.git/gcc/combine.c:11496 0x120f7087f recog_for_combine ../../gcc.git/gcc/combine.c:11596 0x120f86d43 try_combine ../../gcc.git/gcc/combine.c:3595 0x120f8abcf combine_instructions ../../gcc.git/gcc/combine.c:1320 0x120f8abcf rest_of_handle_combine ../../gcc.git/gcc/combine.c:14856 0x120f8abcf execute ../../gcc.git/gcc/combine.c:14901
[Bug target/86774] Alpha port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86774 Michael Cree changed: What|Removed |Added CC||mcree at orcon dot net.nz --- Comment #2 from Michael Cree --- Just to note that in testing earlier this year I managed to successfully run meltdown and spectre v1 attacks on Alpha EV68 hardware. These attacks were less successful on EV67 (only a 1% to 2% success rate). I failed to get any attack on EV56---cache timings did not reveal anything useful (though I did not spend too much time analysing this case).
[Bug c++/71145] New: Alpha: Error: No lda !gpdisp!278 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71145
Bug ID: 71145
Summary: Alpha: Error: No lda !gpdisp!278 was found
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mcree at orcon dot net.nz
Target Milestone: ---
Target: alpha
In certain packages on debian-ports build logs for the Alpha architecture I am
seeing compile failures of the nature:
{standard input}: Assembler messages:
{standard input}:7233: Error: No lda !gpdisp!278 was found
One such example is src/player/SubscriberInfo.o of the source package libavg
(build log is at
https://buildd.debian.org/status/fetch.php?pkg=libavg&arch=alpha&ver=1.8.1-2.1&stamp=1461798687).
Compile failure happens with gcc-5 (Debian version 5.3.1-19) and also with
gcc/g++ (7.0.0) built from the trunk about a week ago (though the line number
of the failure changes).
I will attempt to attach preprocessed source of SubscriberInfo.cpp from libavg.
Um, no I can't; it's too large for the 1000kB limit. How can I provide the
file?
Compiling with:
g++ -pthread -ffast-math -pipe -g -O2 -c SubscriberInfo-preprocessed.cpp -fPIC
-o .libs/SubscriberInfo.o
results in the No lda gpdisp error.
It successfully compiles if the -O2 is changed to -O0 or -O1.
[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71145 --- Comment #3 from Michael Cree --- Created attachment 38500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38500&action=edit compressed preprocessed source Failing preprocessed source compressed with gzip; hopefully this goes through okay.
[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71145 --- Comment #5 from Michael Cree --- Yes, that patch fixes it for me.
[Bug jit/82174] New: Null name in one entry of the builtin_data array of jit-builtins.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82174
Bug ID: 82174
Summary: Null name in one entry of the builtin_data array of
jit-builtins.c
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mcree at orcon dot net.nz
Target Milestone: ---
I see a segmentation violation in some code calling libgccjit. The backtrace
is:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 pp_format(pretty_printer*, text_info*) () at
../../gcc.git/gcc/pretty-print.c:317
317 output_buffer *buffer = pp_buffer (pp);
(gdb) bt
#0 pp_format(pretty_printer*, text_info*) () at
../../gcc.git/gcc/pretty-print.c:317
#1 0x7fef3c1fc698 in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) ()
at ../../gcc.git/gcc/diagnostic.c:974
#2 0x7fef3c1fc99e in diagnostic_impl
(richloc=richloc@entry=0x7fff20ffec20, opt=opt@entry=-1,
gmsgid=gmsgid@entry=0x7fef3c6e88d7 "in %s, at %s:%d",
ap=ap@entry=0x7fff20ffec08,
kind=kind@entry=DK_ICE) at ../../gcc.git/gcc/diagnostic.c:1099
#3 0x7fef3c1fd63d in internal_error (gmsgid=gmsgid@entry=0x7fef3c6e88d7
"in %s, at %s:%d")
at ../../gcc.git/gcc/diagnostic.c:1422
#4 0x7fef3b631a49 in fancy_abort (
file=file@entry=0x7fef3c29aea0 "../../gcc.git/gcc/jit/jit-builtins.c",
line=line@entry=71,
function=function@entry=0x7fef3c29ec80 "matches_builtin") at
../../gcc.git/gcc/diagnostic.c:1488
#5 0x7fef3b38c6d8 in gcc::jit::matches_builtin (bd=..., bd=...,
in_name=0x434b21 "__builtin_ia32_orps256") at
../../gcc.git/gcc/jit/jit-builtins.c:71
#6 gcc::jit::find_builtin_by_name (out_id=,
in_name=0x434b21 "__builtin_ia32_orps256")
at ../../gcc.git/gcc/jit/jit-builtins.c:118
#7 gcc::jit::builtins_manager::get_builtin_function (this=0x2619850,
name=0x434b21 "__builtin_ia32_orps256") at
../../gcc.git/gcc/jit/jit-builtins.c:150
#8 0x7fef3b644019 in gcc_jit_context_get_builtin_function (ctxt=0x25d2ac0,
name=name@entry=0x434b21 "__builtin_ia32_orps256") at
../../gcc.git/gcc/jit/libgccjit.c:917
#9 0x00417bfd in ip_be_avx2_fdecls (be=be@entry=0x643820 ) at
intel-avx2.c:201
#10 0x004143d7 in ip_init_jit () at jit.c:892
#11 0x0040a0ac in time_ip_init_jit () at arith-test.c:231
#12 run_im_ii_tests (operator=operator@entry=0, size=size@entry=...,
chk_flag=112) at arith-test.c:505
#13 0x0040594a in main (argc=, argv=) at
arith-test.c:616
Stepping up to #6 find_builtin_by_name() finds that the loop counter i is:
(gdb) print i
$2 = 1092
but the entries about i in the builtin_data array are:
(gdb) print builtin_data[1091]
$5 = {name = 0x7fef3c2a3964 "__builtin__ITM_RfWE", fnclass = BUILT_IN_NORMAL,
type = gcc::jit::BT_FN_LDOUBLE_VPTR, both_p = false, fallback_p = true,
attr = gcc::jit::ATTR_TM_PURE_TMPURE_NOTHROW_LIST, implicit_p = false}
(gdb) print builtin_data[1092]
$6 = {name = 0x0, fnclass = BUILT_IN_NORMAL, type = gcc::jit::BT_LAST, both_p =
false, fallback_p = false,
attr = gcc::jit::ATTR_LAST, implicit_p = false}
(gdb) print builtin_data[1093]
$7 = {name = 0x7fef3c2a3978 "__builtin___asan_init", fnclass = BUILT_IN_NORMAL,
type = gcc::jit::BT_FN_VOID, both_p = true, fallback_p = true, attr =
gcc::jit::ATTR_NOTHROW_LEAF_LIST,
implicit_p = true}
and it's clear that the name in entry 1092 is NULL, which eventually leads to a
failed insert and the segfault. The size of the array is 46752 and each entry
has 32 bytes thus the code is expecting 1461 entries in the array.
[Bug c/61336] New: ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61336
Bug ID: 61336
Summary: ICE on alpha: in print_operand_address, at
config/alpha/alpha.c:5454
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mcree at orcon dot net.nz
Target: alpha
Created attachment 32869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32869&action=edit
Failing preprocessed source being malloc/malloc.c from glibc
ICE noted with Debian gcc-4.8.3 and now verified with trunk when compiling
malloc.c from glibc on alpha. Preprocessed source attached.
/home/mjc/toolchain/gcc-build/./gcc/xgcc -B/home/mjc/toolchain/gcc-build/./gcc/
ccjDEL1Z.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings
-fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes
-mlong-double-128 -mieee -mfp-rounding-mode=d -fpic
In file included from malloc.c:1878:0:
arena.c: In function ‘ptmalloc_unlock_all2’:
arena.c:303:33: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
arena.c:313:25: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
In file included from malloc.c:1878:0:
arena.c: In function ‘_int_new_arena’:
arena.c:768:24: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
malloc.c: In function ‘__libc_mallopt’:
malloc.c:4833:1: internal compiler error: in print_operand_address, at
config/alpha/alpha.c:5468
0x120a110cf print_operand_address(_IO_FILE*, rtx_def*)
../../gcc.git/gcc/config/alpha/alpha.c:5468
0x1206b3aa7 default_print_operand_address(_IO_FILE*, rtx_def*)
../../gcc.git/gcc/targhooks.c:344
0x12039cc87 output_address(rtx_def*)
../../gcc.git/gcc/final.c:3838
0x120a10e83 print_operand(_IO_FILE*, rtx_def*, int)
../../gcc.git/gcc/config/alpha/alpha.c:5345
0x1206b3a77 default_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc.git/gcc/targhooks.c:330
0x12039cb87 output_operand(rtx_def*, int)
../../gcc.git/gcc/final.c:3822
0x12039d267 output_asm_insn
../../gcc.git/gcc/final.c:3720
0x12039ec2f output_asm_insn
../../gcc.git/gcc/final.c:2643
0x12039ec2f final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../gcc.git/gcc/final.c:2594
0x12039ef23 final(rtx_def*, _IO_FILE*, int)
../../gcc.git/gcc/final.c:2025
0x12039f533 rest_of_handle_final
../../gcc.git/gcc/final.c:
0x12039f533 execute
../../gcc.git/gcc/final.c:4518
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
{standard input}: Assembler messages:
{standard input}:14226: Warning: end of file in string; '"' inserted
{standard input}: Warning: .ent directive without matching .end
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61336 --- Comment #2 from Michael Cree --- OK, I had reported the ICE on the basis that any ICE, whether the code under compilation is correct or not, is a bug. I guess you are implying that when the problem is an inlined asm then it cannot be guaranteed that all the compiler's assumptions are satisfied thus an ICE might be a reasonable outcome? I think I said the source file is from glibc, but actually it is Debian eglibc, which has come via the eglibc project from glibc before being masssaged by Debian. I shall try to see if I can trip the ICE on glibc source itself (it doesn't happen with default configure options, but that's not a sufficient test). Is there some way one can identify in the source exactly the problematic inline asm? I see line 4764 of malloc.c reported in the comment above but that line involves macros. (The difference between the eglibc I used and glibc is not at that point in malloc.c; it might be somewhere in the header files and the macros defined.)
[Bug target/61586] New: ICE on alpha in alpha_handle_trap_shadows, at config/alpha/alpha.c:8724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61586 Bug ID: 61586 Summary: ICE on alpha in alpha_handle_trap_shadows, at config/alpha/alpha.c:8724 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mcree at orcon dot net.nz Target: alpha Created attachment 32985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32985&action=edit Failing preprocessed source. gcc ICE in alpha_handle_trap_shadows, at config/alpha/alpha.c:8724 seen with the attached preprocessed source (being a source file from python-scipy) when compiling at -O2 with both -mieee and -mcpu=ev4 on gcc git master and the 4.9 branch. /home/mjc/toolchain/gcc-build/./gcc/xgcc -B/home/mjc/toolchain/gcc-build/./gcc/ -g -O2 -mcpu=ev4 -mieee -c ccEXci8c.c scipy/ndimage/src/ni_fourier.c: In function ‘NI_FourierFilter’: scipy/ndimage/src/ni_fourier.c:420:1: internal compiler error: in alpha_handle_trap_shadows, at config/alpha/alpha.c:8726 0x120a0b303 alpha_handle_trap_shadows ../../gcc.git/gcc/config/alpha/alpha.c:8726 0x120a0b303 alpha_reorg ../../gcc.git/gcc/config/alpha/alpha.c:9396 0x12064347b execute ../../gcc.git/gcc/reorg.c:3959 Please submit a full bug report, with preprocessed source if appropriate. Reducing optimisation to -O1 or leaving out any of -mieee or -mcpu=ev4 results in a successful compilation. While I have not checked the gcc git 4.8 branch I note that Debian supplied gcc-4.8 compiles the file fine whereas Debian supplied gcc-4.9 ICEs so likely to be a regression from the 4.8 branch. I wonder if this ICE is related in any way to bug 56858.
[Bug c/59820] New: alpha: incorrect optimisation with -mcpu=ev4 and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820 Bug ID: 59820 Summary: alpha: incorrect optimisation with -mcpu=ev4 and -O2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mcree at orcon dot net.nz Target: alpha Created attachment 31837 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31837&action=edit Test code exhibiting problem Compiling the attached test (which is a cut down version of a test from glibc test suite) on an Alpha with -mcpu=ev4 at optimisation -O2 leads to a segmentation fault when the test is run. Output is: $ gcc -mcpu=ev4 -O2 -o gcc-optim-test gcc-optim-test.c $ ./gcc-optim-test set bar to 1 (LE) Segmentation fault Compiling at lower optimisation works correctly, e.g.: $ gcc -mcpu=ev4 -O1 -o gcc-optim-test gcc-optim-test.c $ ./gcc-optim-test set bar to 1 (LE) get sum of foo and bar (LD) = 1 Compiling for more advanced Alpha CPU works correctly, even at -O2, e.g.: $ gcc -mcpu=ev5 -O2 -o gcc-optim-test gcc-optim-test.c $ ./gcc-optim-test set bar to 1 (LE) get sum of foo and bar (LD) = 1 Bug is seen on all versions of gcc tested ranging from gcc-4.4 upto gcc-4.8 from Debian, and gcc git master at commit eb5d7331da45b675e (SVN trunk 206563). Running the failing version under gdb: $ gcc -g -mcpu=ev4 -O2 -o gcc-optim-test gcc-optim-test.c $ gdb ./gcc-optim-test (gdb) run Starting program: /home/mjc/test/./gcc-optim-test set bar to 1 (LE) Program received signal SIGSEGV, Segmentation fault. 0x0201545c in __tls_get_addr () from /lib/ld-linux.so.2 (gdb) bt full #0 0x0201545c in __tls_get_addr () from /lib/ld-linux.so.2 No symbol table info available. #1 0x000125a4 in do_test () at gcc-optim-test.c:44 __result = 0x2031230 result = 0 ap = bp = #2 main () at gcc-optim-test.c:63 No locals. (gdb) disass Dump of assembler code for function __tls_get_addr: 0x02015420 <+0>:ldahgp,2(t12) 0x02015424 <+4>:ldagp,27728(gp) 0x02015428 <+8>:ldasp,-32(sp) 0x0201542c <+12>:rduniq 0x02015430 <+16>:clra1 0x02015434 <+20>:ldqt0,-28776(gp) 0x02015438 <+24>:stqs0,8(sp) 0x0201543c <+28>:mova0,s0 0x02015440 <+32>:ldqa0,0(v0) 0x02015444 <+36>:stqs1,16(sp) 0x02015448 <+40>:movv0,s1 0x0201544c <+44>:stqra,0(sp) 0x02015450 <+48>:ldqt1,0(a0) 0x02015454 <+52>:cmpeqt1,t0,t0 0x02015458 <+56>:beqt0,0x2015494 <__tls_get_addr+116> => 0x0201545c <+60>:ldqa2,0(s0) (gdb) info registers v0 0x2030b102199023454992 t0 0x11 t1 0x11 t2 0x2941 t3 0x2025ff02199023411184 t4 0x72616220646e61208241976684328149280 t5 0x6f660029444c28208027103563073988640 t6 0x61206f6f6620666f6998716345179203183 t7 0x61206998593820933750784 s0 0x1200185d84831938008 s1 0x2030b102199023454992 s2 0x1201383884833117064 s3 0x00 s4 0x120143d904833164688 s5 0x1201453304833170224 fp 0x00 a0 0x20312302199023456816 a1 0x00 a2 0x00 a3 0x21c87982199025125272 a4 0x-1 a5 0x00 t8 0x2840 t9 0x20b72802199024005760 t100x1117 t110x4001024 ra 0x125a44831839652 t120x20154202199023342624 at 0x7c8ad2d82089472728 gp 0x203c0700x203c070 sp 0x11f8cd5c00x11f8cd5c0 pc 0x201545c0x201545c <__tls_get_addr+60> (gdb) print (long)*0x1200185d8 Cannot access memory at address 0x1200185d8 So it would appear that the argument passed to __tls_get_addr() was not a valid address.
[Bug target/59679] gcc version 4.7.3 and gcc version 4.5.3 cause an unaligned access exception on NetBSD/Alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59679 Michael Cree changed: What|Removed |Added CC||mcree at orcon dot net.nz --- Comment #10 from Michael Cree --- This misaligned access in perl is also seen on Debian Alpha Linux. I have been able to reduce the scope.c file substantially while maintaining the misaligned access. I will attach that as scope-reduced.c. The misaligned access occurs in line 60, being the case SAVEt_I8 of the switch statement, and with -O2 compiles to: extbl $4,1,$4 $LVL18: ldl $1,0($6) bic $1,255,$1 bis $4,$1,$4 stl $4,0($6) Thus there is an assumption that ARG0_PTR (which expands to arg0.any_ptr) points to an address at least divisible by four. If one compiles with -fno-tree-ter as mentioned in the initial bug report then one gets: sll $5,48,$5 $LVL18: ldq_u $1,0($4) sra $5,56,$5 mskbl $1,$4,$1 insbl $5,$4,$5 bis $5,$1,$5 stq_u $5,0($4) which copes with any alignment. If either of the cases SAVEt_SAVESWITCHSTACK or SAVEt_SET_SVFLAGS is removed from the switch statement then the ldq_u/mskbl/insbl sequence results. Thus there appears to be some interaction between those two cases and the code at the top of the while statement that the compiler is using to determine that ARG0_PTR points to an address at least divisible by four. I admit that I have so far failed to see how such an inference can be made but look forward to being educated by the erudite gcc maintainers. Compilation was done with: cc -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2 -v -S scope-reduced.c Using built-in specs. COLLECT_GCC=cc Target: alpha-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-13' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --disable-libmudflap --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-alpha/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-alpha --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-alpha --with-arch-directory=alpha --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-long-double-128 --enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu --target=alpha-linux-gnu Thread model: posix gcc version 4.8.2 (Debian 4.8.2-13) COLLECT_GCC_OPTIONS='-D' 'PERL_CORE' '-D' '_REENTRANT' '-D' '_GNU_SOURCE' '-D' 'DEBIAN' '-D' '_FORTIFY_SOURCE=2' '-g' '-O2' '-v' '-S' /usr/lib/gcc/alpha-linux-gnu/4.8/cc1 -quiet -v -imultilib . -imultiarch alpha-linux-gnu -D PERL_CORE -D _REENTRANT -D _GNU_SOURCE -D DEBIAN -D _FORTIFY_SOURCE=2 scope-reduced.c -quiet -dumpbase scope-reduced.c -auxbase scope-reduced -g -O2 -version -o scope-reduced.s GNU C (Debian 4.8.2-13) version 4.8.2 (alpha-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/alpha-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/alpha-linux-gnu/4.8/../../../../alpha-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/alpha-linux-gnu/4.8/include /usr/local/include /usr/lib/gcc/alpha-linux-gnu/4.8/include-fixed /usr/include/alpha-linux-gnu /usr/include End of search list. GNU C (Debian 4.8.2-13) version 4.8.2 (alpha-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 503630c10eca9d1ddabc1e36fce68a5f COMPILER_PATH=/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/:/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/4.8/../../../alpha-linux-gnu/:/usr/lib/gcc/alpha-linux-gnu/4.8/../../../:/lib/alpha-linux-gnu/:/lib/:/usr/lib/alpha-linux-gnu/:/usr/lib/ COLLECT_GCC_OPTIONS='-D' 'PERL_CORE' '-D' '_REENTRANT' '-D' '_GNU_SOURCE' '-D' 'DEBIAN' '-D' '_FORTIFY_SOURCE=2' '-g' '-O2' '-v' '-S' I will also attach preprocessed source.
[Bug target/59679] gcc version 4.7.3 and gcc version 4.5.3 cause an unaligned access exception on NetBSD/Alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59679 --- Comment #11 from Michael Cree --- Created attachment 31957 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31957&action=edit Reduced version of scope.c illustrating problem.
[Bug target/59679] gcc version 4.7.3 and gcc version 4.5.3 cause an unaligned access exception on NetBSD/Alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59679 --- Comment #12 from Michael Cree --- Created attachment 31958 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31958&action=edit Preprocessed version of scope-reduced.c
[Bug target/64113] New: Gcc on Alpha: Error: No lda !gpdisp!282 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64113
Bug ID: 64113
Summary: Gcc on Alpha: Error: No lda !gpdisp!282 was found
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mcree at orcon dot net.nz
Target: alpha-linux-gnu
gcc-4.9.x (and the trunk a couple of weeks ago) compiling certain software
packages (e.g. systemd) on an Alpha running Debian Alpha Linux results in
errors at the link stage such as:
{standard input}: Assembler messages:
{standard input}:5327: Error: No lda !gpdisp!282 was found
lto-wrapper: gcc returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
These packages are successfully compiled with gcc-4.8.x.
I have not been able to construct a minimal source exhibiting the problem. But
because gcc-4.9.0 exhibits the failure and gcc-4.8.0 compiles the code
successfully I have been able to bisect to the first commit in gcc that
produces those errors, and that commit is:
commit c59258dcb37171743fdc6d393e767834aac9642b
Author: law
Date: Tue Nov 12 16:41:51 2013 +
* gimple-ssa-isolate-paths.c (check_loadstore): New function.
(insert_trap_and_remove_trailing_statements): New argument OP which
is the NULL pointer. Emit the trap after the load/store through
the NULL pointer. Simplify the RHS of a store through a NULL pointer
when trivial to do so.
(isolate_path): Corresponding changes.
(gimple_ssa_isolate_erroneous_path): Likewise.
* gcc.dg/tree-ssa/isolate-1.c: Update expected output.
* gcc.dg/tree-ssa/isolate-5.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204708
138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/66207] Switch alpha to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207 Michael Cree changed: What|Removed |Added CC||mcree at orcon dot net.nz --- Comment #14 from Michael Cree --- The Linux kernel has removed non-BWX support for Alpha. The Debian Alpha port has increased the baseline to BWX supported Alphas only. Maybe it is time that gcc did so too. If that would make it realistic to get LRA support for the Alpha target then I would support such a move.
