[Bug target/83220] modification of a global register variable while the function only reads from it

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra, wrong-code
 Target||x86_64-*-* i?86-*-*
  Component|c   |target
Version|unknown |8.0

--- Comment #1 from Richard Biener  ---
Try -ffixed-rbp, not sure if your expectations are valid.  It might have to do
with a regstack thing given you use x87 math.

Confirmed on trunk with -O2, -ffixed-rbp seems to work.

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-30
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|other   |sanitizer
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a looksee.

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #10 from Richard Biener  ---
Somehow after being reasonable for some time this regressed badly again...

Last known good rev. 254418, first known bad rev. 254511

slows down our regular tester by some hours :/

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Note it happens at -O0 already (going OOM) so a FE issue (was fine before).

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Hmm, no, all memory is allocate by IRA (and somehow never freed?)

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Bisection would be nice.

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Tops out at 4.4GB now at -O0, was hovering around 1GB for some time.

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Hum.  Where do we "instrument" __builtin_unreachable () for UBSAN?  EVRP
is now more aggressive with recording ranges, where VRP does it only for
SSA names used dominated by an edge EVRP does it always.  This makes us
optimize away the test before RTL expansion (where the instrumentation
happens?).

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[hainque at gcc dot gnu.org]

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

Olivier Hainque  changed:

   What|Removed |Added

  Attachment #42747|[patch] don't emit  |don't emit
description|.cfi_personality/.cfi_lsda  |.cfi_personality/.cfi_lsda
   |for !dwarf2 eh  |for !dwarf2 eh

--- Comment #11 from Olivier Hainque  ---
Comment on attachment 42747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42747
don't emit .cfi_personality/.cfi_lsda for !dwarf2 eh

>diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>index 3d619b8..62b5c77 100644
>--- a/gcc/dwarf2out.c
>+++ b/gcc/dwarf2out.c
>@@ -958,10 +958,16 @@ dwarf2out_do_cfi_startproc (bool second)
> {
>   int enc;
>   rtx ref;
>-  rtx personality = get_personality_function (current_function_decl);
> 
>   fprintf (asm_out_file, "\t.cfi_startproc\n");
> 
>+  /* .cfi_personality and .cfi_lsda are only relevant to DWARF2
>+ eh unwinders.  */
>+  if (targetm_common.except_unwind_info (&global_options) != UI_DWARF2)
>+return;
>+
>+  rtx personality = get_personality_function (current_function_decl);
>+
>   if (personality)
> {
>   enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2, /*global=*/1);

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
pass_sanopt it seems.  Quite late.  So how is this supposed to work?

The testcase is

int e;

int
main (void)
{
  return e ? 0 : (__builtin_unreachable (), 1);
}

and I bet that if we do

int e;

int
main (void)
{
  if (e)
   return e;
  __builtin_unreachable ();
}

we'd optimize it before with regular VRP.

Yes, we do.

So - why are __builtin_unreachable ()s not instrumented early?  They are,
after all, no longer "unreachable".

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
And the testcase runs exclusively at -O2 for whatever reason...

Marek, you introduced this testcase together with moving instrumentation to
sanopt.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[hubicka at gcc dot gnu.org]

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

--- Comment #35 from Jan Hubicka  ---
Author: hubicka
Date: Thu Nov 30 09:36:36 2017
New Revision: 255268

URL: https://gcc.gnu.org/viewcvs?rev=255268&root=gcc&view=rev
Log:
PR target/81616
* x86-tnue-costs.h (generic_cost): Revise for modern CPUs
* gcc.target/i386/l_fma_double_1.c: Update count of fma instructions.
* gcc.target/i386/l_fma_double_2.c: Update count of fma instructions.
* gcc.target/i386/l_fma_double_3.c: Update count of fma instructions.
* gcc.target/i386/l_fma_double_4.c: Update count of fma instructions.
* gcc.target/i386/l_fma_double_5.c: Update count of fma instructions.
* gcc.target/i386/l_fma_double_6.c: Update count of fma instructions.
* gcc.target/i386/l_fma_float_1.c: Update count of fma instructions.
* gcc.target/i386/l_fma_float_2.c: Update count of fma instructions.
* gcc.target/i386/l_fma_float_3.c: Update count of fma instructions.
* gcc.target/i386/l_fma_float_4.c: Update count of fma instructions.
* gcc.target/i386/l_fma_float_5.c: Update count of fma instructions.
* gcc.target/i386/l_fma_float_6.c: Update count of fma instructions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/x86-tune-costs.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_1.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_2.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_3.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_4.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_5.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_6.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_1.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_2.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_3.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_4.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_5.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_6.c

[Bug rtl-optimization/83213] [8 Regression] peephole bug with -O2

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Created attachment 42749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42749&action=edit
C source code

After 12 hours reducing, this is what I got.

I think creduce isn't very fast, in some cases.

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Because new __builtin_unreachable calls are added everywhere in the
optimization pipeline.  I'd rather disable the optimizations where we remove
conditionals or switches that branch to __builtin_unreachable if
(sanitize_flags_p (SANITIZE_UNREACHABLE)).
Not sure where exactly that is though.  I see:
  /* Discard cases that have an unreachable destination block.  */
  if (EDGE_COUNT (base_bb->succs) == 0
  && gimple_seq_unreachable_p (bb_seq (base_bb)))
{
  edge base_edge = find_edge (gimple_bb (stmt), base_bb);
  if (base_edge != NULL)
remove_edge_and_dominated_blocks (base_edge);
  i = next_index;
  continue;
}
but that is something for switches only, where do we do this for GIMPLE_COND?

BTW, on a related note, I had to skip in c-c++-common/tsan/pr81275.c the -O2 +
C++ testing, the problem there is that the -Wreturn-type warning for C++ needs
the __builtin_unreachable () call too, but that goes away already during cfg
pass right before it.  Would it be possible to defer that until after the
pass_warn_function_return if it is the BUILTINS_LOCATION __builtin_unreachable
()?

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
For the -fsanitize=unreachable, maybe just gimple_seq_unreachable_p shouldn't
return true ever if sanitize_flags_p (SANITIZE_UNREACHABLE).

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 30 Nov 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83219
> 
> --- Comment #5 from Jakub Jelinek  ---
> Because new __builtin_unreachable calls are added everywhere in the
> optimization pipeline.  I'd rather disable the optimizations where we remove
> conditionals or switches that branch to __builtin_unreachable if
> (sanitize_flags_p (SANITIZE_UNREACHABLE)).
> Not sure where exactly that is though.  I see:
>   /* Discard cases that have an unreachable destination block.  */
>   if (EDGE_COUNT (base_bb->succs) == 0
>   && gimple_seq_unreachable_p (bb_seq (base_bb)))
> {
>   edge base_edge = find_edge (gimple_bb (stmt), base_bb);
>   if (base_edge != NULL)
> remove_edge_and_dominated_blocks (base_edge);
>   i = next_index;
>   continue;
> }
> but that is something for switches only, where do we do this for GIMPLE_COND?

See callers of assert_unreachable_fallthru_edge_p ()

[Bug fortran/83224] creating character array from elements shorter than declared does not pad with whitespace properly and aborts

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-30
 Blocks||68241
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 5.5.0 up to trunk.

With the reduced test case

program dusty_corner ! exercise f2008 CHARACTER features
implicit none
character(len=:),allocatable :: words(:)
character(len=:),allocatable :: words1(:), words2(:)

words1=[character(len=3) :: 'one', 'two']
words2=[character(len=5) :: words1, 'three']
write(*,'(5("[",a,"]":))')words2

words=[character(len=3) :: 'one', 'two']
words=[character(len=5) :: words, 'three']
write(*,'(5("[",a,"]":))')words

end program dusty_corner

I get

[one  ][two  ][three]
[onetw][twoth][three]

The problem comes from using 'words' in both sides of the assignment.


Referenced Bugs:

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

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 30 Nov 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83219
> 
> --- Comment #6 from Jakub Jelinek  ---
> For the -fsanitize=unreachable, maybe just gimple_seq_unreachable_p shouldn't
> return true ever if sanitize_flags_p (SANITIZE_UNREACHABLE).

That probably will work in practice.

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
(In reply to rguent...@suse.de from comment #5)
> On November 29, 2017 4:35:12 PM GMT+01:00, "thopre01 at gcc dot gnu.org"
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83216
> >
> >--- Comment #3 from Thomas Preud'homme 
> >---
> >(In reply to Richard Biener from comment #2)
> >> Can't reproduce 
> >> 
> >> What ISL version are you using?
> >
> >ISL 0.15.
> 
> That's outdated. Can you try 0.18?
> 
> Richard. 
> 
> >Also my apologies but I haven't tried on Arm Cortex-M7 yet actually,
> >typed it
> >in as a force of habit.
> >
> >Best regards.

Fair enough, it PASSes with 0.18. I'm happy having this bug closed then. Sorry
for the noise.

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 30 10:29:58 2017
New Revision: 255269

URL: https://gcc.gnu.org/viewcvs?rev=255269&root=gcc&view=rev
Log:
PR target/83210
* internal-fn.c (expand_mul_overflow): Optimize unsigned
multiplication by power of 2 constant into two shifts + comparison.

* gcc.target/i386/pr83210.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr83210.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #7 from Christophe Lyon  ---
https://gcc.gnu.org/install/prerequisites.html needs an update then: it still
refers to isl 0.15.

contrib/download_prerequisites fetches 0.18, and it is available on
ftp://gcc.gnu.org/pub/gcc/infrastructure/

[Bug fortran/83225] New: [8.0 regression] runtime error in transfer.c

[juergen.reuter at desy dot de]

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

Bug ID: 83225
   Summary: [8.0 regression] runtime error in transfer.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

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

The attached example which I unfortunately couldn't further reduce leads to the
following runtime error: 
2$ ./rt_error 
   4
At line 3218 of file main_ut.f90
Fortran runtime error: End of file

Error termination. Backtrace:
#0  0x7f70c18c9004 in formatted_transfer_scalar_write
at ../../../libgfortran/io/transfer.c:2059
#1  0x7f70c18c916c in formatted_transfer
at ../../../libgfortran/io/transfer.c:2279
#2  0x42bd6f in ???
#3  0x42c664 in ???
#4  0x42c69b in ???
#5  0x7f70c0bc9f44 in ???
#6  0x401288 in ???
#7  0x in ???

The gcc/gfortran version is r255190 with the patch from 
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-7-branch/gcc/fortran/resolve.c?r1=255029&r2=255205&pathrev=255205
applied. 
The reproducer works with gfortran 4.8, 4.9, 5, 6, 7, nagfor 6.1 and ifort 17
and 18. It contains the iso_varying_string module.

[Bug rtl-optimization/83213] [8 Regression] peephole bug with -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
My bisection says it starts with r249104, but that doesn't make sense, so it is
likely r249097 or r249098 or some other change from that time.

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 42751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42751&action=edit
gcc8-pr83219.patch

Untested fix.

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[andrey.y.guskov at intel dot com]

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

--- Comment #10 from Andrey Guskov  ---
Confirmed on Haswell and Silvermont.

[Bug tree-optimization/83043] [8 Regression] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #7 from Andrey Guskov  ---
Confirmed on Silvermont.

[Bug fortran/83225] [8.0 regression] runtime error in transfer.c

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-30
 CC||jvdelisle at gcc dot gnu.org
  Known to work||7.2.0
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed, could be r254982 (pr78549).

[Bug c++/83226] New: [7 Regression] std::map with reference T breaks in C++17 mode

[sgunderson at bigfoot dot com]

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

Bug ID: 83226
   Summary: [7 Regression] std::map with reference T breaks in
C++17 mode
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

Hi,

The following code works under GCC for -std=c++14, but breaks under -std=c++17:

#include 
#include 

int main(void)
{
  std::map m;
  std::pair val(3, 4);
  m.insert(val);  // Compile error.
  m.emplace(3, 4);  // Works.
}

I've looked briefly through the standard, but I can't see anything that
indicates you can't have a const reference as value type (not that I'd
recommend it!). The error messages given are:

In file included from /usr/include/c++/7/bits/stl_iterator.h:66:0,
 from /usr/include/c++/7/bits/stl_algobase.h:67,
 from /usr/include/c++/7/bits/stl_tree.h:63,
 from /usr/include/c++/7/map:60,
 from test.cc:1:
/usr/include/c++/7/bits/ptr_traits.h: In substitution of ‘template
template using rebind = _Up* [with _Up = const int&; _Tp =
std::_Rb_tree_node >]’:
/usr/include/c++/7/bits/ptr_traits.h:147:77:   required by substitution of
‘template using __ptr_rebind = typename
std::pointer_traits::rebind<_Tp> [with _Ptr =
std::allocator_traits > > >::pointer; _Tp = const int&]’
/usr/include/c++/7/bits/node_handle.h:203:69:   required by substitution of
‘template template using
__pointer = std::__ptr_rebind::pointer, _Tp> [with _Tp = std::pair::second_type; _Key = int; _Value = std::pair; _NodeAlloc = std::allocator > >]’
/usr/include/c++/7/bits/node_handle.h:206:60:   required from ‘class
std::_Node_handle,
std::allocator > > >’
test.cc:8:15:   required from here
/usr/include/c++/7/bits/ptr_traits.h:133:28: error: forming pointer to
reference type ‘const int&’
 using rebind = _Up*;
^

Confirmed with 20171109 snapshot. Clang 5.0.0 with the same libstdc++ gives a
similar error, so I believe this is about the standard library, not the
compiler (unless it's an invalid program).

GCC 6.4.0 does not give an error here, so I'm marking this as a regression.

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 30 Nov 2017, clyon at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83216
> 
> Christophe Lyon  changed:
> 
>What|Removed |Added
> 
>  CC||clyon at gcc dot gnu.org
> 
> --- Comment #7 from Christophe Lyon  ---
> https://gcc.gnu.org/install/prerequisites.html needs an update then: it still
> refers to isl 0.15.

Yeah, that's the version that also "works" but given testcases behave
differently with different ISL versions I have to chose a version
to match them up with...

> contrib/download_prerequisites fetches 0.18, and it is available on
> ftp://gcc.gnu.org/pub/gcc/infrastructure/

Yes.

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

[Bug fortran/83225] [8.0 regression] runtime error in transfer.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug sanitizer/83219] [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 30 Nov 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83219
> 
> --- Comment #9 from Jakub Jelinek  ---
> Created attachment 42751
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42751&action=edit
> gcc8-pr83219.patch
> 
> Untested fix.

works for me.

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[rai...@emrich-ebersheim.de]

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

--- Comment #12 from Rainer Emrich  ---
(In reply to Olivier Hainque from comment #11)
> Comment on attachment 42747 [details]
> don't emit .cfi_personality/.cfi_lsda for !dwarf2 eh
> 
> >diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> >index 3d619b8..62b5c77 100644
> >--- a/gcc/dwarf2out.c
> >+++ b/gcc/dwarf2out.c
> >@@ -958,10 +958,16 @@ dwarf2out_do_cfi_startproc (bool second)
> > {
> >   int enc;
> >   rtx ref;
> >-  rtx personality = get_personality_function (current_function_decl);
> > 
> >   fprintf (asm_out_file, "\t.cfi_startproc\n");
> > 
> >+  /* .cfi_personality and .cfi_lsda are only relevant to DWARF2
> >+ eh unwinders.  */
> >+  if (targetm_common.except_unwind_info (&global_options) != UI_DWARF2)
> >+return;
> >+
> >+  rtx personality = get_personality_function (current_function_decl);
> >+
> >   if (personality)
> > {
> >   enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2, /*global=*/1);

Confirmed, this patch solves the issue.

Thanks

[Bug target/83156] [8 regression] gcc.target/i386/pr82361-1.c fail

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Fixed.

[Bug libstdc++/21549] Configure options hard to find

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
The issue of undocumented configure options also came up in bug 82824, although
that was a tangent so I won't add it under "See Also" 

(In reply to Benjamin Kosnik from comment #3)
> 
> As an aside, are a lot of these java config opts actually still relevant?
> 
> -benjamin

No, java has been removed.

[Bug fortran/82622] [PDT] ICE in structure_alloc_comps, at fortran/trans-array.c:8963

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
I have just submitted a complete fix to the list, including the problem in
comment #1.

Paul

[Bug c++/83226] [7/8 Regression] std::map with reference T breaks in C++17 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-30
  Known to work||6.4.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|[7 Regression] std::map |[7/8 Regression] std::map
   |with reference T breaks in  |with reference T breaks in
   |C++17 mode  |C++17 mode
 Ever confirmed|0   |1

[Bug c/83222] [8 regression] Inconsistent "initializer element is not constant" error

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Well, even GCC 7 and older were doing it, but only with -O1 and above.

[Bug c/83222] [8 regression] Inconsistent "initializer element is not constant" error

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 42752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42752&action=edit
gcc8-pr83222.patch

Perhaps we can do something like this and in initializers try to behave more
consistently even when outside of functions.  Or in the other direction, handle
static var initializers even in functions like those outside of functions.

[Bug c++/83227] New: [7 Regression] internal compiler error: in process_init_constructor_array

[sgunderson at bigfoot dot com]

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

Bug ID: 83227
   Summary: [7 Regression] internal compiler error: in
process_init_constructor_array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

I believe this is distinct from #82593, so I'm filing it as a separate bug.

The following test program dies with GCC 7.2.0 with -std=c++17:

#include 
#include 

struct Direction {
 Direction() {}
};

struct Front_back : public Direction {
  Front_back() : Direction() {}
};

void foo(const std::vector &elements);

void bar() {
  foo({ Front_back{} });
}

test.cc: In function ‘void bar()’:
test.cc:15:23: internal compiler error: in process_init_constructor_array, at
cp/typeck2.c:1308
   foo({ Front_back{} });
   ^
Please submit a full bug report,
with preprocessed source if appropriate.

It works with GCC 6.4.0, and also with -std=c++14. It's still there in the
20171109 snapshot.

Reduced preprocessed case:

namespace std {
template  class initializer_list {
  const a *b;
  unsigned long c;
};
struct e {
  e(int);
};
template  class f : e {
public:
  f(initializer_list, int g = int()) : e(g) {}
};
}
struct h {};
struct i : h {
  i();
};
void foo(std::f) { foo({i{}}); }

[Bug c++/83204] [6/7/8 Regression] c++ -std=c++14 ICE in maybe_undo_parenthesized_ref, at cp/semantics.c:1694

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-30
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r236616.
I think this is related to maybe_undo_parenthesized_ref relying on
REF_PARENTHESIZED_P operands being in a certain form, which is what
force_paren_expr creates.  But in pt.c we have:
tree r = RECUR (TREE_OPERAND (t, 0));

if (REFERENCE_REF_P (t))
  {
/* A type conversion to reference type will be enclosed in
   such an indirect ref, but the substitution of the cast
   will have also added such an indirect ref.  */
r = convert_from_reference (r);
  }
else
  r = build_x_indirect_ref (input_location, r, RO_UNARY_STAR,
complain|decltype_flag);

if (TREE_CODE (r) == INDIRECT_REF)
  REF_PARENTHESIZED_P (r) = REF_PARENTHESIZED_P (t);
where we copy over the bit, even when the tsubsted operand might be completely
different.  So should maybe_undo_parenthesized_ref be able to cope with any
other form (and how), or should we not set REF_PARENTHESIZED_P if the form of
r's operands no longer matches, something else?

[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Broken with r254548.
Self-contained testcase:

typedef long long V __attribute__((vector_size (32)));

V
foo (long long x)
{
  return (V) { x };
}

I'll have a look.

[Bug c++/83226] [7/8 Regression] std::map with reference T breaks in C++17 mode

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Thu Nov 30 13:45:37 2017
New Revision: 255271

URL: https://gcc.gnu.org/viewcvs?rev=255271&root=gcc&view=rev
Log:
PR libstdc++/83226 avoid forming pointer-to-reference type

PR libstdc++/83226
* include/bits/node_handle.h (_Node_handle::__pointer): Avoid forming
pointer-to-reference types.
* testsuite/23_containers/map/modifiers/insert/83226.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/insert/83226.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/node_handle.h

[Bug fortran/83224] creating character array from elements shorter than declared does not pad with whitespace properly and aborts

[urbanjost at comcast dot net]

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

--- Comment #2 from urbanjost at comcast dot net ---
Thanks for checking on this so quickly. I did not reduce my example any further
than I did because it would just print without padding with blanks the way I
expected and not abort if I made it shorter; using your reduced test and just
trying a few times I see that the abort occurs when the new length is 9 and the 
previous length was 8 or less. I added back a few lines to demonstrate just in
case that is significant, maybe a second problem (ignore otherwise)?

[one  ][two  ][three]
[GOT HERE][onetwtwo][twoththr][threethr][three   ]

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:

JSU@buzz ~
$ cat yyy.f90

program dusty_corner ! exercise f2008 CHARACTER features
implicit none
character(len=:),allocatable :: words(:)
character(len=:),allocatable :: words1(:), words2(:)

words1=[character(len=3) :: 'one', 'two']
words2=[character(len=5) :: words1, 'three']
write(*,'(5("[",a,"]":))')words2

words=[character(len=3) :: 'one', 'two']
words=[character(len=5) :: words, 'three']
words=[character(len=8) :: words, 'three']   ! ADD: ok with len=8
write(*,'(5("[",a,"]":))')'GOT HERE',words   ! ADD: keeps going
words=[character(len=9) :: words, 'three']   ! ADD: actually crashes
write(*,'(5("[",a,"]":))')'DID NOT GET HERE',words   ! ADD: 

end program dusty_corner

[Bug middle-end/83228] New: Remove optimistic assumptions about atomic ops in optab.c

[vries at gcc dot gnu.org]

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

Bug ID: 83228
   Summary: Remove optimistic assumptions about atomic ops in
optab.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There are a number of assumptions in optabs.c:
...
diff --git a/gcc/optabs.c b/gcc/optabs.c
index 48e37f8..7f6f9f1 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -6079,6 +6079,7 @@ expand_atomic_test_and_set (rtx target, rtx mem, enum
memmodel model)

   /* Failing all else, assume a single threaded environment and simply
  perform the operation.  */
   if (!ret)
 {
   /* If the result is ignored skip the move to target.  */
@@ -6358,6 +6359,7 @@ expand_atomic_load (rtx target, rtx mem, enum memmodel
model)
 return NULL_RTX;

   /* Otherwise assume loads are atomic, and emit the proper barriers.  */
   if (!target || target == const0_rtx)
 target = gen_reg_rtx (mode);

@@ -6438,6 +6440,7 @@ expand_atomic_store (rtx mem, rtx val, enum memmodel
model, bool use_release)
 }

   /* Otherwise assume stores are atomic, and emit the proper barriers.  */
   expand_mem_thread_fence (model);

   emit_move_insn (mem, val);
...

The assumptions make sense from the point of view of a target that is complete
and working: if say, the atomic load expansion is missing, it's because the
target intends to use the fallback, because regular loads are atomic.

But during a target bringup for a target where loads are not atomic, the
expansion might be missing because it's not done yet, in which case the
fallback silently gives the wrong answer, while it would be more helpful for
the compiler to ICE at that point, indicating that some support is missing.

So, in these cases we want to ICE by default, unless the target tells us to use
the fallback.

[Bug c++/83226] [7 Regression] std::map with reference T breaks in C++17 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|--- |7.3
Summary|[7/8 Regression] std::map   |[7 Regression] std::map
   |with reference T breaks in  |with reference T breaks in
   |C++17 mode  |C++17 mode
  Known to fail||7.2.0

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, the above mentioned change optimizes during cse1:
(insn 8 7 9 2 (set (reg:V2DI 91)
(vec_merge:V2DI (vec_duplicate:V2DI (reg/v:DI 88 [ x ]))
(reg:V2DI 91)
(const_int 1 [0x1]))) "pr83203.c":6 3655 {sse4_1_pinsrq}
 (expr_list:REG_DEAD (reg/v:DI 88 [ x ])
(nil)))
to:
(insn 8 7 9 2 (set (reg:V2DI 91)
(vec_concat:V2DI (reg/v:DI 88 [ x ])
(const_int 0 [0]))) "pr83203.c":6 3738 {vec_concatv2di}
 (expr_list:REG_DEAD (reg/v:DI 88 [ x ])
(nil)))
as pseudo 91 contains all zeros.
Now, because this is generic tuning we force that into stack.
Though I must repeat for the nth time that this is very confusing; either for
some AMD chips (is it really that bad in contemporary ones) vmovd is way too
expensive, but then either vpinsrq is also too expensive (in that case we
should be happy we emit what we do now on the trunk; but then
_pinsr should use Yi instead of x or v in alternatives
with r input; and similarly use Yi in vec_concatv2di in the vpinsrq and pinsrq
alternatives), or vmovd is expensive, but vpinsrq is not, then we just should
use vpinsrq for the vec_concatv2di pattern,
(i.e. add alternative for =x,r,C which will split into clearing the destination
plus vpinsrq).

Another thing is that with -O2 -mavx2 -mtune=intel we emit:
vmovq   %rdi, %xmm0
vmovdqa %xmm0, %xmm0
ret
when we could just emit
vmovq   %rdi, %xmm0
I think.  I guess we'd need a pattern for combine that would match what
combiner's trying:
(set (reg:V4DI 90)
(vec_concat:V4DI (vec_concat:V2DI (reg/v:DI 88 [ x ])
(const_int 0 [0]))
(const_vector:V2DI [
(const_int 0 [0])
(const_int 0 [0])
])))
and perhaps simplify that into something different - vec_select from all zeros
and vec_duplicate, so that we don't need to list all weird cases?
Though perhaps the r254548 change goes here in the wrong direction.

[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)

> Now, because this is generic tuning we force that into stack.
> Though I must repeat for the nth time that this is very confusing; either
> for some AMD chips (is it really that bad in contemporary ones) vmovd is way
> too expensive, but then either vpinsrq is also too expensive (in that case
> we should be happy we emit what we do now on the trunk; but then
> _pinsr should use Yi instead of x or v in
> alternatives with r input; and similarly use Yi in vec_concatv2di in the
> vpinsrq and pinsrq alternatives), or vmovd is expensive, but vpinsrq is not,
> then we just should use vpinsrq for the vec_concatv2di pattern,
> (i.e. add alternative for =x,r,C which will split into clearing the
> destination plus vpinsrq).

AFAICT, pinsr is expensive either with memory or with register operand. Some
time ago, the idea of mine was to implement missing direct SImode and DImode
moves for AMD targets with "pinsr $0, ..." and "pextr $0, ...", but the idea
was scrapped since these insns were worse than moving the value through memory.

> Another thing is that with -O2 -mavx2 -mtune=intel we emit:
>   vmovq   %rdi, %xmm0
>   vmovdqa %xmm0, %xmm0
> ret
> when we could just emit
> vmovq   %rdi, %xmm0
> I think.  I guess we'd need a pattern for combine that would match what
> combiner's trying:
> (set (reg:V4DI 90)
> (vec_concat:V4DI (vec_concat:V2DI (reg/v:DI 88 [ x ])
> (const_int 0 [0]))
> (const_vector:V2DI [
> (const_int 0 [0])
> (const_int 0 [0])
> ])))
> and perhaps simplify that into something different - vec_select from all
> zeros and vec_duplicate, so that we don't need to list all weird cases?
> Though perhaps the r254548 change goes here in the wrong direction.

Maybe we can handle these in the middle end in some generic way, especially
when combination simplifies to a simple move.

[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
Also, please note that in the past, new instructions from ISA n+1 were just
bolted to existing patterns without much thought, under assumption that the new
instructions are always faster than the old ones.

[Bug c++/83217] Compiler segfault: structured binding by reference to a templated type via a pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 42753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42753&action=edit
gcc8-pr83217.patch

Untested fix.

[Bug tree-optimization/83221] [8 Regression] qsort comparator not anti-commutative: -2147483648, -2147483648

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-30
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
The problem is that the testcase contains more than 32768 basic blocks.

One way to fix it is:
2017-11-30  Jakub Jelinek  

PR tree-optimization/83221
* tree-ssa-reassoc.c (sort_by_operand_rank): Shift bb_rank
down by 16.
(init_reassoc): Formatting fix.

--- gcc/tree-ssa-reassoc.c.jj   2017-10-28 09:00:48.0 +0200
+++ gcc/tree-ssa-reassoc.c  2017-11-30 16:07:47.220334364 +0100
@@ -543,7 +543,7 @@ sort_by_operand_rank (const void *pa, co
return -1;
  /* If neither is, compare bb_rank.  */
  if (bb_rank[bbb->index] != bb_rank[bba->index])
-   return bb_rank[bbb->index] - bb_rank[bba->index];
+   return (bb_rank[bbb->index] >> 16) - (bb_rank[bba->index] >> 16);
}

   bool da = reassoc_stmt_dominates_stmt_p (stmta, stmtb);
@@ -6131,7 +6131,7 @@ init_reassoc (void)

   /* Set up rank for each BB  */
   for (i = 0; i < n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS; i++)
-bb_rank[bbs[i]] = ++rank  << 16;
+bb_rank[bbs[i]] = ++rank << 16;

   free (bbs);
   calculate_dominance_info (CDI_POST_DOMINATORS);

Another possibility is to store bb_rank unshifted and shift only when using
bb_rank
except for this sort_by_operand_rank spot.

Perhaps the best fix is to change the types of all the ranks from unsigned int
(used in some spots) and long (in other spots) to uint64_t, on 64-bit hosts it
shouldn't make much difference if we say reorder:
struct operand_entry
{
  unsigned int rank;
  unsigned int id;
  tree op;
  unsigned int count;
  gimple *stmt_to_insert;
};
to
struct operand_entry
{
  unsigned int count;
  unsigned int id;
  tree op;
  uint64_t rank;
  gimple *stmt_to_insert;
};

Guess
static int
compare_repeat_factors (const void *x1, const void *x2)
{
  const repeat_factor *rf1 = (const repeat_factor *) x1;
  const repeat_factor *rf2 = (const repeat_factor *) x2;

  if (rf1->count != rf2->count)
return rf1->count - rf2->count;

  return rf2->rank - rf1->rank;
}
should be changed in any case to do:
  if (rf1->rank != rf2->rank)
return rf2->rank > rf1->rank ? 1 : -1;
  return 0;
and likely also the count case.

Richard, thoughts on this?

[Bug libstdc++/50871] libstdc++ should be built with -Wpedantic and/or -Wsystem-headers

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
Created attachment 42754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42754&action=edit
patch to add -Weh-mismatch to handle this case

Since the main concern seems to be EH mismatch, how about this?

[Bug c/76732] Improve Woverride-init

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #8 from Rainer Orth  ---
Created attachment 42755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42755&action=edit
different testcase

I've been pointed at the attached testcase.

With Oracle Studio cc, I get

ptr_a = hello
ptr_b = (null)
ptr_c = goodbye

while both gcc and clang produce

ptr_a = (null)
ptr_b = (null)
ptr_c = goodbye

It seems Studio cc is wrong according to C11 6.7.9 par. 19.  However clang
warns
by default

union.c:40:3: warning: initializer overrides prior initialization of this
  subobject [-Winitializer-overrides]
.ptr_c = "goodbye"
 ^
union.c:36:21: note: expanded from macro 'ptr_c'
#define ptr_c   ops_u.ops_v2.v2_c
 ~^~
union.c:39:3: note: previous initialization is here
.ptr_a = "hello",
 ^~~
union.c:34:27: note: expanded from macro 'ptr_a'
#define ptr_a   ops_u.ops_v1.v1_a
^
1 warning generated.

even withou any additional options, which gcc 8.0.0 doesn't even with -Wall
-Woverride-init.

Seems gcc should really follow here.

[Bug c++/83227] [7/8 Regression] internal compiler error: in process_init_constructor_array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.3
Summary|[7 Regression] internal |[7/8 Regression] internal
   |compiler error: in  |compiler error: in
   |process_init_constructor_ar |process_init_constructor_ar
   |ray |ray

[Bug ipa/83229] New: [8 Regression] ICE in from_gcov_type, at profile-count.h:676

[rguenth at gcc dot gnu.org]

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

Bug ID: 83229
   Summary: [8 Regression] ICE in from_gcov_type, at
profile-count.h:676
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gamess fails to build with the following (Haswell, thus arch=core-avx2)

/space/rguenther/install/usr/local/bin/gfortran -c -o hss1a.fppized.o-Ofast
-march=native -Wl,-rpath=/space/rguenther/install/usr/local/lib64  
-DSPEC_CPU_LP64  -ffixed-form -std=legacy   hss1a.fppized.f
...
during IPA pass: inline
hss1a.fppized.f:142:0:

   SUBROUTINE HLFSPD(EG,EH,DAB,FD,FDD,BFDD,OUT)

internal compiler error: in from_gcov_type, at profile-count.h:676
0xbdcf3f profile_count::from_gcov_type(long)
/space/rguenther/src/svn/trunk/gcc/profile-count.h:676
0xbdcf3f estimate_bb_frequencies(bool)
/space/rguenther/src/svn/trunk/gcc/predict.c:3623
0xbdd367 rebuild_frequencies()
/space/rguenther/src/svn/trunk/gcc/predict.c:3911
0xbbc954 execute_function_todo
/space/rguenther/src/svn/trunk/gcc/passes.c:1975
0xbbd2e5 execute_todo
/space/rguenther/src/svn/trunk/gcc/passes.c:2048
0xbbf769 execute_one_ipa_transform_pass
/space/rguenther/src/svn/trunk/gcc/passes.c:2245
0xbbf769 execute_all_ipa_transforms()
/space/rguenther/src/svn/trunk/gcc/passes.c:2281
0x86d097 cgraph_node::expand()
/space/rguenther/src/svn/trunk/gcc/cgraphunit.c:2132
0x86e911 expand_all_functions
/space/rguenther/src/svn/trunk/gcc/cgraphunit.c:2275
0x86e911 symbol_table::compile()
/space/rguenther/src/svn/trunk/gcc/cgraphunit.c:2623
0x870c24 symbol_table::finalize_compilation_unit()
/space/rguenther/src/svn/trunk/gcc/cgraphunit.c:2716
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
specmake: *** [hss1a.fppized.o] Error 1
specmake: *** Waiting for unfinished jobs

[Bug ipa/83229] [8 Regression] ICE in from_gcov_type, at profile-count.h:676

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
A general comment from my side here is that RTL really has too many ways to
express vector "combinations" / "shuffles".  In particular vec_merge can
be expressed (up to the CONST_INT bitmask limit to 128 vector elements...)
as (vec_select (vec_concat (...)).  vec_merge has the advantage of not
requiring the intermediate larger vector mode vec_concat requires.

->  vec_perm to the rescue...

but that requires changing all targets & patterns.

The difficulty is that different targets perfer different variants
(vec_merge vs. select/concat), so generic simplifications are very
difficult to "tune".

Eventually combine needs to learn the equivalence between vec_merge
and select/concat and try "both"?

Or we need to declare vec_merge as canonical when the bitmask is large
enough (and fix all targets for that).  Though in my view the
select vector is easier to read in .md than the bitmask as integer...

[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #2 from seurer at gcc dot gnu.org ---
Also on powerpc64 both BE and LE.

[Bug libstdc++/65927] cppcheck: bits/locale_facets_nonio.h (_M_am_pm_format): Assignment of function parameter has no effect outside the function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This is exported, so we can't remove it or change it. Sigh.

[Bug c/79153] -Wimplicit-fallthrough missed warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
This isn't really that easy, because what we end up with in the IL that Marek's
infrastructure looks at is for switches that may fall through (i.e. ones which
have either a break; stmt or missing default) is just a GIMPLE_LABEL created
for the LABEL_EXPR added already in the FEs, or the:
  if (!default_case)
{
  glabel *new_default;

  default_case
= build_case_label (NULL_TREE, NULL_TREE,
create_artificial_label (UNKNOWN_LOCATION));
  new_default = gimple_build_label (CASE_LABEL (default_case));
  gimplify_seq_add_stmt (&switch_body_seq, new_default);
}
added GIMPLE_LABEL, then lots of stmts in between and finally some
GIMPLE_SWITCH.

So, I think the gimplify.c fallthrough code needs to be told what GIMPLE_LABEL
stmts are the break labels or default case labels and for diagnostics it would
be nice if it could be possible to query the locus of the corresponding switch
stmt and then treat a GIMPLE_LABEL with that special flag just as a statement
that can fall through with the location of the corresponding GIMPLE_SWITCH.

Finding an available bit on LABEL_DECL should be easy, e.g. protected_flag
doesn't seem to be occupied.  As for location, not really sure what code cares
about gimple_location of GIMPLE_LABEL / EXPR_LOCATION of LABEL_EXPR and what
code cares about DECL_LOCATION of a LABEL_DECL and if we could reuse one or the
other to hold the location of the switch, without e.g. the debugger jumping on
back to the switch when we do a break.

[Bug tree-optimization/69811] [6/7/8 Regression] GCC does not simplify 0 == "a"+1 at -O0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
This was actually fixed in gcc-7.

[Bug target/80700] [7/8 Regression] ICE: Bus error (on SPE target)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug c++/82219] [8 Regression] Not wanted warning: "type qualifiers ignored on cast result type" on template instantiation

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/82720] [PDT] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2400

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
I have a fix for this that is combined with that for PR82719. I will post it on
that PR.

Paul

[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug fortran/82719] [PDT] ICE in transfer_expr, at fortran/trans-io.c:2393

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
Created attachment 42756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42756&action=edit
Patch for PRs 82605/606/622/719/720

I am a bit to busy to separate all the different fixes and so here is a
composite:

2017-11-30  Paul Thomas  

PR fortran/82605
* resolve.c (get_pdt_constructor): Initialize 'cons' to NULL.
(resolve_pdt): Correct typo in prior comment. Emit an error if
any parameters are deferred and the object is neither pointer
nor allocatable.

PR fortran/82606
* decl.c (gfc_get_pdt_instance): Continue if the parameter sym
is not present or has no name. Select the parameter by name
of component, rather than component order. Remove all the other
manipulations of 'tail' when building the pdt instance.
(gfc_match_formal_arglist): Emit and error if a star is picked
up in a PDT decl parameter list.

PR fortran/82622
* trans-array.c (set_loop_bounds): If a GFC_SS_COMPONENT has an
info->end, use it rather than falling through to
gcc_unreachable.
(structure_alloc_comps): Check that param->name is non-null
before comparing with the component name.
* trans-decl.c (gfc_get_symbol_decl): Do not use the static
initializer for PDT symbols.
(gfc_init_default_dt): Do nothing for PDT symbols.
* trans-io.c (transfer_array_component): Parameterized array
components use the descriptor ubound since the shape is not
available.

PR fortran/82719
PR fortran/82720
* trans-expr.c (gfc_conv_component_ref): Do not use the charlen
backend_decl of pdt strings. Use the hidden component instead.
* trans-io.c (transfer_expr): Do not do IO on "hidden" string
lengths. Use the hidden string length for pdt string transfers
by adding it to the se structure. When finished nullify the
se string length.

2017-11-30  Paul Thomas  

PR fortran/82605
* gfortran.dg/pdt_4.f03 : Incorporate the new error.

PR fortran/82606
* gfortran.dg/pdt_19.f03 : New test.
* gfortran.dg/pdt_21.f03 : New test.

PR fortran/82622
* gfortran.dg/pdt_20.f03 : New test.
* gfortran.dg/pdt_22.f03 : New test.

PR fortran/82719
PR fortran/82720
* gfortran.dg/pdt_23.f03 : New test.

Paul

[Bug libstdc++/65927] cppcheck: bits/locale_facets_nonio.h (_M_am_pm_format): Assignment of function parameter has no effect outside the function

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu Nov 30 17:29:08 2017
New Revision: 255278

URL: https://gcc.gnu.org/viewcvs?rev=255278&root=gcc&view=rev
Log:
PR libstdc++/65927 Fix -Wunused-but-set-parameter warning

PR libstdc++/65927
* include/bits/locale_facets_nonio.h (__timepunct::_M_am_pm_format):
Remove statement with no effect.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/locale_facets_nonio.h

[Bug libstdc++/65927] cppcheck: bits/locale_facets_nonio.h (_M_am_pm_format): Assignment of function parameter has no effect outside the function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for gcc-8

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #9 from seurer at gcc dot gnu.org ---
Also on powerpc64 both BE and LE

[Bug fortran/83230] New: [8.0 regression] segmentation fault in bind C C/C++

[juergen.reuter at desy dot de]

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

Bug ID: 83230
   Summary: [8.0 regression] segmentation fault in bind C C/C++
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

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

The following code seg faults in the most recent versions for gcc/g++/gfortran,
cf. below. I'm using the gcc trunk 255190 with the patch in 
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-7-branch/gcc/fortran/resolve.c?r1=255029&r2=255205&pathrev=255205
applied. The C++ code which I adapted here and linked into my Fortran program
works standalone with that version of gcc/g++, but the bind(C) fails. I'm not
sure whether this an error (or simply a change in the C/C++ API) or whether
something in bind(C) broke. The C++ code contains an implementation for an XDR
reader, which is applied from a Fortran program via bind(C) to read in the file
eio_stdhep_1.hep which is also attached. If this is in bind(C) it could be
related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83225
at least it happened relatively close to the commit causing that bug. 

$ ./rt_error 
 writing stdhep event ...

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7fcfa0029caf in ???
#1  0x7fcfa007613c in ???
#2  0x7fcfa1071c05 in _ZN9__gnu_cxx13new_allocatorIcE10deallocateEPcm
at
/home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:125
#3  0x7fcfa1071c05 in _ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm
at
/home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:462
#4  0x7fcfa1071c05 in
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_destroyEm
at
/home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:226
#5  0x7fcfa1071c05 in
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv
at
/home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:221
#6  0x7fcfa1071c05 in _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED4Ev
at
/home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:647
#7  0x7fcfa1071c05 in
_ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED4Ev
at
/home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:65
#8  0x7fcfa1071c05 in
_ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEED1Ev
at
/home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:732
#9  0x407b56 in ???
#10  0x406c1d in ???
#11  0x408485 in ???
#12  0x408519 in ???
#13  0x4085f8 in ???
#14  0x40862e in ???
#15  0x7fcfa0014f44 in ???
#16  0x401918 in ???
#17  0x in ???
Segmentation fault (core dumped)

[Bug c++/82219] [8 Regression] Not wanted warning: "type qualifiers ignored on cast result type" on template instantiation

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Nov 30 17:43:08 2017
New Revision: 255279

URL: https://gcc.gnu.org/viewcvs?rev=255279&root=gcc&view=rev
Log:
PR c++/82219 - bogus -Wignored-qualifiers with template

* pt.c (tsubst_copy_and_build) [STATIC_CAST_EXPR]: Suppress
-Wignored-qualifiers.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wignored-qualifiers1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #15 from Markus Trippelsdorf  ---
*** Bug 83229 has been marked as a duplicate of this bug. ***

[Bug ipa/83229] [8 Regression] ICE in from_gcov_type, at profile-count.h:676

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/82219] [8 Regression] Not wanted warning: "type qualifiers ignored on cast result type" on template instantiation

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/83231] New: ICE on constexpr evaluation

[antoshkka at gmail dot com]

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

Bug ID: 83231
   Summary: ICE on constexpr evaluation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following valid example 


struct GUID {
unsigned long  Data1;
unsigned char  Data2[ 4 ];
};

constexpr bool is_equal(GUID lhs, GUID rhs) {
return lhs.Data1 == rhs.Data1
&& lhs.Data2[0] == rhs.Data2[0] && lhs.Data2[1] == rhs.Data2[1];
}

void guid_tests() {
constexpr GUID some_guid =
{ 0x3bcac5a9, { 0xb5, 0xc5, 0xb1, 0x9b } };
constexpr bool val = is_equal(some_guid, some_guid);
}


fails to cimpile and produces error message:


: In function 'void guid_tests()':
14 : :14:34:   in 'constexpr' expansion of 'is_equal(some_guid,
some_guid)'
14 : :14:55: internal compiler error: in cxx_eval_bit_field_ref, at
cp/constexpr.c:2608
 constexpr bool val = is_equal(some_guid, some_guid);
   ^
mmap: Cannot allocate memory
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler exited with result code 1


Build flags: --std=c++14 -O2

[Bug libstdc++/50871] libstdc++ should be built with -Wpedantic and/or -Wsystem-headers

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
It's better than what we have today, but I'm not sure it's where we want to get
to in the long term.

I've been trying a patch  that allows the system_header pragma to be disabled
when building and testing. This causes testsuite failures due to warnings that
can't be controlled by options or diagnostic pragmas:

/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/std_abs.h:40:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:77:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/fenv.h:38:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:47:
error: #include_next is a GCC extension
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/complex:1951:
warning: floating point suffix 'if' shadowed by implementation
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/complex:1959:
warning: floating point suffix 'i' shadowed by implementation
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/complex:1963:
warning: integer suffix 'i' shadowed by implementation
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/complex:1967:
warning: floating point suffix 'il' shadowed by implementation
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/complex:1971:
warning: integer suffix 'il' shadowed by implementation

[Bug tree-optimization/83232] New: fma3d spec2000 regression on zen with -Ofast (generic tuning) after r255268 by missed SLP oppurtunity

[hubicka at gcc dot gnu.org]

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

Bug ID: 83232
   Summary: fma3d spec2000 regression on zen with -Ofast (generic
tuning) after r255268 by missed SLP oppurtunity
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

r255268 introduced regression on fma3d. This difference pays back in specfp2000
in general but should be tracked (and hopefully fixed).

Compiling with -fdisable-tree-cunroll makes the problem go away. Problem is
that slp vectorizer is confused by presence of unrolled vectorized loop body
and gives up on vectorizing initialization sequence which leads to memory
mismatch stall.

Problem is in material_11.f90 where the loop of material_41_integration is
vectorized in both cases. New code omits vectorization for alignment but it
also introduces partial stores followed by full sized load:

  _13 = *stress_203(D)[0];
  sinc[0] = _13;
  _336 = *stress_203(D)[1];
  sinc[1] = _336;
  _343 = *stress_203(D)[2];
  sinc[2] = _343;
  _350 = *stress_203(D)[3];
  sinc[3] = _350;
  _22 = *dtnext_206(D);
  _23 = *dxx_207(D);
  _24 = _22 * _23;
  einc[0] = _24;
  _25 = *dyy_209(D);
  _26 = _22 * _25;
  einc[1] = _26;
  _27 = *dzz_211(D);
  _28 = _22 * _27;
  einc[2] = _28;
  _29 = *dxy_213(D);
  _30 = _22 * _29;
  einc[3] = _30;
  _31 = *dxz_215(D);
  _32 = _22 * _31;
  einc[4] = _32;
  _33 = *dyz_217(D);
  _34 = _22 * _33;
  einc[5] = _34;
  vect_cst__471 = {p3_194, p3_194};
  vect__37.58_227 = MEM[(real(kind=8) *)stress_203(D)];
  vect__38.61_323 = MEM[(real(kind=8) *)&einc];
  vect__39.62_444 = vect__38.61_323 * vect_cst__471;
  vect__40.63_443 = vect__37.58_227 + vect__39.62_444;
  MEM[(real(kind=8) *)stress_203(D)] = vect__40.63_443;
  vect__37.58_432 = MEM[(real(kind=8) *)stress_203(D) + 16B];
  vect__38.61_431 = MEM[(real(kind=8) *)&einc + 16B];
  vect__39.62_430 = vect__38.61_431 * vect_cst__471;
  vect__40.63_429 = vect__39.62_430 + vect__37.58_432;
  MEM[(real(kind=8) *)stress_203(D) + 16B] = vect__40.63_429;
  vect__37.58_475 = MEM[(real(kind=8) *)stress_203(D) + 32B];
  vect__38.61_472 = MEM[(real(kind=8) *)&einc + 32B];
  vect__39.62_463 = vect_cst__471 * vect__38.61_472;
  vect__40.63_462 = vect__39.62_463 + vect__37.58_475;
  MEM[(real(kind=8) *)stress_203(D) + 32B] = vect__40.63_462;
  _41 = *stress_203(D)[0];
  _342 = _25 + _27;
  _44 = _23 + _342;
  _8 = _22 * _44;
  _45 = _6 * _8;
  _46 = _41 + _45;
  *stress_203(D)[0] = _46;
  _47 = *stress_203(D)[1];
  _48 = _45 + _47;
  *stress_203(D)[1] = _48;
  *stress_203(D)[2] = 0.0;
  einc[4] = 0.0;
  einc[5] = 0.0;
  if (ak_202 == 0.0)
goto ; [50.00%]
  else
goto ; [50.00%]


while old code did:

  vect__13.78_205 = MEM[(real(kind=8) *)stress_203(D)];
  vect__13.79_445 = MEM[(real(kind=8) *)stress_203(D) + 16B];
  MEM[(real(kind=8) *)&sinc] = vect__13.78_205;
  MEM[(real(kind=8) *)&sinc + 16B] = vect__13.79_445;
  _22 = *dtnext_206(D);
  _23 = *dxx_207(D);
  _24 = _22 * _23;
  _25 = *dyy_209(D);
  _26 = _22 * _25;
  _27 = *dzz_211(D);
  _28 = _22 * _27;
  _29 = *dxy_213(D);
  _30 = _22 * _29;
  _31 = *dxz_215(D);
  _32 = _22 * _31;
  _33 = *dyz_217(D);
  _34 = _22 * _33;
  vect_cst__479 = {_32, _34};
  vect_cst__482 = {_28, _30};
  vect_cst__486 = {_24, _26};
  MEM[(real(kind=8) *)&einc] = vect_cst__486;
  MEM[(real(kind=8) *)&einc + 16B] = vect_cst__482;
  MEM[(real(kind=8) *)&einc + 32B] = vect_cst__479;
  _441 = (unsigned long) stress_203(D);
  _440 = _441 >> 3;
  _439 = -_440;
  _438 = (unsigned int) _439;
  prolog_loop_niters.57_442 = _438 & 1;
  if (prolog_loop_niters.57_442 == 0)
goto ; [33.33%]
  else
goto ; [66.67%]

;;succ:   3 [66.7% (guessed)]  count:102291806 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
;;4 [33.3% (guessed)]  count:51145904 (estimated locally)
(TRUE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, count 102291806 (estimated locally), maybe
hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [66.7% (guessed)]  count:102291806 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  _471 = MEM[(real(kind=8)[6] *)stress_203(D)];
  _463 = einc[0];
  _462 = p3_194 * _463;
  _461 = _462 + _471;
  MEM[(real(kind=8)[6] *)stress_203(D)] = _461;
;;succ:   4 [always]  count:102291806 (estimated locally)
(FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 153437710 (estimated locally), maybe
hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [always]  count:102291806 (estimated locally)
(FALLTHRU,EXECUTABLE)
;;2 [33.3% (guessed)]  count:51145904 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  # i_435 = PHI <2(3), 1(2)>
  prolog_loop_adjusted_niters.58_432 = (sizetype) prolog_loop_niters.57_442;
  n

[Bug fortran/83224] creating character array from elements shorter than declared does not pad with whitespace properly and aborts

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
Looks like the dependency checking in frontend-passes.c isn‘t doing its job. I
will take a look.

[Bug c/79153] -Wimplicit-fallthrough missed warning

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 42758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42758&action=edit
gcc8-pr79153.patch

Untested fix.

[Bug libstdc++/50871] libstdc++ should be built with -Wpedantic and/or -Wsystem-headers

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #14)
> It's better than what we have today, but I'm not sure it's where we want to
> get to in the long term.
> 
> I've been trying a patch  that allows the system_header pragma to be
> disabled when building and testing.

How about using 

#pragma GCC diagnostic warning "-Wsystem-headers"

instead?

> This causes testsuite failures due to
> warnings that can't be controlled by options or diagnostic pragmas:
> 
> /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:
> 47: error: #include_next is a GCC extension

Maybe leave off -Wpedantic for now.

> /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/
> complex:1951: warning: floating point suffix 'if' shadowed by implementation

This seems like a real issue.  Perhaps for C++14 and up we should disable the
built-in complex suffixes.

[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation

[wilson at gcc dot gnu.org]

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

--- Comment #8 from Jim Wilson  ---
Author: wilson
Date: Thu Nov 30 18:38:26 2017
New Revision: 255281

URL: https://gcc.gnu.org/viewcvs?rev=255281&root=gcc&view=rev
Log:
Riscv doc fixes and improvements.

gcc/
Backport from mainline
2017-11-30  Jim Wilson  
* doc/invoke.texi (RISC-V Options): Delete nonexistent -mmemcpy and
-mno-memcpy options.  For -mplt, -mfdiv, -mdiv, -msave-restore, and
-mstrict-align, add info on default value.  Delete redundant lines for
-mabi.  Add missing -mexplicit-relocs docs.

Backport from mainline
2017-11-01  Palmer Dabbelt  
* doc/invoke.texi (RISC-V Options): Use "@minus{}2 GB", not "-2 GB".
* doc/invoke.texi (RISC-V Options): Explicitly name the medlow
and medany code models, and describe what they do.

2017-10-27  Palmer Dabbelt  
PR target/82717
* doc/invoke.texi (RISC-V) <-mabi>: Correct and improve.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/invoke.texi

[Bug fortran/82842] (PDT) Constructors do not work

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
There are a lot more issues with this PR than I am prepared to deal with right
now. However, I will take it and will return to it at a later date.

For the record, the backtrace at the error is:

#0  gfc_match_name (buffer=buffer@entry=0x7fffcdc0 "\240\244#\002")
at ../../trunk/gcc/fortran/match.c:659
#1  0x008a88a7 in match_actual_arg (result=result@entry=0x223a4b8)
at ../../trunk/gcc/fortran/primary.c:1522
#2  0x008a8b6b in match_keyword_arg (actual=actual@entry=0x223a4a0,
base=base@entry=0x223a4a0, 
pdt=pdt@entry=false) at ../../trunk/gcc/fortran/primary.c:1649
#3  0x008a9faa in gfc_match_actual_arglist (sub_flag=sub_flag@entry=0, 
argp=argp@entry=0x7fffcf58, pdt=pdt@entry=false) at
../../trunk/gcc/fortran/primary.c:1863
#4  0x008ac49e in gfc_match_rvalue (result=result@entry=0x7fffd040)
at ../../trunk/gcc/fortran/primary.c:3325
...snip...

Paul

[Bug fortran/82865] Option -fdec collides with PDT

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
I agree with the general sentiment that this should probably be a WONT FIX.
However, it is concerning that there is an interaction.

I will put this on on side as one of the longer term TODOs.

Paul

[Bug tree-optimization/83233] New: [8 Regression] gimple-ssa-store-merging.c:183:3: warning: unnamed type with no linkage used to declare variable with linkage

[trippels at gcc dot gnu.org]

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

Bug ID: 83233
   Summary: [8 Regression] gimple-ssa-store-merging.c:183:3:
warning: unnamed type with no linkage used to declare
variable with linkage
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

In stage 1 with -std=gnu++98:

../../gcc/gcc/gimple-ssa-store-merging.c:183:3: warning: unnamed type with no
linkage used to declare variable ‘{anonymous}::
{anonymous}::nop_stats’ with linkage
 } nop_stats, bswap_stats;
   ^
../../gcc/gcc/gimple-ssa-store-merging.c:183:14: warning: unnamed type with no
linkage used to declare variable ‘{anonymous}::
{anonymous}::bswap_stats’ with linka
ge
 } nop_stats, bswap_stats;
  ^~~
Could be fixed by using idiomatic C++, instead of

namespace {
struct
{
...
} nop_stats, bswap_stats;
}

something like:

namespace {
struct Stats
{
...
};
Stats nop_stats, bswap_stats;
}

[Bug fortran/83224] creating character array from elements shorter than declared does not pad with whitespace properly and aborts

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #4 from Thomas Koenig  ---
This looks like this could work.

No time for a patch submission now, that will have to wait for
a few days.

--- frontend-passes.c   (Revision 255181)
+++ frontend-passes.c   (Arbeitskopie)
@@ -249,7 +249,7 @@ realloc_string_callback (gfc_code **c, int *walk_s
 return 0;

   expr1 = co->expr1;
-  if (expr1->ts.type != BT_CHARACTER || expr1->rank != 0
+  if (expr1->ts.type != BT_CHARACTER
   || !gfc_expr_attr(expr1).allocatable
   || !expr1->ts.deferred)
 return 0;
@@ -270,8 +270,9 @@ realloc_string_callback (gfc_code **c, int *walk_s
   if (!found_substr)
return 0;
 }
-  else if (expr2->expr_type != EXPR_OP
-  || expr2->value.op.op != INTRINSIC_CONCAT)
+  else if (expr2->expr_type != EXPR_ARRAY
+  && (expr2->expr_type != EXPR_OP
+  || expr2->value.op.op != INTRINSIC_CONCAT))
 return 0;

[Bug c++/83227] [7/8 Regression] internal compiler error: in process_init_constructor_array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-30
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r240889.

[Bug tree-optimization/83189] [8 regression] internal compiler error: in probability_in, at profile-count.h:1050

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
I am also seeing this during a bootstrap build.

../../src/trunk/gcc/vec.h: In member function ‘vec* vec::copy() const [with T = ipa_agg_jf_item; A = va_gc]’:
../../src/trunk/gcc/vec.h:910:1: internal compiler error: in probability_in, at
profile-count.h:1050
 vec::copy (ALONE_MEM_STAT_DECL) const
 ^~~
0xc0b456 profile_count::probability_in(profile_count) const
../../src/trunk/gcc/profile-count.h:1050
0x13b6e8d tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)

[Bug libstdc++/50871] libstdc++ should be built with -Wpedantic and/or -Wsystem-headers

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > It's better than what we have today, but I'm not sure it's where we want to
> > get to in the long term.
> > 
> > I've been trying a patch  that allows the system_header pragma to be
> > disabled when building and testing.
> 
> How about using 
> 
> #pragma GCC diagnostic warning "-Wsystem-headers"
> 
> instead?

That doesn't work well, see PR 80472

> > This causes testsuite failures due to
> > warnings that can't be controlled by options or diagnostic pragmas:
> > 
> > /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cmath:
> > 47: error: #include_next is a GCC extension
> 
> Maybe leave off -Wpedantic for now.

Yep. It would be nice if we had __include_next, or could add __extension__ to
avoid those warnings.

> > /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/
> > complex:1951: warning: floating point suffix 'if' shadowed by implementation
> 
> This seems like a real issue.  Perhaps for C++14 and up we should disable
> the built-in complex suffixes.

See PR 79228

[Bug libstdc++/50871] libstdc++ should be built with -Wpedantic and/or -Wsystem-headers

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #16)
> (In reply to Jason Merrill from comment #15)
> > (In reply to Jonathan Wakely from comment #14)
> > > It's better than what we have today, but I'm not sure it's where we want 
> > > to
> > > get to in the long term.
> > > 
> > > I've been trying a patch  that allows the system_header pragma to be
> > > disabled when building and testing.
> > 
> > How about using 
> > 
> > #pragma GCC diagnostic warning "-Wsystem-headers"
> > 
> > instead?
> 
> That doesn't work well, see PR 80472

Oh, did you mean putting that in the libstdc++-v3/src/*/*.cc sources, and
tests, rather than in the headers?

That could work as long as it doesn't also enable warnings for C library
headers, which we generally can't fix or avoid.

[Bug libgcc/83103] Improve __mulkc3 and __divkc3 on Power9

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Thu Nov 30 20:52:27 2017
New Revision: 255282

URL: https://gcc.gnu.org/viewcvs?rev=255282&root=gcc&view=rev
Log:
2017-11-30  Michael Meissner  

PR libgcc/83112
* config/rs6000/float128-ifunc.c (__addkf3_resolve): Use the
correct type for all ifunc resolvers to silence -Wattribute-alias
warnings.  Eliminate the forward declaration of the resolver
functions which is no longer needed.
(__subkf3_resolve): Likewise.
(__mulkf3_resolve): Likewise.
(__divkf3_resolve): Likewise.
(__negkf2_resolve): Likewise.
(__eqkf2_resolve): Likewise.
(__nekf2_resolve): Likewise.
(__gekf2_resolve): Likewise.
(__gtkf2_resolve): Likewise.
(__lekf2_resolve): Likewise.
(__ltkf2_resolve): Likewise.
(__unordkf2_resolve): Likewise.
(__extendsfkf2_resolve): Likewise.
(__extenddfkf2_resolve): Likewise.
(__trunckfsf2_resolve): Likewise.
(__trunckfdf2_resolve): Likewise.
(__fixkfsi_resolve): Likewise.
(__fixkfdi_resolve): Likewise.
(__fixunskfsi_resolve): Likewise.
(__fixunskfdi_resolve): Likewise.
(__floatsikf_resolve): Likewise.
(__floatdikf_resolve): Likewise.
(__floatunsikf_resolve): Likewise.
(__floatundikf_resolve): Likewise.
(__extendkftf2_resolve): Likewise.
(__trunctfkf2_resolve): Likewise.

PR libgcc/83103
* config/rs6000/quad-float128.h (TF): Don't define if long double
is IEEE 128-bit floating point.
(TCtype): Define as either TCmode or KCmode, depending on whether
long double is IEEE 128-bit floating point.
(__mulkc3_sw): Add declarations for software/hardware versions of
complex multiply/divide.
(__divkc3_sw): Likewise.
(__mulkc3_hw): Likewise.
(__divkc3_hw): Likewise.
* config/rs6000/_mulkc3.c (_mulkc3): If we are building ifunc
handlers to switch between using software emulation and hardware
float128 instructions, build the complex multiply/divide functions
for both software and hardware support.
* config/rs6000/_divkc3.c (_divkc3): Likewise.
* config/rs6000/float128-ifunc.c (__mulkc3_resolve): Likewise.
(__divkc3_resolve): Likewise.
(__mulkc3): Likewise.
(__divkc3): Likewise.
* config/rs6000/t-float128-hw (fp128_hardfp_src): Likewise.
(fp128_hw_src): Likewise.
(fp128_hw_static_obj): Likewise.
(fp128_hw_shared_obj): Likewise.
(_mulkc3-hw.c): Create _mulkc3-hw.c and _divkc3-hw.c from
_mulkc3.c and _divkc3.c, changing the function name.
(_divkc3-hw.c): Likewise.
* config/rs6000/t-float128 (clean-float128): Delete _mulkc3-hw.c
and _divkc3-hw.c.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/rs6000/_divkc3.c
trunk/libgcc/config/rs6000/_mulkc3.c
trunk/libgcc/config/rs6000/float128-ifunc.c
trunk/libgcc/config/rs6000/quad-float128.h
trunk/libgcc/config/rs6000/t-float128
trunk/libgcc/config/rs6000/t-float128-hw

[Bug libgcc/83112] Silence warnings from PowerPC libgcc float128-ifunc.c compilation

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Thu Nov 30 20:52:27 2017
New Revision: 255282

URL: https://gcc.gnu.org/viewcvs?rev=255282&root=gcc&view=rev
Log:
2017-11-30  Michael Meissner  

PR libgcc/83112
* config/rs6000/float128-ifunc.c (__addkf3_resolve): Use the
correct type for all ifunc resolvers to silence -Wattribute-alias
warnings.  Eliminate the forward declaration of the resolver
functions which is no longer needed.
(__subkf3_resolve): Likewise.
(__mulkf3_resolve): Likewise.
(__divkf3_resolve): Likewise.
(__negkf2_resolve): Likewise.
(__eqkf2_resolve): Likewise.
(__nekf2_resolve): Likewise.
(__gekf2_resolve): Likewise.
(__gtkf2_resolve): Likewise.
(__lekf2_resolve): Likewise.
(__ltkf2_resolve): Likewise.
(__unordkf2_resolve): Likewise.
(__extendsfkf2_resolve): Likewise.
(__extenddfkf2_resolve): Likewise.
(__trunckfsf2_resolve): Likewise.
(__trunckfdf2_resolve): Likewise.
(__fixkfsi_resolve): Likewise.
(__fixkfdi_resolve): Likewise.
(__fixunskfsi_resolve): Likewise.
(__fixunskfdi_resolve): Likewise.
(__floatsikf_resolve): Likewise.
(__floatdikf_resolve): Likewise.
(__floatunsikf_resolve): Likewise.
(__floatundikf_resolve): Likewise.
(__extendkftf2_resolve): Likewise.
(__trunctfkf2_resolve): Likewise.

PR libgcc/83103
* config/rs6000/quad-float128.h (TF): Don't define if long double
is IEEE 128-bit floating point.
(TCtype): Define as either TCmode or KCmode, depending on whether
long double is IEEE 128-bit floating point.
(__mulkc3_sw): Add declarations for software/hardware versions of
complex multiply/divide.
(__divkc3_sw): Likewise.
(__mulkc3_hw): Likewise.
(__divkc3_hw): Likewise.
* config/rs6000/_mulkc3.c (_mulkc3): If we are building ifunc
handlers to switch between using software emulation and hardware
float128 instructions, build the complex multiply/divide functions
for both software and hardware support.
* config/rs6000/_divkc3.c (_divkc3): Likewise.
* config/rs6000/float128-ifunc.c (__mulkc3_resolve): Likewise.
(__divkc3_resolve): Likewise.
(__mulkc3): Likewise.
(__divkc3): Likewise.
* config/rs6000/t-float128-hw (fp128_hardfp_src): Likewise.
(fp128_hw_src): Likewise.
(fp128_hw_static_obj): Likewise.
(fp128_hw_shared_obj): Likewise.
(_mulkc3-hw.c): Create _mulkc3-hw.c and _divkc3-hw.c from
_mulkc3.c and _divkc3.c, changing the function name.
(_divkc3-hw.c): Likewise.
* config/rs6000/t-float128 (clean-float128): Delete _mulkc3-hw.c
and _divkc3-hw.c.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/rs6000/_divkc3.c
trunk/libgcc/config/rs6000/_mulkc3.c
trunk/libgcc/config/rs6000/float128-ifunc.c
trunk/libgcc/config/rs6000/quad-float128.h
trunk/libgcc/config/rs6000/t-float128
trunk/libgcc/config/rs6000/t-float128-hw

[Bug libgcc/83112] Silence warnings from PowerPC libgcc float128-ifunc.c compilation

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  ---
Fixed in subversion id 255282.

[Bug libgcc/83103] Improve __mulkc3 and __divkc3 on Power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
Fixed in subversion id 255282.

[Bug c++/79228] 'i' suffix for __complex__ extension interferes with C++14 UDLs for std::complex

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/83234] New: Aggressive loop optim warning for loop iteration that cannot happen

[ketan.surender at gmail dot com]

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

Bug ID: 83234
   Summary: Aggressive loop optim warning for loop iteration that
cannot happen
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ketan.surender at gmail dot com
  Target Milestone: ---

Created attachment 42759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42759&action=edit
Reproduction File

I have an example program with the code:

  for (j = 0; j < 3; j++) {
for (i = 1; i <= 3 - j; i++) {
  out8[i - 1][j] = (int8_T)(i + j);
}

for (i = 4 - j; i < 4; i++) {
  out8[i - 1][j] = in15[(i + j) - 3];
}
  }

that produces the warning

hankel_script.c: In function ‘hankel_script’:
hankel_script.c:235:32: warning: iteration 2147483644 invokes undefined
behavior [-Waggressive-loop-optimizations]
   out8[i - 1][j] = in15[(i + j) - 3];
 ~~~^~~~
hankel_script.c:234:5: note: within this loop
 for (i = 4 - j; i < 4; i++) {

The loop bounds have been defined with constants such that iteration 2147483644
cannot happen.

Repro:
gcc -c -O2 hankel_script.i

I do not see the warning with -O3 or -O1.

My gcc version is 6.3. See details below. I am able to reproduce this using
x86-64 gcc 7.2 on https://gcc.godbolt.org/.

COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: [SCRUB]/sources/gcc-6.3/configure
--with-gmp=[SCRUB]/gcc-6.3/gmp-4.3 --with-mpfr=[SCRUB]/gcc-6.3/mpfr
--with-mpc=[SCRUB]/gcc-6.3/mpc --enable-languages=c,c++,fortran
--with-bugurl=[SCRUB],_Debugging --enable-shared --enable-linker-build-id
--enable-plugin --enable-checking=release --enable-multiarch --enable-gold
--enable-ld=default --prefix=[SCRUB]/gcc-6.3.0 --with-pkgversion='MW GCC
6.3.0-GLIBC2.11' --with-tune=generic --with-system-zlib --enable-multilib
--with-multilib-list=m32,m64 --with-arch-directory=amd64 --with-arch-32=i586
--with-abi=m64
gcc version 6.3.0 (MW GCC 6.3.0-GLIBC2.11)

[Bug middle-end/83234] Aggressive loop optim warning for loop iteration that cannot happen

[ketan.surender at gmail dot com]

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

--- Comment #1 from Ketan  ---
I am on Debian 8

[Bug sanitizer/81697] Incorrect ASan global variables alignment on arm

[chefmax at gcc dot gnu.org]

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

--- Comment #4 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Nov 30 21:38:16 2017
New Revision: 255283

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

2017-11-30  Maxim Ostapenko  

PR sanitizer/81697
* asan.c (asan_protect_global): Add new ignore_decl_rtl_set_p
parameter. Return true if ignore_decl_rtl_set_p is true and other
conditions are satisfied.
* asan.h (asan_protect_global): Add new parameter.
* varasm.c (categorize_decl_for_section): Pass true as second parameter
to asan_protect_global calls.

gcc/testsuite/

2017-11-30  Maxim Ostapenko  

PR sanitizer/81697
* c-c++-common/asan/pr81697.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/pr81697.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/asan.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug fortran/83235] New: IAND sometimes doesn't take bitwise-and of sign bit with -O2

[paul.k.romano at gmail dot com]

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

Bug ID: 83235
   Summary: IAND sometimes doesn't take bitwise-and of sign bit
with -O2
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.k.romano at gmail dot com
  Target Milestone: ---

Created attachment 42760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42760&action=edit
Minimal example of IAND bug

I ran into what appears to be a strange bug where the IAND intrinsic function
sometimes doesn't take the bitwise-and of the sign bit for 64-bit integers.
I've attached a MWE that demonstrates the bug, which can be reproduced by
compiling with -O2 or higher. The example writes the bit representation of two
64-bit integers and the result of taking IAND() on them and you can see that
the result of IAND doesn't handle the sign bit correctly. Several slight
changes seem to suppress the bug, e.g. having the second argument to IAND not
be and integer parameter and putting the body of foo in the main program.

I produced this bug using the default gcc from APT in Ubuntu 17.10, as follows:

Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-8ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3)