date:20170215

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Martin Sebor  ---
Thanks.  You are correct, that was the case in my original patch for bug 68120
but it ended up morphing into the _p built-ins (not by my choice).

Resolving as fixed by r237238.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

2017-02-15 Thread joel at clambassador dot com

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

joel at clambassador dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #9 from joel at clambassador dot com ---
Wow, I had completely forgotten about the time I spent puzzled over this
behaviour in 2013.

I'm guessing that just the existence of this as a bug report for 'condition
variables static linking' is sufficient documentation for the rare time it
happens for people. As such I'll note that my unpleasant fix was to include
this in a header:

void pthread_cond_bug() {
pthread_cond_signal((pthread_cond_t *) nullptr);
pthread_cond_init((pthread_cond_t *) nullptr,
  (const pthread_condattr_t *) nullptr);
pthread_cond_destroy((pthread_cond_t *) nullptr);
pthread_cond_timedwait((pthread_cond_t *) nullptr, (pthread_mutex_t *)
   nullptr, (const struct timespec *) nullptr);
pthread_cond_wait((pthread_cond_t *) nullptr, (pthread_mutex_t *)
(nullptr);
}

without actually ever calling it; iirc it links in the functions as a result.

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.0

--- Comment #4 from Martin Sebor  ---
You're right that the goto isn't essential here.  The same problem can be
demonstrated in the simplified test case below.  When f() && f() evaluates
to true (and assuming f() initializes what it points to) there "exists a path
from the function entry to a use of the variable that is initialized."  But
f() evaluates to false f() is not called then "there exists a path for
which b is not initialized."  Since there is no way to prove that the second
path is not taken at runtime then, according to the documentation, GCC should
emit a warning.  However, no warning is issued.

int f (int*);

int foo (void)
{
  int a, b;

  if (f () && f ())
return 0;

  return a + b;
}

[Bug c++/60068] missing diagnostic on array with negative bounds in template

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-16
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.0

--- Comment #1 from Martin Sebor  ---
No change in GCC 7.0.  Clang 5.0, EDG eccp 4.11, and Oracle CC 5.13 all reject
the code.  Thus confirmed.

[Bug c++/60063] [5/6/7 Regression] -Wunused-local-typedefs warning despite attribute used in a template

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-16
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79548
Summary|-Wunused-local-typedefs |[5/6/7 Regression]
   |warning despite attribute   |-Wunused-local-typedefs
   |used in a template  |warning despite attribute
   ||used in a template
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
No change in GCC 7.  The -Wunused-local-typedefs warning is still issued
inconsistently.  The warning on the template is a regression from GCC 4.6 most
likely introduced in r187757, along with bug 79548.

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic -Wunused u.C
void foo ()
{
typedef __attribute__ ((used)) int T;
}

template 
void bar ()
{
  typedef __attribute__ ((used)) T U;
}
u.C: In function ‘void bar()’:
u.C:9:36: warning: typedef ‘U’ locally defined but not used
[-Wunused-local-typedefs]
   typedef __attribute__ ((used)) T U;
^

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

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

--- Comment #12 from Paul Eggert  ---
Ah, sorry, I am using GCC 6.3.1, whereas __builtin_mul_overflow_p is a GCC
7-ism.  Somehow I got it into my head that __builtin_mul_overflow(A,B,C) should
be a constant expression if A, B, are constant expressions and C is a
(constant) null pointer, but evidently that's not the case. Since the problem
must be fixed in GCC 7 with its new __builtin_mul_overflow_p primitive, please
close this bug.

[Bug c++/79548] [5/6/7 Regression] missing -Wunused-variable on a typedef'd variable in a function template

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=33255
Summary|missing -Wunused-variable   |[5/6/7 Regression] missing
   |on a typedef'd variable in  |-Wunused-variable on a
   |a function template |typedef'd variable in a
   ||function template

--- Comment #1 from Martin Sebor  ---
This a regression introduced in GCC 4.7, most likely r178692 (my bisection
points to r178694 because I don't have access to the other binary, but that
seems less likely).

[Bug c++/79548] New: missing -Wunused-variable on a typedef'd variable in a function template

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

Bug ID: 79548
   Summary: missing -Wunused-variable on a typedef'd variable in a
function template
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses the unused local variable in function f() below but misses the
unused variable in the explicitly instantiated template g():

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic -Wunused u.C
void f ()
{
  typedef int T;
  T t;   // warning, ok
}

template 
void g ()
{
  T t;   // warning, ok

  typedef T U;
  U u;   // no warning, bug
}

template void g();
u.C: In function ‘void f()’:
u.C:4:5: warning: unused variable ‘t’ [-Wunused-variable]
   T t;   // warning, ok
 ^
u.C: In instantiation of ‘void g() [with T = int]’:
u.C:16:22:   required from here
u.C:10:5: warning: unused variable ‘t’ [-Wunused-variable]
   T t;   // warning, ok
 ^

[Bug c/59220] bogus warning: packed attribute is unnecessary on an overaligned char

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-16
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.0

--- Comment #1 from Martin Sebor  ---
Confirming my own bug with today's top of trunk (GCC 7.0).

[Bug c++/44648] missing -Wunused warning on a const variable in if statement

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||5.3.0, 6.3.0, 7.0

--- Comment #5 from Martin Sebor  ---
Today's trunk warns on three out of the four cases, missing just the 'if (const
bool b2 = 1)' conditional.

$ cat t.C && gcc -Wall -Wextra -Wpedantic t.C
int main()
{
  bool b0 = 1;   // { dg-warning "" }
  const bool b00 = 1;// { dg-warning "" }
  if (bool b1 = 1)   // { dg-warning "" }
return 0;
  else
return 1;

  if (const bool b2 = 1) // { dg-warning "" }
return 0;
  else
return 1;
}
t.C: In function ‘int main()’:
t.C:5:12: warning: unused variable ‘b1’ [-Wunused-variable]
   if (bool b1 = 1)   // { dg-warning "" }
^~
t.C:3:8: warning: unused variable ‘b0’ [-Wunused-variable]
   bool b0 = 1;   // { dg-warning "" }
^~
t.C:4:14: warning: unused variable ‘b00’ [-Wunused-variable]
   const bool b00 = 1;// { dg-warning "" }
  ^~~

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2017-02-15 Thread dave.anglin at bell dot net

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

--- Comment #3 from dave.anglin at bell dot net ---
I see failure in r240386 (20160923).  r239642 and 239726 were okay.

--
John David Anglin   dave.ang...@bell.net

[Bug c++/40261] confusing diagnostic on ill-formed template definition

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2009-08-25 15:42:13 |2017-2-15
  Known to fail||4.4.0, 5.3.0, 6.3.0, 7.0

--- Comment #2 from Martin Sebor  ---
No change in GCC 7.  For reference, other compilers print:

Clang 5.0:
t.C:4:31: error: nested name specifier 'B::' for declaration does not refer
  into a class, class template or class template partial specialization
template  void B::foo () { }
~~^

EDG eccp 4.11:
"t.C", line 4: error: template argument list must match the parameter list
  template  void B::foo () { }
  ^
Oracle CC:
"t.C", line 4: Error: Cannot define member of undefined specialization "B".
1 Error(s) detected.

IBM XLC++:
"t.C", line 4.25: 1540-0708 (S) The template argument 2 does not match the
corresponding template parameter of "template struct B".

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2017-02-15 Thread dominiq at lps dot ens.fr

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-16
 Ever confirmed|0   |1

[Bug c/35503] Warning about restricted pointers?

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
*** Bug 29465 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/30334] [meta-bug] Request for -Wundefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
Bug 30334 depends on bug 29465, which changed state.

Bug 29465 Summary: warning for overlapping memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c/29465] warning for overlapping memcpy()

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Sebor  ---
The -Wrestrict warning (new in GCC 7) points out this bug.  Unfortunately, the
option is not in -Wall or -Wextra and must be explicitly enabled so few users
will benefit from it.

$ gcc -S -Wrestrict t.c
t.c: In function ‘main’:
t.c:6:13: warning: passing argument 1 to restrict-qualified parameter aliases
with argument 2 [-Wrestrict]
 memcpy (, , sizeof i);
 ^~  ~~

*** This bug has been marked as a duplicate of bug 35503 ***

[Bug c++/71093] use of pseudo-destructor accepted in constant expression

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-16
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Setting Status to Confirmed per comment #1.

[Bug tree-optimization/79547] duplicate strlen calls with same argument not folded

2017-02-15 Thread pinskia at gcc dot gnu.org

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

--- Comment #1 from Andrew Pinski  ---
Most likely the alias analysis thinks s escapes such that f touches it.

Look at the alias dump and also add -vops to the dump option.

[Bug middle-end/71315] missing strlen optimization on a POINTER_PLUS expression

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79547
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
Resolving the original bug as fixed.  I've raised bug 79547 for the problem
pointed out in comment #3.

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2017-02-15 Thread jvdelisle at gcc dot gnu.org

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---

Do you have any idea when the last time this test passed on this platform?

[Bug tree-optimization/79547] New: duplicate strlen calls with same argument not folded

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

Bug ID: 79547
   Summary: duplicate strlen calls with same argument not folded
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As mentioned in bug 71315 comment 3, GCC folds the first of a series of calls
to strlen with the same argument but not the subsequent ones:

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
void f (unsigned);

void f1 (void)
{
char s[] = "1234";

f (__builtin_strlen (s));
}

void f2 (void)
{
char s[] = "1234";

f (__builtin_strlen (s));
f (__builtin_strlen (s));
}


void f3 (void)
{
char s[] = "1234";

f (__builtin_strlen (s));
f (__builtin_strlen (s));
f (__builtin_strlen (s));
}


;; Function f1 (f1, funcdef_no=0, decl_uid=1797, cgraph_uid=0, symbol_order=0)

f1 ()
{
  char s[5];

   [100.00%]:
  s = "1234";
  f (4);
  s ={v} {CLOBBER};
  return;

}



;; Function f2 (f2, funcdef_no=1, decl_uid=1801, cgraph_uid=1, symbol_order=1)

f2 ()
{
  char s[5];
  long unsigned int _3;
  unsigned int _4;

   [100.00%]:
  s = "1234";
  f (4);
  _3 = __builtin_strlen ();
  _4 = (unsigned int) _3;
  f (_4);
  s ={v} {CLOBBER};
  return;

}



;; Function f3 (f3, funcdef_no=2, decl_uid=1805, cgraph_uid=2, symbol_order=2)

f3 ()
{
  char s[5];
  long unsigned int _3;
  unsigned int _4;
  long unsigned int _5;
  unsigned int _6;

   [100.00%]:
  s = "1234";
  f (4);
  _3 = __builtin_strlen ();
  _4 = (unsigned int) _3;
  f (_4);
  _5 = __builtin_strlen ();
  _6 = (unsigned int) _5;
  f (_6);
  s ={v} {CLOBBER};
  return;

}

Re: [Patch, fortran] PR79434 - [submodules] separate module procedure breaks encapsulation

2017-02-15 Thread Jerry DeLisle

On 02/15/2017 10:12 AM, Paul Richard Thomas wrote:
> Dear All,
> 
> Another straightforward patch, although it took some head scratching
> to realize how simple the fix could be :-)
> 
> Bootstraps and regtests on FC23/x_86_64 - OK for trunk and 6-branch?
> 

Yes, OK

Jerry

Re: [Patch, fortran] PR79447 - [F08] gfortran rejects valid & accepts invalid internal subprogram in a submodule

2017-02-15 Thread Jerry DeLisle

On 02/15/2017 10:01 AM, Paul Richard Thomas wrote:
> Dear All,
> 
> This patch is straightforward, verging on 'obvious'.
> 
> Bootstraps and regtests on FC23/x86_64 - OK for trunk and 6 branch?
> 
Yes, OK

Jerry

[Bug c++/55004] [meta-bug] constexpr issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 71391, which changed state.

Bug 71391 Summary: error on aggregate initialization with side-effects in a 
constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71391

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/71391] error on aggregate initialization with side-effects in a constexpr function

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
  Known to fail|7.0 |

--- Comment #1 from Martin Sebor  ---
This appears to have been fixed in r224381 (gcc 6.0.0):

r224381 | jason | 2015-06-11 11:45:01 -0400 (Thu, 11 Jun 2015) | 3 lines

PR c++/66450
* constexpr.c (cxx_eval_store_expression): Avoid messing up outer
ctx->ctor.

*** This bug has been marked as a duplicate of bug 66450 ***

[Bug c++/66450] [5 Regression][C++11][constexpr] Issues when delegating implicit copy constructor in constexpr function

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
*** Bug 71391 has been marked as a duplicate of this bug. ***

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

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

--- Comment #11 from Martin Sebor  ---
Right.  Because the call to __builtin_mul_overflow in the test case is not a
constant expression, the -Woverflow warning detects the overflow in the
multiplication subexpression that is constant.  The __builtin_mul_overflow call
is evaluated into a constant but not until after the warning has detected the
overflow.

The patch for bug 68120 introduced other built-ins to determine overflow at
compile-time.  Using those the return statement in this test case would look
something like this:

return __builtin_mul_overflow_p (0x7fff, 0x7fff, 0)
   ? 2 : (0x7fff * 0x7fff == 0x7fff * 0x7fff);

and compile with no warning.

[Bug libstdc++/79522] std::regex_match always returns false

2017-02-15 Thread jmichae3 at yahoo dot com

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

Jim Michaels  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Jim Michaels  ---
(In reply to Jonathan Wakely from comment #2)
> You did get them swapped. Obviously the regex "abcdefg" can't match "def".
> 
> But even in your second example the behaviour is correct, std::regex_match
> matches the entire string, not any part of it. "def" doesn't match "abcdefg"
> it only matches part of it. Use std::regex_search for that.
> 
> (And "I don't know how C++ works" is still not a bug)

that was a lam, not a response.
this is a valid bug in at least comment #2. UNLESS in a regex /regex/ is
required. that I did not try. so let's try it. different regexes have different
requirements. some you have to just have 2 of the same character at both ends.
I am not some programming dweeb. yeah, I get stuff wrong sometimes, oftentimes
in fact, but I like my code as good as I can get it. and std::regex_match is
supposed to return a bool, which in iostream just comes out as a 0 or 1 I found
out.  so it's great for test rigs. (think: autoconf for fun?)

the documentation does not spell out such a syntax as /regex/.
there is probably a bug in the regex state machine, because it's failing 100%
of the time in my tests. what about your tests? did you apply any?

std::regex should be SO EASY to use. this should have been a no-brainer. I used
a manual.

so here is test#3:

#include 
#include 
int main(void) {
std::cout<<"none of these should fail."<ut
none of these should fail.
test 1 failed
test 2 failed
test 3 failed
test 4 failed

 Wed 02/15/2017 15:53:24.12 L:\projects\find\1.0\win>

[Bug c++/55004] [meta-bug] constexpr issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 71459, which changed state.

Bug 71459 Summary: ICE writing to a string-initialized local array in a 
constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71459

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/71459] ICE writing to a string-initialized local array in a constexpr function

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
The ICE was removed in r243448 (gcc 7.0.0):

r243448 | nathan | 2016-12-08 13:34:04 -0500 (Thu, 08 Dec 2016) | 9 lines

PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

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

--- Comment #10 from Paul Eggert  ---
Unfortunately, the patch for Bug#68120 does not seem to have addressed the
problem here. For example, although the following code uses the new feature
enabled by that patch:

  int f (void) {
return (__builtin_mul_overflow (0x7fff, 0x7fff, (int *) 0)
? 2
: 0x7fff * 0x7fff);
  }

I still get the following warning with GCC 6.3.1 20161221 (Red Hat 6.3.1-1)
x86-64:

t.c: In function ‘f’:
t.c:4:19: warning: integer overflow in expression [-Woverflow]
  : 0x7fff * 0x7fff);
   ^

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

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

--- Comment #21 from Martin Sebor  ---
*** Bug 71457 has been marked as a duplicate of this bug. ***

[Bug c++/71457] valid pointer plus conversion to bool rejected in constexpr context

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
Looks like this was fixed in r244333 (gcc 7.0.0):

r244333 | jakub | 2017-01-11 15:10:36 -0500 (Wed, 11 Jan 2017) | 8 lines

PR c++/71537
* fold-const.c (maybe_nonzero_address): Return 1 for function
local objects.
(tree_single_nonzero_warnv_p): Don't handle function local objects
here.

*** This bug has been marked as a duplicate of bug 71537 ***

[Bug c++/55004] [meta-bug] constexpr issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 71457, which changed state.

Bug 71457 Summary: valid pointer plus conversion to bool rejected in constexpr 
context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71457

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

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

--- Comment #7 from Martin Sebor  ---
Wrong dupe id.

*** This bug has been marked as a duplicate of bug 66938 ***

[Bug c/66938] using bool as destination in overflow checkers

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

--- Comment #2 from Martin Sebor  ---
*** Bug 71479 has been marked as a duplicate of this bug. ***

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|rejects-valid   |diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
  Known to fail|7.0 |

--- Comment #6 from Martin Sebor  ---
Resolving as a dupe of 66943 (the error is correct).

Trunk (GCC 7.0) prints:

t.c: In function ‘f’:
t.c:4:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to boolean type
   __builtin_add_overflow (0, 0, );
 ^
t.c:7:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to enumerated type
   __builtin_add_overflow (0, 0, );
 ^

*** This bug has been marked as a duplicate of bug 66943 ***

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
*** Bug 71479 has been marked as a duplicate of this bug. ***

[Bug c/66938] using bool as destination in overflow checkers

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||5.3.0, 6.3.0

--- Comment #1 from Martin Sebor  ---
This was fixed in r237754.  Current trunk (GCC 7.0) prints the following
errors:

$ cat t.c && gcc -S -Wall t.c
void f (void)
{
  _Bool b;
  __builtin_add_overflow (0, 0, );

  enum E { e0 } e;
  __builtin_add_overflow (0, 0, );

  char c;
  __builtin_add_overflow (0, 0, );
}
t.c: In function ‘f’:
t.c:4:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to boolean type
   __builtin_add_overflow (0, 0, );
 ^
t.c:7:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to enumerated type
   __builtin_add_overflow (0, 0, );
 ^

[Bug c/79546] Strange error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]

2017-02-15 Thread pinskia at gcc dot gnu.org

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

--- Comment #1 from Andrew Pinski  ---
>-Werror=unsafe-loop-optimizations

That is not enabled by default even with -Werror -W -Wall.

But "missed loop optimization, the loop counter may overflow" is basically
saying if i was an signed integer, the loop counter would overflow in some
cases.  The case depends the value of len.  The only way to fix this would be
rewrite the code so that case would not happen.
The cases where it would happen is len = SIZET_MIN ... SIZET_MIN-0x0FFF (if I
did my math correctly).

[Bug c++/69564] [5/6/7 Regression] lto and/or C++ make scimark2 LU slower

2017-02-15 Thread law at redhat dot com

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

--- Comment #30 from Jeffrey A. Law  ---
Looking at the dumps, the tests for whether or not to use the vectorized loop
are considerably more complex with LTO with memory references as well when
compared to the non-LTO version.  It's almost as-if the program-wide visibility
provided by LTO has *hidden* redundancies and mucked up the IV analysis.

The first block of the LTO check looks like:

  # ivtmp.66_807 = PHI 
  Aii_206 = MEM[base: A_139, index: ivtmp.66_807, step: 8, offset: 0B];
  _208 = Aii_206 + _765;
  AiiJ_209 = *_208;
  _449 = SOR_size_15 > i_167;
  _763 = (unsigned int) i_167;
  _762 = _686 - _763;
  _444 = _762 > 8;
  _443 = _444 & _449;
  _438 = Aii_206 + _760;
  _433 = _434 >= _438;
  _425 = Aii_206 + _435;
  _424 = _425 >= _429;
  _423 = _424 | _433;
  _422 = _423 & _443;
  if (_422 != 0)
goto ; [80.00%]
  else
goto ; [20.00%]

Compared to the non-LTO block:

  _156 = ivtmp.112_242 + 16;
  _155 = prephitmp_168 + _156;
  _151 = Aii_72 + ivtmp.112_242;
  _150 = _151 >= _155;
  _146 = Aii_72 + _156;
  _142 = prephitmp_168 + ivtmp.112_242;
  _141 = _142 >= _146;
  _140 = _141 | _150;
  _139 = _140 & _160;
  if (_139 != 0)
goto ;
  else
goto ;


Then the next block in the check (LTO):

;;   basic block 57, loop depth 3, count 0, freq 66, maybe hot
;;prev block 56, next block 58, flags: (NEW, REACHABLE, VISITED)
;;pred:   56 [80.0%]  (TRUE_VALUE,EXECUTABLE)
  niters.2_408 = SOR_size_15 > i_167 ? _762 : 1;
  _366 = (unsigned long) _425;
  _365 = _366 >> 3;
  _364 = -_365;
  _363 = (unsigned int) _364;
  prolog_loop_niters.4_367 = _363 & 1;
  _740 = (unsigned int) ivtmp.86_769;
  _509 = _686 + 4294967294;
  _738 = _509 - _740;
  _295 = SOR_size_15 > i_167 ? _738 : 0;
  _283 = prolog_loop_niters.4_367 == 0 ? 1 : 2;
  if (_283 > _295)
goto ; [10.00%]
  else
goto ; [90.00%]


non-LTO:

;;   basic block 23, loop depth 2, count 0, freq 2, maybe hot
;;prev block 22, next block 24, flags: (NEW, REACHABLE)
;;pred:   22 [80.0%]  (TRUE_VALUE,EXECUTABLE)
  _119 = (unsigned long) _151;
  _118 = _119 & 15;
  _117 = _118 >> 3;
  _116 = -_117;
  _115 = (unsigned int) _116;
  _114 = _115 & 1;
  prolog_loop_niters.46_120 = MIN_EXPR <_114, ivtmp.115_244>;
  if (prolog_loop_niters.46_120 == 0)
goto ;
  else
goto ;


Egad.  No wonder LTO loses.  I don't think the loop iterates enough to make up
for this mess.

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-15
 Ever confirmed|0   |1

--- Comment #9 from Martin Sebor  ---
Paul, with bug 68120 resolved, can this bug be closed as well or is there
something else to do here?

[Bug c/79479] -Woverflow false alarm in unreachable expression

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #15 from Martin Sebor  ---


*** This bug has been marked as a duplicate of bug 4210 ***

[Bug middle-end/4210] should not warning with dead code

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

--- Comment #26 from Martin Sebor  ---
*** Bug 79479 has been marked as a duplicate of this bug. ***

[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type

2017-02-15 Thread wschmidt at gcc dot gnu.org

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||powerpc*-*-*
   Target Milestone|--- |6.4
  Known to fail||5.4.1, 6.3.1

[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type

2017-02-15 Thread carll at gcc dot gnu.org

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

Carl Love  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-15
   Assignee|unassigned at gcc dot gnu.org  |carll at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Carl Love  ---
The issue has been fixed in mainline 7.0, commit r245460 on 2017-02-14.

Commit  r245460 needs to be back ported to GCC 5 and GCC 6.

[Bug c/79546] New: Strange error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]

2017-02-15 Thread rjones at redhat dot com

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

Bug ID: 79546
   Summary: Strange error: missed loop optimization, the loop
counter may overflow
[-Werror=unsafe-loop-optimizations]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

#include 
#include 

int f (size_t len);

int
main (int argc, char *argv[])
{
  size_t len;

  if (argc < 2) abort ();
  if (sscanf (argv[1], "%zu", ) != 1) abort ();

  f (len);

  exit (0);
}

int
f (size_t len)
{
  size_t i;

  i = 0;
  while (i < len) {
i += 0x1000;
printf ("page %zu\n", i);
  }
}
---

When compiled with:

$ gcc -O2 -Werror=unsafe-loop-optimizations test.c -o test
test.c: In function ‘main’:
test.c:25:9: error: missed loop optimization, the loop counter may overflow
[-Werror=unsafe-loop-optimizations]
   while (i < len) {
 ^
test.c: In function ‘f’:
test.c:25:9: error: missed loop optimization, the loop counter may overflow
[-Werror=unsafe-loop-optimizations]
   while (i < len) {
 ^
cc1: some warnings being treated as errors

---

What I don't understand is what the error means, nor how to correct it.

---

$ gcc --version
gcc (GCC) 7.0.1 20170204 (Red Hat 7.0.1-0.6)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

From Fedora 26.

[Bug target/79545] New: gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type

2017-02-15 Thread carll at gcc dot gnu.org

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

Bug ID: 79545
   Summary: gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines
have wrong type
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carll at gcc dot gnu.org
  Target Milestone: ---

The following issue was found in gcc 6.1.  It also exists in gcc5.4.

The source and return operand types for xvcvuxdsp and xvcvsxdsp instructions
do not match the instruction definitions from the Power ISA document.  The
current code expects a V2DF source and returns V4SI.  The two instructions
should take a V2DI source and return V4SF.

Additionally, there is a typo in the instruction generation for the xvcvuxdsp
instruction generates instruction xvcvuxwdp instead of xvcvuxdsp.  The issues
are in file gcc/config/rs6000/vsx.md for define_insn "vsx_xvcvsxdsp" and 
define_insn "vsx_xvcvuxdsp" RTL statements.

[Bug middle-end/4210] should not warning with dead code

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

--- Comment #25 from Paul Eggert  ---
I'd like this bug to be changed from SUSPENDED to CONFIRMED, given that it's
continuing to be a problem (e.g., bug#79479).

Also, I'd like to suggest what I hope is a simple fix. In 2006 Joseph wrote
"skip_evaluation can't be set for if (0) because you can jump into if (0),
whereas jumps into statement expressions are not permitted". So, how about if
we merely set skip_evaluation for "if (0)" when the then-part lacks labels?
This should be an easy test, as it shouldn't require parsing the whole function
body. The test might still generate false alarms for code containing gotos, but
in practice such gotos are rare, so the proposed change should be a significant
improvement even if it's not perfect.

[Bug c++/78572] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4968

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c/79479] -Woverflow false alarm in unreachable expression

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

--- Comment #14 from Paul Eggert  ---
Thanks, please feel free to mark this as a duplicate of Bug#4210. I plan to
follow up there.

[Bug tree-optimization/79345] [6/7 Regression] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

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

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |tree-optimization

--- Comment #4 from Jason Merrill  ---
Changing component since this seems to be a tree-ssa-uninit.c issue.

Re: [gomp4] adjust num_gangs and add a diagnostic for unsupported num_workers

2017-02-15 Thread Thomas Schwinge

Hi Cesar!

On Mon, 13 Feb 2017 08:58:39 -0800, Cesar Philippidis  
wrote:
> This patch does the followings:
> 
>  * Adjusts the default num_gangs to utilize more of GPU hardware.
>  * Teach libgomp to emit a diagnostic when num_workers isn't supported.
> 
> [...]

Thanks!

> This patch has been applied to gomp-4_0-branch.

For easier review, I'm quoting here your r245393 commit with whitespace
changes ignored:

> --- libgomp/plugin/plugin-nvptx.c
> +++ libgomp/plugin/plugin-nvptx.c
> @@ -917,10 +918,15 @@ nvptx_exec (void (*fn), size_t mapnum, void 
> **hostaddrs, void **devaddrs,
>   seen_zero = 1;
>  }
>  
> -  if (seen_zero)
> -{
> -  /* See if the user provided GOMP_OPENACC_DIM environment
> -  variable to specify runtime defaults. */
> +  /* Both reg_granuarlity and warp_granuularity were extracted from
> + the "Register Allocation Granularity" in Nvidia's CUDA Occupancy
> + Calculator spreadsheet.  Specifically, this required SM_30+
> + targets.  */
> +  const int reg_granularity = 256;

That is per warp, so a granularity of 256 / 32 = 8 registers per thread.
(Would be strange otherwise.)

> +  const int warp_granularity = 4;
> +
> +  /* See if the user provided GOMP_OPENACC_DIM environment variable to
> + specify runtime defaults. */
>static int default_dims[GOMP_DIM_MAX];
>  
>pthread_mutex_lock (_dev_lock);
> @@ -952,25 +958,30 @@ nvptx_exec (void (*fn), size_t mapnum, void 
> **hostaddrs, void **devaddrs,
>CUdevice dev = nvptx_thread()->ptx_dev->dev;
>/* 32 is the default for known hardware.  */
>int gang = 0, worker = 32, vector = 32;
> -   CUdevice_attribute cu_tpb, cu_ws, cu_mpc, cu_tpm;
> +  CUdevice_attribute cu_tpb, cu_ws, cu_mpc, cu_tpm, cu_rf, cu_sm;
>  
>cu_tpb = CU_DEVICE_ATTRIBUTE_MAX_THREADS_PER_BLOCK;
>cu_ws = CU_DEVICE_ATTRIBUTE_WARP_SIZE;
>cu_mpc = CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT;
>cu_tpm  = CU_DEVICE_ATTRIBUTE_MAX_THREADS_PER_MULTIPROCESSOR;
> +  cu_rf  = CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR;
> +  cu_sm  = CU_DEVICE_ATTRIBUTE_MAX_SHARED_MEMORY_PER_MULTIPROCESSOR;
>  
>if (cuDeviceGetAttribute (_size, cu_tpb, dev) == CUDA_SUCCESS
> && cuDeviceGetAttribute (_size, cu_ws, dev) == CUDA_SUCCESS
> && cuDeviceGetAttribute (_size, cu_mpc, dev) == CUDA_SUCCESS
> -   && cuDeviceGetAttribute (_size, cu_tpm, dev)  == CUDA_SUCCESS)
> +   && cuDeviceGetAttribute (_size, cu_tpm, dev) == CUDA_SUCCESS
> +   && cuDeviceGetAttribute (_size, cu_rf, dev)  == CUDA_SUCCESS
> +   && cuDeviceGetAttribute (_size, cu_sm, dev)  == CUDA_SUCCESS)

Trying to compile this on CUDA 5.5/331.113, I run into:

[...]/source-gcc/libgomp/plugin/plugin-nvptx.c: In function 'nvptx_exec':
[...]/source-gcc/libgomp/plugin/plugin-nvptx.c:970:16: error: 
'CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR' undeclared (first use in 
this function)
   cu_rf  = CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR;
^~~~
[...]/source-gcc/libgomp/plugin/plugin-nvptx.c:970:16: note: each 
undeclared identifier is reported only once for each function it appears in
[...]/source-gcc/libgomp/plugin/plugin-nvptx.c:971:16: error: 
'CU_DEVICE_ATTRIBUTE_MAX_SHARED_MEMORY_PER_MULTIPROCESSOR' undeclared (first 
use in this function)
   cu_sm  = CU_DEVICE_ATTRIBUTE_MAX_SHARED_MEMORY_PER_MULTIPROCESSOR;
^~~~

For reference, please see the code handling
CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR in the trunk version
of the nvptx_open_device function.

And then, I don't specifically have a problem with discontinuing CUDA 5.5
support, and require 6.5, for example, but that should be a conscious
decision.

> @@ -980,8 +991,6 @@ nvptx_exec (void (*fn), size_t mapnum, void **hostaddrs, 
> void **devaddrs,
>matches the hardware configuration.  Logical gangs are
>scheduled onto physical hardware.  To maximize usage, we
>should guess a large number.  */
> -   if (default_dims[GOMP_DIM_GANG] < 1)
> - default_dims[GOMP_DIM_GANG] = gang ? gang : 1024;

That's "bad", because a non-zero "default_dims[GOMP_DIM_GANG]" (also
known as "default_dims[0]") is used to decide whether to enter this whole
code block, and with that assignment removed, every call of the
nvptx_exec function will now re-do all this GOMP_OPENACC_DIM parsing,
cuDeviceGetAttribute calls, computations, and so on.  (See "GOMP_DEBUG=1"
output.)

I think this whole code block should be moved into the nvptx_open_device
function, to have it executed once when the device is opened -- after
all, all these are per-device attributes.  (So, it's actually
conceptually incorrect to have this done only once in the nvptx_exec
function, given that this data then is used in the same

[Bug c++/69564] [5/6/7 Regression] lto and/or C++ make scimark2 LU slower

2017-02-15 Thread law at redhat dot com

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

--- Comment #29 from Jeffrey A. Law  ---
So to bring this BZ back to the core questions (the scope seems to have widened
through the year since this originally reported).  Namely are the use of LTO or
C++ making things slower, particularly for scimark's LU factorization test.

>From my experiments, the answer is a very clear yes. I hacked up the test a bit
to only run LU and run a fixed number of iterations.  That makes comparisons
with something like callgrind much easier. 

Use of C++ adds 2-3% in terms of instruction counts.  LTO adds an additional
2-3% to the instruction counts.  These are additive, C++ with LTO is about 5%
higher than C without LTO.

The time (not surprisingly) is lost in LU_factor, the main culprit seems to be
this pair of nested loops:

   int ii;
for (ii=j+1; ii

[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

2017-02-15 Thread wschmidt at gcc dot gnu.org

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

--- Comment #1 from Bill Schmidt  ---
Note that this is indeed wrong because the semantics of vec_sra are to
duplicate the sign bit even for unsigned inputs.

[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

2017-02-15 Thread wschmidt at gcc dot gnu.org

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||wrong-code
Version|unknown |7.0
   Target Milestone|--- |7.0

[Bug target/79544] New: vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

2017-02-15 Thread willschm at gcc dot gnu.org

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

Bug ID: 79544
   Summary: vec_sra (unsigned long long,foo) generating vsrd
instead of vsrad
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40756=edit
sample test

Noticed that vec_sra is generating a vsrd instruction rather than the expected
vsrad instruction when using "unsigned long long" parameter.   

>   #include 
>   vector unsigned long long
>   test6_sra (vector unsigned long long x, vector unsigned long long y)
>   {
> return vec_sra (x, y);
>   }

> #> gcc -c testme_sra.c  -S -mvsx -O3 

> #> grep -A 3 test6_sra: testme_sra.s
> test6_sra:
>   vsrd 2,2,3
>   blr
>   .long 0

vec_sra() against char,short,int appear OK. 

Seeing this on trunk (20170208) as well as older distro supplied compilers. 

test attached.

[Bug rtl-optimization/78127] [5/6/7 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440

2017-02-15 Thread vmakarov at gcc dot gnu.org

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Vladimir Makarov  ---
I've reproduced it and started to work on it.  I think the fix will be ready on
this week.

[Bug c++/79363] [6 Regression] ICE with NSDMI and array

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |NSDMI and array |NSDMI and array

--- Comment #5 from Martin Sebor  ---
Fixed on trunk via r245494.

[Bug c++/79050] [5/6/7 Regression] ICE: tree code 'template_type_parm' is not supported in LTO streams

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/79464] [7 Regression] ICE in ipa_modify_formal_ parameters

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Feb 15 20:29:08 2017
New Revision: 245495

URL: https://gcc.gnu.org/viewcvs?rev=245495=gcc=rev
Log:
PR c++/79464 - ICE in IPA with omitted constructor parms

* class.c (build_clone): Also omit parms from TYPE_ARG_TYPES.
(adjust_clone_args): Adjust.
(add_method): Remember omitted parms.
* call.c (add_function_candidate): Likewise.
* mangle.c (write_method_parms): Likewise.
* method.c (ctor_omit_inherited_parms): Return false if there are no
parms to omit.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/class.c
trunk/gcc/cp/mangle.c
trunk/gcc/cp/method.c
trunk/gcc/testsuite/g++.dg/cpp1z/inh-ctor23.C

[Bug c++/79464] [7 Regression] ICE in ipa_modify_formal_ parameters

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/79363] [6/7 Regression] ICE with NSDMI and array

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Wed Feb 15 20:28:32 2017
New Revision: 245494

URL: https://gcc.gnu.org/viewcvs?rev=245494=gcc=rev
Log:
PR c++/79363 - ICE with NSDMI and array

gcc/cp/ChangeLog:

PR c++/79363
* init.c (maybe_reject_flexarray_init): New function.
(perform_member_init): Call it.

gcc/testsuite/ChangeLog:

PR c++/79363
* g++.dg/ext/flexary12.C: Adjust.
* g++.dg/ext/flexary20.C: Same.
* g++.dg/ext/flexary21.C: Same.
* g++.dg/ext/flexary22.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ext/flexary22.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/flexary12.C
trunk/gcc/testsuite/g++.dg/ext/flexary20.C
trunk/gcc/testsuite/g++.dg/ext/flexary21.C

C++ PATCH for c++/79464 (ICE in IPA with inherited ctor)

2017-02-15 Thread Jason Merrill

In the new inherited constructor framework, base inheriting
constructor variants don't retain the parameters inherited from a
virtual base constructor, since that constructor won't actually be
called from there; it will be called directly by the complete object
constructor.

Previously, I had cut off DECL_ARGUMENTS and the argument list, but
left these omitted parameters in TYPE_ARG_TYPES.  This constituted
lying to the compiler, and it got its revenge.

This patch also removes the omitted parameters from TYPE_ARG_TYPES,
and then adjusts overloading and mangling to refer to the parameters
from the maybe-in-charge variant instead.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d133cc9358be1b81147584b37a85ba58a5027d24
Author: Jason Merrill 
Date:   Tue Feb 14 12:25:06 2017 -0500

PR c++/79464 - ICE in IPA with omitted constructor parms

* class.c (build_clone): Also omit parms from TYPE_ARG_TYPES.
(adjust_clone_args): Adjust.
(add_method): Remember omitted parms.
* call.c (add_function_candidate): Likewise.
* mangle.c (write_method_parms): Likewise.
* method.c (ctor_omit_inherited_parms): Return false if there are no
parms to omit.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 718438c..154509b 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -2005,7 +2005,11 @@ add_function_candidate (struct z_candidate **candidates,
  considered in overload resolution.  */
   if (DECL_CONSTRUCTOR_P (fn))
 {
-  parmlist = skip_artificial_parms_for (fn, parmlist);
+  if (ctor_omit_inherited_parms (fn))
+   /* Bring back parameters omitted from an inherited ctor.  */
+   parmlist = FUNCTION_FIRST_USER_PARMTYPE (DECL_ORIGIN (fn));
+  else
+   parmlist = skip_artificial_parms_for (fn, parmlist);
   skip = num_artificial_parms_for (fn);
   if (skip > 0 && first_arg != NULL_TREE)
{
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 7ec07c9..1442b55 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1149,6 +1149,12 @@ add_method (tree type, tree method, tree using_decl)
   if (! DECL_STATIC_FUNCTION_P (method))
parms2 = TREE_CHAIN (parms2);
 
+  /* Bring back parameters omitted from an inherited ctor.  */
+  if (ctor_omit_inherited_parms (fn))
+   parms1 = FUNCTION_FIRST_USER_PARMTYPE (DECL_ORIGIN (fn));
+  if (ctor_omit_inherited_parms (method))
+   parms2 = FUNCTION_FIRST_USER_PARMTYPE (DECL_ORIGIN (method));
+
   if (compparms (parms1, parms2)
  && (!DECL_CONV_FN_P (fn)
  || same_type_p (TREE_TYPE (fn_type),
@@ -4761,6 +4767,10 @@ build_clone (tree fn, tree name)
DECL_VINDEX (clone) = NULL_TREE;
 }
 
+  bool ctor_omit_inherited_parms_p = ctor_omit_inherited_parms (clone);
+  if (ctor_omit_inherited_parms_p)
+gcc_assert (DECL_HAS_IN_CHARGE_PARM_P (clone));
+
   /* If there was an in-charge parameter, drop it from the function
  type.  */
   if (DECL_HAS_IN_CHARGE_PARM_P (clone))
@@ -4780,8 +4790,12 @@ build_clone (tree fn, tree name)
   if (DECL_HAS_VTT_PARM_P (fn)
  && ! DECL_NEEDS_VTT_PARM_P (clone))
parmtypes = TREE_CHAIN (parmtypes);
-   /* If this is subobject constructor or destructor, add the vtt
-parameter.  */
+  if (ctor_omit_inherited_parms_p)
+   {
+ /* If we're omitting inherited parms, that just leaves the VTT.  */
+ gcc_assert (DECL_NEEDS_VTT_PARM_P (clone));
+ parmtypes = tree_cons (NULL_TREE, vtt_parm_type, void_list_node);
+   }
   TREE_TYPE (clone)
= build_method_type_directly (basetype,
  TREE_TYPE (TREE_TYPE (clone)),
@@ -4818,7 +4832,7 @@ build_clone (tree fn, tree name)
 
   /* A base constructor inheriting from a virtual base doesn't get the
  arguments.  */
-  if (ctor_omit_inherited_parms (clone))
+  if (ctor_omit_inherited_parms_p)
 DECL_CHAIN (DECL_CHAIN (DECL_ARGUMENTS (clone))) = NULL_TREE;
 
   for (parms = DECL_ARGUMENTS (clone); parms; parms = DECL_CHAIN (parms))
@@ -4965,6 +4979,13 @@ adjust_clone_args (tree decl)
   decl_parms = TREE_CHAIN (decl_parms),
 clone_parms = TREE_CHAIN (clone_parms))
{
+ if (clone_parms == void_list_node)
+   {
+ gcc_assert (decl_parms == clone_parms
+ || ctor_omit_inherited_parms (clone));
+ break;
+   }
+
  gcc_assert (same_type_p (TREE_TYPE (decl_parms),
   TREE_TYPE (clone_parms)));
 
@@ -4999,7 +5020,7 @@ adjust_clone_args (tree decl)
  break;
}
}
-  gcc_assert (!clone_parms);
+  gcc_assert (!clone_parms || clone_parms == void_list_node);
 }
 }
 
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 3ead33e..8b30f42 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -2740,6 +2740,10 @@ write_method_parms

[PATCH v4] aarch64: Add split-stack initial support

2017-02-15 Thread Adhemerval Zanella

This is an update patch from my previous version (v3) based mainly on
glibc comments on exported loader symbol [1].  The changes from previous
version are:

   - Remove __tcb_private_ss call on libgcc and emit a data usage on
 glibc symbol when split-stack is used.  This removes the runtime
 errors when running on older glibc and instead make the loader
 fails with a missing symbol.

   - Add glibc version check on split-stack support check.

   - Some comments fixes on morestack.S.

   - Remove some compile warnings on morestack-c.c.

--

This patch adds the split-stack support on aarch64 (PR #67877).  As for
other ports this patch should be used along with glibc and gold support.

The support is done similar to other architectures: a split-stack field
is allocated before TCB by glibc, a target-specific __morestack implementation
and helper functions are added in libgcc and compiler supported in adjusted
(split-stack prologue, va_start for argument handling).  I also plan to
send the gold support to adjust stack allocation acrosss split-stack
and default code calls.

Current approach is to set the final stack adjustments using a 2 instructions
at most (mov/movk) which limits stack allocation to upper limit of 4GB.
The morestack call is non standard with x10 hollding the requested stack
pointer, x11 the argument pointer (if required), and x12 to return
continuation address.  Unwinding is handled by a personality routine that
knows how to find stack segments.

Split-stack prologue on function entry is as follow (this goes before the
usual function prologue):

function:
mrsx9, tpidr_el0
movx10, 
movk   x10, #0x0, lsl #16
subx10, sp, x10
movx11, sp  # if function has stacked arguments
adrp   x12, main_fn_entry
addx12, x12, :lo12:.L2
cmpx9, x10
b.lt   
b  __morestack
main_fn_entry:
[function prologue]

Notes:

1. Even if a function does not allocate a stack frame, a split-stack prologue
   is created.  It is to avoid issues with tail call for external symbols
   which might require linker adjustment (libgo/runtime/go-varargs.c).

2. Basic-block reordering (enabled with -O2) will move split-stack TCB ldr
   to after the required stack calculation.

3. Similar to powerpc, When the linker detects a call from split-stack to
   non-split-stack code, it adds 16k (or more) to the value found in "allocate"
   instructions (so non-split-stack code gets a larger stack).  The amount is
   tunable by a linker option.  The edit means aarch64 does not need to
   implement __morestack_non_split, necessary on x86 because insufficient
   space is available there to edit the stack comparison code.  This feature
   is only implemented in the GNU gold linker.

4. AArch64 does not handle >4G stack initially and although it is possible
   to implement it, limiting to 4G allows to materize the allocation with
   only 2 instructions (mov + movk) and thus simplifying the linker
   adjustments required.  Supporting multiple threads each requiring more
   than 4G of stack is probably not that important, and likely to OOM at
   run time.

5. The TCB support on GLIBC is meant to be included in version 2.26.

6. The continuation address materialized on x12 is done using 'adrp'
   plus add and a static relocation.  Current code uses the
   aarch64_expand_mov_immediate function and since a better alternative
   would be 'adp', it could be a future optimization (not implemented
   in this patch).

[1] https://sourceware.org/ml/libc-alpha/2017-02/msg00272.html

libgcc/ChangeLog:

* libgcc/config.host: Use t-stack and t-statck-aarch64 for
aarch64*-*-linux.
* libgcc/config/aarch64/morestack-c.c: New file.
* libgcc/config/aarch64/morestack.S: Likewise.
* libgcc/config/aarch64/t-stack-aarch64: Likewise.
* libgcc/generic-morestack.c (__splitstack_find): Add aarch64-specific
code.

gcc/ChangeLog:

* common/config/aarch64/aarch64-common.c
(aarch64_supports_split_stack): New function.
(TARGET_SUPPORTS_SPLIT_STACK): New macro.
* gcc/config/aarch64/aarch64-linux.h (TARGET_ASM_FILE_END): Remove
macro.
* gcc/config/aarch64/aarch64-protos.h: Add
aarch64_expand_split_stack_prologue and
aarch64_split_stack_space_check.
* gcc/config/aarch64/aarch64.c (aarch64_gen_far_branch): Add suport
to emit 'b' instruction to rtx different than LABEL_REF.
(aarch64_expand_builtin_va_start): Use internal argument pointer
instead of virtual_incoming_args_rtx.
(morestack_ref): New symbol.
(aarch64_load_split_stack_value): New function.
(aarch64_expand_split_stack_prologue): Likewise.
(aarch64_internal_arg_pointer): Likewise.
(aarch64_split_stack_space_check): Likewise.
(aarch64_file_end): Emit the split-stack note sections.

Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)

2017-02-15 Thread Jason Merrill

OK.

On Wed, Feb 15, 2017 at 12:30 PM, Jakub Jelinek  wrote:
> On Wed, Feb 15, 2017 at 11:56:30AM -0500, Jason Merrill wrote:
>> On Tue, Feb 14, 2017 at 3:13 PM, Jakub Jelinek  wrote:
>> > The following testcase fails, because while we have the nodiscard
>> > attribute on the template, we actually never propagate it to the
>> > instantiation, which is where it is checked (I'm really surprised about
>> > this).
>>
>> Normally we propagate attributes when instantiating the class; see the
>> call to apply_late_template_attributes in
>> instantiate_class_template_1.  I'm not sure why that wouldn't be
>
> Yes, instantiate_class_template_1 calls apply_late_template_attributes,
> but that actually does nothing if there are no dependent attributes.
> If there are any, it sets TYPE_ATTRIBUTES (or DECL_ATTRIBUTES) to
> a copy of the attributes list, removes all the dependent attributes
> from there and calls cplus_decl_attributes on the late attrs (after
> tsubst_attribute them).  So setting {TYPE,DECL}_ATTRIBUTES to the
> attributes list unmodified if there are no dependent ones matches
> the behavior for non-dependent ones if there is at least one dependent.
>
> So, does the following patch look better?
>
> 2017-02-15  Jakub Jelinek  
>
> PR c++/79502
> * pt.c (apply_late_template_attributes): If there are
> no dependent attributes, set *p to attributes.
>
> * g++.dg/cpp1z/nodiscard4.C: New test.
>
> --- gcc/cp/pt.c.jj  2017-02-14 09:23:49.0 +0100
> +++ gcc/cp/pt.c 2017-02-15 18:21:45.581055915 +0100
> @@ -10113,6 +10113,8 @@ apply_late_template_attributes (tree *de
>
>cplus_decl_attributes (decl_p, late_attrs, attr_flags);
>  }
> +  else
> +*p = attributes;
>  }
>
>  /* Perform (or defer) access check for typedefs that were referenced
> --- gcc/testsuite/g++.dg/cpp1z/nodiscard4.C.jj  2017-02-15 18:11:33.281135469 
> +0100
> +++ gcc/testsuite/g++.dg/cpp1z/nodiscard4.C 2017-02-15 18:11:33.281135469 
> +0100
> @@ -0,0 +1,14 @@
> +// PR c++/79502
> +// { dg-do compile { target c++11 } }
> +
> +template
> +struct [[nodiscard]] missiles {};
> +
> +missiles make() { return {}; }
> +missiles (*fnptr)() = make;
> +
> +int main()
> +{
> +  make();  // { dg-warning "ignoring returned value of type" }
> +  fnptr(); // { dg-warning "ignoring returned value of type" }
> +}
>
>
> Jakub

Re: Doc question: is "templatized" a word?

2017-02-15 Thread Jason Merrill

On Wed, Feb 15, 2017 at 1:57 PM, Jonathan Wakely  wrote:
> On 15 February 2017 at 15:53, Jason Merrill wrote:
>> On Sat, Feb 11, 2017 at 4:19 PM, Jonathan Wakely  
>> wrote:
>>> On 11 February 2017 at 20:36, Sandra Loosemore wrote:
 On 02/11/2017 06:21 AM, Jonathan Wakely wrote:
>
> On 11 February 2017 at 08:48, Gerald Pfeifer wrote:
>>
>> On Fri, 10 Feb 2017, Sandra Loosemore wrote:
>>>
>>> The documentation for -Wno-non-template-friend refers to
>>> "non-templatized
>>> friend functions" and "templatized functions".  I don't see the term
>>> "templatized" used anywhere in the C++ standard.  This paragraph also
>>> uses
>>> "nontemplate function", which I assume refers to the same thing the C++
>>> standard spells "non-template function".  So does "non-templatized
>>> function"
>>> also mean "non-template function"?  Or does it have some other meaning?
>>
>>
>> I would avoid "templatized" and believe "non-template function" is
>> more appropriate in your example.
>
>
> Yes,
>
> s/non-templatized/non-template/
> s/nontemplate/non-template/
> s/templatized function/function template/
>
> But I wonder if that warning is even useful nowadays. The example of
> "friend foo(int);" is bogus and is correctly rejected:
>
> fr.cc:2:17: error: ISO C++ forbids declaration of ‘foo’ with no type
> [-fpermissive]
> friend foo(int);
>   ^


 I hadn't actually gotten that far :-) but it looks like that's an
 implicit-int error unrelated to the actual purpose of this option.

 This ended up on my todo list firstly because "templatized" didn't
 spell-check, and secondly because the "new compiler behavior" documented in
 connection with this option has existed at least since 1998 and can hardly
 be considered "new" any more.  Also I think the reference to section 14.5.3
 of the C++ standard is bit-rotten (it's 14.5.4 in the c++0x draft I have
 handy).

 I'll leave it up to the C++ experts to decide whether the option should 
 just
 be removed and the warning replaced with a hard error controlled by some
 other flag.
>>>
>>> It definitely shouldn't be turned into a hard error, the warning
>>> complains about valid code, such as:
>>>
>>> template struct A {
>>>   friend int foo(T);
>>> };
>>>
>>> int main() {
>>>   A a;
>>> }
>>>
>>> I think it warns because the meaning of that code changed, a *long*
>>> time ago, so it's saying "if you wrote this code in the 1990s it might
>>> do something different to what you expect."
>>>
>>> I'm not sure how useful that warning is now, although EDG warns for it
>>> too (with a fix-it hint that I think is bogus):
>>>
>>> "fr.cc", line 2: warning: "int foo(T)" declares a non-template function -- 
>>> add
>>>   <> to refer to a template instance
>>> friend int foo(T);
>>>^
>>
>> That fix-it looks fine to me;
>
> Where should I add the <> to make it valid?
>
> If I change the example to "friend int foo<>(T);" EDG says it's not a 
> template:
>
> template struct A {
>   friend int foo<>(T);
> };
>
> int main() {
>   A a;
> }
>
> "fr.cc", line 2: error: foo is not a template
> friend int foo<>(T);

Yep, you would also need to declare the foo template earlier in the TU.

Jason

[Bug middle-end/32003] Undocumented -fdump-tree options

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

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Wed Feb 15 20:13:11 2017
New Revision: 245493

URL: https://gcc.gnu.org/viewcvs?rev=245493=gcc=rev
Log:
2017-02-15  Martin Sebor  

PR middle-end/32003
* doc/invoke.texi (-fdump-final-insns): Replace option accidentally
removed in a prior commit.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

Re: [PATCH doc] clean up -fdump-tree- options (PR 32003)

2017-02-15 Thread Martin Sebor


On 02/15/2017 05:51 AM, Thomas Schwinge wrote:

Hi!

On Wed, 1 Feb 2017 20:26:24 -0700, Martin Sebor  wrote:

On 02/01/2017 08:06 PM, Sandra Loosemore wrote:

On 02/01/2017 06:57 PM, Martin Sebor wrote:

PR middle-end/32003
* doc/invoke.texi (-fdump-rtl-): Remove pass-specific options from
index.


"rtl" vs. "tree" typo.  ;-)


--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -544,29 +544,9 @@ Objective-C and Objective-C++ Dialects}.
 -fdump-rtl-@var{pass}  -fdump-rtl-@var{pass}=@var{filename} @gol
 -fdump-statistics @gol
 -fdump-tree-all @gol
--fdump-tree-original@r{[}-@var{n}@r{]}  @gol
-[...]
--fdump-tree-storeccp@r{[}-@var{n}@r{]} @gol
--fdump-final-insns=@var{file} @gol


Is it intentional that you've also removed "-fdump-final-insns" here?
(It remains documented further down the file.)


No, I meant to only remove the -fdump-tree-xxx options in this pass.
I committed r245493 to restore it and fix the ChangeLog.  Thanks for
the review and for pointing it out!

Martin

DWARF Version 5 Standard Released

2017-02-15 Thread Michael Eager

The DWARF Debugging Information Format Standards Committee is pleased to announce the availability
of Version 5 of the DWARF Debugging Format Standard. The DWARF Debugging Format is used to
communicate debugging information between a compiler and debugger to make it easier for programmers
to develop, test, and debug programs.

DWARF is used by a wide range of compilers and debuggers, both proprietary and open source, to
support debugging of Ada, C, C++, Cobol, FORTRAN, Java, and other programming languages. DWARF V5
adds support for new languages like Rust, Swift, Ocaml, Go, and Haskell, as well as support for new
features in older languages. DWARF can be used with a wide range of processor architectures, such as
x86, ARM, PowerPC, from 8-bit to 64-bit.

DWARF is the standard debugging format for Linux and several versions of Unix and is widely used
with embedded processors. DWARF is designed to be extended easily to support new languages and new
architectures.

The DWARF Version 5 Standard has been in development for six years. DWARF Committee members include
representatives from over a dozen major companies with extensive experience in compiler and debugger
development. Version 5 incorporates improvements in many areas: better data compression, separation
of debugging data from executable files, improved description of macros and source files, faster
searching for symbols, improved debugging of optimized code, as well as numerous improvements in
functionality and performance.

The DWARF Version 5 Standard can be downloaded without charge from the DWARF website (dwarfstd.org).
Additional information about DWARF, including how to subscribe to the DWARF mailing list, can also
be found on the website. Questions about the DWARF Debugging Information Format or the DWARF
Committee can be directed to the DWARF Committee Chair, Michael Eager at i...@dwarfstd.org.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

Re: [PATCH][RFA][target/79404] Fix uninitialized reference to ira_register_move_cost[mode]

2017-02-15 Thread Jeff Law


On 02/15/2017 12:42 PM, Gerald Pfeifer wrote:

Hi Jeff,

On Mon, 13 Feb 2017, Jeff Law wrote:

I've verified this allows libgcc to build on the H8 target and
bootstrapped/regression tested the change on x86_64-unknown-linux-gnu
as well.


I need to reproduce this, but my latest daily bootstrap on
i386-unknown-freebsd10.3 failed with...

.../gerald/gcc-HEAD/libquadmath/math/remainderq.c: In function
'remainderq':
.../gerald/gcc-HEAD/libquadmath/math/remainderq.c:67:1: internal
compiler error: in ira_init_register_move_cost, at ira.c:1580

...and your message was the only one on gcc-patches the last couple
of days that contains the string "ira_init_register_move_cost".

Not sure yet that it's your patch, but this looks a little bit like a
smoking gun... :-)

Already testing a fix.

jeff

[Bug c/79479] -Woverflow false alarm in unreachable expression

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #13 from Martin Sebor  ---
The false positives/negatives I'm concerned about would result from moving the
warning from the front-end to the middle-end.  This would be necessary to
handle some of the non-trivial cases I mentioned in comment #11.  In the
front-end the warning only sees as far as the end of a full expression.  The
front-end does no data flow analysis beyond attempting to evaluate expressions.

In the middle-end, to expose dependencies between statements (such as the
dependency of expr on cond in "if (cond) { expr; }" the warning would depend on
various transformations done by optimization passes (such as constant
propagation and dead code elimination).  Some of these transformations could
also simplify or remove expressions that involve constant overflows, leading to
false negatives, and others could introduce them even though they didn't exist
in the original code (e.g., along new code paths that may never be even
executed), causing false positives.

Bugs certainly should be raised for these problems (and many have been) but
because of the complex interactions between the transformations they tend to be
quite difficult to fix, and some can't be fixed at all.  The net result would
be a trade-off between one set of fairly simple bugs or complaints vs another,
much more complex bugs.  There are a number of examples of these trade-offs in
Bugzilla with even more discussion on gcc-patches.  This doesn't mean that
warnings shouldn't be implemented in the middle-end, just that they aren't
going to be perfect there either, or make everyone happy (in fact, simple
warnings like -Woverflow tend to be less controversial than data flow warnings
because they are for the most part decidable.)

In any case, since bug 4210 already tracks the enhancement you would like to
see I propose to close this as a duplicate of that bug.  Please let me know if
you disagree, otherwise I'll go ahead and resolve it as such.

Re: [gomp4] Async related additions to OpenACC runtime library

2017-02-15 Thread Thomas Schwinge

Hi!

On Tue, 14 Feb 2017 19:58:11 +0800, Chung-Lin Tang  
wrote:
> On 2017/2/14 07:25 PM, Thomas Schwinge wrote:
> > Testing [...], I saw a lot of regressions,
> > and in r245427 just committed [...] to address
> > these.  Did you simply forget to commit your changes to
> > libgomp/libgomp.map, or why did this work for you?  Please verify:
> 
> Weird, I did not see any regressions

We figured it out; I just filed 
'Inappropriate "ld --version" checking'.


Grüße
 Thomas

[Bug other/79543] New: Inappropriate "ld --version" checking

2017-02-15 Thread tschwinge at gcc dot gnu.org

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

Bug ID: 79543
   Summary: Inappropriate "ld --version" checking
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org
  Target Milestone: ---

libgomp (and, from a quick scan, also other places of GCC/other target
libraries) conditionally use certain linker features, depending on linker
version numbers.  For example, linker version scripts in libgomp; see
LIBGOMP_BUILD_VERSIONED_SHLIB, LIBGOMP_BUILD_VERSIONED_SHLIB_GNU usage in
libgomp/Makefile.am, which are defined in libgomp/acinclude.m4 based on the
enable_symvers value, which is set by some logic depending on "ld --version"
output.  Looking at one specific build's libgomp/config.log, I see:

[...]
configure:16132: checking if the linker ([...]/gcc/collect-ld) is GNU ld
configure:16147: result: yes
[...]
configure:16389: WARNING: === Linker version 1125 is too old for
configure:16391: WARNING: === full symbol versioning support in this
release of GCC.
configure:16393: WARNING: === You would need to upgrade your binutils to
version
configure:16395: WARNING: === 21400 or later and rebuild GCC.
configure:16404: WARNING: === Symbol versioning will be disabled.
[...]

Now, what is this "1125" linker version?

$ [...]/gcc/collect-ld --version
GNU ld (Sourcery CodeBench ([...]) Lite 2015.11-[...]) 2.25.51

..., and then apply the "magic" used in libgomp/acinclude.m4 to compute
libgomp_gnu_ld_version:

$ [...]/gcc/collect-ld --version | sed -e 's/GNU gold /GNU ld /;s/GNU ld
version /GNU ld /;s/GNU ld ([^)]*) /GNU ld /;s/GNU ld \([0-9.][0-9.]*\).*/\1/;
q' | awk -F. '{ if (NF<3) $3=0; print ($1*100+$2)*100+$3 }'
1125

"1125" instead of the expected "22551".  That's pretty weird, and I suppose it
may be causing all kinds of "interesting" issues, when using a linker that has
been configured to override/augment its version string?

Joseph told me that "the correct logic for finding the version number is to
take everything after the last space on the first line of the output, as per
the GNU Coding Standards.  (It's possible some very old binutils versions may
not have properly formatted output; my view is that each GCC version should
have a minimum corresponding binutils version, no more than say five years old,
for targets using GNU binutils.)"

Yet better, obviously, would be to not rely on such version-based decisions at
all.

(Hopefully, similar parsing is not also being done for "as --version", or other
tools, and this was just a one-off problem, possibly originally introduced in
libstdc++-v3/acinclude.m4, 15 years ago, and the copied from there to other
target libraries?  I haven't looked in detail.)


(For reference, this is the root cause for the issue reported in
.)

[Bug ada/79542] New: [7.0 regression] GNAT bug box

2017-02-15 Thread reznikmm at gmail dot com

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

Bug ID: 79542
   Summary: [7.0 regression] GNAT bug box
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reznikmm at gmail dot com
  Target Milestone: ---

Created attachment 40754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40754=edit
package body

Here is a reproducer for regression in GCC 7.
The regression was found by fedora project while recompiling packages
with new compiler. gcc 6, gcc 5 works fine with it.

gcc version 7.0.1 20170212 (experimental) (GCC)
Target: x86_64-pc-linux-gnu
Configured with: /work/reznik/gcc/gcc-7-20170212/configure
--enable-languages=ada,c,c++ --prefix=/work/reznik/gcc/install
--disable-multilib

Command line:
gcc -O2 -c -g finite_automatons.adb

Output:
+===GNAT BUG DETECTED==+
| 7.0.1 20170212 (experimental) (x86_64-pc-linux-gnu) GCC error:   |
| in add_gnat_descriptive_type_attribute, at dwarf2out.c:19511 |
| Error detected around finite_automatons.adb:34:8 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

finite_automatons.adb
finite_automatons.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:406

[Bug ada/79542] [7.0 regression] GNAT bug box

2017-02-15 Thread reznikmm at gmail dot com

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

--- Comment #1 from Maxim Reznik  ---
Created attachment 40755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40755=edit
package spec

[Bug rtl-optimization/79541] New: lra reads uninitialized memory (with invalid input)

2017-02-15 Thread bernds at gcc dot gnu.org

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

Bug ID: 79541
   Summary: lra reads uninitialized memory (with invalid input)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernds at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40753=edit
Reproducer

Disclaimer: I'm uncertain how severe this is: the test program contains an
invalid assembly statement that LRA converts into a nop. If that asm is
corrected, the problem no longer reproduces, and I don't know if the issue
could show up on a legitimate input. I noticed this because an unrelated patch
that should have had no effect on this program caused differences in assembly
output.

Compile the test program as follows, for ppc-linux (I use an x86_64-linux x
ppc-linux cross):

valgrind ./cc1 -O2 sl4.i   -I include 

The following should show up in the output:

==7398== Conditional jump or move depends on uninitialised value(s)
==7398==at 0xCB3791: lra_eliminate_regs_1(rtx_insn*, rtx_def*,
machine_mode, bool, bool, long, bool) (lra-eliminations.c:403)
==7398==by 0xCB4133: lra_eliminate_regs_1(rtx_insn*, rtx_def*,
machine_mode, bool, bool, long, bool) (lra-eliminations.c:642)
==7398==by 0xCC1D71: remove_pseudos(rtx_def**, rtx_insn*)
(lra-spills.c:421)
==7398==by 0xCC1E1F: remove_pseudos(rtx_def**, rtx_insn*)
(lra-spills.c:431)
==7398==by 0xCC2089: spill_pseudos() (lra-spills.c:475)
==7398==by 0xCC27A9: lra_spill() (lra-spills.c:604)
==7398==by 0xC93355: lra(_IO_FILE*) (lra.c:2486)
==7398==by 0xC38FC0: do_reload() (ira.c:5400)
==7398==by 0xC39476: (anonymous namespace)::pass_reload::execute(function*)
(ira.c:5584)
==7398==by 0xD83360: execute_one_pass(opt_pass*) (passes.c:2465)
==7398==by 0xD836C4: execute_pass_list_1(opt_pass*) (passes.c:2554)
==7398==by 0xD836F5: execute_pass_list_1(opt_pass*) (passes.c:2555)

The unitialized memory seems to be the sp_offset field of an insn created by
LRA. The .reload dump should contain a line as follows, with random numbers for
sp_off:

 Choosing alt 5 in insn 266:  (0) m  (1) r {*movsi_internal1}
(sp_off=139971034200304)

Re: [PATCH][RFA][target/79404] Fix uninitialized reference to ira_register_move_cost[mode]

2017-02-15 Thread Gerald Pfeifer


Hi Jeff,

On Mon, 13 Feb 2017, Jeff Law wrote:

I've verified this allows libgcc to build on the H8 target and
bootstrapped/regression tested the change on x86_64-unknown-linux-gnu as well.


I need to reproduce this, but my latest daily bootstrap on
i386-unknown-freebsd10.3 failed with...

.../gerald/gcc-HEAD/libquadmath/math/remainderq.c: In function 'remainderq':
.../gerald/gcc-HEAD/libquadmath/math/remainderq.c:67:1: internal compiler 
error: in ira_init_register_move_cost, at ira.c:1580

...and your message was the only one on gcc-patches the last couple
of days that contains the string "ira_init_register_move_cost".

Not sure yet that it's your patch, but this looks a little bit like 
a smoking gun... :-)


Gerald

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

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

--- Comment #5 from Marek Polacek  ---
This

void fn1 ()
{
  L: goto *&
}

doesn't ICE because we handle the goto here
11406 case GOTO_EXPR:
11407   /* If the target is not LABEL, then it is a computed jump
11408  and the target needs to be gimplified.  */
11409   if (TREE_CODE (GOTO_DESTINATION (*expr_p)) != LABEL_DECL)
11410 {
11411   ret = gimplify_expr (_DESTINATION (*expr_p), pre_p,
11412NULL, is_gimple_val, fb_rvalue);

notice the fb_rvalue, so then we won't reach the switch in Comment 3.

New Spanish PO file for 'gcc' (version 7.1-b20170101)

2017-02-15 Thread Translation Project Robot

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/es.po

(This file, 'gcc-7.1-b20170101.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2017-02-15 Thread danglin at gcc dot gnu.org

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

--- Comment #1 from John David Anglin  ---
Removed comment:

# ./fmt_fw_d.exe
 print '(f2.1)',100.00  ! => : no digits

Program aborted. Backtrace:

[Bug libfortran/79540] New: [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2017-02-15 Thread danglin at gcc dot gnu.org

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

Bug ID: 79540
   Summary: [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90   -O0
execution test
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-hpux*
Target: hppa*-*-hpux*
 Build: hppa*-*-hpux*

spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11
/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_fw_d.f90
-fno-di
agnostics-show-caret -fdiagnostics-color=never -O0 -std=gnu
-B/test/gnu/gcc/objd
ir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux
11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortr
an/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs
-B/test/gn
u/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa
64-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/.
/libquadmath/.libs -lm -o ./fmt_fw_d.exe
PASS: gfortran.dg/fmt_fw_d.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfort
ran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu
/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp
-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc
spawn [open ...]
Program aborted. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
FAIL: gfortran.dg/fmt_fw_d.f90   -O0  execution test

[Bug libstdc++/79114] [6 Regression] std::throw_with_nested("string literal") is rejected

2017-02-15 Thread redi at gcc dot gnu.org

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Wed Feb 15 19:10:43 2017
New Revision: 245492

URL: https://gcc.gnu.org/viewcvs?rev=245492=gcc=rev
Log:
PR libstdc++/79114 use dg-require-atomic-builtins for new test

PR libstdc++/79114
* testsuite/18_support/nested_exception/79114.cc: Add dg-require.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog

[Bug c/79518] __builtin_assume_aligned should mark argument as aligned

2017-02-15 Thread e...@coeus-group.com

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

--- Comment #4 from Evan Nemerson  ---
I agree that GCC's implementation makes more sense, but unfortunately it makes
it hard to write portable code.

I'm not suggesting the current behavior be abandoned, only that
__builtin_assume_aligned be enhanced so the argument is marked as aligned when
possible.

Think of it as an optimization opportunity; given something like

  void* foo = __builtin_assume_aligned(bar, 16);
  /* Use bar for something instead of foo */

GCC could see that bar is 16-byte aligned and generate better code accordingly,
even though the programmer did something dumb.

I won't reopen this, but I hope you will…  AFAICT there aren't any
disadvantages, and it would be very helpful for people with code already
optimized using MSVC, ICC, etc.

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

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

--- Comment #4 from Marek Polacek  ---
I wonder if something like this would be appropriate:

--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -12003,6 +12003,10 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
 gimple_test_f, fallback);
  break;

+   case LABEL_DECL:
+ /* A LABEL_DECL that is FORCED_LABEL.  Skip it.  */
+ break;
+
default:
   /* Anything else with side-effects must be converted to
  a valid statement before we get here.  */

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

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

--- Comment #3 from Marek Polacek  ---
gimplify_expr has code to handle taking the address of a label:
11610 case LABEL_DECL:
11611   /* We get here when taking the address of a label.  We mark
11612  the label as "forced"; meaning it can never be removed and
11613  it is a potential target for any computed goto.  */
11614   FORCED_LABEL (*expr_p) = 1;
11615   ret = GS_ALL_DONE;
11616   break;

but we crash later on in the switch here:

11978   /* We aren't looking for a value, and we don't have a valid
11979  statement.  If it doesn't have side-effects, throw it away.  */
11980   if (!TREE_SIDE_EFFECTS (*expr_p))
11981 *expr_p = NULL;
11982   else if (!TREE_THIS_VOLATILE (*expr_p))
11983 {
11984   /* This is probably a _REF that contains something nested that
11985  has side effects.  Recurse through the operands to find it. 
*/
11986   enum tree_code code = TREE_CODE (*expr_p);

The problem is that the LABEL_DECL L is considered TREE_SIDE_EFFECTS, because
the definition of FORCED_LABEL is:

#define FORCED_LABEL(NODE) (LABEL_DECL_CHECK (NODE)->base.side_effects_flag)

[Bug libstdc++/79539] __polynomial mode lookahead still has an exponential behavior

2017-02-15 Thread timshen at gcc dot gnu.org

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

Tim Shen  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |timshen at gcc dot 
gnu.org

--- Comment #1 from Tim Shen  ---
Assign to myself.

[Bug libstdc++/79539] New: __polynomial mode lookahead still has an exponential behavior

2017-02-15 Thread timshen at gcc dot gnu.org

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

Bug ID: 79539
   Summary:  __polynomial mode lookahead still has an
exponential behavior
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timshen at gcc dot gnu.org
  Target Milestone: ---

Lookahead is implemented in terms of non-memoized recursion, which may have
exponential behavior.

In __polynomial mode, we can add a quadratic memoization to it, making it
O(|state| * |target string|) at worst. It's not linear, but still polynomial.

[Bug libstdc++/79114] [6 Regression] std::throw_with_nested("string literal") is rejected

2017-02-15 Thread redi at gcc dot gnu.org

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

--- Comment #8 from Jonathan Wakely  ---
Ah yes, because throw_with_nested still depends on atomics in gcc-6-branch, and
so we need a dg-require- in the test (but only on the branch). I'll add that.

Re: Doc question: is "templatized" a word?

2017-02-15 Thread Jonathan Wakely

On 15 February 2017 at 15:53, Jason Merrill wrote:
> On Sat, Feb 11, 2017 at 4:19 PM, Jonathan Wakely  
> wrote:
>> On 11 February 2017 at 20:36, Sandra Loosemore wrote:
>>> On 02/11/2017 06:21 AM, Jonathan Wakely wrote:

 On 11 February 2017 at 08:48, Gerald Pfeifer wrote:
>
> On Fri, 10 Feb 2017, Sandra Loosemore wrote:
>>
>> The documentation for -Wno-non-template-friend refers to
>> "non-templatized
>> friend functions" and "templatized functions".  I don't see the term
>> "templatized" used anywhere in the C++ standard.  This paragraph also
>> uses
>> "nontemplate function", which I assume refers to the same thing the C++
>> standard spells "non-template function".  So does "non-templatized
>> function"
>> also mean "non-template function"?  Or does it have some other meaning?
>
>
> I would avoid "templatized" and believe "non-template function" is
> more appropriate in your example.


 Yes,

 s/non-templatized/non-template/
 s/nontemplate/non-template/
 s/templatized function/function template/

 But I wonder if that warning is even useful nowadays. The example of
 "friend foo(int);" is bogus and is correctly rejected:

 fr.cc:2:17: error: ISO C++ forbids declaration of ‘foo’ with no type
 [-fpermissive]
 friend foo(int);
   ^
>>>
>>>
>>> I hadn't actually gotten that far :-) but it looks like that's an
>>> implicit-int error unrelated to the actual purpose of this option.
>>>
>>> This ended up on my todo list firstly because "templatized" didn't
>>> spell-check, and secondly because the "new compiler behavior" documented in
>>> connection with this option has existed at least since 1998 and can hardly
>>> be considered "new" any more.  Also I think the reference to section 14.5.3
>>> of the C++ standard is bit-rotten (it's 14.5.4 in the c++0x draft I have
>>> handy).
>>>
>>> I'll leave it up to the C++ experts to decide whether the option should just
>>> be removed and the warning replaced with a hard error controlled by some
>>> other flag.
>>
>> It definitely shouldn't be turned into a hard error, the warning
>> complains about valid code, such as:
>>
>> template struct A {
>>   friend int foo(T);
>> };
>>
>> int main() {
>>   A a;
>> }
>>
>> I think it warns because the meaning of that code changed, a *long*
>> time ago, so it's saying "if you wrote this code in the 1990s it might
>> do something different to what you expect."
>>
>> I'm not sure how useful that warning is now, although EDG warns for it
>> too (with a fix-it hint that I think is bogus):
>>
>> "fr.cc", line 2: warning: "int foo(T)" declares a non-template function -- 
>> add
>>   <> to refer to a template instance
>> friend int foo(T);
>>^
>
> That fix-it looks fine to me;

Where should I add the <> to make it valid?

If I change the example to "friend int foo<>(T);" EDG says it's not a template:

template struct A {
  friend int foo<>(T);
};

int main() {
  A a;
}

"fr.cc", line 2: error: foo is not a template
friend int foo<>(T);
   ^

1 error detected in the compilation of "edg.cc".

I don't think I understand what this kind of friend declarationdoes,
or what the warning is for, so if you think it's still useful I'm
happy with that :-)

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009