[Bug c++/86652] pointer to function type cannot have 'const' qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86652 --- Comment #2 from Andrew Pinski --- This seems like the const is applying to the function (not the function type that it is returning).
[Bug c++/86652] pointer to function type cannot have 'const' qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86652
--- Comment #1 from zhonghao at pku dot org.cn ---
A related code sample:
class C { public: template int (*f())() const; };
int foo(C c) { return (*c.f())(); }
The messages from clang++:
error: pointer to function type cannot have 'const' qualifier
class C { public: template int (*f())() const; };
error: no matching member function for call to 'f'
int foo(C c) { return (*c.f())(); }
~~^~
2 errors generated.
[Bug c++/86652] New: pointer to function type cannot have 'const' qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86652
Bug ID: 86652
Summary: pointer to function type cannot have 'const' qualifier
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
class C {
public:
template
int (*f())() const;
};
g++ accepts the code, but clang++ rejects it:
code4.cpp:4:7: error: pointer to function type cannot have 'const' qualifier
int (*f())() const;
^
1 error generated.
If it's a pointer to a const function, the line shall be:
int (*f() const)();
If the return type is const (which is of course meaningless), the line shall
be:
const int (*f())();
However, I do not quite understant int (*f())() const;. Maybe it is illegal as
clang++ says?
[Bug debug/68836] GCC can't properly emit debug info for function arguments in a back-trace when using -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Without a (guality?) testcase there's nothing to do here. But quite likely > the reason is inlining. Alex new work _might_ help here. Which new work?
[Bug other/63440] -Og does enable -fmerge-constants too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=59658 --- Comment #3 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Note that the various "Enabled at levels ..." were not updated for -Og. This part is bug 59658.
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Eric Gallager changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Tom de Vries seems to have been working on bugs related to this recently.
[Bug other/84889] Ideas on revamping how we format diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from Eric Gallager --- ASSIGNED since there's an assignee
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-24 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- I'll probably keep --enable-objc-gc in my configure flags anyways even if it becomes automatic, but becoming automatic could help increase test coverage of it. I guess I'll confirm this.
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #2 from The Written Word --- (In reply to The Written Word from comment #1) > I get a similar error with 8.1.0. And with 5.5.0.
[Bug tree-optimization/86650] -Warray-bounds missing inlining context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86650 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01286.html
[Bug target/86448] GCC 9 compiler generates slower code for spec 2006 milc on a power9 using -mcpu=power9 than using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86448 kelvin at gcc dot gnu.org changed: What|Removed |Added CC||kelvin at gcc dot gnu.org --- Comment #1 from kelvin at gcc dot gnu.org --- Using trunk on a dedicated DD2.2 power9, I get the following performance comparisons: -mcpu=power8-mcpu=power9 28.92 28.97 28.37 28.99 28.13 28.26 29.06 28.12 28.8 28.23 28.9 28.69 28.37 28.48 28.3 28.08 delta Percent average 28.6062528.4775 0.12875 0.45%
[Bug tree-optimization/86650] -Warray-bounds missing inlining context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86650 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-23 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Testing a patch.
[Bug c++/79501] member deduction guide not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79501 eracpp at eml dot cc changed: What|Removed |Added CC||eracpp at eml dot cc --- Comment #1 from eracpp at eml dot cc --- Still observed on trunk (GCC 9.0.0 20180722): https://wandbox.org/permlink/vpY98XCvEz2k0IN9 Relevant paragraph from the standard ([temp.deduct.guild]-3): http://eel.is/c++draft/temp.deduct.guide#3.sentence-4 "A deduction-guide shall be declared in the same scope as the corresponding class template and, for a member class template, with the same access."
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #44 from Qing Zhao --- > (In reply to wilco from comment #43) will provide a simple patch for this issue.
[Bug lto/86651] New: lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651
Bug ID: 86651
Summary: lto-wrapper.exe: fatal error:
simple_object_copy_lto_debug_sections not implemented:
Invalid argument
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling anything with '-flto -g' yields the following error message during
linking:
$ echo "void main(){}" > nop.c
$ i586-pc-msdosdjgpp-gcc -flto -g nop.c
lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not
implemented: Invalid argument
compilation terminated.
collect2.exe: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
$ i586-pc-msdosdjgpp-gcc -v
Using built-in specs.
COLLECT_GCC=D:\msys64\usr\local\cross\bin\i586-pc-msdosdjgpp-gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/usr/local/cross/libexec/gcc/i586-pc-msdosdjgpp/8.1.0/lto-wrapper.exe
Target: i586-pc-msdosdjgpp
Configured with: ../gnu/gcc-8.10/configure --disable-plugin --enable-lto
--enable-libstdcxx-filesystem-ts --disable-nls --enable-libquadmath-support
--enable-version-specific-runtime-libs --enable-fat --disable-libstdcxx-pch
--target=i586-pc-msdosdjgpp --prefix=/usr/local/cross --enable-languages=c,c++
Thread model: single
gcc version 8.1.0 (GCC)
This appears to be the same bug as pr85238, which is marked FIXED / RESOLVED.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #11 from Qing Zhao --- > to reply: Comment #10 from Martin Sebor — thanks for the details. However, I do not feel comfortable for the compiler to change an undefined buggy code. I think that it’s better to let the user to correct his/her own buggy code. What the compiler should do is just tell the user that his/her code is wrong, and why it’s wrong. the user should know better how to correct his code.
[Bug other/86649] [9 regression] g++.dg/tree-ssa/pr19476-1.C fails starting with r262928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86649 Rainer Orth changed: What|Removed |Added Target|powerpc64*-*-* |powerpc*-*-*, i?86-*-*, ||x86_64-*-*, aarch64-*-*, ||sparc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 CC||ro at gcc dot gnu.org Host|powerpc64*-*-* | Target Milestone|--- |9.0 Ever confirmed|0 |1 Build|powerpc64*-*-* | --- Comment #1 from Rainer Orth --- I'm seeing it on Solaris/SPARC and x86, and there are gcc-testresults postings on several more.
[Bug tree-optimization/86396] fold calls to strtod() into constants where possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86396
--- Comment #2 from joseph at codesourcery dot com ---
You can't fold atof ("3.14") with -frounding-math because the result
depends on the rounding mode, or with -ftrapping-math (which is the
default) because it should raise "inexact" (there are also overflow /
underflow cases that should set errno). There are also locale-specific
aspects to these functions, such as the variation of the decimal-point
character which means you can't fold atof ("3.14") even with
-fno-rounding-math -fno-trapping-math as the locale might use "," not "."
as decimal-point character, and the variation of uppercase / lowercase 'I'
/ 'i' mappings (see glibc bug 15744). (And implementation-specific
variations in the handling of the n-char-sequence with NAN, quite likely;
glibc has the peculiarity there of using strtoull and thus not being able
to represent all values in a binary128 payload.)
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Mon Jul 23 19:40:28 2018 New Revision: 262935 URL: https://gcc.gnu.org/viewcvs?rev=262935=gcc=rev Log: PR libstdc++/70940 optimize pmr::resource_adaptor for allocators using malloc pmr::resource_adaptor can avoid allocating an oversized buffer and doing manual alignment within that buffer when the wrapped allocator is known to always meet the requested alignment. Specifically, if the allocator is known to use malloc or new directly, then we can call the allocator directly for any fundamental alignment. PR libstdc++/70940 * include/experimental/memory_resource (__resource_adaptor_common::_AlignMgr::_M_unadjust): Add assertion. (__resource_adaptor_common::__guaranteed_alignment): New helper to give maximum alignment an allocator guarantees. Specialize for known allocators using new and malloc. (__resource_adaptor_imp::do_allocate): Use __guaranteed_alignment. (__resource_adaptor_imp::do_deallocate): Likewise. * testsuite/experimental/memory_resource/new_delete_resource.cc: Check that new and delete are called with expected sizes. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/memory_resource trunk/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
[Bug tree-optimization/86650] New: -Warray-bounds missing inlining context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86650 Bug ID: 86650 Summary: -Warray-bounds missing inlining context Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- As pointed out in the thread below, unlike warnings, instances of -Warray-bounds don't include inlining context, making them harder to analyze: https://sourceware.org/ml/libc-alpha/2018-07/msg00693.html Making both the inlining context and the declaration being referenced available in the warning would be helpful. The following post shows the difference it makes in the instance of the warning discussed in the Glibc thread: https://sourceware.org/ml/libc-alpha/2018-07/msg00701.html
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #10 from Martin Sebor --- The code is undefined so the return value doesn't really matter but conservatively, I think any non-zero value would work. What to do is a judgment call between letting the library call return some (possibly bogus and unpredictable) value or crash, and folding the call into a predictable (but possibly bogus) value and avoiding crashing. If folding into a bogus value despite the undefined behavior is a concern then folding the call to a comparison of the minimum of sizeof(string-literal) and the memcmp size would be another alternative to gain predictable results while avoiding reading past the end.
[Bug other/86649] New: [9 regression] g++.dg/tree-ssa/pr19476-1.C fails starting with r262928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86649 Bug ID: 86649 Summary: [9 regression] g++.dg/tree-ssa/pr19476-1.C fails starting with r262928 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- make -k check-gcc RUNTESTFLAGS=dg.exp=g++.dg/tree-ssa/pr19476-1.C . . . # of expected passes6 # of unexpected failures3 FAIL: g++.dg/tree-ssa/pr19476-1.C -std=gnu++98 scan-tree-dump ccp1 "return 42" FAIL: g++.dg/tree-ssa/pr19476-1.C -std=gnu++11 scan-tree-dump ccp1 "return 42" FAIL: g++.dg/tree-ssa/pr19476-1.C -std=gnu++14 scan-tree-dump ccp1 "return 42"
[Bug bootstrap/86621] [9 regression] 'alloca' bound is unknown in tree-vect-slp.c:1437:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86631 --- Comment #12 from Martin Sebor --- I'm tracking the test failures in bug 86631.
[Bug c++/86648] [9 Regression] ICE on class template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86648 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I don't see any ICE with -std=c++17.
[Bug c++/86648] New: [9 Regression] ICE on class template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86648
Bug ID: 86648
Summary: [9 Regression] ICE on class template argument
deduction
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris_oncev at hotmail dot com
Target Milestone: ---
On compiler explorer using the gcc (trunk) compiler I get an ICE.
https://godbolt.org/g/NPtXxH
The same code works on earlier versions 8.1 and 7.3 and Clang.
```
#include
template
struct Foo {
static constexpr int a = 3;
};
template
struct Bar {
static constexpr std::tuple baz = { 1, 2, Foo::a };
// add ^
// to make it compile
};
int main() {
return std::get<2>(Bar::baz);
}
```
[Bug c/86647] New: Test on constant expression (unsigned) -1 < 0 triggers a spurious -Wtype-limits warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86647
Bug ID: 86647
Summary: Test on constant expression (unsigned) -1 < 0 triggers
a spurious -Wtype-limits warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
(unsigned) -1 < 0 triggers a -Wtype-limits warning, while the gcc man page
says:
-Wtype-limits
Warn if a comparison is always true or always false due to the
limited range of the data type, but do not warn for constant
expressions. For example, warn if an unsigned variable is compared
against zero with "<" or ">=". This warning is also enabled by
-Wextra.
i.e. one shouldn't get a warning for constant expressions like (unsigned) -1.
int foo (void)
{
return (unsigned) -1 < 0;
}
zira:~> gcc-snapshot -Wtype-limits -c tst.c
tst.c: In function 'foo':
tst.c:3:24: warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]
return (unsigned) -1 < 0;
^
Note that 1U < 0 does not trigger a warning, as expected. But 2147483648U < 0
triggers it (with 32-bit int). So, it seems that one gets a warning when the
unsigned constant converted to signed would give a negative integer.
The consequence of this bug is that the following macro used to detect signed
integer types
#define SIGNED(T) ((T) -1 < 0)
triggers a warning on unsigned integer types.
[Bug tree-optimization/69224] [6/7 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224 --- Comment #13 from Jeffrey A. Law --- Agreed. I don't see a lot of value in backporting this fix to the release branches. One could argue that decision means this should move to CLOSED as it's been fixed for gcc-8 and the trunk.
[Bug c++/86646] Special member function 'cannot be defaulted' if type alias is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86646 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- ICC rejects it for the same reason, but I don't see any justification for that in the standard. Clang accepts it.
[Bug target/86591] [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Carl Love --- Committed fix
[Bug target/86591] [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591 --- Comment #2 from Carl Love --- Author: carll Date: Mon Jul 23 16:16:41 2018 New Revision: 262934 URL: https://gcc.gnu.org/viewcvs?rev=262934=gcc=rev Log: gcc/testsuite/ChangeLog: 2018-07-23 Carl Love PR 86591 * gcc.target/powerpc/altivec-1-runnable.c: Move vector double tests to file altivec-2-runnable.c. * gcc.target/powerpc/altivec-2-runnable.c: Add vector double tests. * gcc.target/powerpc/buitlins-1.c: Remove dg-final check for xxlor. Update dg-final test for __divdi3 and __udivdi3 instructions. Update comments for instruction generated by vec_mergeh, vec_perm, vec_round, vec_cts, vec_ctu, vec_cpsgn tests. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c trunk/gcc/testsuite/gcc.target/powerpc/builtins-1.c
[Bug tree-optimization/86625] funroll-loops doesn't unroll, producing >3x assembly and running 10x slower than manual complete unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625 --- Comment #7 from Chris Elrod --- (In reply to Chris Elrod from comment #6) > However, for column 23 (2944/128 = 23) with -O3 and column 25 for -O2 of the > 32 columns of A Correction: it was the 16x13 version that used stack data after loading column 25 instead of 23 of A.
[Bug libstdc++/86516] Spurious warning __builtin_memset at O3 when protected by a conditional involving empty()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86516
--- Comment #2 from Paul Gotch ---
I can reproduce this at will with GCC 7.3 it does not reproduce with GCC 8
// Compile with g++ -c -Wextra -Wall -Werror -O3 test.cpp
#include
class Foo
{
public:
Foo() {}
virtual ~Foo()
{
}
// warning only reproduces if this calls inner and is virtual
virtual void outer()
{
inner();
}
void inner()
{
while ( ! vInt.empty() )
{
vInt.resize( vInt.size() - 1 );
}
}
std::vector vInt;
};
// An instantiation of Foo is required for warning to reproduce
void* makeFoo()
{
return new Foo();
}
[Bug tree-optimization/86644] [9 Regression] UBSAN error: tree-vect-patterns.c:225:17: runtime error: shift exponent 64 is too large for 32-bit type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86644 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-23 CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/86618] tree-vect-stmts.c:3340: ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #9 from Qing Zhao --- > --- Comment #8 from Martin Sebor --- > FWIW, it would be safer and more deterministic to fold these invalid calls to > some non-zero value that it is to emit the invalid library call. could you please provide more details on this? what kind of non-zero value should be assigned to these invalid calls?
[Bug tree-optimization/86625] funroll-loops doesn't unroll, producing >3x assembly and running 10x slower than manual complete unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625 --- Comment #6 from Chris Elrod --- (In reply to Richard Biener from comment #3) > If you see spilling on the manually unrolled loop register pressure is > somehow an issue. In the matmul kernel: D = A * X where D is 16x14, A is 16xN, and X is Nx14 (N arbitrarily set to 32) The code holds all of D in registers. 16x14 doubles, and 8 doubles per register mean 28 of the 32 registers. Then, it loads 1 column of A at a time (2 more registers), and broadcasts elements from the corresponding row in each column of X, updating the corresponding column of D with fma instructions. By broadcasting 2 at a time, it should be using exactly 32 registers. For the most part, that is precisely what the manually unrolled code is doing for each column of A. However, for column 23 (2944/128 = 23) with -O3 and column 25 for -O2 of the 32 columns of A, it suddenly spills (all the stack accesses happen for the same column, and none of the others), even though the process is identical for each column. Switching to a smaller 16x13 output, freeing up 2 registers to allow 4 broadcast loads at a time, still resulted in 4 spills (down from 5) for only column #23 or #25. I couldn't reproduce the spills in the avx2 kernel. The smaller kernel has an 8x6 output, taking up 12 registers. Again leaving 4 total registers, 2 for a column of A, and 2 broadcasts from X at a time. So it's the same pattern. The smaller kernel does reproduce the problems with the loops. Both -O3 without `-fdisable-tree-cunrolli` leading to a slow vectorization scheme, and with it or `-O2 -ftree-vectorize` producing repetitive loads and stores within the loop.
[Bug target/86635] [avr] Miscompilation with __memx and libgcc float function __gtsf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635 --- Comment #3 from Georg-Johann Lay --- As a work-around -fno-tree-ter appears to work.
[Bug tree-optimization/86636] [9 Regression] ICE in json::string::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86636
--- Comment #2 from David Malcolm ---
Thanks for filing this.
Segfault happens here in optrecord_json_writer::location_to_json:
206 obj->set ("file", new json::string (LOCATION_FILE (loc)));
due to a NULL value for LOCATION_FILE (loc).
(gdb) call inform (loc, "")
/tmp/test.c: In function ‘n2._loopfn.0’:
cc1: note:
(gdb) p /x loc
$2 = 0x8007
(gdb) p line_table->location_adhoc_data_map.data[7]
$3 = {locus = 0, src_range = {m_start = 0, m_finish = 0}, data =
0x719ebb40}
which is UNKNOWN_LOCATION wrapped with adhoc data.
Fix appears to be to update this conditional to look through ad-hoc data
wrappers:
386 if (item->get_location () != UNKNOWN_LOCATION)
387 json_item->set ("location", location_to_json
(item->get_location ()));
[Bug target/86635] [avr] Miscompilation with __memx and libgcc float function __gtsf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635 Georg-Johann Lay changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Georg-Johann Lay --- Hi, in expand dump there is (insn 8 7 9 (parallel [ (set (reg:SF 22 r22) (mem/u/c:SF (reg/f:PSI 47) [1 a+0 S4 A8 AS7])) (clobber (reg:SF 22 r22)) (clobber (reg:QI 21 r21)) (clobber (reg:HI 30 r30)) ]) "foo.c":4 -1 (nil)) so the problem is that the middle-end provides a hard reg as target that overlaps one of the interface regs. This reminds me of PR63633 / PR65657. PR63633 fixed the 3-operand insns case that use hard regs used in the transparent libgcc calls. The intention of the clobber of reg 22 (and the other clobbers) is to keep passes from propagating anything that overlaps the clobbers into an operand of the insn, xload_A at that time. The very libcall (xload__libgcc) with its proper operands is generated from that insn during .split1. FYI, I tried the "proper" solution (use 1-reg constraints etc. and let reg-alloc do the job) several times and with different versions of gcc, and I always failed miserably: the code bloat was not acceptable, in particular with DImode (cf. also PR85805). Lest alone all the spill fails to expect with such a solution. Thank you for taking care of this; at the moment all I can do is commenting from the distance and try to help with analysis and the rationals behind the current code.
[Bug c/85704] [8/9 Regression] cc1 run out of memory when it compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 44425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44425=edit gcc9-pr85704.patch Untested fix. If people use thousands of consecutive zero sized fields in structures, this could be compile time problematic, but we unfortunately don't have any sort of monotonically increasing ids for FIELD_DECLs within the same structure.
[Bug tree-optimization/86625] funroll-loops doesn't unroll, producing >3x assembly and running 10x slower than manual complete unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625 --- Comment #5 from Chris Elrod --- Created attachment 44424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44424=edit Smaller avx512 kernel that still spills into the stack This generated 18 total `vmovapd` (I think there'd ideally be 0) when compiled with: gfortran -march=skylake-avx512 -mprefer-vector-width=512 -O2 -ftree-vectorize -shared -fPIC -S kernels16x32x13.f90 -o kernels16x32x13.s 4 of which moved onto the stack, and one moved from the stack back into a register. (The others were transfered from the stack within vfmadd instructions: `vfmadd213pd72(%rsp), %zmm11, %zmm15` ) Similar to the larger kernel, using `-O3` instead of `-O2 -ftree-vectorize` eliminated two of the `vmovapd`instructions between registers, but none of the spills.
[Bug tree-optimization/86625] funroll-loops doesn't unroll, producing >3x assembly and running 10x slower than manual complete unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625 --- Comment #4 from Chris Elrod --- Created attachment 44423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44423=edit 8x16 * 16x6 kernel for avx2. Here is a scaled down version to reproduce most of the the problem for avx2-capable architectures. I just used march=haswell, but I think most recent architectures fall under this. For some, like zenv1, you may need to add -mprefer-vector-width=256. To get the inefficiently vectorized loop: gfortran -march=haswell -Ofast -shared -fPIC -S kernelsavx2.f90 -o kernelsavx2bad.s To get only the unnecessary loads/stores, use: gfortran -march=haswell -O2 -ftree-vectorize -shared -fPIC -S kernelsavx2.f90 -o kernelsavx2.s This file compiles instantly, while with `O3` the other one can take a couple seconds. However while it does `vmovapd` between registers, it no longer spills into the stack in the manually unrolled version, like the avx512 kernel does.
[Bug c++/86619] Missed optimization opportunity with array aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
--- Comment #4 from Michael Veksler ---
It is interesting to check the impact on numerical C++ benchmarks.
Fortran has a conceptual restrict on all its parameter arrays,
since aliasing is not allowed.
void f(int * __restrict__ v1, int * __restrict__ v2, int n)
{
for (int i=0 ; i < n ; i++)
v1[0] += v2[i];
}
and Fortran:
subroutine f(v1, v2, n)
integer :: v1(100)
integer :: v2(100)
integer :: n
DO i=1, n
v1(1) = v1(1) + v2(i)
END DO
end subroutine f
Generate the same loop:
.L3:
addl(%rdx), %eax
addq$4, %rdx
cmpq%rdx, %r8
jne .L3
But without restrict, as expected, g++ generates:
.L8:
addl(%rdx), %eax
addq$4, %rdx
cmpq%r8, %rdx
movl%eax, (%rcx)
jne .L8
Running both variants from a loop (in a separate translation unit,
without whole program optimization) (g++ 7.2.0 with -O2 on 64 bit cygwin):
#include
#include
void f(int * __restrict__ v1, int *__restrict__ v2, int SIZE);
void g(int * v1, int * v2, int SIZE);
constexpr int SIZE = 1'000'000;
int v2[SIZE];
int main()
{
int v1;
f(, v2, SIZE); // Warm up cache
auto start = std::clock();
constexpr int TIMES = 10'000;
for (int i=0 ; i < TIMES; ++i) {
v1 = 0;
f(, v2, SIZE);
}
auto t1 = std::clock();
for (int i=0 ; i < TIMES; ++i) {
v1 = 0;
g(, v2, SIZE);
}
auto t2 = std::clock();
std::cout << "with restrict: "
<< double(t1 - start) / CLOCKS_PER_SEC << " sec\n";
std::cout << "without restrict: "
<< double(t2 - t1) / CLOCKS_PER_SEC << " sec\n";
}
And the results are:
with restrict: 4.477 sec
without restrict: 5.756 sec
Which clearly demonstrates the impact of good alias analysis.
With plain C pointers, this is an unavoidable price.
But unfortunately this also happens when passing pointers or
references to arrays of different sizes, or when inheriting two
different types from std::array, in order to mark the parameters
as non-aliasing.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #43 from Wilco --- (In reply to qinzhao from comment #42) > just checked in the patch for fixing the unsigned char issue as: > https://gcc.gnu.org/viewcvs/gcc?view=revision=262907 That looks it is using unsigned char accesses indeed. One more thing: the expansion happens both with -Os and -O0, and that shouldn't happen. The memcmp expansion works from -O2 onwards, which is probably a good choice for the strcmp too (a single char could be optimized with -Os but that would be the empty string).
[Bug c++/86646] New: Special member function 'cannot be defaulted' if type alias is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86646
Bug ID: 86646
Summary: Special member function 'cannot be defaulted' if type
alias is used
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: programmer at posteo dot de
Target Milestone: ---
GCC 7.3.0 (as well as 8.1 and 9.0 from godbolt.org) fails to compile the
following code:
//---
template
struct Foo {
static constexpr int N = N_;// this indirection causes the error
using Self = Foo;
Foo(const Self&) = default;
};
//---
The error message reads
> file.cpp:6:22: error: ‘Foo::Foo(const Self&)’ cannot be defaulted
I used the following command line to obtain that error message:
> g++ -Wall -Wextra -std=c++11 file.cpp
[Bug c/86617] [6/7/8/9 Regression] Volatile qualifier is ignored sometimes for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617 --- Comment #8 from Bernd Edlinger --- Author: edlinger Date: Mon Jul 23 13:23:51 2018 New Revision: 262933 URL: https://gcc.gnu.org/viewcvs?rev=262933=gcc=rev Log: gcc: 2018-07-23 Bernd Edlinger PR c/86617 * genmatch.c (dt_operand::gen_match_op): Avoid folding volatile values. testsuite: 2018-07-23 Bernd Edlinger PR c/86617 * gcc.dg/pr86617.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr86617.c Modified: trunk/gcc/ChangeLog trunk/gcc/genmatch.c trunk/gcc/testsuite/ChangeLog
[Bug target/86635] [avr] Miscompilation with __memx and libgcc float function __gtsf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635
--- Comment #1 from Senthil Kumar Selvaraj ---
Created attachment 44422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44422=edit
pr86635.patch
Looks like ud_dce removes the insn that sets reg:SF r22 because the insn says
r22 is clobbered. The below insn is in the previous pass dump (init-regs), and
ud_dce deletes insns 8, presumably because the output register is clobbered by
the insn.
(insn 8 7 9 2 (parallel [
(set (reg:SF 22 r22)
(mem/u/c:SF (reg/f:PSI 47) [1 a+0 S4 A8 AS7]))
(clobber (reg:SF 22 r22))
(clobber (reg:QI 21 r21))
(clobber (reg:HI 30 r30))
]) "test.c":4 36 {xloadsf_A}
(expr_list:REG_DEAD (reg/f:PSI 47)
(expr_list:REG_UNUSED (reg:HI 30 r30)
(expr_list:REG_EQUAL (mem/u/c:SF (symbol_ref:PSI ("a") [flags
0xe40] ) [1 a+0 S4 A8 AS7])
(nil)
This pattern is generated via a gen_xload_A call in mov expander,
so adding constraints to xload_A will not help.
Forcing the dest to be a pseudo (attached patch) fixes the problem - other
passes see the clobber, remove it and use reg:SF r22 as the output reg.
[Bug middle-end/86645] [9 Regression] UBSAN error: tree-cfg.c:7874:26: runtime error: load of value 4293224825, which is not a valid value for type 'dump_flag'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86645 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-23 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I've got patch for it.
[Bug middle-end/86645] New: [9 Regression] UBSAN error: tree-cfg.c:7874:26: runtime error: load of value 4293224825, which is not a valid value for type 'dump_flag'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86645 Bug ID: 86645 Summary: [9 Regression] UBSAN error: tree-cfg.c:7874:26: runtime error: load of value 4293224825, which is not a valid value for type 'dump_flag' Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Blocks: 63426 Target Milestone: --- Seen for any test-case. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug bootstrap/86630] gcc/graphite.c build failure on AIX 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Ok, resolving then, GCC 5 is no longer maintained and GCC 6 is fixed.
[Bug tree-optimization/86644] [9 Regression] UBSAN error: tree-vect-patterns.c:225:17: runtime error: shift exponent 64 is too large for 32-bit type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86644 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/86642] Spurious return type warning with enable_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642 --- Comment #4 from Steinar H. Gunderson --- (In reply to Jonathan Wakely from comment #3) > (In reply to Steinar H. Gunderson from comment #0) > > Same issue with 4.9, so no regression. Clang has the same issue. > > That should have been your first clue that the problem is at your end, not > in both compilers. Maybe, but they share libstdc++, which could have had some kind of missing regression.
[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159 Jonathan Wakely changed: What|Removed |Added CC||eric at efcs dot ca --- Comment #5 from Jonathan Wakely --- *** Bug 77923 has been marked as a duplicate of this bug. ***
[Bug c++/77923] GCC emits "declares nothing" diagnostic on meaningful declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77923 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Oh I have a patch for this (and it's a dup) *** This bug has been marked as a duplicate of bug 66159 ***
[Bug c++/86642] Spurious return type warning with enable_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642 --- Comment #3 from Jonathan Wakely --- (In reply to Steinar H. Gunderson from comment #0) > Same issue with 4.9, so no regression. Clang has the same issue. That should have been your first clue that the problem is at your end, not in both compilers.
[Bug bootstrap/86630] gcc/graphite.c build failure on AIX 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630 --- Comment #3 from The Written Word --- (In reply to Richard Biener from comment #2) > GCC assumes that inttypes.h contains PRIx64 It does. gcc/system.h has: /* Define this so that inttypes.h defines the PRI?64 macros even when compiling with a C++ compiler. Define it here so in the event inttypes.h gets pulled in by another header it is already defined. */ #define __STDC_FORMAT_MACROS However, as I built with ISL, gcc/graphite.c includes the ISL .h files before gcc/system.h meaning __STDC_FORMAT_MACROS gets defined after inttypes.h is pulled in, avoiding the definition of PRIx64. This #include order in gcc/graphite.c was fixed for gcc-6 so this problem seems to be limited to gcc-5 so I need to find a way around this.
[Bug libstdc++/86513] ostringstream default constructor missing from libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86513 Jonathan Wakely changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Jonathan Wakely --- *** Bug 86643 has been marked as a duplicate of this bug. ***
[Bug c++/86643] [9 Regression] basic_ostringstream usage leads to:undefined reference to `std::__cxx11::basic_stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Jonathan Wakely ---
(In reply to Tobias Burnus from comment #1)
> Culprit is r262474 - "P0935R0 Eradicating unnecessarily explicit default
> constructors"
>
>
> Looking closer at the example, it doesn't use std::basic_ostringstream as
> advertised but:
>std::ostringstream buf2("test", std::ios_base::ate);
>
> The "std::ostringstream" is deprecated
What? No it isn't.
> and replacing it by
>std::basic_ostringstream buf2("test", std::ios_base::ate);
> works.
>
>
> The question is whether the patch intended to remove the deprecated support
> for std::ostringstream or not. If it did, I think that warrens an entry at
> https://gcc.gnu.org/gcc-9/changes.html ; if not, then it needs to be fixed.
No support for anything has been removed. You need a clean build.
*** This bug has been marked as a duplicate of bug 86513 ***
[Bug c/85704] [8/9 Regression] cc1 run out of memory when it compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection,|
|needs-reduction |
CC||dave.pagan at oracle dot com,
||jsm28 at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Reduced testcase for -Os:
struct C { struct {} c; };
struct D { int d; struct C e; int f; };
void
foo (struct D *x)
{
*x = (struct D) { .e = (struct C) { .c = {} } };
}
[Bug tree-optimization/86644] New: [9 Regression] UBSAN error: tree-vect-patterns.c:225:17: runtime error: shift exponent 64 is too large for 32-bit type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86644 Bug ID: 86644 Summary: [9 Regression] UBSAN error: tree-vect-patterns.c:225:17: runtime error: shift exponent 64 is too large for 32-bit type 'int' Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rdsandiford at googlemail dot com Blocks: 63426 Target Milestone: --- Probably starting with r262276 I see: $ ./xgcc -B. -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto -fno-use-linker-plugin -flto-partition=none -Wno-stringop-overflow -ftree-vectorize -c -o pr55569.o /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr55569.c /home/marxin/Programming/gcc/gcc/tree-vect-patterns.c:225:17: runtime error: shift exponent 64 is too large for 32-bit type 'int' Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug tree-optimization/86628] Missed simplification of division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #6 from rguenther at suse dot de ---
On Mon, 23 Jul 2018, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
>
> --- Comment #5 from Marc Glisse ---
> (In reply to Richard Biener from comment #4)
> > Yeah, generally we can't associate because (x*y)*z may not overflow because
> > x == 0 but x*(y*z) may because y*z overflows.
>
> We can do it
>
> - in the wrapping case (I think you were considering making signed operations
> wrap starting from a late reassoc pass)
Yes.
> - when y*z gets computed anyway (if y*z is computed before x*y*z, value
> numbering could help, but otherwise, it is inconvenient, one would either have
> to let x*y*z register a trigger (not a true value) for y*z, or make several
> passes. It may be easier to walk through the uses of z when we see x*y*z with
> a
> single-use x*y)
>
> > I wonder if we have in general ((x*y)*z)*...)*k what it takes to prove
> > that it is valid to factor out a random pair (already computed elsewhere).
> > I suppose we have to move that factored pair innermost for the case it
> > is zero?
>
> Or outermost for the case something else is 0? It seems hard unless you know
> that no variable is 0 or -1 and all the operations are adjacent. The good
> thing
> is that the frequency of occurrence decreases quickly with the size of the
> pattern, so handling the case of size 3 might reap a large part of the
> benefits.
OK, so one possibility is to do this at VN elimination time when
seeing x*c match (a*b)*c and see whether {a,b}*c is available, if so
replace x*c accordingly. This might not make the computation of x
dead though.
Generally reassoc is a global association + CSE problem of course
but reassoc is currently formulated as a local problem.
[Bug c/86618] tree-vect-stmts.c:3340: ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 CC||marxin at gcc dot gnu.org Blocks||63426 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c++/86642] Spurious return type warning with enable_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642 Steinar H. Gunderson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Steinar H. Gunderson --- You're right; this was too hasty. Thanks!
[Bug c++/86643] [9 Regression] basic_ostringstream usage leads to:undefined reference to `std::__cxx11::basic_stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643
--- Comment #1 from Tobias Burnus ---
Culprit is r262474 - "P0935R0 Eradicating unnecessarily explicit default
constructors"
Looking closer at the example, it doesn't use std::basic_ostringstream as
advertised but:
std::ostringstream buf2("test", std::ios_base::ate);
The "std::ostringstream" is deprecated and replacing it by
std::basic_ostringstream buf2("test", std::ios_base::ate);
works.
The question is whether the patch intended to remove the deprecated support for
std::ostringstream or not. If it did, I think that warrens an entry at
https://gcc.gnu.org/gcc-9/changes.html ; if not, then it needs to be fixed.
Cross ref:
P0935R0 is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0935r0.html
Patch causing the regression is
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00318.html
[Bug c++/86619] Missed optimization opportunity with array aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619 --- Comment #3 from rguenther at suse dot de --- On Mon, 23 Jul 2018, mickey.veksler at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619 > > --- Comment #2 from Michael Veksler --- > >> type-based alias analysis doesn't distinguish between int[2] and int[3]. > > Is it just the way GCC implements type-based alias analysis, > or is it defined that way in the C and C++ standards? It's the way GCC implements it. > I suspect that the weaker alias analysis of arrays (int [size] and > std::array) is one of the things that make C++ slower than > Fortran on some benchmarks. Not sure - Fortran shares the restriction and also uses pointer-based accesses. Fortran is just more constrained so it can put __restrict on its arrays as an implementation detail very aggressively.
[Bug c/85704] [8/9 Regression] cc1 run out of memory when it compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Started with r258497 aka PR46921 fix.
[Bug target/82092] [8/9 regression] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 Eric Gallager changed: What|Removed |Added CC||zfefm at gmx dot de --- Comment #17 from Eric Gallager --- *** Bug 86639 has been marked as a duplicate of this bug. ***
[Bug other/86639] building gcc from source fails with Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86639 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Eric Gallager --- dup of bug 82092 *** This bug has been marked as a duplicate of bug 82092 ***
[Bug c++/86642] Spurious return type warning with enable_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642 W E Brown changed: What|Removed |Added CC||webrown.cpp at gmail dot com --- Comment #1 from W E Brown --- I believe this issue is based on a minor misunderstanding. As written, the return type is never a void type. However, a small adjustment in the return type gives what seems to be the intended effect: std::enable_if_t // assumes C++14 or later or typename std::enable_if::type // any C++ dialect Either will work to invoke the enable_if metafunction and produce a SFINAE effect. However, as written, the metafunction is not invoked and so does not activate SFINAE. However, as written, the code says that func will return an object of this metafunction's type; since the function does not do so, the warning seems correct. I respectfully recommend this issue be closed as INVALID.
[Bug c++/86605] Suboptimal code for pointer arithmetic with 'this'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86605 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Seems this started with r245949 which was an i386 backend change.
[Bug middle-end/86627] [6/7/8/9 Regression] Signed 128-bit division by 2 no longer expanded to RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 44421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44421=edit gcc9-pr86627.patch Untested fix. For / 3 etc. we'd need to rewrite choose_multiplier to work on wide_ints fully I guess.
[Bug target/86547] s390x: Maximum number of LRA assignment passes is achieved (30) when compiling a small inline assembler snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86547 --- Comment #2 from Ilya Leoshkevich --- I dug a bit deeper and found that this used to compile without errors on gcc-4_8_5-release. Bisect points to s390-specific commit 7b1bda1c, which first appeared in gcc-4_9_0-release: 2013-06-06 Vladimir Makarov * config/s390/s390.opt (mlra): New option. * config/s390/s390.c (s390_decompose_address): Check displacement for all registers for LRA. (s390_secondary_reload): Don't used secondary reloads for LRA. (s390_lra_p): New function. (TARGET_LRA_P): Define. * config/s390/s390.md (*movmem_short, *clrmem_short): Change value of attribute cpu_facility to zarch for the last alternative. (*cmpmem_short): Ditto. This commit appears to have introduced LRA for s390x.
[Bug tree-optimization/86628] Missed simplification of division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628 --- Comment #5 from Marc Glisse --- (In reply to Richard Biener from comment #4) > Yeah, generally we can't associate because (x*y)*z may not overflow because > x == 0 but x*(y*z) may because y*z overflows. We can do it - in the wrapping case (I think you were considering making signed operations wrap starting from a late reassoc pass) - when y*z gets computed anyway (if y*z is computed before x*y*z, value numbering could help, but otherwise, it is inconvenient, one would either have to let x*y*z register a trigger (not a true value) for y*z, or make several passes. It may be easier to walk through the uses of z when we see x*y*z with a single-use x*y) > I wonder if we have in general ((x*y)*z)*...)*k what it takes to prove > that it is valid to factor out a random pair (already computed elsewhere). > I suppose we have to move that factored pair innermost for the case it > is zero? Or outermost for the case something else is 0? It seems hard unless you know that no variable is 0 or -1 and all the operations are adjacent. The good thing is that the frequency of occurrence decreases quickly with the size of the pattern, so handling the case of size 3 might reap a large part of the benefits.
[Bug c++/86619] Missed optimization opportunity with array aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619 --- Comment #2 from Michael Veksler --- >> type-based alias analysis doesn't distinguish between int[2] and int[3]. Is it just the way GCC implements type-based alias analysis, or is it defined that way in the C and C++ standards? I suspect that the weaker alias analysis of arrays (int [size] and std::array) is one of the things that make C++ slower than Fortran on some benchmarks.
[Bug c++/86643] [9 Regression] basic_ostringstream usage leads to:undefined reference to `std::__cxx11::basic_stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/86643] New: [9 Regression] basic_ostringstream usage leads to:undefined reference to `std::__cxx11::basic_stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643 Bug ID: 86643 Summary: [9 Regression] basic_ostringstream usage leads to:undefined reference to `std::__cxx11::basic_stringstream Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Compiling ostringstream example fails to link with GCC 9 (today's version); works with GCC 8. # g++ foo.cc /tmp/ccBHU05J.o: In function `main': foo.cc:(.text+0x17): undefined reference to `std::__cxx11::basic_stringstream, std::allocator >::basic_stringstream()' collect2: error: ld returned 1 exit status Example from: https://en.cppreference.com/w/cpp/io/basic_ostringstream/basic_ostringstream
[Bug debug/86638] Og guality failures without -ftree-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86638
--- Comment #3 from Tom de Vries ---
(In reply to Richard Biener from comment #2)
> Hmm, it sounds like DCE/DSE should insert
>
> # DEBUG x$a => x$a_11
>
> kind debug stmts. IIRC SRA does more than that, adding DECL_DEBUG_EXPRs
> with magic.
>
> Not sure if the debug stmts itself help enough here.
At cddce1, we have:
...
__attribute__((noclone, noinline))
foo (int fd, union U x)
{
int result;
int _1;
_Bool _2;
_Bool _4;
int _5;
:
# DEBUG BEGIN_STMT
_1 = x.a;
_2 = _1 != 0;
result_8 = (int) _2;
# DEBUG result => result_8
# DEBUG BEGIN_STMT
if (fd_9(D) != 0)
goto ; [INV]
else
goto ; [INV]
:
# DEBUG BEGIN_STMT
_4 = _1 == 0;
result_10 = (int) _4;
# DEBUG result => result_10
:
# result_6 = PHI
# DEBUG result => result_6
# DEBUG BEGIN_STMT
__asm__ __volatile__("nop" : : : "memory");
# DEBUG BEGIN_STMT
_5 = x.a;
z ={v} _5;
# DEBUG BEGIN_STMT
- x.a = 6;
# DEBUG BEGIN_STMT
__asm__ __volatile__("nop" : : : "memory");
# DEBUG BEGIN_STMT
return result_6;
}
...
So, are you proposing to keep track of components like this:
...
- x.a = 6;
+ # DEBUG x.a => 6
...
?
[Bug c/86617] [6/7/8/9 Regression] Volatile qualifier is ignored sometimes for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617 --- Comment #7 from Bernd Edlinger --- Yes. Sure.
[Bug c/86617] [6/7/8/9 Regression] Volatile qualifier is ignored sometimes for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617 --- Comment #6 from rguenther at suse dot de --- On Mon, 23 Jul 2018, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617 > > --- Comment #5 from Bernd Edlinger --- > (In reply to Richard Biener from comment #3) > > but I guess that doesn't work because the counting is missing. OTOH > > two same SAVE_EXPRs () are not operand_equal_p but SAVE_EXPRs have > > TREE_SIDE_EFFECTS set but we can safely handle SAVE_EXPR + SAVE_EXPR. > > > > shouldn't that be fixed in operand_equal_p ? Probably. Can you test your patch and post it?
[Bug middle-end/86640] [8/9 regression] ICE in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||segher at gcc dot gnu.org Target Milestone|--- |8.2
[Bug tree-optimization/86625] funroll-loops doesn't unroll, producing >3x assembly and running 10x slower than manual complete unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||53947 --- Comment #3 from Richard Biener --- If you see spilling on the manually unrolled loop register pressure is somehow an issue. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/77923] GCC emits "declares nothing" diagnostic on meaningful declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77923 --- Comment #1 from Eric Fiselier --- Ping. I keep hitting this more and more. GCC seems to be warning because the declaration includes the CXX scope specifier "::foo". Removing the "::" seems to work. However, removing the "::" causes the code to take on a different semantic meaning. The warning shouldn't be issued in either case.
[Bug c++/86642] New: Spurious return type warning with enable_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
Bug ID: 86642
Summary: Spurious return type warning with enable_if
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
The following program gives a warning with -Wall:
#include
std::enable_if
func() {}
klump:~> g++-8 -O2 -std=gnu++14 -Wall -c test.cpp
test.cpp: In function ‘std::enable_if func()’:
test.cpp:4:9: warning: no return statement in function returning non-void
[-Wreturn-type]
func() {}
^
The function technically returns non-void, but in reality, it returns void
(nothing will ever look at its return type). Thus, the warning should not
really be there.
Same issue with 4.9, so no regression. Clang has the same issue.
[Bug c++/86641] New: Regression: non-ODR used auto class data members fail to deduce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86641
Bug ID: 86641
Summary: Regression: non-ODR used auto class data members fail
to deduce.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric at efcs dot ca
Target Milestone: ---
In some situations, GCC will fail to resolve the storage size of auto variables
which are not not directly ODR used:
For example:
// std=c++17
struct MyT {
constexpr MyT(long x) : value(x) {}
long value;
};
namespace {
template
struct test_case {
// error: storage size of '{anonymous}::test_case::value' isn't known
static constexpr auto value = T(100);
static constexpr T use_value = value;
};
}
test_case TC;
This only occurs in C++17 and newer. It seems to be a regression from GCC 8.x.
According to jwakely, this seems related to r260150.
[Bug middle-end/86640] [8/9 regression] ICE in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640 Ramana Radhakrishnan changed: What|Removed |Added Keywords||ice-on-valid-code Target||arm-none-linux-gnueabihf Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan --- confirmed.
[Bug middle-end/86640] New: [8/9 regression] ICE in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640
Bug ID: 86640
Summary: [8/9 regression] ICE in combine
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ramana at gcc dot gnu.org
Target Milestone: ---
char fn1() {
long long b[5];
for (int a = 0; a < 5; a++)
b[a] = ~0ULL;
return b[3];
}
$> arm-none-linux-gnueabihf-gcc -c -O3 -mfpu=neon -mfloat-abi=hard
-march=armv7-a /tmp/crash.c
during RTL pass: combine
/tmp/crash.c: In function ‘fn1’:
/tmp/crash.c:11:1: internal compiler error: in do_SUBST, at combine.c:731
}
^
0x12e637c do_SUBST
/tmp/dgboter/bbs/bc-b3-3-13--rhe6x86_64/buildbot/rhe6x86_64--arm-none-linux-gnueabihf/build/src/gcc/gcc/combine.c:730
0x12f913e subst
/tmp/dgboter/bbs/bc-b3-3-13--rhe6x86_64/buildbot/rhe6x86_64--arm-none-linux-gnueabihf/build/src/gcc/gcc/combine.c:5589
0x12fb2d1 try_combine
/tmp/dgboter/bbs/bc-b3-3-13--rhe6x86_64/buildbot/rhe6x86_64--arm-none-linux-gnueabihf/build/src/gcc/gcc/combine.c:3359
0x1301398 combine_instructions
/tmp/dgboter/bbs/bc-b3-3-13--rhe6x86_64/buildbot/rhe6x86_64--arm-none-linux-gnueabihf/build/src/gcc/gcc/combine.c:1299
0x1301398 rest_of_handle_combine
/tmp/dgboter/bbs/bc-b3-3-13--rhe6x86_64/buildbot/rhe6x86_64--arm-none-linux-gnueabihf/build/src/gcc/gcc/combine.c:14898
0x1301398 execute
/tmp/dgboter/bbs/bc-b3-3-13--rhe6x86_64/buildbot/rhe6x86_64--arm-none-linux-gnueabihf/build/src/gcc/gcc/combine.c:14943
[Bug c/86617] [6/7/8/9 Regression] Volatile qualifier is ignored sometimes for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617 --- Comment #5 from Bernd Edlinger --- (In reply to Richard Biener from comment #3) > but I guess that doesn't work because the counting is missing. OTOH > two same SAVE_EXPRs () are not operand_equal_p but SAVE_EXPRs have > TREE_SIDE_EFFECTS set but we can safely handle SAVE_EXPR + SAVE_EXPR. > shouldn't that be fixed in operand_equal_p ?
[Bug middle-end/86627] [6/7/8/9 Regression] Signed 128-bit division by 2 no longer expanded to RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- My r242690 aka PR78416 fix. I'll have a look.
[Bug c++/86620] __attribute__((no inline)) gives incorrect warning with overloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86620 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- On trunk reported since r248387.
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c/86617] [6/7/8/9 Regression] Volatile qualifier is ignored sometimes for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617 --- Comment #4 from Bernd Edlinger --- this comment in match.pd made me look at operand_equal_p: /* Simplify x - x. This is unsafe for certain floats even in non-IEEE formats. In IEEE, it is unsafe because it does wrong for NaNs. Also note that operand_equal_p is always false if an operand is volatile. */
[Bug debug/86638] Og guality failures without -ftree-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86638 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Hmm, it sounds like DCE/DSE should insert # DEBUG x$a => x$a_11 kind debug stmts. IIRC SRA does more than that, adding DECL_DEBUG_EXPRs with magic. Not sure if the debug stmts itself help enough here.
[Bug fortran/86626] ICE in get_array_charlen at gcc/fortran/trans-array.c:6870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86626 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|ICE |ICE in get_array_charlen at ||gcc/fortran/trans-array.c:6 ||870 --- Comment #2 from Martin Liška --- All releases I have (4.5.0+) ICE on that.
[Bug tree-optimization/86632] Incorrect value copied into output array with -O3 ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Richard Biener --- Dup then. *** This bug has been marked as a duplicate of bug 82108 ***
[Bug target/82108] [7 Regression] Wrong vectorized code generated for x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108 Richard Biener changed: What|Removed |Added CC||ketan.surender at gmail dot com --- Comment #8 from Richard Biener --- *** Bug 86632 has been marked as a duplicate of this bug. ***
[Bug other/86639] New: building gcc from source fails with Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86639 Bug ID: 86639 Summary: building gcc from source fails with Mac OS 10.9 Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: zfefm at gmx dot de Target Milestone: --- Created attachment 44420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44420=edit configure output I try to build gcc 8.1.0 from source on a Mac with OS 10.9.5. Build fails with following error (see end of attached gcc-make-output.txt): A linker snapshot was created at: /tmp/libgcc_s.dylib-2018-06-23-105655.ld-snapshot ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse, file /SourceCache/ld64/ld64-241.9/src/ld/parsers/macho_relocatable_file.cpp, line 1745. collect2: error: ld returned 1 exit status make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 I tried on two different Mac with OS 10.9.5, I even did a clean install of OS 10.9.5 and the developer tools, I run always in the same error. I can build gcc 7.3.0 with OS 10.9.5, or gcc 8.1.0 with OS 10.13 without any error. I attached the output of: $ ../configure --prefix=/usr/local/gcc-8.1 \ > --with-gmp=/usr/local/gcc-8.1 \ > --with-mpfr=/usr/local/gcc-8.1 \ > --with-mpc=/usr/local/gcc-8.1 \ > --enable-languages=c,c++,fortran \ > --with-isl=/usr/local/gcc-8.1 \ > --program-suffix=-8.1 &> gcc-conf-output.txt If needed I can also send the complete output of make (large!) and the mentioned /tmp/libgcc_s.dylib-2018-06-23-105655.ld-snapshot.
[Bug tree-optimization/86632] Incorrect value copied into output array with -O3 ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to work||7.3.0, 8.1.0, 9.0 Ever confirmed|0 |1 Known to fail||6.4.0, 7.2.0 --- Comment #4 from Martin Liška --- Confirmed, fixed on trunk in r251790, which is backported to GCC 7.x branch.
[Bug middle-end/86631] [9 Regression] missing -Walloc-size-larger-than on ILP32 hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86631 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug bootstrap/86630] gcc/graphite.c build failure on AIX 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630 --- Comment #2 from Richard Biener --- GCC assumes that inttypes.h contains PRIx64
[Bug tree-optimization/86628] Missed simplification of division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-23 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- (In reply to Marc Glisse from comment #3) > We already simplify some simple cases like x*t/t -> x in match.pd. Larger > cases are for a pass like reassoc. In this particular case, we could also > imagine somehow noticing that (x*y)*z is better reassociated as x*(y*z) > because y*z is already computed. Yeah, generally we can't associate because (x*y)*z may not overflow because x == 0 but x*(y*z) may because y*z overflows. I wonder if we have in general ((x*y)*z)*...)*k what it takes to prove that it is valid to factor out a random pair (already computed elsewhere). I suppose we have to move that factored pair innermost for the case it is zero? Note the reassoc pass doesn't handle TYPE_OVERFLOW_UNDEFINED types at all at the moment. > A later pass would then cleanup x*t/t. > Simplifying the unsigned case looks wrong to me.
