[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657 --- Comment #4 from Martin Liška --- (In reply to Jakub Jelinek from comment #3) > As I said earlier, the patch is IMHO wrong and instead ARM/AArch64 should > implement efficient mempcpy in the library. > If not, we should have a target hook whether the target has sane mempcpy or > not and use it at least for cases like this, where using it will allow > tail-calling it, while using memcpy precludes that. And then XFAIL the test > on targets with bad mempcpy implementation. Yes, I'm planning to come up with such target hook.
[Bug c++/83796] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796 Michael Johnson changed: What|Removed |Added Version|5.4.0 |7.2.0 --- Comment #1 from Michael Johnson --- Correctly won't compile on MSVC and Clang, erroneously compiles from gcc 4.7.3 onwards Godbolt: https://godbolt.org/g/EuR2cy I think may be caused by change: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/call.c?r1=194820&r2=194819&pathrev=194820&diff_format=f https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325
[Bug ipa/83054] [8 Regression] ICE in operator>, at profile-count.h:823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83054 --- Comment #3 from Martin Liška --- Author: marxin Date: Fri Jan 12 08:59:52 2018 New Revision: 256566 URL: https://gcc.gnu.org/viewcvs?rev=256566&root=gcc&view=rev Log: Initialize type_warnings::dyn_count with a default value (PR ipa/83054). 2018-01-12 Martin Liska PR ipa/83054 * ipa-devirt.c (final_warning_record::grow_type_warnings): New function. (possible_polymorphic_call_targets): Use it. (ipa_devirt): Likewise. 2018-01-12 Martin Liska PR ipa/83054 * g++.dg/warn/pr83054.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/pr83054.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/83054] [8 Regression] ICE in operator>, at profile-count.h:823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83054 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug target/83812] New: nvptx-run: error getting kernel result: operation not supported on global/shared address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83812 Bug ID: 83812 Summary: nvptx-run: error getting kernel result: operation not supported on global/shared address space Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- When running make check for an nvptx build (with newlib sources linked in), we get: ... build-gcc/nvptx-none/libgomp/testsuite/libgomp.sum build-gcc/nvptx-none/mgomp/newlib/testsuite/newlib.sum build-gcc/nvptx-none/newlib/testsuite/newlib.sum build-gcc/gcc/testsuite/g++/g++.sum build-gcc/gcc/testsuite/gfortran/gfortran.sum build-gcc/gcc/testsuite/gcc/gcc.sum ... A bit surprising is the libgomp testsuite. [ Note: this is not testing a config of a host with nvptx accelerator, this is testing nvptx as host using the nvptx-run tool. ] The test results are not good: ... === libgomp Summary === # of expected passes272 # of unexpected failures2081 # of unresolved testcases 2043 # of unsupported tests 270 ... Mostly test-cases fail to build due to missing functions. However, when we look at tests that have been executed, we see a different picture: ... $ grep -c ^PASS:.*execution build-gcc/nvptx-none/libgomp/testsuite/libgomp.sum 106 $ grep -c ^FAIL:.*execution build-gcc/nvptx-none/libgomp/testsuite/libgomp.sum 31 ... The failures are (note: libgomp.c/pr64824.c contains omp atomic capture): ... FAIL: libgomp.c/pr64824.c execution test FAIL: libgomp.fortran/omp_atomic1.f90 -O0 execution test FAIL: libgomp.fortran/omp_atomic1.f90 -O1 execution test FAIL: libgomp.fortran/omp_atomic1.f90 -O2 execution test FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -g execution test FAIL: libgomp.fortran/omp_atomic1.f90 -Os execution test FAIL: libgomp.fortran/omp_atomic2.f90 -O0 execution test FAIL: libgomp.fortran/omp_atomic2.f90 -O1 execution test FAIL: libgomp.fortran/omp_atomic2.f90 -O2 execution test FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -g execution test FAIL: libgomp.fortran/omp_atomic2.f90 -Os execution test FAIL: libgomp.fortran/omp_atomic3.f90 -O0 execution test FAIL: libgomp.fortran/omp_atomic3.f90 -O1 execution test FAIL: libgomp.fortran/omp_atomic3.f90 -O2 execution test FAIL: libgomp.fortran/omp_atomic3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/omp_atomic3.f90 -O3 -g execution test FAIL: libgomp.fortran/omp_atomic3.f90 -Os execution test FAIL: libgomp.fortran/omp_atomic4.f90 -O0 execution test FAIL: libgomp.fortran/omp_atomic4.f90 -O1 execution test FAIL: libgomp.fortran/omp_atomic4.f90 -O2 execution test FAIL: libgomp.fortran/omp_atomic4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/omp_atomic4.f90 -O3 -g execution test FAIL: libgomp.fortran/omp_atomic4.f90 -Os execution test FAIL: libgomp.fortran/omp_atomic5.f90 -O0 execution test FAIL: libgomp.fortran/omp_atomic5.f90 -O1 execution test FAIL: libgomp.fortran/omp_atomic5.f90 -O2 execution test FAIL: libgomp.fortran/omp_atomic5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/omp_atomic5.f90 -O3 -g execution test FAIL: libgomp.fortran/omp_atomic5.f90 -Os execution test ... Looking in more detail at libgomp.c/pr64824.c: ... nvptx-run: error getting kernel result: operation not supported on global/shared address space (CUDA_ERROR_INVALID_ADDRESS_SPACE, 717) FAIL: libgomp.c/pr64824.c execution test ... The rest of the test-cases fails with the same error. I see the same error only once gcc/g++/gfortran testing: ... PASS: gfortran.dg/coarray/atomic_2.f90 -fcoarray=single -O2 (test for excess errors) spawn nvptx-none-run ./atomic_2.exe^M nvptx-run: error getting kernel result: operation not supported on global/shared address space (CUDA_ERROR_INVALID_ADDRESS_SPACE, 717)^M FAIL: gfortran.dg/coarray/atomic_2.f90 -fcoarray=single -O2 execution test ...
[Bug debug/83765] LTO bootstrap with Ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765 --- Comment #6 from Pierre-Marie de Rodat --- (In reply to Eric Botcazou from comment #4) > We have been crossing fingers about that for some time. ;-) CCing the > expert. Calling me “expert” is a bit far fetched: I never worked with LTO, and I already have trouble understand what’s going on in dwarf2out after optimizations. ;-) I’m relieved that Richard’s patch seems to have fixed the issue!
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
--- Comment #13 from Richard Biener ---
So r224161 (hey Aldy!) caused this bogus DW_AT_abstract_origin and
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 255167)
+++ gcc/dwarf2out.c (working copy)
@@ -21231,10 +21231,8 @@ gen_variable_die (tree decl, tree origin
{
/* If we will be creating an inlined instance, we need a
new DIE that will get annotated with
-DW_AT_abstract_origin. Clear things so we can get a
-new DIE. */
+DW_AT_abstract_origin. */
gcc_assert (!DECL_ABSTRACT_P (decl));
- old_die = NULL;
}
else
{
fixes that (but not the guality FAIL).
[Bug libquadmath/83800] [libquadmath] M_SQRT2q & sqrtq(2.0Q) off by one ULP ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Jakub Jelinek --- I think only the double routines in glibc guarantee 0.5ulp precise results, libquadmath is based on the quad long double code in glibc generally and certainly doesn't have such guarantees. I think the sqrtq isn't even based on that, and just does an approximation using sqrt or sqrtl and 1-2 Newton iterations. From what you've said, it isn't even off by whole 1ulp, but something in between 0.5ulp and 1ulp.
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #34 from Rainer Orth --- Author: ro Date: Fri Jan 12 09:52:53 2018 New Revision: 256568 URL: https://gcc.gnu.org/viewcvs?rev=256568&root=gcc&view=rev Log: Link with correct values-*.o files on Solaris (PR target/40411) gcc/testsuite: PR libfortran/67412 * gfortran.dg/execute_command_line_2.f90: Remove dg-xfail-run-if on *-*-solaris2.10. libstdc++-v3: PR libstdc++/64054 * testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc: Remove dg-xfail-run-if. gcc: PR target/40411 * config/sol2.h (STARTFILE_ARCH_SPEC): Don't use with -shared or -symbolic. Use values-Xc.o for -pedantic. Link with values-xpg4.o for C90, values-xpg6.o otherwise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sol2.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/execute_command_line_2.f90 trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
[Bug target/67412] gfortran.dg/execute_command_line_2.f90 FAILs on Solaris 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 --- Comment #11 from Rainer Orth --- Author: ro Date: Fri Jan 12 09:52:53 2018 New Revision: 256568 URL: https://gcc.gnu.org/viewcvs?rev=256568&root=gcc&view=rev Log: Link with correct values-*.o files on Solaris (PR target/40411) gcc/testsuite: PR libfortran/67412 * gfortran.dg/execute_command_line_2.f90: Remove dg-xfail-run-if on *-*-solaris2.10. libstdc++-v3: PR libstdc++/64054 * testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc: Remove dg-xfail-run-if. gcc: PR target/40411 * config/sol2.h (STARTFILE_ARCH_SPEC): Don't use with -shared or -symbolic. Use values-Xc.o for -pedantic. Link with values-xpg4.o for C90, values-xpg6.o otherwise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sol2.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/execute_command_line_2.f90 trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
[Bug libstdc++/64054] 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64054 --- Comment #19 from Rainer Orth --- Author: ro Date: Fri Jan 12 09:52:53 2018 New Revision: 256568 URL: https://gcc.gnu.org/viewcvs?rev=256568&root=gcc&view=rev Log: Link with correct values-*.o files on Solaris (PR target/40411) gcc/testsuite: PR libfortran/67412 * gfortran.dg/execute_command_line_2.f90: Remove dg-xfail-run-if on *-*-solaris2.10. libstdc++-v3: PR libstdc++/64054 * testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc: Remove dg-xfail-run-if. gcc: PR target/40411 * config/sol2.h (STARTFILE_ARCH_SPEC): Don't use with -shared or -symbolic. Use values-Xc.o for -pedantic. Link with values-xpg4.o for C90, values-xpg6.o otherwise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sol2.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/execute_command_line_2.f90 trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-01/msg01024.ht ||ml Target Milestone|--- |8.0 --- Comment #35 from Rainer Orth --- Fixed for GCC 8.1.
[Bug libstdc++/64054] 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64054 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc- |patches/2014-11/msg03271.ht |patches/2018-01/msg01024.ht |ml |ml Resolution|--- |FIXED Target Milestone|5.5 |8.0 --- Comment #20 from Rainer Orth --- Fixed for GCC 8.1.
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #36 from Rainer Orth --- Meant to mark fixed.
[Bug libstdc++/64054] 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64054 Bug 64054 depends on bug 40411, which changed state. Bug 40411 Summary: -std=c99 does not enable c99 mode in Solaris C library https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/67412] gfortran.dg/execute_command_line_2.f90 FAILs on Solaris 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 Rainer Orth changed: What|Removed |Added Status|SUSPENDED |RESOLVED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-01/msg01024.ht ||ml Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #12 from Rainer Orth --- Fixed for GCC 8.1.
[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.7.2
Keywords|diagnostic |
Last reconfirmed||2018-01-12
CC||jason at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Abstract classes allowed to |[6/7/8 Regression] Abstract
|be instantiated when|classes allowed to be
|initialised as default |instantiated when
|parameter to function or|initialised as default
|constructor |parameter to function or
||constructor
Known to fail||4.7.3, 4.8.4, 4.9.3, 5.4.0,
||6.3.0, 7.2.0, 8.0
--- Comment #2 from Jonathan Wakely ---
r194820 is a likely candidate, thanks.
Valid testcase (the one above doesn't compile) which calls a pure virtual at
runtime when compiled with G++ or EDG:
struct MyAbstractClass
{
virtual int foo() const = 0;
};
struct TestClass
{
TestClass(const MyAbstractClass& m = {}) // should generate compiler error
: value_(m.foo()) {}
int value_;
};
int TestFunction(const MyAbstractClass& m = {}) // should generate compiler
error
{
return m.foo();
}
int main(int argc, char *argv[])
{
TestClass testInstance;
TestFunction();
}
[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass yields wrong rotate result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #34 from Eric Botcazou --- Author: ebotcazou Date: Fri Jan 12 10:18:24 2018 New Revision: 256572 URL: https://gcc.gnu.org/viewcvs?rev=256572&root=gcc&view=rev Log: PR rtl-optimization/83565 * rtlanal.c (nonzero_bits1): On WORD_REGISTER_OPERATIONS machines, do not extend the result to a larger mode for rotate operations. (num_sign_bit_copies1): Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20180112-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass yields wrong rotate result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #35 from Eric Botcazou --- Author: ebotcazou Date: Fri Jan 12 10:20:42 2018 New Revision: 256573 URL: https://gcc.gnu.org/viewcvs?rev=256573&root=gcc&view=rev Log: PR rtl-optimization/83565 * rtlanal.c (nonzero_bits1): On WORD_REGISTER_OPERATIONS machines, do not extend the result to a larger mode for rotate operations. (num_sign_bit_copies1): Likewise. Added: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20180112-1.c - copied unchanged from r256572, trunk/gcc/testsuite/gcc.c-torture/execute/20180112-1.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/rtlanal.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass yields wrong rotate result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #36 from Eric Botcazou --- Thanks for reporting the problem and distilling a reduced testcase.
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #37 from Bruno Haible --- (In reply to Rainer Orth from comment #35) > Fixed for GCC 8.1. Please consider comment 17: The behaviour of a shared library also depends on whether the executable is linked with or without values-xpg6.o. The author of the shared library may not expect this and may not have tested in this situation. Can you please address this through documentation? As a shared library author, I find it extremely nasty to become aware of this tricky issue only after the fact. It could be some text such as "Note about Solaris: If you develop a shared library that makes use of functionality that is specified differently in C99 than in C90, you need to make sure that the library works fine either way. Whether C99 compliant definitions or C90 compliant definitions are in effect, depends whether the executable(!) is created with "gcc -std=c99" versus "gcc -std=c90"."
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/83802] Caller doesn't destroy default argument passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83802 Richard Biener changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Richard Biener --- I think I've seen a dup somewhere.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Alexey Salmin changed:
What|Removed |Added
CC||alexey.salmin at gmail dot com
--- Comment #36 from Alexey Salmin ---
FYI a test case that actually triggers SIGSEGV on x86 with gcc 7.2:
https://godbolt.org/g/kPw6NJ
Compiler emits a movaps instruction which is alignment-sensitive. A warning
would be helpful.
struct pair_t {
char c;
__int128_t i;
} __attribute__((packed));
struct pair_t p = {0, 1};
__int128_t *addr = &p.i;
int main() {
*addr = ~(__int128_t)0;
return (p.i != 1) ? 0 : 1;
}
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #9 from Jakub Jelinek --- Created attachment 43114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43114&action=edit gcc8-pr81155.patch Untested workaround till GDB is fixed, disable partitioning of main in lto.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #10 from Jan Kratochvil --- It should affect all functions, not just main. But then GDB already needlessly expands so many CUs that usually when some function is needed its CU is already expanded. So maybe it is seen just accidentally on one trivial testcase.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #11 from Jakub Jelinek --- Well, we certainly don't want to disable partitioning for all functions if in LTO, that would be extremely costly. Most of real-world programs don't do all the work in main, so disabling that may be acceptable. But as I said, when doing break main or l main etc. it just seems to work fine, it is just the initial current file that is broken if main has DW_AT_ranges and a partial DIE. Note GCC 8 turns -freorder-blocks-and-partition by default, something that has been done in the past only for PGO builds (-fprofile-use), so there will be significantly more functions with DW_AT_ranges now.
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801
--- Comment #7 from Georg-Johann Lay ---
(In reply to Jakub Jelinek from comment #5)
> I think the testcases just make invalid assumptions.
Huh? Which assumptions specifically?
1) There are objects of static storage duration in some non-generic AS.
2) Object locations must match accesses (which is not the case for the
code v8 generates for the test cases): Flash reads for flash, RAM reads
for RAM. Any mixing is wrong code.
3) If the compiler puts some object that should go into some AS into a
different AS, then it must prove that all accesses are also to that
other AS (including accesses via addresses that may escape and acceses
via inline asm).
4) For avr, the whole point of ASes is to save precious RAM and put stuff
into flash. As accessing flash needs different instructions, different
addressing modes and registers, ASes are used (or one must resort to
inline asm). Hence dropping AS and using generic AS makes only sense
from the perspective of optimization if the original AS object is no
more needed (otherwise the entity will be there at least twice, once
in flash and once in RAM).
> In any case, the change that matters here is likely my r254930 or r255285,
> and one could do something like add say:
> && (ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (decl)))
> || !AGGREGATE_TYPE_P (TREE_TYPE (decl)))
> to decl_constant_value_1 conditions to prevent it from looking at aggregate
> initializers in non-generic address spaces.
> Perhaps there should be also some cap on the size of decl that is optimized
> regardless of the address space, e.g. 7.x and earlier had:
> || TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE
> || DECL_MODE (exp) == BLKmode)
> condition to punt. Now, sometimes it is beneficial to have even BLKmode or
> array decls to go through, say if we have str[5], similarly
> const_var.field,then not punting on those will allow it to be optimized into
> constant, while 7.x couldn't.
As mentioned in 4) above, "optimizing" to CST makes only sense if the original
decl can be dropped; at least for avr. The point is not speed of access but
saving RAM memory and using flash instead. Keep in mind that .rodata must be
in RAM; therefore __flash and other ASes need specific sections to locate in
flash, namely .progmem* sections.
At least it should be decided whether STRING_CST is legitimate for ASes (and
hence the target hooks should handle them, dito for other CSTs) or if it is
incorrect to attach ASes to them (and decls should be used instead like v7
did).
> But, with something large and non-constant
> access it might actually regress (duplicate the constant).
Duplicating is really bad. The whole point of ASes for avr is so save memory,
RAM in particular.
Actually, anything in flash must be const (at least for avr) and hence has a
known layout, size and initializer. Due to this /any/ char[] in AS could be
represented as STRING_CST. If the FE doesn't know, maybe a new target hook is
needed?
Common idioms to put strings in flash are:
const __flash char string[] = "flash-string";
both outside of functions and as local static inside of functions, and
#define FSTR(X) ((const __flash char[]) { X } )
const __flash char* const __flash animals[] =
{
FSTR ("mite"), FSTR ("slug"), FSTR ("sloth")
};
(which is rejected for local static due to "&& current_function_decl" in
c-parser.c).
[Bug gcov-profile/83813] New: [GCOV] unsigned char in a union lead to incorrect coverage in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83813
Bug ID: 83813
Summary: [GCOV] unsigned char in a union lead to incorrect
coverage in gcov
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
# gcc-8 -v
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)
# cat small.c
union U
{
int f0;
unsigned char f1;
};
int main()
{
int i = 0;
union U u = {0};
for (u.f1 = 0; u.f1 != -2; ++u.f1) {
i ^= u.f1;
if (i < 1)
return 0;
}
return 1;
}
# gcc-8 small.c -fprofile-arcs -ftest-coverage; ./a.out; gcov-8 small.c; cat
small.c.gcov
File 'small.c'
Lines executed:85.71% of 7
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:union U
-:2:{
-:3:int f0;
-:4:unsigned char f1;
-:5:};
-:6:
1:7:int main()
-:8:{
1:9:int i = 0;
1: 10:union U u = {0};
1: 11:for (u.f1 = 0; u.f1 != -2; ++u.f1) {
#: 12:i ^= u.f1;
1: 13:if (i < 1)
1: 14:return 0;
-: 15:}
-: 16:
-: 17:return 1;
-: 18:}
Line #12 is wrongly marked as not executed. While change f1's type as int or
unsigned int, the coverage is correct.
[Bug gcov-profile/83813] [GCOV] unsigned char in a union lead to incorrect coverage in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83813 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I'll take a look next stage1.
[Bug target/83368] alloca after setjmp breaks PIC base reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368 --- Comment #17 from Eric Botcazou --- Author: ebotcazou Date: Fri Jan 12 11:29:30 2018 New Revision: 256575 URL: https://gcc.gnu.org/viewcvs?rev=256575&root=gcc&view=rev Log: PR target/83368 * config/sparc/sparc.h (PIC_OFFSET_TABLE_REGNUM): Set to INVALID_REGNUM in PIC mode except for TARGET_VXWORKS_RTP. * config/sparc/sparc.c: Include cfgrtl.h. (TARGET_INIT_PIC_REG): Define. (TARGET_USE_PSEUDO_PIC_REG): Likewise. (sparc_pic_register_p): New predicate. (sparc_legitimate_address_p): Use it. (sparc_legitimize_pic_address): Likewise. (sparc_delegitimize_address): Likewise. (sparc_mode_dependent_address_p): Likewise. (gen_load_pcrel_sym): Remove 4th parameter. (load_got_register): Adjust call to above. Remove obsolete stuff. (sparc_expand_prologue): Do not call load_got_register here. (sparc_flat_expand_prologue): Likewise. (sparc_output_mi_thunk): Set the pic_offset_table_rtx object. (sparc_use_pseudo_pic_reg): New function. (sparc_init_pic_reg): Likewise. * config/sparc/sparc.md (vxworks_load_got): Set the GOT register. (builtin_setjmp_receiver): Enable only for TARGET_VXWORKS_RTP. Added: trunk/gcc/testsuite/gcc.target/sparc/setjmp-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/config/sparc/sparc.h trunk/gcc/config/sparc/sparc.md
[Bug target/83368] alloca after setjmp breaks PIC base reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #18 from Eric Botcazou --- Fixed on the mainline.
[Bug rtl-optimization/83814] New: [8 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814 Bug ID: 83814 Summary: [8 Regression] ICE: Segmentation fault Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: ---
[Bug rtl-optimization/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814 Markus Trippelsdorf changed: What|Removed |Added CC||msebor at gcc dot gnu.org Summary|[8 Regression] ICE: |[8 Regression] ICE: in |Segmentation fault |fold_binary_loc, at ||fold-const.c:9733 --- Comment #1 from Markus Trippelsdorf --- % g++ -c read_graphviz_new.ii In file included from ../boost/regex/v4/regex.hpp:70, from ../boost/regex.hpp:31, from ../libs/graph/src/read_graphviz_new.cpp:46: ../boost/regex/v4/basic_regex_creator.hpp: In member function ‘boost::re_detail_106700::re_syntax_base* boost::re_detail_106700::basic_regex_creator::append_set(const boost::re_detail_106700::basic_char_set&, mpl_::true_*)’: ../boost/regex/v4/basic_regex_creator.hpp:592:142: internal compiler error: in fold_binary_loc, at fold-const.c:9733 std::memset(result->_map + static_cast(c1), true, 1 + static_cast(c2) - static_cast(c1)); ^ Reducing...
[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80846 --- Comment #19 from Richard Biener --- Author: rguenth Date: Fri Jan 12 11:43:13 2018 New Revision: 256576 URL: https://gcc.gnu.org/viewcvs?rev=256576&root=gcc&view=rev Log: 2018-01-12 Richard Biener PR tree-optimization/80846 * target.def (split_reduction): New target hook. * targhooks.c (default_split_reduction): New function. * targhooks.h (default_split_reduction): Declare. * tree-vect-loop.c (vect_create_epilog_for_reduction): If the target requests first reduce vectors by combining low and high parts. * tree-vect-stmts.c (vect_gen_perm_mask_any): Adjust. (get_vectype_for_scalar_type_and_size): Export. * tree-vectorizer.h (get_vectype_for_scalar_type_and_size): Declare. * doc/tm.texi.in (TARGET_VECTORIZE_SPLIT_REDUCTION): Document. * doc/tm.texi: Regenerate. i386/ * config/i386/i386.c (ix86_split_reduction): Implement TARGET_VECTORIZE_SPLIT_REDUCTION. * gcc.target/i386/pr80846-1.c: New testcase. * gcc.target/i386/pr80846-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr80846-1.c trunk/gcc/testsuite/gcc.target/i386/pr80846-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/target.def trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80846 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 80846, which changed state. Bug 80846 Summary: auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80846 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P1
Component|rtl-optimization|c++
Target Milestone|--- |8.0
--- Comment #2 from Markus Trippelsdorf ---
% cat read_graphviz_new.ii
template void *a{__builtin_memset(0, 0, int() - char())};
% g++ -c read_graphviz_new.ii
read_graphviz_new.ii:1:63: internal compiler error: in fold_binary_loc, at
fold-const.c:9733
template void *a{__builtin_memset(0, 0, int() - char())};
^
0x10838f8f fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:9733
0x1085b0c7 fold(tree_node*)
../../gcc/gcc/fold-const.c:11957
0x1026d17b cp_fold
../../gcc/gcc/cp/cp-gimplify.c:2279
0x1026f057 cp_fold_maybe_rvalue
../../gcc/gcc/cp/cp-gimplify.c:2005
0x1053a773 fold_for_warn(tree_node*)
../../gcc/gcc/c-family/c-common.c:878
0x105e0a8b warn_for_memset(unsigned int, tree_node*, tree_node*, int)
../../gcc/gcc/c-family/c-warn.c:1872
0x103ca8c7 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7182
0x103cb24f cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8281
0x103997f3 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9049
0x1039a2c7 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9150
0x1039c3af cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9437
0x1039af57 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:9721
0x1039c2e7 cp_parser_initializer_clause
../../gcc/gcc/cp/parser.c:21840
0x1039b75f cp_parser_initializer_list
../../gcc/gcc/cp/parser.c:22109
0x1039b75f cp_parser_braced_list
../../gcc/gcc/cp/parser.c:21880
0x103a02bf cp_parser_initializer
../../gcc/gcc/cp/parser.c:21798
0x103d132b cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19599
0x103dc26b cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27091
0x103dc4df cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26693
0x103dd183 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26930
[Bug fortran/59298] ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298 --- Comment #8 from Adam Hirst --- After another year, the issue still seems present. ICE when compiling the file I attached, and Janus' reduced case. The removal of the parenthesis still has the effect of avoiding the ICE. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp Thread model: posix gcc version 7.2.1 20171224 (GCC)
[Bug target/83629] [7 Regression] ICE: in decompose_normal_address, at rtlanal.c:6329 with -O2 -fPIC -frename-registers --param=sched-autopref-queue-depth=nnn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629 --- Comment #6 from Segher Boessenkool --- Author: segher Date: Fri Jan 12 12:10:16 2018 New Revision: 256577 URL: https://gcc.gnu.org/viewcvs?rev=256577&root=gcc&view=rev Log: rs6000: Tune new testcase (PR83629) It has some problems running on some 64-bit configuratiions, and the bug it is testing for is only on 32-bit; so let's not run it elsewhere. gcc/testsuite/ PR target/83629 * gcc.target/powerpc/pr83629.c: Require ilp32. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr83629.c
[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 --- Comment #2 from Oleg Endo --- Author: olegendo Date: Fri Jan 12 12:10:56 2018 New Revision: 256578 URL: https://gcc.gnu.org/viewcvs?rev=256578&root=gcc&view=rev Log: gcc/ PR target/81819 * config/rx/rx.c (rx_is_restricted_memory_address): Handle SUBREG case. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rx/rx.c
[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 --- Comment #3 from Oleg Endo --- Author: olegendo Date: Fri Jan 12 12:12:38 2018 New Revision: 256579 URL: https://gcc.gnu.org/viewcvs?rev=256579&root=gcc&view=rev Log: gcc/ Backport from mainline 2018-01-12 Oleg Endo PR target/81819 * config/rx/rx.c (rx_is_restricted_memory_address): Handle SUBREG case. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rx/rx.c
[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796 --- Comment #3 from Jonathan Wakely --- Actually I think it's r194284 commit 6fb305c7c88b07c429e8a39fbd514a417c5b6127 Author: jason Date: Fri Dec 7 04:54:27 2012 + PR c++/54325 * tree.c (build_aggr_init_expr): Don't check for abstract class. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@194284 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug go/83794] misc/cgo/test uses gigabytes of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Looks all fine now.
[Bug sanitizer/83356] [7 Regression] excessive stack usage compiling with -O2 -fsanitize=bounds -fsanitize=object-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 --- Comment #11 from Arnd Bergmann --- The second version of my workaround (build with 'gcc -Os' on gcc-7.1+) was merged into mainline linux: https://patchwork.kernel.org/patch/10143607/
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 --- Comment #8 from Jakub Jelinek --- Created attachment 43115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43115&action=edit gcc8-pr83801.patch Untested patch, that if !is_init kind of restores the 7.x behavior of not using DECL_INITIAL if it is BLKmode or has ARRAY_TYPE, on the other hand if is_init it tries even harder now to optimize more cases. But these are non-lval, so not even inside of ADDR_EXPR and in initializers e.g. array indices should be constant too and so it really should fold into something usable in the initializer.
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 --- Comment #14 from Richard Biener --- Author: rguenth Date: Fri Jan 12 13:19:23 2018 New Revision: 256580 URL: https://gcc.gnu.org/viewcvs?rev=256580&root=gcc&view=rev Log: 2018-01-12 Richard Biener PR debug/83157 * dwarf2out.c (gen_variable_die): Do not reset old_die for inline instance vars. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug tree-optimization/83510] Recent changes for -Warray-bounds trigger false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510 Franz Sirl changed: What|Removed |Added Known to work||6.4.0, 7.2.0 --- Comment #2 from Franz Sirl --- It started with r255649: 2017-12-14 David Malcolm PR tree-optimization/83312 * domwalk.h (dom_walker::dom_walker): Fix typo in comment. * tree-cfg.c (find_taken_edge): Update to handle NULL_TREE for "val" param, and to cope with arbitrary basic blocks. (find_taken_edge_cond_expr): Add "cond_stmt" param and use it to handle NULL_TREE for "val", dropping "bb" param. (find_taken_edge_switch_expr): Make "switch_stmt" param const and drop "bb" param. Handle NULL_TREE for "val". (find_case_label_for_value): Make "switch_stmt" param const. * tree-vrp.c (class check_array_bounds_dom_walker): New subclass of dom_walker. (vrp_prop::check_all_array_refs): Reimplement as... (check_array_bounds_dom_walker::before_dom_children): ...this new vfunc. Replace linear search through BB block list, excluding those with non-executable in-edges via dominator walk.
[Bug rtl-optimization/83771] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 3 reachable only by paths crossing the cold partition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83771 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-12 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r250417.
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 --- Comment #15 from Richard Biener --- Bug now needs new investigation.
[Bug regression/39508] gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD to R_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508 --- Comment #6 from H.J. Lu --- (In reply to Roel Van de Paar from comment #5) > Jason, thank you for your work on this here. Would you have a look at > https://github.com/jdbirdwell/afl/issues/5 which looks to be the same issue, > and it seems you may be able to contribute there. Thank you & God bless, Roel That guy seems to have problem to install binutils 2.29.1. Has he ever got binutils 2.29.1 working?
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 --- Comment #44 from Martin Jambor --- Author: jamborm Date: Fri Jan 12 14:06:10 2018 New Revision: 256581 URL: https://gcc.gnu.org/viewcvs?rev=256581&root=gcc&view=rev Log: Deferring FMA transformations in tight loops 2018-01-12 Martin Jambor PR target/81616 * params.def: New parameter PARAM_AVOID_FMA_MAX_BITS. * tree-ssa-math-opts.c: Include domwalk.h. (convert_mult_to_fma_1): New function. (fma_transformation_info): New type. (fma_deferring_state): Likewise. (cancel_fma_deferring): New function. (result_of_phi): Likewise. (last_fma_candidate_feeds_initial_phi): Likewise. (convert_mult_to_fma): Added deferring logic, split actual transformation to convert_mult_to_fma_1. (math_opts_dom_walker): New type. (math_opts_dom_walker::after_dom_children): New method, body moved here from pass_optimize_widening_mul::execute, added deferring logic bits. (pass_optimize_widening_mul::execute): Moved most of code to math_opts_dom_walker::after_dom_children. * config/i386/x86-tune.def (X86_TUNE_AVOID_128FMA_CHAINS): New. * config/i386/i386.c (ix86_option_override_internal): Added maybe_setting of PARAM_AVOID_FMA_MAX_BITS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/x86-tune.def trunk/gcc/params.def trunk/gcc/tree-ssa-math-opts.c
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 --- Comment #9 from Georg-Johann Lay --- (In reply to Jakub Jelinek from comment #8) > Created attachment 43115 [details] > gcc8-pr83801.patch > > Untested patch, that if !is_init kind of restores the 7.x behavior of not > using DECL_INITIAL if it is BLKmode or has ARRAY_TYPE, on the other hand if > is_init it tries even harder now to optimize more cases. But these are > non-lval, so not even inside of ADDR_EXPR and in initializers e.g. array > indices should be constant too and so it really should fold into something > usable in the initializer. Great, thanks. Appears to work for me. At least I couln't find code that breaks. And it also fixes ICE PR83729.
[Bug target/83815] New: Enhance addressing for long double on PowerPC with -meabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83815 Bug ID: 83815 Summary: Enhance addressing for long double on PowerPC with -meabi=ieeelongdouble Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- TFmode (and TCmode) in rs6000.c is tuned for IBM extended double. With the -mabi=ieeelongdouble option which switches long double to IEEE 128-bit, we need to go through the various addressing functions in rs6000.c and support the appropriate reg+reg addressing (and reg+offset in ISA 3.0).
[Bug target/83815] Enhance addressing for long double on PowerPC with -meabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83815 Michael Meissner changed: What|Removed |Added Target||powerpc64le-linux, ||powerpc64-linux Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-12 CC||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64le-linux, ||powerpc64-linux Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1 Build||powerpc64le-linux, ||powerpc64-linux Severity|normal |enhancement
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #15 from Jakub Jelinek --- Created attachment 43116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43116&action=edit gcc8-pr82694.patch So like this untested patch? Certainly don't have energy to look for all other spots that might need similar treatment, on the other side, not sure how far we really need to go in working around buggy code. If the kernel works with it, perhaps that is enough (and even for the kernel would be if they fix their mess). All the patch does is introduce the new option and revert the patch using the new macros.
[Bug lto/83816] New: [7 Regression] lto1: internal compiler error: compressed stream: data error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 Bug ID: 83816 Summary: [7 Regression] lto1: internal compiler error: compressed stream: data error Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- This happens when building a bigger app on RX with LTO during linking: 0x7f619a lto_end_uncompression(lto_compression_stream*) ../../gcc7/gcc/lto-compress.c:293 0x7f43e8 lto_get_section_data(lto_file_decl_data*, lto_section_type, char const*, unsigned long*, bool) ../../gcc7/gcc/lto-section-in.c:164 0x561ebf lto_file_finalize ../../gcc7/gcc/lto/lto.c:2033 0x561ebf lto_create_files_from_ids ../../gcc7/gcc/lto/lto.c:2050 0x561ebf lto_file_read ../../gcc7/gcc/lto/lto.c:2091 0x561ebf read_cgraph_and_symbols ../../gcc7/gcc/lto/lto.c:2803 0x561ebf lto_main() ../../gcc7/gcc/lto/lto.c:3308 Not sure how to make a reproducer for that. I can't post the full source of the whole thing. Any advice on how to get info out of the compiler to solve this is appreciated.
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814 Jakub Jelinek changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Can't reproduce this with #c2. Though, calling fold_for_warn inside of templates looks wrong, that is generally very unsafe. The calls to fold_for_warn have been introduced in the PR43486 changes. Or perhaps warn_for_memset just shouldn't be called if either of arg0 and arg2 is type_dependent_expression_p?
[Bug c++/83817] New: [8 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817
Bug ID: 83817
Summary: [8 Regression]
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: rx*-*-*
Build: internal compiler error: tree check: expected
call_expr, have aggr_init_expr in
tsubst_copy_and_build, at cp/pt.c:17822
Compiling the following on RX with -O2 -std=c++14
#include
struct message
{
std::string m_content_data;
};
struct response : message { };
struct request : message { };
typedef response (*http_handler_func)(const request&);
struct http_handler
{
const char* uri;
http_handler_func func;
};
static response some_handler (const request&);
static const http_handler http_handlers_single[] =
{
{ "x", [] (const auto& r) { return some_handler (r); } },
};
results in
http_server_bug.cpp: In instantiation of 'static decltype (((const*)((const*
const)0))->operator()(static_cast()))::_FUN(const auto:1&) [with auto:1 = request; decltype
(((const*)((const*
const)0))->operator()(static_cast())) = response]':
http_server_bug.cpp:25:56: required from '::operator
decltype (((const*)((const*
const)0))->operator()(static_cast())) (*)(const
auto:1&)() const [with auto:1 = request; decltype (((const*)((const*
const)0))->operator()(static_cast())) = response]'
http_server_bug.cpp:26:1: required from here
http_server_bug.cpp:25:56: internal compiler error: tree check: expected
call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822
{ "x", [] (const auto& r) { return some_handler (r); } },
^
0x58ae34 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-trunk/gcc/tree.c:9375
0x75721a tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-trunk/gcc/tree.h:3127
0x75721a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:17822
0x75a163 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:16765
0x75944c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15996
0x759693 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:16249
0x795aee instantiate_decl(tree_node*, bool, bool)
../../gcc-trunk/gcc/cp/pt.c:23311
0x79d1e9 instantiate_pending_templates(int)
../../gcc-trunk/gcc/cp/pt.c:23427
0x67dd02 c_parse_final_cleanups()
../../gcc-trunk/gcc/cp/decl2.c:4705
[Bug c++/83817] [8 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817 --- Comment #1 from Oleg Endo --- Created attachment 43117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43117&action=edit preprocessed source
[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 --- Comment #4 from Oleg Endo --- Fixed on trunk and GCC 7.
[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Oleg Endo --- Fixed on trunk and GCC 7.
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-12 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from David Malcolm --- I was able to reproduce the #c2 ICE with --target=powerpc64-unknown-linux-gnu
[Bug rtl-optimization/83628] [8 Regression] performance regression when accessing arrays on alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83628 --- Comment #9 from uros at gcc dot gnu.org --- Author: uros Date: Fri Jan 12 16:47:45 2018 New Revision: 256589 URL: https://gcc.gnu.org/viewcvs?rev=256589&root=gcc&view=rev Log: PR target/83628 * config/alpha/alpha.md (*saddsi_1): New insn_ans_split pattern. (*saddl_se_1): Ditto. (*ssubsi_1): Ditto. (*saddl_se_1): Ditto. testsuite/ChangeLog: PR target/83628 * gcc.target/alpha/pr83628-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/alpha/pr83628-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/alpha/pr83628-2.c
[Bug c++/83778] [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83778
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Minimal reproducer:
int f4 (__attribute__((altivec(vector__))) int a)
{
return __builtin_vec_extract (a, 4);
}
./cc1plus -quiet -std=gnu++14 -maltivec pr83778.C -isystem include/
-mcpu=power8
The difference is that before r256448 rs6000_resolve_overloaded_builtin was
called with INTEGER_CST in the arg2, but now with NON_LVALUE_EXPR wrapper
around it.
[Bug c++/83778] [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83778 --- Comment #5 from Jakub Jelinek --- Created attachment 43118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43118&action=edit gcc8-pr83778.patch This restores the previous behavior for me. Note, the question is whether the 4 is really invalid, in that case perhaps we shouldn't fold it to something early and let it error during expansion.
[Bug tree-optimization/83510] [8 Regression] Recent changes for -Warray-bounds trigger false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510 Martin Sebor changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83312 Blocks||56456 Summary|Recent changes for |[8 Regression] Recent |-Warray-bounds trigger |changes for -Warray-bounds |false positive |trigger false positive Known to fail||8.0 --- Comment #3 from Martin Sebor --- Yes, that's the one. Thanks for chasing it down. The warning appears to be due to the change in the order the pass now walks the basic blocks of the function. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug rtl-optimization/80481] Unoptimal additional copy instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481 --- Comment #3 from Vladimir Makarov --- Author: vmakarov Date: Fri Jan 12 17:00:36 2018 New Revision: 256590 URL: https://gcc.gnu.org/viewcvs?rev=256590&root=gcc&view=rev Log: 2018-01-12 Vladimir Makarov PR rtl-optimization/80481 * ira-color.c (get_cap_member): New function. (allocnos_conflict_by_live_ranges_p): Use it. (slot_coalesced_allocno_live_ranges_intersect_p): Add assert. (setup_slot_coalesced_allocno_live_ranges): Ditto. 2018-01-12 Vladimir Makarov PR rtl-optimization/80481 * g++.dg/pr80481.C: New. Added: trunk/gcc/testsuite/g++.dg/pr80481.C Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814 --- Comment #5 from David Binderman --- The original source code for bug # 68619 and flag -O2, seems to reproduce on x86_64. I'll have a go at reducing that.
[Bug tree-optimization/83781] [8 Regression] Bootstrap failed on x86 with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83781 David Frantz changed: What|Removed |Added CC||kb2gmx at verizon dot net --- Comment #10 from David Frantz --- Look a the declaration for buf. (line number 783) Change the char buf[64] to char buf[128] This worked for me. -David Frantz
[Bug c++/83818] New: g++ class template parameter deduction discards const qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83818
Bug ID: 83818
Summary: g++ class template parameter deduction discards const
qualifier
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla.gcc.karo at cupdev dot net
Target Milestone: ---
The following code should fail to compile, since `s` is declared const; the
assignment to u should fail because it discards the const qualifier.
The assignment to s.x should also fail because `s` is const, but the code
compiles successfully;
# Code
```
template
struct tstruct {
T x;
tstruct(const T &x_) : x{x_} {}
};
int main() {
const tstruct s{2};
tstruct &u = s;
s.x = 2;
return 0;
}
```
# Compiling the code above (with class template parameter deduction)
```
$ g++ --std=c++17 -Wall -Wextra -Wpedantic g.cc -o g
g.cc: In function ‘int main()’:
g.cc:9:17: warning: unused variable ‘u’ [-Wunused-variable]
tstruct &u = s;
$ ls -al g
-rwxr-xr-x 1 karo karo 8.3K Jan 12 18:11 g*
```
# With explicitly added to avoid template parameter deduction
If I explicitly add the `` template parameter to the declaration of `s`,
gcc yields the correct errors and does not produce a file:
```
$ g++ --std=c++17 -Wall -Wextra -Wpedantic g.cc -o g
g.cc: In function ‘int main()’:
g.cc:9:21: error: binding reference of type ‘tstruct&’ to ‘const
tstruct’ discards qualifiers
tstruct &u = s;
^
g.cc:10:9: error: assignment of member ‘tstruct::x’ in read-only object
s.x = 2;
^
g.cc:9:17: warning: unused variable ‘u’ [-Wunused-variable]
tstruct &u = s;
```
# GCC Version
```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.1 20171128 (GCC)
```
[Bug c++/83818] g++ class template parameter deduction discards const qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83818 --- Comment #1 from Karolin varner --- Created attachment 43119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43119&action=edit Test case
[Bug c++/83818] g++ class template parameter deduction discards const qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83818
--- Comment #2 from Karolin varner ---
Comment on attachment 43119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43119
Test case
>template
>struct tstruct {
> T x;
> tstruct(const T &x_) : x{x_} {}
>};
>
>int main() {
> const tstruct s{2};
> tstruct &u = s;
> s.x = 2;
> return 0;
>}
[Bug libquadmath/83800] [libquadmath] M_SQRT2q & sqrtq(2.0Q) off by one ULP ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800 --- Comment #4 from joseph at codesourcery dot com --- Functions bound to IEEE operations, such as sqrt and fma, should be correctly rounding for all IEEE floating-point types (so not IBM long double) supported by glibc. However, there's no generic ldbl-128 sqrtl / sqrtf128 in glibc; each architecture implements it either using soft-fp, or using hardware sqrt instructions where supported. There's a case that when built against new-enough glibc, quadmath.h should be mapping most function calls to call the libm *f128 functions instead (I suppose more work elsewhere might be needed to do that mapping for calls from Fortran code).
[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
sudi at gcc dot gnu.org changed:
What|Removed |Added
CC||law at redhat dot com,
||vmakarov at redhat dot com
--- Comment #4 from sudi at gcc dot gnu.org ---
What I have observed so far is that the failure occurs based on how the
scheduler (sched1) chooses to schedule the movmem12b instructions (insn 16 in
all the cases below). If that
instruction is scheduled a bit later (even by one instruction), its all good!
Even though the movmem12b instruction has a very heavy demand on the registers,
shouldn't the allocator and/or the scheduler be able to detect that? Is this a
scheduler problem or an allocator problem or neither?
Example Passing cases:
-mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
;; Pressure summary: GENERAL_REGS:8
;;0--> b 0: i 13 r119=[`*.LC1']
:(l_a+e_1),l_dc1,l_dc2,l_wb:GENERAL_REGS+1(1)
;;1--> b 0: i 12 r118=sfp-0x10
:e_1,e_2,e_3,e_wb:@GENERAL_REGS+1(1)
;;2--> b 0: i 2 r111=r0
:e_1,e_2,e_3,e_wb:@GENERAL_REGS+1(0):model 0
;;3--> b 0: i 16
{[r118]=[r119];[r118+0x4]=[r119+0x4];[r118+0x8]=[r119+0x8];r120=r118+0xc;r121=r119+0xc;clobber
scratch;clobber scratch;clobber
scratch;}:(l_a+e_1),l_dc1*2,l_dc2,l_wb:GENERAL_REGS+2(1)
...
,..
Example Failing case:
-mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
-mtune=cortex-m0plus
;; Pressure summary: GENERAL_REGS:8
;;0--> b 0: i 13 r119=[`*.LC1']
:core:GENERAL_REGS+1(1)
;;1--> b 0: i 12 r118=sfp-0x10
:core:@GENERAL_REGS+1(1)
;;2--> b 0: i 16
{[r118]=[r119];[r118+0x4]=[r119+0x4];[r118+0x8]=[r119+0x8];r120=r118+0xc;r121=r119+0xc;clobber
scratch;clobber scratch;clobber scratch;}:core*4:GENERAL_REGS+2(1)
...
...
Other passing option:
mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
-mtune=cortex-m7
Other failing option:
-mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
-mtune=cortex-m4
[Bug tree-optimization/83819] New: [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug ID: 83819 Summary: [meta-bug] missing strlen optimizations Product: gcc Version: 8.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: --- This meta-bug groups optimizations missing strlen optimizations.
[Bug target/83737] [nvptx] FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83737 --- Comment #6 from Tom de Vries --- Author: vries Date: Fri Jan 12 17:36:07 2018 New Revision: 256591 URL: https://gcc.gnu.org/viewcvs?rev=256591&root=gcc&view=rev Log: Set use_gcc_stdint=wrap for nvptx 2018-01-12 Tom de Vries PR target/83737 * config.gcc (nvptx*-*-*): Set use_gcc_stdint=wrap. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug target/83738] [avr] Don't save registers in main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83738 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #3 from Tom de Vries --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83737#c2 : ... Author: gjl Date: Tue Jan 9 10:38:45 2018 New Revision: 256373 URL: https://gcc.gnu.org/viewcvs?rev=256373&root=gcc&view=rev Log: gcc/ Don't save registers in main(). PR target/83737 * doc/invoke.texi (AVR Options) [-mmain-is-OS_task]: Document it. * config/avr/avr.opt (-mmain-is-OS_task): New target option. * config/avr/avr.c (avr_set_current_function): Don't error if naked, OS_task or OS_main are specified at the same time. (avr_function_ok_for_sibcall): Don't disable sibcalls for OS_task, OS_main. (avr_insert_attributes) [-mmain-is-OS_task] : Add OS_task attribute. * common/config/avr/avr-common.c (avr_option_optimization_table): Switch on -mmain-is-OS_task for optimizing compilations. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/avr/avr-common.c trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.opt trunk/gcc/doc/invoke.texi ...
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814
Sunil Pandey changed:
What|Removed |Added
CC||skpgkp1 at gmail dot com
--- Comment #6 from Sunil Pandey ---
I'm getting similar issue with mariadb build. Here is test case.
$ cat cert_wrapper.i.cpp
extern "C" void *memset(void *, int, unsigned long);
unsigned a;
template void b() {
int c;
memset((char *)c + a, 0, a);
}
$g++ --version
g++ (GCC) 8.0.0 20180111 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$g++ -pie -fPIC -Wl,-z,relro,-z,now -fstack-protector
--param=ssp-buffer-size=4 -fno-rtti -O3 -g -static-libgcc
-fno-omit-frame-pointer -fno-strict-aliasing -fPIC -fvisibility=hidden -o
cert_wrapper.i.cpp.o -c cert_wrapper.i.cpp
cert_wrapper.i.cpp: In function ‘void b()’:
cert_wrapper.i.cpp:5:29: internal compiler error: in fold_binary_loc, at
fold-const.c:9733
memset((char *)c + a, 0, a);
^
0x6a5bce fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc-main.3UZ3/gcc/fold-const.c:9733
0xcc11ec fold(tree_node*)
../../gcc-main.3UZ3/gcc/fold-const.c:11957
0x935265 cp_fold
../../gcc-main.3UZ3/gcc/cp/cp-gimplify.c:2279
0x935e0c cp_fold_maybe_rvalue
../../gcc-main.3UZ3/gcc/cp/cp-gimplify.c:2005
0xb27fb9 warn_for_memset(unsigned int, tree_node*, tree_node*, int)
../../gcc-main.3UZ3/gcc/c-family/c-warn.c:1871
0x9fa898 cp_parser_postfix_expression
../../gcc-main.3UZ3/gcc/cp/parser.c:7182
0x9fae70 cp_parser_unary_expression
../../gcc-main.3UZ3/gcc/cp/parser.c:8281
0x9dc7ef cp_parser_cast_expression
../../gcc-main.3UZ3/gcc/cp/parser.c:9049
0x9dcffa cp_parser_binary_expression
../../gcc-main.3UZ3/gcc/cp/parser.c:9150
0x9de7c4 cp_parser_assignment_expression
../../gcc-main.3UZ3/gcc/cp/parser.c:9437
0x9deeda cp_parser_expression
../../gcc-main.3UZ3/gcc/cp/parser.c:9606
0x9e0ba8 cp_parser_expression_statement
../../gcc-main.3UZ3/gcc/cp/parser.c:11063
0x9e5a8d cp_parser_statement
../../gcc-main.3UZ3/gcc/cp/parser.c:10879
0x9e7020 cp_parser_statement_seq_opt
../../gcc-main.3UZ3/gcc/cp/parser.c:11206
0x9e70f7 cp_parser_compound_statement
../../gcc-main.3UZ3/gcc/cp/parser.c:11160
0x9fd6f0 cp_parser_function_body
../../gcc-main.3UZ3/gcc/cp/parser.c:21700
0x9fd6f0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-main.3UZ3/gcc/cp/parser.c:21737
0x9fdfb0 cp_parser_function_definition_after_declarator
../../gcc-main.3UZ3/gcc/cp/parser.c:26635
0x9fec9b cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-main.3UZ3/gcc/cp/parser.c:26551
0x9fec9b cp_parser_init_declarator
../../gcc-main.3UZ3/gcc/cp/parser.c:19426
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libfortran/83811] fortran 'e' format broken for single digit exponents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83811 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- There have been a number of tweaks possibly affecting string internal unit I/O. I will investigate this further.
[Bug target/83737] [nvptx] FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83737 Tom de Vries changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |8.0
[Bug c++/83820] New: No diagnostic issued for noreturn attribute specifier with an argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83820
Bug ID: 83820
Summary: No diagnostic issued for noreturn attribute specifier
with an argument list
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: smw at gcc dot gnu.org
Target Milestone: ---
No diagnostic is issued for a [[noreturn]] attribute specifier containing an
attribute-argument-clause. See [dcl.attr.noreturn]/1
Example code accepted by GCC but rejected by clang, ICC, MSVC:
[[noreturn()]] void f() { throw 0; }
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814 --- Comment #7 from David Binderman --- Thanks for the small testcase. Problem seems to occur between revisions 256420 and 256556. No special flags required. -c will do it.
[Bug tree-optimization/83821] New: local aggregate initialization defeats strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83821
Bug ID: 83821
Summary: local aggregate initialization defeats strlen
optimization
Product: gcc
Version: 8.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: ---
For the test case below, GCC optimizes the strlen call in f() but fails to do
the same in g(). It appears because the maybe_invalidate() function in the
pass considers the initialization of/assignment to b.i as possibly clobbering
the value of b.s, not realizing that there is no way for the two members to
alias.
$ cat z.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout z.c
#define STR "0123456789"
struct A
{
char s[sizeof STR];
};
void f (void)
{
struct A a = { STR };
if (__builtin_strlen (a.s) != sizeof STR - 1) // folded
__builtin_abort (); // eliminated
}
struct B
{
char s[sizeof STR];
int i;
};
void g (void)
{
struct B b = { STR, 123 };
if (__builtin_strlen (b.s) != sizeof STR - 1) // not folded
__builtin_abort (); // not eliminated
}
;; Function f (f, funcdef_no=0, decl_uid=1952, cgraph_uid=0, symbol_order=0)
f ()
{
[local count: 1073741825]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1959, cgraph_uid=1, symbol_order=1)
g ()
{
struct B b;
long unsigned int _1;
[local count: 1073741825]:
b.s = "0123456789";
b.i = 123;
_1 = __builtin_strlen (&b.s);
if (_1 != 10)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312327]:
b ={v} {CLOBBER};
return;
}
[Bug libfortran/83811] fortran 'e' format broken for single digit exponents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83811 --- Comment #2 from Jerry DeLisle --- The change has nothing to do with internl units. So it is related to the write float refctoring we did.
[Bug c++/83820] No diagnostic issued for noreturn attribute specifier with an argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83820 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-12 CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81544 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed, thanks. GCC 8 does a better job diagnosing these issues (e.g., it complains about attribute malloc on a void function) but this case was missed in r255469. There probably are other meaningless declarations that would be helpful to warn about so please open a new bug for each.
[Bug c++/83818] g++ class template parameter deduction discards const qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83818 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-12 Known to work||8.0 Ever confirmed|0 |1 Known to fail||7.2.0 --- Comment #3 from Jonathan Wakely --- Confirmed. Already seems to be fixed on trunk.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Fri Jan 12 18:20:49 2018 New Revision: 256592 URL: https://gcc.gnu.org/viewcvs?rev=256592&root=gcc&view=rev Log: PR debug/81155 * bb-reorder.c (pass_partition_blocks::gate): In lto don't partition main to workaround a bug in GDB. Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c
[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242 --- Comment #8 from Jozef Lawrynowicz --- Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01108.html
[Bug target/83822] New: trunk/gcc/config/rs6000/rs6000-string.c:970]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83822 Bug ID: 83822 Summary: trunk/gcc/config/rs6000/rs6000-string.c:970]: (style) Redundant condition Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/gcc/config/rs6000/rs6000-string.c:970]: (style) Redundant condition: bytes_is_const. '!A || (A && B)' is equivalent to '!A || B' Source code is if (!bytes_is_const || (bytes_is_const && bytes_remaining >= load_mode_size))
[Bug c++/83186] [8 regression] internal compiler error: in build_address, at cp/typeck.c:5667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83186 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/83821] local aggregate initialization defeats strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83821 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-12 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Testing a simple patch.
[Bug c++/83186] [8 regression] internal compiler error: in build_address, at cp/typeck.c:5667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83186 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Jan 12 19:40:11 2018 New Revision: 256594 URL: https://gcc.gnu.org/viewcvs?rev=256594&root=gcc&view=rev Log: PR c++/83186 - ICE with static_cast of list-initialized temporary. * typeck.c (build_static_cast): Use build_non_dependent_expr. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist-cast1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug regression/39508] gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD to R_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508 --- Comment #7 from Roel Van de Paar --- "That guy" is me :) Yes binutils 2.29.1 works fine after the minor 'ar' fix.
[Bug fortran/83525] open(newunit=funit, status="scratch") fails if an internal file (characters) was read previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83525 --- Comment #4 from Jerry DeLisle --- Author: jvdelisle Date: Fri Jan 12 20:01:47 2018 New Revision: 256595 URL: https://gcc.gnu.org/viewcvs?rev=256595&root=gcc&view=rev Log: 2018-01-12 Jerry DeLisle PR libgfortran/83525 * gfortran.dg/newunit_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/newunit_5.f90.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/83525] open(newunit=funit, status="scratch") fails if an internal file (characters) was read previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83525 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jerry DeLisle --- Test case committed so closing.
[Bug fortran/83823] New: [8 Regression] Character length issues with PACK()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83823
Bug ID: 83823
Summary: [8 Regression] Character length issues with PACK()
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
The following code gives wrong output with 8.0 svn rev.256556:
program gfcbug145
implicit none
type t_obstyp
character(len=8) :: name
end type t_obstyp
type (t_obstyp) ,parameter :: obstyp(*)= &
[ t_obstyp ('SYNOP' ), &
t_obstyp ('DRIBU' ), &
t_obstyp ('TEMP' ), &
t_obstyp ('RADAR' ) ]
logical :: mask(size(obstyp)) = .true.
print *,obstyp% name
print *, pack (obstyp% name, mask)
write(6,'(20(a8,:,"|"))') obstyp% name
write(6,'(20(a8,:,"|"))') pack (obstyp% name, mask)
end program gfcbug145
Bad output with 8.0:
SYNOP DRIBU TEMPRADAR
SYNOPDRIBUTEMPRRADAR
SYNOP |DRIBU |TEMP|RADAR
SYNOP| DRIBU| TEMPR| RADAR
Good output with 7.2:
SYNOP DRIBU TEMPRADAR
SYNOP DRIBU TEMPRADAR
SYNOP |DRIBU |TEMP|RADAR
SYNOP |DRIBU |TEMP|RADAR
Note also the bogus 'R' after "TEMP".
[Bug fortran/83622] [8 Regression] Wrong code with derived type and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83622 --- Comment #7 from Harald Anlauf --- (In reply to paul.richard.tho...@gmail.com from comment #6) > That's what I have been trying to find out :-) > > It's jogging my memory but I cannot for the life of me rememeber what > it was about. > > Paul Hi Paul, I tried and found that commenting the two lines with the "early return" fixes the issue in comment #0.
[Bug c++/53499] Incorrect partial ordering result with member vs non-member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
--- Comment #3 from Ed Catmur ---
I believe this also causes gcc to reject (as ambiguous) the example in
[temp.func.order]/3:
struct A { };
template struct B {
template int operator*(R&); // #1
};
template int operator*(T&, R&); // #2
// The declaration of B::operator* is transformed into the equivalent of
// template int operator*(B&, R&); // #1a
int main() {
A a;
B b;
b * a;// calls #1a
}
[Bug tree-optimization/83821] local aggregate initialization defeats strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83821 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01131.html
