[Bug c++/82764] [7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:5030

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||oremanj at mit dot edu

--- Comment #13 from Jonathan Wakely  ---
*** Bug 81976 has been marked as a duplicate of this bug. ***

[Bug c++/81976] bad is_standard_layout/has_unique_object_representations results with a chain of empty bases

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Let's call it a dup of PR 82764 then.

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

[Bug target/85624] New: ICE when initializing array that is 128-byte aligned

[saaadhu at gcc dot gnu.org]

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

Bug ID: 85624
   Summary: ICE when initializing array that is 128-byte aligned
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saaadhu at gcc dot gnu.org
  Target Milestone: ---

avr-gcc 9.0.0 20180502 (and older versions) crashes with an ICE for the
following piece of code

void foo() {
  volatile int arr[3] __attribute__((aligned(128))) = {0};
  return arr[2];
}

Compiled with -O3 -mmcu=avr5, the compiler outputs

In function 'foo':
5 : warning: 'return' with a value, in function returning void
return arr[2];
~~~^~~
3 : note: declared here
void foo() {
^~~
6 : error: unrecognizable insn:
}
^
(insn 13 12 14 2 (parallel [
(set (mem:BLK (reg:HI 49) [0  A8])
(const_int 0 [0]))
(use (reg:QI 48))
(use (const_int 128 [0x80]))
(clobber (scratch:HI))
(clobber (scratch:QI))
]) "/tmp/gcc-explorer-compiler11843-10755-1jj9whv.s66yh3q5mi/example.c":4 -1
(nil))
during RTL pass: vregs
6 : internal compiler error: in extract_insn, at recog.c:2304
0x5a8f99 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-src/gcc/rtl-error.c:108
0x5a8fb8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-src/gcc/rtl-error.c:116
0xb1394b extract_insn(rtx_insn*)
../../gcc-src/gcc/recog.c:2304
0x8b7873 instantiate_virtual_regs_in_insn
../../gcc-src/gcc/function.c:1599
0x8b7873 instantiate_virtual_regs
../../gcc-src/gcc/function.c:1969
0x8b7873 execute
../../gcc-src/gcc/function.c:2018
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler exited with result code 1

[Bug fortran/85579] [9 regression] SIGSEV in fortran test case gfortran.dg/pr51434.f90 starting with r259754

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu May  3 07:33:09 2018
New Revision: 259880

URL: https://gcc.gnu.org/viewcvs?rev=259880&root=gcc&view=rev
Log:
2018-05-03  Richard Biener  

PR testsuite/85579
* fortran.dg/pr51434.f90: Truncate transfer argument.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr51434.f90

[Bug ipa/85617] Wunused-but-set-variable does not analyze variables passed to functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
The warning really can't be implemented later than in the FE, because many of
the non-setting uses are optimized away already during the FEs.  So there is no
way this can be handled as requested.

[Bug fortran/85579] accepts invalid fortran test case gfortran.dg/pr51434.f90

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Target Milestone|9.0 |---
Summary|[9 regression] SIGSEV in|accepts invalid fortran
   |fortran test case   |test case
   |gfortran.dg/pr51434.f90 |gfortran.dg/pr51434.f90
   |starting with r259754   |

[Bug target/85610] Unable to optimize away mov followed by compare into a cmpb in case of atomic_load

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
  Component|tree-optimization   |target
Version|tree-ssa|7.3.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  RTL expansion looks ok so it looks like a combine/backend issue.

;; _5 = __atomic_load_1 (&MEM[(const struct __atomic_base *)&flag_atomic]._M_i,
0);

(insn 5 4 0 (set (reg:QI 87 [ _5 ])
(mem/v:QI (symbol_ref:DI ("flag_atomic") [flags 0x2]  ) [-1  S1 A8]))
"/usr/include/c++/7/bits/atomic_base.h":396 -1
 (nil))

;; if (_5 == 0)

(insn 6 5 7 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 87 [ _5 ])
(const_int 0 [0]))) "t.C":9 -1
 (nil))

(jump_insn 7 6 0 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 0)
(pc))) "t.C":9 -1
 (int_list:REG_BR_PROB 5400 (nil)))

[Bug tree-optimization/85611] Suboptimal code generation for (potentially) redundant atomic loads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-03
Version|tree-ssa|7.3.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So what do you expect?  Elide the 2nd atomic load?  We currently make no
attempt at "optimizing" atomics on GIMPLE.  OTOH run2 shows we do sth on RTL -
ah, no.
The testcase is just incomplete enough that the control statement is dead and
the load is removed during RTL optimization.

[Bug tree-optimization/85615] [8/9 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
Version|unknown |8.1.1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Mine.

[Bug target/85616] ARM target using -O2 may cause unaligned access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm

--- Comment #1 from Richard Biener  ---
I think this was fixed at some point so there should be a duplicate.

[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.3.1
   Keywords||ice-on-valid-code,
   ||needs-bisection
   Last reconfirmed||2018-05-03
 Ever confirmed|0   |1
Summary|Zero initialized non|[8/9 Regression] Zero
   |constant stack array causes |initialized non constant
   |internal compile error  |stack array causes internal
   ||compile error
   Target Milestone|--- |8.2
  Known to fail||8.1.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug other/85622] gcc-8.1.0/NEWS says it's not released yet

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
It already says that...  we're just lazy from time to time.  Making gcc_release
double-check and fail might be an option ;)

This bug by itself isn't fixable, so WONTFIX...

[Bug libgcc/85621] savms/resms have executable stack (lack GNU-stack marking)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Confirmed.

[Bug fortran/85625] New: Intenal Compiler Error for coindexed assignment

[Bader at lrz dot de]

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

Bug ID: 85625
   Summary: Intenal Compiler Error for coindexed assignment
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 44054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44054&action=edit
reproducer for described problem

The attached Fortran file produces an ICE when built with

gfortran -fcoarray=lib dummycoarray_04_pos.f90

The error message that is issued is:

dummycoarray_04_pos.f90:11:0:

x[i] = x

internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2258
0x6f7d66 gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*)
../../gcc/fortran/dependency.c:2258
0x748bc5 conv_caf_send
../../gcc/fortran/trans-intrinsic.c:1863
0x74f085 gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc/fortran/trans-intrinsic.c:10981
0x701e52 trans_code
../../gcc/fortran/trans.c:1887
0x7653d3 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1433
0x76d78a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1464
0x701db7 trans_code
../../gcc/fortran/trans.c:1916
0x72812b gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x7056d9 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:
0x6b8dab translate_all_program_units
../../gcc/fortran/parse.c:6108
0x6b8dab gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x6ff14f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Replacing the RHS by an auxiliary variable that holds a copy of x does not
trigger the error. However, since significant changes to existing codes may be
required, I think this is a quite serious regression and should be fixed soon.

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||ryxi at stu dot xidian.edu.cn

--- Comment #12 from Xi Ruoyao  ---
This issue makes the shared libraries (libstdc++.so etc.) unusable if GCC is
bootstrapped with C{XX,}FLAGS_FOR_TARGET="-flto -O3".

[Bug fortran/85507] [6/7/8/9 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258

[Bader at lrz dot de]

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

Bader at lrz dot de  changed:

   What|Removed |Added

 CC||Bader at lrz dot de

--- Comment #15 from Bader at lrz dot de  ---
*** Bug 85625 has been marked as a duplicate of this bug. ***

[Bug fortran/85625] Internal Compiler Error for coindexed assignment

[Bader at lrz dot de]

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

Bader at lrz dot de  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
Summary|Intenal Compiler Error for  |Internal Compiler Error for
   |coindexed assignment|coindexed assignment

--- Comment #1 from Bader at lrz dot de  ---
I just noted that 85507 deals with the same issue. Sorry for the duplicate.

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

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  ---
Concerning comment #11, if you have toplevel asms you need to disable LTO for
that unit, as there is no way to tell for gcc what the asm statement is doing.
Perhaps attribute would be better way to do this?

What is status of this bug in general? I must admit I thought we have issues
long solved here :(

[Bug target/85616] ARM target using -O2 may cause unaligned access

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Trunk still generates the stm instruction.

[Bug tree-optimization/85615] [8/9 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
It looks like loop structure is already broken to the extent that
loop->num_nodes
cannot be trusted and thus

  bblocks = XCNEWVEC (basic_block, loop->num_nodes);
  dbds_ce_stop = loop->header;
  nblocks = dfs_enumerate_from (loop->latch, 1, dbds_continue_enumeration_p,
bblocks, loop->num_nodes, bb);

breaks (not enough space in bblocks, thus bb is not reachable from
loop->latch).
In fact loop structure looks totally broken to me :/

We seem to thread through always true/false conditions that are left over from
VRP substitute-and-fold which relies on CFG cleanup to cleanup things here.

When we thread through block 12,

Breakpoint 5, thread_block_1 (bb=, 
noloop_only=true, joiners=false)

we have threaded through the loop header which in the end wrecks things.
We do not hit

  /* One case occurs when there was loop header buried in a jump
 threading path that crosses loop boundaries.  We do not try
 and thread this elsewhere, so just cancel the jump threading
 request by clearing the AUX field now.  */
  if (bb->loop_father != e2->src->loop_father
  && !loop_exit_edge_p (e2->src->loop_father, e2))
{

nor

  /* Another case occurs when trying to thread through our
 own loop header, possibly from inside the loop.  We will
 thread these later.  */
  unsigned int i;
  for (i = 1; i < path->length (); i++)
{

but the case involves a very long path (6 edges) where we thread through
the header of an outer loop into an inner loop and finally through the
exit of the inner loop.  I guess we should hit the first case by allowing
the exit threading only if the exit is to bb->loop_father.  Otherwise
we create an alternate entry (which is what happens here).  Like by
making the check consisted with the others.

I'm testing the following.

Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 259879)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -1309,7 +1309,7 @@ thread_block_1 (basic_block bb, bool nol
 and thread this elsewhere, so just cancel the jump threading
 request by clearing the AUX field now.  */
  if (bb->loop_father != e2->src->loop_father
- && !loop_exit_edge_p (e2->src->loop_father, e2))
+ && !loop_exit_edge_p (bb->loop_father, e2))
{
  /* Since this case is not handled by our special code
 to thread through a loop header, we must explicitly

[Bug other/85622] gcc-8.1.0/NEWS says it's not released yet

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu May  3 09:29:39 2018
New Revision: 259881

URL: https://gcc.gnu.org/viewcvs?rev=259881&root=gcc&view=rev
Log:
PR other/85622
* gcc_release: For -f, verify contrib/gennews has the major version
pages listed and both index.html and changes.html have been updated
for the new release.

Modified:
trunk/maintainer-scripts/ChangeLog
trunk/maintainer-scripts/gcc_release

[Bug tree-optimization/85588] [6/7/8/9 Regression] -fwrapv miscompilation

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
A fix is probably as simple as

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 259879)
+++ gcc/fold-const.c(working copy)
@@ -472,7 +472,7 @@ negate_expr_p (tree t)
 case TRUNC_DIV_EXPR:
 case ROUND_DIV_EXPR:
 case EXACT_DIV_EXPR:
-  if (TYPE_UNSIGNED (type))
+  if (TYPE_OVERFLOW_WRAPS (type))
break;
   if (negate_expr_p (TREE_OPERAND (t, 0)))
return true;

[Bug fortran/85603] ICE with character array substring assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
 Blocks||68241
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

I am pretty sure this is a duplicate.

The code compiles if I replace

  strings = strings(:)(:maxlen)

with

  strings(1) = strings(1)(:maxlen)
  strings(2) = strings(2)(:maxlen)

but this does not set the length of 'strings' to 'maxlen'.

IIRC I have recently seen a post saying that substrings of string array
sections are forbidden by the standard.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #14 from Xi Ruoyao  ---
(In reply to Jan Hubicka from comment #13)
> What is status of this bug in general? I must admit I thought we have issues
> long solved here :(

It still exists in 8.1.  Libstdc++ uses top level asm statement for symbol
versioning.  Then symbol std::istream::ignore(long)@GLIBCXX_3_4 just
disappears, and libstdc++.so can't be used (this symbol becomes *UND*).

[Bug other/85622] gcc-8.1.0/NEWS says it's not released yet

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
The added checks should make sure we don't forget to do it early next time.
We can't really fix the 8.1 tarballs now of course.

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #15 from Xi Ruoyao  ---
(In reply to Jan Hubicka from comment #13)
> Concerning comment #11, if you have toplevel asms you need to disable LTO
> for that unit, as there is no way to tell for gcc what the asm statement is
> doing. Perhaps attribute would be better way to do this?

Well then this is PR 57703.   Should we mark duplicate? :(

[Bug target/85626] New: [nvptx] __builtin_trap should not return

[vries at gcc dot gnu.org]

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

Bug ID: 85626
   Summary: [nvptx] __builtin_trap should not return
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

As mentioned here ( https://cygwin.com/ml/newlib/2018/msg00335.html ):
...
Then, the nvptx port of gcc implements __builtin_trap using the 'trap' ptx
insn.


The trap insn is documented in the ptx documentation as:
...
Abort execution and generate an interrupt to the host CPU.
...

After consulting with nvidia when running into unexpected behaviour we found
out that in fact the ptx compilers (ptxas and the JIT in the drivers) do not
consider trap a noreturn insn, and that a trap handler may return, and advised
us to add an 'exit' after the trap. I've asked them to improve the ptx
documentation (the abort is somewhat misleading), but sofar no luck there.


So, in fact nvptx __builtin_trap can return, which is a gcc bug, that I still
need to file and fix.
...

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Jan Hubicka from comment #13)
> > Concerning comment #11, if you have toplevel asms you need to disable LTO
> > for that unit, as there is no way to tell for gcc what the asm statement is
> > doing. Perhaps attribute would be better way to do this?
> 
> Well then this is PR 57703.   Should we mark duplicate? :(

I think the bug is sufficiently different and should have different
workarounds.

We might want to add a function attribute to allow to specify symver, so like

int pci_fill_info_v31(struct pci_dev *d, int flags)
__attribute__((alias("pci_fill_info"), symver("@LIBPCI_3.0"));

or similar (combine alias and symver as symver_alias?).  Or simply
recognize @ in alias.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #18 from Vincent  ---
Still in 8.1, now with a different diagnosis:

g++-8 -c -O3 67650.cpp
67650.cpp:33:8: warning: 'void AN::rp() [with OC = LR::LLC; RC = BLKC]' used but never defined
   void rp(){}
^~
Ironically the message complains about the non definition of the member
function, and displays that very definition...

[Bug tree-optimization/85627] New: [6/7/8/9 Regression] ICE in update_phi_components in tree-complex.c

[ktkachov at gcc dot gnu.org]

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

Bug ID: 85627
   Summary: [6/7/8/9 Regression] ICE in update_phi_components in
tree-complex.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

The testcase:

__complex double
foo (__complex double a, __complex double b)
{
  __complex res = a;
  try {
res = a * b;
  }
  catch (...) {
 res = b;
  }
  return res;
}

compiled with
g++ -O2 -fnon-call-exceptions
ICEs with:

during GIMPLE pass: cplxlower
complex.c: In function '__complex__ double foo(__complex__ double, __complex__
double)':
complex.c:3:1: internal compiler error: Segmentation fault
 foo (__complex double a, __complex double b)
 ^~~
0xe1b5b1 crash_signal
%SRC/gcc/toplev.c:325
0xb31899 phi_nodes_ptr
%SRC/gcc/gimple.h:4406
0xb31899 gsi_start_phis(basic_block_def*)
%SRC/gcc/gimple-iterator.c:917
0xe81fb1 update_phi_components
%SRC/gcc/tree-complex.c:747
0xe83bc8 tree_lower_complex
%SRC/gcc/tree-complex.c:1695
0xe85b7a execute
%SRC/gcc/tree-complex.c:1757
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/85627] [6/7/8/9 Regression] ICE in update_phi_components in tree-complex.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
Version|unknown |8.1.1
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So one issue is the complex libcalls are ECF_NOTHROW.  That's not really
expected with -fnon-call-exceptions.  Fix required to
build_common_builtin_nodes, but it
would really need to be done per function given -fnon-call-exceptions is per
function.  I guess just removing ECF_NOTHROW is good enough.

Then the issue is of course the loop over BBs in tree_lower_complex () does not
expect any CFG changes (like purging dead EH edges).  We could delay this
and/or deal with BASIC_BLOCK_FOR_FN returning NULL for removed BBs.

Another issue is - after your patch - that we possibly miss some stmts if you
start to split blocks.  That's already done by expand_complex_div_wide as well
so there's a pre-existing issue here.

[Bug tree-optimization/85627] [6/7/8/9 Regression] ICE in update_phi_components in tree-complex.c

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Part of the fix:

Index: gcc/tree-complex.c
===
--- gcc/tree-complex.c  (revision 259879)
+++ gcc/tree-complex.c  (working copy)
@@ -1692,6 +1692,8 @@ tree_lower_complex (void)
   for (i = 0; i < n_bbs; i++)
 {
   bb = BASIC_BLOCK_FOR_FN (cfun, rpo[i]);
+  if (!bb)
+   continue;
   update_phi_components (bb);
   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
expand_complex_operations_1 (&gsi);

[Bug tree-optimization/85627] [6/7/8/9 Regression] ICE in update_phi_components in tree-complex.c

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
expand_complex_div_wide seems to work fine.

[Bug tree-optimization/85627] [6/7/8/9 Regression] ICE in update_phi_components in tree-complex.c

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Fixing the nothrow issue reveals:

Index: tree.c
===
--- tree.c  (revision 259879)
+++ tree.c  (working copy)
@@ -10386,17 +10386,19 @@ build_common_builtin_nodes (void)
  *q = TOLOWER (*p);
*q = '\0';

+   /* For -ftrapping-math these should throw from a former
+  -fnon-call-exception stmt.  */
built_in_names[mcode] = concat (prefix, "mul", mode_name_buf, "3",
NULL);
 local_define_builtin (built_in_names[mcode], ftype, mcode,
  built_in_names[mcode],
- ECF_CONST | ECF_NOTHROW | ECF_LEAF);
+ ECF_CONST | ECF_LEAF);

built_in_names[dcode] = concat (prefix, "div", mode_name_buf, "3",
NULL);
 local_define_builtin (built_in_names[dcode], ftype, dcode,
  built_in_names[dcode],
- ECF_CONST | ECF_NOTHROW | ECF_LEAF);
+ ECF_CONST | ECF_LEAF);
   }
   }


t.ii:2:1: error: statement marked for throw in middle of block
 foo (__complex double a, __complex double b)
 ^~~
_6 = __muldc3 (a$real_10, a$imag_11, b$real_12, b$imag_13);
during GIMPLE pass: cplxlower
t.ii:2:1: internal compiler error: verify_gimple failed

this is because the components are extracted after the call:

   [local count: 1073741825]:
  a$real_10 = REALPART_EXPR ;
  a$imag_11 = IMAGPART_EXPR ;
  b$real_12 = REALPART_EXPR ;
  b$imag_13 = IMAGPART_EXPR ;
  _6 = __muldc3 (a$real_10, a$imag_11, b$real_12, b$imag_13);
  _14 = REALPART_EXPR <_6>;
  _15 = IMAGPART_EXPR <_6>;

   [local count: 1073741825]:
  # res_2 = PHI <_6(2), b_5(D)(4)>
  # res$real_16 = PHI <_14(2), b$real_12(4)>
  # res$imag_17 = PHI <_15(2), b$imag_13(4)>
  return res_2;

thus with EH we need to split the block after the call.

[Bug tree-optimization/85627] [6/7/8/9 Regression] ICE in update_phi_components in tree-complex.c

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Fixed by, for example, the following which keeps EH intact for the original
testcase if combined with the tree.c fix

Index: gcc/tree-complex.c
===
--- gcc/tree-complex.c  (revision 259879)
+++ gcc/tree-complex.c  (working copy)
@@ -1015,14 +1015,25 @@ expand_complex_libcall (gimple_stmt_iter
   if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
 gimple_purge_dead_eh_edges (gsi_bb (*gsi));

-  if (gimple_in_ssa_p (cfun))
+  type = TREE_TYPE (type);
+  if (stmt_can_throw_internal (stmt))
 {
-  type = TREE_TYPE (type);
-  update_complex_components (gsi, stmt,
+  edge_iterator ei;
+  edge e;
+  FOR_EACH_EDGE (e, ei, gimple_bb (stmt)->succs)
+   if (!(e->flags & EDGE_EH))
+ break;
+  basic_block bb = split_edge (e);
+  gimple_stmt_iterator gsi2 = gsi_start_bb (bb);
+  update_complex_components (&gsi2, stmt,
 build1 (REALPART_EXPR, type, lhs),
 build1 (IMAGPART_EXPR, type, lhs));
-  SSA_NAME_DEF_STMT (lhs) = stmt;
 }
+  else
+update_complex_components (gsi, stmt,
+  build1 (REALPART_EXPR, type, lhs),
+  build1 (IMAGPART_EXPR, type, lhs));
+  SSA_NAME_DEF_STMT (lhs) = stmt;
 }

 /* Expand complex multiplication to scalars:

[Bug ipa/85617] Wunused-but-set-variable does not analyze variables passed to functions

[danielgutson at gmail dot com]

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

--- Comment #4 from Daniel Gutson  ---
(In reply to Jakub Jelinek from comment #3)
> The warning really can't be implemented later than in the FE, because many
> of the non-setting uses are optimized away already during the FEs.  So there
> is no way this can be handled as requested.

Ok just for educational and documentational purposes, could you please comment
1) what structural changes should be done in order to be able to get this
possible? 2) could you please point me in the code to where the first breaking
optimization is that turns this unfeasible?
If the front-end would support this, would then other benefits come up for
other analyses?

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[rdapp at linux dot ibm.com]

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

rdapp at linux dot ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot ibm.com

--- Comment #4 from rdapp at linux dot ibm.com ---
This also happens on s390x, even with -O0 and no new -march setting.

The following line in EtherMac.cc

 delete outputbuffer.pop()

actually emits two calls to

 cQueue::pop ().

On the second call, the queue is empty and the program terminates.

Already in the .original pass, a SAVE_EXPR that was there before is not present
anymore:

if (SAVE_EXPR 

[Bug tree-optimization/85627] [6/7/8/9 Regression] ICE in update_phi_components in tree-complex.c

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 44055
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44055&action=edit
patch

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #17 from Xi Ruoyao  ---
(In reply to Richard Biener from comment #16)

> We might want to add a function attribute to allow to specify symver, so like
> 
> int pci_fill_info_v31(struct pci_dev *d, int flags)
> __attribute__((alias("pci_fill_info"), symver("@LIBPCI_3.0"));
> 
> or similar (combine alias and symver as symver_alias?).  Or simply
> recognize @ in alias.

But a normal alias is

int pci_fill_info(struct pci_dev *, int)
__attribute__((alias("pci_fill_info_v31")));

The exported name is the function declare name, and the actual name is in alias
attribute.

I prefer

int pci_fill_info(struct pci_dev *, int)
__attribute__((symver_alias("@LIBPCI_3.0", "pci_fill_info_v31")));

[Bug tree-optimization/85615] [8/9 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Regresses gcc.dg/uninit-20.c.

Trying

  if (bb->loop_father != e2->src->loop_father
  && (!loop_exit_edge_p (e2->src->loop_father, e2)
  || flow_loop_nested_p (bb->loop_father, 
 e2->dest->loop_father)))

instead.

[Bug ipa/85617] Wunused-but-set-variable does not analyze variables passed to functions

[danielgutson at gmail dot com]

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

--- Comment #5 from Daniel Gutson  ---
Additionally, could you please consider to gently leave this issue open as an
enhancement?

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |
   |nu  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
   Host|powerpc64le-unknown-linux-g |
   |nu  |
 Ever confirmed|0   |1
  Build|powerpc64le-unknown-linux-g |
   |nu  |

--- Comment #5 from H.J. Lu  ---
Also failed on x86:

https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg00217.html

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[rdapp at linux dot ibm.com]

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

--- Comment #6 from rdapp at linux dot ibm.com ---
This hunk causes the double pop():

@@ -4650,8 +4648,6 @@ build_delete (tree otype, tree addr,
special_function_kind auto_delete,
}
}
}
-  if (TREE_SIDE_EFFECTS (addr))
-   addr = save_expr (addr);

   /* Throw away const and volatile on target type of addr.  */
   addr = convert_force (build_pointer_type (type), addr, 0, complain);


addr has the side-effects bit set at that point.

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target|x86_64-apple-darwin14.4.0   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
 Ever confirmed|0   |1

--- Comment #19 from Jonathan Wakely  ---
Reduced:

struct RE
{
  virtual void rp()=0;
  void ax(){rp();}
};

struct BLKC
{
  virtual void rb(){}
};

template 
struct LK : BLKC
{
  T* p = nullptr;
  void rb() override { p->ax();}
};

template 
struct AN : RE
{
  void rp() override {}
};

template 
struct LR
{
  virtual ~LR(){}
  struct LLC { virtual ~LLC(){} };
  LK> l;
};

constexpr char ET[]="";
struct I
{
  LR _e;
};

int main(){new I();}



$ g++  -Wall  67650.cc -O1 -fdevirtualize
67650.cc:22:8: warning: ‘void AN<  >::rp() [with
 = LR<(& ET)>::LLC]’ declared ‘static’ but never
defined [-Wunused-function]
   void rp() override {}
^~

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #49 from John Paul Adrian Glaubitz  ---
Hi Andrew!

(In reply to Andrew Jenner from comment #21)
> I'm still actively working on it. The patch is close to ready for commit
> now, I think - I'm going to try to get it committed by the end of the week.

Is there any progress on this? Is there anything we (Debian) can do to help
you?

Do you need access to a porterbox or do you need your own powerpcspe hardware
for testing? It might be possible to arrange that, I know people who could
supply such hardware. Debian got its PowerPC e500v2 boards through donations as
well.

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to Vincent from comment #5)
> The problem is static time, not dynamic time.
> This artefact is just a result of source code reduction. In  my code there
> is no "0", and the problem exists.

Are you sure about that? Using your original testcase I can only reproduce the
link error when it has ((T*)0)->ax()

[Bug ipa/85617] Wunused-but-set-variable does not analyze variables passed to functions

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
E.g. cp_fold/c_fully_fold, gimplification, match.pd folding during
gimplification etc. can optimize away many uses.
I see no point in keeping open enhancement requests that are impossible to
implement.

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Comment 19 shows a bogus warning triggered by -fdevirtualize but I'm not
convinced the original report of a link-error bug is valid.

[Bug tree-optimization/85588] [6/7/8/9 Regression] -fwrapv miscompilation

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Or rather

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 259879)
+++ gcc/fold-const.c(working copy)
@@ -474,12 +474,15 @@ negate_expr_p (tree t)
 case EXACT_DIV_EXPR:
   if (TYPE_UNSIGNED (type))
break;
-  if (negate_expr_p (TREE_OPERAND (t, 0)))
+  /* In general we can't negate A in A / B, because if A is INT_MIN and
+ B is not 1 we change the sign of the result.  */
+  if (TREE_CODE (TREE_OPERAND (t, 0)) == INTEGER_CST
+ && negate_expr_p (TREE_OPERAND (t, 0)))
return true;
   /* In general we can't negate B in A / B, because if A is INT_MIN and
 B is 1, we may turn this into INT_MIN / -1 which is undefined

[Bug libstdc++/84949] -ffast-math bugged with respect to NaNs

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
std::numeric_limits defines:

  static _GLIBCXX_USE_CONSTEXPR bool has_infinity = __FLT_HAS_INFINITY__;
  static _GLIBCXX_USE_CONSTEXPR bool has_quiet_NaN = __FLT_HAS_QUIET_NAN__;
  static _GLIBCXX_USE_CONSTEXPR bool has_signaling_NaN = has_quiet_NaN;
  static _GLIBCXX_USE_CONSTEXPR float_denorm_style has_denorm
= bool(__FLT_HAS_DENORM__) ? denorm_present : denorm_absent;
  //...
  static _GLIBCXX_USE_CONSTEXPR bool is_iec559
= has_infinity && has_quiet_NaN && has_denorm == denorm_present;

And that seems to be the right thing to do. If the compiler tells us the type
has infinities and NaNs then we expose that through std::numeric_limits.

I don't think we want the C++ library to be inconsistent with the compiler
here. So maybe any change should be in the compiler not libstdc++.

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sudi at gcc dot gnu.org

--- Comment #7 from sudi at gcc dot gnu.org ---
Also failing on aarch64 targets.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

Andrew Jenner  changed:

   What|Removed |Added

  Attachment #43312|0   |1
is obsolete||

--- Comment #50 from Andrew Jenner  ---
Created attachment 44056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44056&action=edit
Patch in progress as of 2018/05/03

Hi John,

Thanks for the offer of help. I already have hardware, but I need to get my
test scripts in order. I'm attaching my current patch. If you could get some
test results with and without this patch to make sure it doesn't break
anything, that would be a tremendous help. Unfortunately I've been side-tracked
onto other projects and haven't been able to give this the attention it
deserves, but I hope to get back to it in the next couple of weeks. Thanks
again!

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #51 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Jenner from comment #50),
> 
> Thanks for the offer of help. I already have hardware, but I need to get my
> test scripts in order.

Ok, great!

> I'm attaching my current patch. If you could get some
> test results with and without this patch to make sure it doesn't break
> anything, that would be a tremendous help.

Absolutely. Where should I test the patch? Natively on powerpcspe? On x86_64?
Or anything else? We have a wide range of architectures available for testing.

> Unfortunately I've been
> side-tracked onto other projects and haven't been able to give this the
> attention it deserves, but I hope to get back to it in the next couple of
> weeks. Thanks again!

No worries. Your efforts are highly appreciated and I'm happy to help whereever
I can.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #22 from Vincent  ---
See comment #6.

(In reply to Jonathan Wakely from comment #20)
> (In reply to Vincent from comment #5)
> > The problem is static time, not dynamic time.
> > This artefact is just a result of source code reduction. In  my code there
> > is no "0", and the problem exists.
> 
> Are you sure about that? Using your original testcase I can only reproduce
> the link error when it has ((T*)0)->ax()

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #23 from Vincent  ---
See comment #10. The error is sensitive to unrelated changes. There is some
(front-end?) corruption somewhere.

(In reply to Jonathan Wakely from comment #21)
> Comment 19 shows a bogus warning triggered by -fdevirtualize but I'm not
> convinced the original report of a link-error bug is valid.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

--- Comment #52 from Andrew Jenner  ---
(In reply to John Paul Adrian Glaubitz from comment #51)
> Absolutely. Where should I test the patch? Natively on powerpcspe? On
> x86_64? Or anything else? We have a wide range of architectures available
> for testing.

The patch only changes the powerpcspe backend - there's no need to test it
against any other targets.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #53 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Jenner from comment #52)
> (In reply to John Paul Adrian Glaubitz from comment #51)
> > Absolutely. Where should I test the patch? Natively on powerpcspe? On
> > x86_64? Or anything else? We have a wide range of architectures available
> > for testing.
> 
> The patch only changes the powerpcspe backend - there's no need to test it
> against any other targets.

Ok. I will try a native build then.

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #18 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #17)

> I prefer
> 
> int pci_fill_info(struct pci_dev *, int)
> __attribute__((symver_alias("@LIBPCI_3.0", "pci_fill_info_v31")));

But then what should we do for

int pci_fill_info(struct pci_dev *, int)
__attribute__((symver_alias("@LIBPCI_3.0", "pci_fill_info_v31")));

int pci_fill_info(struct pci_dev *, int)
__attribute__((symver_alias("@LIBPCI_3.1", "pci_fill_info_v32")));

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu May  3 12:59:43 2018
New Revision: 259889

URL: https://gcc.gnu.org/viewcvs?rev=259889&root=gcc&view=rev
Log:
[tree-complex.c] PR tree-optimization/70291: Inline floating-point complex
multiplication more aggressively

We can improve the performance of complex floating-point multiplications by
inlining the expansion a bit more aggressively.
We can inline complex x = a * b as:
x = (ar*br - ai*bi) + i(ar*bi + br*ai);
if (isunordered (__real__ x, __imag__ x))
  x = __muldc3 (a, b); //Or __mulsc3 for single-precision

That way the common case where no NaNs are produced we can avoid the libgcc
call and fall back to the
NaN handling stuff in libgcc if either components of the expansion are NaN.

The implementation is done in expand_complex_multiplication in tree-complex.c
and the above expansion
will be done when optimising for -O1 and greater and when not optimising for
size.
At -O0 and -Os the single call to libgcc will be emitted.

For the code:
__complex double
foo (__complex double a, __complex double b)
{
  return a * b;
}

We will now emit at -O2 for aarch64:
foo:
fmuld16, d1, d3
fmuld6, d1, d2
fnmsub  d5, d0, d2, d16
fmadd   d4, d0, d3, d6
fcmpd5, d4
bvs .L8
fmovd1, d4
fmovd0, d5
ret
.L8:
stp x29, x30, [sp, -16]!
mov x29, sp
bl  __muldc3
ldp x29, x30, [sp], 16
ret

Instead of just a branch to __muldc3.

PR tree-optimization/70291
* tree-complex.c (expand_complex_libcall): Add type, inplace_p
arguments.  Change return type to tree.  Emit libcall as a new
statement rather than replacing existing one when inplace_p is true.
(expand_complex_multiplication_components): New function.
(expand_complex_multiplication): Expand floating-point complex
multiplication using the above.
(expand_complex_division): Rename inner_type parameter to type.
Update expand_complex_libcall call-site.
(expand_complex_operations_1): Update expand_complex_multiplication
and expand_complex_division call-sites.

* gcc.dg/complex-6.c: New test.
* gcc.dg/complex-7.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/complex-6.c
trunk/gcc/testsuite/gcc.dg/complex-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely  ---
(In reply to Vincent from comment #22)
> See comment #6.

I already saw it, and I already tried that change. The problem disappears if
you make that change. 

(In reply to Vincent from comment #23)
> See comment #10. The error is sensitive to unrelated changes. There is some
> (front-end?) corruption somewhere.

I'm not convinced by that either.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #25 from Vincent  ---
Oh, it used to be the case. I think that must be due to some additional
artefact of more recent compilers. I'll try to find another way to show it.

(In reply to Jonathan Wakely from comment #24)
> (In reply to Vincent from comment #22)
> > See comment #6.
> 
> I already saw it, and I already tried that change. The problem disappears if
> you make that change. 
> 
> (In reply to Vincent from comment #23)
> > See comment #10. The error is sensitive to unrelated changes. There is some
> > (front-end?) corruption somewhere.
> 
> I'm not convinced by that either.

[Bug fortran/65086] Segfault: Invalid copy-out of temporary as argument is in read-only memory

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
I rechecked this. Same situation still with gfortran 9.0. Also ran nagfor.
nagfor behaves the same way as gfortran does, so the seg fault is only gone if
the intent(in) in sub4 is added.

[Bug libstdc++/84535] std::thread constructor missing constraint on first argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed for GCC 9

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
(In reply to Vincent from comment #25)
> Oh, it used to be the case. I think that must be due to some additional
> artefact of more recent compilers. I'll try to find another way to show it.

I tried 5.1.0 and 5.2.0 and several other previous releases, they all link the
program successfully, with just this warning:

main.cpp:53:8: warning: 'I' has a field 'I::_e' whose type uses the anonymous
namespace

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #27 from Vincent  ---
Sorry for the silly check, are you sure you are trying with -O3 or
-fdevirtualize -O2? 

You can try this with 8.1:

void *v;

template 
struct LK: public BLKC
{
  void rb(){((T*)v)->ax();}
  static T* st;
};

As a replacement to the call to null, and the missing definition problem is
reported.

(In reply to Jonathan Wakely from comment #26)
> (In reply to Vincent from comment #25)
> > Oh, it used to be the case. I think that must be due to some additional
> > artefact of more recent compilers. I'll try to find another way to show it.
> 
> I tried 5.1.0 and 5.2.0 and several other previous releases, they all link
> the program successfully, with just this warning:
> 
> main.cpp:53:8: warning: 'I' has a field 'I::_e' whose type uses the
> anonymous namespace

[Bug tree-optimization/85615] [8/9 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu May  3 13:20:02 2018
New Revision: 259891

URL: https://gcc.gnu.org/viewcvs?rev=259891&root=gcc&view=rev
Log:
2018-05-03  Richard Biener  

PR tree-optimization/85615
* tree-ssa-threadupdate.c (thread_block_1): Only allow exits
to loops not nested in BBs loop father to avoid creating multi-entry
loops.

* gcc.dg/torture/pr85615.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr85615.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug tree-optimization/85615] [8 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] ICE at -O2 |[8 Regression] ICE at -O2
   |and above on valid code on  |and above on valid code on
   |x86_64-linux-gnu: in|x86_64-linux-gnu: in
   |dfs_enumerate_from, at  |dfs_enumerate_from, at
   |cfganal.c:1197  |cfganal.c:1197

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #28 from Vincent  ---
Other silly check, did you try with my code or your reduced code ?

(In reply to Jonathan Wakely from comment #26)
> (In reply to Vincent from comment #25)
> > Oh, it used to be the case. I think that must be due to some additional
> > artefact of more recent compilers. I'll try to find another way to show it.
> 
> I tried 5.1.0 and 5.2.0 and several other previous releases, they all link
> the program successfully, with just this warning:
> 
> main.cpp:53:8: warning: 'I' has a field 'I::_e' whose type uses the
> anonymous namespace

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Implemented for GCC 9.

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
Dumping the original tree of the test in comment 0 gives

...
lazy ()
{
  static logical(kind=4) check (void);
  logical(kind=4) flag;

  flag = 0;
  flag = check () && flag;
  flag = flag && check ();
}
...

Am I mistaken to read this as being handled by the middle-end? If yes, the
situation is discussed in pr57160 comment 1.

> *
> 7.1.4 Evaluation of operations
> 2 The evaluation of a function reference shall neither affect nor be affected
> by the evaluation of any other entity within the statement.
> *

Does it means that 'check' has to be evaluated in

if (flag) flag = check ()

even if flag==.false. ?

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries  ---
Author: vries
Date: Thu May  3 13:47:14 2018
New Revision: 259892

URL: https://gcc.gnu.org/viewcvs?rev=259892&root=gcc&view=rev
Log:
[testsuite] Add scan-offload-tree-dump

2018-05-03  Tom de Vries  

PR testsuite/85106
* lib/scanoffloadtree.exp: New file.

* testsuite/lib/libgomp-dg.exp (libgomp-dg-test): Add save-temps to
extra_tool_flags if it contains an -foffload=-fdump-* flag.
* testsuite/lib/libgomp.exp: Include scanoffloadtree.exp.
* testsuite/libgomp.oacc-c/vec.c: Use scan-offload-tree-dump.

* doc/sourcebuild.texi (Commands for use in dg-final, Scan optimization
dump files): Add offload-tree.

Added:
trunk/gcc/testsuite/lib/scanoffloadtree.exp
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/lib/libgomp-dg.exp
trunk/libgomp/testsuite/lib/libgomp.exp
trunk/libgomp/testsuite/libgomp.oacc-c/vec.c

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> Am I mistaken to read this as being handled by the middle-end?
> If yes, the situation is discussed in pr57160 comment 1.

I meant "If no"!-(

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||link-failure

--- Comment #29 from Jonathan Wakely  ---
(In reply to Vincent from comment #27)
> Sorry for the silly check, are you sure you are trying with -O3 or
> -fdevirtualize -O2? 

I've tried both. I'm using x86_64-pc-linux-gnu though.


> You can try this with 8.1:
> 
> void *v;
> 
> template 
> struct LK: public BLKC
> {
>   void rb(){((T*)v)->ax();}
>   static T* st;
> };
> 
> As a replacement to the call to null, and the missing definition problem is
> reported.

OK now I can reproduce it with trunk.

(In reply to Vincent from comment #28)
> Other silly check, did you try with my code or your reduced code ?

Yours.

Here's the reduced form that gives a link-error with trunk:

#include 

template 
struct RE
{
  virtual void rp()=0;
  void ax(){rp();}
};

struct EN : RE
{
  EN(::std::string = ""){}
  void rp(){}
};

template 
struct AN : RE
{
  void rp(){}
};

template 
struct LK
{
  T* p = nullptr;
  virtual void rb(){p->ax();}
};

template 
struct LR
{
  virtual ~LR(){}
  struct LLC { virtual ~LLC(){} };
  LK> l;
};

constexpr char ET[]="";
struct I : EN
{
  LR _e;
};

int main(){new I();}


$ ~/gcc/8.1.0/bin/g++ -Wall -O1 -fdevirtualize main.cc 
main.cc:19:8: warning: ‘void AN::rp() [with OC = LR<(& ET)>::LLC]’ used but
never defined
   void rp(){}
^~
/tmp/cc4IHAPf.o: In function `LK::LLC> >::rb()':
main.cc:(.text+0x37): undefined reference to `AN::LLC>::rp()'
collect2: error: ld returned 1 exit status

[Bug libstdc++/84535] std::thread constructor missing constraint on first argument

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 14:08:36 2018
New Revision: 259893

URL: https://gcc.gnu.org/viewcvs?rev=259893&root=gcc&view=rev
Log:
PR libstdc++/84535 constrain std::thread constructor

The standard requires that the std::thread constructor is constrained so
it can't be called with a first argument of type std::thread. The
current implementation only meets that requirement if the constructor is
called with one argument, by using deleted overloads. This uses an
enable_if constraint to enforce the requirement for any number of
arguments.

Also add a static assertion to give a more readable error for invalid
arguments that cannot be invoked. Also simplify _Invoker to reduce the
error cascade for ill-formed instantiations with non-invocable
arguments.

PR libstdc++/84535
* include/std/thread (thread::__not_same): New SFINAE helper.
(thread::thread(_Callable&&, _Args&&...)): Add SFINAE constraint that
first argument is not a std::thread. Add static assertion to check
INVOKE expression is valid.
(thread::thread(thread&), thread::thread(const thread&&)): Remove.
(thread::_Invoke::_M_invoke, thread::_Invoke::operator()): Use
__invoke_result for return types and remove exception specifications.
* testsuite/30_threads/thread/cons/84535.cc: New.

Added:
trunk/libstdc++-v3/testsuite/30_threads/thread/cons/84535.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/thread

[Bug target/85593] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled

[austinpmorton at gmail dot com]

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

--- Comment #4 from Austin Morton  ---
In my particular case I was able to work around the issue by removing the naked
attribute and using extended assembly with a clobbers list.

The resulting code is nearly identical (allowing GCC to generate the correct
pro/epilog instead of hand writing it), and gcc correctly allocates R4 instead
of R3.

This still feels like a bug in GCC.  In the example I gave, if you compiled the
naked function in a separate C file and linked them it would generate the
correct code.  The issue is that GCC is able to "see" the naked function and is
performing optimizations that it shouldn't as a result.

I believe that GCC should treat naked functions as opaque as far as
optimizations are concerned.
At the very least, there should be a note about this kind of issue included in
the documentation of the naked attribute.

[Bug middle-end/60646] Investigate improved complex division algorithms

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Regarding performance, the paper from the description indicates the "Improved"
algorithm is the highest performing one and is more resistant to overflows and
underflows. Am I reading that right?

[Bug target/85628] New: Make better use of BFI (BFXIL)

[ktkachov at gcc dot gnu.org]

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

Bug ID: 85628
   Summary: Make better use of BFI (BFXIL)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The testcase:
unsigned long long combine(unsigned long long a, unsigned long long b) {
return (a & 0xll) | (b & 0xll);
}

void read2(unsigned long long a, unsigned long long b, unsigned long long *c,
unsigned long long *d) {
*c = combine(a, b); *d = combine(b, a);
}

on aarch64 with -O2 currently generates:
combine:
bfi x0, x1, 0, 32
ret

read2:
and x5, x1, 4294967295
and x4, x0, -4294967296
orr x4, x4, x5
and x1, x1, -4294967296
and x0, x0, 4294967295
str x4, [x2]
orr x0, x0, x1
str x0, [x3]
ret

With LLVM it does a better job:
combine:// @combine
bfxil   x0, x1, #0, #32
ret

read2:  // @read2
mov x8, x0
bfxil   x8, x1, #0, #32
bfxil   x1, x0, #0, #32
str x8, [x2]
str x1, [x3]
ret

This should just be a matter of adding the necessary patterns in aarch64.md.
Combine already tries to match:

(set (reg:DI 105)
(ior:DI (and:DI (reg/v:DI 97 [ b ])
(const_int -4294967296 [0x]))
(and:DI (reg/v:DI 96 [ a ])
(const_int 4294967295 [0x]

[Bug bootstrap/85629] New: GCC 8.1.0: FTBFS: make check fails in Go part

[kdevel at vogtner dot de]

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

Bug ID: 85629
   Summary: GCC 8.1.0: FTBFS: make check fails in Go part
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

Centos 6.9 final, X86_64, expect installed, dejagnu not installed

$ grep ^FAIL build.log.2018-05-02T20\:49\:37

FAIL: go test cmd/go
FAIL: go test runtime
FAIL: TestBreakpoint
FAIL: TestCatchPanic
FAIL: TestCgoCallbackGC
FAIL: TestCgoCCodeSIGPROF
FAIL: TestCgoCheckBytes
FAIL: TestCgoCrashHandler
FAIL: TestCgoExecSignalMask
FAIL: TestCgoExternalThreadPanic
FAIL: TestCgoExternalThreadSignal
FAIL: TestCgoExternalThreadSIGPROF
FAIL: TestCgoLockOSThreadExit
FAIL: TestCgoNumGoroutine
FAIL: TestCgoPanicDeadlock
FAIL: TestCgoSignalDeadlock
FAIL: TestCgoTraceback
FAIL: TestCgoTracebackSigpanic
FAIL: TestCrashDumpsAllThreads
FAIL: TestCrashHandler
FAIL: TestEnsureDropM
FAIL: TestGccgoCrashTraceback
FAIL: TestGccgoCrashTracebackNodebug
FAIL: TestGCFairness
FAIL: TestGCFairness2
FAIL: TestGoexitCrash
FAIL: TestGoexitDeadlock
FAIL: TestGoexitInPanic
FAIL: TestGoNil
FAIL: TestInitDeadlock
FAIL: TestLargeStringConcat
FAIL: TestLockedDeadlock
FAIL: TestLockedDeadlock2
FAIL: TestLockOSThreadExit
FAIL: TestMainGoroutineID
FAIL: TestNetpollDeadlock
FAIL: TestNoHelperGoroutines
FAIL: TestNumGoroutine
FAIL: TestPanicAfterGoexit
FAIL: TestPanicDeadlockGosched
FAIL: TestPanicDeadlockSyscall
FAIL: TestPanicLoop
FAIL: TestPanicRace
FAIL: TestPanicTraceback
FAIL: TestRecoveredPanicAfterGoexit
FAIL: TestRecursivePanic
FAIL: TestSignalDuringExec
FAIL: TestSignalExitStatus
FAIL: TestSignalIgnoreSIGTRAP
FAIL: TestSigStackSwapping
FAIL: TestSimpleDeadlock
FAIL: TestThreadExhaustion
FAIL: go test misc/cgo/test
FAIL: go test misc/cgo/testcarchive
FAIL: go test cmd/vet

[Bug bootstrap/85630] New: GCC 8.1.0: Filesystem pollution during build: .cache dir in $HOME

[kdevel at vogtner dot de]

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

Bug ID: 85630
   Summary: GCC 8.1.0: Filesystem pollution during build: .cache
dir in $HOME
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

After a make bootstrap and make test (which failed, Bug 85629) a directory
named ".cache" is left over in $HOME. It contains a sub-directory "go-build":

$ ls
00  09  12  1b  24  2d  36  3f  48  51  5a  63  6c  75  7e  87  90  99  a2  ab 
b4  bd  c6  cf  d8  e1  ea  f3  fc
01  0a  13  1c  25  2e  37  40  49  52  5b  64  6d  76  7f  88  91  9a  a3  ac 
b5  be  c7  d0  d9  e2  eb  f4  fd
02  0b  14  1d  26  2f  38  41  4a  53  5c  65  6e  77  80  89  92  9b  a4  ad 
b6  bf  c8  d1  da  e3  ec  f5  fe
03  0c  15  1e  27  30  39  42  4b  54  5d  66  6f  78  81  8a  93  9c  a5  ae 
b7  c0  c9  d2  db  e4  ed  f6  ff
04  0d  16  1f  28  31  3a  43  4c  55  5e  67  70  79  82  8b  94  9d  a6  af 
b8  c1  ca  d3  dc  e5  ee  f7  log.txt
05  0e  17  20  29  32  3b  44  4d  56  5f  68  71  7a  83  8c  95  9e  a7  b0 
b9  c2  cb  d4  dd  e6  ef  f8  README
06  0f  18  21  2a  33  3c  45  4e  57  60  69  72  7b  84  8d  96  9f  a8  b1 
ba  c3  cc  d5  de  e7  f0  f9  trim.txt
07  10  19  22  2b  34  3d  46  4f  58  61  6a  73  7c  85  8e  97  a0  a9  b2 
bb  c4  cd  d6  df  e8  f1  fa
08  11  1a  23  2c  35  3e  47  50  59  62  6b  74  7d  86  8f  98  a1  aa  b3 
bc  c5  ce  d7  e0  e9  f2  fb

$ cat README 
This directory holds cached build artifacts from the Go build system.
Run "go clean -cache" if the directory is getting too large.
See golang.org to learn more about Go.

These files shall be placed in the build-directory and not in $HOME.

[Bug libstdc++/84087] string::assign problem with two arguments

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 15:01:20 2018
New Revision: 259895

URL: https://gcc.gnu.org/viewcvs?rev=259895&root=gcc&view=rev
Log:
PR libstdc++/84087 add default arguments to basic_string members (LWG 2268)

This change was a DR against C++11 and so should have been implemented
years ago.

PR libstdc++/84087 LWG DR 2268 basic_string default arguments
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI=1]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Add default arguments (LWG 2268).
[_GLIBCXX_USE_CXX11_ABI=0]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Likewise.
* testsuite/21_strings/basic_string/dr2268.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/21_strings/basic_string/dr2268.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/basic_string.h

[Bug fortran/85631] New: Runtime error message array bound mismatch with nonzero optimization

[zeccav at gmail dot com]

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

Bug ID: 85631
   Summary: Runtime error message array bound mismatch with
nonzero optimization
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

! Runtime error message on good Fortran
! gfortran -O -g -fcheck=bounds
! must be compiled and run
!At line 20 of file pcp2k.f
!Fortran runtime error: Array bound mismatch for dimension 1 of array
'__var_1_mma' (0/2)

!Error termination. Backtrace:
!#0  0x1496530ec2de in ???
!#1  0x1496530ece89 in ???
!#2  0x1496530ed26b in ???
!#3  0x40082d in MAIN__
!   at /home/vitti/test/pcp2k.f:8
!#4  0x40086e in main
!   at /home/vitti/test/pcp2k.f:9
  integer, parameter :: N=2
  real, dimension(:,:), pointer :: block_1, block_2
  allocate(block_1(N,N),block_2(N,N))
  block_1=0
  block_2=0
  block_1 = MATMUL(TRANSPOSE(block_1), block_2)
  end

[Bug libstdc++/84087] string::assign problem with two arguments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|deferred|
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #7 from Jonathan Wakely  ---
This is fixed on trunk now. I'll probably backport it to the release branches.

[Bug fortran/85631] [8/9 Regression] Runtime error message array bound mismatch with nonzero optimization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||wrong-code
   Last reconfirmed||2018-05-03
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Runtime error message array |[8/9 Regression] Runtime
   |bound mismatch with nonzero |error message array bound
   |optimization|mismatch with nonzero
   ||optimization
   Target Milestone|--- |8.2
  Known to fail||8.1.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 8 and trunk (9.0), likely r248553. Usual workaround: compile with
-fno-frontend-optimize.

[Bug libstdc++/85632] New: std::filesystem::space or std::experimental::filesystem::space does not return correct information

[bandinfinite at gmail dot com]

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

Bug ID: 85632
   Summary: std::filesystem::space or
std::experimental::filesystem::space does not return
correct information
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bandinfinite at gmail dot com
  Target Milestone: ---

I'm typing this report on my phone so forgive me for not perfect formatting.
The bug is simple, filesystem::space() probably won't return correct info for
most modern  storage device that contain a big enough partition (anything more
than 4GB   counts). The cause of this bug is simply that the author forgot
static_cast(data retrieved by statvfs) before the calculation. So
the fix is also trivial and can definitely backport to all version  contain
experimental::filesystem.
The latest 8.1 release shares this bug, confirmed with the git mirror hours
ago.

[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Bah, now we have failures for TR1 with -std=c++17 or -std=c++2a:


$ ~/gcc/8/bin/g++ -std=c++17 -include tr1/cmath -x c++ /dev/null 
In file included from :
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1163:20: error:
‘__gnu_cxx::conf_hypergf’ has not been declared
   using __gnu_cxx::conf_hypergf;
^~~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1164:20: error:
‘__gnu_cxx::conf_hypergl’ has not been declared
   using __gnu_cxx::conf_hypergl;
^~~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1165:20: error:
‘__gnu_cxx::conf_hyperg’ has not been declared
   using __gnu_cxx::conf_hyperg;
^~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1203:20: error:
‘__gnu_cxx::hypergf’ has not been declared
   using __gnu_cxx::hypergf;
^~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1204:20: error:
‘__gnu_cxx::hypergl’ has not been declared
   using __gnu_cxx::hypergl;
^~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1205:20: error:
‘__gnu_cxx::hyperg’ has not been declared
   using __gnu_cxx::hyperg;
^~

[Bug libstdc++/85632] std::filesystem::space or std::experimental::filesystem::space does not return correct information

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-03
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/85633] New: [8 Regression] reorders function ignoring fpu exception state

[jtaylor.debian at googlemail dot com]

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

Bug ID: 85633
   Summary: [8 Regression] reorders function ignoring fpu
exception state
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com
  Target Milestone: ---

gcc-8 seems to ignore the global fpu exception state when reordering functions.
In this example it reorders the fpu_invalid_set_function which is _not_ marked
as const before the last _mm_min_ps call which can set the fpu invalid
exception.

#include 
int fpu_invalid_set(void);
float reduce(__m128 a);

float fun(float *a)
{
__m128 c1 = _mm_set_ps1(1000);
__m128 c2 = _mm_set_ps1(1000);
for (int i=0; i < 64; i+=8) {
__m128 x1 = _mm_loadu_ps(&a[i]);
__m128 x2 = _mm_loadu_ps(&a[i+4]);
c1 = _mm_min_ps(c1, x1);
c2 = _mm_min_ps(c2, x2);
}
c1 = _mm_min_ps(c1, c2);
if (fpu_invalid_set()) {
return 1;
}
else {
return reduce(c1);
}
}

gcc -O2 -c fun.c
objdump -d fun.o
 :
   0:   48 83 ec 28 sub$0x28,%rsp
   4:   0f 28 0d 00 00 00 00movaps 0x0(%rip),%xmm1# b 
   b:   48 8d 87 00 01 00 00lea0x100(%rdi),%rax
  12:   0f 28 c1movaps %xmm1,%xmm0
  15:   0f 1f 00nopl   (%rax)
  18:   0f 10 17movups (%rdi),%xmm2
  1b:   0f 10 5f 10 movups 0x10(%rdi),%xmm3
  1f:   48 83 c7 20 add$0x20,%rdi
  23:   0f 5d c2minps  %xmm2,%xmm0
  26:   0f 5d cbminps  %xmm3,%xmm1
  29:   48 39 f8cmp%rdi,%rax
  2c:   75 ea   jne18 
  2e:   0f 29 44 24 10  movaps %xmm0,0x10(%rsp)
  33:   0f 29 0c 24 movaps %xmm1,(%rsp)
  37:   e8 00 00 00 00  callq  3c   call to early
  3c:   0f 28 0c 24 movaps (%rsp),%xmm1
  40:   0f 28 44 24 10  movaps 0x10(%rsp),%xmm0
  45:   85 c0   test   %eax,%eax
  47:   74 17   je 60 
  49:   f3 0f 10 05 00 00 00movss  0x0(%rip),%xmm0# 51 
  50:   00 
  51:   48 83 c4 28 add$0x28,%rsp
  55:   c3  retq   
  56:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  5d:   00 00 00 
  60:   0f 5d c1minps  %xmm1,%xmm0 <<< min at wrong
place
  63:   48 83 c4 28 add$0x28,%rsp
  67:   e9 00 00 00 00  jmpq   6c 


gcc 7 and earlier execute the minps instruction before calling the function
that checks the fpu state.

[Bug middle-end/85633] reorders function ignoring fpu exception state

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
Summary|[8 Regression] reorders |reorders function ignoring
   |function ignoring fpu   |fpu exception state
   |exception state |

--- Comment #1 from Andrew Pinski  ---
There is no tie between FPU operations and function calls.  This is not a
regression as it was just done by accident between GCC 8.

[Bug middle-end/85633] reorders function ignoring fpu exception state

[jtaylor.debian at googlemail dot com]

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

--- Comment #2 from Julian Taylor  ---
changing the fpu state does not count as a side effect?
This doesn't seem plausible, this type of code is one the reasons the fpu
exception state exists.
There is a lot of code written with this in mind which worked for decades and
now not anymore. I think that classifies as a regression.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #30 from Vincent  ---
Am using OSX, but I do not believe it makes a big difference. Thanks, Jonathan,
let me know if I can help in any way.

(In reply to Jonathan Wakely from comment #29)
> (In reply to Vincent from comment #27)
> > Sorry for the silly check, are you sure you are trying with -O3 or
> > -fdevirtualize -O2? 
> 
> I've tried both. I'm using x86_64-pc-linux-gnu though.
> 
> 
> > You can try this with 8.1:
> > 
> > void *v;
> > 
> > template 
> > struct LK: public BLKC
> > {
> >   void rb(){((T*)v)->ax();}
> >   static T* st;
> > };
> > 
> > As a replacement to the call to null, and the missing definition problem is
> > reported.
> 
> OK now I can reproduce it with trunk.
> 
> (In reply to Vincent from comment #28)
> > Other silly check, did you try with my code or your reduced code ?
> 
> Yours.
> 
> Here's the reduced form that gives a link-error with trunk:
> 
> #include 
> 
> template 
> struct RE
> {
>   virtual void rp()=0;
>   void ax(){rp();}
> };
> 
> struct EN : RE
> {
>   EN(::std::string = ""){}
>   void rp(){}
> };
> 
> template 
> struct AN : RE
> {
>   void rp(){}
> };
> 
> template 
> struct LK
> {
>   T* p = nullptr;
>   virtual void rb(){p->ax();}
> };
> 
> template 
> struct LR
> {
>   virtual ~LR(){}
>   struct LLC { virtual ~LLC(){} };
>   LK> l;
> };
> 
> constexpr char ET[]="";
> struct I : EN
> {
>   LR _e;
> };
> 
> int main(){new I();}
> 
> 
> $ ~/gcc/8.1.0/bin/g++ -Wall -O1 -fdevirtualize main.cc 
> main.cc:19:8: warning: ‘void AN::rp() [with OC = LR<(& ET)>::LLC]’ used
> but never defined
>void rp(){}
> ^~
> /tmp/cc4IHAPf.o: In function `LK::LLC> >::rb()':
> main.cc:(.text+0x37): undefined reference to `AN::LLC>::rp()'
> collect2: error: ld returned 1 exit status

[Bug middle-end/85633] reorders function ignoring fpu exception state

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
See PR 38960 for why I said this is not a regression.

[Bug target/85628] Make better use of BFI (BFXIL)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>This should just be a matter of adding the necessary patterns in aarch64.md.

I was doing for MIPS and it was rejected because combine or something before
combine should be generating zero_extract on the set side.

[Bug c++/85634] New: 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

Bug ID: 85634
   Summary: 8.1 ICE in tsubst_copy, at cp/pt.c:15483
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at ishiboo dot com
  Target Milestone: ---

Easily reproducible on a RHEL6 Linux box using the just released GCC 8.1.0
compiler built from source.

1) Clone https://github.com/bloomberg/bde
2) cd bde/groups/bsl/bslstl
3) Compile bslstl_queue.t.cpp

The full compiler command line and output is:

g++-8 \
-Wall -Wno-unused-variable \
-DBDE_BUILD_TARGET_EXC \
-DBDE_BUILD_TARGET_MT \
-DBDE_BUILD_TARGET_OPT \
-fexceptions \
-O2 \
-fno-gcse \
-fno-strict-aliasing \
-DNDEBUG \
-D_POSIX_PTHREAD_SEMANTICS \
-D_REENTRANT \
-D_FILE_OFFSET_BITS=64 \
-DBDE_NO_CPP_STDLIB \
-D_RWSTD_COMPILE_INSTANTIATE=1 \
-I. \
-I../bslalg \
-I../bsltf \
-I../bslma \
-I../bslh \
-I../bslmf \
-I../bslscm \
-I../bsls \
-c \
-o /dev/null \
bslstl_queue.t.cpp

Output:

bslstl_queue.t.cpp: In instantiation of 'static void TestDriver::testCase6() [with VALUE = signed char; CONTAINER =
bsl::deque >]':
bslstl_queue.t.cpp:6618:9:   required from here
bslstl_queue.t.cpp:5114:21: internal compiler error: in tsubst_copy, at
cp/pt.c:15483
 operatorPtr operatorEq = operator==;
 ^~
0x6fe553 tsubst_copy
../../gcc/cp/pt.c:15483
0x6f75dc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18975
0x6fc177 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17412
0x6fd5e5 tsubst_init
../../gcc/cp/pt.c:15274
0x6fce7e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16726
0x6fbb04 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16599
0x6fc0b5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16896
0x6fbb04 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16599
0x6fc0b5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16896
0x6fa6ad instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:23977
0x715b1b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24093
0x673430 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4725
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Please submit a full bug report, with preprocessed source if appropriate.

[Bug middle-end/85633] reorders function ignoring fpu exception state

[jtaylor.debian at googlemail dot com]

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

--- Comment #4 from Julian Taylor  ---
Oh that is unfortunate.
I guess one has to inject the dependency in the fpu checking function as an
argument then.

[Bug c++/80947] [6/7 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[duarte at scylladb dot com]

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

Duarte  changed:

   What|Removed |Added

 CC||duarte at scylladb dot com

--- Comment #16 from Duarte  ---
This is happening again in g++ (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20).

[Bug libstdc++/84769] variant::get(): unscoped call to get

[duarte at scylladb dot com]

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

--- Comment #6 from Duarte  ---
I think that calls to get<0> should be scoped, for example in visit().

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

--- Comment #2 from Andrew Paprocki  ---
Created attachment 44057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44057&action=edit
-save-temps output

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

--- Comment #3 from Andrew Paprocki  ---
Compiler info:

$ g++-8 -v
Reading specs from /dev/shm/refroot/opt/bb/lib/gcc-8.1/bin/../lib/gcc/specs
COLLECT_GCC=/dev/shm/refroot/opt/bb/bin/g++-8
COLLECT_LTO_WRAPPER=/dev/shm/refroot/opt/bb/lib/gcc-8.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran,go
--build=x86_64-unknown-linux-gnu --prefix=/opt/bb/lib/gcc-8.1
--with-ar=/opt/rh/devtoolset-4/root/usr/bin/ar
--with-ld=/opt/rh/devtoolset-4/root/usr/bin/ld
--with-nm=/opt/rh/devtoolset-4/root/usr/bin/nm
--with-objcopy=/opt/rh/devtoolset-4/root/usr/bin/objcopy
--with-objdump=/opt/rh/devtoolset-4/root/usr/bin/objdump
--with-ranlib=/opt/rh/devtoolset-4/root/usr/bin/ranlib
--with-readelf=/opt/rh/devtoolset-4/root/usr/bin/readelf
--with-gmp-include=/opt/bb/include --with-gmp-lib=/opt/bb/lib64
--with-mpfr-include=/opt/bb/include --with-mpfr-lib=/opt/bb/lib64
--with-mpc-include=/opt/bb/include --with-mpc-lib=/opt/bb/lib64
--with-libiconv-prefix=/tmp/gcc-8.1-8.1.0-0/build/iconv
--with-stage1-ldflags='-Wl,--enable-new-dtags  -Wl,-R/opt/bb/lib64'
--with-boot-ldflags='-Wl,--enable-new-dtags  -Wl,-R/opt/bb/lib64'
--enable-plugin --enable-vtable-verify --disable-bootstrap
Thread model: posix
gcc version 8.1.0

Host info:

RHEL6 

$ uname -a
Linux nylxdev1 2.6.32-642.6.2.el6.x86_64 #1 SMP Mon Oct 24 10:22:33 EDT 2016
x86_64 x86_64 x86_64 GNU/Linux

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

--- Comment #4 from Andrew Paprocki  ---
(In reply to Marek Polacek from comment #1)
> Please submit a full bug report, with preprocessed source if appropriate.

I had to attach the .ii and .s file tgz'd due to the file size limit of the
bugtracker.