[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

[jvdelisle at gcc dot gnu.org]

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 libstdc++/85069] std::invoke_result returns a wrong type

[redi at gcc dot gnu.org]

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 libstdc++/85069] std::invoke_result returns a wrong type

[akrzemi1 at gmail dot com]

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

[redi at gcc dot gnu.org]

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

[redi at gcc dot gnu.org]

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 fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access

[jvdelisle at gcc dot gnu.org]

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] New: std::invoke_result returns a wrong type

[akrzemi1 at gmail dot com]

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 c++/85068] New: [6/7/8 Regression] ICE with invalid covarint return types

[reichelt at gcc dot gnu.org]

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 tree-optimization/67283] GCC regression over inlining of returned structures

[egallager at gcc dot gnu.org]

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 libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.

[egallager at gcc dot gnu.org]

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=rev=174100
> Log:
> 2011-05-23  Benjamin Kosnik  
> 
>   PR libstdc++/37144
>   PR libstdc++/28457
>   [snip]

So... is this FIXED now?

[Bug target/45927] autoconf regression wrt .quad availability targeting amd64 from biarch cross compiler

[egallager at gcc dot gnu.org]

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 c++/85067] New: [8 Regression] ICE with volatile parameter in defaulted copy-constructor

[reichelt at gcc dot gnu.org]

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 tree-optimization/60890] Performance regression in 4.8 for memory postinc

[egallager at gcc dot gnu.org]

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 target/45391] CPU2006 482.sphinx3: gcc4.6 5% regression from prefetching of vectorized loop

[egallager at gcc dot gnu.org]

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 preprocessor/53525] Performance regression due to enabling track-macro-expansion

[egallager at gcc dot gnu.org]

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 tree-optimization/47815] Tail call regression with GCC snapshot

[egallager at gcc dot gnu.org]

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 java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain

[egallager at gcc dot gnu.org]

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 fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access

[dominiq at lps dot ens.fr]

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 (_parm.0);
_gfortran_transfer_integer_write (_parm.0, [0], 4);
_gfortran_st_write_done (_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, [0]);
  MAIN__ ();
  return 0;
}

[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access

[tkoenig at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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 (_parm.0);
{
  static integer(kind=4) C.3677 = 1;

  _gfortran_transfer_integer_write (_parm.0, , 4);
}
_gfortran_st_write_done (_parm.0);
  }
}

[Bug target/85058] Builtin-functions for -mbmi2 documented with wrong names

[redi at gcc dot gnu.org]

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

[tkoenig at gcc dot gnu.org]

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 fortran/70068] ICE: out of memory on involving empty substring

[tkoenig at gcc dot gnu.org]

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/70068] ICE: out of memory on involving empty substring

[tkoenig at gcc dot gnu.org]

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=gcc=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 tree-optimization/85066] New: FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c scan-tree-dump vect "vectorized 1 loops"

[hjl.tools at gmail dot com]

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/42651] Functions with result: Wrongly accepts attributes to function name

[kargl at gcc dot gnu.org]

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 c++/85065] New: [concepts] ICE with invalid use of a concept

[reichelt at gcc dot gnu.org]

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 c++/85064] New: [concepts] ICE with auto as template parameter

[reichelt at gcc dot gnu.org]

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 fortran/42651] Functions with result: Wrongly accepts attributes to function name

[kargl at gcc dot gnu.org]

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=gcc=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 target/85044] ENDBR is missing in ix86_trampoline_init

[hjl.tools at gmail dot com]

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 tree-optimization/84969] [8 Regression] Wrong code with -ftree-loop-distribute-patterns

[jakub at gcc dot gnu.org]

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 tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct

[jakub at gcc dot gnu.org]

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 c++/85061] ICE with __builtin_offsetof applied to static member

[jakub at gcc dot gnu.org]

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 fortran/70068] ICE: out of memory on involving empty substring

[tkoenig at gcc dot gnu.org]

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 tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct

[vries at gcc dot gnu.org]

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=edit
Updated tentative patch

[Bug tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct

[vries at gcc dot gnu.org]

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=edit
Tentative patch

Currently doing:
- bootstrap & reg-test on x86_64, and
- build and libgomp reg-test on x86_64 with nvptx accelerator.

[Bug target/85058] Builtin-functions for -mbmi2 documented with wrong names

[jakub at gcc dot gnu.org]

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] New: Switch conversion in openacc routine introduces unsupported construct

[vries at gcc dot gnu.org]

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 debug/78685] -Og generates too many ""s

[jakub at gcc dot gnu.org]

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 debug/82738] [meta-bug] issues with the -Og optimization level

[jakub at gcc dot gnu.org]

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 rtl-optimization/85059] Compiling with -Og should preserve variable values

[jakub at gcc dot gnu.org]

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 c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"

[jakub at gcc dot gnu.org]

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 c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"

[jakub at gcc dot gnu.org]

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++/85062] New: [6/7/8 Regression] ICE on alignas with parameter pack

[reichelt at gcc dot gnu.org]

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 tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

[rsandifo at gcc dot gnu.org]

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 tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

[rsandifo at gcc dot gnu.org]

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=gcc=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/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)

[sch...@linux-m68k.org]

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 c++/85061] New: ICE with __builtin_offsetof applied to static member

[reichelt at gcc dot gnu.org]

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 java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain

[bruno at clisp dot org]

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 lto/85047] cdd2a01 (and others) FAIL with -flto

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85047

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug lto/85047] cdd2a01 (and others) FAIL with -flto

[ebotcazou at gcc dot gnu.org]

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=edit
Reduced testcase

To be compiled with "gnatmake lto23 -flto".

[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain

[bruno at clisp dot org]

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 c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"

[redi at gcc dot gnu.org]

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 c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"

[redi at gcc dot gnu.org]

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"

[redi at gcc dot gnu.org]

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 tree-optimization/63734] [5.0 regression] FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 (internal compiler error)

[glisse at gcc dot gnu.org]

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] New: Object cannot call its inherited member function "without object"

[dingyuc at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85060

Bug ID: 85060
   Summary: Object cannot call its inherited member function
"without object"
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dingyuc at 126 dot com
  Target Milestone: ---

Created attachment 43746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43746=edit
The source code "hierarchy.cc" and a preprocessed file "hierarchy.ii"

The attached source code can be compiled and executed by older versions of g++
but not by g++ 7.0.0 - 7.3.1. I managed to simplify the case into three level
of classes where child and grandchild classes are templates. The code has been
tested on Archlinux, OS_X and some online compilers, all confirming it's a gcc7
problem.
Simply the command
$ g++ hierarchy.cc
will yield
hierarchy.cc: In member function ‘void CC::bar()’:
hierarchy.cc:20:32: error: cannot call member function ‘int CA::foo()’
without object
 const SPECIFIER m = CA::foo(); // Won't pass!!

Here is the complete source code for people bothered to untar:
$ cat hierarchy.cc 
#include 
#ifndef SPECIFIER
#define SPECIFIER int// fail with g++7
// #define SPECIFIER auto   // fail with g++7, or invalid without c++11
// #define SPECIFIER T  // pass with g++7 when int->T is possible
#endif

class CA {
public:
  int foo() { return 42; }
};

template 
class CB : public CA { };

template 
class CC : public CB {
public:
  void bar() {
const SPECIFIER m = CA::foo(); // Won't pass!!
// const SPECIFIER m = this->CA::foo(); // This will work.
std::cout << "THE ULTIMATE ANSWER: " << m << std::endl;
  }
};

int main(void) {
  CC c;
  c.bar();
  return 0;
}