[Bug tree-optimization/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734 --- Comment #10 from Marc Glisse --- (In reply to Eric Gallager from comment #9) > (In reply to Marc Glisse from comment #8) > > (In reply to Eric Gallager from comment #7) > > > 5 branch is closed > > > > You closed the PR, so does that mean you checked and it is fixed at least on > > trunk? > > I thought that if it were still an issue on trunk, the title would have said > [6/7/8 regression] instead of [5.0 regression]. I don't think that's a completely reliable indicator, in the absence of any other information in the PR. I don't know if the title update is automatic when a new branch is created, maybe it is but didn't happen here because it says "5.0 Regression" instead of "5 Regression"... Anyway, I just looked at https://gcc.gnu.org/ml/gcc-testresults/2018-03/msg01741.html and don't see any "vshuf" failure, it seems to have disappeared (probably just went latent), so everything is fine.
[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid, wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-24
Known to work||6.4.0
Summary|Object cannot call its |[7/8 Regression] Object
|inherited member function |cannot call its inherited
|"without object"|member function "without
||object"
Ever confirmed|0 |1
Known to fail||7.3.0
--- Comment #1 from Jonathan Wakely ---
Confirmed:
struct CA {
int foo() { return 42; }
};
template
struct CB : CA { };
template
struct CC : CB {
int bar() {
const int m = CA::foo();
return m;
}
int baz() {
const T m = CA::foo();
return m;
}
};
int main() {
CC c;
__builtin_printf("%d %d\n", c.bar(), c.baz());
}
This fails to compile with gcc-7:
85060.cc: In member function 'int CC::bar()':
85060.cc:11:26: error: cannot call member function 'int CA::foo()' without
object
const int m = CA::foo();
~~~^~
It compiles with gcc-8 but warns about an uninitialized variable, and prints
garbage:
1078263808 42
So rejects-valid with gcc-7-branch and wrong-code with trunk.
[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org Known to fail||8.0.1 --- Comment #2 from Jonathan Wakely --- It started to be rejected with r236221 Fix type-dependence and the current instantiation. PR c++/10200 PR c++/69753 * pt.c (tsubst_decl): Use uses_template_parms. (instantiate_template_1): Handle non-dependent calls in templates. (value_dependent_expression_p): Handle BASELINK, FUNCTION_DECL. (type_dependent_expression_p): Only consider innermost template args. (dependent_template_arg_p): Check enclosing class of a template here. (dependent_template_p): Not here. (type_dependent_object_expression_p): New. * typeck.c (finish_class_member_access_expr): Use it. * parser.c (cp_parser_postfix_expression): Use it. (cp_parser_postfix_dot_deref_expression): Use it. Use comptypes to detect the current instantiation. (cp_parser_lookup_name): Really implement DR 141. * search.c (lookup_field_r): Prefer a dependent using-declaration. (any_dependent_bases_p): Split out from... * name-lookup.c (do_class_using_decl): ...here. * call.c (build_new_method_call_1): Use it. * semantics.c (finish_call_expr): 'this' doesn't make a call dependent. * tree.c (non_static_member_function_p): Remove. * typeck2.c (build_x_arrow): Use dependent_scope_p. Then was accepted again with r258116: PR c++/84582 * semantics.c (force_paren_expr): Create a PAREN_EXPR when in a template. (maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR. * typeck2.c (store_init_value): Call fold_non_dependent_expr instead of instantiate_non_dependent_expr. * tree.c (lvalue_kind): Handle PAREN_EXPR like NON_DEPENDENT_EXPR. * g++.dg/cpp1y/auto-fn15.C: Extend testing. * g++.dg/cpp1z/static1.C: New test. * g++.dg/template/static37.C: New test.
[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060
--- Comment #3 from Jonathan Wakely ---
Or using constexpr, so no linking required to check the value:
struct CA {
constexpr int foo() const { return 42; }
};
template
struct CB : CA { };
template
struct CC : CB {
constexpr int bar() const {
const int m = CA::foo();
return m;
}
constexpr int baz() const {
const T m = CA::foo();
return m;
}
};
constexpr CC c;
static_assert( c.bar() == 42, "" );
gcc-7-branch:
85060-2.cc: In member function 'constexpr int CC::bar() const':
85060-2.cc:11:26: error: cannot call member function 'constexpr int CA::foo()
const' without object
const int m = CA::foo();
~~~^~
85060-2.cc: At global scope:
85060-2.cc:23:1: error: non-constant condition for static assertion
static_assert( c.bar() == 42, "" );
^
trunk:
85060-2.cc:23:24: error: non-constant condition for static assertion
static_assert( c.bar() == 42, "" );
^
[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #3 from Bruno Haible --- (In reply to Jakub Jelinek from comment #2) > You need to read the documentation, which would tell you you need to use > -fmain=HelloWorld option. It is true that -fmain=HelloWorld was missing in the reporter's command line. But if that had been the only problem, the error message would have been (.text+0x18): undefined reference to `main' not Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain The error message "java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain" means that the ecj1 program cannot find the org.eclipse.jdt.internal.compiler.batch.GCCMain class, which it expects to find in the jar file specified through the --with-ecj-jar option. So, the reporter's real problem was that he configured GCC with a --with-ecj-jar option without argument.
[Bug lto/85047] cdd2a01 (and others) FAIL with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85047 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Created attachment 43747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43747&action=edit Reduced testcase To be compiled with "gnatmake lto23 -flto".
[Bug lto/85047] cdd2a01 (and others) FAIL with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85047 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
--- Comment #4 from Bruno Haible ---
I am having the same error, even with option -C (which does not need a
-fmain=... option):
$ gcj -v -C HelloWorld.java
Using built-in specs.
COLLECT_GCC=/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/gcj
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7.3/configure --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--prefix=/arch/x86-linux/gnu-inst-gcc/4.7.3 --enable-shared
--enable-version-specific-runtime-libs --enable-nls --enable-threads=posix
--enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32
--with-gmp=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-mpc=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-libelf=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-ecj-jar=/gfs/petix/Volumes/ExtData/source/gnu/gcc/sourceware.org-ecj/ecj-latest.jar
Thread model: posix
gcc version 4.7.3 (GCC)
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-B'
'/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/libexec/gcc/i686-pc-linux-gnu/4.7.3'
'-v' '-C'
'-fbootclasspath=./:/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/../lib/gcc/../../share/java/libgcj-4.7.3.jar'
'-g1' '-fsyntax-only' '-femit-class-files' '-S' '-o' 'NONE' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/libexec/gcc/i686-pc-linux-gnu/4.7.3/ecj1
HelloWorld.java -g1
-fbootclasspath=./:/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/../lib/gcc/../../share/java/libgcj-4.7.3.jar
-g1 -fsource=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccrzqP4M.zip
Exception in thread "main" java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(MainThread.java:100)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(URLClassLoader.java)
at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:27)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
at gnu.java.lang.MainThread.run(MainThread.java)
The problem is that the file that I specified as --with-ecj-jar value when
configuring GCC no longer exists. The GCC installation has not copied the file
to the GCC installation directory! But the ecj1 program still references it.
I cannot find an option to tell ecj1 about the new file name of ecj-latest.jar.
So I ended up creating a symlink so that the old file name still works.
[Bug c++/85061] New: ICE with __builtin_offsetof applied to static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85061
Bug ID: 85061
Summary: ICE with __builtin_offsetof applied to static member
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 4.0.0
(when __builtin_offsetof was introduced):
=
struct A
{
static int x[2];
};
int i = __builtin_offsetof(volatile A, x[0]);
=
bug.cc:6:44: internal compiler error: in fold_offsetof_1, at
c-family/c-common.c:6275
int i = __builtin_offsetof(volatile A, x[0]);
^
0x67d2bf fold_offsetof_1(tree_node*, tree_code)
../../gcc/gcc/c-family/c-common.c:6275
0xa2d34a fold_offsetof(tree_node*)
../../gcc/gcc/c-family/c-common.c:6290
0x925d4d cp_parser_builtin_offsetof
../../gcc/gcc/cp/parser.c:9899
0x925d4d cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5398
0x937c0c cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7032
0x9387e0 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8324
0x9186df cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9092
0x918eea cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9193
0x91a724 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9488
0x91987b cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:9772
0x91a6a7 cp_parser_initializer_clause
../../gcc/gcc/cp/parser.c:21929
0x91cf62 cp_parser_initializer
../../gcc/gcc/cp/parser.c:21869
0x93c3ae cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19684
0x943758 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13059
0x944568 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12884
0x9484c2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12782
0x9488d1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12658
0x948bc4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x948bc4 c_parse_file()
../../gcc/gcc/cp/parser.c:39024
0xa480d6 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]
[Bug tree-optimization/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734 Andreas Schwab changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #11 from Andreas Schwab --- Fixed somewhere between r221132 and r221170.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #11 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Sat Mar 24 10:52:34 2018 New Revision: 258833 URL: https://gcc.gnu.org/viewcvs?rev=258833&root=gcc&view=rev Log: Use SCEV information when aligning for vectorisation (PR 84005) This PR is another regression caused by the removal of the simple_iv check in dr_analyze_innermost for BB analysis. Without splitting out the step, we weren't able to find an underlying object whose alignment could be increased. As with PR81635, I think the simple_iv was only handling one special case of something that ought to be more general. The more general thing here is that if the address can be analysed as a scalar evolution, and if all updates preserve alignment N, it's possible to align the address to N by increasing the alignment of the base object to N. That applies also to outer loops, and to both loop and BB analysis. I wasn't sure where the new functions ought to live, but tree-data-ref.c seemed OK since (a) that already does scev analysis on addresses and (b) you'd want to use dr_analyze_innermost first if you were analysing a reference. 2018-03-24 Richard Sandiford gcc/ PR tree-optimization/84005 * tree-data-ref.h (get_base_for_alignment): Declare. * tree-data-ref.c (get_base_for_alignment_1): New function. (get_base_for_alignment): Likewise. * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Use get_base_for_alignment to find a suitable base object, instead of always using drb->base_address. gcc/testsuite/ PR tree-optimization/84005 * gcc.dg/vect/bb-slp-1.c: Make sure there is no message about failing to force the alignment. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/bb-slp-1.c trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/85062] New: [6/7/8 Regression] ICE on alignas with parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85062
Bug ID: 85062
Summary: [6/7/8 Regression] ICE on alignas with parameter pack
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following valid code snippet triggers an ICE since GCC 5.2.0:
template struct A
{
int alignas(T...) i;
};
A a;
bug.cc:3:7: internal compiler error: tree check: expected tree that contains
'common' structure, have 'expr_pack_expansion' in list_length, at tree.c:2973
int alignas(T...) i;
^~~
0x78cd61 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9494
0x78d0ca contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3505
0x78d0ca list_length(tree_node const*)
../../gcc/gcc/tree.c:2973
0x9fc35a decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/gcc/attribs.c:573
0x8a4c25 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:10951
0x8b5db8 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:829
0x92d9e2 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:23918
0x92ea8a cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:23397
0x92ea8a cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22529
0x930b89 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22791
0x930b89 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16776
0x93dec6 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13627
0x942635 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27213
0x9429bc cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26905
0x94327c cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:27142
0x94327c cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:27161
0x9485e9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12731
0x9488d1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12658
0x948bc4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x948bc4 c_parse_file()
../../gcc/gcc/cp/parser.c:39024
Please submit a full bug report, [etc.]
In case of a non-variadic template the code is accepted with a warning
(which is why IMHO the code above should be accepted, too):
bug.cc:3:7: warning: attribute ignored [-Wattributes]
int alignas(T) i;
^~~
bug.cc:3:7: note: an attribute that appertains to a type-specifier is ignored
[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |7.4
[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060 --- Comment #4 from Jakub Jelinek --- In *.original dump we have in bar: const int m = <<< error >>>; (but no error was reported).
[Bug rtl-optimization/85059] Compiling with -Og should preserve variable values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85059 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup, this has been already discussed, just not implemented (yet). *** This bug has been marked as a duplicate of bug 78685 ***
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Bug 82738 depends on bug 85059, which changed state. Bug 85059 Summary: Compiling with -Og should preserve variable values https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85059 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 Jakub Jelinek changed: What|Removed |Added CC||fredrik at dolda2000 dot com --- Comment #7 from Jakub Jelinek --- *** Bug 85059 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/85063] New: Switch conversion in openacc routine introduces unsupported construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85063
Bug ID: 85063
Summary: Switch conversion in openacc routine introduces
unsupported construct
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this test-case (filed earlier at lto PR84592):
...
/* { dg-additional-options "-ftree-switch-conversion" } */
#include
#pragma acc routine seq
static int __attribute__((noinline)) foo (int n)
{
switch (n & 3)
{
case 0: return 4;
case 1: return 3;
case 2: return 2;
default:
return 1;
}
}
int
main (void)
{
int n[1];
n[0] = 4;
#pragma acc parallel copy(n)
{
n[0] = foo (n[0]);
}
printf ("n: %d\n", n[0]);
return 0;
}
...
When compiling this at -O2, we run into an ICE in lto1.
Switch conversion triggers for this example, which introduces a function static
var, and the ICE happens when processing the function static var (which is what
PR84592 is about).
However, OpenACC forbids function static vars in routines. So, switch
conversion shouldn't run on OpenACC routines.
[Bug target/85058] Builtin-functions for -mbmi2 documented with wrong names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85058 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- We should not document the __builtin_ia32_* builtins that we aren't supporting, which is the wast majority of them. We only support the *intrin.h intrinsic wrappers.
[Bug tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85063 --- Comment #1 from Tom de Vries --- Created attachment 43748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43748&action=edit Tentative patch Currently doing: - bootstrap & reg-test on x86_64, and - build and libgomp reg-test on x86_64 with nvptx accelerator.
[Bug tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85063 --- Comment #2 from Tom de Vries --- Created attachment 43749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43749&action=edit Updated tentative patch
[Bug fortran/70068] ICE: out of memory on involving empty substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug c++/85061] ICE with __builtin_offsetof applied to static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85061 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-24 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- --- gcc/c-family/c-common.c.jj 2018-03-13 00:38:23.809662252 +0100 +++ gcc/c-family/c-common.c 2018-03-24 15:21:36.171485128 +0100 @@ -6272,7 +6272,7 @@ fold_offsetof_1 (tree expr, enum tree_co case COMPOUND_EXPR: /* Handle static members of volatile structs. */ t = TREE_OPERAND (expr, 1); - gcc_assert (VAR_P (t)); + gcc_checking_assert (VAR_P (get_base_address (t))); return fold_offsetof_1 (t); default: seems to fix this.
[Bug tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85063 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So just make it a file scope static var instead, instead of disabling the optimization? Aren't there many other cases where static vars can be introduced, e.g. in the gimplifier when gimplifying initializers, compound literals, ...? What about switch inside of OpenACC constructs? Is there any reason why function static vars can't be supported, besides that the standard says they aren't allowed? The diagnostics should be done in the FE anyway, or could be guarded with !DECL_ARTIFICIAL etc.
[Bug tree-optimization/84969] [8 Regression] Wrong code with -ftree-loop-distribute-patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84969 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So fixed?
[Bug target/85044] ENDBR is missing in ix86_trampoline_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85044 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-24 Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- I am testing: https://github.com/hjl-tools/gcc/commit/04471b37fa58ec317d6467b6c9516339c0f9beba
[Bug fortran/42651] Functions with result: Wrongly accepts attributes to function name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42651 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Mar 24 16:31:57 2018 New Revision: 258834 URL: https://gcc.gnu.org/viewcvs?rev=258834&root=gcc&view=rev Log: 2018-03-24 Steven G. Kargl PR fortran/42651 * decl.c (check_function_name): Improved error message (gfc_match_volatile, gfc_match_asynchronous) Use check_function_name. 2018-03-24 Steven G. Kargl PR fortran/42651 * gfortran.dg/pr42651.f90: New test. * gfortran.dg/func_result_7.f90: Update error message. Added: trunk/gcc/testsuite/gfortran.dg/pr42651.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/func_result_7.f90
[Bug c++/85064] New: [concepts] ICE with auto as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85064
Bug ID: 85064
Summary: [concepts] ICE with auto as template parameter
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Blocks: 67491
Target Milestone: ---
The following invalid code snippet (compiled with "-fconcepts")
triggers an ICE since GCC 6.1.0:
==
template void foo(T);
void bar()
{
foo<0, auto>(0);
}
==
bug.cc: In substitution of 'template, class T> void foo(T)
[with int = 0; T = auto]':
bug.cc:5:17: required from here
bug.cc:5:17: internal compiler error: in unify, at cp/pt.c:21109
foo<0, auto>(0);
^
0x63d13d unify
../../gcc/gcc/cp/pt.c:21109
0x986953 unify_one_argument
../../gcc/gcc/cp/pt.c:19700
0x98a3c3 type_unification_real
../../gcc/gcc/cp/pt.c:19820
0x98cab5 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:19205
0x82b68f add_template_candidate_real
../../gcc/gcc/cp/call.c:3179
0x82c0a0 add_template_candidate
../../gcc/gcc/cp/call.c:3258
0x82c0a0 add_candidates
../../gcc/gcc/cp/call.c:5514
0x82c4c1 add_candidates
../../gcc/gcc/cp/call.c:4186
0x82c4c1 perform_overload_resolution
../../gcc/gcc/cp/call.c:4194
0x82e542 build_new_function_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4267
0x9ac685 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2534
0x937fca cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7245
0x9387e0 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8324
0x9186df cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9092
0x918eea cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9193
0x91a724 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9488
0x91ae38 cp_parser_expression
../../gcc/gcc/cp/parser.c:9657
0x91cb18 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11133
0x922f0d cp_parser_statement
../../gcc/gcc/cp/parser.c:10937
0x924470 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11276
Please submit a full bug report, [etc.]
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug c++/85065] New: [concepts] ICE with invalid use of a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065 Bug ID: 85065 Summary: [concepts] ICE with invalid use of a concept Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Blocks: 67491 Target Milestone: --- The following invalid code snippet (compiled with "-fconcepts") triggers an ICE since GCC 6.2.0: template concept bool C = true; C c = 0; bug.cc:3:1: error: invalid reference to concept 'C' C c = 0; ^ bug.cc:3:7: internal compiler error: in placeholder_extract_concept_and_args, at cp/constraint.cc:1467 C c = 0; ^ 0x5e9488 placeholder_extract_concept_and_args(tree_node*, tree_node*&, tree_node*&) ../../gcc/gcc/cp/constraint.cc:1467 0x8651f1 hash_placeholder_constraint(tree_node*) ../../gcc/gcc/cp/constraint.cc:1522 0x95625f auto_hash::hash(tree_node*) ../../gcc/gcc/cp/pt.c:25615 0x95625f hash_table::find_slot(tree_node* const&, insert_option) ../../gcc/gcc/hash-table.h:414 0x95625f extract_autos_r ../../gcc/gcc/cp/pt.c:25649 0x956a41 for_each_template_parm_r ../../gcc/gcc/cp/pt.c:9579 0x11645eb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/gcc/tree.c:11387 0x9567b1 for_each_template_parm ../../gcc/gcc/cp/pt.c:9677 0x967982 extract_autos ../../gcc/gcc/cp/pt.c:25677 0x967982 do_auto_deduction(tree_node*, tree_node*, tree_node*, int, auto_deduction_context, tree_node*, int) ../../gcc/gcc/cp/pt.c:26316 0x89ef73 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc/gcc/cp/decl.c:6911 0x93c2eb cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:19741 0x943758 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:13059 0x944568 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:12884 0x9484c2 cp_parser_declaration ../../gcc/gcc/cp/parser.c:12782 0x9488d1 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:12658 0x948bc4 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4563 0x948bc4 c_parse_file() ../../gcc/gcc/cp/parser.c:39024 0xa480d6 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1132 Please submit a full bug report, [etc.] Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug fortran/42651] Functions with result: Wrongly accepts attributes to function name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42651 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/85066] New: FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c scan-tree-dump vect "vectorized 1 loops"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85066 Bug ID: 85066 Summary: FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c scan-tree-dump vect "vectorized 1 loops" Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: rguenther at suse dot de Target Milestone: --- Target: x86-64 Executing on host: /export/build/gnu/gcc-x32-thunk/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32-thunk/build-x86_64-linux/gcc/ /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c -mx32-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize -fvect-cost-model=dynamic -msse2 -fdump-tree-vect-details -S -o costmodel-pr84986.s(timeout = 300) spawn -ignore SIGHUP /export/build/gnu/gcc-x32-thunk/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32-thunk/build-x86_64-linux/gcc/ /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c -mx32 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize -fvect-cost-model=dynamic -msse2 -fdump-tree-vect-details -S -o costmodel-pr84986.s^M PASS: gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c (test for excess errors) FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c scan-tree-dump vect "vectorized 1 loops"
[Bug fortran/70068] ICE: out of memory on involving empty substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 24 17:37:21 2018 New Revision: 258835 URL: https://gcc.gnu.org/viewcvs?rev=258835&root=gcc&view=rev Log: 2018-03-24 Thomas Koenig PR fortran/70068 * expr.c (find_substring_ref): Change types of start, end and length variables to gfc_charlen_t. Set length to zero for empty substring. 2018-03-24 Thomas Koenig PR fortran/70068 * gfortran.dg/substr_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/substr_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/70068] ICE: out of memory on involving empty substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260 --- Comment #2 from Thomas Koenig --- Still the same thing with current trunk. Interestingly, integer, parameter:: is(1)=(/(i,i=1,1)/) integer, parameter :: x = is(1) print *,x end is simplified correctly. Maybe a missing call to gfc_simplify_expr somewhere...
[Bug target/85058] Builtin-functions for -mbmi2 documented with wrong names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85058 --- Comment #3 from Jonathan Wakely --- I did wonder about that. So documenting _pdep_u32 is right, but we should not call it a built-in, and should mention the header instead?
[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #2)
> Still the same thing with current trunk.
>
> Interestingly,
>
> integer, parameter:: is(1)=(/(i,i=1,1)/)
> integer, parameter :: x = is(1)
> print *,x
> end
>
> is simplified correctly.
>
> Maybe a missing call to gfc_simplify_expr somewhere...
Still what?
gfc -o z a.f90 -fdump-tree-original && ./z
1
laptop-kargl:kargl[231] more a.f90.003t.original
MAIN__ ()
{
integer(kind=4) i;
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 3;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
{
static integer(kind=4) C.3677 = 1;
_gfortran_transfer_integer_write (&dt_parm.0, &C.3677, 4);
}
_gfortran_st_write_done (&dt_parm.0);
}
}
[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- The whole parameter array could be removed if is(1) was simplified to 1 (which it currently isn't). I have a patch.
[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260
--- Comment #5 from Dominique d'Humieres ---
The dump for the test in comment 0 is
MAIN__ ()
{
integer(kind=4) i;
static integer(kind=4) is[1] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ...,
9989, 9990, 9991, 9992, 9993, 9994, 9995, 9996, 9997, 9998, , 1};
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = &"pr51260.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 2;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_integer_write (&dt_parm.0, &is[0], 4);
_gfortran_st_write_done (&dt_parm.0);
}
}
__attribute__((externally_visible))
main (integer(kind=4) argc, character(kind=1) * * argv)
{
static integer(kind=4) options.1[7] = {68, 8191, 0, 1, 1, 0, 31};
_gfortran_set_args (argc, argv);
_gfortran_set_options (7, &options.1[0]);
MAIN__ ();
return 0;
}
[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #5 from Eric Gallager ---
(In reply to Bruno Haible from comment #4)
> I am having the same error, even with option -C (which does not need a
> -fmain=... option):
>
> $ gcj -v -C HelloWorld.java
> Using built-in specs.
> COLLECT_GCC=/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/gcj
> Target: i686-pc-linux-gnu
> Configured with: ../gcc-4.7.3/configure --build=i686-pc-linux-gnu
> --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
> --prefix=/arch/x86-linux/gnu-inst-gcc/4.7.3 --enable-shared
> --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix
> --enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32
> --with-gmp=/arch/x86-linux/gnu-inst-gcc/4.7.3
> --with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.7.3
> --with-mpc=/arch/x86-linux/gnu-inst-gcc/4.7.3
> --with-libelf=/arch/x86-linux/gnu-inst-gcc/4.7.3
> --with-ecj-jar=/gfs/petix/Volumes/ExtData/source/gnu/gcc/sourceware.org-ecj/
> ecj-latest.jar
> Thread model: posix
> gcc version 4.7.3 (GCC)
> COLLECT_GCC_OPTIONS='-fsaw-java-file' '-B'
> '/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/libexec/gcc/i686-pc-linux-
> gnu/4.7.3' '-v' '-C'
> '-fbootclasspath=./:/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/../
> lib/gcc/../../share/java/libgcj-4.7.3.jar' '-g1' '-fsyntax-only'
> '-femit-class-files' '-S' '-o' 'NONE' '-shared-libgcc' '-mtune=generic'
> '-march=pentiumpro'
> /media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/libexec/gcc/i686-pc-linux-
> gnu/4.7.3/ecj1 HelloWorld.java -g1
> -fbootclasspath=./:/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/../
> lib/gcc/../../share/java/libgcj-4.7.3.jar -g1 -fsource=1.5 -ftarget=1.5
> -fzip-dependency /tmp/ccrzqP4M.zip
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org.eclipse.jdt.internal.compiler.batch.GCCMain
>at gnu.java.lang.MainThread.run(MainThread.java:100)
> Caused by: java.lang.ClassNotFoundException:
> org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
> gnu.gcj.runtime.SystemClassLoader{urls=[],
> parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
>at java.net.URLClassLoader.findClass(URLClassLoader.java)
>at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:27)
>at java.lang.ClassLoader.loadClass(ClassLoader.java)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
>at gnu.java.lang.MainThread.run(MainThread.java)
>
> The problem is that the file that I specified as --with-ecj-jar value when
> configuring GCC no longer exists. The GCC installation has not copied the
> file to the GCC installation directory! But the ecj1 program still
> references it.
>
> I cannot find an option to tell ecj1 about the new file name of
> ecj-latest.jar. So I ended up creating a symlink so that the old file name
> still works.
GCC 4.7 is no longer supported; the only open branch where java is still
included is GCC 6, and it is only open for regression fixes and docs only.
[Bug tree-optimization/47815] Tail call regression with GCC snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47815 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- Is this still an issue with newer versions of gcc?
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56746 --- Comment #19 from Eric Gallager --- (In reply to Richard Biener from comment #15) > (In reply to comment #14) > > Ping? Can someone review my last patch? I think it's clean enough to be > > applied (minus the TODO notes) and extra fixes can come separately later. > > Did you post it to gcc-patches? If so, ping there. Yup, it's in the URL field now: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00284.html ...adding "patch" keyword.
[Bug target/45391] CPU2006 482.sphinx3: gcc4.6 5% regression from prefetching of vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45391 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=45021, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=45022 Resolution|--- |INVALID --- Comment #7 from Eric Gallager --- (In reply to Andrew Pinski from comment #6) > Is this still true with GCC 4.9 or the trunk? Guess not since there's been no reply since being put in WAITING 3 years ago; closing accordingly. (Feel free to reopen if it is actually still an issue)
[Bug tree-optimization/60890] Performance regression in 4.8 for memory postinc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60890 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-24 CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=48814, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56590 Ever confirmed|0 |1 --- Comment #5 from Eric Gallager --- (In reply to Andrew Pinski from comment #4) > Can you try GCC 5.x and/or the trunk? There has been many IVOPTs > improvements since 4.8.x. Putting in WAITING until this is tried.
[Bug c++/85067] New: [8 Regression] ICE with volatile parameter in defaulted copy-constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85067
Bug ID: 85067
Summary: [8 Regression] ICE with volatile parameter in
defaulted copy-constructor
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE on trunk:
==
template struct A
{
A();
A(volatile A&) = default;
};
struct B
{
A<0> a;
};
B b;
==
bug.cc: In instantiation of 'struct A<0>':
bug.cc:9:8: required from here
bug.cc:4:3: error: defaulted declaration 'A< >::A(volatile
A< >&) [with int = 0]' does not match the expected
signature
A(volatile A&) = default;
^
bug.cc:4:3: note: expected signature: 'constexpr A<0>::A(A<0>&)'
bug.cc:12:3: internal compiler error: in implicitly_declare_fn, at
cp/method.c:2059
B b;
^
0x61e3ab implicitly_declare_fn(special_function_kind, tree_node*, bool,
tree_node*, tree_node*)
../../gcc/gcc/cp/method.c:2059
0x8f5e63 lazily_declare_fn(special_function_kind, tree_node*)
../../gcc/gcc/cp/method.c:2392
0x8fd544 get_class_binding(tree_node*, tree_node*, int)
../../gcc/gcc/cp/name-lookup.c:1297
0x9a2625 lookup_field_r
../../gcc/gcc/cp/search.c:977
0x9a178d dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc/gcc/cp/search.c:1410
0x9a1972 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc/gcc/cp/search.c:1134
0x9a1c53 lookup_fnfields(tree_node*, tree_node*, int)
../../gcc/gcc/cp/search.c:1329
0x823c91 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:8932
0x8d2923 expand_default_init
../../gcc/gcc/cp/init.c:1892
0x8d2923 expand_aggr_init_1
../../gcc/gcc/cp/init.c:2007
0x8d3289 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1747
0x887ddf build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:6273
0x887ddf check_initializer
../../gcc/gcc/cp/decl.c:6422
0x89fbdc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7127
0x93c2eb cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19741
0x943758 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13059
0x944568 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12884
0x9484c2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12782
0x9488d1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12658
0x948bc4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
Please submit a full bug report, [etc.]
The regression was introduced between 2017-09-26 and 2017-10-07.
[Bug target/45927] autoconf regression wrt .quad availability targeting amd64 from biarch cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45927 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-24 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > Does this still happen in GCC 5? putting in WAITING on a reply to this
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Benjamin Kosnik from comment #9) > Mine. Fixed momentarily. (In reply to Benjamin Kosnik from comment #10) > Author: bkoz > Date: Tue May 24 02:38:19 2011 > New Revision: 174100 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174100 > Log: > 2011-05-23 Benjamin Kosnik > > PR libstdc++/37144 > PR libstdc++/28457 > [snip] So... is this FIXED now?
[Bug tree-optimization/67283] GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Known to work||7.0 Resolution|--- |FIXED --- Comment #16 from Eric Gallager --- (In reply to Xavier Roche from comment #15) > Seems to be working fine starting from 6.1.0 (tested up to 7.0.0 20161113) OK, closing then.
[Bug c++/85068] New: [6/7/8 Regression] ICE with invalid covarint return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85068
Bug ID: 85068
Summary: [6/7/8 Regression] ICE with invalid covarint return
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 4.0.0:
=
struct A;
struct B
{
virtual A* foo();
};
struct C : virtual B
{
virtual C* foo();
};
struct D : C
{
virtual C* foo();
};
=
bug.cc:10:14: error: invalid covariant return type for 'virtual C* C::foo()'
virtual C* foo();
^~~
bug.cc:5:14: error: overriding 'virtual A* B::foo()'
virtual A* foo();
^~~
bug.cc:13:8: internal compiler error: Segmentation fault
struct D : C
^
0xebb63f crash_signal
../../gcc/gcc/toplev.c:325
0x84327d tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3134
0x84327d update_vtable_entry_for_fn
../../gcc/gcc/cp/class.c:2492
0x84327d dfs_modify_vtables
../../gcc/gcc/cp/class.c:2668
0x9a178d dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc/gcc/cp/search.c:1410
0x9a17e6 dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc/gcc/cp/search.c:1422
0x9a17e6 dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc/gcc/cp/search.c:1422
0x9a39c7 dfs_walk_once(tree_node*, tree_node* (*)(tree_node*, void*),
tree_node* (*)(tree_node*, void*), void*)
../../gcc/gcc/cp/search.c:1507
0x849b5a modify_all_vtables
../../gcc/gcc/cp/class.c:2696
0x849b5a finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6813
0x84ba1c finish_struct(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:7047
0x92eb70 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22537
0x930b89 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22791
0x930b89 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16776
0x93dec6 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13627
0x9435c0 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12937
0x944568 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12884
0x9484c2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12782
0x9488d1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12658
0x948bc4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
Please submit a full bug report, [etc.]
[Bug libstdc++/85069] New: std::invoke_result returns a wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85069
Bug ID: 85069
Summary: std::invoke_result returns a wrong type
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
`std::invoke_result` returns a wrong type. Consider the following source file:
```
#include
// log_type displays the type of T in compiler error
template void log_type() = delete;
struct F
{
int operator()() { return 9; }
};
int main()
{
log_type>();
}
```
I do not expect it to compile, but when generating error message it displays
the "return type" from the type trait. I expect the type of
`std::invoke_result_t` to be `int`, but instead, the compiler reports that
it is `F`. I do not get this problem when I use the deprecated trait
`std::result_of` instead.
[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- There is a similar problem going on with pr66709, only with a string: program p character(4), parameter :: fmt(1) = '(i8)' integer :: n read (*, fmt=fmt) n write (*, fmt=fmt) n end The parameter expr gets into trans-io as an ARRAY_EXPR with rank 0. I have tried gfc_simplify_expr and that does not do it. If one removes the 'parameter' attribute this compiles and runs fine. So somewhere in the parameter processing we are missing something.
[Bug libstdc++/85069] std::invoke_result returns a wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85069 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- std::invoke_result_t is F, so you're trying to call log_type so the error is correct. Maybe you meant to use std::invoke_result_t? The invoke_result trait doesn't work the same as result_of (it would be pointless to replace result_of with something that works identically but has a different name).
[Bug libstdc++/85069] std::invoke_result returns a wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85069 --- Comment #2 from Jonathan Wakely --- P.S. std::result_of is implemented in terms of std::invoke_result, so they will always give the same answer when asked the same question. I think your problem is you're asking the wrong question.
[Bug libstdc++/85069] std::invoke_result returns a wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85069 --- Comment #3 from Andrzej Krzemienski --- You're correct. It is my bad. Sorry, I assumed they both had identical interface. This ticket can be closed.
[Bug libstdc++/85069] std::invoke_result returns a wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85069 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- OK thanks.
[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69497 --- Comment #6 from Jerry DeLisle --- Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ... A gcc/testsuite/gfortran.dg/pr69497.f90 M gcc/fortran/ChangeLog M gcc/fortran/symbol.c M gcc/testsuite/ChangeLog Committed r258839 Muffed the ChangeLogs and fixed them.
[Bug driver/82806] New: Stabilize paths in assembler and dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82806 Bug ID: 82806 Summary: Stabilize paths in assembler and dumps Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Recently I've run into the following issues: 1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82415 "Bug 82415 - FAIL: gcc.target/i386/naked-1.c scan-assembler-not ret". I build and tested gcc in a directory with "ret" in the path, and an assembler scan triggered on that. 2. https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00055.html. I build and tested gcc in a directory with "while" in the path, and a tree-dump scan triggered on that. I wonder if we can add a gcc option -fstrip-path[=] that strips (or replaces with a constant string) paths in compiler output such as dumps and assembler. By using by default fstrip-path="stripped-path" or some such in the testsuite, we can stabilize compiler output and reduce noise in the testsuite. --- Comment #1 from Tom de Vries --- 3. https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01357.html vrp104.c scan-tree-dump-times "switch" I build and tested gcc in a directory with switch in the path, and an tree-dump scan triggered on that.
[Bug c++/85070] New: ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85070
Bug ID: 85070
Summary: ICE on C++ code: in lazily_declare_fn, at
cp/method.c:2409
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180324 (experimental) [trunk revision 258835] (GCC)
$
$ g++tk -std=c++11 tmp.cpp -c
$
$ g++tk -std=c++14 tmp.cpp -c
tmp.cpp:8:8: error: ‘constexpr A& A::operator=(const A&)’ cannot be overloaded
with ‘constexpr A& B::operator=(const A&)’
struct A : B
^
tmp.cpp:5:17: note: previous declaration ‘constexpr A& B::operator=(const A&)’
constexpr A & operator= (const A &);
^~~~
tmp.cpp:11:11: internal compiler error: in lazily_declare_fn, at
cp/method.c:2409
} a { a = a };
^
0x7dadb5 lazily_declare_fn(special_function_kind, tree_node*)
../../gcc-source-trunk/gcc/cp/method.c:2409
0x7e2bdc get_class_binding(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/name-lookup.c:1309
0x8b7a75 lookup_field_r
../../gcc-source-trunk/gcc/cp/search.c:977
0x8b688e dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc-source-trunk/gcc/cp/search.c:1410
0x8b6a51 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc-source-trunk/gcc/cp/search.c:1134
0x8b6e13 lookup_fnfields(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/search.c:1330
0x6d2006 build_new_op_1
../../gcc-source-trunk/gcc/cp/call.c:5694
0x6d2e1e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:6058
0x91d707 cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:8055
0x91ecec build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:8301
0x8036ee cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9532
0x804513 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9772
0x8049f7 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21931
0x804b3d cp_parser_initializer_list
../../gcc-source-trunk/gcc/cp/parser.c:22198
0x804b3d cp_parser_braced_list
../../gcc-source-trunk/gcc/cp/parser.c:21969
0x8079b6 cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:21887
0x82a6f1 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19686
0x82c1c8 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13067
0x82d04f cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12885
0x838910 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$
-
struct A;
struct B
{
constexpr A & operator= (const A &);
};
struct A : B
{
using B::operator=;
} a { a = a };
