[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 Martin Husemann changed: What|Removed |Added CC||martin at netbsd dot org --- Comment #3 from Martin Husemann --- Note that this makes it impossible for distributions to default to sparc v7 with an unmodified gcc. Only options are - locally patch (fix) gcc - provide separate distribution binaries for v7 and v8 - drop support for v7 completely ... which all three sound bad to me.
[Bug c/89312] snprintf warning is unparsable and not confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89312 --- Comment #4 from Martin Husemann --- This is scary. So in the future there will be valid reasons for the truncation warning, but you are not offering any way to suppress the totally useless false positives? My problem with this warning is that (as of gcc 7.4) it has a S/N ratio very close to 0. snprintf will truncate the output? Yes, that is what the standard says and what I expect from it. There is no usefull more targeted workaround than turning it off. I actually did sucessfully quell the warning with this idiom: char buf[STRLEN]; int r = snprintf(buf, sizeof(buf), format, ); if (r >= sizeof(buf)) buf[sizeof(buf)-1] = 0; but that is of course totally stupid (and hopefully gcc will eliminate the if () part completely (but since the warning goes away, it seems not to do that). We always compile all stuff with -Wall and -Werror, we even dealt with the very painfull (and much too simplistic) case fallthrough checker. But with the format truncation there is no option but to either make the code worse or turn it off completely.
[Bug c/89312] snprintf warning is unparsable and not confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89312 --- Comment #2 from Martin Husemann --- Thanks for the explanation, but I see no way I could improve the code in question reasonably and (sorry to be blunt) consider it quite stupid of gcc to warn about it by default. I do want the total string to be truncated, not individual fields, so precision does not help. Making the target buffer larger makes no sense as there is limited space in the GUI for output. I will globaly shut off the warning, it is useless for this code. This is a (slight) pain, as the warning is (newer) gcc specific.
[Bug c/89312] New: snprintf warning is unparsable and not confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89312
Bug ID: 89312
Summary: snprintf warning is unparsable and not confusing
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Target Milestone: ---
Gcc 7 has a new warning:
partman.c:1908:12: error: ' (' directive output may be truncated writing 2
bytes into a region of size between 1 and 255 [-Werror=format-truncation=]
"%s (%s, %s-%d)",
^~
I am not a native speaker so this may be a lanugage barrirer, but I completely
fail to parse what it is trying to tell me here.
Obviously as I am using snprintf I am aware that truncation of the output could
happen (and happy with it). There is no point in gcc warning about this
(different to cases like strncpy truncation). The function is standard defined
and safe, why warn at all here?
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #4 from Martin Husemann ---
The costs are missing for various modes:
(gdb) p (default_target_ira_int->x_ira_register_move_cost)
$6 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7f7ff7b8c8b0, 0x7f7ff7b8c8b0, 0x0 }
(that is: only HImode and SImode costs are available)
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 --- Comment #3 from Martin Husemann --- Indeed. Digging a bit with gdb (but in our local 6.4 version) shows: #0 0x009fa7be in allocno_copy_cost_saving (allocno=0x7f7ff679a178, hard_regno=11) at /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/ira-color.c:2763 2763 cost += cp->freq * ira_register_move_cost[allocno_mode][rclass][rclass]; (gdb) p (default_target_ira_int->x_ira_register_move_cost)[allocno_mode] $5 = (move_table *) 0x0 Where is that table supposed to be setup?
[Bug target/71695] m68k: long long multiplication broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695 Martin Husemann changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Husemann --- Sorry for late reply - it turns out this was due to a local, let say, "merge mishap" and slightly related to ancient bug 12792.
[Bug c++/79466] New: strange varargs warnings on superflous paranthesises
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79466 Bug ID: 79466 Summary: strange varargs warnings on superflous paranthesises Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Target Milestone: --- Created attachment 40719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40719=edit Simple example triggering the warning When compiled with g++ -std=gnu++14 the expression __builtin_va_start ((ap), (fmt)); triggers a strange warning: example.cc:4:37: warning: second parameter of 'va_start' not last named argument [-Wvarargs] __builtin_va_start ((ap), (fmt)); ^ Removing the extra paranthesis makes it work. This does not happen with -std=gnu++11. Sample attached, compile with: g++ -Wall -O2 -std=gnu++14 -c -o example.o example.cc (warning and optimization settings do not make a difference, only std= is important)
[Bug target/71695] m68k: long long multiplication broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695 Martin Husemann changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from Martin Husemann --- Chuck Silvers has looked a bit closer and found that while it does not happen with an unmodified gcc 5.4 configured for --target=m68k-linux, it is reproducable when configuring for --target=m68k-netbsdelf. One of the differences in the config is the override to BIGGEST_ALIGNEMENT in netbsd-elf.h: For m68k/SVR4, some types (doubles for example) are aligned on 8 byte boundaries */ #undef BIGGEST_ALIGNMENT #define BIGGEST_ALIGNMENT 64 while Linux uses: Most published ABIs say that ints should be aligned on 16-bit boundaries, but CPUs with 32-bit busses get better performance aligned on 32-bit boundaries. */ #define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16) This seems to have been there since prehistoric times. Removing this override makes gcc generate the same code as shown by Andreas. More interesting though is that adding BIGGEST_ALIGNMENT 64 to the linux configuration does NOT make gcc emit the bad code, so there must be another factor involved. Any hints appreciated!
[Bug target/71695] m68k: long long multiplication broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695 Martin Husemann changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Martin Husemann --- Indeed, an unmodified gcc 5.4 configured for linux does not do this - sorry for the noise.
[Bug target/71695] New: m68k: long long multiplication broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695 Bug ID: 71695 Summary: m68k: long long multiplication broken Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Target Milestone: --- Created attachment 38787 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38787=edit source code demonstrating the bug Calculating the nth power of ten in below simple program fails for all input values != 0; i.e.: [/tmp] martin@mac-beth > ./a.out 0 10 [/tmp] martin@mac-beth > ./a.out 1 0 [/tmp] martin@mac-beth > ./a.out 2 0 [/tmp] martin@mac-beth > ./a.out 3 0 This is due to muls.l zeroing both registers at .L3 here: clr.l %d2 moveq #10,%d1 .L3: muls.l %d2,%d1 move.l %d1,%d3 add.l %d3,%d3 mulu.l %d1,%d2:%d1 add.l %d3,%d2 addq.l #1,%a0 cmp.l %d0,%a0 jne .L3 This is with the gcc 5.4 version in the NetBSD source tree, identifying as: Using built-in specs. COLLECT_GCC=/usr/tools/bin/m68k--netbsdelf-gcc COLLECT_LTO_WRAPPER=/usr/tools/libexec/gcc/m68k--netbsdelf/5.4.0/lto-wrapper Target: m68k--netbsdelf Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure --target=m68k--netbsdelf --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb1 20160606' --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads --with-diagnostics-color=auto-if-env --with-sysroot=/hosts/mac68k --with-mpc=/usr/tools --with-mpfr=/usr/tools --with-gmp=/usr/tools --disable-nls --disable-multilib --program-transform-name=s,^,m68k--netbsdelf-, --enable-languages='c c++ objc' --prefix=/usr/tools Thread model: posix gcc version 5.4.0 (NetBSD nb1 20160606) Compiler invocation: m68k--netbsdelf-gcc -S -Wall -O2 bug-m68k.c Any value of -O will cause the bad code.
[Bug c/71051] incorrect sparc64 code generated, inevitable jump to null function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71051 --- Comment #1 from Martin Husemann --- Created attachment 38465 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38465=edit generated asm code
[Bug c/71051] New: incorrect sparc64 code generated, inevitable jump to null function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71051 Bug ID: 71051 Summary: incorrect sparc64 code generated, inevitable jump to null function pointer Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Target Milestone: --- Created attachment 38464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38464=edit striped down example C code Attached is a reduced example of code that is part of the NetBSD C startup, it is used to call all destructors in a shared binary before unloading the module. There is some linker magic used to fill the dtor pointer array. We hit the issue in the wild, but the stripped attached example shows the invalid code. We have seen similar issues on other architectures, so it is likely not sparc64 specific, but this case has been analyzed best. The loop over the dtors is terminated when the current dtor pointer is >= __DTOR_LIST_END__, and the generated asm code goes like: or %i4, %l44(__DTOR_LIST_END__), %i4 cmp %i5, %i4 blu,pt %xcc, .LL5 mov0, %g1 If the branch to .LL5 is taken, %g1 will always be NULL. So not surprisingly we crash by jumping to 0: .LL5: call%g1, 0 add%i5, 8, %i5 This is with the 5.3 version integrated in NetBSD-current: > cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper Target: sparc64--netbsd Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure --target=sparc64--netbsd --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb1 20160317' --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-threads --enable-libstdcxx-time=rt --with-mpc-lib=/var/obj/mknative/sparc64/usr/src/external/lgpl3/mpc/lib/libmpc --with-mpfr-lib=/var/obj/mknative/sparc64/usr/src/external/lgpl3/mpfr/lib/libmpfr --with-gmp-lib=/var/obj/mknative/sparc64/usr/src/external/lgpl3/gmp/lib/libgmp --with-mpc-include=/usr/src/external/lgpl3/mpc/dist/src --with-mpfr-include=/usr/src/external/lgpl3/mpfr/dist/src --with-gmp-include=/usr/src/external/lgpl3/gmp/lib/libgmp/arch/sparc64 --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd7.0. --host=sparc64--netbsd --with-sysroot=/var/obj/mknative/sparc64/usr/src/destdir.sparc64 Thread model: posix gcc version 5.3.0 (nb1 20160317) and the compiler invocation w.as cc -Wall -Wextra -O2 -fno-strict-aliasing -fwrapv -c -S example.c
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Version|4.8.1 |5.2.0 --- Comment #3 from Martin Husemann martin at netbsd dot org --- This still applies to recent versions and is an obvious fix. Please apply!
[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Attachment #30803|0 |1 is obsolete|| --- Comment #2 from Martin Husemann martin at netbsd dot org --- Created attachment 36137 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36137action=edit Updated version of host hooks for NetBSD
[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Version|4.8.1 |5.2.0 --- Comment #3 from Martin Husemann martin at netbsd dot org --- This still applies to current releases of gcc and makes plain FSF gcc unbuildable on many NetBSD architectures.
[Bug driver/61651] Cross compiler will use host as eroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61651 --- Comment #1 from Martin Husemann martin at netbsd dot org --- Passing AS_FOR_TARGET (and friends) in the configure environment does not help, but explicitly adding --with-as=.. does fix the issue. So this looks like a pure configure bug.
[Bug driver/61651] New: Cross compiler will use host as eroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61651 Bug ID: 61651 Summary: Cross compiler will use host as eroneously Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org With a gcc configured like this: mipsel--netbsd-gcc -v Using built-in specs. COLLECT_GCC=mipsel--netbsd-gcc COLLECT_LTO_WRAPPER=/usr/pkg/libexec/gcc/mipsel--netbsd/4.9.0/lto-wrapper Target: mipsel--netbsd Configured with: ../gcc-4.9.0/configure --disable-nls --disable-libquadmath --disable-libquadmath-support --disable-libssp --disable-libgomp --disable-libstdc++-v3 --disable-libatomic --enable-languages='c c++' --enable-shared --enable-long-long --with-local-prefix=/usr/pkg --enable-threads=posix --with-boot-ldflags= --target=mipsel--netbsd --with-gmp=/usr/pkg --with-mpc=/usr/pkg --with-mpfr=/usr/pkg --prefix=/usr/pkg --build=x86_64--netbsd --host=x86_64--netbsd --infodir=/usr/pkg/info --mandir=/usr/pkg/man Thread model: posix gcc version 4.9.0 (GCC) and binutils pre-installed in the PATH, picked up by configure correctly: checking dynamic linker characteristics... NetBSD ld.elf_so checking how to hardcode library paths into programs... immediate checking what assembler to use... /usr/pkg/bin/mipsel--netbsd-as checking whether we are using gold... no checking what linker to use... /usr/pkg/bin/mipsel--netbsd-ld checking what nm to use... /usr/pkg/bin/mipsel--netbsd-nm checking for mipsel--netbsd-objdump... /usr/pkg/bin/mipsel--netbsd-objdump checking what objdump to use... /usr/pkg/bin/mipsel--netbsd-objdump I still get compiler that tries to invoke plain as: mipsel--netbsd-gcc --print-prog-name=as as and also tries to use this, which obviously fails: mipsel--netbsd-gcc -v -c test.c Using built-in specs. COLLECT_GCC=mipsel--netbsd-gcc Target: mipsel--netbsd Configured with: ../gcc-4.9.0/configure --disable-nls --disable-libquadmath --disable-libquadmath-support --disable-libssp --disable-libgomp --disable-libstdc++-v3 --disable-libatomic --enable-languages='c c++' --enable-shared --enable-long-long --with-local-prefix=/usr/pkg --enable-threads=posix --with-boot-ldflags= --target=mipsel--netbsd --with-gmp=/usr/pkg --with-mpc=/usr/pkg --with-mpfr=/usr/pkg --prefix=/usr/pkg --build=x86_64--netbsd --host=x86_64--netbsd --infodir=/usr/pkg/info --mandir=/usr/pkg/man Thread model: posix gcc version 4.9.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' /usr/pkg/libexec/gcc/mipsel--netbsd/4.9.0/cc1 -quiet -v test.c -quiet -dumpbase test.c -auxbase test -version -o /var/tmp//cc5IJkOh.s GNU C (GCC) version 4.9.0 (mipsel--netbsd) compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/pkg/lib/gcc/mipsel--netbsd/4.9.0/../../../../mipsel--netbsd/sys-include ignoring nonexistent directory /usr/pkg/lib/gcc/mipsel--netbsd/4.9.0/../../../../mipsel--netbsd/include #include ... search starts here: #include ... search starts here: /usr/pkg/lib/gcc/mipsel--netbsd/4.9.0/include /usr/pkg/lib/gcc/mipsel--netbsd/4.9.0/include-fixed End of search list. GNU C (GCC) version 4.9.0 (mipsel--netbsd) compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3b870805c849a6d735de46047e60e2cd COLLECT_GCC_OPTIONS='-v' '-c' as -v -EL -O1 -no-mdebug -mabi=32 -KPIC -o test.o /var/tmp//cc5IJkOh.s GNU assembler version 2.23.2 (x86_64--netbsd) using BFD version (NetBSD Binutils nb1) 2.23.2 as: unrecognized option `-EL'
[Bug target/60941] New: gcc 4.8.3/sparc64 miscompiles firefox javascript interpreter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
Bug ID: 60941
Summary: gcc 4.8.3/sparc64 miscompiles firefox javascript
interpreter
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
System: NetBSD/sparc64; NetBSD in-tree version of gcc:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: sparc64--netbsd
Configured with: /usr/src6/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=sparc64--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20120916' --with-system-zlib --enable-__cxa_atexit
--with-mpc-lib=/var/obj/mknative/sparc64/usr/src6/external/lgpl3/mpc/lib/libmpc
--with-mpfr-lib=/var/obj/mknative/sparc64/usr/src6/external/lgpl3/mpfr/lib/libmpfr
--with-gmp-lib=/var/obj/mknative/sparc64/usr/src6/external/lgpl3/gmp/lib/libgmp
--with-mpc-include=/usr/src6/external/lgpl3/mpc/dist/src
--with-mpfr-include=/usr/src6/external/lgpl3/mpfr/dist/src
--with-gmp-include=/usr/src6/external/lgpl3/gmp/lib/libgmp/arch/sparc64
--enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch
--build=x86_64-unknown-netbsd6.0. --host=sparc64--netbsd
--with-sysroot=/var/obj/mknative/sparc64/usr/src6/destdir.sparc64
Thread model: posix
gcc version 4.8.3 (NetBSD nb2 20140304)
When building a firefox 28 with gcc 4.8 and at least -O2 the javascript
interpreter misbehaves and causes firefox to crash. An example URL that
triggers this is:
https://github.com/mconf/ffmpeg/blob/master/doc/optimization.txt
The bug itself is a bit subtle - hope I get it clear:
The firefox javascript interpreter has a very special way to represent all
kinds of values in a single 64 bit value (which makes it impossible to
represent certain double NaN values and some pointer values - however, this is
all properly taken care of). The definition of the Value type is:
typedef union jsval_layout
{
uint64_t asBits;
struct {
JSValueTag tag : 17;
uint64_t payload47 : 47;
} debugView;
struct {
uint32_t padding;
union {
int32_ti32;
uint32_t u32;
JSWhyMagic why;
} payload;
} s;
double asDouble;
void *asPtr;
size_t asWord;
uintptr_t asUIntPtr;
} JSVAL_ALIGNMENT jsval_layout;
There is a helper macro that constructs new Values from 32bit ints:
static inline JS_VALUE_CONSTEXPR jsval_layout
INT32_TO_JSVAL_IMPL(int32_t i32)
{
JS_RETURN_LAYOUT_FROM_BITS(((uint64_t)(uint32_t)i32) |
JSVAL_SHIFTED_TAG_INT32);
}
and JS_RETURN_LAYOUT_FROM_BITS is (depending on ifdefs) in this case defined
as:
# define JS_RETURN_LAYOUT_FROM_BITS(BITS) \
return (jsval_layout) { .asBits = (BITS) }
Now ignoring a few details, the values with tag 0xfff88 in the high order bits
are int32 values, and the low order bits just contain the value.
With some printf instrumentation, right before the crash happens, the
interpreter stack looks like:
end of JSOP_INT8 top of stack: fff88019
end of JSOP_URSH top of stack: fff88028
end of JSOP_BITXOR top of stack: fff8814e18ab
end of JSOP_GETLOCAL top of stack: fff88000510e527f
end of JSOP_INT8 top of stack: fff8801a
now you see 0x510e527f and 0x1a as the topmost values, both int32. Next a
logical shift left is done with these two.
The assembler code generated loads the args into %g2 and %g3 and does a sll:
(gdb) p/x $g3
$1 = 0x510e527f
(gdb) p/x $g2
$2 = 0x1a
0xfe4d97e0 sll %g3, %g2, %g2
now sll leaves the high 32 bits in undefined state, so after the sll we get
0x1443949fc00 instead of 0xfc00 in %g2. Unfortunately the code now ors
the correct tag bits into this and stores it directly as a 64bit value:
= 0xfe4d97e4 ldx [ %l7 + %o0 ], %o0
0xfe4d97e8 add %g1, -8, %g3
0xfe4d97ec or %g2, %g4, g2
0xfe4d97f0 stx %g3, [ %fp + 0x727 ]
(the 0xfff88 tag bits had been precomputed in %g4 earlier). This leads to
broken jsvalue_layout data, as the result now looks like a pointer to a
javascript object to the interpreter, and when trying to call methods of that,
the crash happens.
The code in the interpreter loop (slightly unriddled a few macros) looks
correct to me:
CASE(JSOP_LSH)
{
int32_t i, j;
if (!ToInt32(cx, REGS.stackHandleAt(-2), i))
goto error;
if (!ToInt32(cx, REGS.stackHandleAt(-1), j))
goto error;
i = i (j 31);
REGS.sp--;
REGS.sp[-1].setInt32(i);
}
END_CASE(JSOP_LSH)
The setInt32() function is the accessor mentioned earlier:
void setInt32(int32_t i) {
data
[Bug target/60941] gcc 4.8.3/sparc64 miscompiles firefox javascript interpreter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
Here is a small test program:
---8---
#include stdio.h
#include stdlib.h
int main(int argc, char **argv)
{
unsigned long v[2], *p;
int a, b;
for (int i = 0; i 2 i argc; i++) {
v[i] = atol(argv[i+1]) | 0xfff88000;
printf(i = %d, got: %lx\n, i, v[i]);
}
p = v[1];
a = *p-- 0x0;
b = *p 0x0;
printf(a = %08x b= %08x\n, a, b);
b = a (b 31);
*p = ((uint64_t)(uint32_t)b) | 0xfff88000;
printf(res: %08lx\n, *p);
return 0;
}
---8---
compile with c++ -Wall -O2 test.c and run as:
./a.out 26 1359893119
i = 0, got: fff8801a
i = 1, got: fff88000510e527f
a = 510e527f b= 001a
res: fffcb949fc00
I would have expected res: 0xfff88000fc00 (and on amd64 I get exactly that)
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 --- Comment #5 from Martin Husemann martin at netbsd dot org --- Thomas and I compared environments and found the difference: it is gcc compiled by clang that misbehaves. I could reproduce and verify it - but past bootstrapping it is something that will never happen to native FSF gcc in the wild, I suppose.
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 --- Comment #4 from Martin Husemann martin at netbsd dot org --- Neither can I on NetBSD/amd64 - will check with Thomas for differences on his system
[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749 --- Comment #4 from Martin Husemann martin at netbsd dot org --- Yes - I'm still trying to reduce it to a reasonable test case, but in general it works - so I am confused big time. Also Julio (the ATF author) claims the same test works on FreeBSD with a very similar compiler version.
[Bug c/59958] alpha does not deal with non-aligned returns from malloc() when doing byte wise access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59958 --- Comment #2 from Martin Husemann martin at netbsd dot org --- Is the alignment expected from malloc() configurable in gcc and/or different from the standard stack alignment? A small test program along the lines of if ((uintptr_t)malloc(1) mask) printf(yes\n) else printf(no\n); and checking what gcc -O2 optimizes away for different masks seems to show that on alpha 7 is optimized, while 15 is not. This sounds good for alpha. However, I get the same results for amd64 - where I would have expected the required alignement to be 16 byte. Is this a bug in our amd64 target configuration, or am I misundertanding something?
[Bug c/59958] New: alpha does not deal with non-aligned returns from malloc() when doing byte wise access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59958
Bug ID: 59958
Summary: alpha does not deal with non-aligned returns from
malloc() when doing byte wise access
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Created attachment 31962
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31962action=edit
generated assembler code (cc -O2 -S test.c)
On NetBSD/alpha a call to malloc requesting a two byte allocation may return a
pointer that is only 2-byte algined. We believe this to be within the C std
spec (as alignemnt is good enough for all complete objects fitting in the
allocated space).
However, gcc seems to assume return values from malloc to have higher
alignment.
This test program:
--8--
#include stdio.h
#include stdlib.h
int main(int argc, char **argv)
{
char *p;
size_t i;
for (i = 0; i 24; i++) {
p = malloc(2);
printf(got %p\n, p);
p[0] = 'A'; p[1] = 0;
printf(stored string: %s\n, p);
}
return 0;
}
--8--
shows the problem:
[..]
got 0x3fffdc02238
stored string: A
got 0x3fffdc0223a
pid 600 (a.out): unaligned access: va=0x3fffdc0223a pc=0x12bc4
ra=0x12bbc sp=0x1db08 op=ldl
pid 600 (a.out): unaligned access: va=0x3fffdc0223a pc=0x12be4
ra=0x12bbc sp=0x1db08 op=stl
stored string: A
got 0x3fffdc0223c
stored string: A
got 0x3fffdc0223e
pid 600 (a.out): unaligned access: va=0x3fffdc0223e pc=0x12bc4
ra=0x12bbc sp=0x1db08 op=ldl
pid 600 (a.out): unaligned access: va=0x3fffdc0223e pc=0x12be4
ra=0x12bbc sp=0x1db08 op=stl
stored string: A
got 0x3fffdc02240
[..]
This might be more of a problem with target alpha and the byte access code,
compiling the test program with -mbwx does help (but not all alpha CPUs support
that).
gcc version used:
cc -v
Using built-in specs.
COLLECT_GCC=cc
Target: alpha--netbsd
Configured with: /usr/src7/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=alpha--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20120916' --with-system-zlib --enable-__cxa_atexit
--with-mpc-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/mpc/lib/libmpc
--with-mpfr-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/mpfr/lib/libmpfr
--with-gmp-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/gmp/lib/libgmp
--with-mpc-include=/usr/src7/external/lgpl3/mpc/dist/src
--with-mpfr-include=/usr/src7/external/lgpl3/mpfr/dist/src
--with-gmp-include=/usr/src7/external/lgpl3/gmp/lib/libgmp/arch/alpha
--enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch
--build=x86_64-unknown-netbsd6.0. --host=alpha--netbsd
--with-sysroot=/var/obj/mknative/alpha/usr/src7/destdir.alpha
Thread model: posix
gcc version 4.8.3 (NetBSD nb1 20131213)
[Bug c/59674] On m68k and vax variables stack variables with MAX_STACK_ALIGNMENT make ssp fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674 Martin Husemann martin at netbsd dot org changed: What|Removed |Added CC||martin at netbsd dot org --- Comment #8 from Martin Husemann martin at netbsd dot org --- (In reply to Andreas Schwab from comment #7) If you have fundamental types with stricter alignment requirements than provided by STACK_BOUNDARY your ABI has a problem, and this SSP failure is just one symptom. Why is that a fundamental problem? It is not that different to i386 and data used for MMX/SSE instructions - not nice, but the compiler should be able to cope.
[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749 --- Comment #2 from Martin Husemann martin at netbsd dot org --- Unfortunately I can not reproduce the issue with the .i file generated with -save-temps (but still with the original .c file).
[Bug c/59749] New: unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749
Bug ID: 59749
Summary: unused warning not emited for unused static struct
unles -save-temps is used
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Created attachment 31793
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31793action=edit
original source file exhibiting the problem
I have a program (for the atf testing framework) that is supposed to warn about
an unused variable and (due to -Werror) fail compilation. This works fine with
gcc 4.5.4.
But with 4.8.2 I get:
$ /usr/pkg/gcc48/bin/cc -O2 -c -Wall -Werror /usr/tests/atf/atf-c/unused_test.c
$
The code (after macro expansion) declares a struct and initialize it:
static atfu_this_is_unused_tc_pack = { .m_ident = };
and there is no reference to this struct anywhere in the file.
Interestingly when preparing for this ticket I did:
$ /usr/pkg/gcc48/bin/cc -O2 -save-temps -c -Wall -Werror
/usr/tests/atf/atf-c/unused_test.c
/usr/tests/atf/atf-c/unused_test.c:41:123: error: 'atfu_this_is_unused_tc'
defined but not used [-Werror=unused-variable]
ATF_TC(this_is_unused);
^
cc1: all warnings being treated as errors
$ /usr/pkg/gcc48/bin/cc -v Using built-in specs.
COLLECT_GCC=/usr/pkg/gcc48/bin/cc
COLLECT_LTO_WRAPPER=/usr/pkg/gcc48/libexec/gcc/sparc64--netbsd/4.8.2/lto-wrapper
Target: sparc64--netbsd
Configured with: ../gcc-4.8.2/configure --enable-languages='c c++'
--enable-shared --enable-long-long --with-local-prefix=/usr/pkg/gcc48
--enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++
-static-libgcc -Wl,-R/usr/pkg/lib ' --with-gnu-ld --with-ld=/usr/bin/ld
--with-gnu-as --with-as=/usr/bin/as --disable-nls --with-gmp=/usr/pkg
--with-mpc=/usr/pkg --with-mpfr=/usr/pkg --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc48/include/c++/ --prefix=/usr/pkg/gcc48
--build=sparc64--netbsd --host=sparc64--netbsd --infodir=/usr/pkg/gcc48/info
--mandir=/usr/pkg/gcc48/man
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749 --- Comment #1 from Martin Husemann martin at netbsd dot org --- Created attachment 31794 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31794action=edit unused_test.i file from -save-temps
[Bug c/59750] New: stack protector does not catch 1 byte overwrite of char[10] array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59750
Bug ID: 59750
Summary: stack protector does not catch 1 byte overwrite of
char[10] array
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
This test program correctly dies when compiled with gcc 4.5.4:
#include string.h
int main(int argc, char **argv)
{
char b[10];
strcpy(b, 1);
strcat(b, 012345678);
return 0;
}
but when compiled with gcc 4.8.2 it does not cause an abort on sparc64:
$ /usr/pkg/gcc48/bin/cc -fstack-protector -O0 test.c
$ ./a.out
$
Using a few more chars (0123456789ABCDE) in the strcat make ssp catch it.
$ /usr/pkg/gcc48/bin/cc -v
Using built-in specs.
COLLECT_GCC=/usr/pkg/gcc48/bin/cc
COLLECT_LTO_WRAPPER=/usr/pkg/gcc48/libexec/gcc/sparc64--netbsd/4.8.2/lto-wrapper
Target: sparc64--netbsd
Configured with: ../gcc-4.8.2/configure --enable-languages='c c++'
--enable-shared --enable-long-long --with-local-prefix=/usr/pkg/gcc48
--enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++
-static-libgcc -Wl,-R/usr/pkg/lib ' --with-gnu-ld --with-ld=/usr/bin/ld
--with-gnu-as --with-as=/usr/bin/as --disable-nls --with-gmp=/usr/pkg
--with-mpc=/usr/pkg --with-mpfr=/usr/pkg --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc48/include/c++/ --prefix=/usr/pkg/gcc48
--build=sparc64--netbsd --host=sparc64--netbsd --infodir=/usr/pkg/gcc48/info
--mandir=/usr/pkg/gcc48/man
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug target/58901] vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901 --- Comment #5 from Martin Husemann martin at netbsd dot org --- Created attachment 31275 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31275action=edit .i file from the failing compile
[Bug target/58901] vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901 --- Comment #6 from Martin Husemann martin at netbsd dot org --- This is beyound my gcc capabilities: the rtx in question is wrong for vax, but the bug seems to be at a higher level: an indexed memory access can not be wrapped into a subreg with offset in the same statement - the rtx needs to be split into a register load and then subreg extraction (or so I think, not an expert in vax addressing modes)
[Bug target/58901] vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #3 from Martin Husemann martin at netbsd dot org ---
Matt asked for the instruction involved - I think it is this:
(insn 245 244 246 51 (set (mem:HI (reg/v/f:SI 1 %r1 [orig:67 sup ] [67]) [2
*sup_104+0 S2 A16])
(plus:HI (subreg:HI (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0
[orig:81 count ] [81])
(const_int 4 [0x4]))
(symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl
0x7f22fe60 DECPOWERS)) [3 DECPOWERS S4 A32]) 0)
(const_int -1 [0x])))
../../gcc-4.8.2/libdecnumber/decNumber.c:7183 48 {addhi3}
(nil))
[Bug target/58901] vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901 --- Comment #4 from Martin Husemann martin at netbsd dot org --- I got a quick lesson in addressing modes for vax ;-) It seems the mode = HImode passed to the upper functions in the call stack is the problem - with HImode we can only use index operands with a factor of 2, but this rtx has a factor of 4. The problem starts in alter_subreg(), where the call to adjust_address_1 is done: #6 0x002d1a06 in alter_subreg (xp=0x7f0e8bc8, final_p=true, 2131659720, 1) at ../../gcc-4.8.2/gcc/final.c:3072 3072*xp = adjust_address (y, GET_MODE (x), offset); and x has (due to subreg) HImode: (gdb) p debug_rtx(x) (subreg:HI (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81]) (const_int 4 [0x4])) (symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS)) [3 DECPOWERS S4 A32]) 0) $12 = void (gdb) p debug_rtx(y) (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81]) (const_int 4 [0x4])) (symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS)) [3 DECPOWERS S4 A32])
[Bug target/58901] vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901 --- Comment #1 from Martin Husemann martin at netbsd dot org --- The real question is: why does memory_address_addr_space_p() return false for this rtx. Stepping into it results in: 0x007618be in vax_legitimate_address_p (mode=HImode, x=0x7ea0fd2c, strict=20, 5, 2124479788, 0) at ../../gcc-4.8.2/gcc/config/vax/vax.c:1801 1801vax_legitimate_address_p (enum machine_mode mode, rtx x, bool strict) (gdb) n 1805 if (nonindexed_address_p (x, strict)) (gdb) print mode $4 = HImode (gdb) p debug_rtx(x) (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81]) (const_int 4 [0x4])) (symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS)) $5 = void (gdb) p strict $6 = false (gdb) n 1808 if (GET_CODE (x) != PLUS) (gdb) 1813 xfoo0 = XEXP (x, 0); (gdb) 1814 xfoo1 = XEXP (x, 1); (gdb) 1816 if (index_term_p (xfoo0, mode, strict) (gdb) 1826 if (indexable_address_p (xfoo0, xfoo1, mode, strict) (gdb) 1830 return false; with a backtrace: #0 vax_legitimate_address_p (mode=HImode, x=0x7ea0fd2c, strict=false, 5, 2124479788, 0) at ../../gcc-4.8.2/gcc/config/vax/vax.c:1830 #1 0x0052049a in default_addr_space_legitimate_address_p (mode=HImode, mem=0x7ea0fd2c, strict=false, as=0 '\000', 5, 2124479788, 0, 0) at ../../gcc-4.8.2/gcc/targhooks.c:1175 #2 0x004aa683 in memory_address_addr_space_p (mode=HImode, addr=0x7ea0fd2c, as=0 '\000', 5, 2124479788, 0) at ../../gcc-4.8.2/gcc/recog.c:1299 #3 0x00295454 in change_address_1 (memref=0x7ea2d560, mode=HImode, addr=0x7ea0fd2c, validate=1, 2124600672, 5, 2124479788, 1) at ../../gcc-4.8.2/gcc/emit-rtl.c:2019 and, as expected: (gdb) p debug_rtx(xfoo0) (mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81]) (const_int 4 [0x4])) $7 = void (gdb) p debug_rtx(xfoo1) (symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS) $8 = void
[Bug target/58901] vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
indexable_address_p() returns false for
(symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS)
because flag_pic is true and symbolic_operand (xfoo0, SImode)) returns true:
/* Return true if xfoo0 and xfoo1 constitute a valid indexed address. */
static bool
indexable_address_p (rtx xfoo0, rtx xfoo1, enum machine_mode mode, bool strict)
{
if (!CONSTANT_ADDRESS_P (xfoo0))
return false;
if (BASE_REGISTER_P (xfoo1, strict))
return !flag_pic || mode == QImode;
if (flag_pic symbolic_operand (xfoo0, SImode))
return false;
return reg_plus_index_p (xfoo1, mode, strict);
}
I don't know vax addressing modes - help!
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #10 from Martin Husemann martin at netbsd dot org --- Matt Thomas suggested to go with the easy solution for now: protect the calls with MEM_P, i.e.: change the ! mode_dependent_address_p() in the bitfield patterns to (MEM_P(..) ! mode_dependent_address_p(...)) With this change, a NetBSD kernel can be compiled (but does not yet boot), and bootstrap goes way further along (will file another ticket for the next obstacle).
[Bug target/58901] New: vax bootstrap fails on subreg reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901 Bug ID: 58901 Summary: vax bootstrap fails on subreg reload Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Trying a native bootstrap on VAX fails when compiling libdecnumber with a failed assertion here: #0 0x0085637c in fancy_abort (file=0x8dae4d ../../gcc-4.8.2/gcc/emit-rtl.c, line=2019, function=0x8db1e3 change_address_1(rtx_def*, machine_mode, rtx_def*, int)::__FUNCTION__ change_address_1, 9285197, 2019, 9286115) at ../../gcc-4.8.2/gcc/diagnostic.c:1146 #1 0x00295470 in change_address_1 (memref=0x7ea2d560, mode=HImode, addr=0x7ea0fd2c, validate=1, 2124600672, 5, 2124479788, 1) at ../../gcc-4.8.2/gcc/emit-rtl.c:2019 #2 0x00295f54 in adjust_address_1 (memref=0x7ea2d560, mode=HImode, offset=0, validate=1, adjust_address=1, adjust_object=0, size=2, 2124600672, 5, 0, 1, 1, 0, 2) at ../../gcc-4.8.2/gcc/emit-rtl.c:2151 #3 0x002d1a06 in alter_subreg (xp=0x7f0e8bc8, final_p=true, 2131659720, 1) at ../../gcc-4.8.2/gcc/final.c:3072 #4 0x002d2231 in cleanup_subreg_operands (insn=0x7f2d6360, 2133680992) at ../../gcc-4.8.2/gcc/final.c:3018 #5 0x004e5810 in reload (first=0x7ea58620, global=1, 2124776992, 1) at ../../gcc-4.8.2/gcc/reload1.c:1240 #6 0x003dc5e2 in do_reload () at ../../gcc-4.8.2/gcc/ira.c:4679 #7 0x003dc7aa in rest_of_handle_reload () at ../../gcc-4.8.2/gcc/ira.c:4779 #8 0x00483bf5 in execute_one_pass (pass=0xc6fda4 pass_reload, 13041060) at ../../gcc-4.8.2/gcc/passes.c:2333 (gdb) p debug_rtx(memref) (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:81 count ] [81]) (const_int 4 [0x4])) (symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS)) [3 DECPOWERS S4 A32]) The invocation was: /usr/pkgobj/lang/gcc48/work/build/./prev-gcc/cc1 -quiet -v -I ../../gcc-4.8.2/libdecnumber -I . -I /usr/pkg/include -I /usr/include -I ../../gcc-4.8.2/libdecnumber -I . -I /usr/pkg/include -I /usr/include -iprefix /usr/pkgobj/lang/gcc48/work/build/prev-gcc/../lib/gcc/vax--netbsdelf/4.8.2/ -isystem /usr/pkgobj/lang/gcc48/work/build/./prev-gcc/include -isystem /usr/pkgobj/lang/gcc48/work/build/./prev-gcc/include-fixed -isystem /usr/pkg/gcc48/vax--netbsdelf/include -isystem /usr/pkg/gcc48/vax--netbsdelf/sys-include ../../gcc-4.8.2/libdecnumber/decNumber.c -fPIC -quiet -dumpbase decNumber.c -auxbase decNumber -g -gtoggle -O2 -Wextra -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wsuggest-attribute=format -Wcast-qual -Wpedantic -Wno-long-long -version -o /var/tmp//ccfituj1.s
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #9 from Martin Husemann martin at netbsd dot org --- Please correct me if I am wrong, but in the bitfield cotexts in vax.md there are multiple places with similar constructs like: 219 (REG_P (operands[0]) 220|| ! mode_dependent_address_p (XEXP (operands[0], 0), 221MEM_ADDR_SPACE (operands[0]) If I read the code correctly, MEM_ADDR_SPACE() might only be called if MEM_P() is true. The expression at hand is a SUBREG, so neither REG_P() nor MEM_P() is true, and we end up invoking MEM_ADDR_SPACE() and should cause a call to rtl_check_failed_code1(), causing an internal error and abort. No clue why that fails (and how). I do not understand VAX good enough, but as THE cisc arch would expect the moves generated here to work for subregs as well - so maybe we need to check for REG_P() || SUBREG_P(), where SUBREG_P would be new (GET_CODE(X) == SUBRECT)?
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #7 from Martin Husemann martin at netbsd dot org --- I can reproduce the same crash on a different input file with a amd64 - vax cross compiler (so we can drop the theory that a miscompiled recog_1 function causes this).
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #8 from Martin Husemann martin at netbsd dot org --- And apparently same cause: ooops, bogus rtx mem attrs: 0x4 (subreg:SI (reg/v:DI 70 [ xtime ]) 4)
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #5 from Martin Husemann martin at netbsd dot org --- Just as a sanity check: I verified that the natively generated insn-recog.c is the same as one cross compiled on an amd64 host.
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #6 from Martin Husemann martin at netbsd dot org ---
To verify, I instrumented get_mem_attrs:
static inline struct mem_attrs *
get_mem_attrs (const_rtx x)
{
struct mem_attrs *attrs;
attrs = MEM_ATTRS (x);
attrs = MEM_ATTRS (x);
if (!attrs) {
attrs = mode_mem_attrs[(int) GET_MODE (x)];
if ((unsigned long)attrs 1024) {
fprintf(stderr, ooops, mode_mem_attrs are bogus: %p mode %d\n, attrs,
G$
debug_rtx(x);
}
} else if ((unsigned long)attrs 1024) {
fprintf(stderr, ooops, bogus rtx mem attrs: %p\n, attrs);
debug_rtx(x);
}
return attrs;
}
and indeed this fires:
ooops, bogus rtx mem attrs: 0x4
(subreg:SI (reg/v:DI 71 [ __s ]) 4)
In file included from
/usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/bits/locale_facets_nonio.h:1903:0,
from
/usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/locale:41,
from
../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/locale-inst.cc:29:
...
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Husemann martin at netbsd dot org --- fixed on trunk
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #4 from Martin Husemann martin at netbsd dot org --- I stared at the assembly a bit more (but my vax fu is weak): we are in the last line of 216 #line 781 ../../gcc-4.8.1/gcc/config/vax/vax.md 217 ((INTVAL (operands[1]) == 8 || INTVAL (operands[1]) == 16) 218 INTVAL (operands[2]) % INTVAL (operands[1]) == 0 219 (REG_P (operands[0]) 220|| ! mode_dependent_address_p (XEXP (operands[0], 0), 221MEM_ADDR_SPACE (operands[0]) and doing: 0x92cda2 recog_1(rtx, rtx, int*)+936: movl *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,r0 this is r0 = operands[0] MEM_ADDR_SPACE(RTX) is get_mem_attrs (RTX)-addrspace) so we do the call: 0x92cda9 recog_1(rtx, rtx, int*)+943: pushl r0 0x92cdab recog_1(rtx, rtx, int*)+945: calls $0x1,0x92c99e get_mem_attrs(const_rtx) and apparently get_mem_attrs(operand[0]) returned 4, which we then deref to -addrspace and crash.
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #3 from Martin Husemann martin at netbsd dot org --- 0x92c9fc recog_1(rtx, rtx, int*)+2:movab 0xff60(sp),sp 0x92ca01 recog_1(rtx, rtx, int*)+7: movab *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,0xffd8(fp) 0x92ca09 recog_1(rtx, rtx, int*)+15: movl 0x4(ap),r0 0x92ca0d recog_1(rtx, rtx, int*)+19: movl 0x4(r0),0xffdc(fp) 0x92ca12 recog_1(rtx, rtx, int*)+24: movw *0xffdc(fp),r0 0x92ca16 recog_1(rtx, rtx, int*)+28: movzwl r0,r0 0x92ca19 recog_1(rtx, rtx, int*)+31: movl r0,0xff64(fp) 0x92ca1e recog_1(rtx, rtx, int*)+36: cmpl 0xff64(fp),$0x2c 0x92ca23 recog_1(rtx, rtx, int*)+41: beql 0x92ca60 recog_1(rtx, rtx, int*)+102 0x92ca25 recog_1(rtx, rtx, int*)+43: cmpl 0xff64(fp),$0x007a 0x92ca2e recog_1(rtx, rtx, int*)+52: bneq 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92ca30 recog_1(rtx, rtx, int*)+54: brw 0x92cbe1 recog_1(rtx, rtx, int*)+487 0x92ca33 recog_1(rtx, rtx, int*)+57: pushl $0x6 0x92ca35 recog_1(rtx, rtx, int*)+59: pushl 0xffdc(fp) 0x92ca38 recog_1(rtx, rtx, int*)+62: calls $0x2,0x6715e8 nonimmediate_operand(rtx_def*, machine_mode) 0x92ca3f recog_1(rtx, rtx, int*)+69: clrb 0xff6b(fp) 0x92ca43 recog_1(rtx, rtx, int*)+73: tstl r0 0x92ca45 recog_1(rtx, rtx, int*)+75: beql 0x92ca4c recog_1(rtx, rtx, int*)+82 0x92ca47 recog_1(rtx, rtx, int*)+77: movb $0x1,0xff6b(fp) 0x92ca4c recog_1(rtx, rtx, int*)+82: tstb 0xff6b(fp) 0x92ca50 recog_1(rtx, rtx, int*)+86: bneq 0x92ca55 recog_1(rtx, rtx, int*)+91 0x92ca52 recog_1(rtx, rtx, int*)+88: brw 0x92df46 recog_1(rtx, rtx, int*)+5452 0x92ca55 recog_1(rtx, rtx, int*)+91: movl 0xffdc(fp),*0xef3cfc _GLOBAL_OFFSET_TABLE_+1548 0x92ca5d recog_1(rtx, rtx, int*)+99: brw 0x92cf4a recog_1(rtx, rtx, int*)+1360 0x92ca60 recog_1(rtx, rtx, int*)+102: pushl $0x6 0x92ca62 recog_1(rtx, rtx, int*)+104: pushl 0xffdc(fp) 0x92ca65 recog_1(rtx, rtx, int*)+107: calls $0x2,0x66d802 push_operand(rtx_def*, machine_mode) 0x92ca6c recog_1(rtx, rtx, int*)+114: clrb 0xff6c(fp) 0x92ca70 recog_1(rtx, rtx, int*)+118: tstl r0 0x92ca72 recog_1(rtx, rtx, int*)+120: beql 0x92ca79 recog_1(rtx, rtx, int*)+127 0x92ca74 recog_1(rtx, rtx, int*)+122: movb $0x1,0xff6c(fp) 0x92ca79 recog_1(rtx, rtx, int*)+127: tstb 0xff6c(fp) 0x92ca7d recog_1(rtx, rtx, int*)+131: beql 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92ca7f recog_1(rtx, rtx, int*)+133: movl 0xffdc(fp),*0xef3cfc _GLOBAL_OFFSET_TABLE_+1548 0x92ca87 recog_1(rtx, rtx, int*)+141: movl 0x4(ap),r0 0x92ca8b recog_1(rtx, rtx, int*)+145: movl 0x8(r0),0xffdc(fp) 0x92ca90 recog_1(rtx, rtx, int*)+150: movl 0xffdc(fp),r0 0x92ca94 recog_1(rtx, rtx, int*)+154: movb 0x2(r0),r0 0x92ca98 recog_1(rtx, rtx, int*)+158: movzbl r0,r0 0x92ca9b recog_1(rtx, rtx, int*)+161: cmpl r0,$0x6 0x92ca9e recog_1(rtx, rtx, int*)+164: bneq 0x92caac recog_1(rtx, rtx, int*)+178 0x92caa0 recog_1(rtx, rtx, int*)+166: movw *0xffdc(fp),r0 0x92caa4 recog_1(rtx, rtx, int*)+170: movzwl r0,r0 0x92caa7 recog_1(rtx, rtx, int*)+173: cmpl r0,$0x32 0x92caaa recog_1(rtx, rtx, int*)+176: beql 0x92cab8 recog_1(rtx, rtx, int*)+190 0x92caac recog_1(rtx, rtx, int*)+178: movl 0x4(ap),r0 0x92cab0 recog_1(rtx, rtx, int*)+182: movl 0x4(r0),0xffdc(fp) 0x92cab5 recog_1(rtx, rtx, int*)+187: brw 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92cab8 recog_1(rtx, rtx, int*)+190: movl 0xffdc(fp),r0 0x92cabc recog_1(rtx, rtx, int*)+194: movl 0x4(r0),0xffe0(fp) 0x92cac1 recog_1(rtx, rtx, int*)+199: pushl $0x6 0x92cac3 recog_1(rtx, rtx, int*)+201: pushl 0xffe0(fp) 0x92cac6 recog_1(rtx, rtx, int*)+204: calls $0x2,0x671620 register_operand(rtx_def*, machine_mode) 0x92cacd recog_1(rtx, rtx, int*)+211: clrb 0xff6d(fp) 0x92cad1 recog_1(rtx, rtx, int*)+215: tstl r0 0x92cad3 recog_1(rtx, rtx, int*)+217: beql 0x92cada recog_1(rtx, rtx, int*)+224 0x92cad5 recog_1(rtx, rtx, int*)+219: movb $0x1,0xff6d(fp) 0x92cada recog_1(rtx, rtx, int*)+224: tstb 0xff6d(fp) 0x92cade recog_1(rtx, rtx, int*)+228: beql 0x92caf0 recog_1(rtx, rtx, int*)+246 0x92cae0 recog_1(rtx, rtx, int*)+230: movab *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,r0 0x92cae7 recog_1(rtx, rtx, int*)+237: addl2 $0x4,r0 0x92caea recog_1(rtx, rtx, int*)+240: movl 0xffe0(fp),(r0) 0x92caee recog_1(rtx, rtx, int*)+244: brb 0x92cafc recog_1(rtx, rtx, int*)+258 0x92caf0 recog_1(rtx, rtx, int*)+246: movl 0x4
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #3 from Martin Husemann martin at netbsd dot org --- Of course I do not mind fixing gas, but the whole point of the D formatting code is to work around this assembler bug, and while this might be mostly irrelevant nowadays, isn't gcc supposed to work with other assemblers (like the VMS one) as well? Gas seems to be bug-compatible here. Overall, especially since this change is trivial, wouldn't it be best/easiest to apply it anyway?
[Bug target/58442] New: bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 Bug ID: 58442 Summary: bootstrapping vax crashes on NetBSD Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org During stage1 build of libstc++ this call dies with a segfault: Reading symbols from /usr/pkgobj/lang/gcc48/work/build/gcc/cc1plus...done. (gdb) run -quiet -nostdinc++ -v -I /usr/pkgobj/lang/gcc48/work/gcc-4.8.1/libstdc++-v3/../libgcc -I /usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/vax--netbsdelf -I /usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include -I /usr/pkgobj/lang/gcc48/work/gcc-4.8.1/libstdc++-v3/libsupc++ -I /usr/pkg/include -I /usr/include -iprefix /usr/pkgobj/lang/gcc48/work/build/gcc/../lib/gcc/vax--netbsdelf/4.8.1/ -isystem /usr/pkgobj/lang/gcc48/work/build/./gcc/include -isystem /usr/pkgobj/lang/gcc48/work/build/./gcc/include-fixed -D _GLIBCXX_SHARED -D PIC -D _GLIBCXX_SHARED -isystem /usr/pkg/gcc48/vax--netbsdelf/include -isystem /usr/pkg/gcc48/vax--netbsdelf/sys-include ../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/locale-inst.cc -quiet -dumpbase locale-inst.cc -auxbase-strip locale-inst.o -g -O2 -O1 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=locale-inst.lo -fgcse -fgcse-after-reload -fPIC -o /var/tmp//ccj04DGQ.s [..] GNU C++ (GCC) version 4.8.1 (vax--netbsdelf) compiled by GNU C version 4.1.3 20080704 prerelease (NetBSD nb3 2007), GMP version 5.0.1, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e5b251aee23ceb19ee70c90a0aeb9824 Program received signal SIGSEGV, Segmentation fault. 0x0092cdb0 in recog_1 (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:417 (gdb) bt #0 0x0092cdb0 in recog_1 (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:417 #1 0x0092f180 in recog_2 (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:529 #2 0x00932c1c in recog (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:1462 #3 0x0066f5e3 in recog_memoized (insn=0x7e1b26c0, 2115708608) at ../../gcc-4.8.1/gcc/recog.h:155 #4 0x0066f83c in extract_insn (insn=0x7e1b26c0, 2115708608) at ../../gcc-4.8.1/gcc/recog.c:2148 #5 0x005066d1 in instantiate_virtual_regs_in_insn ( insn=0x7e1b26c0, 2115708608) at ../../gcc-4.8.1/gcc/function.c:1561 #6 0x00507cd3 in instantiate_virtual_regs () at ../../gcc-4.8.1/gcc/function.c:1928 #7 0x00646f2f in execute_one_pass (pass=0xef6974, 15690100) at ../../gcc-4.8.1/gcc/passes.c:2330 #8 0x00647108 in execute_pass_list (pass=0xef6974, 15690100) at ../../gcc-4.8.1/gcc/passes.c:2378 #9 0x0064713d in execute_pass_list (pass=0xef7194, 15692180) at ../../gcc-4.8.1/gcc/passes.c:2379 (gdb) list 412 (match_operand:VAXint 2 general_operand nrmT,nrmT)))] 413 414 @ 415subVAXint:isfx2 %2,%0 416subVAXint:isfx3 %2,%1,%0) 417 418 (define_expand subdi3 419 [(set (match_operand:DI 0 nonimmediate_operand =g) 420 (minus:DI (match_operand:DI 1 general_operand g) 421 (match_operand:DI 2 general_operand g)))] (gdb) p debug_rtx(x0) (set (zero_extract:SI (subreg:SI (reg/v:DI 71 [ __s ]) 4) (const_int 8 [0x8]) (const_int 0 [0])) (subreg:SI (reg:DI 108) 4))
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #1 from Martin Husemann martin at netbsd dot org --- (gdb) x/i 0x0092cdb0 = 0x92cdb0 recog_1(rtx, rtx, int*)+950: movb 0x14(r0),r0 (gdb) info reg r0 0x4 4 r1 0x8 8 r2 0x0 0 r3 0xf0c308 15778568 r4 0x0 0 r5 0x0 0 r6 0x9e 158 r7 0x7f7d6c72 2138926194 r8 0x7f7ca000 2138873856 r9 0x7ff0 2147483632 r100x7f7d 2138898432 r110xa1b08 662280 ap 0x7fffe1c4 2147475908 fp 0x7fffe1b0 2147475888 sp 0x7fffe110 2147475728 pc 0x92cdb0 9620912 ps 0x3c062914560
[Bug target/58426] vax fails to compile gcov.c in stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Husemann martin at netbsd dot org --- As you seem to use 4.8.1, your GCC is older than my commit, so I think backporting this patch would probably cure your problem. Give it a try! Yes, I was using stock 4.8.1. And indeed this change seems to fix it. Thanks!
[Bug target/58426] New: vax fails to compile gcov.c in stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426 Bug ID: 58426 Summary: vax fails to compile gcov.c in stage1 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Compilation stops with: ../../../gcc-4.8.1/libgcc/libgcov.c:827:1: internal compiler error: output_operand: invalid expression as operand (will dig into it and provide more info)
[Bug target/58426] vax fails to compile gcov.c in stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
The error happens here:
#1 0x002d15ca in output_addr_const (file=0x7f5b79c8,
x=0x7f10a250, 2136701384, 2131796560) at ../../gcc-4.8.1/gcc/final.c:3877
#2 0x002d1466 in output_addr_const (file=0x7f5b79c8,
x=0x7ecb52a0, 2136701384, 2127254176) at ../../gcc-4.8.1/gcc/final.c:3837
#3 0x00762eb4 in print_operand (file=0x7f5b79c8, x=0x7ecb52a0,
code=0, 2136701384, 2127254176, 0)
at ../../gcc-4.8.1/gcc/config/vax/vax.c:557
#4 0x00520a05 in default_print_operand (stream=0x7f5b79c8, x=0x7ecb52a0,
code=0, 2136701384, 2127254176, 0) at ../../gcc-4.8.1/gcc/targhooks.c:327
#5 0x002d1a04 in output_operand (x=0x7ecb52a0, code=0, 2127254176, 0)
at ../../gcc-4.8.1/gcc/final.c:3735
#6 0x002d1dcb in output_asm_insn (templ=0x9245a0 addl3 %1,%2,%0,
operands=0xc7fee0, 9586080, 13106912) at ../../gcc-4.8.1/gcc/final.c:3633
#7 0x002d45b1 in final_scan_insn (insn=0x7ec4ce58, file=0x7f5b79c8,
optimize_p=1, nopeepholes=0,
seen=0x7fffe438, 2126827096, 2136701384, 1, 0, 2147476536)
at ../../gcc-4.8.1/gcc/final.c:2931
#8 0x002d4a08 in final (first=0x7ec2d9c0, file=0x7f5b79c8,
optimize_p=1, 2126698944, 2136701384, 1)
at ../../gcc-4.8.1/gcc/final.c:1967
and the expression passed by vax.c to output_addr_const() is:
$3 = {code = PLUS, mode = SImode, jump = 0, call = 0, unchanging = 0,
volatil = 0, in_struct = 0, used = 0, frame_related = 0, return_val = 0,
u = {fld = {{rt_int = 2131796560, rt_uint = 2131796560,
rt_str = 0x7f10a250 , rt_rtx = 0x7f10a250, rt_rtvec = 0x7f10a250,
rt_type = 2131796560, rt_addr_diff_vec_flags = {min_align = 80,
base_after_vec = 0, min_after_vec = 1, max_after_vec = 0,
min_after_base = 0, max_after_base = 0, offset_unsigned = 1,
scale = 16}, rt_cselib = 0x7f10a250, rt_tree = 0x7f10a250,
rt_bb = 0x7f10a250, rt_mem = 0x7f10a250, rt_reg = 0x7f10a250,
rt_constant = 0x7f10a250, rt_cfi = 0x7f10a250}}, hwint = {2131796560},
block_sym = {fld = {{rt_int = 2131796560, rt_uint = 2131796560,
rt_str = 0x7f10a250 , rt_rtx = 0x7f10a250, rt_rtvec = 0x7f10a250,
rt_type = 2131796560, rt_addr_diff_vec_flags = {min_align = 80,
base_after_vec = 0, min_after_vec = 1, max_after_vec = 0,
min_after_base = 0, max_after_base = 0, offset_unsigned = 1,
scale = 16}, rt_cselib = 0x7f10a250, rt_tree = 0x7f10a250,
rt_bb = 0x7f10a250, rt_mem = 0x7f10a250, rt_reg = 0x7f10a250,
rt_constant = 0x7f10a250, rt_cfi = 0x7f10a250}, {
rt_int = 2126996200, rt_uint = 2126996200,
rt_str = 0x7ec762e8 \037, rt_rtx = 0x7ec762e8,
rt_rtvec = 0x7ec762e8, rt_type = 2126996200,
rt_addr_diff_vec_flags = {min_align = 232, base_after_vec = 0,
min_after_vec = 1, max_after_vec = 0, min_after_base = 0,
max_after_base = 0, offset_unsigned = 1, scale = 199},
rt_cselib = 0x7ec762e8, rt_tree = 0x7ec762e8, rt_bb = 0x7ec762e8,
rt_mem = 0x7ec762e8, rt_reg = 0x7ec762e8, rt_constant = 0x7ec762e8,
rt_cfi = 0x7ec762e8}, {rt_int = 393266, rt_uint = 393266,
rt_str = 0x60032 ded_initEjj, rt_rtx = 0x60032,
rt_rtvec = 0x60032, rt_type = 393266, rt_addr_diff_vec_flags = {
min_align = 50, base_after_vec = 0, min_after_vec = 0,
max_after_vec = 0, min_after_base = 0, max_after_base = 0,
offset_unsigned = 0, scale = 6}, rt_cselib = 0x60032,
rt_tree = 0x60032, rt_bb = 0x60032, rt_mem = 0x60032,
rt_reg = 0x60032, rt_constant = 0x60032, rt_cfi = 0x60032}},
block = 0x7f10a250, offset = 2126996200}, rv = {cl = 0, decimal = 0,
sign = 0, signalling = 1, canonical = 0, uexp = 33309321, sig = {
2126996200, 393266, 2131796560, 2126996200, 23}}, fv = {data = {
low = 2131796560, high = 2126996200}, mode = 393266}}}
[Bug target/58426] vax fails to compile gcov.c in stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
The more interesting XEXP(x, 0) of that rtx is the one triggering the failure:
$15 = {code = REG, mode = SImode, jump = 0, call = 0, unchanging = 0,
volatil = 0, in_struct = 0, used = 0, frame_related = 1, return_val = 0,
u = {fld = {{rt_int = 13, rt_uint = 13,
rt_str = 0xd Address 0xd out of bounds, rt_rtx = 0xd,
rt_rtvec = 0xd, rt_type = TQmode, rt_addr_diff_vec_flags = {
min_align = 13, base_after_vec = 0, min_after_vec = 0,
max_after_vec = 0, min_after_base = 0, max_after_base = 0,
offset_unsigned = 0, scale = 0}, rt_cselib = 0xd, rt_tree = 0xd,
rt_bb = 0xd, rt_mem = 0xd, rt_reg = 0xd, rt_constant = 0xd,
rt_cfi = 0xd}}, hwint = {13}, block_sym = {fld = {{rt_int = 13,
rt_uint = 13, rt_str = 0xd Address 0xd out of bounds,
rt_rtx = 0xd, rt_rtvec = 0xd, rt_type = TQmode,
rt_addr_diff_vec_flags = {min_align = 13, base_after_vec = 0,
min_after_vec = 0, max_after_vec = 0, min_after_base = 0,
max_after_base = 0, offset_unsigned = 0, scale = 0},
rt_cselib = 0xd, rt_tree = 0xd, rt_bb = 0xd, rt_mem = 0xd,
rt_reg = 0xd, rt_constant = 0xd, rt_cfi = 0xd}, {rt_int = 13,
rt_uint = 13, rt_str = 0xd Address 0xd out of bounds,
rt_rtx = 0xd, rt_rtvec = 0xd, rt_type = TQmode,
rt_addr_diff_vec_flags = {min_align = 13, base_after_vec = 0,
min_after_vec = 0, max_after_vec = 0, min_after_base = 0,
max_after_base = 0, offset_unsigned = 0, scale = 0},
rt_cselib = 0xd, rt_tree = 0xd, rt_bb = 0xd, rt_mem = 0xd,
rt_reg = 0xd, rt_constant = 0xd, rt_cfi = 0xd}, {rt_int = 0,
rt_uint = 0, rt_str = 0x0, rt_rtx = 0x0, rt_rtvec = 0x0,
rt_type = VOIDmode, rt_addr_diff_vec_flags = {min_align = 0,
base_after_vec = 0, min_after_vec = 0, max_after_vec = 0,
min_after_base = 0, max_after_base = 0, offset_unsigned = 0,
scale = 0}, rt_cselib = 0x0, rt_tree = 0x0, rt_bb = 0x0,
rt_mem = 0x0, rt_reg = 0x0, rt_constant = 0x0, rt_cfi = 0x0}},
block = 0x40060026, offset = 12}, rv = {cl = 1, decimal = 1, sign = 1,
signalling = 0, canonical = 0, uexp = 0, sig = {13, 0, 1074135078, 12,
12}}, fv = {data = {low = 13, high = 13}, mode = VOIDmode}}}
[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 --- Comment #1 from Martin Husemann martin at netbsd dot org --- Created attachment 30803 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30803action=edit host hooks for NetBSD
[Bug preprocessor/58397] New: Please add host_hooks for NetBSD to make precompiled headers work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 Bug ID: 58397 Summary: Please add host_hooks for NetBSD to make precompiled headers work Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Created attachment 30802 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30802action=edit build glue changes As discussed in #58370 and #58379, precompiled headers do not work on NetBSD hosts. To fix this, a new gcc/config/host-netbsd.c file and the needed build glue is attached. This is mostly a copy of the openbsd stuff with a few minor changes (like adding MAP_FIXED, which is needed on NetBSD) and adding a different address for sparc64 machines.
[Bug preprocessor/58370] pre compiled headers failure on NetBSD/sparc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370 --- Comment #4 from Martin Husemann martin at netbsd dot org --- To avoid confusion, I'm splitting this into two separate reports - will dig further into the crash myself, since it is probably not easy to reproduce on other host platforms.
[Bug preprocessor/58379] New: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379 Bug ID: 58379 Summary: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org I may be misunderstanding the interface - but it looks to me like it lets the kernel chose an arbitrary mapping address for different compiler invocations but relies on the assumption that the returned address will be the same. If not, the compiler fails with a fatal_error when trying to read a precompiled header file (had to relocate PCH). I can not imagine a host system where this would work reliably (or even typically twice in a row). Please tell me I misunderstood, or consider disabling PCH support for host platforms without host_hooks overriding this function.
[Bug preprocessor/58381] New: crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
Bug ID: 58381
Summary: crash in diagnostic_report_current_module when a
fatal_error happens during PCH processing on
NetBSD/spa64rc
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
In toplev_main variable line_table is initialized and becomes 0x417dc000,
however, when invoking diagnostic_report_current_module with this backtrace it
is different:
#0 diagnostic_report_current_module (context=0x17b28d0, where=19) at
../../gcc-4.8.1/gcc/diagnostic.c:468
#1 0x003a6368 in cp_diagnostic_starter (context=0x17b28d0,
diagnostic=0xa3e8)
at ../../gcc-4.8.1/gcc/cp/error.c:2907
#2 0x012d5e44 in diagnostic_report_diagnostic (context=0x17b28d0,
diagnostic=0xa3e8)
at ../../gcc-4.8.1/gcc/diagnostic.c:756
#3 0x012d6b90 in fatal_error (gmsgid=0x13e1230 had to relocate PCH)
at ../../gcc-4.8.1/gcc/diagnostic.c:1076
#4 0x008e83dc in gt_pch_restore (f=0x424a0738) at
../../gcc-4.8.1/gcc/ggc-common.c:704
#5 0x005c575c in c_common_read_pch (pfile=0x42765800, name=0x4275dbc0
conftest.h.gch, fd=4,
orig_name=0x4275dbb0 conftest.h) at
../../gcc-4.8.1/gcc/c-family/c-pch.c:370
#6 0x012f05f8 in should_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
at ../../gcc-4.8.1/libcpp/files.c:787
#7 0x012f097c in _cpp_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
at ../../gcc-4.8.1/libcpp/files.c:872
#8 0x012f0fe4 in _cpp_stack_include (pfile=0x42765800,
fname=0x4275db90 conftest.h, angle_brackets=0,
type=IT_INCLUDE) at ../../gcc-4.8.1/libcpp/files.c:1008
#9 0x012e1fc4 in do_include_common (pfile=0x42765800, type=IT_INCLUDE)
at ../../gcc-4.8.1/libcpp/directives.c:793
#10 0x012e2024 in do_include (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/directives.c:804
#11 0x012e13dc in _cpp_handle_directive (pfile=0x42765800, indented=0)
at ../../gcc-4.8.1/libcpp/directives.c:492
#12 0x012f9dc4 in _cpp_lex_token (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/lex.c:1990
#13 0x01306cec in cpp_get_token_1 (pfile=0x42765800,
location=0xb0b8)
at ../../gcc-4.8.1/libcpp/macro.c:2355
#14 0x01307330 in cpp_get_token_with_location (pfile=0x42765800,
loc=0xb0b8)
at ../../gcc-4.8.1/libcpp/macro.c:2537
#15 0x005b9484 in c_lex_with_flags (value=0xb0c0,
loc=0xb0b8,
cpp_flags=0xb0b2 , lex_flags=0) at
../../gcc-4.8.1/gcc/c-family/c-lex.c:300
#16 0x003b225c in cp_lexer_get_preprocessor_token (lexer=0x0,
token=0xb0b0)
at ../../gcc-4.8.1/gcc/cp/parser.c:715
#17 0x003f64e8 in cp_parser_initial_pragma
(first_token=0xb0b0)
at ../../gcc-4.8.1/gcc/cp/parser.c:28139
#18 0x003b1d98 in cp_lexer_new_main () at
../../gcc-4.8.1/gcc/cp/parser.c:585
#19 0x003b6604 in cp_parser_new () at
../../gcc-4.8.1/gcc/cp/parser.c:3253
#20 0x003f6b78 in c_parse_file () at
../../gcc-4.8.1/gcc/cp/parser.c:28335
#21 0x005c30a0 in c_common_parse_file () at
../../gcc-4.8.1/gcc/c-family/c-opts.c:1046
#22 0x00c5f230 in compile_file () at ../../gcc-4.8.1/gcc/toplev.c:543
#23 0x00c62540 in do_compile () at ../../gcc-4.8.1/gcc/toplev.c:1864
#24 0x00c62788 in toplev_main (argc=24, argv=0xb718) at
../../gcc-4.8.1/gcc/toplev.c:1940
#25 0x012bc2c0 in main (argc=24, argv=0xb718) at
../../gcc-4.8.1/gcc/main.c:36
(gdb) print line_table
$6 = (line_maps *) 0x42e7
(gdb) print *line_table
$16 = {info_ordinary = {maps = 0x11400, allocated = 1, used = 1115871712,
cache = 0}, info_macro = {
maps = 0x10500, allocated = 0, used = 1117049688, cache = 0}, depth =
1, trace_includes = 55,
highest_location = 3, highest_line = 1117048808, max_column_hint = 0,
reallocator = 0x11500,
round_alloc_size = 0, location_adhoc_data_map = {htab = 0x0, curr_loc = 1,
allocated = 335544320, data = 0x24282d9e0}}
The used fields look strange. Later in the same call it crashes:
Program received signal SIGSEGV, Segmentation fault.
0x012fff88 in linemap_location_from_macro_expansion_p (set=0x42e7,
location=19)
at ../../gcc-4.8.1/libcpp/line-map.c:948
948 linemap_assert (location = MAX_SOURCE_LOCATION
(gdb) bt
#0 0x012fff88 in linemap_location_from_macro_expansion_p
(set=0x42e7, location=19)
at ../../gcc-4.8.1/libcpp/line-map.c:948
#1 0x012ff31c in linemap_lookup (set=0x42e7, line=19) at
../../gcc-4.8.1/libcpp/line-map.c:642
#2 0x0130065c in linemap_macro_loc_to_def_point (set=0x42e7,
location=19, original_map
[Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379 --- Comment #2 from Martin Husemann martin at netbsd dot org --- (In reply to Richard Biener from comment #1) If you have a system that randomizes then you have to re-define the hook. Besides ASLR there are various things out of control of the compiler that do result in varying mapping adresses (like malloc using mmap instead of brk), so chances are low in any modern system. I'm not opposed to create a hook for NetBSD, but I have a hard time seeing a possible sensible implementation. Look at the #ifdef cascade in config/host-openbsd.c for a disgusting example of code that should not be in a compiler (IMHO). How hard is making the externalized format address neutral?
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 --- Comment #2 from Martin Husemann martin at netbsd dot org --- Created attachment 30790 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30790action=edit Restore line_table and input_location before calling fatal_error when failing a pch load With this patch, the fatal_error is properly reported: $BUILDDIR/stage1-gcc/xg++ -B $BUILDDIR/stage1-gcc -Werror -Winvalid-pch -Wno-deprecated -c conftest.cc conftest.cc:1:0: fatal error: had to relocate PCH #include conftest.h ^ compilation terminated.
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 --- Comment #1 from Martin Husemann martin at netbsd dot org --- The global pointer line_table is changed to the contents of the precompiled header file in gt_pch_restore in this loop: /* Read in all the global pointers, in 6 easy loops. */ for (rt = gt_ggc_rtab; *rt; rt++) for (rti = *rt; rti-base != NULL; rti++) for (i = 0; i rti-nelt; i++) if (fread ((char *)rti-base + rti-stride * i, sizeof (void *), 1, f) != 1) fatal_error (can%'t read PCH file: %m); but not reset to the previous values when the compiler decides to not use the pch contents (for example because the address of the mmap differs). We probably need to save at least line_table (and maybe input_location) at the start of this function and restore it before invoking fatal_error.
[Bug preprocessor/58370] New: pre compiled headers failure on NetBSD/sparc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370
Bug ID: 58370
Summary: pre compiled headers failure on NetBSD/sparc64
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Trying to configure gcc fails with an endless loop in one of the configure
tests of libstc++. There are actually two errors in this:
(1) a fatal error when reading a PCH file had to relocate PCH
(2) a SIGSEGV when trying to resolve symbol information for the diagnostic
message, which in turn leads to a SIGSEGV inside the SIGSEGV handler
I don't know if (2) is only fallout from (1). I can provide more debug output
if needed (not sure what part of this is NetBSD specific).
The backtrace is:
#0 0x012fff88 in linemap_location_from_macro_expansion_p (
set=0x42e7, location=19) at ../../gcc-4.8.1/libcpp/line-map.c:948
#1 0x012ff31c in linemap_lookup (set=0x42e7, line=19)
at ../../gcc-4.8.1/libcpp/line-map.c:642
#2 0x0130065c in linemap_macro_loc_to_def_point (set=0x42e7,
location=19, original_map=0xa0c8)
at ../../gcc-4.8.1/libcpp/line-map.c:1134
#3 0x01300934 in linemap_resolve_location (set=0x42e7, loc=19,
lrk=LRK_MACRO_DEFINITION_LOCATION, map=0xa0c8)
at ../../gcc-4.8.1/libcpp/line-map.c:1263
#4 0x012d4ab8 in diagnostic_report_current_module (context=0x17b28d0,
where=19) at ../../gcc-4.8.1/gcc/diagnostic.c:481
#5 0x003a6368 in cp_diagnostic_starter (context=0x17b28d0,
diagnostic=0xa308) at ../../gcc-4.8.1/gcc/cp/error.c:2907
#6 0x012d5e44 in diagnostic_report_diagnostic (context=0x17b28d0,
diagnostic=0xa308) at ../../gcc-4.8.1/gcc/diagnostic.c:756
#7 0x012d6b90 in fatal_error (gmsgid=0x13e1230 had to relocate PCH)
at ../../gcc-4.8.1/gcc/diagnostic.c:1076
#8 0x008e83dc in gt_pch_restore (f=0x424a0738)
at ../../gcc-4.8.1/gcc/ggc-common.c:704
#9 0x005c575c in c_common_read_pch (pfile=0x42765800,
name=0x4275dbc0 conftest.h.gch, fd=4, orig_name=0x4275dbb0 conftest.h)
at ../../gcc-4.8.1/gcc/c-family/c-pch.c:370
#10 0x012f05f8 in should_stack_file (pfile=0x42765800,
file=0x42788130, import=false) at ../../gcc-4.8.1/libcpp/files.c:787
#11 0x012f097c in _cpp_stack_file (pfile=0x42765800, file=0x42788130,
import=false) at ../../gcc-4.8.1/libcpp/files.c:872
#12 0x012f0fe4 in _cpp_stack_include (pfile=0x42765800,
fname=0x4275db90 conftest.h, angle_brackets=0, type=IT_INCLUDE)
at ../../gcc-4.8.1/libcpp/files.c:1008
#13 0x012e1fc4 in do_include_common (pfile=0x42765800, type=IT_INCLUDE)
at ../../gcc-4.8.1/libcpp/directives.c:793
#14 0x012e2024 in do_include (pfile=0x42765800)
at ../../gcc-4.8.1/libcpp/directives.c:804
#15 0x012e13dc in _cpp_handle_directive (pfile=0x42765800, indented=0)
at ../../gcc-4.8.1/libcpp/directives.c:492
#16 0x012f9dc4 in _cpp_lex_token (pfile=0x42765800)
at ../../gcc-4.8.1/libcpp/lex.c:1990
#17 0x01306cec in cpp_get_token_1 (pfile=0x42765800,
location=0xafd8) at ../../gcc-4.8.1/libcpp/macro.c:2355
#18 0x01307330 in cpp_get_token_with_location (pfile=0x42765800,
loc=0xafd8) at ../../gcc-4.8.1/libcpp/macro.c:2537
#19 0x005b9484 in c_lex_with_flags (value=0xafe0,
loc=0xafd8, cpp_flags=0xafd2 , lex_flags=0)
at ../../gcc-4.8.1/gcc/c-family/c-lex.c:300
#20 0x003b225c in cp_lexer_get_preprocessor_token (lexer=0x0,
token=0xafd0) at ../../gcc-4.8.1/gcc/cp/parser.c:715
#21 0x003f64e8 in cp_parser_initial_pragma (
first_token=0xafd0) at ../../gcc-4.8.1/gcc/cp/parser.c:28139
#22 0x003b1d98 in cp_lexer_new_main ()
This can be reproduced like this:
cat conftest.h
#include math.h
cat conftest.cc
#include conftest.h
$BUILDDIR/stage1-gcc/xg++ -B $BUILDDIR/stage1-gcc -Werror -Winvalid-pch
-Wno-deprecated -x c++-header conftest.h -o conftest.h.gch
$BUILDDIR/stage1-gcc/xg++ -B $BUILDDIR/stage1-gcc -Werror -Winvalid-pch
-Wno-deprecated -c conftest.cc
A bit of gdb output:
Core was generated by `cc1plus'.
Program terminated with signal 11, Segmentation fault.
#0 0x012fff88 in linemap_location_from_macro_expansion_p (
set=0x42e7, location=19) at ../../gcc-4.8.1/libcpp/line-map.c:948
948 linemap_assert (location = MAX_SOURCE_LOCATION
(gdb) list
943 {
944 if (IS_ADHOC_LOC (location))
945 location = set-location_adhoc_data_map.data[
946 location MAX_SOURCE_LOCATION].locus;
947
948 linemap_assert (location = MAX_SOURCE_LOCATION
949(set-highest_location
950
[Bug preprocessor/58370] pre compiled headers failure on NetBSD/sparc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370 --- Comment #1 from Martin Husemann martin at netbsd dot org --- The fatal error seems to happen because NetBSD uses the default HAVE_MMAP_FILE implementation of gt_pch_get_address and gt_pch_use_address instead of specific host hooks. Looking at the existing host hook implementations for those two functions I am really terrified. Why is relocation not possible?
[Bug preprocessor/58370] pre compiled headers failure on NetBSD/sparc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370 --- Comment #3 from Martin Husemann martin at netbsd dot org --- (In reply to Richard Biener from comment #2) Probably because nobody submitted and tested a NetBSD implementation. You mean an evil hack to try to avoid the relocation (like all existing host hooks seem to do)? Relocation of precompiled header information should not be host specific. With it, any posix mmap (via the default implementation) would do.
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 --- Comment #4 from Martin Husemann martin at netbsd dot org --- (In reply to Eric Botcazou from comment #3) So what? What happens if conftest.cc doesn't fiddle with visibility at all? Sorry, I am not quite sure I understand what you are up to. Same thing happens, so this is not bug 26905 but a more generic issue and we could simplify the test case? Or are you trying to argue whether we should see a PLT call at all? Martin
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 --- Comment #6 from Martin Husemann martin at netbsd dot org --- Ooops, my lack of x86 ABI knowledge strikes again. Indeed, visibility is properly expressed in the prologue, all is fine.
[Bug target/58278] New: visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 Bug ID: 58278 Summary: visibility bug from #26905 still happens with the sparc64 backend Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Created attachment 30729 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30729action=edit test for bug 26905 Compiling the test from #26905 with -fPIC -shared -S... on sparc64 creates this output: --8-- .file conftest.cc .section.text .align 4 .global _Z8TestFuncv .type _Z8TestFuncv, #function .proc 020 _Z8TestFuncv: .LLFB0: .cfi_startproc save%sp, -176, %sp .cfi_window_save .cfi_register 15, 31 .cfi_def_cfa_register 30 call_ZN10TestStruct4InitEv, 0 nop return %i7+8 nop .cfi_endproc .LLFE0: .size _Z8TestFuncv, .-_Z8TestFuncv .ident GCC: (GNU) 4.8.1 --8-- note the missing PLT call.
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 --- Comment #2 from Martin Husemann martin at netbsd dot org --- Compare with this on amd64: c++ -o plain.s -S conftest.cc c++ -o shared.s -fPIC -shared -S conftest.cc diff -u plain.s shared.s --- plain.s 2013-08-30 21:46:18.0 +0200 +++ shared.s2013-08-30 21:46:25.0 +0200 @@ -10,7 +10,7 @@ movq%rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 - call_ZN10TestStruct4InitEv + call_ZN10TestStruct4InitEv@PLT popq%rbp .cfi_def_cfa 7, 8 ret while on sparc (and sparc64) there is no difference. See bug 26905 for details.
[Bug target/56875] New: vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
Bug #: 56875
Summary: vax target miscompiles short negative constants for
64bit values
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@netbsd.org
Created attachment 29823
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29823
Use the D format specifie for ashqs second arg
The documentation for VAX operand formatting codes says:
D64-bit immediate operand
and:
/* The purpose of D is to get around a quirk or bug in vax assembler
whereby -1 in a 64-bit immediate operand means 0x,
which is not a 64-bit minus one. */
However, the ashq instruction patters do not use this properly.
This small test program triggers it:
#include stdio.h
#include inttypes.h
int main(int argc, char **argv)
{
size_t i;
uint64_t v, nv;
for (i = 0; i 16; i++) {
v = ~(uint64_t)0 i;
nv = ~v;
printf(%zu: mask %08llx not %08llx\n, i, v, nv);
}
return 0;
}
The relevant line from assembly:
ashq %r6,$-1,%r2
which is misinterpreted by the assembler, so dissasembly is:
10637: 79 56 8f ff ashq r6,$0x,r2
1063b: ff ff ff 00
1063f: 00 00 00 52
The attached patch fixes it.
[Bug target/54226] New: Executables compiled with -pie do not work on NetBSD/sparc or sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54226
Bug #: 54226
Summary: Executables compiled with -pie do not work on
NetBSD/sparc or sparc
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@netbsd.org
Due to a missing -fPIC when compiling libgcc crtstuff, the binaries are not
actually position independent.
On NetBSD, a hello world compiled with gcc -fpie -pie hello.c links to a
binary like this:
a.out: file format elf64-sparc
Program Header:
PHDR off0x0040 vaddr 0x0040 paddr
0x0040 align 2**3
filesz 0x0150 memsz 0x0150 flags r-x
INTERP off0x0190 vaddr 0x0190 paddr
0x0190 align 2**0
filesz 0x0017 memsz 0x0017 flags r--
LOAD off0x vaddr 0x paddr
0x align 2**20
filesz 0x0b34 memsz 0x0b34 flags r-x
...
but of course the first section is not mapped at 0.
Fix is simple: set TARGET_LIBGCC2_CFLAGS in libgcc/config.host (via a new
additional ${tmake_file}) to -fPIC.
I can provide a simple patch doing that, however, I fail to see why this would
be a NetBSD speciality, i.e. why it works without that flags on other systems -
or maybe it just does not work there as well and we need a broader fix (same
solution, different match in config.host).
[Bug target/54226] Executables compiled with -pie do not work on NetBSD/sparc or sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54226 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #2 from Martin Husemann martin at netbsd dot org 2012-08-11 10:39:35 UTC --- I see - that is fine, and sorry I did not check newer branches before.
[Bug rtl-optimization/48830] [4.6 regression] unrecognized insn: storing invalid upper FP reg in SImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
CC||martin at netbsd dot org
--- Comment #18 from Martin Husemann martin at netbsd dot org 2012-07-19
13:56:11 UTC ---
I see something similar with gcc 4.5.3 when compiling mrtg:
./src/rateup.c:1136:1: error: insn does not satisfy its constraints:
(insn 11219 11218 3096 307 ./src/rateup.c:913 (set (mem/c:SI (reg:DI 2 %g2) [23
%sfp+-10660 S4 A32])
(reg:SI 65 %f33 [+4 ])) 50 {*movsi_insn} (nil))
./src/rateup.c:1136:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396
(this has originally been reported as http://gnats.netbsd.org/46719)
Is this the samme issue? Any chance of a fix for the 4.5 branch?
[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219 --- Comment #7 from Martin Husemann martin at netbsd dot org 2012-05-06 10:59:19 UTC --- Created attachment 27324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27324 gcc -S output for the miscompiled function The original report showed the disassembler output from gdb; here is the original compiler output (stripped to the function in question, I can provide the full output if needed). The crash happens in the section starting at line 521: .LLBB1732: .loc 1 4563 0 ldx [%i0+624], %g1 add %fp, 1695, %o0 mov 0, %o1 call__sigsetjmp14, 0 stx%g1, [%fp+1687] .LLVL2000: add %fp, 1687, %g1 st %o0, [%fp+1815] .LLBE1732: .loc 1 4567 0 andcc %o0, 0xff, %o1 .LLBB1733: .loc 1 4563 0 stx %g1, [%i0+624] on return from the sigsetjmp %i0 is zero and we crash in the last line cited above. I think the register %i0 is left as zero after (post first call to sigsetjmp) when going throught he code starting at line 77: .LLVL1968: .LL2453: .LLBB1694: .LLBB1695: .loc 3 77 0 ldx [%fp+2191], %i0 .LLVL1969: .LL2734: and %i0, 224, %g1 srl %g1, 5, %g1 .LLVL1970: .LLBE1695: .LLBE1694: .loc 1 4617 0 cmp %g1, 1 This register value later gets saved to the on-stack copy of the register window, from where it is restored on siglongjmp.
[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219 --- Comment #2 from Martin Husemann martin at netbsd dot org 2012-05-04 07:56:48 UTC --- I double checked: the sigsetjmp/siglonjmp function prototypes are properly marked as returns_twice and noreturn, so I claim this to be abug in gcc ;-)
[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219 --- Comment #4 from Martin Husemann martin at netbsd dot org 2012-05-04 13:27:37 UTC --- Created attachment 27307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27307 intermediate file when compiling regcomp.c
[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219 --- Comment #5 from Martin Husemann martin at netbsd dot org 2012-05-04 13:29:45 UTC --- Using built-in specs. COLLECT_GCC=cc Target: sparc64--netbsd Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure --target=sparc64--netbsd --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb2 20111202' --enable-__cxa_atexit --with-mpc=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr --with-mpfr=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr --with-gmp=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd6.0 --host=sparc64--netbsd Thread model: posix gcc version 4.5.3 (NetBSD nb2 20110806) NetBSD thirdstage.duskware.de 6.99.6 NetBSD 6.99.6 (MODULAR) #37: Thu May 3 10:33:30 CEST 2012 mar...@night-porter.duskware.de:/usr/src/sys/arch/sparc64/compile/MODULAR sparc64 Command line used: gcc -DPERL_CORE -c -O2 -pipe -pthread -g -O2 -I/usr/include -fno-strict-aliasing -fstack-protector -I/usr/pkg/include -std=c89 -O2 -pipe -pthread -g -O2 -I/usr/include -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings I will try to create a smaller test case to reproduce it, but is not easy.
[Bug target/53219] New: inline function erroneously clobbers %i0 register on 64 bit sparc comiple of perls regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
Bug #: 53219
Summary: inline function erroneously clobbers %i0 register on
64 bit sparc comiple of perls regcomp.c
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@netbsd.org
gcc 4.5.3 on NetBSD/sparc64 miscompiles perl's regcomp.c file.
Inside the big Perl_re_compile() function with %i0 being my_perl, the context
for the whole function, it inlines this tiny function:
72 PERL_STATIC_INLINE regex_charset
73 get_regex_charset(const U32 flags)
74 {
75 /* Returns the enum corresponding to the character set in 'flags'
*/
76
77 return (regex_charset) ((flags RXf_PMf_CHARSET)
_RXf_PMf_CHARSET_SHIFT);
78 }
This is the generated assembler code:
0x4058f560 Perl_re_compile+128:
brnz %g1, 0x4058f570 Perl_re_compile+144
0x4058f564 Perl_re_compile+132:add %l3, %g1, %l5
0x4058f568 Perl_re_compile+136:clr [ %fp + 0x66b ]
0x4058f56c Perl_re_compile+140:clr [ %fp + 0x88f ], %i0
0x4058f574 Perl_re_compile+148:and %i0, 0xe0, %g1
0x4058f578 Perl_re_compile+152:srl %g1, 5, %g1
0x4058f57c Perl_re_compile+156:cmp %g1, 1
0x4058f580 Perl_re_compile+160:
be,pn %icc, 0x40590ecc Perl_re_compile+6636
Note at the == marker, %i0 is reloaded without save before nor any restore
later. This causes a crash shortly later.
Simple test:
perl -e '/(?{{})/'
[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219 --- Comment #1 from Martin Husemann martin at netbsd dot org 2012-05-03 21:34:13 UTC --- It occured to me that gcc would (rightfully) behave this way, if the (previous) value in %i0 should be considered dead at this point - which might be the case, hard to tell due to lots of macro magic [is there some way to easily check this?]. However, in this function there is a sigsetjmp() call, and in the test case we return to it. The standard says that non volatile automatic variables which values changed after the setjmp() call may have the later value on return from the longjmp - and this probably extrapolates to this type of register usage. Since %i0 is not callee saved in sparc64, its value is restored on longjmp from the register window shadow copy on the stack, where it has the later value (0 in the exammple). So, how could I check this hypothesis? Is there some attribute magic we could use to hint gcc to keep all values alive at the setjmp call alive untill the end of the function?
[Bug c/18473] New: unrecognizable insn compiling various sources
(This is filed as PR toolchain/28065 in the NetBSD gnats database) When crosscompiling a NetBSD/hppa kernel on a NetBSD/sparc64 host, the compiler fails in various files. On example of the error message is: /usr/src/src/sys/netinet6/nd6.c: In function `nd6_setmtu0': /usr/src/src/sys/netinet6/nd6.c:230: error: unrecognizable insn: (insn 34 33 35 6 0x40cc94a0 (set (reg:DI 97) (plus:DI (reg:DI 103) (const_int -5056 [0xec40]))) -1 (nil) (expr_list:REG_DEAD (reg:DI 103) (nil))) /usr/src/src/sys/netinet6/nd6.c:230: internal compiler error: in extract_insn, at recog.c:2175 The compiler configuration is: Reading specs from /usr/src/cross/hp700/lib/gcc-lib/hppa--netbsd/3.3.3/specs Configured with: /usr/src/src/tools/gcc/../../gnu/dist/gcc/configure --target=hppa--netbsd --disable-nls --enable-long-long --disable-multilib --enable-threads --program-transform-name=s,^,hppa--netbsd-, --enable-languages=c c++ objc f77 --prefix=/usr/src/cross/hp700 Thread model: posix gcc version 3.3.3 (NetBSD nb3 20040520) The command line is: /usr/src/cross/hp700/bin/hppa--netbsd-gcc -ffreestanding -mpa-risc-1-1 -msoft-float -mdisable-fpregs -mno-space-regs -mfast-indirect-calls -mportable-runtime -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wno-sign-compare -fno-zero-initialized-in-bss -Dhppa -Dhp700 -I. -I/usr/src/src/sys/arch -I/usr/src/src/sys -nostdinc -DFPEMUL -DLKM -DGSCVERBOSE -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT -I/usr/src/src/sys/dist/ipf -c /usr/src/src/sys/netinet6/nd6.c -- Summary: unrecognizable insn compiling various sources Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at netbsd dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc64--netbsd GCC host triplet: sparc64--netbsd GCC target triplet: hppa--netbsd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
[Bug c/18473] unrecognizable insn compiling various sources
--- Additional Comments From martin at netbsd dot org 2004-11-14 10:06 --- Created an attachment (id=7543) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7543action=view) nd6.i - preproccessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
[Bug target/18473] unrecognizable insn compiling various sources
--- Additional Comments From martin at netbsd dot org 2004-11-14 19:56 --- Forgot to mention (and did not try myself): I've been told this same stuff compiles just fine for NetBSD/hppa on a i386 host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
