[Bug target/88473] AVX512: constant folding on mask does not remove unnecessary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88473 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-14 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed.
[Bug rtl-optimization/88253] Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253 Segher Boessenkool changed: What|Removed |Added Target|avr |avr-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-14 CC||segher at gcc dot gnu.org Host|Macos, Windows | Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- Mine. I have a patch.
[Bug c++/88468] Arduino: 1.8.8 (Windows 10) internal compiler error , segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88468 Richard Biener changed: What|Removed |Added Target||avr Status|UNCONFIRMED |WAITING Last reconfirmed||2018-12-14 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Please provide preprocessed source as a testcase. Note that GCC 5 is no longer supported, please update to at least GCC 7.
[Bug target/88469] [7/8/9 regression] AAPCS - Struct with 64-bit bitfield may be passed in wrong registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 Richard Biener changed: What|Removed |Added Keywords||ABI Target Milestone|--- |7.5
[Bug c++/88493] New: Inconsistent error messages for unknown types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88493
Bug ID: 88493
Summary: Inconsistent error messages for unknown types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
When compiling:
8<8<8<
struct Foo;
struct Bar
{
explicit Bar(Fooo* foo_) :
m_foo{foo_}
{
}
void Baz(Fooo* foo_);
Fooo* m_foo;
};
8<8<8<
Foo is forward declared, Fooo is not declared/defined, simulating a typo.
$ g++-8.2.1 -Wall -c 20181213-bad_type_name_diag.cpp
20181213-bad_type_name_diag.cpp:5:19: error: expected ‘)’ before ‘*’ token
explicit Bar(Fooo* foo_) :
~^
)
20181213-bad_type_name_diag.cpp:7:2: error: expected unqualified-id before ‘{’
token
{
^
20181213-bad_type_name_diag.cpp:10:11: error: ‘Fooo’ has not been declared
void Baz(Fooo* foo_);
^~~~
20181213-bad_type_name_diag.cpp:12:2: error: ‘Fooo’ does not name a type; did
you mean ‘Foo’?
Fooo* m_foo;
^~~~
Foo
The first error is not really helping, the second one is a cascade from that.
The third one is OK, but there is no suggestion. The fourth one is the most
useful.
For the three cases of Foo vs Fooo mismatch, three different error messages was
printed.
If I follow the suggestion of the first error msg, and put a ): after Fooo and
comment out the rest of the line:
$ g++-8.2.1 -Wall -c 20181213-bad_type_name_diag.cpp
20181213-bad_type_name_diag.cpp:5:19: error: function definition does not
declare parameters
explicit Bar(Fooo) : //* foo_) :
^
However, mentioning only the type of the parameter and not name it should be
accepted. Then, report an error because Fooo is unknown, possibly suggesting
Foo instead.
GCC 6/7/8/9 report the same errors, with minor formatting/coloring differences.
$ g++-8.2.1 -v
Using built-in specs.
COLLECT_GCC=g++-8.2.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure CC=gcc-8.2.1 CXX=g++-8.2.1
--enable-languages=c,c++ --disable-multilib --program-suffix=-8.2.1
--disable-bootstrap CFLAGS='-O2 -march=native -mtune=native' CXXFLAGS='-O2
-march=native -mtune=native'
Thread model: posix
gcc version 8.2.1 20181213 (GCC)
$ g++-9.0.0 -v
Using built-in specs.
COLLECT_GCC=g++-9.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure CC=gcc-8.2.1 CXX=g++-8.2.1
--enable-languages=c,c++ --disable-multilib --program-suffix=-9.0.0
--disable-bootstrap CFLAGS='-O2 -march=native -mtune=native' CXXFLAGS='-O2
-march=native -mtune=native'
Thread model: posix
gcc version 9.0.0 20181213 (experimental) (GCC)
[Bug rtl-optimization/88311] [9 Regression] mlongcall indirections are optimised away (for binutils versions that don't support AS_PLTSEQ)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88311 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #11 from Alan Modra --- Fixed.
[Bug testsuite/88491] new test case allocfail.sh in r267054 fails if dash is the default shell (/bin/sh)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88491 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #2 from Tom de Vries --- Patch fixing test-case committed, marking resolved-fixed.
[Bug testsuite/88491] new test case allocfail.sh in r267054 fails if dash is the default shell (/bin/sh)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88491 --- Comment #1 from Tom de Vries --- Author: vries Date: Fri Dec 14 09:43:41 2018 New Revision: 267127 URL: https://gcc.gnu.org/viewcvs?rev=267127&root=gcc&view=rev Log: [testsuite] Remove bashism from libbacktrace/allocfail.sh Test-case libbacktrace/allocfail.sh contains bashism "set -o pipefail", which makes the script fail on ubuntu 18.04, which links /bin/sh to /bin/dash. Fix this by removing the "set -o pipefail". Tested by running the test-case with dash on x86_64-linux. 2018-12-14 Tom de Vries PR testsuite/88491 * allocfail.sh: Remove "set -o pipefail". Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/allocfail.sh
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-14 Ever confirmed|0 |1 --- Comment #7 from Ramana Radhakrishnan --- Confirmed.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #6 from Ramana Radhakrishnan ---
(In reply to Segher Boessenkool from comment #5)
> The first one just needs an xfail. I don't know if it should be *-*-* there
> or only arm*-*-* should be added.
>
> The other two need some debugging by someone who knows the target and/or
> these tests.
for the addr-modes-float.c case there are additional vmov's being generated and
thus is certainly a regression.
--- 8.s 2018-12-14 09:41:04.367843079 +
+++ addr-modes-float.s 2018-12-14 09:40:39.907980812 +
@@ -139,10 +139,13 @@
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
+ vmovq8, q0 @ ti
mov r3, r0
+ vmovq9, q1 @ ti
add r0, r0, #48
- vst3.8 {d0, d2, d4}, [r3]!
- vst3.8 {d1, d3, d5}, [r3]
+ vmovq10, q2 @ ti
+ vst3.8 {d16, d18, d20}, [r3]!
+ vst3.8 {d17, d19, d21}, [r3]
[Bug target/88013] can't vectorize rgb to grayscale conversion code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-14 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Ramana Radhakrishnan --- > vshr.u16q9, q9, #8 > vshr.u16q8, q8, #8 > vmovn.i16 d20, q9 > vmovn.i16 d21, q8 Isn't that "just" a missing combine pattern to get us vshrn in both backends ? Ramana
[Bug d/88462] All D execution tests FAIL on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Iain Buclaw --- >> Trying to load 32 bits from a non-4 byte aligned pointer is a no-no on a >> strict-alignment target like sparc... > > I saw that on HPPA as well when testing under QEMU. > > ModuleInfo is a variably-sized packed struct - what is in the variable part is > determined by the value of _flags. > > This is compiler generated, so I'll have a look into giving it proper > alignment > on the compiler side. An alternative might be to leave the on-disk representation as is and only handle alignment on input/startup. However, that's probably a bad tradeoff of some on-disk space savings vs. the runtime cost at every startup.
[Bug tree-optimization/88492] SLP optimization generates ugly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88492 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-14 CC||ktkachov at gcc dot gnu.org Blocks||53947 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Don't know if the vectoriser can do anything better here, but we if not the cost models should be disabling it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- .
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 --- Comment #7 from Zdenek Sojka --- Please feel free to close this one; I might open another PR if I trigger this ICE again.
[Bug target/88224] Wrong Cortex-R7 and Cortex-R8 FPU configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88224 --- Comment #3 from avieira at gcc dot gnu.org --- Author: avieira Date: Fri Dec 14 09:04:24 2018 New Revision: 267124 URL: https://gcc.gnu.org/viewcvs?rev=267124&root=gcc&view=rev Log: PR target/88224: Fix FPU configuration of Cortex-R7 and Cortex-R8 gcc/ 2018-12-14 Andre Vieira Backport from mainline PR target/88224 * config/arm/arm-cpus.in (armv7-r): Add FP16conv configurations. (cortex-r7, cortex-r8): Update fpu and add new configuration. * doc/invoke.texi (armv7-r): Add two new vfp options. (nofp.dp): Add cortex-r7 and cortex-r8 to the list of targets that support this option. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/arm/arm-cpus.in branches/gcc-8-branch/gcc/doc/invoke.texi
[Bug rtl-optimization/88311] [9 Regression] mlongcall indirections are optimised away (for binutils versions that don't support AS_PLTSEQ)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88311 --- Comment #10 from Alan Modra --- Author: amodra Date: Fri Dec 14 09:03:50 2018 New Revision: 267123 URL: https://gcc.gnu.org/viewcvs?rev=267123&root=gcc&view=rev Log: [RS6000] PR88311, mlongcall indirections are optimised away Masking CALL_LONG from the cookie was done in order to simplify and correct length attribute calculations for indirect calls at one point in my call series tidy when the indirect patterns used alternatives "0,n" on the cookie operand. (Leaving the CALL_LONG in place calculated the wrong length for long calls without fp args.) This is no longer necessary now that the indirect sysv call patterns explicitly test for the fp arg bits in their length attribute expressions. And without the CALL_LONG to disable insns like call_value_local_svsv, combine merrily replaces the indirect long call sequence with a direct call. As it should. This patch reinstates the CALL_LONG bit. PR rtl-optimization/88311 * config/rs6000/rs6000.c (rs6000_call_sysv): Do not mask cookie. (rs6000_sibcall_sysv): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481 Heinrich Seebauer changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Heinrich Seebauer --- Alexander, you are right, it is only strange behaviour. Using -O1 drops the 'then' clause, but the results are the same, if one takes a broader view. The program deals with controlling schedules using actual time. Each test run has different input values (current UTC time). I set up a situation where I was able to control system time, and the outcomes were consistent, either using -O0 oe -O1. What confused me was the fact that -O2/-Os did NOT drop the then clause. So -O2 ist not just optimizing the -O1 outcome, but different from the beginning of the optimizer pass. I apologize for not getting this point quickly. Thank you very much for your support and your work for the commuinty, kind regards Heinrich
[Bug testsuite/88454] [9 regression] test case gcc.dg/tree-ssa/split-path-5.c fails after r266971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88454 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 --- Comment #6 from Jakub Jelinek --- #c0 got fixed or made latent with r235905. The #c4 testcase went latent with r249450 (though no idea why it hasn't been filed separately). In any case, not sure if it is worth keeping this open when it is either latent or fixed on the trunk.
[Bug tree-optimization/88280] missing folding of logical and bitwise AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88280 --- Comment #3 from Jakub Jelinek --- (In reply to Richard Biener from comment #1) > Confirmed. g and h end up like this before RTL expansion (initial folding > produces this): > > j_6 = i_4(D) & a_5(D); > _1 = i_4(D) != 0; > _2 = j_6 != 0; > _3 = _1 & _2; > _7 = (int) _3; > return _7; > > and for e we do not combine the i != 0 check. > >[local count: 1073741824]: > if (i_3(D) != 0) > goto ; [50.00%] > else > goto ; [50.00%] > >[local count: 536870913]: > _1 = i_3(D) & a_4(D); > _6 = _1 != 0; > _7 = (int) _6; > >[local count: 1073741824]: > # iftmp.0_2 = PHI <_7(3), i_3(D)(2)> > return iftmp.0_2; Yeah, with f we are just lucky that (i & a) != 0 test is in a different basic block and dominates the i != 0 test; EVRP then adds assertions from that (i & a) != 0 that i != 0 as well as a != 0 and optimizes the second redundant check out. For g and h we could in theory handle that through some match.pd pattern, but dunno if it wouldn't be way too much specialized. If we wanted to do something about e, it would need to be done in reassoc range handling, but again, not really sure how often it would trigger on real-world code.
[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Fri Dec 14 08:29:34 2018 New Revision: 267122 URL: https://gcc.gnu.org/viewcvs?rev=267122&root=gcc&view=rev Log: match_asm_constraints: Use copy_rtx where needed (PR88001) The new insn here (temporarily) illegally shares RTL. This fixes it. PR rtl-optimization/88001 * function.c (match_asm_constraints_1): Don't invalidly share RTL. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
