[Bug c/81665] Please introduce flags attribute for enums which will mimic one from C#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665 Eric Gallager changed: What|Removed |Added CC||palves at redhat dot com --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > Confirming as an enhancement. Pedro Alves also requested this feature on the > gcc-patches mailing list: > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00726.html cc-ing him
[Bug fortran/86837] Optimization breaks an unformatted read with implicit loop on Mac OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 --- Comment #2 from Pascal --- (In reply to Harald Anlauf from comment #1) > If I add "-fno-frontend-optimize", the test case runs properly. > > There have been other cases where front-end optimization fell over > nested loops. You were lucky to find another one that's not yet covered. This option will help, I can live with the other optimizations only. Hope you can fix the problem I was so lucky to find ;>)
[Bug rtl-optimization/86854] crash on stack unwinding with reorder-blocks-and-partition + linker code folding + C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86854 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- This is a bug in gold's linker implementation of --icf=safe. The main reason is the eh/unwind information from GCC is correct for the landing location but --icf=safe does not take into account the difference in landing locations before merging them. Report this to binutils instead.
[Bug rtl-optimization/86854] crash on stack unwinding with reorder-blocks-and-partition + linker code folding + C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86854 --- Comment #1 from Joshua Oreman --- To clarify, the -freorder-blocks-and-partition argument in the example invocations is superfluous (that optimization is enabled by default at -O2). With -fno-reorder-blocks-and-partition the issue is not observed even with identical code folding enabled.
[Bug rtl-optimization/86854] New: crash on stack unwinding with reorder-blocks-and-partition + linker code folding + C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86854
Bug ID: 86854
Summary: crash on stack unwinding with
reorder-blocks-and-partition + linker code folding +
C++ exceptions
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: oremanj at mit dot edu
Target Milestone: ---
With -freorder-blocks-and-partition in GCC 8 (but not in 7.x), GCC shows a
tendency to move exception-throwing C++ code into .cold fragments. The
resulting fragments are often identical between different functions that throw
the same type of exception, and thus will get merged by a linker's "identical
code folding" feature such as gold's --icf=safe. If the functions from which
the identical .cold fragments were split off have different stack layouts, the
merging will lead to misbehavior during stack unwinding, since the single
shared PC of the __cxa_throw call in the merged .cold fragment can't be
associated with the multiple different stack layouts of the multiple functions
that jump to it.
It's not immediately clear to me whether it's GCC or gold that should be doing
something to prevent this, but GCC seems to be much better positioned to
identify the danger, and the documentation for -freorder-blocks-and-partition
says suggestive things about inapplicability to exception-handling scenarios,
so I'm reporting here first.
This is an x86_64 Linux system with GCC from SVN 20180719 (r262861), very close
to 8.2 RC, and none of the few commits between there and 8.2 final appear
related to the issue at hand. gold is version 1.14 from Binutils 2.29.1. Issue
still appears with gold pulled from git master just now; haven't tried with a
newer gcc yet.
$ cat t1.cc
extern "C" int random();
struct nontrivial
{
~nontrivial() { (void) random(); }
};
int fn1(int value)
{
nontrivial guard;
if (value < 0) throw -value;
return 0;
}
$ cat t2.cc
extern "C" int random();
struct nontrivial
{
~nontrivial() { (void) random(); }
};
int fn2(int value)
{
// try to use a lot of registers
int vals[] = {random(), random(), random(), random(),
random(), random(), random(), random()};
int res = (((vals[0] + vals[1]) * (vals[2] + vals[3])) /
((vals[4] + vals[5]) * (vals[6] + vals[7])));
nontrivial guard;
if (value + (res & 1) < 0) throw -value;
return 0;
}
$ cat tm.cc
extern int fn1(int);
extern int fn2(int);
extern "C" int puts(const char *s);
int main()
{
try {
fn1(-1);
puts("didn't throw 1");
} catch (int) {
puts("caught 1");
}
try {
fn2(-2);
puts("didn't throw 2");
} catch (int) {
puts("caught 2");
}
}
$ g++-8 -O2 -std=c++17 -freorder-blocks-and-partition -fuse-ld=gold -o t t1.cc
t2.cc tm.cc
$ ./t
caught 1
caught 2
$ g++-8 -O2 -std=c++17 -freorder-blocks-and-partition -fuse-ld=gold
-Wl,--icf=safe -o t t1.cc t2.cc tm.cc
$ ./t
caught 1
Segmentation fault (core dumped)
[Bug tree-optimization/86853] sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-03 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0
[Bug tree-optimization/86853] New: sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853
Bug ID: 86853
Summary: sprintf optimization for wide strings doesn't account
for conversion failure
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The handling of wide character and string constants in the sprintf pass fails
to consider the possibility of conversion failure. As a result, it sets the
return value to a non-negative range when it should avoid setting it instead.
(Pointed out in https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00275.html).
$ cat d.c && gcc -O2 -Wall -fdump-tree-optimized=/dev/stdout d.c && ./a.out
__WCHAR_TYPE__ ws[] = L"\u";
int main (void)
{
int n0 = __builtin_snprintf (0, 0, "%S", L"\u");
int n1 = __builtin_snprintf (0, 0, "%S", ws);
__builtin_printf ("%i == %i\n", n0, n1);
if (n0 != n1)
__builtin_abort ();
}
;; Function main (main, funcdef_no=0, decl_uid=1899, cgraph_uid=1,
symbol_order=1) (executed once)
main ()
{
int n1;
[local count: 1073741825]:
n1_5 = __builtin_snprintf (0B, 0, "%S", );
__builtin_printf ("%i == %i\n", 1, n1_5);
if (n1_5 != 1)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312327]:
return 0;
}
1 == -1
Aborted (core dumped)
[Bug tree-optimization/80537] missing -Wformat-overflow on POSIX %C conversion specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80537 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 fiesh at zefix dot tv changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from fiesh at zefix dot tv --- "Concrete stuff" that could be done is ensuring Compare for std::sort, but then I feel this might make the ticket too specific. Even though I'm not entirely convinced this is actually a bad idea, I'll close the ticket seeing there seems to be no support for it.
[Bug libstdc++/86852] New: map and unordered_map wrong deduction guides for inilializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852
Bug ID: 86852
Summary: map and unordered_map wrong deduction guides for
inilializer_list
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
According to
https://en.cppreference.com/w/cpp/container/unordered_map/deduction_guides
Deduction guides for unodrered_map:
template,
class Pred = std::equal_to,
class Alloc = std::allocator>>
unordered_map(std::initializer_list>,
typename /*see below*/::size_type = /*see below*/,
Hash = Hash(), Pred = Pred(), Alloc = Alloc())
-> unordered_map;
Note that the guide is for std::pair, i.e., the key is const.
In libstdc++'s unodered_map:
unordered_map(initializer_list>,
typename unordered_map::size_type = {},
_Hash = _Hash(), _Pred = _Pred(), _Allocator = _Allocator())
-> unordered_map<_Key, _Tp, _Hash, _Pred, _Allocator>;
Note that pair<_Key, _Tp>, i.e., the key is not const.
This breaks unordered_map and map deduction guides:
#include
#include
int main() {
std::unordered_map m1(std::initializer_list<
std::pair>({{1, 2}, {2, 3}}));
}
This fails with:
: In function 'int main()':
:5:69: error: class template argument deduction failed:
std::pair>({{1, 2}, {2, 3}}));
However, if const is removed from the key:
This breaks unordered_map and map deduction guides:
#include
#include
int main() {
std::unordered_map m1(std::initializer_list<
std::pair< int, int>>({{1, 2}, {2, 3}}));
}
Deduction guide works, but it is unusable:
: In function 'int main()':
:5:64: error: no matching function for call to 'std::unordered_map::unordered_map(std::initializer_list >)'
std::pair< int, int>>({{1, 2}, {2, 3}}));
=
The only way to make this work in gcc is
std::unordered_map m{std::pair{1,2}, {3,4}};
But this does not seem to be correct.
[Bug tree-optimization/86851] New: missing -Wformat-overflow on %s with a constant string plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86851
Bug ID: 86851
Summary: missing -Wformat-overflow on %s with a constant string
plus variable offset
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Even though it's possible to determine the range of lengths of the constant
string in the sprintf call below the sprintf pass fails to do so and so misses
the buffer overflow and also emits suboptimal code. The problem is in the
string_constant function failing to determine the string the [i] expression
refers to. The expression the function sees is SSA_NAME (L"123...") + offset
but it only handles ADDR_EXPR, PLUS_EXPR/POINTER_PLUS_EXPR, and DECL.
$ cat d.c && gcc -O2 -S -Wall -fdump-tree-printf-return-value=/dev/stdout d.c
static const char a[] = "123456789";
char d[4];
void f (int i)
{
if (i > 2)
i = 2;
__builtin_sprintf (d, "%s", [i]);
}
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=2)
d.c:10: __builtin_sprintf: objsize = 4, fmtstr = "%s"
Directive 1 at offset 0: "%s"
Result: 0, 0, -1, 9223372036854775807 (0, 0, -1, -1)
Directive 2 at offset 2: "", length = 1
f (int i)
{
const char * _1;
sizetype _2;
[local count: 1073741825]:
i_6 = MIN_EXPR ;
_2 = (sizetype) i_6;
_1 = + _2;
__builtin_strcpy (, _1);
return;
}
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 François Dumont changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #7 from François Dumont --- Yes, we can consider this as fixed. I don't even think that I will eventually try to add the antisymmetry check.
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1
[Bug c++/86849] g++ applies guaranteed copy elision to delegating construction, resulting in miscompiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86849 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1
[Bug c/86850] New: ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850
Bug ID: 86850
Summary: ubsan: runtime error: member call on null pointer
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
struct {
long a[0]
} b;
c, d, k;
long l() {
long e, g, h, j;
int f, i;
for (; i < 4; i++)
j = h < 0;
e += i >> i + j ^ j;
g -= h + j ^ j;
for (i--; i; i++) {
j = -(h < 0);
e += i >> i + j ^ g >> 1;
g -= h >> 1 + j ^ j;
h -= c + j ^ j;
}
return f << 7 + e;
}
m() {
if (d)
if (k)
b.a[1] = b.a[0] = l() - 4;
}
when compiled by a recent ubsan version of trunk, does this:
$ ~/gcc/results.263285.ubsan/bin/gcc -c -O3 -std=c89 -w bug453.c
../../trunk/gcc/vec.h:1688:5: runtime error: member call on null pointer of
type 'struct vec'
It is fine at lower optimise levels:
$ ~/gcc/results.263285.ubsan/bin/gcc -c -O2 -std=c89 -w bug453.c
$
[Bug c++/86849] New: g++ applies guaranteed copy elision to delegating construction, resulting in miscompiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86849
Bug ID: 86849
Summary: g++ applies guaranteed copy elision to delegating
construction, resulting in miscompiles
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Live testcase: https://godbolt.org/g/AKn7j7
For posterity:
#include
struct A {
A() {}
A(int);
~A() {}
int n;
char k;
};
A f();
A::A(int) : A(f()) {}
A f() {
A result;
std::memset(, 0, sizeof(A));
return result; // (nrvo)
}
struct B {
char x, y, z;
};
struct X : A, virtual B { // B is in A's tail padding
X() : B{1, 2, 3}, A(4) {}
};
char test() {
X x;
return x.x; // should return 1
}
Here, GCC uses f() to directly construct the A base class of the X object, and
that tramples over A's tail padding (which contains the B virtual base class of
X, which has already been initialized).
It's not correct to apply guaranteed copy elision to a delegating construction,
just like it's not correct to apply it to a base class construction -- not even
in the C1 constructor variant, due to [[no_unique_address]].
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Implemented in trunk (for gcc 9) by r263298.
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Fri Aug 3 18:38:13 2018 New Revision: 263298 URL: https://gcc.gnu.org/viewcvs?rev=263298=gcc=rev Log: Add fix-it hint for missing return statement in assignment operators (PR c++/85523) gcc/cp/ChangeLog: PR c++/85523 * decl.c: Include "gcc-rich-location.h". (add_return_star_this_fixit): New function. (finish_function): When warning about missing return statements in functions returning non-void, add a "return *this;" fix-it hint for assignment operators. gcc/testsuite/ChangeLog: PR c++/85523 * g++.dg/pr85523.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr85523.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/86837] Optimization breaks an unformatted read with implicit loop on Mac OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf --- If I add "-fno-frontend-optimize", the test case runs properly. There have been other cases where front-end optimization fell over nested loops. You were lucky to find another one that's not yet covered.
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 --- Comment #4 from Caleb James DeLisle --- Very sorry to have bothered you and thank you for your time.
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 --- Comment #3 from Andrew Pinski --- The problem is in https://github.com/cjdelisle/cjdns/blob/crashey/memory/BufferAllocator.c /* Define alignment as the size of a pointer which is usually 4 or 8 bytes. */ #define ALIGNMENT sizeof(char*) That should be different; maybe sizeof(uint64_t) or __alignof__(uint64_t). There might be a C99/C14 macro that you could use.
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
Hmm, the allocator Allocator__calloc is not returning the "correct" alignment
pointer for the type used here.
0x0042a534 <+152>: bl 0x405b74
0x0042a538 <+156>: vldrd16, [sp, #16]
0x0042a53c <+160>: vldrd17, [sp, #24]
0x0042a540 <+164>: vrev64.8q8, q8
0x0042a544 <+168>: mov r4, r0
0x0042a548 <+172>: mov r0, r5
0x0042a54c <+176>: vst1.64 {d16-d17}, [r4 :64]
r4 here is from the allocator.
And if I read this correctly, then Allocator__calloc is incorrect.
struct Prefix6* out = Allocator__calloc((alloc),(sizeof(struct
Prefix6)),(1),"RouteGen.c",161);
out->highBits =
((uint64_t)__builtin_bswap64(((uint64_t)(longs.highBits_be;
out->lowBits =
((uint64_t)__builtin_bswap64(((uint64_t)(longs.lowBits_be;
int pfx = Sockaddr_getPrefix(sa);
So it is doing a store into out (the high and low bits fields).
So this memory needs to be 8 byte aligned as the alignment of struct Prefix6 is
8 bytes due to the uint64_t.
So this is invalid.
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 --- Comment #1 from Caleb James DeLisle --- This issue also reproduces on 6.3.0: root@dirtysanchez:/home/user# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
[Bug tree-optimization/86848] New: ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848
Bug ID: 86848
Summary: ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong
alignment for `vst1.64 {d16-d17}, [r4 :64]` before
function call
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cjd at cjdns dot fr
Target Milestone: ---
Created attachment 44504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44504=edit
.i file which can be compiled to an o file to observe the vst1.64
Comments:
Using -O3, and -mfpu=neon-vfpv4, I'm getting a wrong alignment when pushing
local variables to the stack before a function call.
Unfortunately I was not able to reproduce this with a simple code snippet but I
have an .i file which produces the assembly and
you can see the effect by doing:
git clone git://github.com/cjdelisle/cjdns && cd cjdns
git checkout crashey
CC=arm-linux-gnueabihf-gcc-8 AR=arm-linux-gnueabihf-gcc-ar-8
RANLIB=arm-linux-gnueabihf-gcc-ranlib-8 CFLAGS="-marm -march=armv7-a
-mfpu=neon-vfpv4" CROSS=1 NO_LTO=1 VERBOSE=1 ./do
## copying ./build_linux/test_testcjdroute_c to the ARM device and running
gdb ./test_testcjdroute_c -ex 'r RouteGen_test'
If you only want to see the assembler dump, you can download the attached .i
file and compile it with the provided compile
command and then gdb the .o file and disassemble sockaddrToPrefix6.
Compiler version (default from Ubuntu):
root@dickbutt:/opt/cjdns# arm-linux-gnueabihf-gcc-8 -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20180414-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/arm-linux-gnueabihf-as
--with-ld=/usr/bin/arm-linux-gnueabihf-ld --program-suffix=-8 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-multiarch --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-multilib --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf
--program-prefix=arm-linux-gnueabihf-
--includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu
8-20180414-1ubuntu2)
Relevant compile command:
arm-linux-gnueabihf-gcc-8 -c -x cpp-output -o build_linux/tunnel_RouteGen_c.o
-std=c99 -Wall -Wextra -Werror -Wno-pointer-sign -Wmissing-prototypes -pedantic
-D linux=1 -D CJD_PACKAGE_VERSION="cjdns-v20.2-39-g5d561d65-dirty"
-Wno-unused-parameter -D Log_DEBUG -g -D NumberCompress_TYPE=v3x5x8 -D
Identity_CHECK=1 -D Allocator_USE_CANARIES=1 -D PARANOIA=1
-DHAS_ETH_INTERFACE=1 -fPIE -marm -march=armv7-a -mfpu=neon-vfpv4 -marm
-march=armv7-a -mfpu=neon-vfpv4 -marm -march=armv7-a -mfpu=neon-vfpv4
-D_FORTIFY_SOURCE=2 -fno-stack-protector -fstack-protector-all
-Wstack-protector -O3 build_linux/tunnel_RouteGen_c.o.i
Debugger output:
root@dirtysanchez:/home/user# gdb -q ./test_testcjdroute_c -ex 'r
RouteGen_test'
Reading symbols from ./test_testcjdroute_c...done.
Starting program: /home/user/test_testcjdroute_c RouteGen_test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
1533318603 DEBUG RouteGen_test.c:108 Forward
Program received signal SIGBUS, Bus error.
sockaddrToPrefix6 (sa=sa@entry=0xbeffeb98, allocator=) at
tunnel/RouteGen.c:164
164 Assert_true(pfx > -1);
(gdb) disassemble
Dump of assembler code for function sockaddrToPrefix6:
0x0042a49c <+0>: ldr r3, [pc, #308] ; 0x42a5d8
0x0042a4a0 <+4>: ldr r2, [pc, #308] ; 0x42a5dc
0x0042a4a4 <+8>: add r3, pc, r3
0x0042a4a8 <+12>:push{r4, r5, r6, r7, r8, lr}
0x0042a4ac <+16>:sub sp, sp, #40 ; 0x28
0x0042a4b0 <+20>:ldr r6, [r3, r2]
0x0042a4b4 <+24>:mov r4, r1
0x0042a4b8 <+28>:add r1, sp, #12
0x0042a4bc <+32>:mov r5, r0
0x0042a4c0 <+36>:ldr r3, [r6]
0x0042a4c4 <+40>:str r3, [sp, #36] ; 0x24
0x0042a4c8 <+44>:bl 0x4102a0
0x0042a4cc <+48>:cmp r0, #16
0x0042a4d0 <+52>:
[Bug target/86795] mn10300 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86795 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86795, which changed state. Bug 86795 Summary: mn10300 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86795 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86795] mn10300 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86795 --- Comment #1 from Jeffrey A. Law --- Author: law Date: Fri Aug 3 17:39:00 2018 New Revision: 263296 URL: https://gcc.gnu.org/viewcvs?rev=263296=gcc=rev Log: PR target/86795 * config/mn10300/mn10300.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mn10300/mn10300.c
[Bug tree-optimization/86847] New: [9 Regression] Switch code size growth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86847
Bug ID: 86847
Summary: [9 Regression] Switch code size growth
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ka6ash at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I noticed that the size of code has grown in switch statements between 8.1.0
and trunk. For the code shown below, gcc-trunk generates 2 jumps for each
switch statement (18 in total) when gcc-8.1.0 only 11. The difference appears
at switchlower1 pass. As I understand, gcc-8 prunes redundant tests when gcc-9
doesn't and instead relies on further tree optimizations
(https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00891.html). But the
optimizations cannot manage with it as well as pruning in gcc-8 can and size
grows. Enabling -O2 does not change the situation significantly.
int cipher_to_alg(int cipher)
{
switch (cipher)
{
case 8: return 2;
case 16: return 3;
case 32: return 4;
case 64: return 6;
case 256: return 9;
case 512: return 10;
case 2048: return 11;
case 4096: return 12;
case 8192: return 13;
}
return 0;
}
arm-none-eabi-gcc-8.1.0 cipher.c -Os -S
cipher_to_alg:
cmp r0, #256
beq .L6
bgt .L3
cmp r0, #16
beq .L7
bgt .L4
cmp r0, #8
moveq r0, #2
.L15:
movne r0, #0
bx lr
.L4:
cmp r0, #32
beq .L9
cmp r0, #64
moveq r0, #6
b .L15
.L3:
cmp r0, #2048
beq .L11
bgt .L5
cmp r0, #512
moveq r0, #10
b .L15
.L5:
cmp r0, #4096
beq .L13
cmp r0, #8192
moveq r0, #13
b .L15
.L6:
mov r0, #9
bx lr
.L7:
mov r0, #3
bx lr
.L9:
mov r0, #4
bx lr
.L11:
mov r0, #11
bx lr
.L13:
mov r0, #12
bx lr
arm-none-eabi-gcc-9.0.0 cipher.c -Os -S
cipher_to_alg:
cmp r0, #256
bgt .L2
beq .L8
cmp r0, #16
bgt .L4
beq .L9
cmp r0, #8
bgt .L20
bne .L20
mov r0, #2
bx lr
.L4:
cmp r0, #32
bgt .L5
[Bug libstdc++/86846] New: [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 Bug ID: 86846 Summary: [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 This causes many tests to fail: spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gc c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-9/hppa6 4-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-9/hppa 64-hp-hpux11.11/sys-include -fchecking=1 -B/test/gnu/gcc/objdir/hppa64-hp-hpux11 .11/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sect ions -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/lib supc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/lib stdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/frees tanding.cc -lsupc++ -fvtable-verify=none -fno-diagnostics-show-caret -fdiagnosti cs-color=never ./libtestc++.a -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc ++-v3/src/filesystem/.libs -lm -o ./freestanding.exe ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/obj dir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.sl 1 warnings. output is: ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/obj dir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.sl 1 warnings. FAIL: 17_intro/freestanding.cc (test for excess errors)
[Bug jit/86845] New: libgccjit.so.0.0.1 build error with in-tree isl: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86845 Bug ID: 86845 Summary: libgccjit.so.0.0.1 build error with in-tree isl: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- While trying to build GCC with enough support to debug bug 86841 (apparently the ISL installed on the machine isn't good enough), I downloaded and installed the latest prerequisites, configured GCC via 'configure --enable-host-shared --enable-languages=all' and got the error below. This used to work fine. /usr/bin/ld: /opt/notnfs/msebor/build/gcc-git/./isl/.libs/libisl.a(isl_val_gmp.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC /opt/notnfs/msebor/build/gcc-git/./isl/.libs/libisl.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status /opt/notnfs/msebor/src/gcc/git/gcc/jit/Make-lang.in:97: recipe for target 'libgccjit.so.0.0.1' failed make[3]: *** [libgccjit.so.0.0.1] Error 1 make[3]: *** Waiting for unfinished jobs
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 --- Comment #7 from H.J. Lu --- (In reply to janus from comment #5) > However, in-pack.f90 is the only one that is made to fail by the combination > of -Ofast and -march=skylake-avx512. I think it's the same problem as PR > 86735 (at least it behaves in the same way). > Which kernel are you using?
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1 --- Comment #6 from H.J. Lu --- On Intel Xeon Platinum 8180 under kerne 4.17.11-200, I got PASS: gfortran.fortran-torture/execute/in-pack.f90 execution, -Ofast -march=native FAIL: gfortran.fortran-torture/execute/intrinsic_nearest.f90 execution, -Ofast -march=native FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution, -Ofast -march=native
[Bug tree-optimization/86844] wrong code generation cause by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 Andreas Krebbel changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Severity|normal |major
[Bug tree-optimization/86841] ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841 --- Comment #1 from Martin Sebor --- I don't apparently have this enabled in my builds so I can't readily confirm this error -- I get f951: sorry, unimplemented: Graphite loop optimizations cannot be used (isl is not available) (-fgraphite, -fgraphite-identity, -floop-nest-optimize, -floop-parallelize-all). I have isl-devel installed so I'm not sure what else I need to do to enable it. I'll see if building with ISL downloaded and installed by download_prerequisites enables it (please let me know if there's some trick to making this work.) But beyond that, I doubt this is a problem in the sprintf pass itself. More likely some interaction between the range DOM walker it uses (which sets ranges for statements) and VRP.
[Bug tree-optimization/86844] wrong code generation cause by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 --- Comment #1 from Andreas Krebbel --- Created attachment 44503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44503=edit experimental patch This patch adds a check to check_no_overlap which rejects overlaps if it has seen a non-constant store in between. This fixes the testcase for me.
[Bug tree-optimization/86844] New: wrong code generation cause by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844
Bug ID: 86844
Summary: wrong code generation cause by store merging pass
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 44502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44502=edit
Reduced testcase
Compiling the attached testcase with -O2 results in the following code:
movzbl 4(%rdi), %eax
movl$33024, 8(%rdi)
movb%al, 10(%rdi)
33024 -> 0 0 129 0
The store of 222 gets optimized away.
Without store merging:
movzbl 4(%rdi), %eax
movl$0, 8(%rdi)
movb$-34, 11(%rdi)
movb$-127, 9(%rdi)
movb%al, 10(%rdi)
The original order of stores:
a->b.wd0.u4i = 0;
a->b.wd0.s2.w = 222;
a->b.wd0.s2.y = 129;
a->b.wd0.s2.z = a->f.wd1.s2.z;
coalesce_immediate_stores first reorders the stores according to its bit
positions:
a->b.wd0.u4i = 0;
a->b.wd0.s2.y = 129;
a->b.wd0.s2.z = a->f.wd1.s2.z;
a->b.wd0.s2.w = 222;
It then merges the first and the second and has to end the group seeing the
third. So the last ends up in its own group. Emitting the stores in the
original order makes the 222 store dead. The first two should not be merged.
coalesce_immediate_stores already tries to detect cases where stores later in
the chain might get invalidated by merging early stores but it also assumes
that if the later store also stores a constant it will be possible to merge it
as well. However, in this case the non-constant store in between prevents
this.
Store merging pass output:
;; Function f (f, funcdef_no=0, decl_uid=1922, cgraph_uid=1, symbol_order=0)
Processing basic block <2>:
Starting new chain with statement:
a_3(D)->b.wd0.u4i = 0;
The base object is:
a_3(D)
Recording immediate store from stmt:
a_3(D)->b.wd0.s2.w = 222;
Recording immediate store from stmt:
a_3(D)->b.wd0.s2.y = 129;
Recording immediate store from stmt:
a_3(D)->b.wd0.s2.z = _1;
stmt causes chain termination:
return;
Attempting to coalesce 4 stores in chain
New store group
Store 0:
bitsize:32 bitpos:64 val:0
Store 1:
bitsize:8 bitpos:72 val:129
After writing 0 of size 32 at position 0
the merged value contains 00 00 00 00
the merged mask contains 00 00 00 00
After writing 129 of size 8 at position 8
the merged value contains 00 81 00 00
the merged mask contains 00 00 00 00
New store group
Store 2:
bitsize:8 bitpos:80 val:_1
New store group
Store 3:
bitsize:8 bitpos:88 val:222
Coalescing successful!
Merged into 1 stores
New sequence of 1 stores to replace old one of 2 stores
# .MEM_6 = VDEF <.MEM_5>
MEM[(union *)a_3(D) + 8B] = 33024;
Merging successful!
f (struct bar * a)
{
unsigned char _1;
[local count: 1073741825]:
a_3(D)->b.wd0.s2.w = 222;
MEM[(union *)a_3(D) + 8B] = 33024;
_1 = a_3(D)->D.1919.f.wd1.s2.z;
a_3(D)->b.wd0.s2.z = _1;
return;
}
[Bug target/86828] [6/7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #6 from H.J. Lu --- My machine is Intel Xeon Platinum 8180 and I have no problem under kernel 4.17.11.
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #15 from H.J. Lu --- I can no longer reproduce it under kernel 4.17.11.
[Bug c/86690] [PATCH] Duplicate field in anonymous union causes infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86690 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Joseph S. Myers --- Fix committed for GCC 9.
[Bug c/86690] [PATCH] Duplicate field in anonymous union causes infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86690 --- Comment #3 from Joseph S. Myers --- Author: jsm28 Date: Fri Aug 3 15:25:35 2018 New Revision: 263294 URL: https://gcc.gnu.org/viewcvs?rev=263294=gcc=rev Log: Avoid infinite loop with duplicate anonymous union fields (PR c/86690). If a struct contains an anonymous union and both have a field with the same name, detect_field_duplicates_hash() will replace one of them with NULL. If compilation doesn't stop immediately, it may later call lookup_field() on the union, which falsely assumes the union's LANG_SPECIFIC array is sorted, and may loop indefinitely because of this. 2018-08-03 Bogdan Harjoc PR c/86690 gcc/c: * c-typeck.c (lookup_field): Do not use TYPE_LANG_SPECIFIC after errors. gcc/testsuite: * gcc.dg/union-duplicate-field.c: New test. Added: trunk/gcc/testsuite/gcc.dg/union-duplicate-field.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #6 from Jonathan Wakely --- In fact I'm not really sure there's anything concrete that can be done here. "Check stuff!" isn't very helpful. We already check stuff. Specific suggestions for additional checks are useful. Overly general requests to check everything are not useful, and so the bug report might as well be closed. Nobody's going to work on "check everything everywhere and make it all configurable". Instead of inventing gcc-specific mechanisms it would seem prudent to do something based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html but we have no plans for using that in libstdc++ at this time.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #5 from Jonathan Wakely --- Checking all possible preconditions isn't practical anyway, so isn't going to happen, so we don't need knobs to control that. Not everything can be checked, at some point users need to write correct code.
[Bug c++/86706] [8/9 Regression] ICE in build_base_path, at cp/class.c:294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86706 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Aug 3 15:10:32 2018 New Revision: 263293 URL: https://gcc.gnu.org/viewcvs?rev=263293=gcc=rev Log: PR c++/86706 * class.c (build_base_path): Use currently_open_class. * g++.dg/template/pr86706.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr86706.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek ---
Can't reproduce, either with gcc 8.2.0, or current 8.2.1, or latest trunk:
/d/gcc-8.2.0/objdir/gcc/gfortran -B /d/gcc-8.2.0/objdir/gcc/
-march=skylake-avx512 -Ofast -o pr86735{,.f90} -B
/d/gcc-8.2.0/objdir/x86_64-pc-linux-gnu/libgfortran/.libs/ -B
/d/gcc-8.2.0/objdir/x86_64-pc-linux-gnu/libgfortran/ -B
/d/gcc-8.2.0/objdir/x86_64-pc-linux-gnu/libquadmath/.libs/
-Wl,-rpath,../x86_64-pc-linux-gnu/libgfortran/.libs/; /usr/src/sde/sde64 --
./pr86735
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16
Perhaps sde64 behaves differently from real HW? Tried also -O3 -fstack-arrays,
-mprefer-vector-width={128,256,512}, but everything works.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #4 from fiesh at zefix dot tv --- > So I'm strongly opposed to that part of the suggestion. Either you get all > the ABI-preserving debug checks, or none. Checking all (possible) preconditions without any limit on the introduced complexity might not be possible within reasonable time. Checking transitivity naively is O(N^3). Maybe there's a better way to check something is a strict weak ordering, but in general there might always be a sentence whose veracity cannot be established more efficiently. So if the library wanted to provide checks for every precondition that can be verified (which was my original proposition), I don't see how it's possible meaningfully without any restriction on the computational efforts spent.
[Bug c++/86738] [8/9 Regression] gcc 8.2: Internal compiler error memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86738 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 44501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44501=edit gcc9-pr86738.patch Untested fix.
[Bug target/86838] [9 Regression] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to ktkachov from comment #1) > Confirmed, appeared very recently. I suspect it's fallout from r263251 ? Oops, yes.
[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732 Antony Polukhin changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #9 from Antony Polukhin --- (In reply to Jeffrey A. Law from comment #8) > I wouldn't object to that. In fact I thought we kicked that around along > with an option to remove path leading to the undefined behavior completely. > But it's not something I'm likely to work on. IMO you will need this flag anyway with the "C++20 Contracts" feature to turn contract violations into UB/trap/HandlerCall/terminate/...
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #3 from Jonathan Wakely --- (In reply to fiesh from comment #2) > > Not everything. Some Expects preconditions cannot be tested (e.g. that > > pointer points to an array of at least N objects). > > True. I suppose it's sufficient to have that memory accessed (somehow > explicitly or via other checks), allowing sanitizers to catch bugs here. > > > That sounds like a maintenance nightmare. > > Can you elaborate? There could also be a define like > I_DONT_KNOW_COMPLEXITY_CLASS that sets the exponent n of the O(N^n)? Every additional knob that users can turn increases the implementation burden and the testing required for proper coverage. So I'm strongly opposed to that part of the suggestion. Either you get all the ABI-preserving debug checks, or none.
[Bug c++/86738] [8/9 Regression] gcc 8.2: Internal compiler error memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86738
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
struct S { int s; };
unsigned char a[20];
void
foo ()
{
__builtin_memcpy ([15], [(unsigned) (__UINTPTR_TYPE__) &((S *) 0)->s],
2);
// __builtin_memcpy ([15], [(unsigned) __builtin_offsetof (S, s)], 2);
}
You really should just use offsetof, instead of poor man's attempts at it.
That said, g++ should not crash on it.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #2 from fiesh at zefix dot tv --- > Not everything. Some Expects preconditions cannot be tested (e.g. that > pointer points to an array of at least N objects). True. I suppose it's sufficient to have that memory accessed (somehow explicitly or via other checks), allowing sanitizers to catch bugs here. > That sounds like a maintenance nightmare. Can you elaborate? There could also be a define like I_DONT_KNOW_COMPLEXITY_CLASS that sets the exponent n of the O(N^n)?
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 --- Comment #2 from Thomas Preud'homme --- Thanks for the detailed report.
[Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- So retain all the debug checks in algorithms and in basic_string, but don't replace std::vector with __gnu_debug::vector and so on. Seems like a good idea.
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 --- Comment #6 from Jonathan Wakely --- The irreflexivity checks I originally asked for are done - do we want to keep this open for more extensive checks, or close as FIXED?
[Bug c++/86823] [6/7/8/9 Regression] private member template struct/class is publicly accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823 --- Comment #2 from Jakub Jelinek --- Confirmed by commenting out the two: tentative_firewall firewall (parser); lines and the testcase is rejected again.
[Bug libstdc++/86843] New: Allow separating debug mode into ABI-changing part and rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843 Bug ID: 86843 Summary: Allow separating debug mode into ABI-changing part and rest Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fiesh at zefix dot tv Target Milestone: --- Right now, the debug mode changes the ABI. Thus everything that is linked, including libraries, needs to be compiled using debug mode, making it more difficult to use. It would be great if there were separate defines for activating the ABI changing parts as well as everything not changing the ABI (but possibly violating complexity guarantees, for example). The latter would probably be suitable for almost all debug builds of projects using libstd++.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=60519, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56109 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- (In reply to fiesh from comment #0) > It would be great if there was a means to activate run-time assertions on > these preconditions, as well as on postconditions. In terms of > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0788r3.pdf , > everything listed as "Expects:" and "Ensures:" could be checked by a > run-time check. Not everything. Some Expects preconditions cannot be tested (e.g. that pointer points to an array of at least N objects). > Since in general checking a sentence with n universal quantifiers will > result in O(N^n) many operations, it might be meaningful to separate those > by different macros, allowing the user control over the amount of complexity > degradation they allow for their debug build. That sounds like a maintenance nightmare.
[Bug libstdc++/86842] New: Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 Bug ID: 86842 Summary: Allow run-time checks of pre- and postconditions Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fiesh at zefix dot tv Target Milestone: --- Preface: A rather hard-to-find set of bugs is that introduced by violating run-time preconditions imposed by certain functions. For example, failing to satisfy the Compare requirement for std::sort can lead to tricky problems ranging from segmentation faults to programs just running fine and sometimes doing something not quite expected. It would be great if there was a means to activate run-time assertions on these preconditions, as well as on postconditions. In terms of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0788r3.pdf , everything listed as "Expects:" and "Ensures:" could be checked by a run-time check. Since in general checking a sentence with n universal quantifiers will result in O(N^n) many operations, it might be meaningful to separate those by different macros, allowing the user control over the amount of complexity degradation they allow for their debug build. In addition, checks whose complexity is within the algorithm's complexity class already might be enabled in Debug Mode Lite by default. (This extends https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 )
[Bug c++/86823] [6/7/8/9 Regression] private member template struct/class is publicly accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Bisection points to r231354.
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- From what I see, that commit has been reverted in r263252.
[Bug tree-optimization/86835] [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 44500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44500=edit gcc9-pr86835.patch Untested fix. There was a thinko, in the gsi = *def_gsi; gsi_insert_after (def_gsi, new_stmt, GSI_NEW_STMT); case doing: gsi_insert_before (, new_square_stmt, GSI_SAME_STMT); results exactly in new_square_stmt being two stmts before new_stmt, when it should be after it (i.e. def_gsi points to some stmt, new_stmt is inserted after it and new_square_stmt before it.
[Bug tree-optimization/86835] [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
void
foo (int n, double *x, double *y)
{
int i;
double b = y[4];
for (i = 0; i < n; ++i)
y[3] += __builtin_tanh (x[i] / b);
y[0] /= b;
y[1] /= b * b;
y[2] /= b;
}
[Bug tree-optimization/86835] [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.3 --- Comment #2 from Jakub Jelinek --- Started with r255141.
[Bug target/86752] [9 Regression] FAIL: gcc.target/i386/avx2-cvt-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86752 Sebastian Peryt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||speryt at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Sebastian Peryt --- Duplicate of PR86745 *** This bug has been marked as a duplicate of bug 86745 ***
[Bug target/86745] [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86745 Sebastian Peryt changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from Sebastian Peryt --- *** Bug 86752 has been marked as a duplicate of this bug. ***
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 44499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44499=edit gcc9-pr86836.patch Actually, this seems to work, just tsubst_decomp_names before trying to tsubst_init the initializer; for valid code it should make no difference, because the initializer shouldn't refer to the decomp names, but for invalid code it matters.
[Bug tree-optimization/86841] New: ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841 Bug ID: 86841 Summary: ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: msebor at gcc dot gnu.org, rguenth at gcc dot gnu.org Blocks: 59859 Target Milestone: --- Following causes ICE: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/allocate_with_source_24.f90 -Ofast -floop-parallelize-all -c -fdump-tree-all-gimple during GIMPLE pass: printf-return-value dump file: allocate_with_source_24.f90.170t.printf-return-value2 /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/allocate_with_source_24.f90:93:0: end module iso_varying_string internal compiler error: in zext_hwi, at hwint.h:314 0xfb5147 zext_hwi /home/marxin/Programming/gcc/gcc/hwint.h:314 0xfb5147 unsigned long wi::extract_uhwi >(generic_wide_int const&, unsigned int, unsigned int) /home/marxin/Programming/gcc/gcc/wide-int.h:3205 0xfb5147 wide_int_range_lshift(generic_wide_int&, generic_wide_int&, signop, unsigned int, generic_wide_int const&, generic_wide_int const&, generic_wide_int const&, generic_wide_int const&, bool, bool) /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 0xfc071c extract_range_from_binary_expr_1(value_range*, tree_code, tree_node*, value_range*, value_range*) /home/marxin/Programming/gcc/gcc/tree-vrp.c:2271 0x1027506 vr_values::extract_range_from_binary_expr(value_range*, tree_code, tree_node*, tree_node*, tree_node*) /home/marxin/Programming/gcc/gcc/vr-values.c:768 0x1029830 vr_values::extract_range_from_assignment(value_range*, gassign*) /home/marxin/Programming/gcc/gcc/vr-values.c:1429 0x1504e6b evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool) /home/marxin/Programming/gcc/gcc/gimple-ssa-evrp-analyze.c:293 0x15292b0 before_dom_children /home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:4063 0x14e4e07 dom_walker::walk(basic_block_def*) /home/marxin/Programming/gcc/gcc/domwalk.c:353 0x1529375 execute /home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:4091 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 [Bug 59859] [meta-bug] GRAPHITE issues
[Bug tree-optimization/86841] ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841 Martin Liška changed: What|Removed |Added Target Milestone|--- |9.0 Known to fail||9.0
[Bug tree-optimization/86839] O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839 --- Comment #3 from galileaman bugzilla --- OK, always thought that non-aligned vars only hit performance. I see know it is a requirement in the standard. Sorry, and thanks.
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
I've tried to defer the assert until after cp_finish_decl:
--- pt.c.jj12018-07-31 23:57:23.0 +0200
+++ pt.c2018-08-03 11:11:41.384454435 +0200
@@ -16555,10 +16555,7 @@ tsubst_decomp_names (tree decl, tree pat
decl2 = DECL_CHAIN (decl2))
{
if (TREE_TYPE (decl2) == error_mark_node && *cnt == 0)
- {
- gcc_assert (errorcount);
- return error_mark_node;
- }
+ return error_mark_node;
(*cnt)++;
gcc_assert (DECL_DECOMP_BASE (decl2) == pattern_decl);
gcc_assert (DECL_HAS_VALUE_EXPR_P (decl2));
@@ -16572,7 +16569,6 @@ tsubst_decomp_names (tree decl, tree pat
DECL_TEMPLATE_INSTANTIATED (decl3) = 1;
else
{
- gcc_assert (errorcount);
decl = error_mark_node;
continue;
}
@@ -16582,10 +16578,7 @@ tsubst_decomp_names (tree decl, tree pat
else if (decl != error_mark_node
&& DECL_CHAIN (decl3) != prev
&& decl != prev)
- {
- gcc_assert (errorcount);
- decl = error_mark_node;
- }
+ decl = error_mark_node;
else
prev = decl3;
}
@@ -16770,6 +16763,8 @@ tsubst_expr (tree t, tree args, tsubst_f
cp_finish_decl (decl, init, const_init, NULL_TREE, 0);
if (ndecl != error_mark_node)
cp_finish_decomp (ndecl, first, cnt);
+ else
+ gcc_assert (errorcount);
}
else
cp_finish_decl (decl, init, const_init, NULL_TREE, 0);
@@ -16813,9 +16808,13 @@ tsubst_expr (tree t, tree args, tsubst_f
tree decomp_first = NULL_TREE;
unsigned decomp_cnt = 0;
if (VAR_P (decl) && DECL_DECOMPOSITION_P (decl))
- decl = tsubst_decomp_names (decl, RANGE_FOR_DECL (t), args,
- complain, in_decl,
- _first, _cnt);
+ {
+ decl = tsubst_decomp_names (decl, RANGE_FOR_DECL (t), args,
+ complain, in_decl,
+ _first, _cnt);
+ if (decl == error_mark_node)
+ gcc_assert (errorcount);
+ }
if (processing_template_decl)
{
but that doesn't help, the bug isn't diagnosed in this case either.
For some reason, the orig decomp VAR_DECL is tsubsted to the PARM_DECL rather
than a new VAR_DECL representing the structured binding id, and thus also
cp_finish_decl succeeds. Giving up here.
[Bug middle-end/86840] New: __attribute__((optimize("exceptions"))) is silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86840
Bug ID: 86840
Summary: __attribute__((optimize("exceptions"))) is silently
ignored
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test.c:
...
void a (void);
void do_cleanup (void *p);
void
#ifdef E
__attribute__((optimize("exceptions")))
#endif
b (void)
{
int c __attribute__((cleanup(do_cleanup)));
a();
}
...
When enabling exceptions, an exception table is generated:
...
$ gcc test.c -o- -S -O2 -fexceptions | grep -c "\.gcc_except_table"
2
...
And when disabling exceptions, it's not:
...
$ gcc test.c -o- -S -O2 -fno-exceptions | grep -c "\.gcc_except_table"
0
...
When enabling exceptions using the attribute on function b, no exception table
is generated:
...
$ gcc test.c -o- -S -O2 -fno-exceptions -DE | grep -c "\.gcc_except_table"
0
...
This should have a warning "attribute ignored", and/or document this more
clearly in the documentation of fexceptions and/or the optimize attribute.
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Without templates:
struct A {
int operator*();
void operator++();
bool operator!=(A);
};
class map {
public:
A begin();
A end();
};
void mergemap(map orig, map toadd) {
for (auto p : toadd)
auto [orig] = orig;
}
int
main() {
map x, y;
mergemap(x, y);
}
this is rejected with:
pr86836-2.C: In function ‘void mergemap(map, map)’:
pr86836-2.C:14:19: error: use of ‘orig’ before deduction of ‘auto’
auto [orig] = orig;
^~~~
[Bug tree-optimization/86839] O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- Yeah, clearly invalid.
[Bug target/86838] [9 Regression] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Summary|ICE in gen_aarch64_frecpe, |[9 Regression] ICE in |at ./insn-opinit.h:571 |gen_aarch64_frecpe, at ||./insn-opinit.h:571 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed, appeared very recently. I suspect it's fallout from r263251 ?
[Bug tree-optimization/86839] O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839 --- Comment #1 from Andrew Pinski --- Try using -fsanitizer=undefined . As I think you are violating c/c++ alignment rules. That is a pointer to a float has an alignment requirement of 4 bytes but your pointer that you are using only has an alignment of 1 byte.
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 --- Comment #31 from Rainer Orth --- Created attachment 44498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44498=edit Proposed patch for gcc.dg/vect/no-section-anchors-vect-69.c failure
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #30 from Rainer Orth --- (In reply to Steve Ellcey from comment #22) Finally coming back to this... > Ranier Orth reported a failure on SPARC64 as well, here was my reply > to him. I don't know if your problem is the same without seeing the > specific failure. > > -- > > Looking at the checks at the end, I also see that SPARC does include > the 'Alignment' message and Aarch64 does not and that is handled by a > conditional check. > > I think the fix is to check for 'vectorized 4 loops' when we support > unaligned vector instructions (vect_hw_misalign is true) and check for > 'vectorized 3 loops' otherwise. Does that sound reasonable to you? I just successfully tested a patch along these lines on sparc-sun-solaris2.11 and i386-pc-solaris2.11: works fine. I'll also test on the gcc-8 branch which is likewise affected and then post to gcc-patches. Thanks for the suggestion. Rainer
[Bug tree-optimization/86839] New: O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839
Bug ID: 86839
Summary: O3 create wrong code (segmentation fault) on extern
non-aligned buffer
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: galileaman.bugzilla at gmail dot com
Target Milestone: ---
gcc-5.4 miscompiles the following code on x86_64-linux-gnu at -O3 in 64-bit
mode. The resulting binary cause segmentation fault.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.10' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
$ g++ -Wall -c simple_struct.cpp
$ g++ -Wall -O2 simple.cpp simple_struct.o
$ ./a.out
After alignInt, address 0x7fffc21fb274
After nonAlignInt, address 0x7fffc21fb211
After alignExt, address 0x6011a4
After nonAlignExt, address 0x601201
$ g++ -Wall -O3 simple.cpp simple_struct.o
$ ./a.out
After alignInt, address 0x7ffce7dd6fa4
After nonAlignInt, address 0x7ffce7dd6f41
After alignExt, address 0x6021a4
Segmentation fault (core dumped)
simple_struct.h:
#ifndef _TEST_H
#define _TEST_H
#pragma pack(push)
#pragma pack(1)
#define BUF_LEN (20)
struct BufNonAligned {
char buf[1];
float vals[BUF_LEN];
};
#pragma pack(pop)
#pragma pack(push)
#pragma pack(1)
struct BufAligned {
char buf[4];
float vals[BUF_LEN];
};
#pragma pack(pop)
#endif
simple_struct.cpp:
#include "simple_struct.h"
struct BufAlignedalignExt;
struct BufNonAligned nonAlignExt;
---
simple.cpp:
#include
#include "simple_struct.h"
extern BufAlignedalignExt;
extern BufNonAligned nonAlignExt;
int main(void) {
struct BufAlignedalignInt;
struct BufNonAligned nonAlignInt;
float val = 0.5;
for (float *p = alignInt.vals; p != alignInt.vals + BUF_LEN ; p++) {
*p = val;
}
std::cout << "\tAfter alignInt, address " << alignInt.vals << std::endl;
for (float *p = nonAlignInt.vals; p != nonAlignInt.vals + BUF_LEN ; p++) {
*p = val;
}
std::cout << "\tAfter nonAlignInt, address " << nonAlignInt.vals <
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Paul Thomas --- [...] > Does the attachment fix the problem? Seems I completely missed this, sorry. I've just ran sparc-sun-solaris2.11 and i386-pc-solaris2.11 bootstraps last night; unfortunately there was no change with your patch. Rainer
[Bug target/86838] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-8-3 CC||jgreenhalgh at gcc dot gnu.org, ||kyrylo.tkachov at arm dot com, ||ramana at gcc dot gnu.org Target Milestone|--- |9.0
[Bug target/86838] New: ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 Bug ID: 86838 Summary: ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-linux-gnu Following causes ICE: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c -Ofast -mlow-precision-div -c during RTL pass: expand /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c: In function ‘f’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c:10:6: internal compiler error: in gen_aarch64_frecpe, at ./insn-opinit.h:571 void f(int x, double z, double w) ^ 0x1519c40 gen_aarch64_frecpe(machine_mode, rtx_def*, rtx_def*) ./insn-opinit.h:571 0x15046ec aarch64_emit_approx_div(rtx_def*, rtx_def*, rtx_def*) /home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c:9888 0x1863430 gen_divdf3(rtx_def*, rtx_def*, rtx_def*) /home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.md:5806 0xe49b47 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const /home/marxin/Programming/gcc/gcc/recog.h:302 0xef8535 maybe_gen_insn(insn_code, unsigned int, expand_operand*) /home/marxin/Programming/gcc/gcc/optabs.c:7318 0xee3c27 expand_binop_directly /home/marxin/Programming/gcc/gcc/optabs.c:1098 0xee4120 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /home/marxin/Programming/gcc/gcc/optabs.c:1185 0xbbd4be expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/marxin/Programming/gcc/gcc/expr.c:9631 0xa28c2d expand_gimple_stmt_1 /home/marxin/Programming/gcc/gcc/cfgexpand.c:3673 0xa28eaa expand_gimple_stmt /home/marxin/Programming/gcc/gcc/cfgexpand.c:3734 0xa31df0 expand_gimple_basic_block /home/marxin/Programming/gcc/gcc/cfgexpand.c:5769 0xa337ee execute /home/marxin/Programming/gcc/gcc/cfgexpand.c:6372
[Bug target/84332] ICE in insn_default_length, at config/s390/s390.md:9697 for -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84332 --- Comment #2 from Martin Liška --- Any progress here please?
[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732 --- Comment #8 from Jeffrey A. Law --- I wouldn't object to that. In fact I thought we kicked that around along with an option to remove path leading to the undefined behavior completely. But it's not something I'm likely to work on.
[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732 --- Comment #7 from Marc Glisse --- (In reply to Jeffrey A. Law from comment #5) > And FWIW, I think we should be using __builtin_trap rather than > __builtin_unreachable in many more places because of the security concerns. It would be better to control it with flags instead of doing it inconsistently depending on who wrote each pass. We already have -fsanitize=unreachable -fsanitize-undefined-trap-on-error to automatically replace __builtin_unreachable with __builtin_trap. However, we do not have an opposite 'performance' option for cases where security is irrelevant.
[Bug fortran/50360] [cleanup] use an ENUM for the return values of gfc_dep_compare_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50360 Dominique d'Humieres changed: What|Removed |Added CC|dominiq at lps dot ens.fr | --- Comment #4 from Dominique d'Humieres --- Please don't CC me.
