non-reproducible g++.dg/ubsan/align-2.C -Os execution failure
Hi, I ran into this non-reproducible failure while testing a non-bootstrap build on x86_64: ... PASS: g++.dg/ubsan/align-2.C -Os (test for excess errors) Setting LD_LIBRARY_PATH to .:/data/vries/test-fix-fuse-caller-save-s390/with/nobootstrap/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/dat\ a/vries/test-fix-fuse-caller-save-s390/with/nobootstrap/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/vries/gcc_versions/data/test-fi\ x-fuse-caller-save-s390/with/nobootstrap/build/gcc:/home/vries/gcc_versions/data/test-fix-fuse-caller-save-s390/with/nobootstrap/build/gcc/32:/data/v\ ries/test-fix-fuse-caller-save-s390/with/nobootstrap/build/x86_64-unknown-linux-gnu/./libsanitizer/ubsan/.libs:.:/data/vries/test-fix-fuse-caller-sav\ e-s390/with/nobootstrap/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/data/vries/test-fix-fuse-caller-save-s390/with/nobootstrap/build/x86\_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/vries/gcc_versions/data/test-fix-fuse-caller-save-s390/with/nobootstrap/build/gcc:/home/vries/gc\ c_versions/data/test-fix-fuse-caller-save-s390/with/nobootstrap/build/gcc/32:/data/vries/test-fix-fuse-caller-save-s390/with/nobootstrap/build/x86_64\ -unknown-linux-gnu/./libsanitizer/ubsan/.libs:/home/vries/gcc_versions/infra/lib spawn [open ...]^M /home/vries/gcc_versions/data/test-fix-fuse-caller-save-s390/with/src/gcc/testsuite/g++.dg/ubsan/align-2.C:16:13: runtime error: reference binding to\ misaligned address 0x00600fe9 for type 'int', which requires 4 byte alignment 0x00600fe9: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00FAIL: g++.dg/ubsan/align-2.C -Os execution test ... The sources used where r214879 + a trivial patch ( https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00253.html ) which should not make a difference on x86_64. Configure line: ... Configured with: /home/vries/gcc_versions/data/test-fix-fuse-caller-save-s390/with/src/configure --prefix=/home/vries/gcc_versions/data/test-fix-fuse-caller-save-s390/with/nobootstrap/install --with-cloog=/home/vries/gcc_versions/infra --with-ppl=/home/vries/gcc_versions/infra --with-gmp=/home/vries/gcc_versions/infra --with-mpfr=/home/vries/gcc_versions/infra --with-mpc=/home/vries/gcc_versions/infra --disable-bootstrap --enable-checking=yes,rtl --enable-languages=c,fortran,ada,java,objc,c++ ... I'm posting it here for reference. Thanks, - Tom
[BUILDROBOT] rs6000-ibm-aix4.3 / rs6000-ibm-aix5.3.0: error: ‘ASM_WEAKEN_DECL’ was not declared in this scope
Hi! I should have sent this earlier, but maybe you're still interested: [...] g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o rs6000.o -MT rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo ../../../gcc/gcc/config/rs6000/rs6000.c ../../../gcc/gcc/config/rs6000/rs6000.c: In function ‘bool rs6000_declare_alias(symtab_node*, void*)’: ../../../gcc/gcc/config/rs6000/rs6000.c:29707:50: error: ‘ASM_WEAKEN_DECL’ was not declared in this scope ASM_WEAKEN_DECL (data->file, n->decl, name, NULL); ^ make[2]: *** [rs6000.o] Error 1 I see this at least for rs6000-ibm-aix5.3.0 (eg. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=350500) and rs6000-ibm-aix4.3 (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=350449). MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: The real problem with C++ for kernel modules is: the second : the language just sucks. -- Linus Torvalds signature.asc Description: Digital signature
Re: non-reproducible g++.dg/ubsan/align-2.C -Os execution failure
Hello!
> I ran into this non-reproducible failure while testing a non-bootstrap build
> on x86_64:
>
> ...
> PASS: g++.dg/ubsan/align-2.C -Os (test for excess errors)
I found the same problem on x86_64 CentOS 5.10 when testing with -m32:
gcc unix/-m32:
FAIL: c-c++-common/ubsan/align-2.c -Os execution test
g++ unix/-m32:
FAIL: c-c++-common/ubsan/align-2.c -O2 execution test
FAIL: c-c++-common/ubsan/align-2.c -O3 -fomit-frame-pointer execution test
FAIL: c-c++-common/ubsan/align-2.c -O3 -g execution test
FAIL: c-c++-common/ubsan/align-2.c -O2 -flto -flto-partition=none
execution test
FAIL: c-c++-common/ubsan/align-2.c -O2 -flto execution test
FAIL: c-c++-common/ubsan/align-4.c -O1 execution test
The call to f4 in the following line triggers the failure:
if (f2 (&v.u.e) + f3 (&v.u.e, 4) + f4 (&v.u.f.b) != 0)
__builtin_abort ();
I find it interesting that adding a dummy char c; after long long b in:
struct T { char a; long long b; };
solves the problem for me.
However, running the executable under valgrind shows nothing interesting.
For reference:
$ /lib/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.
Uros.
Re: [BUILDROBOT] rs6000-ibm-aix4.3 / rs6000-ibm-aix5.3.0: error: 'ASM_WEAKEN_DECL' was not declared in this scope
Hi, Jan This probably is expected for AIX 4.3. I am surprised that this occurs for AIX 5.3 because I thought that weak support was available after AIX 5.1 or AIX 5.2. I think that the weak support and MAKE_DECL_ONE_ONLY are required for proper operation now. Maybe I should formally deprecate AIX 4.3. Thanks, David On Thu, Sep 4, 2014 at 4:39 AM, Jan-Benedict Glaw wrote: > Hi! > > I should have sent this earlier, but maybe you're still interested: > > [...] > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual > -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. > -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include > -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber > -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber > -I../../../gcc/gcc/../libbacktrace-o rs6000.o -MT rs6000.o -MMD -MP -MF > ./.deps/rs6000.TPo ../../../gcc/gcc/config/rs6000/rs6000.c > ../../../gcc/gcc/config/rs6000/rs6000.c: In function 'bool > rs6000_declare_alias(symtab_node*, void*)': > ../../../gcc/gcc/config/rs6000/rs6000.c:29707:50: error: 'ASM_WEAKEN_DECL' > was not declared in this scope > ASM_WEAKEN_DECL (data->file, n->decl, name, NULL); > ^ > make[2]: *** [rs6000.o] Error 1 > > > I see this at least for rs6000-ibm-aix5.3.0 (eg. > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=350500) > and rs6000-ibm-aix4.3 > (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=350449). > > MfG, JBG > > -- > Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 > Signature of: The real problem with C++ for kernel modules is: > the second : the language just sucks. >-- Linus Torvalds
Re: Compare Elimination problems
On 09/03/2014 03:14 PM, Paul Shortis wrote:
> (insn 33 84 85 6 (parallel [
> (set (reg:HI 1 r1)
> (ashift:HI (reg:HI 1 r1)
> (const_int 1 [0x1])))
> (clobber (reg:CC_NOOV 7 flags))
> ]) ../gcc/testsuite/gcc.c-torture/execute/960311-3.c:18 33 {ashlhi3}
>
> (insn 34 87 35 6 (set (reg:CC_NOOV 7 flags)
> (compare:CC_NOOV (reg:SI 0 r0)
> (const_int 0 [0])))
> ../gcc/testsuite/gcc.c-torture/execute/960311-3.c:20 39 {*comparesi3_nov}
>
> (jump_insn 35 34 36 6 (set (pc)
> (if_then_else (ge (reg:CC_NOOV 7 flags)
>
> to
>
> (insn 33 84 85 6 (parallel [
> (set (reg:HI 1 r1)
> (ashift:HI (reg:HI 1 r1)
> (const_int 1 [0x1])))
> (set (reg:CC_NOOV 7 flags)
> (compare:CC_NOOV (ashift:HI (reg:HI 1 r1)
> (const_int 1 [0x1]))
> (const_int 0 [0])))
> ]) ../gcc/testsuite/gcc.c-torture/execute/960311-3.c:18 29
> {ashlhi3_cc}
>
> (jump_insn 35 87 36 6 (set (pc)
> (if_then_else (ge (reg:CC_NOOV 7 flags)
>
>
> (reg:HI r1) is a subreg of (reg:SI r0) however the cmpelim seems to be
> substituting the compare of (reg:HI r1 and 0) for the compare of (reg:SI r0
> and
> 0) ?
That would appear to be a bug, though I don't immediately see where.
The relevant test would appear to be
if (rtx_equal_p (SET_DEST (x), in_a))
which would not be true for (reg:SI) vs (reg:HI), whatever their regno's.
Anyway, put your breakpoint in try_eliminate_compare to debug this.
> While I'm here, in i386.md some of the flag setting operations specify a mode
> and some don't . Eg
>
> (define_expand "cmp_1"
> [(set (reg:CC FLAGS_REG)
> (compare:CC (match_operand:SWI48 0 "nonimmediate_operand")
That's a define_expand, not a define_insn.
> (define_insn "*add_3"
> [(set (reg FLAGS_REG)
> (compare
The mode checks are done in the ix86_match_ccmode call inside the predicate.
r~
ICE in bitmap routines with LRA and inline assembly language
I was wondering if anyone has seen this bug involving LRA and inline
assembly code. On MIPS, I am getting the attached ICE. Somehow
the 'first' pointer in the live_reload_and_inheritance_pseudos bitmap
structure is either getting clobbered or is not being correctly
initialized to begin with. I am not sure which yet.
Steve Ellcey
sell...@mips.com
% cat x.c
int NoBarrier_AtomicIncrement(volatile int* ptr, int increment) {
int temp, temp2;
__asm__ __volatile__(".set push\n"
".set noreorder\n"
"1:\n"
"ll %0, 0(%3)\n"
"addu %1, %0, %2\n"
"sc %1, 0(%3)\n"
"beqz %1, 1b\n"
"addu %1, %0, %2\n"
".set pop\n"
: "=&r" (temp), "=&r" (temp2)
: "Ir" (increment), "r" (ptr)
: "memory");
return temp2;
}
% mips-mti-linux-gnu-gcc -O1 -c x.c
x.c: In function 'NoBarrier_AtomicIncrement':
x.c:16:1: internal compiler error: Segmentation fault
}
^
0x9b199f crash_signal
/scratch/sellcey/nightly/src/gcc/gcc/toplev.c:339
0x5d3950 bitmap_element_link
/scratch/sellcey/nightly/src/gcc/gcc/bitmap.c:456
0x5d3950 bitmap_set_bit(bitmap_head*, int)
/scratch/sellcey/nightly/src/gcc/gcc/bitmap.c:673
0x87c370 init_live_reload_and_inheritance_pseudos
/scratch/sellcey/nightly/src/gcc/gcc/lra-assigns.c:413
0x87c370 lra_assign()
/scratch/sellcey/nightly/src/gcc/gcc/lra-assigns.c:1499
0x877966 lra(_IO_FILE*)
/scratch/sellcey/nightly/src/gcc/gcc/lra.c:2236
0x8337de do_reload
/scratch/sellcey/nightly/src/gcc/gcc/ira.c:5311
0x8337de execute
/scratch/sellcey/nightly/src/gcc/gcc/ira.c:5470
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
RE: Register allocation: caller-save vs spilling
Hi Vlad,
I added you directly in case you hadn't spotted my original post.
A simple example for AArch64 trunk is as follows:
// Compile with: -O2 -fomit-frame-pointer -ffixed-d8 -ffixed-d9 -ffixed-d10
-ffixed-d11 -ffixed-d12
-ffixed-d13 -ffixed-d14 -ffixed-d15 -f(no-)caller-saves
void g(void);
float f(float x)
{
x += 3.0;
g();
x *= 3.0;
return x;
}
It seems that reload only ever considers rematerialization of spilled
liveranges, not caller-saved
ones. That means the caller-save code should either reject constants outright
or the memory spill
cost for these should always be lower than that of a caller-save (given
memory_move_cost=4 and
register_move_cost=2 as commonly used by targets, anything that can be
rematerialized should have
less than half the cost of being spilled or caller-saved).
Wilco
> -Original Message-
> From: Wilco Dijkstra [mailto:wdijk...@arm.com]
> Sent: 27 August 2014 17:25
> To: 'gcc@gcc.gnu.org'
> Subject: Register allocation: caller-save vs spilling
>
> Hi,
>
> I'm investigating various register allocation inefficiencies. The first thing
> that stands out
> is that GCC both supports caller-saves as well as spilling. Spilling seems to
> spill all
> definitions and all uses of a liverange. This means you often end up with
> multiple reloads
> close together, while it would be more efficient to do a single load and then
> reuse the loaded
> value several times. Caller-save does better in that case, but it is
> inefficient in that it
> repeatedly stores registers across every call even if unchanged. If both were
> fixed to
> minimise the number of loads/stores I can't see how one could beat the other,
> so you'd no
> longer need both.
>
> Anyway due to the current implementation there are clearly cases where
> caller-save is best and
> cases where spilling is best. However I do not see it making the correct
> decision despite
> trying to account for the costs - some code is significantly faster with
> -fno-caller-saves,
> other code wins with -fcaller-saves. As an example, I see code like this on
> AArch64:
>
> ldr s4, .LC20
> fmuls0, s0, s4
> str s4, [x29, 104]
> bl f
> ldr s4, [x29, 104]
> fmuls0, s0, s4
>
> With -fno-caller-saves it spills and rematerializes the constant as you'd
> expect:
>
> ldr s1, .LC20
> fmuls0, s0, s1
> bl f
> ldr s5, .LC20
> fmuls0, s0, s5
>
> So given this, is the cost calculation correct and does it include
> rematerialization? The
> spill code understands how to rematerialize so it should take this into
> account in the costs.
> I did find some code in ira-costs.c in scan_one_insn() that attempts
> something that looks like
> an adjustment for rematerialization but it doesn't appear to handle all cases
> (simple
> immediates, 2-instruction immediates, address-constants, non-aliased loads
> such as literal
> pool and const data loads).
>
> Also the hook CALLER_SAVE_PROFITABLE appears to have disappeared - overall
> performance
> improves significantly if I add this (basically the default heuristic used on
> instruction
> frequencies):
>
> --- a/gcc/ira-costs.c
> +++ b/gcc/ira-costs.c
> @@ -2230,6 +2230,8 @@ ira_tune_allocno_costs (void)
>* ALLOCNO_FREQ (a)
>* IRA_HARD_REGNO_ADD_COST_MULTIPLIER (regno) / 2);
> #endif
> + if (ALLOCNO_FREQ (a) < 4 * ALLOCNO_CALL_FREQ (a))
> +cost = INT_MAX;
> }
> if (INT_MAX - cost < reg_costs[j])
> reg_costs[j] = INT_MAX;
>
> If such a simple heuristic can beat the costs, they can't be quite right.
Note if (ALLOCNO_FREQ (a) < 2 * ALLOCNO_CALL_FREQ (a)) turns out to be best
overall.
> Is there anyone who understands the cost calculations?
>
> Wilco
gcc-4.8-20140904 is now available
Snapshot gcc-4.8-20140904 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140904/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 214923 You'll find: gcc-4.8-20140904.tar.bz2 Complete GCC MD5=c67fc807e48436e4ddb2ba21fe0f5aec SHA1=c5950765f9caf8c0dfbcce2e022f607745ce4eb7 Diffs from 4.8-20140828 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Compare Elimination problems
Thanks Richard,
I found the bug. try_eliminate_compare follows register
definitions between the flags use and the clobbering compare by
register number only, i.e. the register width isn't considered.
if (DF_REF_REGNO (def) == REGNO (in_a))
break;
This caused R1:HI to follow R0:SI causing the compare:HI (R0, so
be seen as as valid source of flags.
The following change fixes the problem while preserving the
proper behaviour.
x = single_set (insn);
if (x == NULL)
return false;
+ if( GET_MODE(x) != GET_MODE(in_a))
+ return false;
in_a = SET_SRC (x);
Cheers, Paul.
On 05/09/14 02:33, Richard Henderson wrote:
On 09/03/2014 03:14 PM, Paul Shortis wrote:
(insn 33 84 85 6 (parallel [
(set (reg:HI 1 r1)
(ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1])))
(clobber (reg:CC_NOOV 7 flags))
]) ../gcc/testsuite/gcc.c-torture/execute/960311-3.c:18 33 {ashlhi3}
(insn 34 87 35 6 (set (reg:CC_NOOV 7 flags)
(compare:CC_NOOV (reg:SI 0 r0)
(const_int 0 [0])))
../gcc/testsuite/gcc.c-torture/execute/960311-3.c:20 39 {*comparesi3_nov}
(jump_insn 35 34 36 6 (set (pc)
(if_then_else (ge (reg:CC_NOOV 7 flags)
to
(insn 33 84 85 6 (parallel [
(set (reg:HI 1 r1)
(ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1])))
(set (reg:CC_NOOV 7 flags)
(compare:CC_NOOV (ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1]))
(const_int 0 [0])))
]) ../gcc/testsuite/gcc.c-torture/execute/960311-3.c:18 29 {ashlhi3_cc}
(jump_insn 35 87 36 6 (set (pc)
(if_then_else (ge (reg:CC_NOOV 7 flags)
(reg:HI r1) is a subreg of (reg:SI r0) however the cmpelim seems to be
substituting the compare of (reg:HI r1 and 0) for the compare of (reg:SI r0 and
0) ?
That would appear to be a bug, though I don't immediately see where.
The relevant test would appear to be
if (rtx_equal_p (SET_DEST (x), in_a))
which would not be true for (reg:SI) vs (reg:HI), whatever their regno's.
Anyway, put your breakpoint in try_eliminate_compare to debug this.
While I'm here, in i386.md some of the flag setting operations specify a mode
and some don't . Eg
(define_expand "cmp_1"
[(set (reg:CC FLAGS_REG)
(compare:CC (match_operand:SWI48 0 "nonimmediate_operand")
That's a define_expand, not a define_insn.
(define_insn "*add_3"
[(set (reg FLAGS_REG)
(compare
The mode checks are done in the ix86_match_ccmode call inside the predicate.
r~
Re: Compare Elimination problems
Correction,
...compare:CC_N... (R1:HI, 0)
On 05/09/14 09:31, Paul Shortis wrote:
Thanks Richard,
I found the bug. try_eliminate_compare follows register
definitions between the flags use and the clobbering compare by
register number only, i.e. the register width isn't considered.
if (DF_REF_REGNO (def) == REGNO (in_a))
break;
This caused R1:HI to follow R0:SI causing the compare:HI (R0,
so be seen as as valid source of flags.
The following change fixes the problem while preserving the
proper behaviour.
x = single_set (insn);
if (x == NULL)
return false;
+ if( GET_MODE(x) != GET_MODE(in_a))
+ return false;
in_a = SET_SRC (x);
Cheers, Paul.
On 05/09/14 02:33, Richard Henderson wrote:
On 09/03/2014 03:14 PM, Paul Shortis wrote:
(insn 33 84 85 6 (parallel [
(set (reg:HI 1 r1)
(ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1])))
(clobber (reg:CC_NOOV 7 flags))
])
../gcc/testsuite/gcc.c-torture/execute/960311-3.c:18 33
{ashlhi3}
(insn 34 87 35 6 (set (reg:CC_NOOV 7 flags)
(compare:CC_NOOV (reg:SI 0 r0)
(const_int 0 [0])))
../gcc/testsuite/gcc.c-torture/execute/960311-3.c:20 39
{*comparesi3_nov}
(jump_insn 35 34 36 6 (set (pc)
(if_then_else (ge (reg:CC_NOOV 7 flags)
to
(insn 33 84 85 6 (parallel [
(set (reg:HI 1 r1)
(ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1])))
(set (reg:CC_NOOV 7 flags)
(compare:CC_NOOV (ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1]))
(const_int 0 [0])))
])
../gcc/testsuite/gcc.c-torture/execute/960311-3.c:18 29
{ashlhi3_cc}
(jump_insn 35 87 36 6 (set (pc)
(if_then_else (ge (reg:CC_NOOV 7 flags)
(reg:HI r1) is a subreg of (reg:SI r0) however the cmpelim
seems to be
substituting the compare of (reg:HI r1 and 0) for the compare
of (reg:SI r0 and
0) ?
That would appear to be a bug, though I don't immediately see
where.
The relevant test would appear to be
if (rtx_equal_p (SET_DEST (x), in_a))
which would not be true for (reg:SI) vs (reg:HI), whatever
their regno's.
Anyway, put your breakpoint in try_eliminate_compare to debug
this.
While I'm here, in i386.md some of the flag setting
operations specify a mode
and some don't . Eg
(define_expand "cmp_1"
[(set (reg:CC FLAGS_REG)
(compare:CC (match_operand:SWI48 0 "nonimmediate_operand")
That's a define_expand, not a define_insn.
(define_insn "*add_3"
[(set (reg FLAGS_REG)
(compare
The mode checks are done in the ix86_match_ccmode call inside
the predicate.
r~
Modifying generic tree with a plugin
Sombody knows if it is possible modifing the generic during compilation with a plugin?
