[Bug c++/86500] accepts-invalid with :: before decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86500 Martin Sebor changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-12 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. Clang, ICC, and MSVC all reject it.
[Bug c++/86499] lambda-expressions with capture-default are allowed at namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86499
Martin Sebor changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-12
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. Clang rejects it with:
error: non-local lambda expression cannot have a capture-default
auto l = [=]{};
^
ICC and MSVC also accept it.
Please remember include compiler options and output in bug reports:
https://gcc.gnu.org/bugs
[Bug c++/86498] g++ allows conversion from string literal to non-const char* in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86498 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-12 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. Clang compiles it fine. ICC and MSVC also reject it. Please include compiler output in bug reports: https://gcc.gnu.org/bugs
[Bug c++/84993] Combination of fieldnames and accessor suggestions for misspelled private fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84993 David Malcolm changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00594.html
[Bug c++/86503] New: Segmentation fault signal terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86503
Bug ID: 86503
Summary: Segmentation fault signal terminated
Product: gcc
Version: 8.1.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:
template< bool c, class T >
struct enable_if {
typedef T type;
};
template< class T >
struct enable_if< true, T > {};
template< class F, int n >
void
ft( F f, typename enable_if< n == 0, int >::type ) {}
template< class F, int n >
typeof( ft< F, n-1 >( F(), 0 ) )
ft( F f, typename enable_if< n != 0, int >::type ) {}
int main() {
ft< struct a*, 2 >( 0, 0 );
}
g++ produces the following error message:
3regressiontestusingG++typeof.cpp: In substitution of 'template
__typeof__ (ft(F(), 0)) ft(F, typename enable_if<(n != 0),
int>::type) [with F = main()::a*; int n = -897]':
3regressiontestusingG++typeof.cpp:14:21: recursively required by substitution
of 'template __typeof__ (ft(F(), 0)) ft(F, typename
enable_if<(n != 0), int>::type) [with F = main()::a*; int n = 1]'
3regressiontestusingG++typeof.cpp:14:21: required by substitution of
'template __typeof__ (ft(F(), 0)) ft(F, typename
enable_if<(n != 0), int>::type) [with F = main()::a*; int n = 2]'
3regressiontestusingG++typeof.cpp:18:30: required from here
3regressiontestusingG++typeof.cpp:14:21: fatal error: template instantiation
depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum)
typeof( ft< F, n-1 >( F(), 0 ) )
~~^~~~
compilation terminated.
So, I change the command line to:
g++ -ftemplate-depth=100 3regressiontestusingG++typeof.cpp
This time, the error message is as follow:
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/86502] friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86502 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 59480. *** This bug has been marked as a duplicate of bug 59480 ***
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 Andrew Pinski changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #8 from Andrew Pinski --- *** Bug 86502 has been marked as a duplicate of this bug. ***
[Bug c++/86502] New: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86502
Bug ID: 86502
Summary: friend declaration specifying a default argument must
be a definition
Product: gcc
Version: 8.1.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 Test
{
friend const int getInt(int inInt = 0);
};
g++ accepts it, but clang++ rejects it:
error: friend declaration specifying a default argument must be a definition
[Bug c++/86501] New: shadow template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86501
Bug ID: 86501
Summary: shadow template parameter
Product: gcc
Version: 8.1.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 follows:
template < int V >
struct A
{
struct B
{
template < int > friend struct V;
};
};
A < 0 >::B a;
g++ accepts the code, but clang++ rejects it:
error: declaration of 'V' shadows template parameter
template < int > friend struct V;
^
note: template parameter is declared here
template < int V >
^
1 error generated.
[Bug c++/86500] New: accepts-invalid with :: before decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86500
Bug ID: 86500
Summary: accepts-invalid with :: before decltype
Product: gcc
Version: 8.1.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: ---
g++ incorrectly accepts this:
struct S { struct T {}; };
::decltype(S())::T st;
clang++ rejects it:
error: expected unqualified-id
[Bug c++/86499] New: lambda-expressions with capture-default are allowed at namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86499
Bug ID: 86499
Summary: lambda-expressions with capture-default are allowed at
namespace scope
Product: gcc
Version: 8.1.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: ---
g++ incorrectly accepts this:
auto l = [=]{};
Per C++1y [expr.lambda]p9 this is ill-formed: only local lambda expressions may
have capture-defaults (even if they don't actually capture anything).
[Bug c++/86498] New: g++ allows conversion from string literal to non-const char* in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86498
Bug ID: 86498
Summary: g++ allows conversion from string literal to non-const
char* in C++11 mode
Product: gcc
Version: 8.1.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: ---
g++ rejects this valid C++11 code:
void f(char*);
int (...);
int = f("foo");
There is no conversion from string literal to non-const char* in C++11.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #8 from Alexander Monakov --- (In reply to H.J. Lu from comment #7) > It is to be consistent for common symbol linked against .a or .so. That seems like a really strange reason because without --whole-archive there are other ways to arrive at an apparent "inconsistency", while with --whole-archive there's no need for special treatment as the "consistent" result is achieved automatically.
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 --- Comment #1 from kugan at gcc dot gnu.org --- Sorry about the breakage, I am trying to reproduce it on x86-64. Please let me know if you have testcase.
[Bug middle-end/86467] inlining strcmp with small known length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86467 --- Comment #2 from Qing Zhao --- > --- Comment #1 from Richard Biener --- > I think there's a duplicate report. you mean another similar PR existing?
[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #6 from Jason Vas Dias ---
Thanks Andrew!
But, please explain, why does using a static reference cause
anonymous namespace issues ?
Where is this mandated in the C++ standards ?
I understand that any reference to a static object can violate the ODR
rule IFF multiple translation units that contain references to the "same"
static object are combined. But how does that involve anonymous namespace
issues?
Maybe GCC should provide some mechanism to detect static references,
report them separately as a new "-Wstatic-reference"? warning ,
and NOT bring in 'anonymous namespace' usage issues at all ?
It is purely a semantic difference - I agree SOME warning should
have been issued - but complaining about 'anonymous namespace'
when it means 'static reference' is really confusing.
There are NO objects named '{anon::}' in the program.
Couldn't GCC have some trigger on the creation of an '{anon}::'
reference, and use it to report the anonymous namespace usage,
and if none existed, complain about the static reference usage ?
Thanks & Best Regards,
Jason
On 11/07/2018, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
>
> Andrew Pinski changed:
>
>What|Removed |Added
>
>Keywords||diagnostic
>
> --- Comment #5 from Andrew Pinski ---
> It is not complaining about d in main but rather N::D. The warning is done
> before it reaches main.
>
> Really the warning should be clearer as you are not using an anonymous
> namespace rather static linkage which is also causes an anonymous namespace
> issues.
[Bug middle-end/86453] [8/9 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 Martin Sebor changed: What|Removed |Added Keywords||patch Component|c |middle-end --- Comment #10 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00586.html
[Bug c++/86497] New: Regression for x!=x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86497
Bug ID: 86497
Summary: Regression for x!=x
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
When compiling
bool is_nan1(double x){
return x!=x;
}
with g++-8.1 -O3 the resulting assembler (https://godbolt.org/g/BBFM3Q) is
_Z7is_nan1d:
ucomisd %xmm0, %xmm0
movl $1, %edx
setne %al
cmovp %edx, %eax
ret
However, for version 7.3 the result was (https://godbolt.org/g/tR69jf) better:
_Z7is_nan1d:
ucomisd %xmm0, %xmm0
setp %al
ret
Also for 8.1 -Os is the assembler somewhat strange:
_Z7is_nan1d:
ucomisd %xmm0, %xmm0
movb $1, %al
jp .L2
setne %al
[Bug lto/86496] [9 regression] plugin required to handle lto object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86496 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- I think these are the same failures those in bug 86004.
[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #5 from Andrew Pinski --- It is not complaining about d in main but rather N::D. The warning is done before it reaches main. Really the warning should be clearer as you are not using an anonymous namespace rather static linkage which is also causes an anonymous namespace issues.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #7 from H.J. Lu --- (In reply to Alexander Monakov from comment #6) > (In reply to H.J. Lu from comment #5) > > When ld sees a common symbol, it will use a non-common definiton > > in a library, .a or .so, to override it. > > This is surprising, is it documented somewhere? I don't think the ELF spec > suggests something like that needs to happen. It is to be consistent for common symbol linked against .a or .so.
[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #4 from Jason Vas Dias ---
Aha! It is simply that the object pointer template parameter cannot
have static (translation unit) linkage here:
namespace NA
{ class C { ... };
static C c_;
/*^^*/
}
If I remove the 'static', no warning is generated .
This -Wsubobject-linkage warning is therefore doubly confusing !
Since I am instantiating an object whose symbol has automatic storage class,
('d' in main()),
why should gcc complain that I have an object containing a static reference ?
And why does it have anything to do with -Wsubobject-linkage or use of
anonymous namespaces ?
There really is no anonymous namespace usage going on in this code.
I really do want all users of the 'NT' template to get a pointer to the same
global 'class C' 'c_' object , which is ONLY defined in the one place,
but multiple files must be able to include the same 't2.h' header .
I see now I should have used 'extern C c_', and defined it in tM.C.
But actually, in the context in which it was used, since there was no
other defining translation unit, and it was only instantiated in a main()
program, I do not think the warning should have been issued. If I was
actually trying to instantiate multiple 'class D' objects from multiple
translation units, there would be a problem, but I was not.
And really, that '-Wsubobject-linkage' should be split into:
A) Detect genuine anonymous namespace use
B) Detect usage of static object references in headers that can be
included by multiple files, and issue a separate warning message like
'static object reference may not be to same object\
if used in multiple translation units'
or something like that.
It is highly confusing to claim that code uses anonymous namespaces
when it does not.
[Bug c/86453] [8/9 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 --- Comment #9 from Martin Sebor --- Okay, let me look into making the change.
[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #3 from Jason Vas Dias ---
Of course, these lines of t2.h from Comment #1 :
template < class _C_, _C_ *_C_OBJ_, void (_C_::*_M_)() >
class NT
{ static constexpr _C_ *c_ = _C_OBJ_;
public:
NT()
{ (c_->*_M_)();
could be replaced by:
template < class _C_, _C_ *_C_OBJ_, void (_C_::*_M_)() >
class NT
{ static constexpr _C_ *c_ = _C_OBJ_;
public:
NT()
{ (c_->*_M_)();
and the same problem would occur (-Wsubobject-linkage warning) .
(the existence of the 'c_' static const copy of '_C_' is irrelevant.
It is simply that any occurrence of, in file A:
namespace N {
template
class T { ... /* something that uses C */}
}
and in file B :
namespace N {
namespace X {
class Y { ... };
Y y;
}
class C : T< Y, , retval (::a_Y_method) (,..) >
{...};
} // end namespace N
will trigger this bug.
I am trying to figure out why, and how it can be avoided.
I do not want to trigger C++'s special 'anonymous namespace object'
processing in any way here, and I do not see why it is being triggered.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #6 from Alexander Monakov --- (In reply to H.J. Lu from comment #5) > When ld sees a common symbol, it will use a non-common definiton > in a library, .a or .so, to override it. This is surprising, is it documented somewhere? I don't think the ELF spec suggests something like that needs to happen. > Do you have a testcase? No, it would take some time to prepare.
[Bug target/86386] [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386
--- Comment #4 from Jakub Jelinek ---
The A128 MEM is introduced during RA, *.ira still has:
(insn 26 24 28 2 (set (mem/c:QI (reg/f:DI 16 argp) [0 MEM[(char *
{ref-all})]+0 S1 A32])
(vec_select:QI (subreg:V16QI (reg:TI 88 [ _2 ]) 0)
(parallel [
(const_int 2 [0x2])
]))) "pr86386.c":9 3728 {*vec_extractv16qi}
(nil))
and *.reload replaces it with:
(insn 151 23 24 2 (set (mem/c:TI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [3 %sfp+-16 S16 A128])
(reg:TI 0 ax [orig:88 _2 ] [88])) "pr86386.c":8 84 {*movti_internal}
(nil))
...
(insn 152 24 26 2 (set (reg:V16QI 21 xmm0 [168])
(mem/c:V16QI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [3 %sfp+-16 S16 A128]))
"pr86386.c":9 1283 {movv16qi_internal}
(nil))
(insn 26 152 28 2 (set (mem/c:QI (plus:DI (reg/f:DI 6 bp)
(const_int 16 [0x10])) [0 MEM[(char * {ref-all})]+0 S1 A32])
(vec_select:QI (reg:V16QI 21 xmm0 [168])
(parallel [
(const_int 2 [0x2])
]))) "pr86386.c":9 3728 {*vec_extractv16qi}
(nil))
[Bug target/86386] [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Started with r250084.
/* PR target/86386 */
/* { dg-do run { target { avx_runtime && int128 } } } */
/* { dg-options "-Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx" } */
unsigned c, d, e, f;
unsigned __attribute__((noipa))
foo (unsigned char g, unsigned short h, unsigned i, unsigned long long j,
unsigned char k, unsigned short l, unsigned m, unsigned __int128 n)
{
__builtin_memset (, 0, 3);
n <<= m;
__builtin_memcpy (, 2 + (char *) , 1);
m >>= 0;
d ^= __builtin_mul_overflow (l, n, );
return m;
}
int
main ()
{
unsigned __int128 x = foo (0, 0, 0, 0, 0, 4, 1, 3);
if (x != 24)
__builtin_abort ();
return 0;
}
[Bug c/86453] [8/9 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 --- Comment #8 from rguenther at suse dot de --- On July 11, 2018 8:30:43 PM GMT+02:00, "msebor at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 > >--- Comment #7 from Martin Sebor --- >Right. The exclusion logic doesn't depend on no_add_attr; it uses it >for the >same purpose as attribute handlers do: to prevent the rest of the >framework >from applying them. Maybe the exclusion should be done first, before >calling >the handler, and the call to the handler avoided if the exclusion finds >a >conflict. Yes, that would be a possibility. Again, since some attributes are only applied as tree flags we may miss to diagnose conflicts via this mechanism.
[Bug c++/86485] [7/8/9 Regression] "anonymous" maybe-uninitialized false positive with ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- For the is_really_empty_class assignments, usually the logic in cp_gimplify_expr to handle simple_empty_class_p cases (or it is already optimized away earlier). But for the COND_EXPR, the gimplifier creates iftmp.N var and adds 2 MODIFY_EXPRs to that and somehow in this case it doesn't trigger because the second argument to simple_empty_class_p is a TARGET_EXPR, not a gimple lvalue etc. Wonder if cp_gimplify_expr couldn't specially gimplify some COND_EXPRs with is_really_empty_class type by effectively turning it into a VOID_TYPE COND_EXPR and then just return as result of the whole an uninitialized temporary.
[Bug lto/86496] New: [9 regression] plugin required to handle lto object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86496 Bug ID: 86496 Summary: [9 regression] plugin required to handle lto object Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Somewhere in the range r260955-r260970 a change was made that is causing a bunch of the LTO tests to fail. There were some build errors in that range which makes it hard to bisect to the exact revision. FAIL: g++.dg/lto/20091002-1 cp_lto_20091002-1_0.o-cp_lto_20091002-1_0.o link, -fPIC -flto -Wno-return-type FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, -flto -std=c++11 FAIL: g++.dg/lto/pr65193 cp_lto_pr65193_0.o-cp_lto_pr65193_0.o link, -fPIC -r -nostdlib -flto -O2 -g -Wno-return-type FAIL: g++.dg/lto/pr65302 cp_lto_pr65302_0.o-cp_lto_pr65302_1.o link, -flto -O2 -Wno-return-type FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o-cp_lto_pr65316_1.o link, -flto -std=c++11 -g2 -fno-lto-odr-type-merging -O2 -Wno-return-type FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, -std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, -std=gnu++14 -flto -g -Wno-return-type FAIL: g++.dg/lto/pr66180 cp_lto_pr66180_0.o-cp_lto_pr66180_1.o link, -flto -std=c++14 -r -nostdlib FAIL: g++.dg/lto/pr66705 cp_lto_pr66705_0.o-cp_lto_pr66705_0.o link, -O2 -flto -flto-partition=max -fipa-pta FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 -flto -fuse-linker-plugin FAIL: g++.dg/lto/pr69077 cp_lto_pr69077_0.o-cp_lto_pr69077_1.o link, -O3 -g -flto FAIL: g++.dg/lto/pr69133 cp_lto_pr69133_0.o-cp_lto_pr69133_1.o link, -flto -O2 FAIL: g++.dg/lto/pr69137 cp_lto_pr69137_0.o-cp_lto_pr69137_0.o link, -std=c++11 -g -flto FAIL: g++.dg/lto/pr79000 cp_lto_pr79000_0.o-cp_lto_pr79000_1.o link, -flto -g FAIL: g++.dg/lto/pr81940 cp_lto_pr81940_0.o-cp_lto_pr81940_0.o link, -O -flto FAIL: g++.dg/lto/pr85176 cp_lto_pr85176_0.o-cp_lto_pr85176_0.o link, -flto -g1 FAIL: gfortran.dg/lto/pr79108 f_lto_pr79108_0.o-f_lto_pr79108_0.o link, -Ofast -flto --param ggc-min-expand=0 --param ggc-min-heapsize=0 spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++7/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++7/../../ cp_lto_pr64043_0.o -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -flto -std=c++11 -r -nostdlib -O2 -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs -o g++-dg-lto-pr64043-01.exe /usr/bin/ld: /tmp/ccXKXOCe.lto.o: plugin needed to handle lto object FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, -flto -std=c++11 ld --version GNU ld (GNU Binutils for Ubuntu) 2.26.1 Note that with binutils 2.27 it works fine. IIRC there is some issue with binutils for a few revisions that can trigger this but is there something that can be done to prevent all these tests from failing? Should gcc be dependent on certain builds of binutils?
[Bug c/86453] [8/9 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 --- Comment #7 from Martin Sebor --- Right. The exclusion logic doesn't depend on no_add_attr; it uses it for the same purpose as attribute handlers do: to prevent the rest of the framework from applying them. Maybe the exclusion should be done first, before calling the handler, and the call to the handler avoided if the exclusion finds a conflict.
[Bug c++/86485] [7/8/9 Regression] "anonymous" maybe-uninitialized false positive with ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Started with r246314.
Smaller testcase:
struct E {};
struct S { S () {} E e; };
void foo (S);
void
bar (bool b)
{
foo (b ? S {} : S {});
}
[Bug c/86453] [8/9 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 --- Comment #6 from rguenther at suse dot de --- On July 11, 2018 8:12:17 PM GMT+02:00, "msebor at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 > >--- Comment #5 from Martin Sebor --- >The attribute exclusion framework only excludes conflicting attributes >if they >aren't applied by their handler. It doesn't know how to undo changes >that the >handler makes, like modifying tree nodes in place. It would need to be >extended to also let each handler detect the conflicts before making >these >kinds of changes. Note that no_add_attr doesn't mean the attribute isn't applied. Instead some attributes are optimized and translated to tree flags. There isn't really a way the handler can signal the attribute wasn't applied.
[Bug c/86453] [8/9 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 --- Comment #5 from Martin Sebor --- The attribute exclusion framework only excludes conflicting attributes if they aren't applied by their handler. It doesn't know how to undo changes that the handler makes, like modifying tree nodes in place. It would need to be extended to also let each handler detect the conflicts before making these kinds of changes.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #5 from H.J. Lu --- (In reply to Alexander Monakov from comment #4) > (In reply to H.J. Lu from comment #3) > > It is because gold doesn't check archive for a common definition. > > Please elaborate - does ld.bfd try to extract static archive members when it > already has a common definition? Why? When ld sees a common symbol, it will use a non-common definiton in a library, .a or .so, to override it. > > Is there a common symbol involved? > > I don't think so, but I'm not sure. We've also seen other pain points like > the same member extracted and given to the plugin multiple times, even > though the second extraction cannot possibly satisfy any unresolved > references. Do you have a testcase?
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 --- Comment #3 from Jakub Jelinek --- Created attachment 44385 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44385=edit gcc9-pr86492.patch Untested fix.
[Bug c++/86495] New: false no return statement warning in "if constexpr" branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86495
Bug ID: 86495
Summary: false no return statement warning in "if constexpr"
branch
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tower120 at gmail dot com
Target Milestone: ---
The following code produce false "no return statement" warning in gcc 8.1.
Everything fine on 7.x
Live: https://godbolt.org/g/dCuFci
#include
#include
template
class variant_w_base{
Base* m_base;
Variant m_variant;
void update_base(){
m_base = std::visit([](auto&& arg) -> Base* {
using Arg = std::decay_t;
// ERRONEOUS WARNING HERE.
if constexpr (std::is_same_v){
return nullptr;
} else {
return static_cast();
}
}, m_variant);
}
public:
variant_w_base(){
update_base();
}
};
int main() {
struct Base{};
struct Data : Base{};
variant_w_base> v;
return 0;
}
[Bug c++/54080] [C++11] g++ crashes when compiling the following file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54080 --- Comment #4 from nightstrike --- This still crashes with gcc 8.1.1 20180531
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 --- Comment #2 from Jakub Jelinek --- Related to PR84503.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #4 from Alexander Monakov --- (In reply to H.J. Lu from comment #3) > It is because gold doesn't check archive for a common definition. Please elaborate - does ld.bfd try to extract static archive members when it already has a common definition? Why? > Is there a common symbol involved? I don't think so, but I'm not sure. We've also seen other pain points like the same member extracted and given to the plugin multiple times, even though the second extraction cannot possibly satisfy any unresolved references.
[Bug c++/86494] New: Usage in unevaluated context causes compile time errors because of implicit deletion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86494
Bug ID: 86494
Summary: Usage in unevaluated context causes compile time
errors because of implicit deletion
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Following code:
template
struct pair {
T1 first;
pair() = default;
pair(const pair&) = default;
pair(pair&&) = default;
pair& operator=(pair&& __p);
pair& operator=(const pair& __p);
};
struct Idx : public pair {
using pair::pair;
using pair::operator=;
};
template _Tp&& declval() noexcept;
int main() {
// Comment out the next line and everything will compile
using t = decltype(declval() = declval());
Idx p{};
Idx p2(p);
}
Fails to compile on GCC with the following error:
: In function 'int main()':
:25:13: error: use of deleted function 'constexpr Idx::Idx(const Idx&)'
Idx p2(p);
^
:13:8: note: 'constexpr Idx::Idx(const Idx&)' is implicitly declared as
deleted because 'Idx' declares a move constructor or move assignment operator
struct Idx : public pair {
^~~
However clang compiles that code well.
With line 'using t =...' commented out everything compiles well on GCC.
[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491 --- Comment #2 from Jason Vas Dias --- Created attachment 44384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44384=edit More readable (diff -ur) patch against 6.4.1's cp/decl2.c Here is a more readable version of the patch to print out information on the exact component of the base class structure which GCC thinks uses the anonymous namespace. In this case, it is of not much use, but does inform the user that GCC thinks the whole structure declaration somehow uses the anonymous namespace, which obviously it does not, so does signal the existence of this GCC bug to the user.
[Bug c++/86493] New: [concepts] Hard error for "call to non-'constexpr' function" in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86493
Bug ID: 86493
Summary: [concepts] Hard error for "call to non-'constexpr'
function" in a requires expression
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Compiling this well-formed program:
template
concept bool Concept = T::f() == 0;
struct bad {
static int f() { return 0; }
};
int main() {
static_assert(!Concept);
}
with -fconcepts and GCC 6.3/7.3/8.1/trunk diagnoses:
: In function 'int main()':
:2:30: error: call to non-'constexpr' function 'static int bad::f()'
concept bool Concept = T::f() == 0;
^~
instead of correctly failing the concept check.
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-11 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |8.2 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with my r254948.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #3 from H.J. Lu --- (In reply to Alexander Monakov from comment #2) > Note that Gold does not exhibit this issue. I think ld.bfd is at fault here. It is because gold doesn't check archive for a common definition. > We've hit similar issues with some internal plugin development. The main > issue is, ld.bfd feeds the plugin with objects extracted from static > archives, but those objects do not satisfy any unresolved references and > would not be extracted in the first place in non-LTO link. So ld.bfd is > causing useless extra work both for itself and the compiler plugin. > Is there a common symbol involved?
[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #1 from Jason Vas Dias ---
In investigating this problem, I actually modified 6.4.1's gcc/cp/decl2.c
with the following patch to print out which component of the
base struct it thinks uses the anonymous namespace:
BEGIN PATCH:
--- decl2.c,r260630 2018-05-18 14:47:27.0 +0100
+++ decl2.c 2018-07-11 16:16:13.816541340 +0100
@@ -2154,0 +2155,5 @@
+struct tree_vis
+{ tree *tp;
+ int vis;
+};
+
@@ -2158 +2163 @@
- int *vis_p = (int *)data;
+ struct tree_vis *tree_vis_p = (struct tree_vis *)data;
@@ -2166 +2171,2 @@
- *vis_p = VISIBILITY_ANON;
+ tree_vis_p->tp = tp;
+ tree_vis_p->vis = VISIBILITY_ANON;
@@ -2170,2 +2176,4 @@
- && CLASSTYPE_VISIBILITY (*tp) > *vis_p)
-*vis_p = CLASSTYPE_VISIBILITY (*tp);
+ && CLASSTYPE_VISIBILITY (*tp) > tree_vis_p->vis)
+ { tree_vis_p->vis = CLASSTYPE_VISIBILITY (*tp);
+tree_vis_p->tp = tp;
+ }
@@ -2181,3 +2189,8 @@
- int vis = VISIBILITY_DEFAULT;
- cp_walk_tree_without_duplicates (, min_vis_r, );
- return vis;
+ struct tree_vis tv = { NULL, VISIBILITY_DEFAULT };
+ cp_walk_tree_without_duplicates (, min_vis_r, );
+ return tv.vis;
+}
+
+static void
+tree_type_visibility (tree_vis *tvis)
+{ cp_walk_tree_without_duplicates (tvis->tp, min_vis_r, tvis);
@@ -2607 +2620,4 @@
- int subvis = type_visibility (TREE_TYPE (t));
+ tree_vis tvis = { &(TREE_TYPE (t)), VISIBILITY_DEFAULT };
+ tree_type_visibility ();
+
+ int subvis = tvis.vis;
@@ -2627,2 +2643,2 @@
-%qT has a base %qT whose type uses the anonymous namespace",
-type, TREE_TYPE (t));
+%qT has a base %qT whose type uses the anonymous namespace because of its
component %qT",
+type, TREE_TYPE (t), *tvis.tp);
:END PATCH
But the offending component is actually the whole base class:
N::NT<_C_, _C_OBJ_, _M_>::NT() void N::NA::C::m()
In file included from /tmp/tM.C:1:0:
/tmp/t2.H: At global scope:
/tmp/t2.H:14:9: warning: ‘N::D’ has a base ‘N::NT’ whose type uses the anonymous namespace because of its component
‘N::NT’ [-Wsubobject-linkage]
class D : public NT
^
N::D::D() N::D::D() N::D::D() int main() N::NT<_C_, _C_OBJ_, _M_>::NT() [with
_C_ = N::NA::C; _C_* _C_OBJ_ = (& N::NA::c_); void (_C_::* _M_)() =
::NA::C::m] N::NT<_C_, _C_OBJ_, _M_>::NT() [with _C_ = N::NA::C; _C_* _C_OBJ_
= (& N::NA::c_); void (_C_::* _M_)() = ::NA::C::m] N::NT<_C_, _C_OBJ_,
_M_>::NT() [with _C_ = N::NA::C; _C_* _C_OBJ_ = (& N::NA::c_); void (_C_::*
_M_)() = ::NA::C::m]
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling
functions:
void N::NA::C::m() N::D::D() int main() N::NT<_C_, _C_OBJ_,
_M_>::NT() [with _C_ = N::NA::C; _C_* _C_OBJ_ = (& N::NA::c_); void (_C_::*
_M_)() = ::NA::C::m]
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
1386 kB (62%) ggc
phase opt and generate : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall
169 kB ( 8%) ggc
integrated RA : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall
96 kB ( 4%) ggc
TOTAL : 0.00 0.00 0.01
2223 kB
It would be nice if the fix for this could also print out more information
about precisely which component of the structure the compiler thinks uses
the anonymous namespace - it has taken me 2 days of analysis to get this
far, which could have been avoided if GCC printed out information like
the above in the first place.
[Bug tree-optimization/86492] New: [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492
Bug ID: 86492
Summary: [8/9 Regression] store-merging wrong-code
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
union U
{
unsigned int r;
struct
{
unsigned int a:12;
unsigned int b:4;
unsigned int c:16;
} f;
};
__attribute__((noinline, noclone)) unsigned int
foo (unsigned int x)
{
union U r;
r.r = 0;
r.f.c = x;
r.f.b = 0xe;
return r.r;
}
int
main ()
{
volatile unsigned int x;
x = 0x72;
x = foo (x);
union U r;
r.r = x;
if (r.f.a != 0 || r.f.b != 0xe || r.f.c != 0x72)
__builtin_abort ();
return 0;
}
is miscompiled by store-merging at -O2.
[Bug c++/86491] New: bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
Bug ID: 86491
Summary: bogus and unsuppressible warning: 'YYY' has a base
'ZZZ' whose type uses the anonymous namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
Created attachment 44383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44383=edit
test code demonstrating problem as described above.
This could be a duplicate of (now closed) bug #57317 ,
or a demonstration that the fix for that bug is not complete.
It occurs with all versions of GCC on Linux x86_64 - tested:
o RHEL7 system compiler: 4.8.5 (rpm: 4.8.5-28.el7_5.1.x86_64)
My own builds of:
o gcc 5.4.0
o gcc 6.4.1 (from gcc-6-branch r260630)
o gcc 7.3.1 (r260631)
o gcc 8.1.0 (r261026)
.
The following test code triggers a -Wsubobject-linkage warning,
with all the above compilers :
./t2.H:14:9: warning: 'N::D' has a base 'N::NT whose type uses the anonymous namespace \
[enabled by default]
class D : public NT
^
I have constructed the following test code,
which triggers the same -Wsubobject-linkage warning
I am seeing in a large more complex real-world example.
I am not intentionally using the anonymous namespace
in any of this code, and I cannot for the life of me
see how any part of it uses the anonymous namespace:
Test Code :
File t1.H:
// t1.H :
namespace N
{
template < class _C_, _C_ *_C_OBJ_, void (_C_::*_M_)() >
class NT
{ static constexpr _C_ *c_ = _C_OBJ_;
public:
NT()
{ (c_->*_M_)();
}
};
}
File t2.H:
// t2.H :
#include
namespace N
{
namespace NA
{
class C
{ public:
void m()
{}
};
static C c_;
}
class D : public NT
{public:
typedef NT NT_t;
D(): NT_t()
{}
};
}
file tM.C (main program):
#include
extern int main()
{ N::D d;
(void)d;
return 0;
}
The above files are included in the attached
'Wsubobject-linkage-anon-base-bug.tar' file, which includes a make file:
$ tar -xpf Wsubobject-linkage-anon-base-bug.tar
$ cd Wsubobject-linkage-anon-base-bug
$ make
g++ -std=gnu++14 -I. -Wall -Wextra -Werror -o tM tM.C
In file included from tM.C:1:0:
./t2.H:14:9: error: 'N::D' has a base 'N::NT' whose type uses the anonymous namespace [-Werror]
class D : public NT
^
cc1plus: all warnings being treated as errors
make: *** [Makefile:4: tM] Error 1
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Note that Gold does not exhibit this issue. I think ld.bfd is at fault here. We've hit similar issues with some internal plugin development. The main issue is, ld.bfd feeds the plugin with objects extracted from static archives, but those objects do not satisfy any unresolved references and would not be extracted in the first place in non-LTO link. So ld.bfd is causing useless extra work both for itself and the compiler plugin. It would be nice to fix this on ld.bfd side so future plugin writers don't need to wrestle with this issue.
[Bug tree-optimization/80122] __builtin_va_arg_pack() and __builtin_va_arg_pack_len() does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80122
rpirrera at aitek dot it changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #12 from rpirrera at aitek dot it ---
I have found another issue with __builtin_va_arg_pack_len() that happens when
the functions that uses __builtin_va_arg_pack() calls another function that
uses __builtin_va_arg_pack_len(), the argument len is miscalculated as you can
see in the attached example.
This was working in GCC version 4.4.7.
/*** TESTBUILTIN BEGIN /
static inline __attribute__(( __always_inline__)) int
funA(unsigned int param, ...)
{
return __builtin_va_arg_pack_len();
}
static inline __attribute__(( __always_inline__)) int
funB(unsigned int param, ...)
{
return funA(param, 2, 4, __builtin_va_arg_pack());
}
int
testBuiltin(void)
{
printf(ANSI_BOLD "%s" ANSI_RESET " ... ", __FUNCTION__);
int rc = funB(0,1,2);
if (rc != 4) {
return 1;
}
return 0;
}
Thank you!
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-11 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Thanks H.J. for investigation. Honza can you please take a look?
[Bug lto/86490] New: lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
Bug ID: 86490
Summary: lto1: fatal error: multiple prevailing defs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[hjl@gnu-cfl-1 pr23350]$ cat foo.c
int foo;
void bar() {}
[hjl@gnu-cfl-1 pr23350]$ cat bar.c
int foo;
void bar() {}
[hjl@gnu-cfl-1 pr23350]$ cat main.c
int foo;
int
main ()
{
return foo;
}
[hjl@gnu-cfl-1 pr23350]$ make CC=gcc
gcc -O2 -flto -c -o main.o main.c
gcc -O2 -flto -c -o foo.o foo.c
ar --plugin `gcc -print-prog-name=liblto_plugin.so` -rusc libfoo.a foo.o
gcc -O2 -flto -c -o bar.o bar.c
ar --plugin `gcc -print-prog-name=liblto_plugin.so` -rusc libbar.a bar.o
gcc -o x main.o libfoo.a libbar.a
lto1: fatal error: multiple prevailing defs for ‘bar’
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:14: x] Error 1
[hjl@gnu-cfl-1 pr23350]$
Linker has:
if (!blhe)
{
/* The plugin is called to claim symbols in an archive element
from plugin_object_p. But those symbols aren't needed to
create output. They are defined and referenced only within
IR. */
switch (syms[n].def)
{
default:
abort ();
case LDPK_UNDEF:
case LDPK_WEAKUNDEF:
res = LDPR_UNDEF;
break;
case LDPK_DEF:
case LDPK_WEAKDEF:
case LDPK_COMMON:
res = LDPR_PREVAILING_DEF_IRONLY;
break;
}
goto report_symbol;
}
lto1 shouldn't issue
lto1: fatal error: multiple prevailing defs for ‘bar’
unless bar will be included in output.
[Bug tree-optimization/86489] New: ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489
Bug ID: 86489
Summary: ICE in gimple_phi_arg starting with r261682 when
building 531.deepsjeng_r with FDO + LTO
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, kugan at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Build: powerpc64le-unknown-linux-gnu
The patch for pr82479 causes an ICE while building CPU2017 531.deepsjeng_r with
FDO and LTO. The ICE occurs during the link step of the -fprofile-use build.
/home/pthaugen/install/gcc/gcc_hunt/bin/g++ -m64 -O3 -mcpu=power9
-fpeel-loops -funroll-loops -ffast-math -mpopcntd -mrecip -flto -DSPEC_LP64
-m64 -Wl,-q -Wl,-rpath=/home/pthaugen/install/gcc/gcc_hunt/lib64 attacks.o
bitboard.o bits.o board.o draw.o endgame.o epd.o generate.o initp.o make.o
moves.o neval.o pawn.o preproc.o search.o see.o sjeng.o state.o ttable.o
utils.o -o deepsjeng_r
during GIMPLE pass: cunroll
generate.cpp: In function 'gen.constprop':
generate.cpp:159:5: internal compiler error: in gimple_phi_arg, at
gimple.h:4345
int gen(state_t *s, move_s *moves) {
^
0x1013c597 gimple_phi_arg
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/gimple.h:4345
0x1013c5f3 gimple_phi_arg
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/gimple.h:4345
0x1013c5f3 gimple_phi_arg
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/gimple.h:4353
0x10a37607 gimple_phi_arg_def
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/gimple.h:4396
0x10a37607 number_of_iterations_popcount
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-niter.c:2559
0x10a37607 number_of_iterations_exit_assumptions(loop*, edge_def*,
tree_niter_desc*, gcond**, bool)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-niter.c:2364
0x10a392eb number_of_iterations_exit_assumptions(loop*, edge_def*,
tree_niter_desc*, gcond**, bool)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-niter.c:2611
0x10a392eb number_of_iterations_exit(loop*, edge_def*, tree_niter_desc*, bool,
bool)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-niter.c:2616
0x10a3985f number_of_iterations_exit(loop*, edge_def*, tree_niter_desc*, bool,
bool)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/vec.h:884
0x10a3985f estimate_numbers_of_iterations(loop*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-niter.c:4100
0x10a3ce73 estimate_numbers_of_iterations(function*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-niter.c:4329
0x10a07ec7 tree_unroll_loops_completely
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-ivcanon.c:1452
0x10a08603 execute
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-loop-ivcanon.c:1612
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug c++/86480] [8 Regression] error: parameter packs not expanded with '...' in a recursive variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86480 --- Comment #2 from Guillaume Racicot --- Yes of course! I only added the `-std=c++17` flag. Here's a live example: https://godbolt.org/g/p8KLfE
[Bug c++/67147] [concepts] ICE on checking concept with default template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147 --- Comment #4 from Antony Polukhin --- Shorter reproducer: template concept bool fn = true; template int test(); Above sample produces the following output: :1:28: internal compiler error: in tsubst, at cp/pt.c:14368 template concept bool fn = true; ^
[Bug c++/86443] ICEs on #pragma omp distribute parallel for with class iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86443 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Jul 11 13:13:31 2018 New Revision: 262552 URL: https://gcc.gnu.org/viewcvs?rev=262552=gcc=rev Log: PR c++/86443 * testsuite/libgomp.c++/for-15.C (a): Remove unused variable. (results): Make sure the variable is not inside declare target region. (qux): Remove unused function. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c++/for-15.C
[Bug c++/86488] malloc attribute when pointer is returned as part of a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86488 Richard Biener changed: What|Removed |Added Keywords||alias, missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-11 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed, though in principle semantics could be extended to handle structs quite easily. Description would be changed to be more vague about the actual return type but only mention that it may not alias any other memory. That would also cover returning a struct of two pointers which then still may point to each other.
[Bug c++/86482] arm vector instruction requiring allignment uses non alligned input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86482 kkr at danfoss dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from kkr at danfoss dot com --- Checked our stacks, and not all of them were 64 bit alligned, including the one triggering the error. Closing the bug
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #15 from niva at niisi dot msk.ru --- (In reply to Vladimir Makarov from comment #14) > Author: vmakarov > Date: Thu May 14 20:40:44 2015 > New Revision: 223202 > > URL: https://gcc.gnu.org/viewcvs?rev=223202=gcc=rev > Log: > 2015-05-14 Vladimir Makarov > > PR rtl-optimization/65862 > * target.def (ira_change_pseudo_allocno_class): New hook. > * targhooks.c (default_ira_change_pseudo_allocno_class): Default > value of the hook. > * targhooks.h (default_ira_change_pseudo_allocno_class): New > extern > * doc/tm.texi.in (TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Add the > hook. > * ira-costs.c (find_costs_and_classes): Call the hook and change > classes when it is necessary. > * doc/tm.texi: Update. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/doc/tm.texi > trunk/gcc/doc/tm.texi.in > trunk/gcc/ira-costs.c > trunk/gcc/target.def > trunk/gcc/targhooks.c > trunk/gcc/targhooks.h : Is it true that this patch fixes the problem? If so then why this bug is not marked as resolved? (I'm asking because I am greatly interested in this fix.)
[Bug debug/86452] ICE in force_decl_die, at dwarf2out.c:25922 with -g1 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86452
Richard Biener changed:
What|Removed |Added
Status|WAITING |ASSIGNED
CC||dodji at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #5 from Richard Biener ---
It looks like the error is simply that
/* If type is an anonymous tagged type named by a typedef, let's
generate debug info for the typedef. */
if (is_naming_typedef_decl (TYPE_NAME (type)))
{
/* Use the DIE of the containing namespace as the parent DIE of
the type description DIE we want to generate. */
if (DECL_CONTEXT (TYPE_NAME (type))
&& TREE_CODE (DECL_CONTEXT (TYPE_NAME (type))) == NAMESPACE_DECL)
context_die = get_context_die (DECL_CONTEXT (TYPE_NAME (type)));
is using get_context_die rather than
context_die = scope_die_for (type, context_die);
which fixes the ICE.
I believe the conditional can also be elided but that could be a separate
thing to test (testcase also works).
The above was introduced with r160347.
Thus I am testing the following:
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 262551)
+++ gcc/dwarf2out.c (working copy)
@@ -25378,11 +25378,8 @@ gen_type_die_with_usage (tree type, dw_d
generate debug info for the typedef. */
if (is_naming_typedef_decl (TYPE_NAME (type)))
{
- /* Use the DIE of the containing namespace as the parent DIE of
- the type description DIE we want to generate. */
- if (DECL_CONTEXT (TYPE_NAME (type))
- && TREE_CODE (DECL_CONTEXT (TYPE_NAME (type))) == NAMESPACE_DECL)
- context_die = get_context_die (DECL_CONTEXT (TYPE_NAME (type)));
+ /* Give typedefs the right scope. */
+ context_die = scope_die_for (type, context_die);
gen_decl_die (TYPE_NAME (type), NULL, NULL, context_die);
return;
[Bug fortran/39230] ASSOCIATED & undefined pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230
--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> Consider the following snippet:
>
> implicit none
> integer, pointer :: p
> print *,associated(p)
> end
>
> [...]
> Right now the above program simply prints "T". This is kind of dangerous,
> since it looks like the pointer is associated with some target, while in
> fact it is not. ifort prints "F". I didn't check other compilers.
Note that the output of this program actually seems to depend on the
optimization level: With -O0 I get 'T', but with -O{1,2,3} I see 'F.
[Bug fortran/39230] ASSOCIATED & undefined pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) > I think what you want is some -fcheck=pointer option (I think there is a PR > about his). That option would initialize pointer with some bogus value, e.g. -fcheck=pointer is available since gfortran 4.5, but even with gfortran 8 it still does not complain about the use of an undefined pointer in comment 0.
[Bug c++/86488] New: malloc attribute when pointer is returned as part of a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86488
Bug ID: 86488
Summary: malloc attribute when pointer is returned as part of a
struct
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
I am trying to implementing P0901r0 [0] in jemalloc. The signature of the new
memory allocation function looks like this:
typedef struct {
void *ptr;
size_t usize;
} smallocx_return_t;
smallocx_return_t je_smallocx(size_t size, int flags);
I'd like to set the "malloc" [1] attribute for this function but AFAICT this is
not currently possible for this new function because the pointer
smallocx_return_t::ptr is part of a struct.
[0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0901r0.html
[1]: From https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
> malloc
> This tells the compiler that a function is malloc-like, i.e., that the
> pointer P
> returned by the function cannot alias any other pointer valid when the
> function
> returns, and moreover no pointers to valid objects occur in any storage
> addressed by P.
>
> Using this attribute can improve optimization. Functions like malloc and
> calloc
> have this property because they return a pointer to uninitialized or
> zeroed-out
> storage. However, functions like realloc do not have this property, as they
> can
> return a pointer to storage containing pointers.
[Bug c++/86483] alloc_size attribute does not work on functions returning a struct that contains the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86483 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #5 from gnzlbg --- I am moving this to a new bug that's exclusive to the "malloc" attribute.
[Bug c++/86483] alloc_size attribute does not work on functions returning a struct that contains the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86483 --- Comment #4 from gnzlbg --- @Jonathan Wakely: > If you tell the compiler the storage is smaller than 'usize' you're asking it > to treat accesses past 'size' bytes as undefined behaviour (even though > actually accesses up to usize are valid). Indeed. Expressing that the pointer in smallocx_return_t::ptr points to an allocation of smallocx_return_t::size is probably too hard to be useful, since how this size is computed can be arbitrarily complex. The same applies to somehow expressing the minimum alignment from the amount requested but encoded in "int flags". The only the attribute that I think I should be able to use here is the "malloc" attribute for the struct pointer.
[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||6.4.1 Version|unknown |7.3.1 Target Milestone|--- |7.4 Known to fail||7.3.1, 8.1.1, 9.0
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 Thomas Preud'homme changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|thopre01 at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug target/86487] New: [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
Bug ID: 86487
Summary: [7/8/9 Regression] insn does not satisfy its
constraints on arm big-endian
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: arm
int a, b, c, d;
long long fn1(long long p2) { return p2 == 0 ? -1 : -1 % p2; }
void fn2(long long p1, short p2, long p3) {
b = fn1((d || 6) & a);
c = b | p3;
}
Compiled for arm-none-eabi with -O1 -mfloat-abi=hard -mfpu=neon -mbig-endian
-march=armv7-a ICEs with:
anddi.c: In function 'fn2':
anddi.c:6:1: error: insn does not satisfy its constraints:
}
^
(insn 13 11 14 2 (set (reg:DI 0 r0 [124])
(and:DI (reg:DI 1 r1 [orig:121+-4 ] [121])
(const_int 1 [0x1]))) "anddi.c":2 79 {*anddi3_insn}
(nil))
during RTL pass: reload
anddi.c:6:1: internal compiler error: in extract_constrain_insn, at
recog.c:2205
0xb6d56c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
$SRC/gcc/rtl-error.c:108
0xb6d59d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
$SRC/gcc/rtl-error.c:119
0xb40af6 extract_constrain_insn(rtx_insn*)
$SRC/gcc/recog.c:2205
0xa3d659 check_rtl
$SRC/gcc/lra.c:2156
0xa42258 lra(_IO_FILE*)
$SRC/gcc/lra.c:2590
0x9f9298 do_reload
$SRC/gcc/ira.c:5465
0x9f9298 execute
$SRC/gcc/ira.c:5649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/86463] var-tracking is slow with -ggdb and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-11 Component|debug |rtl-optimization Summary|Slow compile with -ggdb and |var-tracking is slow with |optimizations |-ggdb and optimizations Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- That confirms it is var-tracking. There are a number of related PRs.
[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259 --- Comment #20 from Davin McCall --- (In reply to Davin McCall from comment #19) > [...] If the result of offsetof has no provenance even the long form won't > work. "no provenance" meaning "empty provenance", and of course this is not actually correct; shouldn't have posted before coffee. However, if it had provenance of the member, that would be problematic. Having provenance of the compound object (s2') would be ok for Richard Biener's example of ((char *) + offsetof(S, a)) but not for my extended example of determining the address of the containing object using a pointer to a member object and offsetof.
[Bug c++/86480] [8 Regression] error: parameter packs not expanded with '...' in a recursive variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86480 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.2 --- Comment #1 from Richard Biener --- What flags? GCC 7.3 doesn't compile it for me: > g++-7 -S t.C t.C:5:71: error: ‘tuple_size_v’ is not a member of ‘std’ template>> ^~~~ t.C:5:71: note: suggested alternative: ‘tuple_size’ can you please attach the testcase?
[Bug libgcc/85967] [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85967 --- Comment #4 from Ladislav Michl --- I do not have a copyright assignment in place with the FSF and I'm not even author of that patch. Adhemerval Zanella did the work (thank you again) and I added him to CC List. Patch itself needs improving as __aeabi_ldiv0 is called with a 'b' not with a 'bl', so the unwind information is still not really correct.
[Bug c++/86485] [7/8/9 Regression] "anonymous" maybe-uninitialized false positive with ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.4
Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
On 11.07.2018 11:46, Richard Earnshaw (lists) wrote: > On 10/07/18 18:53, Kamil Rytarowski wrote: >> On 10.07.2018 19:49, richard.earnshaw at arm dot com wrote: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >>> >>> --- Comment #7 from richard.earnshaw at arm dot com --- >>> On 10/07/18 10:57, Kamil Rytarowski wrote: On 06.07.2018 15:26, Richard Earnshaw (lists) wrote: > On 06/07/18 12:11, Kamil Rytarowski wrote: >> On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >>> On 06/07/18 11:32, Kamil Rytarowski wrote: On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 > > --- Comment #2 from Richard Earnshaw --- > I'm not sure how relevant the netbsd-elf port is these days. I > believe they've > now moved onto an EABI based ABI. But no GCC port of that has been > contributed. > NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre ARMv4 CPUs use OABI only. >>> >>> GCC-9 will drop support for pre-armv4 CPUs. Such support has been >>> marked as deprecated for about 3 years now. >>> >> >> We verify these ports on real hardware. >> >> NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is >> obsoleting it and surprisingly LLVM soon might have support for a wider >> range of ARM CPUs. >> > > Shark's use strongARM cpus, which are ARMv4. That's not been obsoleted, > but it is considered deprecated these days. > Shark doesn't use all instructions that are generated by GCC (I forgot the CPU property name of it) and thus it has to be switched to Clang/LLVM. >>> >>> You're not making sense. Please be more explicit as to what you mean >>> and give an example. GCC can generate instructions for ARMv4 and >>> StrongARM (used by the shark) is an ARMv4 part. >>> >>> I've run gcc generated code on shark boards for years and not seen problems. >>> >>> R. >>> >> >> I got a feedback that it's called: armv4t. >> > > From whom? StrongARM is ARMv4. It is *not* ARMv4t as it does not > support Thumb. Whatever, GCC can support both ARMv4 and ARMv4t. > > R. > CC: Joerg who was involved in the work on switch to Clang/LLVM. signature.asc Description: OpenPGP digital signature
[Bug tree-optimization/86479] [9 Regression] [graphite] ICE in gimplify_modify_expr, at gimplify.c:5756
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86479 --- Comment #2 from Richard Biener --- PR84873 was that, also manifesting itself in fold_binary_op_with_conditional_arg (but not a trapping but tree sharing issue). Testing a patch.
[Bug debug/86463] Slow compile with -ggdb and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 --- Comment #4 from Rob Farmer --- gfortran -ggdb -O1 -fno-var-tracking -c largeFile.f90 0m2.628s gfortran -ggdb -O2 -fno-var-tracking -c largeFile.f90 0m4.262s gfortran -ggdb -O3 -fno-var-tracking -c largeFile.f90 0m21.706s
[Bug debug/86463] Slow compile with -ggdb and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 --- Comment #3 from rguenther at suse dot de --- On Wed, 11 Jul 2018, robert.j.farmer37 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 > > --- Comment #2 from Rob Farmer --- > > gfortran -ggdb -fno-var-tracking -c largeFile.f90 0m0.358s Try with -O1, -O2 or -O3 please, without -O var-tracking is already disabled.
[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #19 from Davin McCall ---
(In reply to rguent...@suse.de from comment #16)
> On Mon, 25 Jun 2018, glisse at gcc dot gnu.org wrote:
>
> As a general comment I find it disturbing that the user
> is required to write (char *) + offsetof(S, a) instead
> of plain
Even worse, the proposal doesn't mention the provenance of "offsetof" at all.
If the result of offsetof has no provenance even the long form won't work. That
seems like a big oversight to me. Also, code doing something like the following
can't be terribly uncommon:
type struct { int a; int b; } s;
s s_o;
// start with address of contained member:
char *b_cp = _o.b;
// subtract its offset:
char *s_o_cp = b_cp - offsetof(s,b);
s * s_o_p = (s *) s_o_cp;
// access the containing object:
s s2 = *s_o_p;
It would only work generally if an offsetof result is given wildcard
provenance.
[Bug target/85854] Performance regression from gcc 4.9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85854 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-11 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan --- I'm unable to build the pre-processed file with 4.9 - is it possible for you to attach a non-preprocessed version as well ? The reason this happens compared to the usual instructions is that the implementation of the intrinsic can well change between compiler versions. regards Ramana
[Bug other/86486] New: GCC 8 stack clash protection on AArch64 is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86486 Bug ID: 86486 Summary: GCC 8 stack clash protection on AArch64 is incomplete Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: tnfchris at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org Target Milestone: --- Target: aarch64*-*-* * Currently enabling stack clash will only provide protection from alloca and not from prologue and epilogue code. This is not sufficient to protect the stack from overflows. * On AArch64 there are 2 supported guard page sizes: 64KB and 4KB. The default guard page size is 64KB. The guard page size and probing interval must always be identical. Assuming a 64KB guard page, functions can allocate up to 63KB of stack and up to 1KB of outgoing arguments without requiring any probes. The callee save registers (specifically LR) count as an implicit probe. Because of this the current implementation does not provide adequate stack clash protection.
[Bug other/86486] GCC 8 stack clash protection on AArch64 is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86486 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-11 Ever confirmed|0 |1
[Bug c++/86465] C++17 triggers: ‘’ may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465 --- Comment #1 from Jonathan Wakely --- Possibly related to PR 86485 (just a guess, I haven't investigated).
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 sameerad at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sameerad at gcc dot gnu.org --- Comment #14 from sameerad at gcc dot gnu.org --- Assigned to myself.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #13 from Ramana Radhakrishnan --- Sameera, If you are working on this , can you please assign this to yourself ? Ramana
[Bug c++/86485] [7/8/9 Regression] "anonymous" maybe-uninitialized false positive with ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-11 Known to work||6.4.0 Summary|[ 7 regression] "anonymous" |[7/8/9 Regression] |maybe-uninitialized false |"anonymous" |positive with ternary |maybe-uninitialized false |operator|positive with ternary ||operator Ever confirmed|0 |1 Known to fail||7.3.0, 8.1.0, 9.0
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 Ramana Radhakrishnan changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-11 Ever confirmed|0 |1 --- Comment #12 from Ramana Radhakrishnan --- Confirmed then.
[Bug tree-optimization/86479] [9 Regression] [graphite] ICE in gimplify_modify_expr, at gimplify.c:5756
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86479 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-11 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. We are gimplifying via get_rename_from_scev (uf.1_3 < 0 ? prephitmp_15 / 0 : 0 / 0) * prephitmp_40 which is gimplified to control-flow because of the side-effects happening. We analyze _11 in a region covering the following BB (which itself isn't in a loop we analyze but inbetween two loops): : _4 = uf.1_3 < 0; _5 = (long int) _4; _6 = _5 * prephitmp_15; _9 = _6 / 0; ws = _9; _11 = _9 * prephitmp_40; *aw_23(D) = _11; and SCEV simply picks up the expressions and fold_binary_op_with_conditional_arg moves the division by zero into the COND_EXPR built for (long int) (uf.1_3 < 0) * prephitmp_15. That this turns out to be profitable is because 0 / 0 is TREE_CONSTANT and fold_binary_op_with_conditional_arg checks /* Check that we have simplified at least one of the branches. */ if (!TREE_CONSTANT (arg) && !TREE_CONSTANT (lhs) && !TREE_CONSTANT (rhs)) return NULL_TREE; ISTR that 0 / 0 being TREE_CONSTANT popped up lately elsewhere.
[Bug middle-end/61409] [6 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 Thomas Otto changed: What|Removed |Added CC||thomas.o...@pdv-fs.de --- Comment #30 from Thomas Otto --- (So... close as fixed?)
[Bug c++/86485] New: [ 7 regression] "anonymous" maybe-uninitialized false positive with ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485
Bug ID: 86485
Summary: [ 7 regression] "anonymous" maybe-uninitialized false
positive with ternary operator
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.o...@pdv-fs.de
Target Milestone: ---
Created attachment 44382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44382=edit
Minimal example for maybe-uninitialized false positive regression
The following minimal code example triggers the maybe-uninitialized warning on
gcc 8.1 and 7.3, but not on 5.3 or 6.2. Only shows up when optimizations are
enabled, and removing seemingly unrelated code "fixes" it again.
// compile with g++ 7.3 or 8.1 and optimizations enabled (not 5.3 or 6.2)
// g++ -O1 -c maybe_uninitialized_false_positive.cpp -o /dev/null
-Werror=maybe-uninitialized
// minimal working example created with creduce
struct empty_but_important {};
struct in_ternary_op {
in_ternary_op() noexcept {}
empty_but_important e; // REMOVE (or replace with int)
// and the error disappears
};
struct M {
M(in_ternary_op) noexcept;
};
struct MustInheritBase {
virtual M get_a(bool b) noexcept;
};
struct ZZ : MustInheritBase {
M get_a(bool b) noexcept { // b = true; // ADD and the error disappears
return M( b ? in_ternary_op{} : in_ternary_op{} );
// ^~
// error: '' may be used uninitialized in
//this function [-Werror=maybe-uninitialized]
// --
}
};
ZZ zz_fn() { // REMOVE and the error disappears
ZZ z;
return z;
}
[Bug c++/86483] alloc_size attribute does not work on functions returning a struct that contains the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86483 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Jonathan Wakely --- (In reply to gnzlbg from comment #0) > I have to set the alloc_size attribute for smallocx_return_t.ptr s/have to/want to/ surely? And if you did that, you'd be giving the compiler bad information. The point of the new API is that smallocx_return_t::ptr points to storage of size smallocx_return_t::usize bytes, **not** the size given by the 'size' parameter. If you tell the compiler the storage is smaller than 'usize' you're asking it to treat accesses past 'size' bytes as undefined behaviour (even though actually accesses up to usize are valid). A related problem is that you can't say a function parameter specifies the allocated size in some units other than bytes. std::allocator::allocate(size_t n) returns a pointer with space for n * sizeof(T) but you can't use alloc_size to tell the compiler that.
[Bug debug/86463] Slow compile with -ggdb and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 --- Comment #2 from Rob Farmer --- gfortran -ggdb -fno-var-tracking -c largeFile.f90 0m0.358s
[Bug c++/86473] a problem in member lookup?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86473 --- Comment #1 from Richard Biener --- *** Bug 86474 has been marked as a duplicate of this bug. ***
[Bug c++/86474] a problem in member lookup?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86474 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 86473 ***
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-11 Ever confirmed|0 |1
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-11 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Please attach preprocessed source, the snippet you pasted doesn't compile.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #8 from richard.earnshaw at arm dot com --- On 10/07/18 18:53, Kamil Rytarowski wrote: > On 10.07.2018 19:49, richard.earnshaw at arm dot com wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >> >> --- Comment #7 from richard.earnshaw at arm dot com --- >> On 10/07/18 10:57, Kamil Rytarowski wrote: >>> On 06.07.2018 15:26, Richard Earnshaw (lists) wrote: On 06/07/18 12:11, Kamil Rytarowski wrote: > On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >> On 06/07/18 11:32, Kamil Rytarowski wrote: >>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #2 from Richard Earnshaw --- I'm not sure how relevant the netbsd-elf port is these days. I believe they've now moved onto an EABI based ABI. But no GCC port of that has been contributed. >>> >>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A >>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre >>> ARMv4 CPUs use OABI only. >>> >> >> GCC-9 will drop support for pre-armv4 CPUs. Such support has been >> marked as deprecated for about 3 years now. >> > > We verify these ports on real hardware. > > NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is > obsoleting it and surprisingly LLVM soon might have support for a wider > range of ARM CPUs. > Shark's use strongARM cpus, which are ARMv4. That's not been obsoleted, but it is considered deprecated these days. >>> >>> Shark doesn't use all instructions that are generated by GCC (I forgot >>> the CPU property name of it) and thus it has to be switched to Clang/LLVM. >>> >> >> You're not making sense. Please be more explicit as to what you mean >> and give an example. GCC can generate instructions for ARMv4 and >> StrongARM (used by the shark) is an ARMv4 part. >> >> I've run gcc generated code on shark boards for years and not seen problems. >> >> R. >> > > I got a feedback that it's called: armv4t. > From whom? StrongARM is ARMv4. It is *not* ARMv4t as it does not support Thumb. Whatever, GCC can support both ARMv4 and ARMv4t. R.
Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
On 10/07/18 18:53, Kamil Rytarowski wrote: > On 10.07.2018 19:49, richard.earnshaw at arm dot com wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >> >> --- Comment #7 from richard.earnshaw at arm dot com --- >> On 10/07/18 10:57, Kamil Rytarowski wrote: >>> On 06.07.2018 15:26, Richard Earnshaw (lists) wrote: On 06/07/18 12:11, Kamil Rytarowski wrote: > On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >> On 06/07/18 11:32, Kamil Rytarowski wrote: >>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #2 from Richard Earnshaw --- I'm not sure how relevant the netbsd-elf port is these days. I believe they've now moved onto an EABI based ABI. But no GCC port of that has been contributed. >>> >>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A >>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre >>> ARMv4 CPUs use OABI only. >>> >> >> GCC-9 will drop support for pre-armv4 CPUs. Such support has been >> marked as deprecated for about 3 years now. >> > > We verify these ports on real hardware. > > NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is > obsoleting it and surprisingly LLVM soon might have support for a wider > range of ARM CPUs. > Shark's use strongARM cpus, which are ARMv4. That's not been obsoleted, but it is considered deprecated these days. >>> >>> Shark doesn't use all instructions that are generated by GCC (I forgot >>> the CPU property name of it) and thus it has to be switched to Clang/LLVM. >>> >> >> You're not making sense. Please be more explicit as to what you mean >> and give an example. GCC can generate instructions for ARMv4 and >> StrongARM (used by the shark) is an ARMv4 part. >> >> I've run gcc generated code on shark boards for years and not seen problems. >> >> R. >> > > I got a feedback that it's called: armv4t. > >From whom? StrongARM is ARMv4. It is *not* ARMv4t as it does not support Thumb. Whatever, GCC can support both ARMv4 and ARMv4t. R.
[Bug fortran/86468] [9 regression] ICE verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86468 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |9.0 Summary|[9.0 regression] ICE|[9 regression] ICE |verify_gimple failed|verify_gimple failed
[Bug middle-end/86467] inlining strcmp with small known length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86467 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Richard Biener --- I think there's a duplicate report.
[Bug libstdc++/86450] Bootstrap failure due to -Wabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 --- Comment #20 from Jonathan Wakely --- For libstdc++ the default (without --enable-werror or --disable-werror) is to add $(WERROR_FLAG) to WARN_FLAGS. WERROR_FLAG is empty by default, but contains -Werror for maintainer mode. So if you use --enable-maintainer-mode --disable-werror then -Werror won't be added to the libstdc++ flags. Is that an acceptable workaround for now? No code changes required. When I'm back from holiday I'll look into the libstdc++ warning flags and determine why -Wabi was added and how to make it actually work as intended.
