[Bug c++/86431] New: Legal code?

[zhonghao at pku dot org.cn]

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

Bug ID: 86431
   Summary: Legal code?
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

 struct A { 
 static int const B = sizeof B; 
 };

g++ rejects the code:

error: 'B' was not declared in this scope
  static int const B = sizeof B;

The PoD should should be immediately after "B" and before the initializer, as
far as I can see, so this is valid code. BTW, clang++ accepts the code.

[Bug c++/86430] New: ambiguous overload?

[zhonghao at pku dot org.cn]

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

Bug ID: 86430
   Summary: ambiguous overload?
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

// snip
template
struct Const { typedef void const type; };

template
void f(T, typename Const::type*) { } // T1

template
void f(T, void const *) {  } // T2

int main() { void *p = 0; f(0, p); }
// snap

g++ produces the following errors:

error: call of overloaded 'f(int, void*&)' is ambiguous
 int main() { void *p = 0; f(0, p); }

I tried clang++. It accepts the above code. My understanding is as follows:

template
void f(T, typename Const::type*) // T1

template
void f(T, void const *) // T2

We're going to deduce  

(unique-1, Const::type*) -> 
(T,void const*) // T1 -> T2

and

(unique-1, void const*) -> 
(T,Const::type*) // T2 -> T1

The first one takes T = unique-1 but fails at matching "void const*" to
"Const::type*". So this round fails for the second parameter. 

The second one takes T = unique-1. The second is a non-deduced context, thus
not compared, and this does not mismatch. So this round succeeds for parameter
2.

So we have: For parameter 1, each template is at least as specialized as the
other one. For parameter 2, T1 -> T2 did not succeed, so T1 is not at least as
specialized as T2 - but not vice versa (T2 -> T1 suceeded). Thus for parameter
2, T2 is more specialized.

It follows that T2 overall is more specialized that T1.

As a result, the overload is not ambiguous. Please correct me, if I am wrong.

[Bug c++/86361] Compilation failed while other compiler(clang) able to compile code in question

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ville.voutilainen at gmail dot 
com
 Resolution|--- |DUPLICATE

--- Comment #2 from Ville Voutilainen  ---
The lambda capturing k with a parameter named k is ill-formed as per Core DR
2211. Fix coming.

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

[Bug c++/79133] lambda capture shadowing parameter & decltype confusion

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||husain.255 at gmail dot com

--- Comment #5 from Ville Voutilainen  ---
*** Bug 86361 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/86401] The "For constants M and N, if M == (1LL << cst) - 1 && (N & M) == M,..." opts are only in fold-const.c and in RTL

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jul  6 21:42:41 2018
New Revision: 262485

URL: https://gcc.gnu.org/viewcvs?rev=262485=gcc=rev
Log:
PR tree-optimization/86401
* fold-const.c (fold_binary_loc) : Move the
((A & N) + B) & M -> (A + B) & M etc. optimization into ...
(fold_bit_and_mask): ... here.  New helper function for match.pd.
* fold-const.h (fold_bit_and_mask): Declare.
* match.pd (((A & N) + B) & M -> (A + B) & M): New optimization.

* gcc.dg/tree-ssa/pr86401-1.c: New test.
* gcc.dg/tree-ssa/pr86401-2.c: New test.
* c-c++-common/rotate-9.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/rotate-9.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr86401-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr86401-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/fold-const.h
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug target/86324] testsuite test divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Author: bergner
Date: Fri Jul  6 21:05:48 2018
New Revision: 262484

URL: https://gcc.gnu.org/viewcvs?rev=262484=gcc=rev
Log:
gcc/
PR target/86324
* target.def (translate_mode_attribute): New hook.
* targhooks.h (default_translate_mode_attribute): Declare.
* targhooks.c (default_translate_mode_attribute): New function.
* doc/tm.texi.in (TARGET_TRANSLATE_MODE_ATTRIBUTE): New hook.
* doc/tm.texi: Regenerate.
* config/rs6000/rs6000.c (TARGET_TRANSLATE_MODE_ATTRIBUTE): Define.
(rs6000_translate_mode_attribute): New function.

gcc/c-family/
PR target/86324
* c-attribs.c (handle_mode_attribute): Call new
translate_mode_attribute
target hook.

gcc/testsuite/
PR target/86324
gcc.target/powerpc/pr86324-1.c: New test.
gcc.target/powerpc/pr86324-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr86324-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86324-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/86428] strlen of const array initialized with a string of the same length not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-06
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Another test case for the same limitation:

const char a[4] = "123";
const char b[4] = "123";

int f (void)
{
  return __builtin_memcmp (a, b, 4);   // folded
}

const char c[4] = "123\0";   // sizeof "123\0" == 5

int g (void)
{
  return __builtin_memcmp (a, c, 4);   // not folded
}

The solution seems simple: change the string_constant() function to avoid
considering as string constants the strings of the last form, i.e., those with
more initializers than fit in the array they're stored in).

[Bug c++/86429] [8/9 Regression] lambda capture breaks constexpr-ness

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The diagnostic should not mention the __closure name, as that's an
implementation details (see also PR 82643)

[Bug c++/86429] [8/9 Regression] lambda capture breaks constexpr-ness

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-06
  Known to work||7.3.0
 Blocks||54367
Summary|lambda capture breaks   |[8/9 Regression] lambda
   |constexpr-ness  |capture breaks
   ||constexpr-ness
 Ever confirmed|0   |1
  Known to fail||8.1.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Started to fail with r253601


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
[Bug 54367] [meta-bug] lambda expressions

[Bug c++/82643] lambda capture breaks constexpr-ness of non-static const constexpr member call on non-constexpr value/variable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-06
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
GCC 6 rejected that code with a more sensible diagnostic:

c.cc:14:30: error: the value of 'f' is not usable in a constant expression

GCC 7 regressed to saying:

c.cc:14:30: error: '__closure' is not a constant expression

Clang and EDG both reject the code, but diagnosing different lines.

[Bug c++/86429] New: lambda capture breaks constexpr-ness

[zub at linux dot fjfi.cvut.cz]

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

Bug ID: 86429
   Summary: lambda capture breaks constexpr-ness
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zub at linux dot fjfi.cvut.cz
  Target Milestone: ---

This issue seems similar to bug 82643 but unlike that bug, this code compiles
fine in g++ 7.3 and fails to compile in g++ 8.1. Trying it out at wandabox.org
with gcc HEAD (201807) also results in compilation error.

The code requires boost hana:


#include 
#include 

int main()
{
namespace hana = boost::hana;

constexpr auto map = hana::make_map(hana::make_pair(hana::type_c,
"foo"));
[&](auto v) {
constexpr auto x = boost::hana::find(map, v);
std::cout << *x << '\n';
}(hana::type_c);

return 0;
}


With g++ 7.3 and clang++ it compiles OK and when run, prints out "foo\n" on
stdout. With g++ 8.1 I get:

$ g++-8 -std=c++17 gcc-8.1-not_contant.cc 
gcc-8.1-not_contant.cc: In instantiation of ‘main():: [with
auto:1 = boost::hana::type_impl::_]’:
gcc-8.1-not_contant.cc:12:21:   required from here
gcc-8.1-not_contant.cc:10:18: error: ‘__closure’ is not a constant expression
   constexpr auto x = boost::hana::find(map, v);
  ^

While I'm not 100% sure the code is correct, even the error message is strange
(__closure?).

[Bug tree-optimization/86428] New: strlen of const array initialized with a string of the same length not folded

[msebor at gcc dot gnu.org]

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

Bug ID: 86428
   Summary: strlen of const array initialized with a string of the
same length not folded
   Product: gcc
   Version: 9.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: ---

GCC folds strlen() calls with constant array arguments initialized with strings
fewer elements than the size of the array, but not those initialized with
strings with either a) the same number of elements or b) more.  (a) is a
missing optimization opportunity, (b) results in unsafe code (reading past the
end of the array).

Clang folds all three kinds of strlen calls.

$ cat c.c && gcc -O2 -S -Wall -Wextra -fdump-tree-strlen=/dev/stdout c.c
const char a[4] = "123";

int f (void)
{
  return __builtin_strlen (a);   // folded
}

const char b[4] = "123\0";   // no warning

int g (void)
{
  return __builtin_strlen (b);   // not folded
}


;; Function f (f, funcdef_no=0, decl_uid=1899, cgraph_uid=1, symbol_order=1)

f ()
{
   [local count: 1073741825]:
  return 3;

}



;; Function g (g, funcdef_no=1, decl_uid=1903, cgraph_uid=2, symbol_order=3)

g ()
{
  long unsigned int _1;
  int _3;

   [local count: 1073741825]:
  _1 = __builtin_strlen ();
  _3 = (int) _1;
  return _3;

}

[Bug tree-optimization/86427] New: strlen not folded after strcpy into a zeroed-out local array

[msebor at gcc dot gnu.org]

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

Bug ID: 86427
   Summary: strlen not folded after strcpy into a zeroed-out local
array
   Product: gcc
   Version: 9.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: ---

GCC eliminates a call to strlen() on a local copy into an uninitialized array
and from a character string of known length, but doesn't do the same when local
array is first zeroed-out.

$ cat c.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c
const char a[] = "123";

int f (void)
{
  char d[8];

  __builtin_strcpy (d, a);   // eliminated
  return __builtin_strlen (d);   // folded
}

int g (void)
{
  char d[8] = "";

  __builtin_strcpy (d, a);   // not eliminated
  return __builtin_strlen (d);   // not folded
}


;; Function f (f, funcdef_no=0, decl_uid=1899, cgraph_uid=1, symbol_order=1)

f ()
{
   [local count: 1073741825]:
  return 3;

}



;; Function g (g, funcdef_no=1, decl_uid=1903, cgraph_uid=2, symbol_order=2)

g ()
{
  char d[8];
  long unsigned int _1;
  int _5;

   [local count: 1073741825]:
  d = "";
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})];
  _1 = __builtin_strlen ();
  _5 = (int) _1;
  d ={v} {CLOBBER};
  return _5;

}

[Bug c++/86426] New: g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[helloqirun at gmail dot com]

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

Bug ID: 86426
   Summary: g++ ICE at on valid code in tree_operand_check, at
tree.h:3615
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

It affects versions from 4.8 to trunk.
g++4.6 emits errors. But clang++ can compile.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180706 (experimental) [trunk revision 262476] (GCC)


$ g++-trunk abc.c
abc.c: In substitution of ‘template int {anonymous}::f1(X...) [with T = ]’:
abc.c:4:26:   required from here
abc.c:4:26: internal compiler error: tree check: expected class ‘expression’,
have ‘type’ (integer_type) in tree_operand_check, at tree.h:3615
 int a1 = f1(X());
  ^
0x78c90b tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9403
0x651e95 expr_check(tree_node*, char const*, int, char const*)
../../gcc/gcc/tree.h:3286
0x651e95 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/gcc/tree.h:3615
0x651e95 unify_pack_expansion
../../gcc/gcc/cp/pt.c:21125
0x97665d unify
../../gcc/gcc/cp/pt.c:21919
0x9758b3 unify
../../gcc/gcc/cp/pt.c:22116
0x976612 unify
../../gcc/gcc/cp/pt.c:21913
0x974e92 try_class_unification
../../gcc/gcc/cp/pt.c:20907
0x9766b5 unify
../../gcc/gcc/cp/pt.c:21950
0x97bb93 unify_one_argument
../../gcc/gcc/cp/pt.c:20161
0x97c914 unify_pack_expansion
../../gcc/gcc/cp/pt.c:21156
0x97dce3 type_unification_real
../../gcc/gcc/cp/pt.c:20300
0x97ee7f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../gcc/gcc/cp/pt.c:19660
0x826a02 add_template_candidate_real
../../gcc/gcc/cp/call.c:3212
0x827414 add_template_candidate
../../gcc/gcc/cp/call.c:3291
0x827414 add_candidates
../../gcc/gcc/cp/call.c:5532
0x827801 add_candidates
../../gcc/gcc/cp/call.c:4225
0x827801 perform_overload_resolution
../../gcc/gcc/cp/call.c:4233
0x829722 build_new_function_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4306
0x9a0dad finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2536
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ cat abc.c
template  struct X {};
namespace {
template  int f1(X...);
int a1 = f1(X());
}

[Bug c/86420] [9 regression] nextafter(0x1p-1022,0) is constant folded

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Created attachment 44362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44362=edit
gcc9-pr86420.patch

Untested fix.

[Bug target/86425] New: Spec 2006 soplex seems to be slower on PowerPC using -ffast-math than without -ffast-math

[meissner at gcc dot gnu.org]

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

Bug ID: 86425
   Summary: Spec 2006 soplex seems to be slower on PowerPC using
-ffast-math than without -ffast-math
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I did some Spec 2006 runs, and one of the runs I was comparing normal speed
with -ffast-math.  As expected a lot of SpecFP benchmarks were faster using the
-ffast-math option.  However, 3 of the benchmarks were slower, including
soplex.

The 4 hottest functions in soplex are all slower using -ffast-math:

Percent   Percent   |   SamplesSamples   |  
slowmath  fastmath  |   slowmath   fastmath  |  Function
    |        |  
32.3283%  33.0005%  |  4,005,273  4,344,449  | 
_ZN6soplex10SPxSteepPR8entered4ENS_5SPxIdEi 
10.8967%  11.2537%  |  1,350,038  1,481,531  | 
_ZN6soplex8SSVector20assign2product4setupERKNS_5SVSetERKS0_ 
10.4306%  10.9159%  |  1,292,285  1,437,055  |  _ZN6soplex8SSVector5setupEv 
 7.0912%   7.5644%  |878,557995,832  | 
_ZN6soplex9CLUFactor16vSolveUrightNoNZEPdS1_Piid

Function _ZN6soplex10SPxSteepPR8entered4ENS_5SPxIdEi, 32.33 - 33.00% of total
in 2 files


The C++ name is soplex::SPxSteepPR::entered4(soplex::SPxId, int).

Percent   Percent   |   SamplesSamples   |  Line #  Filename 
slowmath  fastmath  |   slowmath   fastmath  |  Line #  Filename 
    |  -  -  |  --  -
50.4925%  51.6016%  |  2,022,362  2,241,806  | 175  svector.h
15.1681%  15.6850%  |607,528681,424  | 161  vector.h 
13.8269%  14.9673%  |553,806650,241  | 295  svector.h
10.0395%   8.8185%  |402,106383,111  | 293  svector.h
 5.0159%   1.5512%  |200,903 67,390  | 403  spxsteeppr.cc
   2.3271%  |   101,098  | 409  spxsteeppr.cc
 2.2996%   1.9382%  | 92,107 84,204  | 346  dataset.h
 1.2001%   1.2045%  | 48,071 52,327  | 402  spxsteeppr.cc

Function _ZN6soplex8SSVector20assign2product4setupERKNS_5SVSetERKS0_, 10.90 -
11.25% of total in 2 files


The C++ name is soplex::SSVector::assign2product4setup(soplex::SVSet const&,
soplex::SSVector const&).

Percent   Percent   |  Samples   Samples   |  Line #  Filename   
slowmath  fastmath  |  slowmath  fastmath  |  Line #  Filename   
    |      |  --  ---
60.5187%  59.4371%  |   817,025   880,583  | 984  ssvector.cc
29.4260%  29.5739%  |   397,262   438,147  | 981  ssvector.cc
 4.9556%   5.2965%  |66,90378,469  | 983  ssvector.cc
 3.9925%   4.4770%  |53,90066,328  | 980  ssvector.cc


Function _ZN6soplex8SSVector5setupEv, 10.43 - 10.92% of total in 2 files


The C++ name is soplex::SSVector::setup().

Percent   Percent   |  Samples   Samples   |  Line #  Filename
slowmath  fastmath  |  slowmath  fastmath  |  Line #  Filename
    |      |  --  
32.1165%  35.4180%  |   415,037   508,976  | 220  ssvector.cc 
22.2823%  25.1495%  |   287,951   361,412  | 212  ssvector.cc 
21.6266%  17.6770%  |   279,478   254,029  | 216  ssvector.cc 
20.2979%  19.6491%  |   262,308   282,368  | 214  ssvector.cc 
 3.6149%   2.1003%  |46,71530,182  | 193  spxdefines.h

Function _ZN6soplex9CLUFactor16vSolveUrightNoNZEPdS1_Piid, 7.09 - 7.56% of
total in 2 files
---

The C++ name is soplex::CLUFactor::vSolveUrightNoNZ(double*, double*, int*,
int, double).

Percent   Percent   |  Samples   Samples   |  Line #  Filename 
slowmath  fastmath  |  slowmath  fastmath  |  Line #  Filename 
    |      |  --  -
14.3154%  11.5548%  |   125,771   115,066  | 479  vsolve.cc
 8.4523%  10.0335%  |74,25999,917  |  72  vsolve.cc
 9.5626%   7.6039%  |84,01375,722  | 470  vsolve.cc
 8.0533%   9.5256%  |70,75394,859  |  73  vsolve.cc
 8.0590%   6.2612%  |70,80262,351  | 469  vsolve.cc
 5.9002%   7.1628%  |51,83671,330  | 490  vsolve.cc
 6.3017%   4.9831%  |55,36449,624  | 474  vsolve.cc
 4.5466%   2.8041%  |39,94427,924  | 502  vsolve.cc
 3.7633%   4.3653%  

[Bug target/86424] New: Milc is slower on PowerPC using -ffast-math than without using -ffast-math

[meissner at gcc dot gnu.org]

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

Bug ID: 86424
   Summary: Milc is slower on PowerPC using -ffast-math than
without using -ffast-math
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I did some Spec 2006 runs, and one of the runs I was comparing normal speed
with -ffast-math.  As expected a lot of SpecFP benchmarks were faster using the
-ffast-math option.  However, 3 of the benchmarks were slower, including milc.

The two hotest functions seem to be slower using -ffast-math:

slowmath  fastmath  |   slowmath   fastmath  |  Function  
    |        |    
17.5310%  17.4259%  |  5,489,872  5,580,840  |  mult_su3_na   
13.4533%  15.6660%  |  4,212,953  5,017,232  |  mult_adj_su3_mat_vec  

Function mult_su3_na, 17.43 - 17.53% of total in 2 files


Percent   Percent   |   SamplesSamples   |  Line #  Filename  
slowmath  fastmath  |   slowmath   fastmath  |  Line #  Filename  
    |  -  -  |  --  --
 9.8993%  75.9216%  |543,453  4,237,070  |  38  m_mat_na.c
65.7913%   2.8468%  |  3,611,855158,877  |  33  m_mat_na.c
   6.9169%  |   386,020  |  40  m_mat_na.c
 1.1277%   6.8534%  | 61,915382,477  |  48  m_mat_na.c
 5.6730%|311,441 |  49  m_mat_na.c
 3.8513%   2.1642%  |211,433120,784  |  46  m_mat_na.c
 3.5253%|193,542 |  45  m_mat_na.c
 2.8633%|157,188 |  41  m_mat_na.c
 2.1619%|118,689 |  39  m_mat_na.c
 1.4727%| 80,847 |  43  m_mat_na.c
 1.1929%| 65,486 |  36  m_mat_na.c
   1.1072%  |61,790  |  44  m_mat_na.c

Function mult_adj_su3_mat_vec, 13.45 - 15.67% of total in 2 files
-

Percent   Percent   |   SamplesSamples   |  Line #  Filename   
slowmath  fastmath  |   slowmath   fastmath  |  Line #  Filename   
    |  -  -  |  --  ---
71.3008%  77.9373%  |  3,003,867  3,910,288  | 116  m_amatvec.c
12.1258%  13.8781%  |510,853696,296  | 126  m_amatvec.c
11.0201%|464,272 | 121  m_amatvec.c
   3.4868%  |   174,944  | 123  m_amatvec.c
 2.1345%   1.4971%  | 89,925 75,109  | 129  m_amatvec.c
 1.3833%| 58,278 | 132  m_amatvec.c

[Bug target/86423] New: Omnetpp is slower on PowerPC using -ffast-math than not using -ffast-math

[meissner at gcc dot gnu.org]

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

Bug ID: 86423
   Summary: Omnetpp is slower on PowerPC using -ffast-math than
not using -ffast-math
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I did some Spec 2006 runs, and one of the runs I was comparing normal speed
with -ffast-math.  As expected a lot of SpecFP benchmarks were faster using the
-ffast-math option.  However, 3 of the benchmarks were slower, including
omnetpp.

In particular, cMessageHeap::shiftup(int) [clone .part.16], which is the hotest
function took 2,442,614 cycles when compiled with -ffast-math, and 2,378,917
cycles when compiled without -ffast-math.

Looking at the profile within the function, we see:

The C++ name is cMessageHeap::shiftup(int) [clone .part.16].

Percent   Percent   |  Samples   Samples   |  Line #  Filename   
slowmath  fastmath  |  slowmath  fastmath  |  Line #  Filename   
    |      |  --  ---
39.3521%  40.3151%  |   936,158   984,740  | 198  cmsgheap.cc
17.4123%  10.5189%  |   414,223   256,938  | 200  cmsgheap.cc
 4.6070%  16.3806%  |   109,595   400,114  |  43  cmsgheap.cc
14.2110%  14.2290%  |   338,071   347,561  | 199  cmsgheap.cc
 9.0102%   7.1333%  |   214,345   174,237  |  45  cmsgheap.cc
 7.4063%   1.8450%  |   176,19145,066  |  44  cmsgheap.cc
 3.4912%   4.9701%  |83,054   121,401  | 196  cmsgheap.cc
 2.3383%   2.3092%  |55,62756,405  | 204  cmsgheap.cc
 2.1165%   2.2862%  |50,34755,841  |  46  cmsgheap.cc

[Bug fortran/82009] [F08] ICE with block construct

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
The missing local variable exists in the fortran dump and it shows as the first
 item in the namespace passed to gfc_process_block_locals. However, it has no
backend decl.

I do not understand enough to proceed

[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On July 6, 2018 6:10:23 PM GMT+02:00, "boris.staletic at gmail dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
>
>--- Comment #4 from Boris Staletic 
>---
>I get the segmentations fault when running cc1plus directly. No matter
>if I
>pass -quiet or not.
>
>So what's the next step?
>
>Also, I have just noticed "Known to work: 8.1.1". Is that a mistake?

It works for me w/o segfault on the branch head.

[Bug target/86340] GCC 8.1 produces broken code for m68k with optimization levels above -O1

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug c/86420] [9 regression] nextafter(0x1p-1022,0) is constant folded

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
I think it's intended for -ftrapping-math to cover this.

Jakub's patch adding this folding functionality handles over/underflow cases,
but looks like the situation in comment #0 is not handled:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01027.html

[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs

[boris.staletic at gmail dot com]

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

--- Comment #4 from Boris Staletic  ---
I get the segmentations fault when running cc1plus directly. No matter if I
pass -quiet or not.

So what's the next step?

Also, I have just noticed "Known to work: 8.1.1". Is that a mistake?

[Bug libstdc++/86272] [6/7/8/9 Regression] __gnu_debug::string uses undefined __glibcxx_check_insert_range2

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

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

--- Comment #9 from François Dumont  ---
Fixed on trunk and all impacted branches.

[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
  Known to work||8.1.1
  Known to fail||8.1.0

--- Comment #3 from Richard Biener  ---
On the tip of the GCC 8 branch the segfault is gone (r262478).  I suspect the
error is memory use (it now peaks >20GB for me) and an unchecked allocation
or some 'int' size variable that overflows.

> /usr/bin/time /abuild/rguenther/obj/gcc/cc1plus -quiet CodePoint.ii
369.55user 7.52system 6:17.08elapsed 99%CPU (0avgtext+0avgdata
25329548maxresident)k
232inputs+604864outputs (0major+6777265minor)pagefaults 0swaps


Still needs tracking down thus.

[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs

[boris.staletic at gmail dot com]

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

--- Comment #2 from Boris Staletic  ---
> so this time it's not parsing but code-generation that blows up things.

That makes sense, when I was playing with the file, it took between 5 to 10
seconds to report syntax errors.

Another thing that avoids the ICE is using a "RawCodePoint" with less
"std::string"s.

Anything else I should try?

[Bug c/86420] [9 regression] nextafter(0x1p-1022,0) is constant folded

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to nsz from comment #0)
> gcc has no flag to say 'floating-point exceptions matter' (like
> -frounding-math for non-default rounding mode)

There is -ftrapping-math (on by default), although its exact meaning is
regularly questioned.

[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-06
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
For me with GCC 8 branch rN I have

> /usr/bin/time g++-8 CodePoint.ii -fsyntax-only
13.09user 0.86system 0:13.96elapsed 100%CPU (0avgtext+0avgdata
2270556maxresident)k
> /usr/bin/time g++-8 CodePoint.ii -S
g++-8: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
135.05user 1.72system 2:16.78elapsed 99%CPU (0avgtext+0avgdata
4050164maxresident)k
0inputs+160outputs (0major+1514630minor)pagefaults 0swaps

so this time it's not parsing but code-generation that blows up things.

Shortening the testcase probably makes things small enough to not hit
GCCs various "limits" where it gives up "optimizing" due to too large
code and non-linear algorithms.

Confirmed.

[Bug c++/86422] New: G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs

[boris.staletic at gmail dot com]

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

Bug ID: 86422
   Summary: G++ ICE(segmentation fault) when compiling a huge
static array of sufficiently complex structs
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris.staletic at gmail dot com
  Target Milestone: ---

My gcc version is 8.1.0. I have not tried with the latest gcc snapshot. If
requested, I will compile a gcc snapshot and try to reproduce.
My CHOST triple is x86_64-pc-linux-gnu, but I've also managed to get g++ to ICE
with an arm-linux-gnueabihf-g++, version 7.3.0, CHOST arm-linux-gnueabihf.
My gcc has been configured with:

/var/tmp/portage/sys-devel/gcc-8.1.0-r3/work/gcc-8.1.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.1.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.1.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.1.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include/g++-v8
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.1.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 8.1.0-r3 p1.3' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx
--disable-systemtap --enable-vtable-verify --enable-libvtv
--disable-libquadmath --enable-lto --without-isl --enable-libsanitizer
--enable-default-pie --enable-default-ssp

The preprocessed file, while being "just" a static array within a trivial
function, it's almost 6MB, so instead of attaching the file I have to post the
link:

https://raw.githubusercontent.com/bstaletic/gcc_ice/master/gcc/CodePoint.ii

When compiled with "g++ -S CodePoint.ii -o CodePoint.s", produces an empty
"CodePoint.s" and the following error:

g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


- Simple changes that avoid ICE:
  - Adding "-flto".
  - Changing the "std::string"s in the "RawCodePoint" (lines 19480 to 19483)
struct to a "char*".
- Makes the compile time really short, produces the assembly.
  - Changing the "std::string"s in the "RawCodePoint" struct to a "char[]".
- Somewhat shorter compile time, produces the assembly.
  - Moving the static array into global scope.

- Changes that caused other strange behaviour, without compiling:
  - Shortening the array by 30.000 elements (from the original >132.000) 
caused gcc to exhaust all ram (8GB), take half of the swap (4GB), end up not
using the CPU (only ram, went over the 12GB) and after a long while I hit
ctrl-c.

Note: Compiling takes more than 8GB of ram.

[Bug c/86418] warn about mismatch in type between argument and parameter type for declaration without prototype

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=48063

--- Comment #1 from Eric Gallager  ---
I got more warnings than that:

$ gcc -O2 -c 86418.c -Wall -Wextra -Wold-style-definition
-Wold-style-declaration -Wtraditional-conversion -Wdouble-promotion
-Wstrict-prototypes -Wfloat-equal -Wunsuffixed-float-constants
-Wmissing-prototypes -Wmissing-declarations
86418.c:2:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
 static void bar ();
 ^~
86418.c:12:1: warning: 'bar' was used with no prototype before its definition
[-Wmissing-prototypes]
 bar (double i)
 ^~~
86418.c: In function 'bar':
86418.c:14:7: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
   if (i)
   ^
86418.c: In function 'bar.constprop':
86418.c:14:6: warning: 'i' is used uninitialized in this function
[-Wuninitialized]
   if (i)
  ^
$

But I'm guessing you want one for the bar(1); call on line 7 too?

[Bug libstdc++/84928] std::accumulate should move the accumulator argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #3 from Jonathan Wakely  ---
Implemented for gcc 9.

[Bug libstdc++/84928] std::accumulate should move the accumulator argument

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Jul  6 14:16:13 2018
New Revision: 262477

URL: https://gcc.gnu.org/viewcvs?rev=262477=gcc=rev
Log:
PR libstdc++/84928 use std::move in  algorithms

P0616R0 altered the effects of the  algorithms to use std::move
on the accumulator values (resolving LWG 2055). This implements the
change for C++2a, but retains the previous behaviour for older
standards.

* include/bits/stl_numeric.h (_GLIBCXX_MOVE_IF_20): Define macro to
conditionally move, according to __cplusplus value.
(accumulate, inner_product, partial_sum, adjacent_difference): Use
_GLIBCXX_MOVE_IF_20.
* testsuite/26_numerics/accumulate/lwg2055.cc: New test.
* testsuite/26_numerics/adjacent_difference/lwg2055.cc: New test.
* testsuite/26_numerics/inner_product/lwg2055.cc: New test.
* testsuite/26_numerics/partial_sum/lwg2055.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/accumulate/lwg2055.cc
trunk/libstdc++-v3/testsuite/26_numerics/adjacent_difference/lwg2055.cc
trunk/libstdc++-v3/testsuite/26_numerics/inner_product/lwg2055.cc
trunk/libstdc++-v3/testsuite/26_numerics/partial_sum/lwg2055.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_numeric.h

[Bug fortran/86421] New: OpenMP declare simd linear ref in module causes gfortran to bail out

[juhmat at gmail dot com]

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

Bug ID: 86421
   Summary: OpenMP declare simd linear ref in module causes
gfortran to bail out
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juhmat at gmail dot com
  Target Milestone: ---

Created attachment 44361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44361=edit
Full compiler output and output of "-save-temps"

Using module that has subroutine containing `!$OMP DECLARE SIMD LINEAR(REF(x))`
directive will cause compiler to bail out in: "(null):0: confused by earlier
errors, bailing out"

Minimal reproducing code:

  module testmodule
use iso_fortran_env
implicit none
  contains
subroutine foo(x) 
  real(kind=real64) :: x
  !$OMP DECLARE SIMD LINEAR(REF(x))
end subroutine
  end module testmodule

  program testprogram
use testmodule
implicit none
  end program testprogram


Compilation command:

  gfortran-8 -fopenmp -save-temps -v testone.F90 -o testone

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[Richard Earnshaw (lists)]

On 06/07/18 12:11, Kamil Rytarowski wrote:
> On 06.07.2018 12:38, Richard Earnshaw (lists) wrote:
>> On 06/07/18 11:32, Kamil Rytarowski wrote:
>>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

 --- Comment #2 from Richard Earnshaw  ---
 I'm not sure how relevant the netbsd-elf port is these days.  I believe 
 they've
 now moved onto an EABI based ABI.  But no GCC port of that has been
 contributed.

>>>
>>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A
>>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre
>>> ARMv4 CPUs use OABI only.
>>>
>>
>> GCC-9 will drop support for pre-armv4 CPUs.  Such support has been
>> marked as deprecated for about 3 years now.
>>
> 
> We verify these ports on real hardware.
> 
> NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is
> obsoleting it and surprisingly LLVM soon might have support for a wider
> range of ARM CPUs.
> 

Shark's use strongARM cpus, which are ARMv4.  That's not been obsoleted,
but it is considered deprecated these days.

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[richard.earnshaw at arm dot com]

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

--- Comment #4 from richard.earnshaw at arm dot com ---
On 06/07/18 12:11, Kamil Rytarowski wrote:
> On 06.07.2018 12:38, Richard Earnshaw (lists) wrote:
>> On 06/07/18 11:32, Kamil Rytarowski wrote:
>>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383

 --- Comment #2 from Richard Earnshaw  ---
 I'm not sure how relevant the netbsd-elf port is these days.  I believe 
 they've
 now moved onto an EABI based ABI.  But no GCC port of that has been
 contributed.

>>>
>>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A
>>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre
>>> ARMv4 CPUs use OABI only.
>>>
>>
>> GCC-9 will drop support for pre-armv4 CPUs.  Such support has been
>> marked as deprecated for about 3 years now.
>>
> 
> We verify these ports on real hardware.
> 
> NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is
> obsoleting it and surprisingly LLVM soon might have support for a wider
> range of ARM CPUs.
> 

Shark's use strongARM cpus, which are ARMv4.  That's not been obsoleted,
but it is considered deprecated these days.

[Bug c/86420] New: [9 regression] nextafter(0x1p-1022,0) is constant folded

[nsz at gcc dot gnu.org]

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

Bug ID: 86420
   Summary: [9 regression] nextafter(0x1p-1022,0) is constant
folded
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

nextafterf(FLT_MIN,0), nextafter(DBL_MIN,0), nextafterl(LDBL_MIN,0) should
signal the underflow exception (c99 annex F requirement), but now gcc constant
folds them, this causes the following glibc test failures with gcc trunk:

FAIL: math/bug-nextafter
FAIL: math/bug-nexttoward

for

double f(void)
{
return __builtin_nextafter (0x1p-1022, 0);
}

on aarch64 with gcc -O2 -S -std=c11 -frounding-math
i get

f:
mov x0, 4503599627370495
fmovd0, x0
ret

with gcc-8 it is

f:
movid1, #0
mov x0, 4503599627370496
fmovd0, x0
b   nextafter

gcc has no flag to say 'floating-point exceptions matter' (like -frounding-math
for non-default rounding mode) so i think gcc should not do such optimizations
in standard conform mode where users might test for exceptions.

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return partial in some cases.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-06
 Ever confirmed|0   |1

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return partial in some cases.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Thanks, this is still present in the latest version of the code too.

This just includes the failing cases:

#include 
#include 

using namespace std;

// 2 code points, both are 4 byte in UTF-8.
// in UTF-16 both are 2 unit i.e. surrogate pairs
const char* u8in = u8"\U0010\U0010";

//tests .in() function of codecvt
auto test_u16_in()
{
char16_t u16out[4];

auto& cvt =
use_facet>(locale::classic());
auto state = mbstate_t{};
auto in_ptr = u8in;
auto out_ptr = u16out;

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
auto res =
cvt.in(state, u8in, u8in + 6, in_ptr, u16out, u16out + 2, out_ptr);
// actual output
assert(res == cvt.partial); // BUG
assert(out_ptr == u16out + 2);
assert(in_ptr == u8in + 4);
// expected output
// assert(res == cvt.partial);
// assert(out_ptr == u16str+2);
// assert(in_ptr == u8str+4);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res =
cvt.in(state, u8in, u8in + 8, in_ptr, u16out, u16out + 2, out_ptr);
// actual output
assert(res == cvt.partial); // BUG
assert(out_ptr == u16out + 2);
assert(in_ptr == u8in + 4);
// expected output
// assert(res == cvt.partial);
// assert(out_ptr == u16str+2);
// assert(in_ptr == u8str+4);
}

//tests .out() function of codecvt
auto test_u16_out()
{
const char16_t* u16in = u"\U0010\U0010";
char u8out[8];

auto& cvt =
use_facet>(locale::classic());
auto state = mbstate_t{};
auto in_ptr = u16in;
auto out_ptr = u8out;

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
auto res =
cvt.out(state, u16in, u16in + 1, in_ptr, u8out, u8out + 3,
out_ptr);
assert(res == cvt.partial); // BUG
assert(in_ptr == u16in);
assert(out_ptr == u8out);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res =
cvt.out(state, u16in, u16in + 1, in_ptr, u8out, u8out + 4,
out_ptr);
assert(res == cvt.partial); // BUG
assert(in_ptr == u16in);
assert(out_ptr == u8out);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res =
cvt.out(state, u16in, u16in + 3, in_ptr, u8out, u8out + 4,
out_ptr);
assert(res == cvt.partial); // BUG
assert(in_ptr == u16in + 2);
assert(out_ptr == u8out + 4);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res =
cvt.out(state, u16in, u16in + 3, in_ptr, u8out, u8out + 8,
out_ptr);
assert(res == cvt.partial); // BUG
assert(in_ptr == u16in + 2);
assert(out_ptr == u8out + 4);
}

int main()
{
test_u16_in();
test_u16_out();
}

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return partial in some cases.

[dmjpp at hotmail dot com]

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

Dimitrij Mijoski  changed:

   What|Removed |Added

  Attachment #44359|0   |1
is obsolete||

--- Comment #2 from Dimitrij Mijoski  ---
Created attachment 44360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44360=edit
better test cases with proper asserts

In the previous file the asserts were accustomed to the bugged behavior, had
only comments.

in this file the asserts are made as the expected behavior.

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Thanks, but please see https://gcc.gnu.org/contribute.html#legal

We can't use a patch without those steps being completed.

Also patches should be sent to the mailing lists, not attached to bugzilla, see
https://gcc.gnu.org/contribute.html#patches

(N.B. I've already started work on an alternative implementation that uses
RtlGenRandom instead).

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return partial in some cases.

[dmjpp at hotmail dot com]

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

--- Comment #1 from Dimitrij Mijoski  ---
Created attachment 44359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44359=edit
test cases that trigger the bug

[Bug libstdc++/86419] New: codecvt::in() and out() incorrectly return partial in some cases.

[dmjpp at hotmail dot com]

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

Bug ID: 86419
   Summary: codecvt::in() and out() incorrectly
return partial in some cases.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmjpp at hotmail dot com
  Target Milestone: ---

I have created a bunch of test cases, and on some it fails unexpectedly. I'll
post the code as attachment, the lines with the bug have the word "bug".

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[dmjpp at hotmail dot com]

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

--- Comment #3 from Dimitrij Mijoski  ---
Created attachment 44358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44358=edit
implements proper random_device for mingw-w64

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[dmjpp at hotmail dot com]

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

Dimitrij Mijoski  changed:

   What|Removed |Added

 CC||dmjpp at hotmail dot com

--- Comment #2 from Dimitrij Mijoski  ---
I have created a patch that fixes this for mingw-w64 using rand_s()
https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx

It does not work with mingw.org (reverts to mt19973 as now). mingw.org does not
have rand_s() declared in its headers.

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #6)
> It is run automatically now by typing "make -k check-fortran" at top level.

Ah, thanks for the remark (wasn't aware of that). Nice!

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #6 from Eric Botcazou  ---
> It took me a while to figure out how to actually run the Fortran subset of
> the libgomp suite (which is not very well documented, or I'm too stupid to
> find it).

It is run automatically now by typing "make -k check-fortran" at top level.

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[Kamil Rytarowski]

On 06.07.2018 12:38, Richard Earnshaw (lists) wrote:
> On 06/07/18 11:32, Kamil Rytarowski wrote:
>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
>>>
>>> --- Comment #2 from Richard Earnshaw  ---
>>> I'm not sure how relevant the netbsd-elf port is these days.  I believe 
>>> they've
>>> now moved onto an EABI based ABI.  But no GCC port of that has been
>>> contributed.
>>>
>>
>> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A
>> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre
>> ARMv4 CPUs use OABI only.
>>
> 
> GCC-9 will drop support for pre-armv4 CPUs.  Such support has been
> marked as deprecated for about 3 years now.
> 

We verify these ports on real hardware.

NetBSD/shark is prepared to be switched to Clang/LLVM as GCC is
obsoleting it and surprisingly LLVM soon might have support for a wider
range of ARM CPUs.



signature.asc
Description: OpenPGP digital signature

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #4)
> The idea of the warning is to ensure that we have
> Location information everywhere, and that patches
> Which do not correctly set the location should cause
> something visible during testing. We do not have this for
> release.

Thanks for the explanation. Makes sense.

Do you have any idea what might have caused the regression?


> We should take care to always regression test libgomp.fortran
> as well...

Yes, I finally got into this habit, after repeatedly breaking libgomp tests
with my patches without noticing it.

I also tried to document how to do this at the bottom of this wiki page:

https://gcc.gnu.org/wiki/TestCaseWriting

It took me a while to figure out how to actually run the Fortran subset of the
libgomp suite (which is not very well documented, or I'm too stupid to find
it).

[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.

[tnfchris at gcc dot gnu.org]

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

--- Comment #14 from Tamar Christina  ---
Author: tnfchris
Date: Fri Jul  6 10:44:35 2018
New Revision: 262472

URL: https://gcc.gnu.org/viewcvs?rev=262472=gcc=rev
Log:
Require sse for testcase on i686.

PR target/84711
* gcc.dg/vect/pr84711.c: Add -msse for i686 targets.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr84711.c

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[richard.earnshaw at arm dot com]

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

--- Comment #3 from richard.earnshaw at arm dot com ---
On 06/07/18 11:32, Kamil Rytarowski wrote:
> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
>>
>> --- Comment #2 from Richard Earnshaw  ---
>> I'm not sure how relevant the netbsd-elf port is these days.  I believe 
>> they've
>> now moved onto an EABI based ABI.  But no GCC port of that has been
>> contributed.
>>
> 
> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A
> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre
> ARMv4 CPUs use OABI only.
> 

GCC-9 will drop support for pre-armv4 CPUs.  Such support has been
marked as deprecated for about 3 years now.

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[Richard Earnshaw (lists)]

On 06/07/18 11:32, Kamil Rytarowski wrote:
> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
>>
>> --- Comment #2 from Richard Earnshaw  ---
>> I'm not sure how relevant the netbsd-elf port is these days.  I believe 
>> they've
>> now moved onto an EABI based ABI.  But no GCC port of that has been
>> contributed.
>>
> 
> NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A
> user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre
> ARMv4 CPUs use OABI only.
> 

GCC-9 will drop support for pre-armv4 CPUs.  Such support has been
marked as deprecated for about 3 years now.

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[Kamil Rytarowski]

On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
> 
> --- Comment #2 from Richard Earnshaw  ---
> I'm not sure how relevant the netbsd-elf port is these days.  I believe 
> they've
> now moved onto an EABI based ABI.  But no GCC port of that has been
> contributed.
> 

NetBSD switched on newer ARM CPUs to EABI and keeps compat with OABI. A
user is free to build either EABI and OABI for ARMv4+ CPUs. Older pre
ARMv4 CPUs use OABI only.



signature.asc
Description: OpenPGP digital signature

[Bug debug/86413] [9 regression] gcc.dg/guality/pr48437.c fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-06
 CC||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm, we have

 <1><101>: Abbrev Number: 5 (DW_TAG_subprogram)
<102>   DW_AT_external: 1
<102>   DW_AT_name: (indirect string, offset: 0x21e): main
<106>   DW_AT_decl_file   : 1
<107>   DW_AT_decl_line   : 2
<108>   DW_AT_decl_column : 5
<109>   DW_AT_type: <0xf5>
 <2><10d>: Abbrev Number: 6 (DW_TAG_variable)
<10e>   DW_AT_name: i
<110>   DW_AT_decl_file   : 1
<111>   DW_AT_decl_line   : 4
<112>   DW_AT_decl_column : 16
<113>   DW_AT_type: <0xfc>
 <2><117>: Abbrev Number: 7 (DW_TAG_lexical_block)
 <3><118>: Abbrev Number: 8 (DW_TAG_variable)
<119>   DW_AT_name: i
<11b>   DW_AT_decl_file   : 1
<11c>   DW_AT_decl_line   : 7
<11d>   DW_AT_decl_column : 18
<11e>   DW_AT_type: <0xf5>
<122>   DW_AT_external: 1
<122>   DW_AT_declaration : 1

and

 <1><153>: Abbrev Number: 3 (DW_TAG_subprogram)
<154>   DW_AT_abstract_origin: <0x101>
<158>   DW_AT_low_pc  : 0x4003e0
<160>   DW_AT_high_pc : 0x30
<168>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<16a>   DW_AT_GNU_all_call_sites: 1
<16a>   DW_AT_sibling : <0x17c>
 <2><16e>: Abbrev Number: 4 (DW_TAG_lexical_block)
<16f>   DW_AT_abstract_origin: <0x117>
 <2><173>: Abbrev Number: 5 (DW_TAG_variable)
<174>   DW_AT_abstract_origin: <0x10d>
<178>   DW_AT_location: 2 byte block: 91 74 (DW_OP_fbreg: -12)
 <2><17b>: Abbrev Number: 0
 <1><17c>: Abbrev Number: 5 (DW_TAG_variable)
<17d>   DW_AT_abstract_origin: <0xeb>
<181>   DW_AT_location: 9 byte block: 3 34 10 60 0 0 0 0 0 
(DW_OP_addr: 601034)

so what seems to be missing is location info for <16e>.  Quite possibly
this happens because we remove the BLOCK from the block tree given there's
nothing left in it.

So I think we have to preserve even non-VAR_DECLs like types because without
high/low-pc attributes for the BLOCKs gdb cannot handle scoping correctly.
Or somehow mark the BLOCKs as to be "used" for scoping.  I guess that would
then keep most of the BLOCKs live in result ...

Hmm, OTOH the live stmt should keep the BLOCK live which in turn should
make it get the locations...  ah, it's

  /* Determine if this block directly contains any "significant"
 local declarations which we will need to output DIEs for.  */
  if (debug_info_level > DINFO_LEVEL_TERSE)
/* We are not in terse mode so *any* local declaration counts
   as being a "significant" one.  */
must_output_die = ((BLOCK_VARS (stmt) != NULL
|| BLOCK_NUM_NONLOCALIZED_VARS (stmt))
   && (TREE_USED (stmt)
   || TREE_ASM_WRITTEN (stmt)
   || BLOCK_ABSTRACT (stmt)));

where w/o vars we don't even output locations (we created the DIE for
the BLOCK already though).  That means a similar testcase for non-LTO
should be possible as soon as we'd start to run free-lang-data unconditionally.

The following fixes the FAIL for me and would allow us to prune unused
vars not only from local_decls but also from the BLOCK tree.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index a7c4620cfc3..95232177d83 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -25622,6 +25622,11 @@ gen_block_die (tree stmt, dw_die_ref context_die)
 /* The outer scopes for inlinings *must* always be represented.  We
generate DW_TAG_inlined_subroutine DIEs for them.  (See below.) */
 must_output_die = 1;
+  else if (BLOCK_DIE (stmt))
+/* If we already have a DIE then it was filled early.  Meanwhile
+   we might have pruned all BLOCK_VARS as optimized out but we
+   still want to generate high/low PC attributes so output it.  */
+must_output_die = 1;
   else
 {
   /* Determine if this block directly contains any "significant"

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
The idea of the warning is to ensure that we have
Location information everywhere, and that patches
Which do not correctly set the location should cause
something visible during testing. We do not have this for
release.

We should take care to always regression test libgomp.fortran
as well...

--- Comment #4 from Thomas Koenig  ---
The idea of the warning is to ensure that we have
Location information everywhere, and that patches
Which do not correctly set the location should cause
something visible during testing. We do not have this for
release.

We should take care to always regression test libgomp.fortran
as well...

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
The idea of the warning is to ensure that we have
Location information everywhere, and that patches
Which do not correctly set the location should cause
something visible during testing. We do not have this for
release.

We should take care to always regression test libgomp.fortran
as well...

--- Comment #4 from Thomas Koenig  ---
The idea of the warning is to ensure that we have
Location information everywhere, and that patches
Which do not correctly set the location should cause
something visible during testing. We do not have this for
release.

We should take care to always regression test libgomp.fortran
as well...

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.0

[Bug c/86418] New: warn about mismatch in type between argument and parameter type for declaration without prototype

[vries at gcc dot gnu.org]

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

Bug ID: 86418
   Summary: warn about mismatch in type between argument and
parameter type for declaration without prototype
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---
  Keywords: diagnostic

Consider this test-case, based on pr48063.c:
...
extern void abort (void);
static void bar ();

int
main (void)
{
  bar (1);
  return 0;
}

static void
bar (double i)
{
  if (i)
abort ();
}
...

The test-case contains undefined behaviour:
- bar is declared without prototype
- the call to bar in main is before the definition of bar, so the call is
  considered calling a function that does not include a prototype (as opposed
  to the situation where we move the definition of bar to before main, and the
  call uses the prototype provided by the definition of bar)
- the int argument in the call is incompatible with the double parameter of the
  definition of bar

In words of the c standard:
...
 [ 6.9.1 Function definitions ]
 If the declarator includes a parameter type list, the list also specifies the
 types of all the parameters; such a declarator also serves as a function
 prototype for later calls to the same function in the same translation unit. 
...
and:
...
 [ 6.5.2.2 Function calls ]
If the expression that denotes the called function has a type that does not
include a prototype, the integer promotions are performed on each argument, and
arguments that have type float are promoted to double. These are called the
default argument promotions. If the number of arguments does not equal the
number of parameters, the behavior is undefined. If the function is defined
with a type that includes a prototype, and either the prototype ends with an
ellipsis (, ...) or the types of the arguments after promotion are not
compatible with the types of the parameters, the behavior is undefined.
...
and:
...
[ J.2 Undefined behavior ]
For call to a function without a function prototype in scope where the function
is defined with a function prototype, either the prototype ends with an
ellipsis or the types of the arguments after promotion are not compatible with
the types of the parameters (6.5.2.2).
...

Atm, the only warning we get is when cloning:
...
$ gcc -O2 pr48063.c  -Wall
pr48063.c: In function ‘bar.constprop’:
pr48063.c:18:6: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
   if (i)
  ^
...

The cloned version has no parameters, and replaces parameter i with local
variable i, which is uninitialized:
...
bar.constprop ()
{
  double i;

  
  if (i_1(D) != 0.0)
goto ;
  else
goto ;

  
  abort ();

  
  return;
}
...

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
>
>  type (dt) :: x(2:n)
>1
> Warning: No location in expression near (1)
> 
> 
> I have no idea what this error message is trying to tell me ... :(

In any case, it comes from "check_locus_expr" (in frontend-passes.c), which was
added by Thomas in r243520. However that commit is already more than a year
old, so something else must have triggered this warning to appear recently.

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
Reduced test case:


module m
  type dt
integer, allocatable :: h(:)
  end type
end module m

  use m
  call foo (4)
contains
  subroutine foo (n)
integer :: n
type (dt) :: x(2:n)
if (lbound (x, 1) /= 2 .or. ubound (x, 1) /= 4) STOP 11
  end subroutine
end



 type (dt) :: x(2:n)
   1
Warning: No location in expression near (1)



I have no idea what this error message is trying to tell me ... :(

[Bug fortran/86417] New: [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[janus at gcc dot gnu.org]

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

Bug ID: 86417
   Summary: [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90
 -O0  (test for excess errors)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

At r262469 I'm seeing the following error in the libgomp testsuite on
x86_64-linux-gnu:

FAIL: libgomp.fortran/alloc-comp-3.f90   -O0  (test for excess errors)
Excess errors:
/home/janus/gcc/trunk/libgomp/testsuite/libgomp.fortran/alloc-comp-3.f90:122:23:
Warning: No location in expression near (1)
/home/janus/gcc/trunk/libgomp/testsuite/libgomp.fortran/alloc-comp-3.f90:122:23:
Warning: No location in expression near (1)

The failure must be pretty new, but I can't exactly pinpoint when it appeared.