[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[jim at meyering dot net]

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

--- Comment #5 from jim at meyering dot net ---
FYI, for a little more context around how I found it, here's the thread on
emacs-devel:
https://lists.gnu.org/archive/html/emacs-devel/2017-05/msg00182.html

[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[jim at meyering dot net]

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

--- Comment #4 from jim at meyering dot net ---
Created attachment 41351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41351=edit
process.i.xz

Thanks for the quick work.
Here's the original process.i file.
Had to compress it, because it was just larger than the 1000kb maximum.

[Bug fortran/80442] Rejects DATA statement with array slice

[koenigni at gcc dot gnu.org]

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

--- Comment #2 from Nicolas Koenig  ---
Author: koenigni
Date: Sat May 13 23:38:36 2017
New Revision: 248012

URL: https://gcc.gnu.org/viewcvs?rev=248012=gcc=rev
Log:

2017-05-09  Nicolas Koenig  

PR fortran/80442
* array.c (gfc_ref_dimen_size): Simplify stride
expression
* data.c (gfc_advance_section): Simplify start,
end and stride expressions
(gfc_advance_section): Simplify start and end
expressions
(gfc_get_section_index): Simplify start expression 

2017-05-09  Nicolas Koenig  

PR fortran/80442
* gfortran.dg/impl_do_var_data.f90: New Test


Added:
trunk/gcc/testsuite/gfortran.dg/impl_do_var_data.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/data.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/80590] [8 regression] non-bootstrap build failure of Ada runtime

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-13
 CC||ebotcazou at gcc dot gnu.org
Version|7.0 |8.0
   Target Milestone|--- |8.0
Summary|[ada] non-bootstrap build   |[8 regression]
   |failure in ada -- Error |non-bootstrap build failure
   |reporting routines  |of Ada runtime
   |re-entered  |
 Ever confirmed|0   |1

[Bug c++/80737] variant as class member resulting to compile errors

[timshen at gcc dot gnu.org]

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

--- Comment #4 from Tim Shen  ---
(In reply to Tim Shen from comment #3)
> (In reply to TC from comment #1)
> > Looks like the constraint on the convert-everything constructor needs to
> > check for is_same, variant> first and short circuit if that's
> > true.
> 
> I'm not quite sure whether we need that short circuit - it's in a SFINAE
> environment, so if anything goes wrong, there shouldn't be a hard error.
> Therefore even if I agree that we should check is_same,
> variant> first, that shouldn't affect the correctness.

s/even if/even though/.

[Bug libstdc++/80737] variant as class member resulting to compile errors

[timshen at gcc dot gnu.org]

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

--- Comment #3 from Tim Shen  ---
(In reply to TC from comment #1)
> Looks like the constraint on the convert-everything constructor needs to
> check for is_same, variant> first and short circuit if that's
> true.

I'm not quite sure whether we need that short circuit - it's in a SFINAE
environment, so if anything goes wrong, there shouldn't be a hard error.
Therefore even if I agree that we should check is_same, variant>
first, that shouldn't affect the correctness.

[Bug libstdc++/80737] variant as class member resulting to compile errors

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #2 from Tim Shen  ---
I reduced the test case a bit, noticing that a seemingly trivial change to
 makes it compile. Here it is: https://godbolt.org/g/tQowts

Defining the macro BUG reproduces the compile failure, however the code in BUG
should have the same meaning as the other branch - it merely uses a type alias.

FWIW clang 5.0.0 compiles the pre-processed code with/without -DBUG.

I believe that it's a GCC frontend issue.

[Bug libstdc++/80737] variant as class member resulting to compile errors

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
#include 
#include 

std::variant a, b(a);

In file included from main.cpp:1:0:
/usr/local/include/c++/7.1.0/variant: In instantiation of 'struct
std::__detail::__variant::__accepted_index':
/usr/local/include/c++/7.1.0/variant:911:26:   required from 'constexpr const
size_t std::variant::__accepted_index'
/usr/local/include/c++/7.1.0/variant:940:6:   required by substitution of
'template constexpr std::variant::variant(_Tp&&)
[with _Tp = std::variant&;  = ]'
main.cpp:4:30:   required from here
/usr/local/include/c++/7.1.0/variant:559:49: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
   decltype(__overload_set<_Types...>::_S_fun(std::declval<_Tp>()),
~^
/usr/local/include/c++/7.1.0/variant:541:58: note: candidate: static
std::integral_constant
std::__detail::__variant::__overload_set<_First, _Rest ...>::_S_fun(_First)
[with _First = std::any; _Rest = {}]
   static integral_constant _S_fun(_First);
  ^~
/usr/local/include/c++/7.1.0/variant:541:58: note:   no known conversion for
argument 1 from 'std::variant' to 'std::any'
/usr/local/include/c++/7.1.0/variant:535:19: note: candidate: static void
std::__detail::__variant::__overload_set<_Types>::_S_fun() [with _Types = {}]
 { static void _S_fun(); };
   ^~
/usr/local/include/c++/7.1.0/variant:535:19: note:   candidate expects 0
arguments, 1 provided
/usr/local/include/c++/7.1.0/variant:559:49: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
   decltype(__overload_set<_Types...>::_S_fun(std::declval<_Tp>()),
~^
/usr/local/include/c++/7.1.0/variant:541:58: note: candidate: static
std::integral_constant
std::__detail::__variant::__overload_set<_First, _Rest ...>::_S_fun(_First)
[with _First = std::any; _Rest = {}]
   static integral_constant _S_fun(_First);
  ^~
/usr/local/include/c++/7.1.0/variant:541:58: note:   no known conversion for
argument 1 from 'std::variant' to 'std::any'
/usr/local/include/c++/7.1.0/variant:535:19: note: candidate: static void
std::__detail::__variant::__overload_set<_Types>::_S_fun() [with _Types = {}]
 { static void _S_fun(); };
   ^~
/usr/local/include/c++/7.1.0/variant:535:19: note:   candidate expects 0
arguments, 1 provided
/usr/local/include/c++/7.1.0/variant:559:49: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
   decltype(__overload_set<_Types...>::_S_fun(std::declval<_Tp>()),
~^
/usr/local/include/c++/7.1.0/variant:541:58: note: candidate: static
std::integral_constant
std::__detail::__variant::__overload_set<_First, _Rest ...>::_S_fun(_First)
[with _First = std::any; _Rest = {}]
   static integral_constant _S_fun(_First);
  ^~
/usr/local/include/c++/7.1.0/variant:541:58: note:   no known conversion for
argument 1 from 'std::variant' to 'std::any'
/usr/local/include/c++/7.1.0/variant:535:19: note: candidate: static void
std::__detail::__variant::__overload_set<_Types>::_S_fun() [with _Types = {}]
 { static void _S_fun(); };
   ^~
/usr/local/include/c++/7.1.0/variant:535:19: note:   candidate expects 0
arguments, 1 provided
/usr/local/include/c++/7.1.0/variant: In instantiation of 'constexpr const
size_t std::__detail::__variant::__accepted_index::value':
/usr/local/include/c++/7.1.0/variant:911:26:   required from 'constexpr const
size_t std::variant::__accepted_index'
/usr/local/include/c++/7.1.0/variant:940:6:   required by substitution of
'template constexpr std::variant::variant(_Tp&&)
[with _Tp = std::variant&;  = ]'
main.cpp:4:30:   required from here
/usr/local/include/c++/7.1.0/variant:564:12: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
  - decltype(__overload_set<_Types...>::
 ~~~
  _S_fun(std::declval<_Tp>()))::value;
  ~~^
/usr/local/include/c++/7.1.0/variant:541:58: note: candidate: static
std::integral_constant
std::__detail::__variant::__overload_set<_First, _Rest 

[Bug fortran/80674] trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
True for all the open branches (5 to 8).

[Bug fortran/80722] gfortran can not compile omp clause with default(none) when there is a type bind method

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from gfortran 5.4.0 up to trunk (8.0).

[Bug libstdc++/80737] New: variant as class member resulting to compile errors

[z-1st at mail dot ru]

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

Bug ID: 80737
   Summary: variant as class member resulting to compile
errors
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: z-1st at mail dot ru
  Target Milestone: ---

variant works as expected outside the class. But if it is declared as a
class member it doesn't compile in some cases

The following example doesn't compile

struct MyClass
{
variant var;
};
int main()
{
MyClass s; //fail
return 0;
}

However, the following compiles

MyClass s{}; //works
MyClass s{1};//works

Also, it is not possible to write custom constructors arount it.

Example output:
https://godbolt.org/g/NNQR09

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Pat Haugen from comment #7)
> (In reply to Pat Haugen from comment #6)
> > 
> > I just ran into the same ICE and the proposed patch fixes the problem.
> 
> Unfortunately the patch introduces the same ICE on another benchmark that
> used to build just fine.

Can you please provide a test-case? Or can you dump the sreal values via
.to_double() ? That can be also hint for us to fix that properly.

[Bug middle-end/80222] may_alias folded away

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #7 from Eric Botcazou  ---
Backporting onto the 6 branch introduced regressions:
  https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01087.html

[Bug c++/80736] New: Wrong overload picked with uniform initialization

[d.frey at gmx dot de]

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

Bug ID: 80736
   Summary: Wrong overload picked with uniform initialization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.frey at gmx dot de
  Target Milestone: ---

The following program leads to an infinite recursion:

#include 

template< typename T >
struct vector
{
   vector() = default;
   vector( const vector& ) = default; // 1

   vector( std::initializer_list< T > ) {} // 2
};

template< typename T >
struct model
{
   T data;

   model( const T& v )
   // : data( v )  // chooses 1
  : data{ v }  // chooses 2 over 1, creating an infinite recursion
   {
   }
};

struct drawable
{
   template< typename T >
   drawable( const T& v )
   {
  model< T >{ v };
   }
};

int main()
{
   vector< drawable > v;
   drawable d = v;
   (void)d;
}

The problem is that the ctor with the initializer_list is preferred over the
copy-ctor. This should be fixed by DR 1467 (AFAICT), but GCC still gets it
wrong in the above program.

Tested with GCC 4.9.3, 5.4, 6.3, and 7.1.

Clang 3.7+ gets it right, previous versions of Clang have the same problem as
GCC.

Link: https://wandbox.org/permlink/MiS6pzVbGOO8Hxaw

[Bug fortran/80666] character length parameter fails if declaration order incorrect

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The change in behavior is likely due to revision r238904 (pr71730). 

Note that compiling the first test in comment 0 with -std=f95 before this
revision gives

% /opt/gcc/gcc7p-238848p2/bin/gfortran pr80666.f90 -std=f95
pr80666.f90:3:13:

   character*(keylen), intent(in) :: key
 1
Error: GNU Extension: Symbol 'keylen' is used before it is typed at (1)
pr80666.f90:1:29:

 subroutine test_arg_order(key,keylen)
 1
Error: Symbol 'key' at (1) has no IMPLICIT type

> Just try to write standard conforming code if possible.

Seconded (this is a very easy case), since the revision r238904 fixes an ICE at
the expense of a GNU extension, I don't think it is worth putting any effort to
restore the extension -> closing this PR as WONTFIX.

> On the other hand, the main misunderstanding here I think is what defines
> the order of the definition of subroutine parameters. Is it the parameter
> list in the subroutine statement or is it the individual type declarations
> that follow it? It seems most logical in my eyes if the parameter list
> is the one that defines order of parameter definitions but I might be wrong.
> Is this defined in the fortran specification at all? 

(1) PARAMETER has a very precise definition in Fortran and AFAICT this
definition (named constants) does not match your use in the above quotation.
Are you meaning dummy arguments?

(2) If yes, there is no correlation between the order the dummy arguments and
the individual type declarations. The order of type declarations is only a
matter of coding style, provided they follow the rule "define before using".

Final note: while looking at the DATA statement, I stumbled on the following

5.6.7 DATA statement

...

3 A variable that appears in a DATA statement and has not been typed
  previously may appear in a subsequent type declaration only if that
  declaration confirms the implicit typing. An array name, array section,
  or array element that appears in a DATA statement shall have had its array
  properties established by a previous specification statement.

Thus the rule "define before using" has at least one exception.

[Bug tree-optimization/79920] [6 Regression] Incorrect floating point results when compiling with -O3

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #6 from Mikael Pettersson  ---
(In reply to Andrey Guskov from comment #5)
> The revision 245968 breaks compilation of 465.tonto from SPEC2006 with these
> options:
> 
> -m32 -Ofast -flto -march=core-avx2

Was this regression fixed, and if so by which revision?  I don't have immediate
access to SPEC2006 so I cannot check for myself.

[Bug c/80734] GCC 6.3.1 errors compiling GCC 4.8.5 - error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute

[eric.parker at inventati dot org]

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

--- Comment #2 from Eric Parker  ---
Okay, that works for me. Thanks Jakub.

[Bug c/80734] GCC 6.3.1 errors compiling GCC 4.8.5 - error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Jakub Jelinek  ---
The bug is on the GCC 4.8 side, so either you need to patch it, or build with
-std=gnu++98 - then __GNUC_STDC_INLINE__ will not be defined and it ought to
compile fine.

[Bug middle-end/80735] New: IPA: SRA inhibits constant propagation of structs across multiple function calls

[daniel.santos at pobox dot com]

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

Bug ID: 80735
   Summary: IPA: SRA inhibits constant propagation of structs
across multiple function calls
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.santos at pobox dot com
CC: mjambor at suse dot cz
  Target Milestone: ---

Created attachment 41350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41350=edit
test_case.c

I've finally managed a simple test case for this long-standing missed
optimization.  Given the test code built with -O2 -fno-inline:

static const struct foo {
  long a;
  long b;
} f = {8, 8};

static long a (const struct foo *foo) {return foo->b;}
static long b (const struct foo *foo) {return a (foo);}
long c (void) {return b ();}

Result:
 :
   0:   48 89 f8mov%rdi,%rax
   3:   c3  retq

0010 :
  10:   bf 08 00 00 00  mov$0x8,%edi
  15:   eb e9   jmp0 

0020 :
  20:   eb ee   jmp10 

Although we got isra for foo::b, I had expected a() to consist of only mov
$0x8, %eax; retq, and b() just be a jump to a().  But when we disable ipa-sra
we get the expected result (-O2 -fno-inline -fno-ipa-sra):

 :
   0:   b8 08 00 00 00  mov$0x8,%eax
   5:   c3  retq

0010 :
  10:   eb ee   jmp0 

0020 :
  20:   eb ee   jmp10 

If we replace the struct with an array or a pointer to a long then SRA does not
interfere with the constant propagation (-O2 -fno-inline):

static const long f[2] = {8, 8};
static long a (const long foo[]) {return foo[1];}
static long b (const long foo[]) {return a (foo);}
long c (void){return b (f);}

Result
 :
   0:   b8 08 00 00 00  mov$0x8,%eax
   5:   c3  retq

0010 :
  10:   eb ee   jmp0 

0020 :
  20:   eb ee   jmp10 

I'm still very new to this part of GCC, but I'm guessing that when we do the
SRA, we toss out the original aggregate.  If so, then we aren't reserving the
possibility that all of the function's callers could get cloned with a constant
for the aggregate, which would (probably always?) be better than just plucking
the scaler out of the aggregate.  I'll be digesting tree.sra.c and the cgraph
to try and figure this one out, but if anybody understands this better then I
would appreciate some hints.  :)