[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
There are warnings from -Wcast-align=strict and -Wconversion that might be
relevant:
$ /usr/local/bin/gcc -c -O3 -fPIC -Wall -Wextra -pedantic -Wconversion
-Wcast-align=strict c.c
c.c: In function 'compute':
c.c:11:34: warning: cast increases required alignment of target type
[-Wcast-align]
11 | #define READ_UINT16(ptr) (*(uint16_t *)(ptr))
| ^
c.c:19:23: note: in expansion of macro 'READ_UINT16'
19 | int newval = (int)READ_UINT16(b1) + value;
| ^~~
c.c:12:34: warning: cast increases required alignment of target type
[-Wcast-align]
12 | #define WRITE_UINT16(ptr, val) (*(uint16_t *)(ptr) = (val))
| ^
c.c:20:5: note: in expansion of macro 'WRITE_UINT16'
20 | WRITE_UINT16(b2, newval);
| ^~~~
c.c:12:54: warning: conversion from 'int' to 'uint16_t' {aka 'short unsigned
int'} may change value [-Wconversion]
12 | #define WRITE_UINT16(ptr, val) (*(uint16_t *)(ptr) = (val))
| ^
c.c:20:5: note: in expansion of macro 'WRITE_UINT16'
20 | WRITE_UINT16(b2, newval);
| ^~~~
$
[Bug preprocessor/83773] Warning for redefined macro does not have its own -Wsomething switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83773 --- Comment #2 from Eric Gallager --- Clang calls it -Wmacro-redefined: $ clang -fdiagnostics-show-option -Wall -c 83773.c 83773.c:2:9: warning: 'AAA' macro redefined [-Wmacro-redefined] #define AAA 2 ^ 83773.c:1:9: note: previous definition is here #define AAA 1 ^ 1 warning generated. $
[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow with a small power-of-2 size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220 --- Comment #5 from Eric Gallager --- (In reply to Martin Sebor from comment #4) > As an aside, the -Wstringop-overflow for f() will disappear if/when the > patch submitted for bug 83508 is committed. > The patch for bug 83508 was committed as r256683
[Bug c++/80733] -fstrict-enum ineffective, incorrect -Wtype-limits warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80733 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug middle-end/87574] [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- This should work again.
[Bug middle-end/87574] [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Wed Oct 10 22:54:04 2018 New Revision: 265028 URL: https://gcc.gnu.org/viewcvs?rev=265028=gcc=rev Log: PR middle-end/87574 * cgraphunit.c (cgraph_node::expand_thunk): Force DECL_IGNORED_P on the thunk when expanding to GIMPLE. Added: trunk/gcc/testsuite/g++.dg/other/pr87574.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87567] constexpr evaluation rejects call to non-constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Fxied.
[Bug c++/87567] constexpr evaluation rejects call to non-constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567 --- Comment #1 from Marek Polacek --- Author: mpolacek Date: Wed Oct 10 21:11:18 2018 New Revision: 265027 URL: https://gcc.gnu.org/viewcvs?rev=265027=gcc=rev Log: PR c++/87567 - constexpr rejects call to non-constexpr function. * constexpr.c (potential_constant_expression_1) : Return true if the condition is always false. : Likewise. * g++.dg/cpp1y/constexpr-loop7.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-loop7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug target/87579] new powerpc64 sse3 test cases in r264992 have compilation failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87579
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #4 from pc at gcc dot gnu.org ---
$ svn info
Path: .
Working Copy Root Path: /home/pc/trunk
URL: svn+ssh://p...@gcc.gnu.org/svn/gcc/trunk
Repository Root: svn+ssh://p...@gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 265026
Node Kind: directory
Schedule: normal
Last Changed Author: pc
Last Changed Rev: 265026
Last Changed Date: 2018-10-10 15:52:48 -0500 (Wed, 10 Oct 2018)
$ make -k check-gcc-c RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=pr37191*"
...
=== gcc Summary ===
# of expected passes1
# of unsupported tests 1
$ make -k check-gcc-c RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=sse3*"
...
=== gcc Summary ===
# of expected passes20
# of unsupported tests 10
[Bug target/87579] new powerpc64 sse3 test cases in r264992 have compilation failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87579 --- Comment #3 from pc at gcc dot gnu.org --- Author: pc Date: Wed Oct 10 20:52:48 2018 New Revision: 265026 URL: https://gcc.gnu.org/viewcvs?rev=265026=gcc=rev Log: Fat-fingered my recent patch adding the SSE3 testcases for powerpc, most likely by twice applying the patch which added the testcases. This patch removes the duplicated code. [gcc/testsuite] 2018-10-10 Paul A. Clarke PR target/87579 * gcc.target/powerpc/sse3-check.h: Remove duplicated code. * gcc.target/powerpc/sse3-addsubps.c: Likewise. * gcc.target/powerpc/sse3-addsubpd.c: Likewise. * gcc.target/powerpc/sse3-haddps.c: Likewise. * gcc.target/powerpc/sse3-hsubps.c: Likewise. * gcc.target/powerpc/sse3-haddpd.c: Likewise. * gcc.target/powerpc/sse3-hsubpd.c: Likewise. * gcc.target/powerpc/sse3-lddqu.c: Likewise. * gcc.target/powerpc/sse3-movsldup.c: Likewise. * gcc.target/powerpc/sse3-movshdup.c: Likewise. * gcc.target/powerpc/sse3-movddup.c: Likewise. * gcc.target/powerpc/pr37191.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr37191.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-addsubpd.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-addsubps.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-check.h trunk/gcc/testsuite/gcc.target/powerpc/sse3-haddpd.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-haddps.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-hsubpd.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-hsubps.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-lddqu.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-movddup.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-movshdup.c trunk/gcc/testsuite/gcc.target/powerpc/sse3-movsldup.c
[Bug target/87579] new powerpc64 sse3 test cases in r264992 have compilation failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87579 --- Comment #2 from pc at gcc dot gnu.org --- The patch for these changes was inadvertently applied twice before being committed, resulting in duplicated code in the new files. I will check in a patch shortly to remove the extra code.
[Bug target/87579] new powerpc64 sse3 test cases in r264992 have compilation failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87579 Segher Boessenkool changed: What|Removed |Added Target|powerpc64*-*-* |powerpc*-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-10 CC||segher at gcc dot gnu.org Host|powerpc64*-*-* | Assignee|unassigned at gcc dot gnu.org |pc at gcc dot gnu.org Ever confirmed|0 |1 Build|powerpc64*-*-* | --- Comment #1 from Segher Boessenkool --- Paul is fixing it.
[Bug c++/87582] New: Returning a reference to a data member via structured bindings incorrectly reports dangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87582
Bug ID: 87582
Summary: Returning a reference to a data member via structured
bindings incorrectly reports dangling
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cfretz at icloud dot com
Target Milestone: ---
My apologies if I've misunderstood something, or if I've duplicated an issue
someone else already posted, but I ran into this late last night:
struct custom {
int one, two;
};
custom thing {1, 2};
auto& bad() {
auto& [one, two] = thing;
return one;
}
int main() {
[[maybe_unused]] auto& one = bad();
}
All versions of gcc I was able to test on godbolt reported returning a
reference to a local variable in the function "bad", while no versions of clang
reported the same.
For reference: https://godbolt.org/z/fcNZDb
To my knowledge, this code should have the end result of binding the reference
"one" in main to the first data member of the global "thing"; not returning a
reference to a local in the function "bad".
The warning is also not issued if "thing" is a std::tuple, or if the
type "custom" is made to be a "tuple-like type" by specializing
std::tuple_size, std::tuple_element, etc.
I was originally expecting that this was an error somewhere in static analysis,
but if you go on to actually try to use the reference you get a segfault as in
this program: https://godbolt.org/z/lb1afO. Address-sanitizer reports a
null-pointer dereference.
Let me know if any clarifications are required, and I hope I haven't wasted
anyone's time!
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 --- Comment #1 from Andrew Pinski --- Use -fsantizer=undefined to catch this at runtime even without sse or otherwise.
[Bug c/87581] New: Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581
Bug ID: 87581
Summary: Misaligned 16-bit read trap on x86 platform should be
either fixed or documented.
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: svoboda at cert dot org
Target Milestone: ---
Created attachment 44825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44825=edit
Crashing program
The attached code crashes with a SIGSEGV on GCC 4.9.4 on x86-64:
To crash it, compile with: gcc -O3 -fPIC
The same program does not crash if:
* GCC 4.8.5
* -fPIC is omitted
* -mno-sse2 is provided
* -O2
* the compute() function is prepended with:
__attribute__ ((target("no-sse")))
The crash occurs when the program reads and writes mis-aligned 16-bit values.
This is undefined behavior according to C11 s6.3.2.3p7, however it is widely
believed that x86 and x86-64 support unaligned memory reads and writes.
If GCC still assumes that unaligned memory read/write is safe on x86 & x86-64
they should change this optimization behavior.
But if GCC does NOT assume this, they (and others) need to be more vocal about
this. It needs to be in documentation...anyone who uses -O3 should know about
it.
(An alternative is to take SSE2 alignment requirements out of -O3 and put it
somewhere like -Ofast).
[Bug fortran/87580] New: Wrong bounds for sourced allocated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87580 Bug ID: 87580 Summary: Wrong bounds for sourced allocated array Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Bounds of vec2 are wrong in this example (0, 9) instead of (1, 10) as expected (which can lead to all sorts of wrong results). Also in 6.4. program tester real(kind(1.d0)), allocatable :: vec2(:) real(kind(1.d0)) vec(10) allocate(vec2, source=vec*2.) print *, lbound(vec), ubound(vec) print *, lbound(vec2), ubound(vec2) end program tester
[Bug lto/87574] [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574
--- Comment #3 from David Binderman ---
(In reply to Eric Botcazou from comment #2)
> Egad. Reducing the compile-only testcase...
Not sure which one you mean, but I can duplicate the second
test case with this reduced C++ code:
class a {
public:
virtual ~a();
};
class c {
public:
enum j {};
virtual j d() = 0;
};
class e : a, c {
j d();
};
class f;
class g {
public:
static g *h();
f *i();
};
class f {
public:
template b *l(int);
};
c::j e::d() {}
void m() {
for (int k;;)
g::h()->i()->l(k)->d();
}
Flags -g and -O2 required. Problem seems to start between revision
264889 and 264959.
[Bug tree-optimization/82073] internal compiler error: in pop_to_marker, at tree-ssa-scopedtables.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82073 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Eric Gallager --- (In reply to Vsevolod Livinskiy from comment #2) > (In reply to Eric Gallager from comment #1) > > Could you post the output of g++ -v so we have version and target info > > please? > Revision is 251589 > > >$ g++ -v > Using built-in specs. > COLLECT_GCC=g++ > COLLECT_LTO_WRAPPER=/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper > Target: x86_64-pc-linux-gnu > Configured with: /gcc-dev/bin-trunk --disable-bootstrap > Thread model: posix > gcc version 8.0.0 20170901 (experimental) (GCC) I can't reproduce with either 8.2 or trunk revision 264045 on x86_64-apple-darwin10. Feel free to reopen if it still happens for you, although if it does, it's probably a GNU/Linux-specific issue, so the component would then be "target" instead.
[Bug target/87579] New: new powerpc64 sse3 test cases in r264992 have compilation failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87579 Bug ID: 87579 Summary: new powerpc64 sse3 test cases in r264992 have compilation failures Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- > FAIL: gcc.target/powerpc/pr37191.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-addsubpd.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-addsubps.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-haddpd.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-haddps.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-hsubpd.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-hsubps.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-lddqu.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-movddup.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-movshdup.c (test for excess errors) > FAIL: gcc.target/powerpc/sse3-movsldup.c (test for excess errors) Examples: In file included from /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/sse3-check.h:47, from /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/sse3-movddup.c:9: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/m128-check.h:74:3: error: conflicting types for 'union128' /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/sse3-check.h:58:1: error: redefinition of 'do_test' In file included from /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/sse3-movddup.c:9:
[Bug c++/87457] thread sanitizer false positive on virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87457 --- Comment #3 from SebastiansPublicAddress at googlemail dot com --- Is there something else, which libstdc++ depends on, that I need to build with ThreadSanitizer? libgcc or libatomic for example?
[Bug c++/87457] thread sanitizer false positive on virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87457 --- Comment #2 from SebastiansPublicAddress at googlemail dot com --- (In reply to Jonathan Wakely from comment #1) > I think the problem is that the std::thread code in libstdc++.so isn't built > with ThreadSanitizer. Wasn't easy to build libstdc++ with different flags (*), but now I think I did it, and I still get the errors. So I think this was not the cause. I'm quite sure that now I'm using a libstdc++ that's built with -fsanitize=thread because: - I added a printf to thread::join() and I see it when I reproduce the failure. - I see -fsanitize=thread in the output of "make" when I build libstdc++. (*) here's how I built libstdc++: - Build the whole gcc-8 debian source package $ sudo apt-get build-dep gcc-8 $ sudo apt-get source gcc-8 gcc-8-8.2.0$ debuild -b -uc -us - backup and remove gcc-8-8.2.0/build/x86_64-linux-gnu/libstdc++-v3 - configure with the same commandline as in the backup gcc-8-8.2.0/build/x86_64-linux-gnu/libstdc++-v3/config.log (fix quoting of --program-transform-name=s&$&-8&;s&^_64-linux-gnu-&) but with prefix /usr/local/tsan - set a few environment variables as suggested by the error messages repeat until build is sucessful - add --enable-cxx-flags=-fsanitize=thread - make, make install - export LD_LIBRARY_PATH=/usr/local/tsan/lib - build my test program with -L/usr/local/tsan/lib -I/usr/local/tsan/include - export LD_LIBRARY_PATH=/usr/local/tsan/lib
[Bug target/87511] [9 Regression][AArch64] UBFIZ instruction with invalid immediate emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87511 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-10 CC||wilco at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Wilco --- Confirmed. The issue is in aarch64_mask_and_shift_for_ubfiz_p: && (INTVAL (mask) & ((1 << INTVAL (shft_amnt)) - 1)) == 0; This evaluates the shift as a 32-bit int rather than HOST_WIDE_INT.
[Bug c++/68510] [concepts] ICE: in gimplify_var_or_parm_decl, at gimplify.c:1827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68510 Paolo Carlini changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/54391] transparent_union typedef'ing inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54391 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Known to work||6.3.0, 7.3.0, 8.2.0, 9.0 Resolution|--- |FIXED Known to fail||4.8.3, 4.9.3, 5.3.0 --- Comment #2 from Martin Sebor --- This was fixed in rr231048 (gcc 6.0.0).
[Bug c/54391] transparent_union typedef'ing inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54391 --- Comment #1 from Martin Sebor --- Author: msebor Date: Wed Oct 10 17:09:26 2018 New Revision: 265024 URL: https://gcc.gnu.org/viewcvs?rev=265024=gcc=rev Log: PR c/54391 - transparent_union typedef'ing inconsistent gcc/testsuite/ChangeLog: * gcc.dg/transparent-union-6.c: New. Added: trunk/gcc/testsuite/gcc.dg/transparent-union-6.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/87578] New: attribute transparent_union silently accepted but ignored on typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87578
Bug ID: 87578
Summary: attribute transparent_union silently accepted but
ignored on typedef
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC (in C mode) silently accepts but discards attribute transparent_union on a
typedef. The attribute handler is never invoked on the typedef (attributes is
null in decl_attributes when the typedef definition is being processed,
suggesting this is a general problem).
G++ diagnoses the typedef definition with -Wattributes. Clang diagnoses it in
both C and C++ modes as well, although with -Wignored-attributes:
x.c:13:31: warning: transparent_union attribute can only be applied to a union
definition; attribute ignored [-Wignored-attributes]
$ cat x.c && gcc -S -Wall -Wextra x.c
union __attribute__ ((transparent_union)) A
{
int *ip;
double *dp;
};
union B
{
int *ip;
double *dp;
};
typedef union __attribute__ ((transparent_union)) B TB; // silently accepted
void f (union A);
void g (TB);
void h (void)
{
f ((int*)0); // okay
f ((double*)0); // okay
g ((int*)0); // error
g ((double*)0); // error
}
x.c: In function ‘h’:
x.c:23:6: error: incompatible type for argument 1 of ‘g’
23 | g ((int*)0); // error
| ^~~
| |
| int *
x.c:16:9: note: expected ‘TB’ {aka ‘union B’} but argument is of type ‘int *’
16 | void g (TB);
| ^~
x.c:24:6: error: incompatible type for argument 1 of ‘g’
24 | g ((double*)0); // error
| ^~
| |
| double *
x.c:16:9: note: expected ‘TB’ {aka ‘union B’} but argument is of type ‘double
*’
16 | void g (TB);
| ^~
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 68510, which changed state. Bug 68510 Summary: [concepts] ICE: in gimplify_var_or_parm_decl, at gimplify.c:1827 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68510 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/68510] [concepts] ICE: in gimplify_var_or_parm_decl, at gimplify.c:1827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68510 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed by r232847.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #19 from Jonathan Wakely --- Fixed on trunk so far.
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 --- Comment #6 from Andi Kleen --- This breaks Linux kernel LTO builds. I currently have a workaround (disabling LTO for that file), but I don't think your "is not common" argument is valid.
[Bug fortran/87577] New: [9 regression] hundreds of fortran test case failures starting with revision r264990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87577 Bug ID: 87577 Summary: [9 regression] hundreds of fortran test case failures starting with revision r264990 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This revision is causing hundreds of test case failures. They all seem to be like this: Executing on host: /home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran1/../../gfortran -B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran1/../../ -B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never-O -std=f95 -fmax-errors=100 -S -o argument_checking_11.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran1/../../gfortran -B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran1/../../ -B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O -std=f95 -fmax-errors=100 -S -o argument_checking_11.s /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:134:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:135:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:139:15: Error: The upper bound in the last dimension must appear in the reference to the assumed size array 'c' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:141:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:142:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:144:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:145:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:148:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:149:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:150:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:151:15: Error: Fortran 2003: Scalar CHARACTER actual argument with array dummy argument 'a' at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:160:15: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:161:15: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:162:15: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:163:16: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:164:16: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:165:16: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:166:15: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:167:15: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:168:15: Error: Substring reference of nonscalar not permitted at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/argument_checking_11.f90:169:15: Error: Substring reference of nonscalar not permitted at (1)
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #18 from Jonathan Wakely --- Author: redi Date: Wed Oct 10 15:39:33 2018 New Revision: 265021 URL: https://gcc.gnu.org/viewcvs?rev=265021=gcc=rev Log: PR libstdc++/87544 limit max_size() to PTRDIFF_MAX / sizeof(T) The C++17 standard requires the default implementation for allocator_traits::max_size to return SIZE_MAX / sizeof(value_type). That causes GCC to warn because the value could be larger than can sensibly be passed to malloc. This patch changes the new_allocator and malloc_allocator max_size() members to use PTRDIFF_MAX instead of SIZE_MAX (and because they define it, the allocator_traits default isn't used). This also changes vector::max_size to impose a sensible limit using PTRDIFF_MAX for cases where the value from the allocator or allocator_traits is not sensible. PR libstdc++/87544 * include/bits/stl_vector.h (vector::_S_max_size): Limit size to PTRDIFF_MAX / sizeof(value_type). * include/ext/malloc_allocator.h (malloc_allocator::max_size): Likewise. * include/ext/new_allocator.h (new_allocator::max_size): Likewise. * testsuite/23_containers/vector/allocator/minimal.cc: Adjust expected value for max_size(). * testsuite/23_containers/vector/capacity/87544.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/capacity/87544.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/ext/malloc_allocator.h trunk/libstdc++-v3/include/ext/new_allocator.h trunk/libstdc++-v3/testsuite/23_containers/vector/allocator/minimal.cc
[Bug target/87573] [9 Regression] error: could not split insn since r264877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87573 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug target/87573] [9 Regression] error: could not split insn since r264877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87573 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Wed Oct 10 15:02:47 2018 New Revision: 265019 URL: https://gcc.gnu.org/viewcvs?rev=265019=gcc=rev Log: PR target/87573 * config/i386/mmx.md (const_vector 0 -> mem splitter): New splitter. testsuite/ChangeLog: PR target/87573 * gcc.target/i386/pr87573.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr87573.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677 --- Comment #5 from rguenther at suse dot de --- On Wed, 10 Oct 2018, ktkachov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677 > > ktkachov at gcc dot gnu.org changed: > >What|Removed |Added > > CC||ktkachov at gcc dot gnu.org > > --- Comment #3 from ktkachov at gcc dot gnu.org --- > GCC does disable some pattern recognition with > -fno-tree-loop-distribute-patterns, which is implied by -ffreestanding (used > by > the kernel). Wouldn't it be consistent to disable this pattern recognition in > that setup as well? popcount is not such a fundamental helper function like > e.g. DImode shifts, after all I am not against adding a new switch for this (not sure if we really should overload -fno-tree-loop-distribute-patterns with this since this will disable popcount recognition at anything below -O3).
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #4 from Alexander Monakov --- PR 87528 is also suggesting to avoid introducing popcount when it's going to be lowered to a libgcc call instead of a native instruction.
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #13 from Eric Botcazou --- > Forgive my naive question as I'm not too familiar with that part of the > compiler: why should the get_best_mem_extraction_insn be guarded with > reverse? I thought I'd just ad an if (reverse) if it succeeds and call > flip_storage_order there, likewise after the call to extract_bit_field_1 > below if successful. No, the numbering of bits depends on the endianness, i.e. you need to know the endianness of the source to do a correct extraction. For example, if you extract bit #2 - bit #9 of a structure in big-endian using HImode, then you cannot do it in little-endian and just swap the bytes afterwards (as a matter of fact, there is nothing to swap since the result is byte-sized). The LE extraction is: HImode load + HImode right_shift (2) whereas the BE extraction is: HImode load + HImode right_shift (6) The extv machinery cannot handle reverse SSO for the time being so the guard is still needed for it in the general case; on the contrary, extract_bit_field_1 can already and doesn't need an additional call to flip_storage_order. Of course, for specific bitfields, typically verifying simple_mem_bitfield_p, then you can extract in native order and do flip_storage_order on the result. In other words, the extv path can be used as you envision, but only for specific bitfields modeled on those accepted by simple_mem_bitfield_p, and then the call to flip_storage_order will indeed be needed.
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 --- Comment #11 from Wilco --- (In reply to Tobias Burnus from comment #10) > In my understanding, the problem is the following (of r254427): > Unconditionally generate a vtable for any module derived > type, as long as the standard is F2003 or later and it > is not a vtype or a PDT template. I'm not sure it's the same problem but the huge size increases I noticed are due to not optimizing zeroes from initializers, so we end up with huge rodata with only zeroes in it.
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- GCC does disable some pattern recognition with -fno-tree-loop-distribute-patterns, which is implied by -ffreestanding (used by the kernel). Wouldn't it be consistent to disable this pattern recognition in that setup as well? popcount is not such a fundamental helper function like e.g. DImode shifts, after all
[Bug c++/87576] Static analysis generating errors on branch never taken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87576 --- Comment #2 from Tom Mason --- Compiling and running the file works in clang, and the asserts pass.
[Bug c++/87576] Static analysis generating errors on branch never taken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87576 --- Comment #1 from Tom Mason --- Trying to compile the attached source file leads to gcc generating a memcpy out of the loop on line 134, then erroring because the generated memcpy overlaps. Indeed the regions do overlap, so if that is a problem, it should not replace the loop with a memcpy. It also generates a max object size exceeded error, which I don't understand? $ ~/gcc-8/bin/g++-8 -O3 -g -DDEBUG -D_DEBUG -Wno-array-bounds -Wall -Wextra -pedantic -Wno-unused-parameter -Werror -std=c++17 main.cpp In function ‘int main(int, char**)’: cc1plus: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 18446744073709551592 or more bytes at offsets 12 and 24 overlaps 9223372036854775761 bytes at offset -9223372036854775785 [-Werror=restrict] cc1plus: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ specified size between 18446744073709551592 and 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] cc1plus: all warnings being treated as errors Without -Wno-array-bounds, it will generate an out of bounds access error instead. This is another issue, as the branch containing this loop is never taken, so the out of bounds error should not be generated. [tom-debian] ~/test_scripts/gcc_bug > $ ~/gcc-8/bin/g++-8 -O3 -g -DDEBUG -D_DEBUG -Wall -Wextra -pedantic -Wno-unused-parameter -Werror -std=c++17 main.cpp main.cpp: In function ‘int main(int, char**)’: main.cpp:135:76: error: array subscript 6 is above array bounds of ‘int [5]’ [-Werror=array-bounds] this->smallData.arr[first + offset] = std::move(this->smallData.arr[last + offset]); ~~~^ cc1plus: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ pointer overflow between offset 12 and size [-24, 9223372036854775807] [-Werror=array-bounds] cc1plus: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ specified size between 18446744073709551592 and 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] cc1plus: all warnings being treated as errors
[Bug c++/87576] New: Static analysis generating errors on branch never taken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87576 Bug ID: 87576 Summary: Static analysis generating errors on branch never taken Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wheybags at wheybags dot com Target Milestone: --- Created attachment 44824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44824=edit source file exhibiting the bug
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 Martin Liška changed: What|Removed |Added Target Milestone|9.0 |--- --- Comment #5 from Martin Liška --- I consider label refs not so common for LTO, thus deferring for now...
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #12 from Thomas Preud'homme --- (In reply to Eric Botcazou from comment #11) > > Therefore unaligned access are handled by extract_bit_field. This in turns > > call extract_bit_field_1 and later extract_integral_bit_field where things > > are different between little endian and big endian. For little endian, it > > goes in the following if block: > > > > /* If OP0 is a memory, try copying it to a register and seeing if a > > cheap register alternative is available. */ > > if (MEM_P (op0) & !reverse) > > > > For big endian it continues and calls extract_fixed_bit_field. I'm wondering > > if an extra call to flip_storage_order when reverse is true would solve the > > issue. Need to understand better whe is it safe to call flip_storage_order. > > Where do you want to add a call to flip_storage_order exactly? The correct > thing to do would be to move the !reverse test from the top-level if to the > first inner if (in order to bypass only the extv business) and see what > happens next (and be prepared for adjusting adjust_bit_field_mem_for_reg to > reverse SSO). Forgive my naive question as I'm not too familiar with that part of the compiler: why should the get_best_mem_extraction_insn be guarded with reverse? I thought I'd just ad an if (reverse) if it succeeds and call flip_storage_order there, likewise after the call to extract_bit_field_1 below if successful.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 82807, which changed state. Bug 82807 Summary: [7/8/9 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug other/84613] [meta-bug] SPEC compiler performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84613 Bug 84613 depends on bug 82807, which changed state. Bug 82807 Summary: [7/8/9 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug target/82807] [7/8/9 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Martin Liška --- Looks gcc-8 and current trunk is back similarly fast as gcc-6. Thus I'm closing that.
[Bug fortran/87575] [9 Regression] compilation error for 465.tonto SPEC benchmark since r264990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87575 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- just confirmed... :/
[Bug fortran/87575] [9 Regression] compilation error for 465.tonto SPEC benchmark since r264990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87575 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-10-10 Known to work||8.2.0 Blocks||26163 Target Milestone|--- |9.0 Known to fail||9.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug fortran/87575] New: [9 Regression] compilation error for 465.tonto SPEC benchmark since r264990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87575 Bug ID: 87575 Summary: [9 Regression] compilation error for 465.tonto SPEC benchmark since r264990 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: burnus at gcc dot gnu.org Target Milestone: --- Since the mentioned revision I see: $ gfortran -c -o cif.fppized.o -Ofast -g -march=native -std=legacy cif.fppized.f90 cif.fppized.f90:792:26: 792 |call ensure_(tonto,all(ID(:)(1:1)=="_"),"CIF:find_looped_items ... ID list does not have a looped datum") | 1 Error: Substring reference of nonscalar not permitted at (1)
[Bug target/87565] suboptimal memory-indirect tailcalls on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan --- (In reply to Alexander Monakov from comment #2) > PLT trampolines all end with 'ldr pc, [ip, xxx]!', so do all calls via PLT > suffer from poor branch prediction of such indirect jumps? IIRC you still need to use that in the PLT trampoline for folks to use Linux like userland on strongarm which has a small user constituency still.
[Bug target/87572] ICE in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87572 --- Comment #1 from H.J. Lu --- Created attachment 44823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44823=edit A patch
[Bug target/82227] ARM thumb inefficient tailcall return sequence (multiple pops)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82227
Ramana Radhakrishnan changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-10
CC||ramana at gcc dot gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Ramana Radhakrishnan ---
Confirmed.(In reply to Peter Cordes from comment #0)
> int ext();
> int tailcall_external() { return ext(); }
> // https://godbolt.org/g/W43fxw
>
> gcc6.3 -Os -mthumb
>
> push{r4, lr}
> bl ext
> pop {r4}
> pop {r1}# two separate pop instructions isn't optimal
> bx r1
>
> gcc6.3 -Os -mthumb -mno-thumb-interwork
>
> push{r4, lr}
> bl ext
> pop {r4, pc}
>
> A 16-bit thumb pop instruction can only pop "lo" registers and PC, not back
> into LR. That's why it can't pop {r4, lr} / bx lr like it does in -marm
> mode.
>
> But there is a more efficient way:
>
> pop {r1, r2}
> bx r2
Yep.
>
> We never needed a call-preserved register; r4 was pushed only to keep the
> stack aligned. So as long as we have 2 call-clobbered regs available, we
> can pop the padding that came from r4, and pop the saved lr, both into
> call-clobbered regs.
>
> If we did need a call-preserved register for anything, two separate pop
> instructions are presumably better than any combination of pop-multiple and
> reg-reg moves.
>
>
>
> This also happens with two identical functions with different names, with
> -Os. One compiles into a call to the other, done exactly the same way as to
> an external function. (See the godbolt link above).
>
> In that case, I don't understand why we can't just tail-call with a `b`
> instruction (like we get with -marm). Both functions are compiled to Thumb2
> code, so we can jump to the other and let it do an interworking return,
> right? Especially with -mno-thumb-interwork, I don't understand why
> tail-calls aren't optimized to a jump.
You need to read up on the various levels of the architecture and the command
line options. Thumb2 doesn't show up at the default level of the architecture
and needs atleast -mthumb -march=armv6t2 . Try reading this for a beginners
guide to the architecture.
https://community.arm.com/tools/b/blog/posts/arm-cortex-a-processors-and-gcc-command-lines?CommentSortBy=CreatedDate=Descending
We don't tail call in general for Thumb1 which is what your options imply
because the branches are just too short (encoded in 16bits ) IIRC.
>
> (I'm not an expert on ARM / Thumb stuff, so there might be a reason I'm
> missing.)
[Bug lto/87574] [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org
[Bug lto/87574] [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-10 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- Egad. Reducing the compile-only testcase...
[Bug target/87550] Intrinsics for rdpmc (__rdpmc, __builtin_ia32_rdpmc) are interpreted as pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87550 --- Comment #4 from Vlad --- Great! Thanks you very much.
[Bug sanitizer/86755] [ASAN] Libasan failed to be build for arm with -mthumb and -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86755 --- Comment #3 from Denis Khalikov --- The fix was accepted to llvm https://reviews.llvm.org/D50180. I hope the patch will be applied soon.
[Bug c++/87410] internal compiler error: in fold_convert_loc, at fold-const.c:2530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87410 --- Comment #2 from Martin Liška --- Created attachment 44822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44822=edit Reduced test-case
[Bug bootstrap/84199] Error building gcc 7.3.0 on Odroid XU4 (ARM, Ubuntu): cannot load liblto_plugin.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84199 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Ramana Radhakrishnan --- I don't think anyone is going to go fetch an odroid for this - it sounds like a problem in your environment as many folks are building / able to build gcc 7.x on an armhf ubuntu system. Looking at the build log - try with appropriate --with-arch --with-float and --with-fpu options to do your build. In general this on armhf is --with-arch=armv7-a --with-fpu=neon --with-float=hard though you could get better options specifically for the odroid.
[Bug sanitizer/86755] [ASAN] Libasan failed to be build for arm with -mthumb and -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86755 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-10 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan --- Confirmed.
[Bug middle-end/86815] [8/9 regression] ICE on valid code on armhf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86815 --- Comment #9 from Ramana Radhakrishnan --- (In reply to Martin Liška from comment #8) > Unfortunately I can't reproduce that with cross compiler. Me neither today. Gianfranco , could you check if you are running out of memory on the machine that you are doing this on with GCC-8 ? Is there a chance that the OOM killer came along when building this file on the native arm machine that you were running this on ? I've tried running this with stock gcc 8 in debian on an armhf docker image and will try building something up later today on my machine , but it may be worth double checking that something like an OOM killer or swap isn't what's throttling the build here.
[Bug target/87550] Intrinsics for rdpmc (__rdpmc, __builtin_ia32_rdpmc) are interpreted as pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87550 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Oct 10 09:28:26 2018 New Revision: 265007 URL: https://gcc.gnu.org/viewcvs?rev=265007=gcc=rev Log: PR target/87550 * config/i386/i386-builtin.def (IX86_BUILTIN_RDPMC): Move from args set to special_args set. * gcc.target/i386/pr87550.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr87550.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-builtin.def trunk/gcc/testsuite/ChangeLog
[Bug target/87573] [9 Regression] error: could not split insn since r264877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87573 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug lto/87574] [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574 --- Comment #1 from Martin Liška --- Created attachment 44821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44821=edit Different test-case One different test-case: $ g++ thread2.ii -O2 -g ... during IPA pass: inline thread.ii: In member function ‘virtual nsresult mozilla::LazyIdleThread::_ZThn24_N7mozilla14LazyIdleThread17OnDispatchedEventEv()’: thread.ii:211364:20: internal compiler error: in dwarf2out_abstract_function, at dwarf2out.c:22468 211364 | virtual nsresult OnDispatchedEvent(void) override; virtual nsresult OnProcessNextEvent(nsIThreadInternal *thread, bool mayWait) override; virtual nsresult AfterProcessNextEvent(nsIThreadInternal *thread, bool eventWasProcessed) override; |^ 0xe1ef5e dwarf2out_abstract_function /home/marxin/Programming/gcc/gcc/dwarf2out.c:22468 0x14c38b8 tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*) /home/marxin/Programming/gcc/gcc/tree-inline.c:5804 0x21661df save_inline_function_body /home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:585 0x21663b0 inline_transform(cgraph_node*) /home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:644 0x127fc45 execute_one_ipa_transform_pass /home/marxin/Programming/gcc/gcc/passes.c:2170 0x127fdcf execute_all_ipa_transforms() /home/marxin/Programming/gcc/gcc/passes.c:2212 0xd68808 cgraph_node::expand() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2181 0xd68e6c expand_all_functions /home/marxin/Programming/gcc/gcc/cgraphunit.c:2326 0xd699cf symbol_table::compile() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2677 0xd69e08 symbol_table::finalize_compilation_unit() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2855
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- > Therefore unaligned access are handled by extract_bit_field. This in turns > call extract_bit_field_1 and later extract_integral_bit_field where things > are different between little endian and big endian. For little endian, it > goes in the following if block: > > /* If OP0 is a memory, try copying it to a register and seeing if a > cheap register alternative is available. */ > if (MEM_P (op0) & !reverse) > > For big endian it continues and calls extract_fixed_bit_field. I'm wondering > if an extra call to flip_storage_order when reverse is true would solve the > issue. Need to understand better whe is it safe to call flip_storage_order. Where do you want to add a call to flip_storage_order exactly? The correct thing to do would be to move the !reverse test from the top-level if to the first inner if (in order to bypass only the extv business) and see what happens next (and be prepared for adjusting adjust_bit_field_mem_for_reg to reverse SSO).
[Bug lto/87574] [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574 Martin Liška changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Target Milestone|--- |9.0
[Bug lto/87574] New: [9 Regression] ICE in add_data_member_location_attribute at gcc/gcc/dwarf2out.c:19226 since r264943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87574
Bug ID: 87574
Summary: [9 Regression] ICE in
add_data_member_location_attribute at
gcc/gcc/dwarf2out.c:19226 since r264943
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I see following ICE:
$ cat ice.ii
class a {
public:
virtual ~a();
};
class b : virtual a {};
struct c : b, a {};
void fn1() { c(); }
$ g++ ice.ii -flto=8 -shared -O2 -g -fPIC
ice.ii:6:8: warning: direct base ‘a’ inaccessible in ‘c’ due to ambiguity
6 | struct c : b, a {};
|^
during RTL pass: final
ice.ii: In member function ‘_ZThn8_N1cD0Ev’:
ice.ii:6:8: internal compiler error: in tree_to_shwi, at tree.c:6839
6 | struct c : b, a {};
|^
0x1404536 tree_to_shwi(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:6839
0xa23471 add_data_member_location_attribute
/home/marxin/Programming/gcc/gcc/dwarf2out.c:19226
0xa324fc gen_inheritance_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:24494
0xa33838 gen_member_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:24965
0xa34220 gen_struct_or_union_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25138
0xa34d01 gen_tagged_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25339
0xa348a5 gen_typedef_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25253
0xa3795b gen_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:26223
0xa350a8 gen_type_die_with_usage
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25404
0xa359f5 gen_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25588
0xa11025 modified_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:13357
0xa29a61 add_type_attribute
/home/marxin/Programming/gcc/gcc/dwarf2out.c:21521
0xa324e5 gen_inheritance_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:24492
0xa33838 gen_member_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:24965
0xa34220 gen_struct_or_union_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25138
0xa34d01 gen_tagged_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25339
0xa348a5 gen_typedef_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25253
0xa3795b gen_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:26223
0xa350a8 gen_type_die_with_usage
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25404
0xa359f5 gen_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25588
[Bug c/87286] ICE on vectors of enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87286 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Oct 10 09:03:40 2018 New Revision: 265006 URL: https://gcc.gnu.org/viewcvs?rev=265006=gcc=rev Log: PR c/87286 * gcc.dg/pr87286.c: Add -Wno-psabi to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr87286.c
[Bug target/87573] [9 Regression] error: could not split insn since r264877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87573 --- Comment #2 from Uroš Bizjak --- Patch in testing: --cut here-- diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md index 539671ce4be5..e60b2296ab6b 100644 --- a/gcc/config/i386/mmx.md +++ b/gcc/config/i386/mmx.md @@ -217,7 +217,14 @@ (define_split [(set (match_operand:MMXMODE 0 "nonimmediate_gr_operand") -(match_operand:MMXMODE 1 "general_gr_operand"))] +(match_operand:MMXMODE 1 "nonimmediate_gr_operand"))] + "!TARGET_64BIT && reload_completed" + [(const_int 0)] + "ix86_split_long_move (operands); DONE;") + +(define_split + [(set (match_operand:MMXMODE 0 "nonimmediate_gr_operand") +(match_operand:MMXMODE 1 "const0_operand"))] "!TARGET_64BIT && reload_completed" [(const_int 0)] "ix86_split_long_move (operands); DONE;") --cut here--
[Bug middle-end/86815] [8/9 regression] ICE on valid code on armhf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86815 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- Unfortunately I can't reproduce that with cross compiler.
[Bug c++/84940] [7 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|7.4 |8.3 Summary|[7/8/9 Regression] internal |[7 Regression] internal |compiler error: in |compiler error: in |build_value_init_noctor, at |build_value_init_noctor, at |cp/init.c:465 |cp/init.c:465 --- Comment #8 from Paolo Carlini --- Fixed trunk and 8.3.0.
[Bug c++/84940] [7/8/9 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940 --- Comment #7 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 10 08:16:37 2018 New Revision: 265005 URL: https://gcc.gnu.org/viewcvs?rev=265005=gcc=rev Log: /cp 2018-10-10 Paolo Carlini PR c++/84940 * semantics.c (finish_unary_op_expr): Check return value of build_x_unary_op for error_mark_node. /testsuite 2018-10-10 Paolo Carlini PR c++/84940 * g++.dg/expr/unary4.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/expr/unary4.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/semantics.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/85114] [6/7 Regression] -fstack-check causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85114
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #9 from Martin Liška ---
Reduced test-case:
$ cat Unified_cpp_layout_generic1.ii
class c {
int *b;
};
class B {
char d;
};
class e {
public:
virtual B f();
struct h {
e *g;
e *i;
void j() { l = g->f(); }
int k;
int n;
B l;
c m;
};
struct o : h {
bool p;
};
};
class G : e {
int q();
};
int G::q() {
o a;
for (;;)
a.j();
}
[Bug c/87286] ICE on vectors of enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87286 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698 --- Comment #8 from Martin Liška --- (In reply to Pat Haugen from comment #7) > I also see the loop now being aligned when I apply your patch. > > srdi 10,10,2 > mtctr 10 > .p2align 4,,15 > .L6: > ld 9,0(11) > ld 8,0(4) Great, patch has been tested and is sitting here: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00501.html
[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698 Martin Liška changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/87573] [9 Regression] error: could not split insn since r264877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87573 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #1 from Uroš Bizjak --- I was expecting a couple of these errors, since MMX constant moves were effectively disabled before the patch. Looking into it.
[Bug target/87573] [9 Regression] error: could not split insn since r264877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87573 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-10 Known to work||8.2.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug target/87573] New: [9 Regression] error: could not split insn since r264877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87573
Bug ID: 87573
Summary: [9 Regression] error: could not split insn since
r264877
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
CC: uros at gcc dot gnu.org
Target Milestone: ---
Following started to ICE:
$ cat ice2.ii
typedef char b __attribute__((vector_size(8)));
char c;
struct d {
b e;
};
void f() {
d a;
*(b *)c = a.e;
}
$ g++ -march=winchip2 -O1 -m32 -S ice2.ii -c
ice2.ii: In function ‘void f()’:
ice2.ii:8:9: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
8 | *(b *)c = a.e;
| ^
ice2.ii:9:1: error: could not split insn
9 | }
| ^
(insn 6 11 14 2 (set (mem:V8QI (reg:SI 0 ax [orig:87 c ] [87]) [0 *_3+0 S8
A64])
(const_vector:V8QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])) "ice2.ii":8:11 1076 {*movv8qi_internal}
(expr_list:REG_DEAD (reg:SI 0 ax [orig:87 c ] [87])
(nil)))
during RTL pass: final
ice2.ii:9:1: internal compiler error: in final_scan_insn_1, at final.c:3070
0x133f6a7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0xee5585 final_scan_insn_1
/home/marxin/Programming/gcc/gcc/final.c:3070
0xee58dc final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/marxin/Programming/gcc/gcc/final.c:3149
0xee3556 final_1
/home/marxin/Programming/gcc/gcc/final.c:2019
0xee8895 rest_of_handle_final
/home/marxin/Programming/gcc/gcc/final.c:4649
0xee8bbe execute
/home/marxin/Programming/gcc/gcc/final.c:4723
[Bug target/87572] New: ICE in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87572
Bug ID: 87572
Summary: ICE in emit_move_insn, at expr.c:3722
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: uros at gcc dot gnu.org
Target Milestone: ---
It's very old ICE:
$ gcc -mavx512ifma -c -mno-sse2 -S ice.i -c
ice.i: In function ‘f’:
ice.i:4:1: warning: AVX512F vector return without AVX512F enabled changes the
ABI [-Wpsabi]
a f() { return __builtin_ia32_vpmadd52huq512_maskz(c, d, e, b); }
^
during RTL pass: expand
ice.i:4:16: internal compiler error: in emit_move_insn, at expr.c:3722
a f() { return __builtin_ia32_vpmadd52huq512_maskz(c, d, e, b); }
^~~
0x76996fea __libc_start_main
../csu/libc-start.c:308
$ cat ice.i
typedef long long a __attribute__((__vector_size__(64)));
int b;
a c, d, e;
a f() { return __builtin_ia32_vpmadd52huq512_maskz(c, d, e, b); }
[Bug c++/71283] Inconsistent location for C++ warning options in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Target Milestone|--- |9.0
[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561 --- Comment #6 from Richard Biener --- Created attachment 44820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44820=edit reduced testcase Reduced testcase.
[Bug c++/84191] [7 Regression] Compiler ICEs when trying to resolve impossible arithmetic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84191 --- Comment #5 from Martin Liška --- Created attachment 44819 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44819=edit reduced test-case
[Bug c++/87571] [8/9 Regression] ICE in friend_accessible_p, accessing protected member of template friend inside template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87571 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |8.3
