[Bug target/90175] New: ambiguous wording "critical attribute" in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 90175
   Summary: ambiguous wording "critical attribute" in diagnostic
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From msp430.c:

  if (is_critical_func (* node))
{
  warning (OPT_Wattributes,
   "critical attribute has no effect on interrupt functions");
  DECL_ATTRIBUTES (*node) = remove_attribute (ATTR_CRIT,
  DECL_ATTRIBUTES (*
node));
}

The words "critical attribute" could either mean an attribute that is critical
for producing correct code. Or, alternatively, they could mean "the
% attribute", which is more probable in this case.

While here, I noticed that the warning message "naked functions cannot be
reentrant" is never translated properly. This message, and the other ones must
be enclosed in N_(...).

It's unfortunate that the function attributes are often named after English
adjectives, so that constructing these ambiguous sentences is possible in the
first place.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

  Attachment #46200|0   |1
is obsolete||

--- Comment #74 from Bernd Edlinger  ---
Created attachment 46203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46203&action=edit
gcc9-pr89093.patch

Same patch, just guard the target attribute with a version check,
so that supported boot-strap configurations should work

[Bug translation/90163] untranslated placeholder in warn_once_call_ms2sysv_xlogues

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||daniel.santos at pobox dot com,
   ||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
pretty sure Daniel Santos did this code

[Bug c++/52961] Make -Wempty-body less noisy and enable it with -Wall

[egallager at gcc dot gnu.org]

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

--- Comment #12 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #10)
> Clang... suggests placing the ";" on a different line to silence
> the warning:
> 
> 
> warning: if statement has empty body [-Wempty-body]
>   if(a);
>^
> note: put the semicolon on a separate line to silence this warning
> 
> which seems a nicer way to silence the warning instead of ugly { ; }

That's a debatable opinion; I think the braces do a better job expressing
grouping

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #73 from Bernd Edlinger  ---
Okay, the requirement is only to be able to boot-strap with
a released gcc version, so gcc-8 should not use the pragma,
while gcc-9 should use the pagma.
I was able to bootstrap from x86_64 -> arm cross -> arm native
that worked fine.
I will guard the pragma with a gcc-version check.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #72 from Bernd Edlinger  ---
I use host Compiler from last week:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/9.0.1/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-9-20190331/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=all
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16
--with-float=hard
Thread model: posix
gcc version 9.0.1 20190331 (experimental) (GCC)

and libgnat, is definietly affected since the personality function pushes d8-d9

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #71 from Bernd Edlinger  ---
I am sorry, but my native arm bootstrap Fails:

g++ -std=gnu++98 -fno-PIE -c  -I../../gcc-trunk-r270444/gcc/../libgcc
-DEH_MECHANISM_arm -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format  -Wmissing-format-attribute -Woverloaded-virtual
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -Iada -I../../gcc-trunk-r270444/gcc
-I../../gcc-trunk-r270444/gcc/ada -I../../gcc-trunk-r270444/gcc/../include
-I../../gcc-trunk-r270444/gcc/../libcpp/include
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gmp
-I/home/ed/gnu/gcc-trunk-r270444/gmp
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpc/src 
-I../../gcc-trunk-r270444/gcc/../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libbacktrace
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./isl/include
-I/home/ed/gnu/gcc-trunk-r270444/isl/include  -o ada/raise-gcc.o -MT
ada/raise-gcc.o -MMD -MP -MF ada/.deps/raise-gcc.TPo
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c
g++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format  -Wmissing-format-attribute -Woverloaded-virtual
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -Iada -I../../gcc-trunk-r270444/gcc
-I../../gcc-trunk-r270444/gcc/ada -I../../gcc-trunk-r270444/gcc/../include
-I../../gcc-trunk-r270444/gcc/../libcpp/include
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gmp
-I/home/ed/gnu/gcc-trunk-r270444/gmp
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpc/src 
-I../../gcc-trunk-r270444/gcc/../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libbacktrace
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./isl/include
-I/home/ed/gnu/gcc-trunk-r270444/isl/include  -o ada/seh_init.o -MT
ada/seh_init.o -MMD -MP -MF ada/.deps/seh_init.TPo
../../gcc-trunk-r270444/gcc/ada/seh_init.c
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c:1165:55: error: unknown target
attribute or pragma 'general-regs-only'
 1165 |struct _Unwind_Context* uw_context ATTRIBUTE_UNUSED)
  |   ^
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c:1183:32: error: unknown target
attribute or pragma 'general-regs-only'
 1183 | _Unwind_Context *uw_context)
  |^
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c:1354:43: error: unknown target
attribute or pragma 'general-regs-only'
 1354 | struct _Unwind_Context* uw_context)
  |   ^
make[3]: *** [ada/raise-gcc.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf'
make: *** [all] Error 2

[Bug rtl-optimization/90174] New: Bad register spill due to top-down allocation order

[fxue at os dot amperecomputing.com]

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

Bug ID: 90174
   Summary: Bad register spill due to top-down allocation order
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

Current regional RA uses a top-down allocation order, which may not properly
split a long live range that crosses sub-region with high register pressure. 

In the following graph, lv0 is live in whole outer region, and suppose inner
region is under high register pressure due to lots of live ranges inside it.

According to RA algorithm, out region is processed firstly, lv0 is picked up as
spill candidate. And then turn to inner region, also the part of lv0 in inner
region is marked as being spilled. Finally result is that the whole lv0 should
be spilled. But if in area excluding inner region, there is with low register
pressure, we can get a better choice to place lv0 in register instead of
memory, and only spill/reload lv0 at boundary of entry-into(A)/exist-from(B)
inner region. In other word, inner region boundary are split points for lv0.


   |  
   outer   | lv0 
   region  | __  split point
   |/
.--A---.
|  |   |
|  |  | |  |
|  inner   |  | lv1 |  | 
|  region  |  | |  |
|  |  | lv2 |  |
|  |  | |  |
|  |   |
'--B---'
   |\__
   |split point
   |

Here is an example to show this. gcc produces bad spills as we point out(-m64
-O3, for x86-64), but llvm generates better spill/reload as we expect.

  int value[20];

  int user0;
  int user1;
  int user2[100];
  int user3;

  int fncall(void);

  void foo(int cond)
  {
  int lv_out = value[0];
  int i;

  user0 = lv_out;   /* Better to place lv_out in register. */

  if (cond) {
  int sum = 0;
  int lv_in_1 = value[1];
  int lv_in_2 = value[2];
  int lv_in_3 = value[3];
  int lv_in_4 = value[4];
  int lv_in_5 = value[5];
  int lv_in_6 = value[6];
  int lv_in_7 = value[7];
  int lv_in_8 = value[8];
  int lv_in_9 = value[9];
  int lv_in_10 = value[10];
  int lv_in_11 = value[11];
  int lv_in_12 = value[12];
  int lv_in_13 = value[13];
  int lv_in_14 = value[14];
  int lv_in_15 = value[15];

  /* Better to spill lv_out here */

  for (i = 0; i < 1000; i++) {
  sum += lv_in_1;
  sum += lv_in_2;
  sum += lv_in_3;
  sum += lv_in_4;
  sum += lv_in_5;
  sum += lv_in_6;
  sum += lv_in_7;
  sum += lv_in_8;
  sum += lv_in_9;
  sum += lv_in_10;
  sum += lv_in_11;
  sum += lv_in_12;
  sum += lv_in_13;
  sum += lv_in_14;
  sum += lv_in_15;

  fncall();

  lv_in_1 ^= i;
  lv_in_2 ^= i;
  lv_in_3 ^= i;
  lv_in_4 ^= i;
  lv_in_5 ^= i;
  lv_in_6 ^= i;
  lv_in_7 ^= i;
  lv_in_8 ^= i;
  lv_in_9 ^= i;
  lv_in_10 ^= i;
  lv_in_11 ^= i;
  lv_in_12 ^= i;
  lv_in_13 ^= i;
  lv_in_14 ^= i;
  lv_in_15 ^= i;
  }

  /* Better to reload lv_out here */

  user1 = sum;
  }

  for (i = 0; i < 100; i++) {
  user2[i ^ 100] = lv_out; /* Better to place lv_out in register */
  }

  user3 = lv_out;  /* Better to place lv_out in register */
  }


For top-down allocation, we can only adjust inner region allocation result, but
no way to refine decision that has been made on outside live-range, it is an
intrinsic weakness of the top-down algorithm. To fix that, we may need to add a
new pass to explicitly split live ranges based on region boundary, or adopt a
reverse means, from inner to outer to perform allocation.

[Bug fortran/90169] Setting an allocatable variable length character array in a type incorrectly sets all members of the array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
The problem is fixed on trunk.  Don't know if anyone intends to back port.
Doubt it as no one has done so.

PR 78578 is irrelevant as the individual who submitted
the testcase has a typo in his/her code.

[Bug middle-end/64122] ICE: tree check: expected tree that contains 'decl common' structure, have 'ssa_name' in prepare_gimple_addressable, at gimplify.c:3228 with -fgnu-tm

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
I can reproduce it only on the 4.9 and 5 branches.

[Bug c++/90173] New: [9 Regression] ICE: Segmentation fault (in strip_declarator_types)

[asolokha at gmx dot com]

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

Bug ID: 90173
   Summary: [9 Regression] ICE: Segmentation fault (in
strip_declarator_types)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190414 snapshot (r270355) ICEs when compiling the following
testcase extracted from test/Parser/cxx1z-class-template-argument-deduction.cpp
from the clang 8.0.0 test suite w/ -std=c++17:

template  struct A { };

A(int) -> A;

namespace decl {
  A (*fp)() = 0;
}

% g++-9.0.0-alpha20190414 -std=c++17 -c yuz02xm1.cpp
yuz02xm1.cpp:6:3: error: template placeholder type 'A<...auto...>' must be
followed by a simple declarator-id
6 |   A (*fp)() = 0;
  |   ^
yuz02xm1.cpp:1:30: note: 'template struct A' declared here
1 | template  struct A { };
  |  ^
yuz02xm1.cpp:6:15: error: conversion from 'int' to non-scalar type 'A'
requested
6 |   A (*fp)() = 0;
  |   ^
yuz02xm1.cpp:6:15: internal compiler error: Segmentation fault
0xf780df crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/toplev.c:326
0x9ada1f strip_declarator_types
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:20058
0x9ada1f cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:20559
0x98f245 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:13541
0x9b432d cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:13238
0x9b4eeb cp_parser_declaration_seq_opt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:13114
0x9b4eeb cp_parser_namespace_body
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:19327
0x9b4eeb cp_parser_namespace_definition
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:19305
0x9b4440 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:13218
0x9b4ac1 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:4701
0x9b4ac1 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:41181
0xabe3eb c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/c-family/c-opts.c:1156

[Bug c++/90172] New: [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[asolokha at gmx dot com]

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

Bug ID: 90172
   Summary: [9 Regression] ICE: Segmentation fault (in
contains_struct_check)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: error-recovery
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190414 snapshot (r270355) ICEs when compiling the following
testcase extracted from test/SemaCXX/cxx1y-generic-lambdas.cpp from the clang
8.0.0 test suite w/ -std=c++17:

template int fooV(Ts ... ts) {
  auto L = [](auto ... a) {
auto M = [](decltype(a) ... b) -> void {
};
return M;
  };

  decltype(L(L, ts...)) (*fp)(decltype(L), decltype(ts) ...) = L;

  return 0;
}

int run2 = fooV("BC", 3, 2.77, 'A', float{}, short{}, unsigned{});

% g++-9.0.0-alpha20190414 -std=c++17 -c mziudrma.cpp
mziudrma.cpp: In instantiation of 'int fooV(Ts ...) [with Ts = {const char*,
int, double, char, float, short int, unsigned int}]':
mziudrma.cpp:13:65:   required from here
mziudrma.cpp:3:14: error: expansion pattern 'decltype (#'nontype_argument_pack'
not supported by dump_expr#)' contains no parameter packs
3 | auto M = [](decltype(a) ... b) -> void {
  |  ^~~
4 | };
  | ~ 
mziudrma.cpp: In instantiation of 'static constexpr decltype (((const fooV(Ts
...) [with Ts = {const char*, int, double, char, float, short int, unsigned
int}]::*)0)->operator()(static_cast(fooV::__lambda2::_FUN::) ...)) fooV(Ts ...)
[with Ts = {const char*, int, double, char, float, short int, unsigned
int}]_FUN(auto:1 ...) [with auto:1 = {fooV(Ts ...)
[with Ts = {const char*, int, double, char, float, short int, unsigned
int}]::, const char*, int, double, char, float, short int,
unsigned int}; decltype (((const fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]::*)0)->operator()(static_cast(fooV::__lambda2::_FUN::) ...)) = void]':
mziudrma.cpp:2:12:   required from 'constexpr fooV(Ts ...) [with Ts = {const
char*, int, double, char, float, short int, unsigned int}]operator decltype (((const fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]::*)0)->operator()(static_cast(fooV::__lambda2::_FUN::) ...)) (*)(auto:1
...)() const [with auto:1 = {fooV(Ts ...) [with Ts = {const char*, int, double,
char, float, short int, unsigned int}]::, const char*, int,
double, char, float, short int, unsigned int}; decltype (((const fooV(Ts ...)
[with Ts = {const char*, int, double, char, float, short int, unsigned
int}]::*)0)->operator()(static_cast(fooV::__lambda2::_FUN::) ...)) = void]'
mziudrma.cpp:8:27:   required from 'int fooV(Ts ...) [with Ts = {const char*,
int, double, char, float, short int, unsigned int}]'
mziudrma.cpp:13:65:   required from here
mziudrma.cpp:2:12: internal compiler error: Segmentation fault
2 |   auto L = [](auto ... a) {
  |^~~~
3 | auto M = [](decltype(a) ... b) -> void {
  | 
4 | };
  | ~~  
5 | return M;
  | ~
6 |   };
  |   ~ 
0xf780df crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/toplev.c:326
0x87eb94 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/tree.h:3289
0x87eb94 build_call_a(tree_node*, int, tree_node**)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/call.c:396
0x9d5142 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:18886
0x9df6af tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:18238
0x9df6af tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:17914
0x9e0ed6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:17030
0x9df721 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:17321
0x9df096 instantiate_decl(tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:24774
0xa0569b instantiate_pending_templates(int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:24890
0x91e770 c_parse_fin

[Bug c++/90171] New: [9 Regression] ICE in build_op_delete_call, at cp/call.c:6630

[asolokha at gmx dot com]

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

Bug ID: 90171
   Summary: [9 Regression] ICE in build_op_delete_call, at
cp/call.c:6630
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190414 snapshot (r270355) ICEs when compiling the following
testcase extracted from test/SemaCXX/cxx2a-destroying-delete.cpp from the clang
8.0.0 test suite w/ -std=c++17:

namespace std {
  using size_t = decltype(sizeof(0));
  enum class align_val_t : size_t;

  struct destroying_delete_t { };
}

struct A {
  void operator delete(A*, std::destroying_delete_t, std::align_val_t);
  void operator delete(A*, std::destroying_delete_t, std::size_t,
std::align_val_t);
};

void delete_A(A *a) { delete a; }

% g++-9.0.0-alpha20190414 -std=c++17 -c hmayxrtu.cpp
hmayxrtu.cpp: In function 'void delete_A(A*)':
hmayxrtu.cpp:13:30: internal compiler error: in build_op_delete_call, at
cp/call.c:6630
   13 | void delete_A(A *a) { delete a; }
  |  ^
0x5a373b build_op_delete_call(tree_code, tree_node*, tree_node*, bool,
tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/call.c:6630
0x937168 build_delete(tree_node*, tree_node*, special_function_kind, int, int,
int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/init.c:4849
0x9a7e3e cp_parser_unary_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:8209
0x9802d2 cp_parser_cast_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:9357
0x980b7a cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:9460
0x981bb6 cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:9758
0x981f39 cp_parser_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:9925
0x985455 cp_parser_expression_statement
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:11514
0x9912ec cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:11310
0x9929e8 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:11657
0x992ac8 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:11611
0x9ac975 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:22660
0x9ac975 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:22711
0x9ad2d6 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:27802
0x9ae0ac cp_parser_function_definition_from_specifiers_and_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:27718
0x9ae0ac cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:20297
0x98f245 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:13541
0x9b432d cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:13238
0x9b4ac1 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:4701
0x9b4ac1 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:41181

[Bug c++/90170] New: [7/8/9 Regression] ICE in unify, at cp/pt.c:22209

[asolokha at gmx dot com]

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

Bug ID: 90170
   Summary: [7/8/9 Regression] ICE in unify, at cp/pt.c:22209
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190414 snapshot (r270355) ICEs when compiling the following
testcase extracted from test/SemaTemplate/temp_arg_nontype.cpp from the clang
8.0.0 test suite w/ -std=c++17:

namespace partial_order_different_types {
  template struct A;

  // FIXME: It appears that this partial specialization should be ill-formed as
  // it is not more specialized than the primary template. V is not deducible
  // because it does not have the same type as the corresponding parameter.
  template struct A<0, N, T, U, V> {}; //
expected-note {{matches}}
}

% g++-9.0.0-alpha20190414 -std=c++17 -c zaccgjmf.cpp
zaccgjmf.cpp:7:55: internal compiler error: in unify, at cp/pt.c:22209
7 |   template struct A<0, N, T, U, V>
{}; // expected-note {{matches}}
  |   ^~~~
0x620a62 unify
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:22209
0x9d05a8 unify
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:22391
0x9d0116 unify
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:22553
0x9d15ff get_partial_spec_bindings
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:23366
0x9f98fa process_partial_specialization
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:4883
0x9f9c45 push_template_decl_real(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:5619
0x9fbeb7 push_template_decl_real(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:5846
0x9fbeb7 push_template_decl(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:5848
0x9fbeb7 push_template_decl(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:5846
0x9fbeb7 maybe_process_partial_specialization(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/pt.c:1014
0x98d054 cp_parser_class_head
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:24021
0x98d054 cp_parser_class_specifier_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:23362
0x98d9d8 cp_parser_class_specifier
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:23686
0x98d9d8 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:17431
0x98e944 cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:14124
0x9b0ba8 cp_parser_single_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:28177
0x9b0f3d cp_parser_template_declaration_after_parameters
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:27860
0x9b188e cp_parser_explicit_template_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:28106
0x9b188e cp_parser_template_declaration_after_export
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:28125
0x9b4459 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/parser.c:13187

It may be a duplicate of PR89480, though.

[Bug fortran/90169] New: allocatable character in type

[menospaamthereaper at hotmail dot com]

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

Bug ID: 90169
   Summary: allocatable character in type
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: menospaamthereaper at hotmail dot com
  Target Milestone: ---

The following code does not produce the correct result on gfortran 7.3.0 (and
probably other versions):

 Program Main
   implicit none
   type str
  character(len=:),allocatable :: CStr(:)
end type
type(str) :: tstr

allocate(character(len=2) :: tstr%CStr(2))

tstr%CStr(1) = "20"
tstr%CStr(2) = "30"

print *,'First: ',tstr%CStr(1)   
print *,'Second:',tstr%CStr(2) 
 End Program Main

The expected result is

 First: 20  
 Second:30 

but the actual result is

 First: 30  
 Second:30 

Note that this works as expected if CStr is not inside of a type. The details
used in this example of the length, etc. do not matter.

(This problem is also listed in 78578 but was not perhaps properly discussed
and so was marked resolved / invalid)

[Bug rtl-optimization/90168] New: Unstable register allocation result for same source code

[fxue at os dot amperecomputing.com]

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

Bug ID: 90168
   Summary: Unstable register allocation result for same source
code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

Supposed a function as the following, in which 'cond', 'S1' and 'S2' are
completely irrelevant, means they do not access same variables(in term of RA,
they own separate live range set).

  f1()
  { 
  if (cond) {
  S1
  } else {
  S2
  }
  }

Ideally, we can expect that register allocation on 'S1'is totally independent
of 'S2', w or w/o which makes no difference. Its result should be same as below
function consisting of only 'S1':

  f2()
  {
  S1
  }

But we found gcc does not has this property. Strictly speaking, this is not a
bug, but exposes some kind of instability in code generation, has
undeterminable impact on some optimization, such as inlining. 

A real example code is listed here (-m64 -O3, for x86-64). Besides different
register number assignments, RA generates different amount of register spills
for 'CODES', foo() has 3 spills and foo1() has only 2.


  int value[10];
  int count;
  int user1;

  int fncall(void);

  #define CODES \
  int i; \
  int sum = 0; \
  int lv_in_1 = value[1]; \
  int lv_in_2 = value[2]; \
  int lv_in_3 = value[3]; \
  int lv_in_4 = value[4]; \
  int lv_in_5 = value[5]; \
  int lv_in_6 = value[6]; \
  int lv_in_7 = value[7]; \
\
  for (i = 0; i < count; i++) { \
  int j; \
  sum += lv_in_1; \
  sum += lv_in_2; \
  sum += lv_in_3; \
  sum += lv_in_4; \
  sum += lv_in_5; \
  sum += lv_in_6; \
  sum += lv_in_7; \
  \
  for (j = 0; j < 16; j++) { \
  fncall(); \
  sum += lv_in_1 ^ j; \
  sum += lv_in_2 ^ j; \
  sum += lv_in_3 ^ j; \
  sum += lv_in_4 ^ j; \
  sum += lv_in_5 ^ j; \
  sum += lv_in_6 ^ j; \
  sum += lv_in_7 ^ j; \
  } \
\
  lv_in_1 ^= i; \
  lv_in_2 ^= i; \
  lv_in_3 ^= i; \
  lv_in_4 ^= i; \
  lv_in_5 ^= i; \
  lv_in_6 ^= i; \
  lv_in_7 ^= i; \
  } \
  user1 = sum

  void foo()
  {
  CODES;
  }

  int cond;
  int user2;

  void foo1()
  {
  if (cond == 5) {
  CODES;
  } else {
  unsigned long long i, j;

  for (i = 0; i < 1; i++) {
  for (j = 0; j < 1; j++) {
  user2 += i * j;
  }
  }
  }
  }

Investigation shows this is related to integer-based frequency normalization
(REG_FREQ_FROM_BB) used by RA, which always rounds up a small frequency (less
than 1) to 1. In foo1(), introduction of new code makes profile counts of CODES
be decreased, so that impact of frequency normalization error becomes more
significant and actually distorts original proportion of profile counts among
basic blocks in CODES. For example, in foo(), two blocks have counts of 3 and
100 receptively, and in foo1(), they become 0.3 and 10, after rounding up, they
are 1 and 10, thus proportion is changed from (3 vs 100) to (1 vs 10).

Possible solution might be to adjust two scale factors used by REG_FREQ_FROM_BB
: REG_FREQ_MAX and BB_FREQ_MAX, or to use float type to hold frequency?

[Bug fortran/90166] Compiler Fails at Assembler

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Fri, Apr 19, 2019 at 01:09:25AM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> This survives regression testing, but boy is it ugly.
> 
> Index: decl.c
> ===
> --- decl.c  (revision 270181)
> +++ decl.c  (working copy)
> @@ -6103,6 +6103,19 @@ gfc_match_prefix (gfc_typespec *ts)
>   if (!gfc_notify_std (GFC_STD_F2008, "MODULE prefix at %C"))
> goto error;
> 
> + if (gfc_current_state () != COMP_MODULE
> + && gfc_current_state () != COMP_SUBMODULE 
> + && gfc_current_state () != COMP_INTERFACE
> + && gfc_current_state () != COMP_CONTAINS

This is likely incorrect.  A CONTAINS can appear in the program,
a subroutine, or function.  Need to check that the CONTAINS is 
with a module.

That is, someone could do

  function foo
 contains
   module subroutine bar
   end subroutine bar
   end function foo

[Bug translation/90164] wrong tense in ABI change diagnostic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  There seems to be little consistency between "changes" and "has
changed" -- it's 11 vs 6.  But "has changed" seems more appropriate here
since/when it's still in effect in the current version.

$ grep " change[ds] " gcc/po/gcc.pot | grep ABI
msgid "AVX512F vector argument without AVX512F enabled changes the ABI"
msgid "AVX512F vector return without AVX512F enabled changes the ABI"
msgid "AVX vector argument without AVX enabled changes the ABI"
msgid "AVX vector return without AVX enabled changes the ABI"
msgid "SSE vector argument without SSE enabled changes the ABI"
msgid "SSE vector return without SSE enabled changes the ABI"
msgid "MMX vector argument without MMX enabled changes the ABI"
msgid "MMX vector return without MMX enabled changes the ABI"
"the ABI of passing struct with a flexible array member has changed in GCC 4.4"
msgid "the ABI of passing union with long double has changed in GCC 4.4"
"the ABI of passing structure with complex float member has changed in GCC 4.4"
"the ABI for passing parameters with %d-byte alignment has changed in GCC 4.6"
"empty class %qT parameter passing ABI changes in %<-fabi-version=12%> (GCC 8)"
msgid "target attribute or pragma changes AltiVec ABI"
msgid "target attribute or pragma changes darwin64 ABI"
"the ABI of passing aggregates with %d-byte alignment has changed in GCC 5"
msgid "the ABI of passing homogeneous float aggregates has changed in GCC 5"

[Bug fortran/90166] Compiler Fails at Assembler

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Fri, Apr 19, 2019 at 12:01:55AM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90166
> 
> --- Comment #2 from Steve Kargl  ---
> On Thu, Apr 18, 2019 at 11:55:51PM +, sgk at troutmask dot
> apl.washington.edu wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90166
> > 
> > --- Comment #1 from Steve Kargl  
> > ---
> > ndex: decl.c
> > ===
> > --- decl.c  (revision 270181)
> > +++ decl.c  (working copy)
> > @@ -7598,6 +7598,13 @@ gfc_match_subroutine (void)
> >if (m != MATCH_YES)
> >  return m;
> > 
> > +  if (current_attr.module_procedure == 1
> > +  && gfc_current_state () != COMP_MODULE)
> 
> This isn't quite right.  A module subroutine can appear in
> an interface statement.
> 

This survives regression testing, but boy is it ugly.

Index: decl.c
===
--- decl.c  (revision 270181)
+++ decl.c  (working copy)
@@ -6103,6 +6103,19 @@ gfc_match_prefix (gfc_typespec *ts)
  if (!gfc_notify_std (GFC_STD_F2008, "MODULE prefix at %C"))
goto error;

+ if (gfc_current_state () != COMP_MODULE
+ && gfc_current_state () != COMP_SUBMODULE 
+ && gfc_current_state () != COMP_INTERFACE
+ && gfc_current_state () != COMP_CONTAINS
+ && !(gfc_state_stack->state == COMP_FUNCTION
+  && (gfc_state_stack->previous->state == COMP_INTERFACE
+   || gfc_state_stack->previous->state == COMP_CONTAINS)))
+   {
+ gfc_error ("MODULE prefix at %C found outside of a module, "
+"submodule, or INTERFACE");
+ goto error;
+   }
+
  current_attr.module_procedure = 1;
  found_prefix = true;
}

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-19
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The variant(T&&) constructor is being selected by overload resolution, because
we talk to apply this constraint:

remove_­cvref_­t is neither a specialization of in_­place_­type_­t nor a
specialization of in_­place_­index_­t,

[Bug fortran/90166] Compiler Fails at Assembler

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Thu, Apr 18, 2019 at 11:55:51PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90166
> 
> --- Comment #1 from Steve Kargl  ---
> ndex: decl.c
> ===
> --- decl.c  (revision 270181)
> +++ decl.c  (working copy)
> @@ -7598,6 +7598,13 @@ gfc_match_subroutine (void)
>if (m != MATCH_YES)
>  return m;
> 
> +  if (current_attr.module_procedure == 1
> +  && gfc_current_state () != COMP_MODULE)

This isn't quite right.  A module subroutine can appear in
an interface statement.

[Bug fortran/90166] Compiler Fails at Assembler

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #1 from Steve Kargl  ---
ndex: decl.c
===
--- decl.c  (revision 270181)
+++ decl.c  (working copy)
@@ -7598,6 +7598,13 @@ gfc_match_subroutine (void)
   if (m != MATCH_YES)
 return m;

+  if (current_attr.module_procedure == 1
+  && gfc_current_state () != COMP_MODULE)
+{
+  gfc_error ("MODULE SUBROUTINE found outside of a module at %C");
+  return MATCH_ERROR;
+}
+
   if (get_proc_name (name, &sym, false))
 return MATCH_ERROR;

[Bug fortran/90166] Compiler Fails at Assembler

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug c/90167] New: invalid example in GCC documentation wrt. effective type rules

[lersek at redhat dot com]

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

Bug ID: 90167
   Summary: invalid example in GCC documentation wrt. effective
type rules
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lersek at redhat dot com
  Target Milestone: ---

The gcc manual says the following under "-fstrict-aliasing"
:

> union a_union {
>   int i;
>   double d;
> };
>
> [...]
>
> Similarly, access by taking the address, casting the resulting pointer
> and dereferencing the result has undefined behavior, even if the cast
> uses a union type, e.g.:
>
> int f() {
>   double d = 3.0;
>   return ((union a_union *) &d)->i;
> }

I think this particular statement does not match the C99 standard. The
C99 standard says, under 6.5p7:

> An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types:
> - a type compatible with the effective type of the object,
> - a qualified version of a type compatible with the effective type of
>   the object,
> - a type that is the signed or unsigned type corresponding to the
>   effective type of the object,
> - a type that is the signed or unsigned type corresponding to a
>   qualified version of the effective type of the object,
> - an aggregate or union type that includes one of the aforementioned
>   types among its members (including, recursively, a member of a
>   subaggregate or contained union), or
> - a character type.

The object whose stored value we're accessing is the local variable "d".

The effective type of the local variable "d" is "double". (Because it
has a declared type, and so the declared type is the effective type.)

The expression (*(union a_union *)&d) is an lvalue expression.

The expression (*(union a_union *)&d) has type "union a_union", which is
a union type that includes "double" among its members (6.5p7 bullet 5).

The "double" type of the union member in question is compatible with the
"double" type of the object whose stored value we're accessing (6.5p7
bullet 1). That's because both "double" types are identical.

Finally, expression (((union a_union *)&d)->i) is equivalent to
((*(union a_union *)&d).i).

Therefore the example given by the gcc documentation is valid C, in my
opinion.

[Bug rtl-optimization/79405] [8/9/10 Regression] Infinite loop in fwprop

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #13 from Segher Boessenkool  ---
We have a fine workaround, committed ages ago, so this isn't a P1 anymore.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #56 from Peter Bergner  ---
I committed the RA fix.  Unassigning myself now.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[bergner at gcc dot gnu.org]

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

--- Comment #55 from Peter Bergner  ---
Author: bergner
Date: Thu Apr 18 22:14:17 2019
New Revision: 270448

URL: https://gcc.gnu.org/viewcvs?rev=270448&root=gcc&view=rev
Log:
PR rtl-optimization/87871
* ira-lives.c (make_object_dead): Don't add conflicts to
TOTAL_CONFLICT_HARD_REGS for register ignore_reg_for_conflicts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-lives.c

[Bug fortran/90166] New: Compiler Fails at Assembler

[cgarrett01 at bellflight dot com]

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

Bug ID: 90166
   Summary: Compiler Fails at Assembler
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cgarrett01 at bellflight dot com
  Target Milestone: ---

If I try to compile the following code (filename = hello.f90)

   module subroutine hello

   write(*,*) "hello"

   end subroutine

with 'gfortran -c hello.f90' I get the assembler error

   /tmp/ccrIt4g8.s: Assembler messages:
   /tmp/ccrIt4g8.s:10: Error: junk at end of line, first unrecognized character
is `('
   /tmp/ccrIt4g8.s:11: Error: unrecognized symbol type ""
   /tmp/ccrIt4g8.s:11: Error: junk at end of line, first unrecognized character
is `('
   /tmp/ccrIt4g8.s:12: Error: invalid character '(' in mnemonic
   /tmp/ccrIt4g8.s:42: Error: expected comma after name `__' in .size directive

It is incorrect code, but I think the compiler should give the error, not the
assembler.  In this case, it's incorrect to have the module attribute in front
of "subroutine hello".

[Bug translation/79878] verify_gimple_assign_single: replace error with internal_error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
This predates pr90149 but that one has more detail so I'm resolving this as a
dupe of the latter.

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

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[msebor at gcc dot gnu.org]

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

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

[Bug libstdc++/90165] New: std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

Bug ID: 90165
   Summary: std::variant constructs wrong alternative
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

struct none { none() = delete; };
struct any { template  any(T&&) {} };

int main()
{
  std::variant v(std::in_place_type);
  std::variant v2(std::in_place_index<0>);
  printf("constructed alternatives %zu and %zu\n", v.index(), v2.index());
}

This program should be ill-formed, but instead compiles and outputs:

constructed alternatives 1 and 1

[Bug libstdc++/78113] std::variant and std::visit's current implementations do not get optimized out (compared to "recursive visitation")

[quicknir at gmail dot com]

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

--- Comment #5 from Nir Friedman  ---
Jonathan, I saw you just change the status of this. Michael Park's and I work
has resulted in a different implementation of std::visit which has much better
codegen; also backed by performance numbers. This also improves perf for things
like comparison, since internally this uses the same mechanisms. We've actually
been trying to contact someone from clang and gcc standard libraries about this
for a while to no success... please feel free to email me at quick...@gmail.com
to get the convo going about how to maybe merge some of that code in. Happy to
help with the actual merging work as well.

[Bug c/90081] stdint constant macros evaluating to wrong type

[harald at gigawatt dot nl]

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

--- Comment #10 from Harald van Dijk  ---
(In reply to jos...@codesourcery.com from comment #9)

Thanks, appreciate the explanation. I guess I'm less willing to trust that the
interpretation that makes sense is the one that's intended, but I can see that
either you're right or the requirements are unclear, and either of those leads
to the same conclusion here.

[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law  ---
So results from playing with do_rpo_vn.

Running do_rpo_vn on the full function is slower than lattice cprop.  It's on
the order of a percent or two.  I mostly did this because it was trivial to
code up, verify it fixed the regression and see if performance was even in the
right ballpark.

Then I did a version which only called do_rpo_vn on blocks with single
predecessors that had PHI nodes.  ie, the vast majority of degenerate PHI
cases.  That still fixed the regression (as expected).  Performance was ever so
slightly worse than doing a full function lattice cprop.  Overall it's on the
order of .03%.  THe resulting code is effectively the same as doing lattice
cprop.

So my current thought is to drop all the phi-only cprop code and use the
lattice cprop instead, adding a single call to the pass between DOM and path
isolation.  The compile-time hit is going to be small, on the order of .4%.  I
could be convinced to use rpo_vn as well -- it's ultimately a wash in terms of
compile-time and resulting code.

[Bug c/90081] stdint constant macros evaluating to wrong type

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
On Thu, 18 Apr 2019, harald at gigawatt dot nl wrote:

> > I think expanding the macro to its argument is clearly correct here, 
> > including for UINT8_C, as the interpretation suggested in DR#456 
> > regarding having an unsigned type in #if leads to the obvious absurdities 
> > I described in reflector message 13320 (15 May 2014).
> 
> That pre-dates the DR's proposed committee response, which is from Oct 2014.

I don't think the committee response paid any attention to the points I 
raised; I think a supposition that compiler magic would be needed is 
inaccurate as the proper reading of the changes in the C99 TCs is that 
they specifically avoid needing such magic.  In any case, it says nothing 
about the types of these macros in #if.  I agree with the conclusion that 
there is no defect (as I think the common-sense reading of the standard 
text is that the promoted type is the result of promoting outside #if, 
just like the limits are the limits of the type outside #if - the limits 
being otherwise would contradict express normative text about the values 
of certain macros).

[Bug c/90081] stdint constant macros evaluating to wrong type

[harald at gigawatt dot nl]

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

--- Comment #8 from Harald van Dijk  ---
(In reply to jos...@codesourcery.com from comment #7)
> No, INT8_C(5) must expand to have type int, not int_least8_t, if 
> int_least8_t promotes to int.  See 7.20.4#3, "The type of the expression 
> shall have the same type as would an expression of the corresponding type 
> converted according to the integer promotions.".  *Not* the type itself, 
> the promoted type.

Good point, my earlier suggested definition is missing an extra + to handle
that.

> I think expanding the macro to its argument is clearly correct here, 
> including for UINT8_C, as the interpretation suggested in DR#456 
> regarding having an unsigned type in #if leads to the obvious absurdities 
> I described in reflector message 13320 (15 May 2014).

That pre-dates the DR's proposed committee response, which is from Oct 2014.

Are absurdities not just the natural result of requiring all preprocessor
number processing to be done in (u)intmax_t? We already have the situation that
e.g. 0U > -1LL is required (under obvious assumptions about type widths) to
give different results in #if expressions than outside of them, and GCC
implements that.

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Thu Apr 18 20:26:07 2019
New Revision: 270447

URL: https://gcc.gnu.org/viewcvs?rev=270447&root=gcc&view=rev
Log:
PR middle-end/89797 - ICE on a vector_size (1LU << 33) int variable 

gcc/ChangeLog:
* tree.h (TYPE_VECTOR_SUBPARTS): Use HOST_WIDE_INT_1U.
* config/aarch64/aarch64.c (aarch64_simd_vector_alignment): Avoid
assuming type size fits in SHWI.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/tree.h

[Bug translation/90148] Closing quote in wrong position in plugin.c

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
From m68k.c:

error ("%<-mpcrel%> %<-fPIC%> is not currently supported on selected cpu");

[Bug translation/90162] exclamation mark in diagnostic!!!!!1111!!!!

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The -Wformat-diag checker I'm working on detects this.  The
capitalization should also be corrected.

[Bug translation/90164] New: wrong tense in ABI change diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 90164
   Summary: wrong tense in ABI change diagnostic
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From i386.c:

  warning (OPT_Wabi, "empty class %qT parameter passing ABI "
   "changes in %<-fabi-version=12%> (GCC 8)", type);

Since the current GCC version is 9, "changes" should be "changed".

[Bug translation/90158] aarch64: wrong quotation in diagnostics

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||90156

--- Comment #3 from Martin Sebor  ---
See pr90156 for the general request to add a checker for these misquoting
patterns.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90156
[Bug 90156] add linter check suggesting to replace %<%s%> with %qs

[Bug c/90081] stdint constant macros evaluating to wrong type

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
On Sat, 13 Apr 2019, bafap5 at yahoo dot com wrote:

>   int x = sizeof ((int8_t) 5); /* Correct, gives 1 */
>   int y = sizeof (INT8_C(5));  /* Incorrect, gives 4 */

No, INT8_C(5) must expand to have type int, not int_least8_t, if 
int_least8_t promotes to int.  See 7.20.4#3, "The type of the expression 
shall have the same type as would an expression of the corresponding type 
converted according to the integer promotions.".  *Not* the type itself, 
the promoted type.

I think expanding the macro to its argument is clearly correct here, 
including for UINT8_C, as the interpretation suggested in DR#456 
regarding having an unsigned type in #if leads to the obvious absurdities 
I described in reflector message 13320 (15 May 2014).

[Bug translation/90163] New: untranslated placeholder in warn_once_call_ms2sysv_xlogues

[roland.illig at gmx dot de]

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

Bug ID: 90163
   Summary: untranslated placeholder in
warn_once_call_ms2sysv_xlogues
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From i386.c:

static void warn_once_call_ms2sysv_xlogues (const char *feature)
{
  static bool warned_once = false;
  if (!warned_once)
{
  warning (0, "%<-mcall-ms2sysv-xlogues%> is not compatible with %s",
   feature);
  warned_once = true;
}
}

warn_once_call_ms2sysv_xlogues ("__builtin_eh_return");
warn_once_call_ms2sysv_xlogues ("static call chains");
warn_once_call_ms2sysv_xlogues ("-fsplit-stack");

The placeholder "feature" can be practically anything. The name of an
intrinsic, a fragment of an English sentence or a command line option.

The fragment of the English sentence doesn't make sense when it is translated.
The %s placeholder must be a %qs, and then the diagnostic becomes:

%<-mcall-ms2sysv-xlogues%> is not compatible with %

This breaks the English sentence and is impossible to translate into other
languages.

[Bug translation/90156] add linter check suggesting to replace %<%s%> with %qs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I'm working on it for GCC 10.

[Bug translation/90160] missing quote in diagnostic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90158
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed.  See also pr90158 for similar issues.

[Bug translation/90162] New: exclamation mark in diagnostic!!!!!1111!!!!

[roland.illig at gmx dot de]

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

Bug ID: 90162
   Summary: exclamation mark in diagnostic!
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From h8300.c:

  warning (OPT_mno_exr, "%<-mno-exr%> valid only with %<-ms%> or "
   "%<-msx%> - Option ignored!");

Diagnostics should not contain any exclamation mark.

[Bug translation/90160] missing quote in diagnostic

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
From gcn.c, one more:

  error ("duplicated parameter specifier %s in amdgpu_hsa_kernel "
 "attribute", str);

[Bug fortran/90150] wrong output produced by float format fX.Y descriptor following translated scientific format XpeY.Z

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Thu, Apr 18, 2019 at 07:48:25PM +, perini at wisc dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90150
> 
> --- Comment #4 from federico  ---
> uhm so that is my fault, I guess - sorry about that.
> 
> Apparently this is what the FORTRAN standard features. Still,
> I’m a bit confused that the P descriptor produces only a format
> change with the E format, while leading to a _value_ change with F.
> 

It is not a value in change.  You have asked the compiler 
to scale the output of the F edit descriptor.  It is 
assumed that you, the programmer, know that the output
value has been scaled.  For example, 1p causes b=10.0
to be output as 100.000, but you know the true value is
10.000.

[Bug c++/90161] New: GCC does not always dllexport constexpr member variables in C++17 mode

[m101010a at gmail dot com]

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

Bug ID: 90161
   Summary: GCC does not always dllexport constexpr member
variables in C++17 mode
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
struct __attribute__((dllexport)) foo {
static constexpr int i = 3;
};
constexpr int foo::i;
$ cat y.cpp
struct __attribute__((dllimport)) foo {
static constexpr int i = 3;
};
int main() {
volatile auto v = &foo::i;
}
$ i686-w64-mingw32-g++ x.cpp -shared -o libx.dll
$ i686-w64-mingw32-g++ y.cpp -o y.exe -L. -lx
$ rm -f libx.dll y.exe
$ i686-w64-mingw32-g++ -std=c++17 x.cpp -shared -o libx.dll
$ i686-w64-mingw32-g++ -std=c++17 y.cpp -o y.exe -L. -lx
/usr/lib/gcc/i686-w64-mingw32/8.3.0/../../../../i686-w64-mingw32/bin/ld:
/tmp/cc8oSAlw.o:y.cpp:(.text+0xf): undefined reference to `_imp___ZN3foo1iE'
collect2: error: ld returned 1 exit status
$ i686-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/8.3.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: /home/marc/.cache/aurman/mingw-w64-gcc/src/gcc/configure
--prefix=/usr --libexecdir=/usr/lib --target=i686-w64-mingw32
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-threads=posix --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl
--enable-lto --enable-dw2-exceptions --disable-sjlj-exceptions --enable-libgomp
--disable-multilib --enable-checking=release
Thread model: posix
gcc version 8.3.0 (GCC) 


This difference is likely because in C++17, foo::i is an inline variable due to
being constexpr.  If there is a function in libx.dll which uses foo::i's
address, the address is exported properly and linking y.exe works fine.  This
works fine on Linux using the visibility attribute.  GCC appears to have
stopped exporting foo::i in GCC 7 (https://godbolt.org/z/yatDtS).

[Bug c++/87651] [8 Regression] inner class with template template friend declaration of same name fails to compile

[haining.cpp at gmail dot com]

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

--- Comment #5 from Ryan R Haining  ---
Failing on 8.3.0 https://wandbox.org/permlink/69kAYkUWgFD5TTxs

[Bug translation/90158] aarch64: wrong quotation in diagnostics

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  Let me add the \"%s\" pattern to my diagnostic checker to flag
outside %< and %>.

I'll see if also flagging plain either %s or " %s " wouldn't cause too many
false positives for valid uses.

[Bug translation/90160] missing quote in diagnostic

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
From gcn.c:

  error ("unknown specifier %s in amdgpu_hsa_kernel attribute", str);

[Bug c++/87652] [8 Regression] inner class template of outer class template can't access friend's protected data member

[haining.cpp at gmail dot com]

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

--- Comment #7 from Ryan R Haining  ---
Still fails in 8.3.0 https://wandbox.org/permlink/69kAYkUWgFD5TTxs

[Bug fortran/90150] wrong output produced by float format fX.Y descriptor following translated scientific format XpeY.Z

[perini at wisc dot edu]

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

--- Comment #4 from federico  ---
uhm so that is my fault, I guess - sorry about that.

Apparently this is what the FORTRAN standard features. Still, I’m a bit
confused that the P descriptor produces only a format change with the E format,
while leading to a _value_ change with F.



Federico Perini

From: sgk at troutmask dot apl.washington.edu 
Sent: Thursday, April 18, 2019 9:40:05 PM
To: Federico Perini
Subject: [Bug fortran/90150] wrong output produced by float format fX.Y
descriptor following translated scientific format XpeY.Z

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

--- Comment #3 from Steve Kargl  ---
On Thu, Apr 18, 2019 at 07:27:31PM +, perini at wisc dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90150
>
> --- Comment #2 from federico  ---
> Number b=10.0, so in format f8.3 it should always be output as “  10.000” ?

Ahem, no.  1p changes the scale factor by 10.  2p changes
scale factor to 100.  The scale factor is a property of
the output connection.  So, 1p and 2p apply to both e10.3
and f8.3 in your format strings.

>> $ a.exe
>>  0.100E+04   10.000 ! "(1e10.3,1x,f8.3)"
>>  1.000E+03  100.000 ! "(1pe10.3,1x,f8.3)"

Perhaps, you want '(1pe10.3,1x,0pf8.3)'

>>  10.00E+02 1000.000 ! "(2pe10.3,1x,f8.3)"

Perhaps, you want '(2pe10.3,1x,0pf8.3)'

> Can you explain what you think the compiler should output?
>
> The P edit descriptor affects the entire string not just
> the immediately following edit descriptor.

--
You are receiving this mail because:
You reported the bug.

[Bug fortran/90150] wrong output produced by float format fX.Y descriptor following translated scientific format XpeY.Z

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Thu, Apr 18, 2019 at 07:27:31PM +, perini at wisc dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90150
> 
> --- Comment #2 from federico  ---
> Number b=10.0, so in format f8.3 it should always be output as “  10.000” ?

Ahem, no.  1p changes the scale factor by 10.  2p changes
scale factor to 100.  The scale factor is a property of
the output connection.  So, 1p and 2p apply to both e10.3
and f8.3 in your format strings.

>> $ a.exe
>>  0.100E+04   10.000 ! "(1e10.3,1x,f8.3)"
>>  1.000E+03  100.000 ! "(1pe10.3,1x,f8.3)"

Perhaps, you want '(1pe10.3,1x,0pf8.3)'

>>  10.00E+02 1000.000 ! "(2pe10.3,1x,f8.3)"

Perhaps, you want '(2pe10.3,1x,0pf8.3)'

> Can you explain what you think the compiler should output?
> 
> The P edit descriptor affects the entire string not just
> the immediately following edit descriptor.

[Bug translation/90160] missing quote in diagnostic

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
From csky.c:

warning (0, "cpu %s is not based on arch %s, ignoring the arch",
 csky_selected_cpu->name, csky_selected_arch->name);

[Bug translation/90160] New: missing quote in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 90160
   Summary: missing quote in diagnostic
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From arm.c:

error ("%s incompatible with %<-mword-relocations%>", flag);

The first %s is also a command line option and thus should be %qs.

[Bug fortran/90150] wrong output produced by float format fX.Y descriptor following translated scientific format XpeY.Z

[perini at wisc dot edu]

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

--- Comment #2 from federico  ---
Number b=10.0, so in format f8.3 it should always be output as “  10.000” ?

Federico Perini

From: kargl at gcc dot gnu.org 
Sent: Thursday, April 18, 2019 8:46:19 PM
To: Federico Perini
Subject: [Bug fortran/90150] wrong output produced by float format fX.Y
descriptor following translated scientific format XpeY.Z

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to federico from comment #0)
> Created attachment 46201 [details]
> Simple test program that reproduces the error
>
> Hi,
>
> just found this error in floating point string format in gfortran 7.4.0.
>
> The error affects floating point output (fX.Y), ONLY when this follows a
> scientific output with heading non-zeros (ZpeX.Y).
>
> The fX.Y output number is multiplied i.e. translated by as many digits as in
> the previous scientific specifier. The issue seems to happen only when both
> are part of a same string format.
>
> The attached program prints the same two numbers (1000.0, 10.0) three times
> with the following formats:
> A = 1000.0
> b = 10.0
>
> $ a.exe
>  0.100E+04   10.000 ! "(1e10.3,1x,f8.3)"
>  1.000E+03  100.000 ! "(1pe10.3,1x,f8.3)"
>  10.00E+02 1000.000 ! "(2pe10.3,1x,f8.3)"
>
>

Can you explain what you think the compiler should output?

The P edit descriptor affects the entire string not just
the immediately following edit descriptor.

--
You are receiving this mail because:
You reported the bug.

[Bug translation/90148] Closing quote in wrong position in plugin.c

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
From arm-builtins.c:

  fatal_error (input_location,
   "You must enable NEON instructions"
   " (e.g. %<-mfloat-abi=softfp%> %<-mfpu=neon%>)"
   " to use these intrinsics.");

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
FWIW, I'm working on a -Wformat enhancement to detect this and some of the
other translation problems you have pointed out.  I'm also going through
gcc.pot and looking for patterns like this to detect myself but having them
pointed out by someone actually doing the translation is very helpful.  Thank
you!

As for this specific error (and others like it) in tree-cfg.c and a few other
files, they are issued for failures detected by internal consistency checks
that ultimately do trigger an internal compiler error.  In my patch I disable
the detection of these problems via #pragma GCC diagnostic ignored
"-Wformat-diag" but another option is to simply fix them:

  error ("%qs of non-mode-precision operand", "BIT_FIELD_REF");

The challenge with doing it that it would changing a fair number of messages
and in some cases, make the format strings look pretty cryptic (by replacing
multiple strings with %s directives).

[Bug c++/90159] New: Poor warning for an ambiguous reference

[david.bolvansky at gmail dot com]

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

Bug ID: 90159
   Summary: Poor warning for an ambiguous reference
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

Test case:
#include 
#include 

using namespace std;

struct sort_heap
{
bool operator()(const int* lhs, const int* rhs) const
{
return *lhs < *rhs;
}
};

void foo()
{
std::priority_queue, sort_heap> tmp;
}

: In function 'void foo()':

:16:59: error: template argument 3 is invalid

   16 | std::priority_queue, sort_heap> tmp;

  |   ^

:16:61: warning: unused variable 'tmp' [-Wunused-variable]

   16 | std::priority_queue, sort_heap> tmp;

  | ^~~


GCC does not provide enough info why argument is really invalid. Clang produces
more info, which explain the root problem:

Clang
:16:50: error: reference to 'sort_heap' is ambiguous

std::priority_queue, sort_heap> tmp;

 ^

:6:8: note: candidate found by name lookup is 'sort_heap'

struct sort_heap

   ^

/opt/compiler-explorer/gcc-8.3.0/lib/gcc/x86_64-linux-gnu/8.3.0/../../../../include/c++/8.3.0/bits/algorithmfwd.h:576:5:
note: candidate found by name lookup is 'std::sort_heap'

sort_heap(_RAIter, _RAIter, _Compare);

^

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #70 from Bernd Edlinger  ---
Yes, thanks, now switching to your latest patch.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[segher at gcc dot gnu.org]

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

--- Comment #54 from Segher Boessenkool  ---
(In reply to Wilco from comment #52)
> (In reply to Segher Boessenkool from comment #48)
> > With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
> > That does not fix this PR though :-/
> 
> But it does fix most of the codesize regression.

Yes, and it often creates *better* code, as far as I can see.

> The shrinkwrapping testcase
> seems a preexisting problem that was exposed by the combine changes,

It is.

> so it
> doesn't need to hold up the release. The regalloc change might fix
> addr-modes-float.c too.

I'd like to see the RA fix in GCC 9.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[segher at gcc dot gnu.org]

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

--- Comment #53 from Segher Boessenkool  ---
(In reply to Richard Earnshaw from comment #51)
> In the more general case splitting this would produce worse code, not
> better, since then we'd end up with two instructions rather than one.

Sure, it _often_ is good to have it merged.  Quite clearly more often than
not it's good, so if you have to pick only one way, this is the way to go.

Hopefully we can do better though.  But not for stage 4, sure.

[Bug translation/90156] add linter check suggesting to replace %<%s%> with %qs

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
To fix bug 90158 thoroughly, please also add \"%s\" to the forbidden string
literals.

[Bug translation/90158] aarch64: wrong quotation in diagnostics

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
The above are not the only occurrences in aarch64.c, there is at least one
more. It's easy to find: \"%s\" or a simple %s surrounded by spaces on both
ends.

See also bug 90156.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #46198|0   |1
is obsolete||

--- Comment #69 from Jakub Jelinek  ---
Created attachment 46202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46202&action=edit
gcc9-pr89093.patch

So, here is the above patch updated in the one libgo hunk.

[Bug translation/90158] New: aarch64: wrong quotation in diagnostics

[roland.illig at gmx dot de]

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

Bug ID: 90158
   Summary: aarch64: wrong quotation in diagnostics
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From aarch64.c:

error ("invalid name (\"%s\") in % pragma or attribute",
str);

Here, the "%s" should be replaced with %qs, to conform to the GCC guidelines
for diagnostics, see
https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html#Quoting.


error ("invalid feature modifier %s of value (\"%s\") in "
   "% pragma or attribute", invalid_extension.c_str (), str);

The %s must be %qs here.

[Bug translation/90157] New: aarch64: unnecessary abbreviation in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 90157
   Summary: aarch64: unnecessary abbreviation in diagnostic
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From aarch64.c:

error ("missing arg for %<-mbranch-protection=%>");

The word "arg" is only allowed in code, not in diagnostics. For example,
https://gcc.gnu.org/codingconventions.html#Diagnostics always talks about
"arguments" never about "args".

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #68 from Jakub Jelinek  ---
Comment on attachment 46200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46200
updated patch

I believe the second hunk in libgo/runtime/go-unwind.c is incorrect, that is on
code not guarded with #ifdef __ARM_EABI_UNWINDER__, so that will break all
other targets.
I can do a distro build which includes --enable-checking=release
bootstrap/regtest within ~ 24 hours or so, but all that is done without me
having easy access to it, so if it works, fine, if it doesn't, I'll just know
it does not.

[Bug translation/90156] New: add linter check suggesting to replace %<%s%> with %qs

[roland.illig at gmx dot de]

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

Bug ID: 90156
   Summary: add linter check suggesting to replace %<%s%> with %qs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

For GCC 9, all occurrences of %<%s%> had been replaced with %qs.

That must have been before 2019-01-08 since on that day the following code
appeared in aarch64.c:

error ("invalid arg %<%s%> for %<-mbranch-protection=%>", str);

To prevent this unnecessarily verbose %<%s%> in the future,
check-internal-format-escaping.py should check for this as well and suggest to
replace it with the simpler %qs.

[Bug fortran/90150] wrong output produced by float format fX.Y descriptor following translated scientific format XpeY.Z

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to federico from comment #0)
> Created attachment 46201 [details]
> Simple test program that reproduces the error
> 
> Hi, 
> 
> just found this error in floating point string format in gfortran 7.4.0. 
> 
> The error affects floating point output (fX.Y), ONLY when this follows a
> scientific output with heading non-zeros (ZpeX.Y).
> 
> The fX.Y output number is multiplied i.e. translated by as many digits as in
> the previous scientific specifier. The issue seems to happen only when both
> are part of a same string format.
> 
> The attached program prints the same two numbers (1000.0, 10.0) three times
> with the following formats: 
> A = 1000.0
> b = 10.0
> 
> $ a.exe
>  0.100E+04   10.000 ! "(1e10.3,1x,f8.3)"
>  1.000E+03  100.000 ! "(1pe10.3,1x,f8.3)"
>  10.00E+02 1000.000 ! "(2pe10.3,1x,f8.3)"
> 
> 

Can you explain what you think the compiler should output?

The P edit descriptor affects the entire string not just
the immediately following edit descriptor.

[Bug target/90155] New: aarch64: too much quoting in diagnostic for %d

[roland.illig at gmx dot de]

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

Bug ID: 90155
   Summary: aarch64: too much quoting in diagnostic for %d
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From aarch64.c:

  if (guard_size != probe_interval)
error ("stack clash guard size %<%d%> must be equal to probing interval "
   "%<%d%>", guard_size, probe_interval);

https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html#Quoting
says:

> Other elements such as numbers that do not refer to numeric constants that 
> appear in the source code should not be quoted.

Therefore the % around the %d should be removed.

[Bug target/90154] New: aarch64: insufficient check for aarch64_stack_protector_guard_reg_str

[roland.illig at gmx dot de]

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

Bug ID: 90154
   Summary: aarch64: insufficient check for
aarch64_stack_protector_guard_reg_str
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From aarch64.c:

  if (opts->x_aarch64_stack_protector_guard_reg_str)
{
  if (strlen (opts->x_aarch64_stack_protector_guard_reg_str) > 100)
  error ("specify a system register with a small string length.");
}

As the German translator I stumbled upon this error message and I had to dig
into the code to find a proper translation for it. Now I have the following
questions:

What are the valid register names?
Is any of these possible names longer than 5 characters?
Why the arbitrary limit on 100 characters?
Where can I find the list of sensible register names to use?

The term "with a small string length" is really confusing. Granted, no one will
ever see this message. Nevertheless, even if I specify "abcde" as the register
name, it will probably be incorrect, and the generated code will be wrong.

I could also launch an Assembly Injection attack on this piece of code by
specifying "0" or "0; halt" or something similar as the register name. I don't
know anything about AArch64 assembly, therefore I'm not the ideal person to
launch this attack. But someone else could.

Having this diagnostic just because of the following code is a lame excuse:

   char buf[150];
   snprintf (buf, 150, "mrs\\t%%0, %s",
aarch64_stack_protector_guard_reg_str);

Why not use a dynamically allocated string? Since this is the GCC code, it
should be even simpler than allocating a local buffer. There's probably an
asprintf lying around.

[Bug target/90153] New: aarch64: unclear diagnostic for stack-protector options

[roland.illig at gmx dot de]

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

Bug ID: 90153
   Summary: aarch64: unclear diagnostic for stack-protector
options
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From aarch64.c:

  if (aarch64_stack_protector_guard == SSP_SYSREG
  && !(opts->x_aarch64_stack_protector_guard_offset_str
   && opts->x_aarch64_stack_protector_guard_reg_str))
{
  error ("both %<-mstack-protector-guard-offset%> and "
 "%<-mstack-protector-guard-reg%> must be used "
 "with %<-mstack-protector-guard=sysreg%>");
}

From reading the diagnostic alone, it could also mean:

-mstack-protector-guard-offset requires -mstack-protector-guard=sysreg
and
-mstack-protector-guard-reg requires -mstack-protector-guard=sysreg

actually it's the other way round:

mstack-protector-guard=sysreg requires both mstack-protector-guard-offset and
mstack-protector-guard-reg to be set.

The term "must be used with" is ambiguous regarding the direction of the "must
be used" here. It could mean "from right to left", or alternatively, "from left
to right".

[Bug translation/90152] untranslated strings in print_z_candidate

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
(In reply to Roland Illig from comment #0)
> Instead of this comment, it would be better to pass the untranslated msgstr
> to print_z_candidate by enclosing the actual string literals with _(...).

Oops, I meant N_(...) of course.

The _(...) would then be inside print_z_candidates.

[Bug translation/90118] Missing space between words

[roland.illig at gmx dot de]

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

--- Comment #5 from Roland Illig  ---
(In reply to Christophe Lyon from comment #3)
> When running the script, it warned in 3 more occurrences in gcc/cp/call.c,
> which I updated too.

By reading the code, I think these instances are correct since the trailing
space is added by this code:

  const char *msg = (msgstr == NULL
 ? ""
 : ACONCAT ((msgstr, " ", NULL)));

There's a much worse problem regarding the first %s though, which I have just
reported in bug 90152.

It would be good if the check-internal-format-escaping.py linter would actually
output what is wrong in the msgid. The number of checks will increase as I'm
trying to translate the rest of GCC 9, therefore it will become more difficult
to guess what is wrong with a translation. Ideally this linter should follow
the GCC guidelines for diagnostics, which are described in
https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html.

[Bug translation/90152] New: untranslated strings in print_z_candidate

[roland.illig at gmx dot de]

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

Bug ID: 90152
   Summary: untranslated strings in print_z_candidate
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From call.c:

  const char *msg = (msgstr == NULL
 ? ""
 : ACONCAT ((msgstr, " ", NULL)));

inform (cloc, "%s%<%D(%T, %T, %T)%> ", msg, fn,
candidate->convs[0]->type,
candidate->convs[1]->type,
candidate->convs[2]->type);

As a translator I have no idea what this first %s might be. It turns out that
by inspecting the call hierarchy, it can be, among others:

  print_z_candidate (0, "  after user-defined conversion:",
 t->cand);

That's a string literal starting with two spaces (rather uncommon I think), and
in addition, this string is never translated, as it does not appear in gcc.pot.

If the msgstr can be translated as a self-contained unit of text in all the
languages into which GCC is translated (which as of 2019 are mainly French and
German), the proper fix is to surround these strings with _(...). If not, each
of these messages needs its own call to inform().

There's even a comment above print_z_candidate:

   NOTE: Unlike most diagnostic functions in GCC, MSGSTR is expected
   to have been run through gettext by the caller.  This wart makes
   life simpler in print_z_candidates and for the translators.  */

Instead of this comment, it would be better to pass the untranslated msgstr to
print_z_candidate by enclosing the actual string literals with _(...). Then,
print_z_candidates could be run in a special test build in which there is an
arbitrary translation for each msgid. Then, gettext(msgstr) must be different
from msgstr itself.

[Bug bootstrap/90132] make bootstrap fails with -O3 (gcc9 snapshot 20190414)

[jayrusman at hotmail dot com]

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

--- Comment #7 from Jason Mancini  ---
Okay! The patch in Comment #1 worked for me. Someone else can fix or reject as
it's not an important bug then.

[Bug ipa/90151] New: 554.roms_r regression on x86_64 at -O2 and generic march/mtune

[jamborm at gcc dot gnu.org]

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

Bug ID: 90151
   Summary: 554.roms_r regression on x86_64 at -O2 and generic
march/mtune
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

My apologies for discovering and reporting this so late, but my
measurements show that 554.roms_r at -O2 and with generic x86_64
march/mtune regressed in performance when compiled with GCC 8 or GCC 9
compared to GCC 7.  On an Intel Sandy Bridge I see 4% slowdown, on an
AMD Zen CPU I see 6.8%, LNT reports almost 4% on Kaby Lake and 5.5% on
Zen: https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch

I have bisected this down to r254885 which is Honza's update of
profile info in IPA-CP:

Author: hubicka
Date: Fri Nov 17 17:41:10 2017
New Revision: 254885

URL: https://gcc.gnu.org/viewcvs?rev=254885&root=gcc&view=rev
Log:

* ipa-cp.c (update_profiling_info): Handle conversion to local
profile.
* tree-cfg.c (execute_fixup_cfg): Do fixup same way as inliner does.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/tree-cfg.c

I compared the number of samples in the hottest functions and arrived
at the following table:

| Object   | Function   | r254884 | r254885 |  diff
|  % |
|--++-+-+---+|
| roms_r_base  | __step2d_mod_MOD_step2d_tile   |  407180 |  409257 |  2077
|  +0.51 |
| roms_r_base  | __pre_step3d_mod_MOD_pre_step3d|  118119 |  134705 | 16586
| +14.04 |
| roms_r_base  | __t3dmix_mod_MOD_t3dmix2   |   85499 |  101650 | 16151
| +18.89 |
| roms_r_base  | __step3d_t_mod_MOD_step3d_t|   85003 |  104599 | 19596
| +23.05 |
| roms_r_base  | __rho_eos_mod_MOD_rho_eos_tile |   74216 |   74746 |   530
|  +0.71 |
| roms_r_base  | __step3d_uv_mod_MOD_step3d_uv_tile |   66393 |   67117 |   724
|  +1.09 |
| roms_r_base  | __rhs3d_mod_MOD_rhs3d  |   62354 |   73321 | 10967
| +17.59 |
| roms_r_base  | __lmd_skpp_mod_MOD_lmd_skpp|   59767 |   70798 | 11031
| +18.46 |
| libm-2.29.so | __ieee754_exp_fma  |   54324 |   56546 |  
|  +4.09 |
| roms_r_base  | __prsgrd_mod_MOD_prsgrd|   48439 |   56413 |  7974
| +16.46 |
| roms_r_base  | __uv3dmix_mod_MOD_uv3dmix2 |   45255 |   52950 |  7695
| +17.00 |
| roms_r_base  | __lmd_vmix_mod_MOD_lmd_vmix|   45069 |   46098 |  1029
|  +2.28 |
| libm-2.29.so | __ieee754_pow_fma  |   39869 |   40731 |   862
|  +2.16 |


When I looked at what happens to the compilation unit with
__step3d_t_mod_MOD_step3d_t, I discovered that no IPA-CP is taking
place.  In fact all IPA dumps from both revisions are exactly the
same, but profile counts of BB in tree dumps that immediately follow
are vastly different:

$ diff -u0 1/step3d_t.fppized.f90.092t.ccp2 2/step3d_t.fppized.f90.092t.ccp2 |
head -38
--- 1/step3d_t.fppized.f90.092t.ccp22019-04-18 18:34:39.725703893 +0200
+++ 2/step3d_t.fppized.f90.092t.ccp22019-04-18 18:53:23.999336873 +0200
@@ -1064 +1064 @@
-   [local count: 8]:
+   [local count: 1]:
@@ -1227 +1227 @@
-   [local count: 4]:
+   [local count: 5000]:
@@ -1229 +1229 @@
-   [local count: 8]:
+   [local count: 1]:
@@ -1264 +1264 @@
-   [local count: 4]:
+   [local count: 5000]:
@@ -1266 +1266 @@
-   [local count: 8]:
+   [local count: 1]:
@@ -1314 +1314 @@
-   [local count: 4]:
+   [local count: 5000]:
@@ -1316 +1316 @@
-   [local count: 8]:
+   [local count: 1]:
@@ -1347 +1347 @@
-   [local count: 4]:
+   [local count: 5000]:
@@ -1349 +1349 @@
-   [local count: 8]:
+   [local count: 1]:
@@ -1380 +1380 @@
-   [local count: 4]:
+   [local count: 5000]:
@@ -1382 +1382 @@
-   [local count: 8]:
+   [local count: 1]:
@@ -1407 +1407 @@
-   [local count: 4]:
+   [local count: 5000]:


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c++/87554] [8 Regression] internal compiler error: in record_reference, at cgraphbuild.c:64

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka  ---
> > The constructor indeed looks broken to me: it should not have naked
> > var_decl. So I am changing component to C++
> 
> I agree that the C++ front end is wrong here, but I also wonder why cgraph is
> looking at the DECL_INITIAL of a DECL_EXTERNAL variable.

Well, at least for constant variables those are useful for contant
folding.  But I suppose we may take care to get rid of decl initials
of non-readonly externals somewhere soon (we do it eventually as part
of unreachable code removal)

Honza
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug tree-optimization/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Actually it was reported by you :)
PR 79878

[Bug c++/87554] [8 Regression] internal compiler error: in record_reference, at cgraphbuild.c:64

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] internal   |[8 Regression] internal
   |compiler error: in  |compiler error: in
   |record_reference, at|record_reference, at
   |cgraphbuild.c:64|cgraphbuild.c:64

--- Comment #10 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #8)
> The constructor indeed looks broken to me: it should not have naked
> var_decl. So I am changing component to C++

I agree that the C++ front end is wrong here, but I also wonder why cgraph is
looking at the DECL_INITIAL of a DECL_EXTERNAL variable.

[Bug fortran/90150] New: wrong output produced by float format fX.Y descriptor following translated scientific format XpeY.Z

[perini at wisc dot edu]

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

Bug ID: 90150
   Summary: wrong output produced by float format fX.Y descriptor
following translated scientific format XpeY.Z
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: perini at wisc dot edu
  Target Milestone: ---

Created attachment 46201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46201&action=edit
Simple test program that reproduces the error

Hi, 

just found this error in floating point string format in gfortran 7.4.0. 

The error affects floating point output (fX.Y), ONLY when this follows a
scientific output with heading non-zeros (ZpeX.Y).

The fX.Y output number is multiplied i.e. translated by as many digits as in
the previous scientific specifier. The issue seems to happen only when both are
part of a same string format.

The attached program prints the same two numbers (1000.0, 10.0) three times
with the following formats: 
A = 1000.0
b = 10.0

$ a.exe
 0.100E+04   10.000 ! "(1e10.3,1x,f8.3)"
 1.000E+03  100.000 ! "(1pe10.3,1x,f8.3)"
 10.00E+02 1000.000 ! "(2pe10.3,1x,f8.3)"


Thanks and keep up the good work!
Federico

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[wilco at gcc dot gnu.org]

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

--- Comment #52 from Wilco  ---
(In reply to Segher Boessenkool from comment #48)
> With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
> That does not fix this PR though :-/

But it does fix most of the codesize regression. The shrinkwrapping testcase
seems a preexisting problem that was exposed by the combine changes, so it
doesn't need to hold up the release. The regalloc change might fix
addr-modes-float.c too.

[Bug ipa/85051] [7/8/9 Regression] ICE: in edge_badness, at ipa-inline.c:1035 with flattening recursive calls

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Thu Apr 18 17:03:00 2019
New Revision: 270446

URL: https://gcc.gnu.org/viewcvs?rev=270446&root=gcc&view=rev
Log:

PR ipa/85051
* ipa-inline.c (flatten_function): New parameter UPDATE.
(ipa_inline, early_inliner): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c

[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
So another update and a rather surprising one at that.

One of the things that is clear is that we need to do some kind of cleanup
between DOM and erroneous path isolation.  Furthermore, the existing cleanup
done by phi-only-cprop is insufficient.

So I finished cobbling together the necessary extensions to phi-only cprop. 
Essentially if we have one or more degenerate PHIs in a block, we also scan the
block for const/copy propagation opportunities.

I then compared that to just using the lattice cprop.

It turns out that the lattice based cprop is consistently better.  Using
valgrind/cachegrind across a collection of .i files the lattice cprop version
executes about .5% fewer instructions.  It was better on each and every input
source file.

Of course to fix the BZ we're going to have to add an instance of the pass.  So
I compared a pristine compiler to one with an extra pass of the lattice copy
propagator inserted between DOM and erroneous path isolation.  The total
slowdown is in the .4% range.

>From a codegen standpoint, it looks like a wash, which was largely expected. 
We tend to clean things up earlier in the pipeline, but the net result is
almost always the same.

I still need to look at the VN on the SEME approach.  That's today's task.

[Bug tree-optimization/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This is recorded as a different bug report.  I think that one was reported by
me.  I will find it latertoday.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #67 from Bernd Edlinger  ---
Created attachment 46200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46200&action=edit
updated patch

So, that is what I am going to bootstrap now.
Adds a libgo patch and some minor changes, mostly where to
put the target-attribute (immediately before the function name).
I assume we can apply that to libgo when its ready.
(I wrote a change log entry but actually there is no libgo/ChangeLog)

[Bug c++/87554] [8/9 Regression] internal compiler error: in record_reference, at cgraphbuild.c:64

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Apr 18 16:50:10 2019
New Revision: 270445

URL: https://gcc.gnu.org/viewcvs?rev=270445&root=gcc&view=rev
Log:
PR c++/87554 - ICE with extern template and reference member.

The removed code ended up setting DECL_INITIAL to the INIT_EXPR returned by
split_nonconstant_init, which makes no sense.  This code was added back in
1996, so any rationale is long lost.

* decl.c (cp_finish_decl): Don't set DECL_INITIAL of external vars.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/extern_template-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug tree-optimization/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
Just another remark:

The words "BIT_FIELD_REF of non-mode-precision operand" do not occur anywhere
in the test suite. They should. Or did I miss something?

If this is meant to be unreachable code, it should rather be an "assert"
instead of an "error".

[Bug tree-optimization/90149] New: diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[roland.illig at gmx dot de]

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

Bug ID: 90149
   Summary: diagnostics containing BIT_FIELD_REF don't conform to
diagnostics guideline
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

The guideline for diagnostics
(https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html) says:

> 27.1.1 Talk in terms of the user’s code

From tree-cfg.c:

  error ("BIT_FIELD_REF of non-mode-precision operand");

The word BIT_FIELD_REF (in uppercase) appears neither in the C nor in the C++
standard. Therefore it is probably not "in terms of the user's code".

This error message should probably be an internal error instead. This also
applies to many other diagnostics, especially those in tree-cfg.c.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[rearnsha at gcc dot gnu.org]

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

--- Comment #51 from Richard Earnshaw  ---
(In reply to Segher Boessenkool from comment #50)
> The insn is
> 
> (insn 7 3 8 2 (parallel [
> (set (reg:CC 100 cc)
> (compare:CC (reg:SI 0 r0 [116])
> (const_int 0 [0])))
> (set (reg/v:SI 4 r4 [orig:112 a ] [112])
> (reg:SI 0 r0 [116]))
> ]) "ira-shrinkwrap-prep-1.c":17:6 188 {*movsi_compare0}
>  (nil))
> 
> and that isn't split, and then prepare_shrink_wrap gives up on it.

In the more general case splitting this would produce worse code, not better,
since then we'd end up with two instructions rather than one.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[segher at gcc dot gnu.org]

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

--- Comment #50 from Segher Boessenkool  ---
The insn is

(insn 7 3 8 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 0 r0 [116])
(const_int 0 [0])))
(set (reg/v:SI 4 r4 [orig:112 a ] [112])
(reg:SI 0 r0 [116]))
]) "ira-shrinkwrap-prep-1.c":17:6 188 {*movsi_compare0}
 (nil))

and that isn't split, and then prepare_shrink_wrap gives up on it.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[segher at gcc dot gnu.org]

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

--- Comment #49 from Segher Boessenkool  ---
(In reply to Wilco from comment #47)
> (In reply to Segher Boessenkool from comment #46)
> > With all three patches together (Peter's, mine, Jakub's), I get a code size
> > increase of only 0.047%, much more acceptable.  Now looking what that diff
> > really *is* :-)
> 
> I think with Jakub's change you don't need to disable the movsi_compare0
> pattern in combine. If regalloc works as expected, it will get split into a
> compare so shrinkwrap can handle it.

prepare_shrink_wrap can not handle that.  prepare_shrink_wrap needs to be
improved for other reasons, of course.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[segher at gcc dot gnu.org]

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

--- Comment #48 from Segher Boessenkool  ---
With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
That does not fix this PR though :-/

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
I'm tempted to just rip out this stuff entirely, and go back to only offering
the strong exception safety guarantee for trivially copyable types, and so
variants would only be never-valueless if all alternatives are trivially
copyable.

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #21 from Jonathan Wakely  ---
Sigh, there is yet another problem with this patch. Consider:

#include 
#include 

struct DeletedMoves
{
  DeletedMoves() = default;
  DeletedMoves(const DeletedMoves&) = default;
  DeletedMoves(DeletedMoves&&) = delete;
  DeletedMoves& operator=(const DeletedMoves&) = default;
  DeletedMoves& operator=(DeletedMoves&&) = delete;
};

struct ThrowingCopy
{
  ThrowingCopy() = default;
  ThrowingCopy(const ThrowingCopy&) { throw 1; }
  ThrowingCopy& operator=(const ThrowingCopy&) { throw 1; }
};

int main()
{
  using namespace std;
  variant> v;
  v.emplace<2>(1);
  v.emplace<2>(1);
}

_Never_valueless> is true, so we try to provide the
strong-exception guarantee:

  else if constexpr (__detail::__variant::_Never_valueless_alt())
{
  // This construction might throw:
  variant __tmp(in_place_index<_Np>, __il,
std::forward<_Args>(__args)...);
  // But _Never_valueless_alt means this won't:
  *this = std::move(__tmp);
}

However because is_move_assignable_v is false the variant has no
move assignment operator, only a copy assignment operator. That means the
"move" assignment actually uses the variant's copy assignment operator, which
performs a copy of the vector, and that can throw. If the variant's current
contained value is not the same type as the one being emplaced, the copy
assignment will destroy the previous value, and then if copying the vector
throws we become valueless. But the variant thinks it can never become
valueless, so we have undefined behaviour.

We can restrict  the strong exception safety guarantee to only happen when the
variant has a move assignment operator:

--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1428,7 +1428,8 @@ namespace __variant
  this->_M_reset();
  __variant_construct_by_index<_Np>(*this, __tmp);
}
- else if constexpr (__detail::__variant::_Never_valueless_alt())
+ else if constexpr (__detail::__variant::_Never_valueless_alt()
+ && _Traits::_S_move_assign)
{
  // This construction might throw:
  variant __tmp(in_place_index<_Np>,
@@ -1474,7 +1475,8 @@ namespace __variant
  __variant_construct_by_index<_Np>(*this, __il,
  std::forward<_Args>(__args)...);
}
- else if constexpr (__detail::__variant::_Never_valueless_alt())
+ else if constexpr (__detail::__variant::_Never_valueless_alt()
+ && _Traits::_S_move_assign)
{
  // This construction might throw:
  variant __tmp(in_place_index<_Np>, __il,

But this means that branch won't be taken for the variant type in the example
above, and so we don't offer the strong exception safety guarantee for that
type, so we also need to consider the extra condition in the
__never_valueless() function:

@@ -352,7 +352,8 @@ namespace __variant
   template 
 constexpr bool __never_valueless()
 {
-  return (_Never_valueless_alt<_Types>::value && ...);
+  return _Traits<_Types...>::_S_move_assign
+   && (_Never_valueless_alt<_Types>::value && ...);
 }

   // Defines index and the dtor, possibly trivial.

[Bug translation/90148] New: Closing quote in wrong position in plugin.c

[roland.illig at gmx dot de]

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

Bug ID: 90148
   Summary: Closing quote in wrong position in plugin.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From plugin.c, at the bottom:

fatal_error (input_location,
 "%<-iplugindir%>  option not passed from the gcc
driver");

The %> should be after the , not before it.

[Bug other/90142] contrib/download_prerequisites uses test ==

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Please send patches to the mailing list, not to bugzilla:
https://gcc.gnu.org/contribute.html#patches