Re: How GCC treats ice-on-invalid-code?
I am sorry maybe I send this in a wrong place, I have sent this again in gcc-bug-requ...@gcc.gun.org. Haoxin Tu 于2020年6月30日周二 上午10:32写道： > Hi, there, > > Our team just develop a c++ code generator tool to testing the compiler, > and those days I have reported 13 ICE bugs in ice-on-invalid-bugs. > > Here are the bugs links: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95956 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95954 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95925 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95930 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95945 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937 > > Until now, only the last two cases are confirmed. So I am wondering that > how GCC treats with those cases in ice-on-invalid-code? I mean, our team is > focusing on improving the quality of the mature productive compilers. If > those bugs are useless for GCC, maybe I should stop reporting similar > issues. > > Waiting for your reply. Thank you very much! > > > Best regrades, > Haoxin >
How GCC treats ice-on-invalid-code?
Hi, there, Our team just develop a c++ code generator tool to testing the compiler, and those days I have reported 13 ICE bugs in ice-on-invalid-bugs. Here are the bugs links: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95956 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95954 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95925 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95930 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95945 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937 Until now, only the last two cases are confirmed. So I am wondering that how GCC treats with those cases in ice-on-invalid-code? I mean, our team is focusing on improving the quality of the mature productive compilers. If those bugs are useless for GCC, maybe I should stop reporting similar issues. Waiting for your reply. Thank you very much! Best regrades, Haoxin
[Bug c++/95987] New: Another ice during GIMPLE pass: slp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95987
Bug ID: 95987
Summary: Another ice during GIMPLE pass: slp
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
$ cat bug627.cc
int a;
class b {
void c();
static int f[];
};
void b::c() {
for (int d; d; ++d)
for (int e = 0; e < 6; ++e)
f[e] = e + 4 << a;
}
compiled on recent gcc trunk, does this:
$ /home/dcb/gcc/results/bin/c++ -c -w -O3 -std=c++14 bug627.cc
bug627.cc: In member function ‘void b::c()’:
bug627.cc:6:6: error: definition in block 3 follows the use
6 | void b::c() {
| ^
for SSA_NAME: a.0_16 in statement:
vect__17.12_53 = vect_cst__12 << a.0_16;
during GIMPLE pass: slp
bug627.cc:6:6: internal compiler error: verify_ssa failed
0x13fa7db verify_ssa(bool, bool)
../../trunk.git/gcc/tree-ssa.c:1208
0x108dde5 execute_function_todo
../../trunk.git/gcc/passes.c:1992
The bug seems to first occur sometime between 20200624 and 20200625.
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #12 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> --- (In reply to Marc Glisse from comment #11) > while(!a.isZero()); > > that doesn't look like something you would find in real code. Are you > waiting for a different thread to modify a? Then you should use an atomic > operation. Are you waiting for the hardware to change something? Use > volatile. Do you really want an infinite loop? Spell it out > if(!a.isZero())for(;;); The code I sent is a downsized version of a larger code, which means that the posted code isn't the real code.
[Bug c++/95977] No deallocation of temporary in return-statement during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95977
--- Comment #1 from Johel Ernesto Guerrero Peña ---
Slightly simplified: https://godbolt.org/z/9unpTF.
```C++
struct X {
int* x{new int{42}};
constexpr ~X() { delete x; }
};
constexpr int f() { return *X{}.x; }
constexpr int z{f()};
```
[Bug bootstrap/95970] gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Ian Lance Taylor --- Should be fixed now.
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #11 from Marc Glisse --- while(!a.isZero()); that doesn't look like something you would find in real code. Are you waiting for a different thread to modify a? Then you should use an atomic operation. Are you waiting for the hardware to change something? Use volatile. Do you really want an infinite loop? Spell it out if(!a.isZero())for(;;);
[Bug bootstrap/95970] gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970 --- Comment #6 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:9bca676cc7a1670be021567ae4a128a5082229d3 commit r11-1721-g9bca676cc7a1670be021567ae4a128a5082229d3 Author: Ian Lance Taylor Date: Mon Jun 29 11:30:43 2020 -0700 compiler: remove some erroneous code that was never run The code accidentally called Type::type_descriptor rather than the do_type_descriptor method. Calling Type::type_descriptor with a second argument of NULL would always crash. Since that never happened, it revealed that this code was never actually executed. Fixes PR go/95970 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/240477
[Bug fortran/95978] [10/11 Regression] ICE in gfc_match_data, at fortran/decl.c:731
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95978 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from anlauf at gcc dot gnu.org --- Committed as obvious on master: https://gcc.gnu.org/pipermail/fortran/2020-June/054650.html
[Bug fortran/95978] [10/11 Regression] ICE in gfc_match_data, at fortran/decl.c:731
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95978 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:583812c2e2f3593823622b0a5821d957c832dbd0 commit r11-1720-g583812c2e2f3593823622b0a5821d957c832dbd0 Author: Harald Anlauf Date: Mon Jun 29 23:20:16 2020 +0200 PR fortran/95978 - ICE in gfc_match_data, at fortran/decl.c:731 Catch NULL pointer dereference on invalid DATA statement. gcc/fortran/ PR fortran/95978 * decl.c (gfc_match_data): Avoid NULL pointer dereference.
[Bug c++/95883] Attributes on lambdas appear to be parsed in the wrong place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95883 --- Comment #4 from Timothee Besset --- We are in the same situation; we are assessing a move to a newer gcc but we need to maintain compatibility with older gcc, at least for the time being. We would like to avoid having to use macros for all of this.
[Bug fortran/95743] [9/10/11 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95743 --- Comment #3 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:95cdcf701dad826f225d6413b59650f181954399 commit r11-1719-g95cdcf701dad826f225d6413b59650f181954399 Author: Thomas Koenig Date: Mon Jun 29 23:11:06 2020 +0200 Do not generate recursion check for compiler-generated procedures. This one-line fix removes a check for recursion for procedures which are compiler-generated, such as finalizers or deallocation. These need to be recursive, even if the user code should not be. gcc/fortran/ChangeLog: PR fortran/95743 * trans-decl.c (gfc_generate_function_code): Do not generate recursion check for compiler-generated procedures.
[Bug c++/95883] Attributes on lambdas appear to be parsed in the wrong place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95883 Patrick Moran changed: What|Removed |Added CC||patrick.a.moran at gmail dot com --- Comment #3 from Patrick Moran --- My argument in favor of restoring the pre-9-series behavior is that of compiler portability. When you have a lambda with a trailing return type that you want to mark with __attribute__((always_inline)) there's now one syntax that works with GCCs before 9.1 and with clang (who is matching gcc), and another syntax that works with GCCs after 9.3, but not with any GCC before 9.3 or any version of clang. If you want to write code that works with GCC 8.3 and 10.1, or with both GCC 10.1 and any clang, then you have to write macros to move the attributes around. Whereas if the patch in this bug (or another like it), then at least the one existing codebase I'm working on won't have to add a macro layer to be able to support lambdas across our range of supported compilers.
[Bug fortran/95978] [10/11 Regression] ICE in gfc_match_data, at fortran/decl.c:731
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95978
--- Comment #3 from anlauf at gcc dot gnu.org ---
The obvious patch
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ac1f63f66e0..f38def4c291 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -728,7 +728,7 @@ gfc_match_data (void)
gfc_constructor *c;
c = gfc_constructor_first (new_data->value->expr->value.constructor);
for (; c; c = gfc_constructor_next (c))
- if (c->expr->ts.type == BT_BOZ)
+ if (c->expr && c->expr->ts.type == BT_BOZ)
{
gfc_error ("BOZ literal constant at %L cannot appear in a "
"structure constructor", >expr->where);
leads to:
z1.f90:5:19:
5 | data c /t(1)/
| 1
Error: Unexpected DATA statement at (1)
[Bug fortran/95978] [10/11 Regression] ICE in gfc_match_data, at fortran/decl.c:731
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95978 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- The offending commit is c77b6f95e014ad1f6654683ff56f9508fe7f268d by Mark and Steven.
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-June/054648.html
[Bug bootstrap/95940] [11 Regression] sparc64-linux bootstrap with gcc-9.3 broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940 --- Comment #3 from Hans-Peter Nilsson --- Created attachment 48810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48810=edit tree-ssanames.ii.gz Beware, gzippped file. Repeat with /home/hp/combcheck/o0/./prev-gcc/cc1plus -fpreprocessed tree-ssanames.ii -quiet -dumpbase tree-ssanames.c -dumpbase-ext .c -mcpu=v9 -g -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wsuggest-attribute=format -Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version -fno-PIE -fno-checking -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -o tree-ssanames.s (in stage 2)
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971
--- Comment #10 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail
dot com> ---
I hope you do realize that the code I posted previously is equivalent, or very
close to being equivalent, to the following code:
struct President {
const bool dead = false;
bool isDead() { return dead; }
} president;
while(!president.isDead());
if(president.isDead()) {
launch_retaliation_nukes();
}
With -ffinite-loops enabled, the nukes are going to be launched because the
only way that the while-loop can terminate is for President::dead to be true
and thus the "const bool dead" can be assumed to be true when execution reaches
the if-statement after skipping the deleted infinite while loop.
[Bug bootstrap/95940] [11 Regression] sparc64-linux bootstrap with gcc-9.3 broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Martin Sebor from comment #1) > Can you provide a test case or a translation unit? You're aware that the report is for bootstrap stage2 on a CompileFarm machine? >From the look of it, something is already miscompiled. I'm not sure how e.g. tree-ssanames.ii by itself would help, but I'll attach it.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #14 from Thomas Koenig --- Because the version in bugzilla is set to 10.0, so I assumed it occurred there, too. Even better if it is not there.
[Bug fortran/95978] [10/11 Regression] ICE in gfc_match_data, at fortran/decl.c:731
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95978 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-06-29 Status|UNCONFIRMED |NEW Target Milestone|--- |10.2 Known to fail||10.1.0, 11.0 Priority|P3 |P4 Known to work||9.3.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- My build at 2019-12-18 doesn't give an ICE, gcc11-706 does. Probably a change on master, back ported to GCC10.
[Bug tree-optimization/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95984
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-06-29
CC||jason at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
If I'm reading the dump right the front end constructs a lambda object and
calls its member operator() with a null this pointer:
;; Function static decltype (((const callback
>::*)0)->operator()(static_cast(callback::._anon_2::_FUN::) ...))
callback >_FUN(auto:1 ...) [with
auto:1 = {int}; decltype (((const callback
>::*)0)->operator()(static_cast(callback::._anon_2::_FUN::) ...)) = void]
(null)
;; enabled by -tree-original
< >operator() (0B,
D.2439) >;
return;
So it seems like the warning code is doing what it's supposed to.
The ICE is triggered by the C++ front end printing the instantiation context
(print_instantiation_full_context), the pretty printer formatting the template
specialization, calling into the C++ front end to perform type substitution,
and the FE ending up calling check_nonnull_arg() on the call, which ends up
triggering the warning and re-entering the diagnostic machinery. There is
nothing out of the ordinary the warning does to do this so it must be a latent
problem in the C++ front end that the warning exposed. I expect Jason or Marek
have seen and deal with something like this before.
[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979 --- Comment #1 from Dominique d'Humieres --- I don't see the ICE on a standard GCC11, but its instrumented version gives ../../work/gcc/fortran/simplify.c:127:10: runtime error: load of value 4294967295, which is not a valid value for type 'expr_t' ../../work/gcc/fortran/error.c:970:2: runtime error: member access within misaligned address 0x0002 for type 'struct gfc_linebuf', which requires 8 byte alignment 0x0002: note: pointer points here ../../work/gcc/fortran/error.c:971:46: runtime error: member access within misaligned address 0x0002 for type 'struct gfc_linebuf', which requires 8 byte alignment 0x0002: note: pointer points here ../../work/gcc/fortran/error.c:979:42: runtime error: member access within misaligned address 0x0002 for type 'struct gfc_linebuf', which requires 8 byte alignment 0x0002: note: pointer points here The instrumented GCC9 and 10 give the expected error.
[Bug fortran/95743] [9/10/11 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95743 Thomas Koenig changed: What|Removed |Added Summary|[9/10 Regression] bogus |[9/10/11 Regression] bogus |recursive call to |recursive call to |nonrecursive procedure with |nonrecursive procedure with |-fcheck=recursion |-fcheck=recursion --- Comment #2 from Thomas Koenig --- Also fails on current master.
[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2020-06-29 CC||anlauf at gcc dot gnu.org Target Milestone|--- |10.2 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #13 from David Edelsohn --- Committed, but why gcc-10? I don't see the testcase on that branch.
[Bug c++/95949] mame build succeeds with -O3 but fails with -O2 and all -O3 flags added manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95949 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #9 from Jonathan Wakely --- Thanks
[Bug c++/95986] New: Partial specialization of class template is not found when class template has NTTP of class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95986
Bug ID: 95986
Summary: Partial specialization of class template is not found
when class template has NTTP of class type
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bence.kodaj at gmail dot com
Target Milestone: ---
In the code below I would expect the static assertion __not__ to fail, but it
does.
OS: Ubuntu 18.04.
Godbolt: https://godbolt.org/z/absUyx
---
#include
template< typename, template< auto... > typename >
struct IsInstantationOf : std::false_type {};
template< template< auto... > typename Template, auto... Arg >
struct IsInstantationOf< Template< Arg... >, Template > : std::true_type {};
template< std::size_t N >
struct StrLiteral {
constexpr StrLiteral( const char ( & )[ N ] ) {}
};
template< StrLiteral >
struct Template {};
int main()
{
const auto a = StrLiteral( "a" );
static_assert( IsInstantationOf< Template< a >, Template >::value );
return 0;
}
---
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #12 from Thomas Koenig --- (In reply to David Edelsohn from comment #11) > With the patch the testcase succeeds on both powerpc-ibm-aix7.2.0.0 (big > endian) and powerpc64-linux (little endian) OK for master and gcc-10 then (unless you prefer to commit this as simple and obvious :-) Thanks!
[Bug c/95857] [8/9/10/11 Regression] Silencing an unused label warning with (void)& can make gcc segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95857
--- Comment #2 from Jakub Jelinek ---
Slightly simplified:
struct E { int e; };
int bar (void), baz (void);
void
foo (void)
{
struct E a = { 0 };
struct E i = { 0 };
if (baz ())
i.e = 1;
else
a.e = -2;
switch (a.e)
{
case -2:
lab1:
switch (i.e)
{
case -3:
case 2:
if (i.e-- != 2)
__builtin_unreachable ();
(void) &
lab2:
baz ();
goto lab1;
case 0:
bar ();
}
}
}
[Bug c++/95302] function attributed to be deprecated cannot include a typedef/using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95302
Rafael Avila de Espindola changed:
What|Removed |Added
CC||rafael at espindo dot la
--- Comment #2 from Rafael Avila de Espindola ---
The same problem happens with a namespace alias:
namespace foo {
void bar();
}
[[deprecated("zed")]] inline void zed() {
namespace a = foo;
a::bar();
}
Produces:
test.cc: In function ‘void zed()’:
test.cc:6:8: warning: ‘void zed()’ is deprecated: zed
[-Wdeprecated-declarations]
6 | a::bar();
|^~~
test.cc:4:35: note: declared here
4 | [[deprecated("zed")]] inline void zed() {
| ^~~
If instead of the alias foo::bar() is used directly, no warning is produced.
The issue is still present on current master
(346bce6fe0cf1ed5f6a7ad732d2361d77b203c87).
[Bug c++/95985] [11 Regression] ICE: tree check: expected tree_list, have error_mark in common_handle_aligned_attribute, at c-family/c-attribs.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95985
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Keywords||error-recovery
--- Comment #2 from Jakub Jelinek ---
While we could do something like:
--- c-attribs.c.jj 2020-06-10 14:58:17.422495938 +0200
+++ c-attribs.c 2020-06-29 21:25:58.300888506 +0200
@@ -1975,7 +1975,9 @@ common_handle_aligned_attribute (tree *n
yet. */
tree last_decl = node[1] ? node[1] : *node;
- if (args)
+ if (args == error_mark_node)
+align_expr = args;
+ else if (args)
{
align_expr = TREE_VALUE (args);
if (align_expr && TREE_CODE (align_expr) != IDENTIFIER_NODE
I don't think it scales well, because we have hundreds of *handle_*attribute
functions and all of them assume that args is either NULL or a TREE_LIST and
changing them doesn't look right.
[Bug c++/95985] [11 Regression] ICE: tree check: expected tree_list, have error_mark in common_handle_aligned_attribute, at c-family/c-attribs.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95985 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-06-29 Ever confirmed|0 |1 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r11-423-gcda6396a1b6e6bba2a3b0847931567c3458f2184
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #9 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> --- (In reply to Martin Liška from comment #8) > Or you can use -fno-finite-loops option. I am sorry, but I cannot trust this compiler not to force me again spending several hours of time just to learn that -O2 is semantically different from -O1 and -O3. The meaning of "semantically equivalent" in my mind is different from the meaning of "semantically equivalent" in your mind. Infinite loopiness is in my opinion semantically significant, so the compiler should have printed a warning that would inform me about the fact that the compiler is changing the semantics of the code in question. With -O3, the assembly code is: Dump of assembler code for function main: <+0>:sub$0x8,%rsp <+4>:xor%edi,%edi <+6>:callq xbool(bool) <+11>: jmpmain+11 "11: jmp 11" is a prime example of what -ffinite-loops is supposed to prevent from being generated. Assuming that -O3 actually does include -ffinite-loops, which I am unable to verify because "g++ --help=optimizers -Q" doesn't accept the -std=gnu++11 option.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #11 from David Edelsohn --- With the patch the testcase succeeds on both powerpc-ibm-aix7.2.0.0 (big endian) and powerpc64-linux (little endian)
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 --- Comment #10 from David Edelsohn --- Created attachment 48809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48809=edit Updated regex for either endianness The new patch updates the regexps to accept the result for either endianness. And removes the extra quoting from the regexps.
[Bug fortran/95981] ICE in gfc_find_array_ref(): No ref found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95981
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-29
Priority|P3 |P4
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Patch is against svn revision 280156.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -1137,7 +1137,9 @@ dim_rank_check (gfc_expr *dim, gfc_expr *array, int al
if (array->expr_type == EXPR_VARIABLE)
{
- ar = gfc_find_array_ref (array);
+ ar = gfc_find_array_ref (array, true);
+ if (!ar)
+ return false;
if (ar->as->type == AS_ASSUMED_SIZE
&& !allow_assumed
&& ar->type != AR_ELEMENT
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-29
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #8 from Martin Liška --- Or you can use -fno-finite-loops option.
[Bug c++/95985] New: [11 Regression] ICE: tree check: expected tree_list, have error_mark in common_handle_aligned_attribute, at c-family/c-attribs.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95985
Bug ID: 95985
Summary: [11 Regression] ICE: tree check: expected tree_list,
have error_mark in common_handle_aligned_attribute, at
c-family/c-attribs.c:1980
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-11.0.0-alpha20200628 snapshot (g:b26fd416fb0a734d3f3e56629b6dff2e3c25dd40)
ICEs when compiling the following testcase, extracted from
test/std/utilities/variant/variant.variant/variant_void.fail.cpp from the
libcxx 10.0.0 test suite:
template
struct pf {
struct sr;
alignas (sr) int ci;
};
pf ci;
% g++-11.0.0 -c hdbdodhk.cpp
hdbdodhk.cpp: In instantiation of 'struct pf':
hdbdodhk.cpp:7:9: required from here
hdbdodhk.cpp:4:12: error: invalid application of '__alignof__' to incomplete
type 'pf::sr'
4 | alignas (sr) int ci;
|^~
hdbdodhk.cpp:4:20: internal compiler error: tree check: expected tree_list,
have error_mark in common_handle_aligned_attribute, at
c-family/c-attribs.c:1980
4 | alignas (sr) int ci;
|^~
0x7c7f86 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/tree.c:9685
0x6b475b tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/tree.h:3301
0x6b475b common_handle_aligned_attribute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/c-family/c-attribs.c:1980
0xaa3247 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/attribs.c:714
0x92e187 cplus_decl_attributes(tree_node**, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/decl2.c:1601
0xa0cb99 tsubst_decl
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/pt.c:14379
0xa303cd instantiate_class_template_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/pt.c:11843
0xa317f2 instantiate_class_template(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/pt.c:12098
0xa7a109 complete_type(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/typeck.c:137
0x8fc4a3 start_decl_1(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/decl.c:5490
0x91e888 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/decl.c:5453
0x9ce4b1 cp_parser_init_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/parser.c:20818
0x9aeb76 cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/parser.c:13785
0x9d92f6 cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/parser.c:13484
0x9d9a4f cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/parser.c:4761
0x9d9a4f c_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/cp/parser.c:44043
0xaf677b c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200628/work/gcc-11-20200628/gcc/c-family/c-opts.c:1190
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #7 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> --- (In reply to Martin Liška from comment #6) > All right, so it's caused by cdde1: > > Assume loop 1 to be finite: it has an exit and -ffinite-loops is on. > >-ffinite-loops >Assume that a loop with an exit will eventually take the exit and > not loop indefinitely. This allows the compiler to remove loops that > otherwise have no side-effects, not considering eventual endless looping as > such. > >This option is enabled by default at -O2 for C++ with -std=c++11 > or higher. Thank you for the explanation. Your mindset is forcing me to stop using g++ over time because of reliability concerns during application development. Sincerely Jan
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #9 from David Edelsohn ---
This set of regexps works for me:
! { dg-final { scan-tree-dump { \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
"(d\\x00\\x
00|\\x00\\x00\\x00d)"\[1\]{lb: 1 sz: 4};} "original" } }
! { dg-final { scan-tree-dump { __builtin_memmove \(\(void \*\)
&\(\*var.str2\)
\[2\]{lb: 1 sz: 4}, \(void \*\)
&"(e\\x00\\x00\\x00f\\x00\\x00|\\x00\\x00\\x00e\
\x00\\x00\\x00f)"\[1\]{lb: 1 sz: 4}, 8\);} "original" } }
! { dg-final { scan-tree-dump { \(\*var.str2\)\[4\]{lb: 1 sz: 4} =
"(\\x00\\xf6
\\x01|\\x00\\x01\\xf6)"\[1\]{lb: 1 sz: 4};} "original" } }
! { dg-final { scan-tree-dump { \(\*var.str2\)\[5\]{lb: 1 sz: 4} =
"(\\b\\xf6\\
x01|\\x00\\x01\\xf6\\b)"\[1\]{lb: 1 sz: 4};} "original" } }
Okay?
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
Patch is against svn r280156.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -6174,7 +6174,10 @@ build_class_sym:
{
/* The correct class container has to be available. */
assoc_sym->ts.type = BT_CLASS;
- assoc_sym->ts.u.derived = CLASS_DATA (selector)->ts.u.derived;
+ if (CLASS_DATA (selector)->ts.u.derived != NULL)
+assoc_sym->ts.u.derived = CLASS_DATA (selector)->ts.u.derived;
+ else
+assoc_sym->ts.u.derived = selector->ts.u.derived;
assoc_sym->attr.pointer = 1;
gfc_build_class_symbol (_sym->ts, _sym->attr,
_sym->as);
}
[Bug tree-optimization/95984] New: [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95984
Bug ID: 95984
Summary: [11 Regression] Internal compiler error: Error
reporting routines re-entered. since
r11-1697-g75ff24e1920ea6b1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Since the revision I see:
$ cat
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic6.C
// PR c++/78816
// { dg-do compile { target c++14 } }
void f(void (*f1)(int)) {
f1(42);
}
template
static auto callback(Lambda &)
{
static auto* p =
p =
return [](auto... x){ return (*p)(x...); };
}
int main() {
int x = 5;
f(callback([=](int y){}));
}
$ g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic6.C
-Wnonnull
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic6.C:
In substitution of ‘template constexpr
callback >operator decltype
(((const callback >::*)0)->operator()(static_cast(callback::._anon_2::_FUN::) ...))
(*)(auto:1 ...)() const [with auto:1 = {int}]’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic6.C:18:27:
required from here
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic6.C:13:10:
warning: ‘this’ pointer null [-Wnonnull]
13 | return [](auto... x){ return (*p)(x...); };
| ^
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic6.C:13:10:
note: in a call to non-static member function ‘callback
>:: [with auto:1 = {int}]’
‘
Internal compiler error: Error reporting routines re-entered.
0xb04ef1 check_nonnull_arg
/home/marxin/Programming/gcc/gcc/c-family/c-common.c:5523
0xb05f72 check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned
long), void*, tree_node*, unsigned long)
/home/marxin/Programming/gcc/gcc/c-family/c-common.c:5881
0xb05cd1 check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned
long), void*, tree_node*, unsigned long)
/home/marxin/Programming/gcc/gcc/c-family/c-common.c:5813
0xb043e8 check_function_nonnull
/home/marxin/Programming/gcc/gcc/c-family/c-common.c:5315
0xb05a9e check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
/home/marxin/Programming/gcc/gcc/c-family/c-common.c:5764
0x867a94 build_over_call
/home/marxin/Programming/gcc/gcc/cp/call.c:8868
0x869e3c build_new_method_call_1
/home/marxin/Programming/gcc/gcc/cp/call.c:10348
0x86ad5f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/marxin/Programming/gcc/gcc/cp/call.c:10423
0xa2b3f2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:20042
0xa2d1c0 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:15913
0x935ad7 dump_template_bindings
/home/marxin/Programming/gcc/gcc/cp/error.c:416
0x935d30 dump_substitution
/home/marxin/Programming/gcc/gcc/cp/error.c:1562
0x935d30 dump_substitution
/home/marxin/Programming/gcc/gcc/cp/error.c:1550
0x92f610 dump_function_decl
/home/marxin/Programming/gcc/gcc/cp/error.c:1720
0x937178 decl_to_string
/home/marxin/Programming/gcc/gcc/cp/error.c:3101
0x937178 cp_printer
/home/marxin/Programming/gcc/gcc/cp/error.c:4261
0x1e2aafc pp_format(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1475
0x1e2cb80 pp_format_verbatim(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1536
0x1e2cb80 pp_verbatim(pretty_printer*, char const*, ...)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1790
0x92ce56 print_instantiation_full_context
/home/marxin/Programming/gcc/gcc/cp/error.c:3503
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/95982] ICE with non-type template parameter that is itself the instantiation of a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95982 --- Comment #2 from Bence Kodaj --- Note: the ICE goes away if I remove the -Wall option.
[Bug c++/95982] ICE with non-type template parameter that is itself the instantiation of a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95982
Bence Kodaj changed:
What|Removed |Added
URL|https://wandbox.org/permlin |https://godbolt.org/z/6BpK2
|k/A9ImqBRe5vyZMFWC |9
--- Comment #1 from Bence Kodaj ---
Sorry, there's a typo in the code - here's the fixed version.
Godbolt URL: https://godbolt.org/z/6BpK29
---
#include
template< typename, template< auto > typename >
struct IsImplementationOf : std::false_type {};
template< template< auto > typename Template, auto Arg >
struct IsImplementationOf< Template< Arg >, Template > : std::true_type {};
template< typename T >
struct X {
constexpr X( T ) {}
};
template< X > struct Y {};
int main()
{
static_assert( IsImplementationOf< Y< X(0) >, Y >::value );
return 0;
}
---
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #6 from Martin Liška --- All right, so it's caused by cdde1: Assume loop 1 to be finite: it has an exit and -ffinite-loops is on. -ffinite-loops Assume that a loop with an exit will eventually take the exit and not loop indefinitely. This allows the compiler to remove loops that otherwise have no side-effects, not considering eventual endless looping as such. This option is enabled by default at -O2 for C++ with -std=c++11 or higher.
[Bug libstdc++/95983] New: `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 Bug ID: 95983 Summary: `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator` Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- https://wandbox.org/permlink/rUZlUGG4UFeWicbM #include #include #include using R = std::ranges::basic_istream_view>; using It = std::ranges::iterator_t; static_assert(std::input_or_output_iterator>); prog.cc:5:20: error: static assertion failed 5 | static_assert(std::input_or_output_iterator>); | ~^~ prog.cc:5:20: note: constraints not satisfied In file included from /opt/wandbox/gcc-head/include/c++/11.0.0/bits/stl_iterator_base_types.h:71, from /opt/wandbox/gcc-head/include/c++/11.0.0/iterator:61, from /opt/wandbox/gcc-head/include/c++/11.0.0/ranges:44, from prog.cc:1: /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:536:13: required for the satisfaction of 'weakly_incrementable<_Iter>' [with _Iter = std::counted_iterator >::_Iterator > >] /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:538:10: in requirements with '_Iter __i' [with _Tp = std::counted_iterator >::_Iterator > >; _Iter = std::counted_iterator >::_Iterator > >] /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:540:11: note: the required type 'std::iter_difference_t<_Iter>' is invalid 540 | typename iter_difference_t<_Iter>; | ~^ /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:541:21: note: nested requirement '__is_signed_integer_like::type>::type, std::incrementable_traits::type>::type> >::type::difference_type>' is not satisfied 541 | requires __detail::__is_signed_integer_like>; | ~~^~ cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more detail It seems that in this case, `iter_difference_t` is treated as an alias of `std::iterator_traits>::difference_type` (which doesn't exist), because libstdc++ defines a specialization of `std::iterator_traits>`. (The error message is worse than it should be, due to bug 94862 and bug 95303.)
[Bug c++/95982] New: ICE with non-type template parameter that is itself the instantiation of a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95982
Bug ID: 95982
Summary: ICE with non-type template parameter that is itself
the instantiation of a template
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bence.kodaj at gmail dot com
Target Milestone: ---
The code below causes an ICE saying "unexpected expression ‘’ of
kind template_parm_index".
OS: Ubuntu 18.04
g++ version: 10.1.0
Wandbox URL: https://wandbox.org/permlink/A9ImqBRe5vyZMFWC#
---
#include
template< typename, template< auto > typename >
struct IsImplementationOf : std::false_type {};
template< template< auto > typename Template, auto Arg >
struct IsImplementationOf< Template< Arg >, Template > : std::true_type {};
template< typename T >
struct X {
constexpr X( T ) {}
};
template< X > struct Y {};
int main()
{
static_assert( IsImplementationOf< Y< X(0) >, Y > );
return 0;
}
---
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> changed: What|Removed |Added Attachment #48804|0 |1 is obsolete|| --- Comment #5 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> --- Created attachment 48808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48808=edit a.cc Initialize A::a to a valid heap pointer, instead of initializing it to (char*)1.
[Bug fortran/95981] New: ICE in gfc_find_array_ref(): No ref found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95981 Bug ID: 95981 Summary: ICE in gfc_find_array_ref(): No ref found Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects also versions down to at least r5. With a missing attribute allocatable or pointer : $ cat z1.f90 program p type t end type class(t) :: x(:) type(t) :: y(size(x,1)) end $ gfortran-11-20200628 -c z1.f90 f951: internal compiler error: gfc_find_array_ref(): No ref found 0x657489 gfc_report_diagnostic ../../gcc/fortran/error.c:782 0x658baa gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1402 0x628e4c gfc_find_array_ref(gfc_expr*, bool) ../../gcc/fortran/array.c:2750 0x629f7a dim_rank_check ../../gcc/fortran/check.c:1145 0x6317fc dim_rank_check ../../gcc/fortran/check.c:5140 0x6317fc gfc_check_size(gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/check.c:5135 0x66cf6c do_check ../../gcc/fortran/intrinsic.c:4749 0x66cf6c check_specific ../../gcc/fortran/intrinsic.c:4762 0x677264 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4999 0x6c52d3 resolve_unknown_f ../../gcc/fortran/resolve.c:2902 0x6c52d3 resolve_function ../../gcc/fortran/resolve.c:3246 0x6c52d3 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7037 0x64a4af variable_decl ../../gcc/fortran/decl.c:2595 0x64a4af gfc_match_data_decl() ../../gcc/fortran/decl.c:6197 0x6ae0a3 match_word ../../gcc/fortran/parse.c:65 0x6ae0a3 decode_statement ../../gcc/fortran/parse.c:376 0x6afaea next_free ../../gcc/fortran/parse.c:1280 0x6afaea next_statement ../../gcc/fortran/parse.c:1512 0x6b113b parse_spec ../../gcc/fortran/parse.c:3923 0x6b3f0c parse_progunit ../../gcc/fortran/parse.c:5852
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Related (and presumably also pr86551) : $ cat z2.f90 program p type t end type class(t) :: x select type (y => x) end select end $ gfortran-11-20200628 -c z2.f90 f951: internal compiler error: Segmentation fault 0xbd215f crash_signal ../../gcc/toplev.c:328 0x686d9b copy_ts_from_selector_to_associate ../../gcc/fortran/match.c:6162 0x68f543 gfc_match_select_type() ../../gcc/fortran/match.c:6422 0x6ae2b4 match_word ../../gcc/fortran/parse.c:65 0x6ae2b4 decode_statement ../../gcc/fortran/parse.c:428 0x6afaea next_free ../../gcc/fortran/parse.c:1280 0x6afaea next_statement ../../gcc/fortran/parse.c:1512 0x6b113b parse_spec ../../gcc/fortran/parse.c:3923 0x6b3f0c parse_progunit ../../gcc/fortran/parse.c:5852 0x6b55e9 gfc_parse_file() ../../gcc/fortran/parse.c:6393 0x7016ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug bootstrap/95970] gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970 --- Comment #5 from Martin Sebor --- Yes, that's what it's saying. Unfortunately, the locations of null pointer constants isn't available in the middle end so all we have left is the function calls they're used in.
[Bug fortran/95980] New: ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 Bug ID: 95980 Summary: ICE in get_unique_type_string, at fortran/class.c:485 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5. With a missing attribute allocatable or pointer : $ cat z1.f90 program p type t integer :: a end type class(t) :: x select type (y => x) end select end $ gfortran-11-20200628 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbd215f crash_signal ../../gcc/toplev.c:328 0x63535a get_unique_type_string ../../gcc/fortran/class.c:485 0x635de1 get_unique_hashed_string ../../gcc/fortran/class.c:522 0x6392ce gfc_build_class_symbol(gfc_typespec*, symbol_attribute*, gfc_array_spec**) ../../gcc/fortran/class.c:666 0x68f543 gfc_match_select_type() ../../gcc/fortran/match.c:6422 0x6ae2b4 match_word ../../gcc/fortran/parse.c:65 0x6ae2b4 decode_statement ../../gcc/fortran/parse.c:428 0x6afaea next_free ../../gcc/fortran/parse.c:1280 0x6afaea next_statement ../../gcc/fortran/parse.c:1512 0x6b113b parse_spec ../../gcc/fortran/parse.c:3923 0x6b3f0c parse_progunit ../../gcc/fortran/parse.c:5852 0x6b55e9 gfc_parse_file() ../../gcc/fortran/parse.c:6393 0x7016ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/95979] New: [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979
Bug ID: 95979
Summary: [10/11 Regression] ICE in get_kind, at
fortran/simplify.c:129
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20191215 and 20200105 :
$ cat z1.f90
program p
integer :: a = index('abcd', 'c', [.true.], kind=1)
end
$ cat z2.f90
program p
integer :: a = index('abcd', 'c', [.true.], kind=4)
end
$ cat z3.f90
program p
integer :: a(1) = index('abcd', 'c', [.true.])
integer :: b(1) = index('abcd', 'c', [.true.], kind=1)
print *, a
print *, b
end
$ gfortran-10-20191215 -c z1.f90
z1.f90:2:15:
2 |integer :: a = index('abcd', 'c', [.true.], kind=1)
| 1
Error: Incompatible ranks 0 and 1 in assignment at (1)
$ gfortran-11-20200628 -c z1.f90
0xbd215f crash_signal
../../gcc/toplev.c:328
0x65730f gfc_format_decoder
../../gcc/fortran/error.c:981
0x1504fce pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1475
0x14f96df diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:1159
0x657489 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x65759b gfc_error_opt
../../gcc/fortran/error.c:1352
0x658aa0 gfc_error(char const*, ...)
../../gcc/fortran/error.c:1381
0x6db27a get_kind
../../gcc/fortran/simplify.c:129
0x6e4ce1 gfc_simplify_index(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:3479
0x66c997 do_simplify
../../gcc/fortran/intrinsic.c:4634
0x677178 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4899
0x65d5f9 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2180
0x65e03a scalarize_intrinsic_call
../../gcc/fortran/expr.c:2422
0x65c82b gfc_check_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2934
0x65cb07 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3087
0x65fd70 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3133
0x64b5f4 variable_decl
../../gcc/fortran/decl.c:2886
0x64b5f4 gfc_match_data_decl()
../../gcc/fortran/decl.c:6197
0x6ae0a3 match_word
../../gcc/fortran/parse.c:65
0x6ae0a3 decode_statement
../../gcc/fortran/parse.c:376
[Bug fortran/95978] New: [10/11 Regression] ICE in gfc_match_data, at fortran/decl.c:731
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95978 Bug ID: 95978 Summary: [10/11 Regression] ICE in gfc_match_data, at fortran/decl.c:731 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- This changed between 20200223 and 20200308 : $ cat z1.f90 program p type t integer :: a type(t), allocatable :: b data c /t(1)/ end type end $ cat z2.f90 program p type t integer :: a class(*), allocatable :: b data c /t(1)/ end type end $ gfortran-10-20200223 -c z1.f90 z1.f90:5:19: 5 | data c /t(1)/ | 1 Error: Unexpected DATA statement at (1) $ gfortran-11-20200628 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbd215f crash_signal ../../gcc/toplev.c:328 0x6419e5 gfc_match_data() ../../gcc/fortran/decl.c:731 0x6aacb1 match_word ../../gcc/fortran/parse.c:65 0x6aed7e decode_statement ../../gcc/fortran/parse.c:469 0x6afaea next_free ../../gcc/fortran/parse.c:1280 0x6afaea next_statement ../../gcc/fortran/parse.c:1512 0x6b1574 parse_derived ../../gcc/fortran/parse.c:3343 0x6b1574 parse_spec ../../gcc/fortran/parse.c:3884 0x6b3f0c parse_progunit ../../gcc/fortran/parse.c:5852 0x6b55e9 gfc_parse_file() ../../gcc/fortran/parse.c:6393 0x7016ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug rtl-optimization/89310] Poor code generation returning float field from a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310 --- Comment #6 from Segher Boessenkool --- rldicr is one of the insns generated by "*rotl3_mask", which recognises all canonical formulations of all our rotate-and-mask instructions.
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-06-29 --- Comment #4 from Martin Liška --- > The source code initializes A::a to (char*)1 in order to keep the code as > small as possible to trigger the issue. A::a could have been initialized to > a valid delete-able heap address, but this would unnecessarily enlarge the > source code. Thank you for the report. Please extend the example in order to not contain undefined behavior. delete 1 crashes for me.
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #8 from David Edelsohn ---
It uses . where it wants to consume a quotation mark (").
Because the BE/LE difference is flipping characters, would it negate the
purpose of the test to check for one or zero characters?
! { dg-final { scan-tree-dump { \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
.d?\\x00\\x00d?.\[1\]{lb: 1 sz: 4};} "original" } }
In other words, test for the "d" or not at one end, and "d" or not at the other
end.
And the next test would become
! { dg-final { scan-tree-dump " __builtin_memmove \(\(void \*\) &\(\*var.
str2\)\[2\]{lb: 1 sz: 4}, \(void \*\\) &.e?\\x00\\x00\\x00[ef]\\x00
\\x00f?.\[1\]{lb: 1 sz: 4}, 8\);" "original" } }
Or is a possible failure that the endian was flipped?
[Bug bootstrap/95970] gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970 --- Comment #4 from Ian Lance Taylor --- I'm having a hard time parsing the warning. It says gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null [-Wnonnull] The line is return type->do_type_descriptor(gogo, NULL); Is this trying to say that "type" may be NULL? That's true, it can be. This does look like a bug. There must be some reason that this code is never executed.
[Bug c++/95949] mame build succeeds with -O3 but fails with -O2 and all -O3 flags added manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95949 Julian Sikorski changed: What|Removed |Added Attachment #48803|0 |1 is obsolete|| --- Comment #8 from Julian Sikorski --- Created attachment 48807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48807=edit Preprocessed emumem.cpp source with precompiled header off Preprocessed source obtained with: make SOURCES=src/mame/drivers/model1.cpp REGENIE=1 NOWERROR=1 OPTIMIZE=2 PRECOMPILE=0 OPT_FLAGS="-save-temps" VERBOSE=1 -j12 Compressed because uncompressed file is 3.3 MB.
[Bug bootstrap/95970] gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970
--- Comment #3 from Martin Sebor ---
On second thought, I think the warning might be correct. The function it's
issued for is a static member of class Type (I at first thought it was
virtual):
Expression*
Type::type_descriptor(Gogo* gogo, Type* type)
{
return type->do_type_descriptor(gogo, NULL); <<< -Wnonnull
}
and the call to it is below:
Expression*
Named_type::do_type_descriptor(Gogo* gogo, Named_type* name)
{
if (this->is_error_)
return Expression::make_error(this->location_);
if (name == NULL && this->is_alias_)
{
if (this->seen_alias_)
return Expression::make_error(this->location_);
this->seen_alias_ = true;
Expression* ret = this->type_->type_descriptor(gogo, NULL); <<<
this->seen_alias_ = false;
return ret;
}
I'll leave it to Ian to confirm one way or the other.
[Bug c++/95977] New: No deallocation of temporary in return-statement during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95977
Bug ID: 95977
Summary: No deallocation of temporary in return-statement
during constant evaluation
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/iyRFxf.
```C++
struct X {
int* x{new int{42}};
X() = default;
constexpr X(const X& x) : x{new int{*x.x}} { }
constexpr ~X() { delete x; }
};
constexpr int f() { X x; return *X{x}.x; }
constexpr int z{f()};
```
```
:4:45: error: 'f()' is not a constant expression because allocated
storage has not been deallocated
4 | constexpr X(const X& x) : x{new int{*x.x}} { }
| ^
```
[Bug c++/95949] mame build succeeds with -O3 but fails with -O2 and all -O3 flags added manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95949 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #7 from Jonathan Wakely --- The preprocessed source is incomplete, it looks like the relevant declarations are probably in the preprocessed header ./../../../../mingw-gcc/obj/x64/Release/emu.h.gch Can you disable the use of the preprocessed header?
[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952 --- Comment #6 from Mikael Pettersson --- (In reply to Peter Bergner from comment #5) > (In reply to Peter Bergner from comment #4) > > I can help you build a default32 gcc if just adding -m32 to your > > compile doesn't ICE on the test case. > > I should mention, it's not as easy as just configuring with > --with-cpu=default32. You also need a binutils that has been built as a > 32-bit binary. This is an Apple G5 running a 64-bit linux-5.7 kernel and a mostly 32-bit user-space, hence the --with-cpu=default32 (which has been there since "forever").
[Bug c++/95949] mame build succeeds with -O3 but fails with -O2 and all -O3 flags added manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95949 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > Please provide preprocessed source for Eminem.cpp, compiled with -O2 Thanks for realising I meant emumem.cpp, despite my phone's autocorrect!
[Bug bootstrap/95970] gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970 --- Comment #2 from Martin Sebor --- I think the warning is a false positive. The problem call is introduced by early inlining and is eliminated by path isolation, but the -Wnonnull warning code runs before that happens (by the post_ipa_warn pass). Here's the relevant portion of the path isolation dump showing the removal: ;; Function Named_type::do_type_descriptor (_ZN10Named_type18do_type_descriptorE P4GogoPS_, funcdef_no=8125, decl_uid=214219, cgraph_uid=3913, symbol_order=4835) Pass statistics of "isolate-paths": ... Removing basic block 11 ;; basic block 11, loop depth 0 ;; pred: _20 = MEM[(int (*) () *)_19 + 96B]; _21 = OBJ_TYPE_REF(_20;(struct Type)0B->12) (0B, gogo_9(D), 0B); this_7(D)->seen_alias_ = 0; goto ; [100.00%] ;; succ: 10
[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952 --- Comment #5 from Peter Bergner --- (In reply to Peter Bergner from comment #4) > I can help you build a default32 gcc if just adding -m32 to your > compile doesn't ICE on the test case. I should mention, it's not as easy as just configuring with --with-cpu=default32. You also need a binutils that has been built as a 32-bit binary.
[Bug c++/95976] New: [[no_unique_address]] on union members has the opposite-of-intended effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95976
Bug ID: 95976
Summary: [[no_unique_address]] on union members has the
opposite-of-intended effect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: metaprogrammingtheworld at gmail dot com
Target Milestone: ---
When using [[no_unique_address]] with union members, ironically, each member is
now given a unique address! Without [[no_unique_address]], the layout is as one
would expect. This is particularly unfortunate since it means that a union's
size grows in proportion to the number of members when using
[[no_unique_address]]!
Example:
//
struct empty {};
union no_attribute_t
{
empty _0;
empty _1;
};
union with_attribute_t
{
[[no_unique_address]] empty _0;
[[no_unique_address]] empty _1;
};
constexpr no_attribute_t no_attribute{};
constexpr with_attribute_t with_attribute{};
// This succeeds
static_assert( _attribute._0 == _attribute._1 );
// This fails
static_assert( _attribute._0 == _attribute._1 );
//
[Bug bootstrap/95970] gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970 Martin Jambor changed: What|Removed |Added Last reconfirmed||2020-06-29 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ian at airs dot com --- Comment #1 from Martin Jambor --- I hit this today too (and it indeed prevents go bootstrap), so I guess it's confirmed. Ian, can you have a look whether the warning is correct? I glanced at the code only for a little while but it looks so to me.
[Bug c++/95975] New: -Wstrict-aliasing=1 false negative for std::pair member at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95975
Bug ID: 95975
Summary: -Wstrict-aliasing=1 false negative for std::pair
member at -O2
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v-thbutl at microsoft dot com
Target Milestone: ---
The code example below will result in a warning of type-punning for a cast from
a void* std::pair member reference to uintptr_t&. This only occurs at
optimization levels greater than -O1. This warning is not reported if x.first
is replaced with std::get<0>(x).
code example:
#include
#include
uintptr_t& foo(std::pair& x)
{
return (uintptr_t&)x.first;
}
compiler output:
$ g++ -O2 -Wstrict-aliasing=1 main.cc
main.cc: In function ‘uintptr_t& foo(std::pair&)’:
main.cc:6:24: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
6 | return (uintptr_t&)x.first;
| ~~^
[Bug target/95974] New: AArch64 arm_neon.h stores interfere with gimple optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95974
Bug ID: 95974
Summary: AArch64 arm_neon.h stores interfere with gimple
optimisations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Blocks: 95958
Target Milestone: ---
Target: aarch64*-*-*
For:
---
#include
#include
std::vector a;
void
f (size_t n, float32x4_t v)
{
for (size_t i = 0; i < n; i += 4)
vst1q_f32 ([i], v);
}
---
we generate code that loads the start address of
"a" in every iteration of the loop:
---
cbz x0, .L4
adrpx4, .LANCHOR0
add x4, x4, :lo12:.LANCHOR0
mov x1, 0
.p2align 3,,7
.L6:
ldr x3, [x4]
lsl x2, x1, 2
add x1, x1, 4
str q0, [x3, x2]
cmp x0, x1
bhi .L6
.L4:
ret
---
This is really the store equivalent of PR95962. The problem is
that __builtin_aarch64_st1v4sf is modelled as a general function
that could read and write from arbitrary memory. As with PR95962,
one option would be to lower to gimple accesses where possible,
at least for little-endian targets.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
[Bug 95958] [meta-bug] Inefficient arm_neon.h code for AArch64
[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #4 from Peter Bergner --- (In reply to Will Schmidt from comment #3) > Couldn't duplicate on P8/BE. I still have a couple builds going to see if I > can duplicate elsewhere. > > I see "--with-cpu=default32 " in the config string. Is this an older > hardware platform? --with-cpu=default32 is valid on any BE system, old or new. It just creates a compiler that defaults to -m32 rather than -m64. Ie, the compile above that is ICEing has an implicit -m32 added. I can help you build a default32 gcc if just adding -m32 to your compile doesn't ICE on the test case.
[Bug target/95973] New: Add __cpuidex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95973 Bug ID: 95973 Summary: Add __cpuidex Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com Target Milestone: --- Target: i386, x86-64 GCC has __cpuid_count(leaf,subleaf, a,b,c,d) MSVS has void __cpuidex( int cpuInfo[4], int function_id, int subfunction_id ); MSVS's interface is a little more sensible, passing & returning an array vs modifying 4 arguments in an un-C-language-like way. We should add __cpuidex.
[Bug c++/95972] New: ICE in check_member_template, at cp/decl2.c:570
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972
Bug ID: 95972
Summary: ICE in check_member_template, at cp/decl2.c:570
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.
$cat bug.cc
a() { [] ( struct { b ( auto
$g++ -w bug.cc
bug.cc:1:1: error: ISO C++ forbids declaration of ‘a’ with no type
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-fpermissive-fpermissive]8;;]
1 | a() { [] ( struct { b ( auto
| ^
bug.cc: In function ‘int a()’:
bug.cc:1:19: error: types may not be defined in parameter types
1 | a() { [] ( struct { b ( auto
| ^
bug.cc:2: error: expected ‘,’ or ‘...’ at end of input
bug.cc:1:29: error: expected ‘)’ at end of input
1 | a() { [] ( struct { b ( auto
| ~ ^
| )
bug.cc:1:21: error: ISO C++ forbids declaration of ‘b’ with no type
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-fpermissive-fpermissive]8;;]
1 | a() { [] ( struct { b ( auto
| ^
bug.cc:2: internal compiler error: in check_member_template, at cp/decl2.c:570
0x61d665 check_member_template(tree_node*)
../../gcc/cp/decl2.c:570
0x9d3490 finish_member_template_decl(tree_node*)
../../gcc/cp/pt.c:308
0x989fba finish_fully_implicit_template
../../gcc/cp/parser.c:44279
0x9cb99a cp_parser_member_declaration
../../gcc/cp/parser.c:25414
0x99f921 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24850
0x99f921 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23947
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9bf3ef cp_parser_parameter_declaration
../../gcc/cp/parser.c:22818
0x9bfdd2 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22641
0x9c01bc cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22568
0x9c0bae cp_parser_lambda_declarator_opt
../../gcc/cp/parser.c:11102
0x9a8836 cp_parser_lambda_expression
../../gcc/cp/parser.c:10633
0x9a8836 cp_parser_primary_expression
../../gcc/cp/parser.c:5443
0x9b2960 cp_parser_postfix_expression
../../gcc/cp/parser.c:7296
0x99564a cp_parser_binary_expression
../../gcc/cp/parser.c:9609
0x9971ae cp_parser_assignment_expression
../../gcc/cp/parser.c:9914
0x9974d2 cp_parser_expression
../../gcc/cp/parser.c:10082
0x99a368 cp_parser_expression_statement
../../gcc/cp/parser.c:11742
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #3 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> --- Created attachment 48806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48806=edit Makefile
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #1 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> --- Created attachment 48804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48804=edit a.cc
[Bug other/95971] [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971 --- Comment #2 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> --- Created attachment 48805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48805=edit b.cc
[Bug other/95971] New: [10 regression] Optimizer converts a false boolean value into a true boolean value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971
Bug ID: 95971
Summary: [10 regression] Optimizer converts a false boolean
value into a true boolean value
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: 0xe2.0x9a.0x9b at gmail dot com
Target Milestone: ---
Hello. I have found an optimization issue that is triggered by the -O2
optimization option in GCC 10.1.0.
The source code (see below) contains an infinite while(cond){} loop. The loop
condition is expected to always evaluate to true. The optimizer incorrectly
derives that the loop condition evaluates to false and removes the loop. It is
possible that the issue is related to optimizations of the delete operator in
C++.
Reproducibility:
g++ 10.1.0 -O0: not reproducible
g++ 10.1.0 -O1: not reproducible
g++ 10.1.0 -O2: REPRODUCIBLE
g++ 10.1.0 -O3: not reproducible
g++ 9.3.0 -O2: not reproducible
clang++ 10 -O2: not reproducible
Full source code:
$ cat a.cc
void xbool(bool value);
struct A {
char *a = (char*)1;
~A() { delete a; }
bool isZero() { return a == (void*)0; }
};
int main() {
A a;
xbool(a.isZero());
while(!a.isZero());
xbool(a.isZero()); // This line isn't required to trigger the issue
return 0;
}
$ cat b.cc
void xbool(bool value) {}
$ cat Makefile
test:
g++ -c -O2 a.cc
g++ -c b.cc
g++ -o a a.o b.o
time ./a
Dump of assembler code for function main:
push %rbp
xor%edi,%edi // %rdi := false
sub$0x10,%rsp
movq $0x1,0x8(%rsp)
callq xbool(bool)
mov$0x1,%edi // %rdi := true
callq xbool(bool)
lea0x8(%rsp),%rdi
callq A::~A()
add$0x10,%rsp
xor%eax,%eax
pop%rbp
retq
mov%rax,%rbp
jmpq main.cold
In the assembler code: The compiler correctly passes zero (false) in the 1st
call to function xbool(bool), then incorrectly passes one (true) in the 2nd
call to function xbool(bool).
The source code initializes A::a to (char*)1 in order to keep the code as small
as possible to trigger the issue. A::a could have been initialized to a valid
delete-able heap address, but this would unnecessarily enlarge the source code.
The GCC version string on my machine is "g++ (Gentoo 10.1.0-r1 p2) 10.1.0".
Please confirm the reproducibility of this issue.
[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952 --- Comment #3 from Will Schmidt --- Couldn't duplicate on P8/BE. I still have a couple builds going to see if I can duplicate elsewhere. I see "--with-cpu=default32 " in the config string. Is this an older hardware platform? thanks
[Bug c++/95949] mame build succeeds with -O3 but fails with -O2 and all -O3 flags added manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95949 --- Comment #5 from Julian Sikorski --- Created attachment 48803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48803=edit Preprocessed emumem.cpp source Preprocessed source obtained with: make SOURCES=src/mame/drivers/model1.cpp REGENIE=1 NOWERROR=1 OPTIMIZE=2 OPT_FLAGS="-save-temps" VERBOSE=1 -j12
[Bug bootstrap/95970] New: gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’ pointer null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970
Bug ID: 95970
Summary: gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’
pointer null
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Since r11-1697 Go bootstrap fails due to the following warning turned error:
In static member function ‘static Expression* Type::type_descriptor(Gogo*,
Type*)’,
inlined from ‘virtual Expression* Named_type::do_type_descriptor(Gogo*,
Named_type*)’ at /ssd/test/src/gcc/trunk/gcc/go/gofrontend/types.cc:4:53,
inlined from ‘virtual Expression* Named_type::do_type_descriptor(Gogo*,
Named_type*)’ at /ssd/test/src/gcc/trunk/gcc/go/gofrontend/types.cc:11105:1:
/ssd/test/src/gcc/trunk/gcc/go/gofrontend/types.cc:1474:34: warning: ‘this’
pointer null [-Wnonnull]
1474 | return type->do_type_descriptor(gogo, NULL);
The warning, issued from tree-ssa-ccp.c, is triggered by the use of the null
pointer as the first argument in the following call for the IL below.
_31 = OBJ_TYPE_REF(_30;(struct Type)0B->12) (0B, gogo_12(D), 0B);
Named_type::do_type_descriptor (struct Named_type * const this, struct Gogo *
gogo, struct Named_type * name)
{
struct Expression * D.404029;
struct Expression * ret;
bool _1;
bool _2;
bool _3;
struct Type * _4;
struct Expression * _5;
struct Named_type * iftmp.1259_6;
struct Expression * _14;
struct Expression * _17;
struct Expression * _19;
struct Expression * _20;
struct Named_type * iftmp.1259_21;
struct Named_type * iftmp.1259_22;
struct Expression * _24;
struct Expression * _25;
struct Expression * _27;
struct Expression * _28;
int (*) () * _29;
int (*) () _30;
struct Expression * _31;
:
_1 = this_9(D)->is_error_;
if (_1 != 0)
goto ; [INV]
else
goto ; [INV]
:
_27 = Expression::make_error (this_9(D)->location_);
_28 = _27;
goto ; [INV]
:
if (name_10(D) == 0B)
goto ; [INV]
else
goto ; [INV]
:
_2 = this_9(D)->is_alias_;
if (_2 != 0)
goto ; [INV]
else
goto ; [INV]
:
_3 = this_9(D)->seen_alias_;
if (_3 != 0)
goto ; [INV]
else
goto ; [INV]
:
_19 = Expression::make_error (this_9(D)->location_);
_20 = _19;
goto ; [INV]
:
this_9(D)->seen_alias_ = 1;
_29 = MEM[(struct Type *)0B]._vptr.Type;
_30 = MEM[(int (*) () *)_29 + 96B];
_31 = OBJ_TYPE_REF(_30;(struct Type)0B->12) (0B, gogo_12(D), 0B);
_33 = _31;
_14 = _33;
ret_15 = _14;
this_9(D)->seen_alias_ = 0;
_17 = ret_15;
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
[Bug fortran/95880] [9 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9 Regression] ICE in |gfc_add_type, at|gfc_add_type, at |fortran/symbol.c:2030 since |fortran/symbol.c:2030 since |r11-524-geb069ae8819c3a84 |r11-524-geb069ae8819c3a84 --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on master and 10-branch.
[Bug target/95969] New: Use of __builtin_aarch64_im_lane_boundsi in AArch64 arm_neon.h interferes with gimple optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95969
Bug ID: 95969
Summary: Use of __builtin_aarch64_im_lane_boundsi in AArch64
arm_neon.h interferes with gimple optimisation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Blocks: 95958
Target Milestone: ---
Target: aarch64*-*-*
For:
#include
void
f (float32x4_t **ptr)
{
float32x4_t res = vsetq_lane_f32 (0.0f, **ptr, 0);
**ptr = res;
}
the final gimple .optimized dump looks like:
float32x4_t __vec;
float32x4_t * _1;
__Float32x4_t _2;
float32x4_t * _3;
[local count: 1073741824]:
_1 = *ptr_5(D);
_2 = *_1;
__builtin_aarch64_im_lane_boundsi (16, 4, 0);
__vec_8 = BIT_INSERT_EXPR <_2, 0.0, 0>;
_3 = *ptr_5(D);
*_3 = __vec_8;
return;
where we still have two loads from *ptr. This is because
__builtin_aarch64_im_lane_boundsi has no attributes:
it's modelled a general function that could do pretty
much anything.
Although we fix this testcase in the RTL optimisers, it's easy
for the issue to cause unoptimised code in larger, more realistic
testcases.
The problem is similar to PR95964. The difficulty is that
here we have to model the function as having some kind of
side-effect, otherwise it will simply get optimised away.
Ideally we'd fix this by implementing the intrinsics directly
in the compiler and doing the checks in the frontend via
TARGET_CHECK_BUILTIN_CALL. That's obviously a big change
though. Until then, we should optimise away calls whose
arguments are already correct so that they don't clog
up the IL.
If not returning a value makes it harder to fold the call
for some reason, perhaps an alternative would be to pass
a vector value through a dummy const function, e.g.:
_4 = __builtin_aarch64_... (_2, 16, 4, 0);
__vec_8 = BIT_INSERT_EXPR <_4, 0.0, 0>;
That might not be necessary though -- haven't checked.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
[Bug 95958] [meta-bug] Inefficient arm_neon.h code for AArch64
[Bug fortran/95340] [10/11 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95340 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on 10-branch. Thanks for the report!
[Bug fortran/95340] [10/11 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95340 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:687147abdfccc1b53adc9a2d31e419719f3deaab commit r10-8390-g687147abdfccc1b53adc9a2d31e419719f3deaab Author: Harald Anlauf Date: Sun Jun 28 16:24:15 2020 +0200 PR fortran/95340 - ICE in gfc_match_select_rank, at fortran/match.c:6690 Do not dereference NULL pointer when querying array shape of possibly improperly delared variable. gcc/fortran/ PR fortran/95340 * match.c (gfc_match_select_rank): Do not dereference NULL pointer. (cherry picked from commit b62cac6d92ff251213753475b69ec0b269cb7fae)
[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e3942f91376ba29a8014fd19f7719c5697ac05e8 commit r10-8389-ge3942f91376ba29a8014fd19f7719c5697ac05e8 Author: Harald Anlauf Date: Sun Jun 28 13:52:09 2020 +0200 PR fortran/95880 - ICE in gfc_add_type, at fortran/symbol.c:2030 The fix for PR39695 did not properly distinguish between procedure names and other symbols names in errors emitted for invalid code. Fix that. gcc/fortran/ PR fortran/95880 * symbol.c (gfc_add_type): If sym->ns->proc_name is set, use it, otherwise fall back to sym->name. (cherry picked from commit f3a8f66a83f8c94f6fbb0233cefba8032f2e4876)
[Bug c++/95968] New: error: 'args#0' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95968
Bug ID: 95968
Summary: error: 'args#0' is not a constant expression
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zakeria433 at gmail dot com
Target Milestone: ---
Hi,
command: g++ test_class.cpp -Wall -Wextra -std=c++20
System: Debian 10
The following code is rejected by Gcc 10.1. However, if I replace test_class's
constructor with constexpr instead of consteval, it does compile on gcc.
// Example program
#include
#include
// #include
template
requires(std::is_floating_point::value)
class test_class
{
public:
const T first_param;
const std::tuple pack;
consteval test_class(T first_param_, Pack... pack_) :
first_param(first_param_),
pack(pack_...)
{
}
consteval auto test_func()
{
//auto p = first_param;
auto x = std::apply([/*p*/](const auto ... args) {return
test_class(1.0, args...);}, pack);
return x;
}
};
int main()
{
constexpr auto var1 = test_class(4.0);
//constexpr auto var2 = test_class(5.0);
constexpr auto var3 = test_class(12.0, var1).test_func();
//static_assert(vart3.first_param == 12, "assert fail");
}
error: ‘args#0’ is not a constant expression
22 | auto x = std::apply([/*p*/](const auto ... args) {return
test_class(1.0, args...);}, pack);
|
^~~~
Live demo:
https://godbolt.org/z/oWWFaP
[Bug target/95967] Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967 --- Comment #1 from rsandifo at gcc dot gnu.org --- Created attachment 48802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48802=edit 6 constructor functions This time with attachment -- not sure what happened last time.
[Bug target/95967] New: Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967
Bug ID: 95967
Summary: Poor aarch64 vector constructor code when using
arm_neon.h
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Depends on: 95962
Blocks: 95958
Target Milestone: ---
Target: aarch64*-*-*
We generate poor code for the attached functions:
f1:
moviv4.4s, 0
ins v4.s[0], v0.s[0]
ins v4.s[1], v1.s[0]
ins v4.s[2], v2.s[0]
mov v0.16b, v4.16b
ins v0.s[3], v3.s[0]
ret
f2:
dup v0.4s, v0.s[0]
ins v0.s[1], v1.s[0]
ins v0.s[2], v2.s[0]
ins v0.s[3], v3.s[0]
ret
f3:
sub sp, sp, #16
stp s0, s1, [sp]
stp s2, s3, [sp, 8]
ldr q0, [sp]
add sp, sp, 16
ret
g1:
moviv0.4s, 0
ld1 {v0.s}[0], [x0]
ld1 {v0.s}[1], [x1]
ld1 {v0.s}[2], [x2]
ld1 {v0.s}[3], [x3]
ret
g2:
ld1r{v0.4s}, [x0]
ld1 {v0.s}[1], [x1]
ld1 {v0.s}[2], [x2]
ld1 {v0.s}[3], [x3]
ret
g3:
sub sp, sp, #16
ldr s0, [x3]
ldr s3, [x0]
ldr s2, [x1]
ldr s1, [x2]
stp s3, s2, [sp]
stp s1, s0, [sp, 8]
ldr q0, [sp]
add sp, sp, 16
ret
All three f functions should generate:
mov v0.s[1], v1.s[0]
mov v0.s[2], v2.s[0]
mov v0.s[3], v3.s[0]
ret
and all three g functions should generate:
ldr s0, [x0]
ld1 { v0.s }[1], [x1]
ld1 { v0.s }[2], [x2]
ld1 { v0.s }[3], [x3]
ret
which is what current Clang does.
Getting the right code for f3 and g3 depends on the fix for PR95962.
There's a reasonable chance that PR95962 will be enough on its own
to fix f3 and g3, but I included them just in case it isn't.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
[Bug 95958] [meta-bug] Inefficient arm_neon.h code for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
[Bug 95962] Inefficient code for simple arm_neon.h iota operation
[Bug c++/95568] No CTAD with list initialization within templated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95568 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Marek Polacek --- Fixed.
[Bug bootstrap/95965] [11 regression] bootstrap failure on sparc due to "register"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95965 Mikael Pettersson changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Mikael Pettersson --- Yes, fixed by ceac3edb42e1090be8cee895a5659fe847a4050a.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 94553, which changed state. Bug 94553 Summary: Revise [basic.scope.declarative]/4.2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/94553] Revise [basic.scope.declarative]/4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c++/94553] Revise [basic.scope.declarative]/4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553 --- Comment #7 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:54980635c537f3130481da2d8b1109c775db8bb0 commit r11-1714-g54980635c537f3130481da2d8b1109c775db8bb0 Author: Marek Polacek Date: Fri Jun 26 12:40:59 2020 -0400 c++: Check uniqueness of concepts/variable templates [PR94553] This patch wraps up PR94553. Variable template names have no C compatibility implications so they should be unique in their declarative region. It occurred to me that this applies to concepts as well. This is not specified in [basic.scope.declarative]/4.2 but that seems like a bug in the standard. I couldn't use variable_template_p because that uses PRIMARY_TEMPLATE_P which uses DECL_PRIMARY_TEMPLATE and that might not have been set up yet (push_template_decl hasn't yet been called). PRIMARY_TEMPLATE_P is important to distinguish between a variable template and a variable in a function template. But I think we don't have to worry about that in duplicate_decls: a template declaration cannot appear at block scope, and additional checks in duplicate_decls suggest that it won't ever see a TEMPLATE_DECL for a variable in a function template. So checking that the DECL_TEMPLATE_RESULT is a VAR_DECL seems to be fine. I could have added a default argument to variable_template_p too to avoid checking PRIMARY_TEMPLATE_P but it didn't seem worth the effort. gcc/cp/ChangeLog: PR c++/94553 * decl.c (duplicate_decls): Make sure a concept or a variable template is unique in its declarative region. gcc/testsuite/ChangeLog: PR c++/94553 * g++.dg/cpp1y/pr68578.C: Adjust dg-error. * g++.dg/cpp1y/var-templ66.C: New test. * g++.dg/cpp2a/concepts-redecl1.C: New test.
[Bug tree-optimization/95966] New: soft float operations are not tail called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95966
Bug ID: 95966
Summary: soft float operations are not tail called
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i'd expect this to be a tail call into the soft float add
operation on soft float targets:
fp_t foo(fp_t a, fp_t b)
{
return a + b;
}
e.g. on x86 with 'typedef __float128 fp_t' the generated code is
foo:
sub rsp, 8
call__addtf3
add rsp, 8
ret
on aarch64 with 'typedef long double fp_t' the generated code is
foo:
stp x29, x30, [sp, -16]!
mov x29, sp
bl __addtf3
ldp x29, x30, [sp], 16
ret
i see similar code on other softfp targets.
[Bug c++/95568] No CTAD with list initialization within templated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95568 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:b1005f553d3543bb56dc6b9b34ee35455d697ca4 commit r11-1713-gb1005f553d3543bb56dc6b9b34ee35455d697ca4 Author: Marek Polacek Date: Tue Jun 23 18:07:34 2020 -0400 c++: Fix CTAD for aggregates in template [PR95568] 95568 complains that CTAD for aggregates doesn't work within requires-clause and it turned out that it doesn't work when we try the deduction in a template. The reason is that maybe_aggr_guide creates a guide that can look like this template X(decltype (X::x))-> X where the parameter is a decltype, which is a non-deduced context. So the subsequent build_new_function_call fails because unify_one_argument can't deduce anything from it ([temp.deduct.type]: "If a template parameter is used only in non-deduced contexts and is not explicitly specified, template argument deduction fails.") Those decltypes come from finish_decltype_type. We can just use TREE_TYPE instead. I pondered using unlowered_expr_type, but that didn't make any difference for the FIELD_DECLs I saw in class-deduction-aggr6.C. gcc/cp/ChangeLog: PR c++/95568 * pt.c (collect_ctor_idx_types): Use TREE_TYPE. gcc/testsuite/ChangeLog: PR c++/95568 * g++.dg/cpp2a/class-deduction-aggr5.C: New test. * g++.dg/cpp2a/class-deduction-aggr6.C: New test.
[Bug target/95964] AArch64 arm_neon.h arithmetic functions lack appropriate attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964 --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > You could use fnspec attributes to improve things but of course open-coding > those as GIMPLE is preferable (last resort is to "fold" the calls to > GIMPLE sequences as powerpc does for select builtins). Yeah, open-coding is another option, if the operation and command-line options are right. Part of the problem though is that the intrinsics are supposed to behave like the associated instructions, including in terms of honouring the rounding mode, etc. They're also not supposed to inherit C's idea of what's undefined behaviour for the closest “equivalent” operators or libm functions. So yeah, I think adding attributes is the way to go in general.
[Bug bootstrap/95940] [11 Regression] sparc64-linux bootstrap with gcc-9.3 broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940 Martin Sebor changed: What|Removed |Added Last reconfirmed||2020-06-29 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Martin Sebor --- Can you provide a test case or a translation unit?
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #24 from Anthony --- (In reply to rguent...@suse.de from comment #23) > On Sun, 28 Jun 2020, prop_design at protonmail dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 > > > > --- Comment #22 from Anthony --- > > (In reply to Thomas Koenig from comment #21) > > > Another question: Is there anything left to be done with the > > > vectorizer, or could we remove that dependency? > > > > thanks for looking into this again for me. i'm surprised it worked the same > > on > > Linux, but knowing that, at least helps debug this issue some more. I'm not > > sure about the vectorizer question, maybe that question was intended for > > someone else. the runtimes seem good as is though. i doubt the > > auto-parallelization will add much speed. but it's an interesting feature > > that > > i've always hoped would work. i've never got it to work though. the only > > code > > that did actually implement something was Intel Fortran. it implemented one > > trivial loop, but it slowed the code down instead of speeding it up. the > > output > > from gfortran shows more loops it wants to run in parallel. they aren't > > important ones. but something would be better than nothing. if it slowed the > > code down, i would just not use it. > > GCC adds runtime checks for a minimal number of iterations before > dispatching to the parallelized code - I guess we simply never hit > the threshold. This is configurable via --param parloops-min-per-thread, > the default is 100, the default number of threads is determined the same > as for OpenMP so you can probably tune that via OMP_NUM_THREADS. thanks for that tip. i tried changing the parloops parameters but no luck. the only difference was the max thread use went from 2 to 3. core use was the same. i added the following an some variations of these: --param parloops-min-per-thread=2 (the default was 100 like you said) --param parloops-chunk-size=1 (the default was zero so i removed this parameter later) --param parloops-schedule=auto (tried all options except guided, the default is static) i was able to check that they were set via: --help=param -Q some other things i tried was adding -mthreads and removing -static. but so far no luck. i also tried using -mthreads instead of -pthread. i should make clear i'm testing PROP_DESIGN_MAPS, not MP_PROP_DESIGN. MP_PROP_DESIGN is ancient and the added benchmarking loops were messing with the ability of the optimizer to auto-parallelize (in the past at least).
