[Bug fortran/66227] [5/6/7 Regression] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.5.0
   Target Milestone|--- |5.5
  Known to fail||5.4.1, 6.2.0

--- Comment #8 from janus at gcc dot gnu.org ---
Fixed on trunk with r242535. For more discussion of the fix see the thread
starting at https://gcc.gnu.org/ml/fortran/2016-11/msg00150.html.

I'll backport the fix to the release branches soon if no problems appear on
trunk.

[Bug tree-optimization/78305] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 17 08:39:33 2016
New Revision: 242536

URL: https://gcc.gnu.org/viewcvs?rev=242536&root=gcc&view=rev
Log:
2016-11-17  Richard Biener  

PR middle-end/78305
* fold-const.c (negate_expr_p): Fix multiplication case.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr78305.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/78305] [6 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.4.0, 7.0
   Target Milestone|--- |6.3
Summary|Wrong constant folding  |[6 Regression] Wrong
   ||constant folding
  Known to fail||6.2.0

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.  Works with GCC 5 (though definitely latent there).

[Bug middle-end/78306] [CilkPlus] "inlining failed in call to always_inline ‘memset’: function not inlinable" with -fcilkplus

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 17 08:42:50 2016
New Revision: 242537

URL: https://gcc.gnu.org/viewcvs?rev=242537&root=gcc&view=rev
Log:
2016-11-17  Richard Biener  

PR tree-optimization/78306
* ipa-inline-analysis.c (initialize_inline_failed): Do not
inhibit inlining if function calls cilk_spawn.
(can_inline_edge_p): Likewise.

* gcc.dg/cilk-plus/pr78306.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/cilk-plus/pr78306.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78306] [CilkPlus] "inlining failed in call to always_inline ‘memset’: function not inlinable" with -fcilkplus

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED
  Known to fail||6.2.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build, wrong-code
  Component|other   |bootstrap
   Target Milestone|--- |7.0
Summary|Bootstrap failure:  |[7 Regression] Bootstrap
   |match.pd: cannot determine  |failure: match.pd: cannot
   |type of operand |determine type of operand

--- Comment #1 from Richard Biener  ---
Looks like a stage2 miscompilation to me (you didn't say which stage you get
the error in).

[Bug tree-optimization/78386] Optimization -O2 and higher cause math inconsistency

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Should be the default when you don't enable GNU extensions (thus use -std=c11
for example).  But use of FMA can also appear without -fexpensive-optimizations
if the combiner can synthesize it on RTL (without 4-insn combinations and other
special-cases that are also guarded with -fexpensive-optimizations).

In theory FMA should result in less rounding "errors".

I believe we do not (yet) support the C pragma to control FP contraction
while we probably could to some extent (on a function granularity via
the Optimization attribute or on file granularity via global option control).

[Bug tree-optimization/78384] [7 Regression] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 15)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-17
 CC||matz at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Caused by loop splitting.

[Bug c++/78391] New: g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

[lucanus81 at gmail dot com]

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

Bug ID: 78391
   Summary: g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't
warn when class members are used uninitialized.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucanus81 at gmail dot com
  Target Milestone: ---

Created attachment 40063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40063&action=edit
Minimal testcase that shows the (possible) problem.

It seems like g++ (any version) doesn't warn when class members are
uninitialized when no optimization is enabled (and at -O0). For -O1, -O2, -O3
we correctly get a warning (On the contrary, clang, any version, reports a
warning at any optimization level).

struct data { int x=w; int w=10; };

int main() {
data d;
return d.x;
}

g++ ub.cpp -Wall -Wextra -std=gnu++1z -O0 
=> no warning

g++ ub.cpp -Wall -Wextra -std=gnu++1z -O1
=> 
ub.cpp: In function 'int main()':
ub.cpp:4:10: warning: 'd.data::w' is used uninitialized in this function
[-Wuninitialized]
 data d;

for -O2, -O3 we get exactly the same warning.

[Bug tree-optimization/78383] label as values ICE with C++ lambda

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
The label does not have DECL_NONLOCAL set (but it should?).  But the obvious
error in cfgcleanup is that it fails to verify if the label jumped to belongs
to the current function, either by handling target_block == NULL or by
checking DECL_CONTEXT.

[Bug c++/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-17
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
-Wuninitialized requires optimization to handle this case.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #9 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Thu Nov 17 09:48:34 2016
New Revision: 242540

URL: https://gcc.gnu.org/viewcvs?rev=242540&root=gcc&view=rev
Log:
2016-11-17  Prathamesh Kulkarni  

PR tree-optimization/78319

testsuite/
* gcc.dg/uninit-pred-8_a.c (foo): Mark dg-bogus test to xfail on
arm-none-eabi.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/uninit-pred-8_a.c

[Bug c++/68180] [ICE] at cp/constexpr.c:2768 in initializing __vector in a loop

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Nov 17 09:59:07 2016
New Revision: 242541

URL: https://gcc.gnu.org/viewcvs?rev=242541&root=gcc&view=rev
Log:
2016-11-17  Paolo Carlini  

PR c++/68180
* g++.dg/cpp1y/pr68180.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr68180.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

[lucanus81 at gmail dot com]

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

--- Comment #2 from Luca Stoppa  ---
(In reply to Richard Biener from comment #1)
> -Wuninitialized requires optimization to handle this case.

I see thanks. Considering that I found this bug in our unit tests, I'll simply
add -O1 in order to avoid in the future this issue in our code.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[tony.reix at atos dot net]

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

--- Comment #13 from Tony Reix  ---
We have experimented with 20161106 snapshot and the change does work fine.
We have fixed our Proxy issue and we will work with GCC v7 trunk now.
Now investigating other issues.

[Bug fortran/78392] New: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[janus at gcc dot gnu.org]

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

Bug ID: 78392
   Summary: ICE in gfc_trans_auto_array_allocation, at
fortran/trans-array.c:5979
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Consider this short test case:

module mytypes
   implicit none
 contains
   pure integer function get_i ()
 get_i = 13
   end function
end module

program test
  use mytypes
  implicit none
  integer, dimension(get_i()), save :: x
  print *, size (x)
end


It seems to be valid Fortran, but generates an ICE with every gfortran version
I tried (from 4.7 to to 7-trunk).

On trunk, the error looks like this:

internal compiler error: in gfc_trans_auto_array_allocation, at
fortran/trans-array.c:5979
0x8dff23 gfc_trans_auto_array_allocation(tree_node*, gfc_symbol*,
gfc_wrapped_block*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-array.c:5979
0x90494d gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:4321
0x90b66e gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:6366
0x8cdcfd gfc_generate_code(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans.c:2030
0x85cefd translate_all_program_units
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6038
0x85d572 gfc_parse_file()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6238
0x8b66a5 gfc_be_parse_file
/home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202


It is related to typebound_proc_19.f90 in the testsuite (from PR 47399).

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||dominiq at lps dot ens.fr

--- Comment #1 from janus at gcc dot gnu.org ---
When removing the SAVE attribute ...


module mytypes
   implicit none
 contains
   pure integer function get_i ()
 get_i = 13
   end function
end module

program test
  use mytypes
  implicit none
  integer, dimension(get_i()) :: x
  print *, size (x)
end


... it compiles fine with all tested versions. However, this variant is a
regression of the patch for PR 55207, see:

https://gcc.gnu.org/ml/fortran/2014-03/msg00108.html

However, as comment 0 shows, it is not a problem introduced with that patch,
but it is rather a long-standing problem that is only uncovered by the patch
(according to F08, variables in the main PROGRAM implicitly get the SAVE
attribute).

[Bug c++/78393] New: Segfault with --help=^

[dave-gccbugs at earth dot li]

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

Bug ID: 78393
   Summary: Segfault with --help=^
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dave-gccbugs at earth dot li
  Target Milestone: ---

I misread the help page, and so asked for help on ^, this caused a segfault.

$ gcc --help=^
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.


$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

also happens on 

$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2

[Bug c++/78393] Segfault with --help=^

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
dup.

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

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dave-gccbugs at earth dot li

--- Comment #9 from ktkachov at gcc dot gnu.org ---
*** Bug 78393 has been marked as a duplicate of this bug. ***

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #2 from Dominik Vogt  ---
Both, the hang in genattrtab and the error message happen in stage 2.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

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

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

--- Comment #3 from Andreas Schwab  ---
Does it help to revert r242414?

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
There's another error that our dailybuild system found yesterday.  May have the
same cause.

build/genmatch --gimple
/home/dailybuild/gnu-dailybuild/arena/20161116/gcc-head/src/gcc/match.pd \
> tmp-gimple-match.c
genmatch: Internal error: abort in linemap_check_ordinary, at
libcpp/include/line-map.h:532
Makefile:2441: recipe for target 's-match' failed
make[3]: *** [s-match] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod gccgo.pod gfortran.pod
gcov-tool.pod fsf-funding.pod
make[3]: Leaving directory
'/31/home/dailybuild/gnu-dailybuild/arena/20161116/gcc-head/build-s390x-zEC12/gcc'
Makefile:4583: recipe for target 'all-stage2-gcc' failed

[Bug c++/78383] label as values ICE with C++ lambda

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||wrong-code
 Status|ASSIGNED|NEW
 CC||jason at gcc dot gnu.org
  Component|tree-optimization   |c++
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
The ICE is easily fixed but the missing DECL_NONLOCAL causes a miscompilation
into an endless loop because we move the label before the lambda call.  The
lambda doesn't seem to be a nested function (which contains DECL_NONLOCAL
handling) so the C++ frontend needs to handle this.

Almost finished testing a patch for the ICE, leaving to C++ FE people to
either reject the testcase or set DECL_NONLOCAL properly.

For reference, the following is the fix for the ICE:

Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 242539)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -230,6 +230,8 @@ cleanup_control_flow_bb (basic_block bb,
 edges which do not go to the right block.  For the one
 edge which goes to the right block, fix up its flags.  */
   label = TREE_OPERAND (gimple_goto_dest (stmt), 0);
+  if (DECL_CONTEXT (label) != cfun->decl)
+   return retval;
   target_block = label_to_block (label);
   for (ei = ei_start (bb->succs); (e = ei_safe_edge (ei)); )
{

[Bug c++/78383] label as values ICE with C++ lambda

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 17 12:39:24 2016
New Revision: 242543

URL: https://gcc.gnu.org/viewcvs?rev=242543&root=gcc&view=rev
Log:
2016-11-17  Richard Biener  

PR middle-end/78383
* tree-cfgcleanup.c (cleanup_control_flow_bb): Do not turn
non-local goto into CFG.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-cfgcleanup.c

[Bug c++/78383] label as values ICE with C++ lambda

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Richard Biener  ---
Ok, I believe it's an invalid testcase:

@node Labels as Values
...
You may not use this mechanism to jump to code in a different function.
If you do that, totally unpredictable things happen.  The best way to
avoid this is to store the label address only in automatic variables and
never pass it as an argument.

an exception is made for direct gotos to labels from nested functions to
the containing function if the label is previously declared.  C++ doesn't
support nested functions and lambdas are not explicitely mentioned.

Note that even before IPA propagates &label we mess up the CFG to:

int main() ()
{
  struct __lambda0 f;

label:
  main()_ZZ4mainENKUlPvE_clES_.isra.0 (&label);

}

so even cases that would rely on inlining to bring the reference back
to the label containing function may "break".

ICE fixed -> INVALID.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #5 from Dominik Vogt  ---
(In reply to Andreas Schwab from comment #3)
> Does it help to revert r242414?

Yep.  r242414 has introduced the problem.

(Happens only with --with-arch=zEC12.)

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> On trunk, the error looks like this:
> 
> internal compiler error: in gfc_trans_auto_array_allocation, at
> fortran/trans-array.c:5979

This line is an assert, and simply removing it makes the code in comment 0
compile and run without errors:


Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c   (Revision 242535)
+++ gcc/fortran/trans-array.c   (Arbeitskopie)
@@ -5976,7 +5976,6 @@ gfc_trans_auto_array_allocation (tree decl, gfc_sy
   type = TREE_TYPE (type);

   gcc_assert (!sym->attr.use_assoc);
-  gcc_assert (!TREE_STATIC (decl));
   gcc_assert (!sym->module);

   if (sym->ts.type == BT_CHARACTER


It also regtests cleanly on current trunk. With this patch, the only difference
in the dump of comment 0 and comment 1 is:


--- c0.f90.003t.original2016-11-17 13:15:57.487735846 +0100
+++ c1.f90.003t.original2016-11-17 13:13:07.096377920 +0100
@@ -12,7 +12,7 @@ test ()
   void * restrict D.3458;
   integer(kind=8) ubound.0;
   integer(kind=8) size.1;
-  static integer(kind=4)[0:D.3455] * restrict x;
+  integer(kind=4)[0:D.3455] * restrict x;
   integer(kind=8) D.3455;
   bitsizetype D.3456;
   sizetype D.3457;


As an alternative to removing the assert, one could possibly prevent SAVEd
variables in the main PROGRAM from being declared as "static" (which might also
cure the performance regressions that Dominique reported for my patch for PR
55207)?

[Bug tree-optimization/78386] Optimization -O2 and higher cause math inconsistency

[gromero at linux dot vnet.ibm.com]

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

Gustavo Romero  changed:

   What|Removed |Added

 CC||gromero at linux dot 
vnet.ibm.com

--- Comment #7 from Gustavo Romero  ---
Hi all,

I'm sorry, I told the issue is also present on x64, but I did some additional
tests today and I found it's not true.

On our test case the _LITTLE_ENDIAN macro is used. But on x64 it seems
_LITTLE_ENDIAN is not predefined
(gcc -dM -E - < /dev/null | fgrep "_LITTLE_ENDIAN 1" return nothing, but on
Power it does), so it was not correctly set.

The test case has been updated to reflect that difference, so now:

on x64:
$ ./call ; ./opt_call 
cosine total sum is: 0.33853897900536206
cosine total sum is: 0.33853897900536206

on PPC64:
$ ./call ; ./opt_call 
cosine total sum is: 0.33853897900536206
cosine total sum is: 0.33853897900538427

Thank you.

Regards

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|s390x   |s390x-*-*, ia64-*-*,
   ||aarch64-*-*
 CC||matz at suse dot de
   Host|s390x   |

--- Comment #6 from Andreas Schwab  ---
This is also breaking ia64 bootstrap, with various symptoms, and breaks
gcc.c-torture/execute/cbrt.c execution test on aarch64.

[Bug tree-optimization/78394] New: False positives of maybe-uninitialized with -Og

[linux at carewolf dot com]

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

Bug ID: 78394
   Summary: False positives of maybe-uninitialized with -Og
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com
  Target Milestone: ---

Created attachment 40064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40064&action=edit
maybe_uninitialized.cpp

Compiling with -Og produces a number of unique false positives for the
maybe-unintialized warnings. The warnings are only emited for -Og and not for
-O0, -O1, -O2 or -O3.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-17
 CC||matz at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |matz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Michael Matz  ---
Impressive how a seemingly obvious improvement to combine breaks all over the
place :-/  Anyway, mine then.

[Bug tree-optimization/78384] [7 Regression] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 15)

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Matz  ---
Mine.

[Bug tree-optimization/78343] [6/7 Regression] Loop is not eliminated

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Previously handled by the loop_depth check I guess.  Note that in

void
record_temporary_equivalences (edge e,
   class const_and_copies *const_and_copies,
   class avail_exprs_stack *avail_exprs_stack)
{
...
  /* Record the simple NAME = VALUE equivalence.  */
  tree rhs = edge_info->rhs;
  record_equality (lhs, rhs, const_and_copies);

  /* We already recorded that LHS = RHS, with canonicalization,
 value chain following, etc.

 We also want to record RHS = LHS, but without any canonicalization
 or value chain following.  */
  if (TREE_CODE (rhs) == SSA_NAME)
const_and_copies->record_const_or_copy_raw (rhs, lhs,
SSA_NAME_VALUE (rhs));

we eventually (as in this case) record the same equality twice given
record_equality performs canonicalization:

Optimizing block #4

1>>> STMT 1 = i_6 le_expr quant_3(D)
1>>> STMT 1 = i_6 ge_expr quant_3(D)
1>>> STMT 1 = i_6 eq_expr quant_3(D)
1>>> STMT 0 = i_6 ne_expr quant_3(D)
0>>> COPY quant_3(D) = i_6
0>>> COPY quant_3(D) = i_6
Optimizing statement sum_2 = quant_3(D) * quant_3(D);
  Replaced 'quant_3(D)' with variable 'i_6'
  Replaced 'quant_3(D)' with variable 'i_6'

in the IL we have a non-canonical compare:

:
# i_11 = PHI 
i_6 = i_11 + 1;
if (i_6 != quant_3(D))

IVOPT transforms

  if (quant_3(D) > i_6)
goto ;

to

  if (i_6 != quant_3(D))
goto ;

(both just as side-notes, not really relevant to this PR).

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |powerpc64le-unknown-linux-g
   |nu, x86_64-*|nu
  Component|tree-optimization   |target
Summary|Optimization -O2 and higher |[PPC] Optimization -O2 and
   |cause math inconsistency|higher cause math
   ||inconsistency

--- Comment #8 from Bill Schmidt  ---
(In reply to Bill Schmidt from comment #3)
> Breno and his team have indicated that this is a problem on x86_64 also, so
> changing the title and targets accordingly.

This turns out not to be true.  Adjusting to PPC-only bug for now.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[edlinger at gcc dot gnu.org]

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

--- Comment #63 from Bernd Edlinger  ---
Author: edlinger
Date: Thu Nov 17 13:47:24 2016
New Revision: 242549

URL: https://gcc.gnu.org/viewcvs?rev=242549&root=gcc&view=rev
Log:
2016-11-17  Bernd Edlinger  

PR target/77308
* config/arm/arm.md (*thumb2_ldrd, *thumb2_ldrd_base,
*thumb2_ldrd_base_neg, *thumb2_strd, *thumb2_strd_base,
*thumb2_strd_base_neg): Recognize insn regardless of
current_tune->prefer_ldrd_strd.
* config/arm/ldrdstrd.md: Enable all ldrd/strd peephole rules
whenever possible.

testsuite:
2016-11-17  Bernd Edlinger  

PR target/77308
* gcc.target/arm/pr53447-5.c: New test.
* lib/target-supports.exp
(check_effective_target_arm_prefer_ldrd_strd): Adjust.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr53447-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/ldrdstrd.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

[linux at carewolf dot com]

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

Allan Jensen  changed:

   What|Removed |Added

  Attachment #40064|0   |1
is obsolete||

--- Comment #1 from Allan Jensen  ---
Created attachment 40065
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40065&action=edit
maybe_uninitialized.cpp

Added another example

[Bug fortran/77505] Negative character length not treated as LEN=0

[elizebethp at gmail dot com]

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

--- Comment #6 from Elizebeth Punnoose  ---
Modified code with the warning message moved behind -fcheck=bounds.

Index: trans-array.c
===
--- trans-array.c   (revision 241960)
+++ trans-array.c   (working copy)
@@ -2226,6 +2226,8 @@
   gfc_ss_info *ss_info;
   gfc_expr *expr;
   gfc_ss *s;
+  tree neg_len;
+  char *msg;

   /* Save the old values for nested checking.  */
   old_first_len = first_len;
@@ -2271,6 +2273,27 @@
  gfc_conv_expr_type (&length_se, expr->ts.u.cl->length,
  gfc_charlen_type_node);
  ss_info->string_length = length_se.expr;
+
+ /* Check if the character length is negative, 
+if so consider it as LEN=0. */
+ neg_len = fold_build2_loc (input_location, LT_EXPR,
+   boolean_type_node, ss_info->string_length,
+   build_int_cst (gfc_charlen_type_node, 0));
+ /* Print a warning if bounds checking is enabled. */
+ if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+ {
+   msg = xasprintf ("Negative character length will be treated as
LEN=0");
+   gfc_trans_runtime_check (false, true, neg_len, 
+&length_se.pre, where, msg);
+   free(msg);
+ }
+ ss_info->string_length = fold_build3_loc (input_location, 
+  COND_EXPR, gfc_charlen_type_node, 
+  neg_len, gfc_index_zero_node, 
+  ss_info->string_length);
+ ss_info->string_length = gfc_evaluate_now (ss_info->string_length,
+&length_se.pre);
+
  gfc_add_block_to_block (&outer_loop->pre, &length_se.pre);
  gfc_add_block_to_block (&outer_loop->post, &length_se.post);
}

[Bug fortran/78395] New: [OOP] ICE for operations with polymorphic variables

[cmacmackin at gmail dot com]

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

Bug ID: 78395
   Summary: [OOP] ICE for operations with polymorphic variables
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cmacmackin at gmail dot com
  Target Milestone: ---

Created attachment 40066
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40066&action=edit
Minimal code producing ICE.

While trying to produce a minimal example for an issue I've been having with
gfortran seeming to misidentify return types when I chain togethor certain
type-bound operators, I came across this ICE. I've attached the code which
produces the ICE. gfortran seems to run into trouble when parsing return types
for line 132. When I perform the same operations using non-polymorphic
variabels (as in line 131) there is no issue.

I am using a self-compiled gfortran-6 binary (compiled against the OpenCoarrays
library, although I'm not using any coarray features). Running "gfortran -v
minimal-abstract.f90" produces

Driving: gfortran -v minimal-abstract.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/macmackin/.local/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/configure
--prefix=/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/installations/gcc/6.1.0
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-werror
Thread model: posix
gcc version 6.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/macmackin/.local/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.1.0/f951
minimal-abstract.f90 -quiet -dumpbase minimal-abstract.f90 -mtune=generic
-march=x86-64 -auxbase minimal-abstract -version -fintrinsic-modules-path
/home/macmackin/.local/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/finclude -o
/tmp/macmackin/ccMxUT4H.s
GNU Fortran (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:245
0x60aaae gfc_add_component_ref(gfc_expr*, char const*)
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/class.c:245
0x67f528 resolve_typebound_function
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/resolve.c:6008
0x67f528 gfc_resolve_expr(gfc_expr*)
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/resolve.c:6351
0x631e1a gfc_extend_expr(gfc_expr*)
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/interface.c:3836
0x67f147 resolve_operator
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/resolve.c:3844
0x67f147 gfc_resolve_expr(gfc_expr*)
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/resolve.c:6333
0x685933 gfc_resolve_code(gfc_code*, gfc_namespace*)
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/resolve.c:10437
0x6880e2 resolve_codes
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/resolve.c:15554
0x6881d1 gfc_resolve(gfc_namespace*)
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/resolve.c:15588
0x6739da resolve_all_program_units
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/parse.c:5552
0x6739da gfc_parse_file()
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/parse.c:5804
0x6b4d15 gfc_be_parse_file
   
/home/macmackin/Code/OpenCoarrays-1.7.2/prerequisites/downloads/gcc-6.1.0/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


When I try compiling the same file with gfortran-4.8 I get

Driving: gfortran-4.8 -v minimal-abstract.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.3' --with-bugurl=file:/

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

[gromero at linux dot vnet.ibm.com]

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

--- Comment #9 from Gustavo Romero  ---
Both -ffp-contract=off and -std=c11 (with -O3) do not damage the precision:

CFLAGS=-I. -g -static -O3 -ffp-contract=off# Precision is OK
CFLAGS=-I. -g -static -std=c11 -O3 # Precision is OK
CFLAGS=-I. -g -static -std=c11 -ffp-contract=off -O3   # Precision is OK
CFLAGS=-I. -g -static -O3  # Precision is NOT OK

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

--- Comment #25 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Nov 17 14:22:17 2016
New Revision: 242550

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

2016-11-17  Bill Schmidt  
Richard Biener  

PR tree-optimization/77848
* tree-if-conv.c (tree_if_conversion): Always version loops unless
the user specified -ftree-loop-if-convert.

[gcc/testsuite]

2016-11-17  Bill Schmidt  
Richard Biener  

PR tree-optimization/77848
* gfortran.dg/vect/pr77848.f: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr77848.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #26 from Bill Schmidt  ---
Fixed.  I will open a bug for the bb-slp-cond-1.c regression.

[Bug tree-optimization/78396] New: [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848

[wschmidt at gcc dot gnu.org]

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

Bug ID: 78396
   Summary: [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after
fix for PR77848
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848 identified a case where
if-conversion modified a loop that was not subsequently vectorized, with the
resulting code being significantly worse than without if-conversion.  Since
if-conversion has no cost model, this was resolved by requiring loop versioning
for all if-converted loops unless if-conversion was specifically requested.

There was one bit of fallout from this, as gcc.dg/vect/bb-slp-cond-1.c now
fails.  This test expected if-converted input that the BB vectorizer would be
able to handle after the loop vectorizer failed on it.

There are two ways this can be resolved:
 - Improve the data dependence analysis in the loop vectorizer; or
 - Teach the basic block vectorizer to if-convert PHIs in otherwise
straight-line code.

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

--- Comment #27 from Bill Schmidt  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396 is open to track that
failure.

[Bug tree-optimization/78396] [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug target/78397] New: The stack is not 8 bytes aligned on ARM

[alexandre.martins at stormshield dot eu]

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

Bug ID: 78397
   Summary: The stack is not 8 bytes aligned on ARM
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexandre.martins at stormshield dot eu
  Target Milestone: ---
  Host: armv5te
Target: armv5te
 Build: armv5te

Created attachment 40067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40067&action=edit
Demo C file to reproduce the bug

Greetings

I'm currently developing on an ARMv5te platform on FreeBSD 10.3. I'm mixing
code compiled by clang 3.4 (libc, rtld, ...) and by gcc 5.4.0 (my program).

Time to time, an assertion in the rtld of FreeBSD warn us that a lock is not in
a consistent state. The lock is stored on the stack, so I suspect stack
corruption.

After few hours of digging, I see that clang assume that the stack is 8 bytes
aligned (as
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka4127.html
say) and perform some optimisations (?) on pointer computations. In my problem,
too add 4 to an address supposed to be 8 bytes aligned, clang produce : "orr
r0, r0, #4". It's working well when the stack is 8 bytes aligned, but not when
it's 4 bytes aligned.

Unfortunately, some of my code, when compiled with GCC and optimised, unalign
the stack. You will find the source code and the assembly in attached file.

[Bug target/78397] The stack is not 8 bytes aligned on ARM

[alexandre.martins at stormshield dot eu]

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

--- Comment #1 from Alexandre Martins  
---
Created attachment 40068
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40068&action=edit
Demo generated assembly

[Bug target/78397] The stack is not 8 bytes aligned on ARM

[alexandre.martins at stormshield dot eu]

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

Alexandre Martins  changed:

   What|Removed |Added

 CC||alexandre.martins@stormshie
   ||ld.eu

--- Comment #2 from Alexandre Martins  
---
Created attachment 40069
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40069&action=edit
proposed patch

When trying to fix this bug, I made this patch. Hope it help ...

[Bug fortran/78398] New: missing warnings and inconsistencies with -Wuninitialized

[janus at gcc dot gnu.org]

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

Bug ID: 78398
   Summary: missing warnings and inconsistencies with
-Wuninitialized
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Please consider the following example:


subroutine s1
  integer :: i,j
  j = i   ! warning here
  print *,i   ! none here
end

module m
contains
  subroutine s2
integer :: i,j
j = i   ! warning here
print *,i   ! none here
  end
end module

program p
contains
  subroutine s3
integer :: i,j
j = i   ! none here
print *,i   ! none here
  end
end


Compiling this with -Wuninitialized correctly produces two warnings on the
marked lines (with gfortran 5, 6 and trunk), but four warnings are missing.

Two things are inconsistent here:
1) The subroutines s1,s2,s3 are completely identical. If the routine is
alone-standing or inside a module, we get a warning. But if it is contained in
a program, the warning is gone.
2) We get a warning when an uninitialized variable is used in an assignment,
but not in a print statement.

[Bug fortran/78398] missing warnings and inconsistencies with -Wuninitialized

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> 2) We get a warning when an uninitialized variable is used in an assignment,
> but not in a print statement.

This may be related to PR 34721.

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-17
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
I can confirm the ICE in gfc_add_component_ref only with gfortran 5.4.1 and
earlier.


gfortran 6.2.0 says:

   v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
  1
Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported


And a current trunk build:


   v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
   1
Error: Can't convert TYPE(__vtype_types_mod_A1) to CLASS(a2) at (1)


The error with 6.2 is acceptable, I guess, but the one with trunk is not so
nice.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #8 from Michael Matz  ---
The aarch64 fail is fixed by the below patch.  It will take a while for me
to try this on s390, so if somebody beats me to test this I won't complain.

diff --git a/gcc/combine.c b/gcc/combine.c
index 0210685..05b6554 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7380,6 +7380,7 @@ make_extraction (machine_mode mode, rtx inner,
HOST_WIDE_INT pos,
   || !REG_P (inner)
   || TRULY_NOOP_TRUNCATION_MODES_P (tmode, inner_mode)
   || reg_truncated_to_mode (tmode, inner))
+  && (REG_P (inner) || pos == 0)
   && (! in_dest
   || (REG_P (inner)
   && have_insn_for (STRICT_LOW_PART, tmode

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> gfortran 6.2.0 says:
> 
>v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
>   1
> Error: Assignment to an allocatable polymorphic variable at (1) is not yet
> supported

It seems this error message was removed on trunk by Andre's r241439.

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
-std=gnuXX affects IEEE 754 conformance, but that is not mentioned in the
documentation, only in source code comments (c-family/c-cppbuiltin.c)

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #11 from Bill Schmidt  ---
Looks like this is WAD.  From the documentation:

  -ffp-contract=style

  ‘-ffp-contract=off’ disables floating-point expression contraction. ‘-ffp- 
contract=fast’ enables floating-point expression contraction such as forming of
fused multiply-add operations if the target has native support for them.
‘-ffp-contract=on’ enables floating-point expression contraction if allowed by
the language standard. This is currently not implemented and treated equal to
‘-ffp-contract=off’.

  The default is ‘-ffp-contract=fast’.

Also, from internal commentary this default is associated with the default
standard, which is -std=gnu11.  "In strict C standards comformance mode,
consider unpredictable excess precision to mean lack of IEEE 754 support.  The
same applies to unpredictable contraction.  For C++, and outside strict
conformance mode, do not consider these options to mean lack of IEEE 754
support."  This is why using -std=c11, for example, solves the "problem."

Thus, looks like your best option is to use -ffp-contract=off to get the
desired results.

Thanks,
Bill

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Somewhat reduced test case (without all the abstract stuff):


module types_mod
  implicit none

  type, public :: t1
integer :: a
  contains
procedure :: get_t2
  end type

  type, public :: t2
integer :: b
  contains
procedure, pass(rhs) :: mul2
procedure :: assign
generic :: operator(*) => mul2
generic :: assignment(=) => assign
  end type

contains

  function get_t2(this)
class(t1), intent(in) :: this
class(t2), allocatable :: get_t2
type(t2), allocatable :: local
allocate(local)
local%b = this%a
call move_alloc(local, get_t2)
  end function

  function mul2(lhs, rhs)
class(t2), intent(in) :: rhs
integer, intent(in) :: lhs
class(t2), allocatable :: mul2
type(t2), allocatable :: local
allocate(local)
local%b = rhs%b*lhs
call move_alloc(local, mul2)
  end function

  subroutine assign(this, rhs)
class(t2), intent(out) :: this
class(t2), intent(in)  :: rhs
select type(rhs)
type is(t2)
  this%b = rhs%b
class default
  error stop
end select
  end subroutine

end module


program minimal
  use types_mod
  implicit none

  class(t1), allocatable :: v4
  class(t2), allocatable :: v6

  allocate(v4, source=t1(4)) ! Also fails if I use `allocate(t1 :: v4)`
  v6 = 3 * v4%get_t2() ! This line is the one which causes ICE

end

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #0)
> By definition, for radix b = 2, LDBL_MAX is the value (1 - 2^(-p)) * 2^emax
> (see §5.2.4.2.2p12), which is the largest value representable in the
> floating-point model.

There has been a defect report and this is no longer the case. See:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2092.htm

"DR 467 decided that FLT_MAX, DBL_MAX, LDBL_MAX are the maximum representable
finite numbers for their respective types."

So, this solves this issue: LDBL_MAX is correct according to this DR. As a
consequence, I'm resolving the PR as invalid.

[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Thu Nov 17 15:55:26 2016
New Revision: 242552

URL: https://gcc.gnu.org/viewcvs?rev=242552&root=gcc&view=rev
Log:
Fix locations within raw strings

Whilst investigating PR preprocessor/78324 I noticed that the
substring location code currently doesn't handle raw strings
correctly, by not skipping the 'R', opening quote, delimiter
and opening parenthesis.

For example, an attempt to underline chars 4-7 with caret at 6 of
this raw string yields this erroneous output:
   __emit_string_literal_range (R"foo(0123456789)foo",
~~^~

With the patch, the correct range/caret is printed:

   __emit_string_literal_range (R"foo(0123456789)foo",
  ~~^~

gcc/ChangeLog:
* input.c (selftest::test_lexer_string_locations_long_line): New
function.
(selftest::test_lexer_string_locations_raw_string_multiline): New
function.
(selftest::input_c_tests): Call the new functions, via
for_each_line_table_case.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic-test-string-literals-1.c
(test_raw_string_one_liner): New function.
(test_raw_string_multiline): New function.

libcpp/ChangeLog:
* charset.c (cpp_interpret_string_1): Skip locations from
loc_reader when advancing 'p' when handling raw strings.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #9 from Dominik Vogt  ---
On Thu, Nov 17, 2016 at 03:03:03PM +, matz at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
> 
> --- Comment #8 from Michael Matz  ---
> The aarch64 fail is fixed by the below patch.  It will take a while for me
> to try this on s390, so if somebody beats me to test this I won't complain.

I'm just bootstrapping s390x with the fix; would you like me to
run a regression test against the fixed patch?

Ciao

Dominik ^_^  ^_^

[Bug c++/78399] New: g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

[lucanus81 at gmail dot com]

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

Bug ID: 78399
   Summary: g++ generates sub-optimal assembler code when structs
aren't explicitly aligned.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucanus81 at gmail dot com
  Target Milestone: ---

Created attachment 40070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40070&action=edit
suboptimal code

Consider the following example:

struct pod { char x[7]; };
pod copy_pod(pod d) { return d; }

gcc (at any optimization level) will general sub-optimal assembler code (see
attachment).
The interesting thing is that if we change "pod" to contain a number of bytes
that fit into a cpu register (2, 4, 8, 16, 32, 64) then the generated assembler
is optimal (see attachment)

struct pod { char x[8]; };
pod copy_pod(pod d) { return d; }

One workaround I found is to explicitly use alignas:
struct alignas(8) pod { char x[7]; }; 

I'm wondering whether gcc should generate optimal code even without alignas(8).

[Bug tree-optimization/46639] [5/6 Regression] Missing optimization due to function splitting and redundant conditionals

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Missing  |[5/6 Regression] Missing
   |optimization due to |optimization due to
   |function splitting and  |function splitting and
   |redundant conditionals  |redundant conditionals

--- Comment #19 from Jeffrey A. Law  ---
Early FRE picks this up in gcc-7.

[Bug c++/78399] g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

[lucanus81 at gmail dot com]

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

--- Comment #1 from Luca Stoppa  ---
Created attachment 40071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40071&action=edit
Optimal code

[Bug rtl-optimization/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 17 16:16:38 2016
New Revision: 242554

URL: https://gcc.gnu.org/viewcvs?rev=242554&root=gcc&view=rev
Log:
PR rtl-optimization/78355
* doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Document that the macro only
needs to deal with unaligned accesses.
* doc/tm.texi: Regenerate.
* lra-constraints.c (simplify_operand_subreg): Only invoke
SLOW_UNALIGNED_ACCESS on innermode if the MEM is not aligned enough.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/lra-constraints.c

[Bug rtl-optimization/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #9 from Eric Botcazou  ---
Thanks for reporting the problem and fixing it at the same time!

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #10 from Michael Matz  ---
(In reply to Dominik Vogt from comment #9)
> On Thu, Nov 17, 2016 at 03:03:03PM +, matz at gcc dot gnu.org wrote:
> 
> I'm just bootstrapping s390x with the fix; would you like me to
> run a regression test against the fixed patch?

Cool, thanks.  If bootstrap is still not working then it would help to
have a testcase that breaks on s390x, not a whole miscompiled compiler :)
So, if still broken please run a reg-test without bootstrap with and without
that revision and see if there are any testcases breaking.

[Bug c++/78399] g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Related to PR 50384.

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
I can confirm it only happens with the -Og optimization level; I also tested
-Ofast and -Os, and neither of those triggered it either.

gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Og maybe_uninit_00.cpp
maybe_uninit_00.cpp: In function ‘float foo()’:
maybe_uninit_00.cpp:19:17: warning: ‘vy’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 return vx + vy;
 ^~
maybe_uninit_00.cpp:19:17: warning: ‘vx’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O1 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O2 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O3 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Og maybe_uninit_01.cpp
maybe_uninit_01.cpp: In function ‘float foo()’:
maybe_uninit_01.cpp:19:17: warning: ‘vy’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 return vx + vy;
 ^~
maybe_uninit_01.cpp:19:17: warning: ‘vx’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --enable-objc-gc --disable-host-shared
--enable-maintainer-mode --disable-default-pie --with-ld64 --without-pic
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 7.0.0 20161027 (experimental) (GCC)

[Bug rtl-optimization/78400] New: [7 Regression] ICE: in df_refs_verify, at df-scan.c:4045 when building powerpc crosscompiler

[zsojka at seznam dot cz]

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

Bug ID: 78400
   Summary: [7 Regression] ICE: in df_refs_verify, at
df-scan.c:4045 when building powerpc crosscompiler
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc-unknown-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 40072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40072&action=edit
reduced testcase

Compiler output:
$ $
/repo/build-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc/./gcc/cc1
-quiet -O2 testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in df_refs_verify, at df-scan.c:4045
 }
 ^
0x7924a2 df_refs_verify
/repo/gcc-trunk/gcc/df-scan.c:4045
0x797f30 df_insn_refs_verify
/repo/gcc-trunk/gcc/df-scan.c:4125
0x79a272 df_bb_verify
/repo/gcc-trunk/gcc/df-scan.c:4154
0x79a597 df_scan_verify()
/repo/gcc-trunk/gcc/df-scan.c:4286
0x782e78 df_verify()
/repo/gcc-trunk/gcc/df-core.c:1831
0x782efa df_analyze_1
/repo/gcc-trunk/gcc/df-core.c:1217
0xb8d304 try_shrink_wrapping_separate(basic_block_def*)
/repo/gcc-trunk/gcc/shrink-wrap.c:1694
0x8b0d7f thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.c:5960
0x8b1572 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.c:6419
0x8b1572 execute
/repo/gcc-trunk/gcc/function.c:6461
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$
/repo/build-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc/./gcc/xgcc
-v
Using built-in specs.
COLLECT_GCC=/repo/build-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc/./gcc/xgcc
Target: powerpc-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl
--with-sysroot=/usr/powerpc-unknown-linux-gnu
--target=powerpc-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc-unknown-linux-gnu
--with-ld=/usr/bin/powerpc-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc
Thread model: posix
gcc version 7.0.0 20161117 (experimental) (GCC) 


The compiler was configured with --enable-checking=yes,rtl,df,extra ; maybe df
checking is needed to reproduce.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

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

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

--- Comment #11 from Andreas Schwab  ---
That didn't fix the ia64 bootstrap failure.

[Bug c++/78401] New: SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78401
   Summary: SciMark v2.0 Composite test runs 1,5 times slower
under GCC 6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article&item=gcc-clang-kblclear&num=2

GCC 6.2.0 - 1057
Clang 3.9.0 - 1603

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug c++/78402] New: SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78402
   Summary: SciMark v2.0  Dense LU Matrix Factorization test runs
more than 2 times slower under GCC 6.2 than under
Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article&item=gcc-clang-kblclear&num=2

GCC 6.2.0 - 1834
Clang 3.9.0 - 4165

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug c++/78403] New: SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78403
   Summary: SciMark v2.0 Jacobi Successive Over-Relaxation test is
30% slower under GCC 6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article&item=gcc-clang-kblclear&num=2

GCC 6.2.0 - 875
Clang 3.9.0 - 1162

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[avieira at gcc dot gnu.org]

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

--- Comment #6 from avieira at gcc dot gnu.org ---
I had a look at this and after some digging I found the bug is not due to LTO,
but rather with "local" functions. If you make bar static you will end up with
the same faulty behavior.

After some more digging I found myself going through the 'untyped_call' code in
arm.md. Here I found both 'untyped_call' and 'untyped_return' had not been
adjusted to be able to cope with HardFP ABI's.  I wrote a patch to mend this,
needs a bit more work, but I think it's correct and I might put it on
gcc-patches at a later time.

However, when I started thinking of how I was going to "fix" this wrong-code
generation, I realized that due to the way untyped_call's and untyped_return's
are constructed and the nature of '__builtin_return' and '__builtin_apply', you
do not know which registers are actually used to return the values, you only
know it might be 'r0-r4' and 'd0-d7'. So even though I know the call-site would
expect a return of type 'double' in 'r0-r1', because this is local function
(aka 'ARM_PCS_AAPCS_LOCAL') and the target does not support double precision,
there is no way for me to know in which of the registers the function is
actually returning, so I dont know what registers to move to 'r0-r1'.

So  I don't think we can get this builtin to work for single precision
VFPs, without compromising on the way we use local function returns.

[Bug c++/78404] New: SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78404
   Summary: SciMark v2.0 Sparse Matrix Multiply test is 20% slower
under GCC 6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article&item=gcc-clang-kblclear&num=2

GCC 6.2.0 - 1835
Clang 3.9.0 - 2204

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[cmacmackin at gmail dot com]

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

--- Comment #4 from Chris  ---
I tried compiling (my original example) on a different box, this one with
gfortran 6.2.0 obtained from the ubuntu-toolchain-r/test PPA. I got

Driving: gfortran-6 -v minimal.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
6.2.0-3ubuntu11~16.04' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --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 --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~16.04) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/f951 minimal.f90 -quiet -dumpbase minimal.f90
-mtune=generic -march=x86-64 -auxbase minimal -version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-linux-gnu/6/finclude -o /tmp/chris/ccDLOYCy.s
GNU Fortran (Ubuntu 6.2.0-3ubuntu11~16.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Ubuntu 6.2.0-3ubuntu11~16.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241
0x5dede4 gfc_add_component_ref(gfc_expr*, char const*)
../../src/gcc/fortran/class.c:241
0x6564f1 resolve_typebound_function
../../src/gcc/fortran/resolve.c:6014
0x6564f1 gfc_resolve_expr(gfc_expr*)
../../src/gcc/fortran/resolve.c:6357
0x60730a gfc_extend_expr(gfc_expr*)
../../src/gcc/fortran/interface.c:3943
0x656064 resolve_operator
../../src/gcc/fortran/resolve.c:3850
0x656064 gfc_resolve_expr(gfc_expr*)
../../src/gcc/fortran/resolve.c:6339
0x65cab3 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../src/gcc/fortran/resolve.c:10459
0x65f282 resolve_codes
../../src/gcc/fortran/resolve.c:15656
0x65f37e gfc_resolve(gfc_namespace*)
../../src/gcc/fortran/resolve.c:15691
0x64a62a resolve_all_program_units
../../src/gcc/fortran/parse.c:5854
0x64a62a gfc_parse_file()
../../src/gcc/fortran/parse.c:6106
0x68c1c2 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Would there be some issue with the build which is causing the ICE for me? The
error message which you reported for gfortran 6.2.0 also doesn't make sense to
me, as I use defined-assignment to allocatable variables frequently in my code
without problem. Indeed, it is used a line or two earlier in the example I
provided.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #12 from Michael Matz  ---
(In reply to Andreas Schwab from comment #11)
> That didn't fix the ia64 bootstrap failure.

Would have been too easy I guess :-)  Okay, can you try to find a testcase
that regressed by not bootstrapping but running the testsuite?

[Bug c/78405] New: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78405
   Summary: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC
6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

http://www.phoronix.com/scan.php?page=article&item=gcc-clang-kblclear&num=4

GCC 6.2.0 - 243
Clang 3.9.0 - 289

GCC options: -m64 -O3 -lssl -lcrypto -ldl

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug c/78406] New: Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78406
   Summary: Crafty v23.4 is 20% slower under GCC 6.2 than under
Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

http://www.phoronix.com/scan.php?page=article&item=gcc-clang-kblclear&num=4

GCC 6.2.0 - 95 seconds
Clang 3.9.0 - 78 seconds

GCC options: -lstdc++ -lm

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #13 from Dominik Vogt  ---
I'm doing this on s390x right now.  Just takes some more time.

[Bug c/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
  Component|middle-end  |c

--- Comment #1 from Markus Trippelsdorf  ---
Artem, please don't open a new bug for every phoronix benchmark where gcc
appears to be slower than clang.

First of all there are existing bug report for many of the issues.
And secondly phoronix is famous for its bogus benchmark numbers, 
so please take them with a big grain of salt.

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 17 17:09:13 2016
New Revision: 242555

URL: https://gcc.gnu.org/viewcvs?rev=242555&root=gcc&view=rev
Log:
PR middle-end/78201
* varasm.c (default_use_anchors_for_symbol_p): Fix a comment typo.
Don't test decl != NULL.  Don't look at DECL_SIZE, but DECL_SIZE_UNIT
instead, return false if it is NULL, or doesn't fit into uhwi, or
is larger or equal to targetm.max_anchor_offset.

* g++.dg/opt/pr78201.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr78201.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

--- Comment #2 from Artem S. Tashkinov  ---
(In reply to Markus Trippelsdorf from comment #1)
> Artem, please don't open a new bug for every phoronix benchmark where gcc
> appears to be slower than clang.
> 
> First of all there are existing bug report for many of the issues.
> And secondly phoronix is famous for its bogus benchmark numbers, 
> so please take them with a big grain of salt.

I'm terribly sorry. Still there are no obvious duplicates for any of the
recently reported bugs.

I don't pay attention when one compiler is 10%, give or take, faster than
another. However this recent test shows some major differences so I was worried
that maybe GCC 6.2.0 is falling behind.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #14 from Dominik Vogt  ---
With the fix I couldn't reproduce the error message in four attempts, but
genattrtab still hangs.  Maybe this is bad luck, but maybe the error is gone. 
Running a regression test without bootstrapping on s390x, --with-arch=zEC12,
--languages=c, there is a long list of tests that fail:

 Running target unix/-m64
+FAIL: gcc.c-torture/execute/20030408-1.c   -O1  execution test
+FAIL: gcc.c-torture/execute/20040709-1.c   -O1  execution test
+FAIL: gcc.c-torture/execute/930921-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/930921-1.c   -Os  execution test
+FAIL: gcc.c-torture/execute/builtin-bitops-1.c   -O2  execution test
+FAIL: gcc.c-torture/execute/builtin-bitops-1.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/builtin-bitops-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O3 -g  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -Os  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O3 -g  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -Os  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O3 -g  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -Os  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec1.c   -O1  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec2.c   -O1  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec2.c   -O3 -g  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O1  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O2  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O3 -g  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  execution test
+FAIL: gcc.dg/ftrapv-2.c execution test
+FAIL: gcc.dg/ftrapv-3.c execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O1  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O2  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O3 -g  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -Os  execution test
+FAIL: gcc.dg/sso/p3.c   -O1 -fno-inline  output pattern test, is My_R1: c2
7b f3 2a 5e 12 9a 95
+FAIL: gcc.dg/sso/p3.c   -O2  output pattern test, is My_R1: c2 7b f3 2a 5e
12 9a 95
+FAIL: gcc.dg/sso/p3.c   -O3 -finline-functions  output pattern test, is My_R1 
  : c2 7b f3 2a 5e 12 9a 95
+FAIL: gcc.dg/sso/p3.c   -Os  output pattern test, is My_R1: c2 7b f3 2a 5e
12 9a 95
+FAIL: gcc.dg/torture/pr43000.c   -O1  execution test
+FAIL: gcc.dg/torture/pr43000.c   -O2  execution test
+FAIL: gcc.dg/torture/pr43000.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.dg/torture/pr43000.c   -O3 -g  execution test
+FAIL: gcc.dg/torture/pr43000.c   -Os  execution test
+FAIL: gcc.target/s390/risbg-ll-1.c scan-assembler
f43:\\n\\trisbg\\t%r2,%r2,32,128+61,64-12
+FAIL: gcc.target/s390/risbg-ll-2.c scan-assembler
f9:\\n\\trisbg\\t%r3,%r2,48,63,64-48

[Bug lto/78407] New: LTO breaks separate overriding of symbol aliases

[srk31 at srcf dot ucam.org]

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

Bug ID: 78407
   Summary: LTO breaks separate overriding of symbol aliases
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: srk31 at srcf dot ucam.org
  Target Milestone: ---

Created attachment 40073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40073&action=edit
Test case tarball

I have a library which tests, in a constructor function, whether another
library is overriding one of its symbols. If so, it skips initialization (since
the other library is taking care of it). This is necessary because constructors
cannot meaningfully be overridden.

To do this test, I create a hidden alias of the overridable symbol. This will
always point to our copy, even if the global alias gets overridden.

int foo = 0;

extern int our_foo __attribute__((visibility("hidden"),alias("foo")));

static void (__attribute__((constructor)) init)(void)
{
if (&our_foo != &foo)
{
/* skip init */
}
else
{
/* do init */
}
}

Building this library with LTO works fine on gcc 4.9.3 and earlier. On 5.x and
6.x the address comparison gets wrongly optimised away (tested on 5.2.1 and
6.2.0). In 4.9.x I get:

06c0 :
 6c0:   55  push   %rbp
 6c1:   48 89 e5mov%rsp,%rbp
 6c4:   48 8d 05 5e 09 20 00lea0x20095e(%rip),%rax 
 6cb:   48 8b 15 06 09 20 00mov0x200906(%rip),%rdx 
 6d2:   48 39 d0cmp%rdx,%rax
 6d5:   74 1a   je 6f1 
...

i.e. a cmp instruction, whereas with 5.2.1 there is none.

06b0 :
 6b0:   55  push   %rbp
 6b1:   48 89 e5mov%rsp,%rbp
 6b4:   48 8d 35 f5 ff ff fflea-0xb(%rip),%rsi# 6b0 
 6bb:   48 8d 3d 17 00 00 00lea0x17(%rip),%rdi# 6d9 <_fini+0x9>
 6c2:   b8 00 00 00 00  mov$0x0,%eax
 6c7:   e8 c4 fe ff ff  callq  590 
 6cc:   5d  pop%rbp
 6cd:   c3  retq   

Unless I'm mistaken: for any two ELF symbol aliases, if at least one has global
visibility, LTO cannot assume they will remain aliased at run time.

Tarball attached. On doing "make run", "lib1" should only claim to initialize
itself once, but it happens twice on 5.x+.

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Chris from comment #4)
> I tried compiling (my original example) on a different box, this one with
> gfortran 6.2.0 obtained from the ubuntu-toolchain-r/test PPA. I got
> 
> [..]
> gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~16.04) 

My gfortran-6 version is what currently is in Ubuntu 16.10:

gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)

and that does not give an ICE, but the error shown above.


> Would there be some issue with the build which is causing the ICE for me?

Not sure. Since our versions differ a bit, the most probable scenario is that
the different behavior was caused by some recent backport (unfortunately Ubuntu
does not give exact revision numbers). One should check the logfile:

https://gcc.gnu.org/viewcvs/gcc/branches/gcc-6-branch/gcc/fortran/ChangeLog?view=markup


> The error message which you reported for gfortran 6.2.0 also doesn't make
> sense to me, as I use defined-assignment to allocatable variables frequently
> in my code without problem.

True. Didn't notice that. I guess the error should only apply to intrinsic
assignment, not user-defined. So maybe that's a bug after all.


> Indeed, it is used a line or two earlier in the
> example I provided.

Which one do you mean exactly? Shouldn't they all use the user-defined
assignment function?

In any case the error is thrown on the last line, and I also get it on the
reduced example in comment 3:


$ gfortran-6 c3.f90 
c3.f90:62:2:

   v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
  1
Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Created attachment 40074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40074&action=edit
Test program for benchmarks

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Here are some measurements with the AVX-enabling patch.
They were done on an AVX machine, namely gcc75 from the compile farm.

This was done with the command line

gfortran -static-libgfortran -finline-matmul-limit=0 -Ofast -o compare_mavx
compare_2.f90

Uncontidionally setting -mavx in the Makefile for matmul, with stock trunk:

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  5000  0.067  0.077  0.051  0.069
3  5000  0.193  0.218  0.157  0.194
4  5000  0.429  0.423  0.368  0.435
5  5000  0.609  0.659  0.556  0.630
7  5000  0.948  1.018  0.931  1.009
8  5000  1.608  1.251  1.589  1.715
9  5000  1.755  1.484  1.745  1.856
   15  5000  2.710  2.175  2.963  3.105
   16  5000  4.289  2.510  4.541  4.784
   17  5000  4.411  3.032  4.675  4.888
   31  5000  6.165  4.395  6.912  6.902
   32  5000  8.800  4.362  8.793  8.809
   33  5000  8.156  4.463  8.145  8.193
   63  5000  9.727  4.364  9.709  9.716
   64  5000 11.828  4.023 11.810 11.798
   65  5000 10.726  4.489 10.654 10.725
  127  3920 12.144  4.292 12.281 12.268
  128  3829 13.829  4.484 13.807 13.841
  129  3741 12.986  4.438 12.964 12.985
  255   483 14.446  4.571 14.462 14.442
  256   477 15.738  4.707 15.744 15.738
  257   472 13.981  4.565 13.995 13.990
  51160 14.954  4.674 14.977 14.933
  51259 16.120  4.840 16.137 16.062
  51359 14.488  4.392 14.497 14.490
 1023 7 15.011  3.573 15.021 14.995
 1024 7 15.938  3.489 15.947 15.938
 1025 7 14.670  3.568 14.683 14.627

With library-side switching
(https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01810.html):

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  5000  0.067  0.080  0.053  0.067
3  5000  0.192  0.226  0.159  0.192
4  5000  0.427  0.436  0.364  0.431
5  5000  0.588  0.664  0.543  0.621
7  5000  0.938  0.914  0.926  1.011
8  5000  1.589  1.235  1.558  1.671
9  5000  1.704  1.486  1.694  1.810
   15  5000  2.638  2.175  2.854  3.031
   16  5000  4.234  2.532  4.533  4.745
   17  5000  4.374  3.044  4.677  4.839
   31  5000  6.207  4.401  6.891  6.918
   32  5000  8.824  4.364  8.614  8.603
   33  5000  7.954  4.349  7.945  7.944
   63  5000  8.802  4.369  9.728  9.764
   64  5000 11.845  4.025 11.783 11.849
   65  5000 10.753  4.595 10.719 10.753
  127  3920 12.023  4.314 12.285 12.004
  128  3829 13.427  4.369 13.722 13.742
  129  3741 12.877  4.323 12.668 12.985
  255   483 14.398  4.453 14.336 13.496
  256   477 15.708  4.680 15.711 15.465
  257   472 13.977  4.439 13.965 13.977
  51160 14.920  4.691 14.937 14.939
  51259 15.959  4.787 16.084 16.082
  51359 14.444  4.636 14.464 14.452
 1023 7 14.978  3.448 14.979 14.980
 1024 7 15.903  3.640 15.900 15.905
 1025 7 14.638  3.464 14.626 14.636

With stock trunk:

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  5000  0.072  0.078  0.053  0.072
3  5000  0.199  0.224  0.

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[cmacmackin at gmail dot com]

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

--- Comment #6 from Chris  ---
> Which one do you mean exactly? Shouldn't they all use the user-defined 
> assignment function?

Yes, that's right--they all should. Sorry, I didn't have the code up in front
of me when I wrote that so I was a bit imprecise in what I was saying.

[Bug target/77599] M68K: __builtin_bswap32() isn't compiled correctly with -mshort

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #2 from Jeffrey A. Law  ---
The problem here is you're using -mshort  on *-linux-gnu which IMHO is invalid.


Linux defines int32_t as a "int".  And -mshort changes the width of an int to
16 bits, at which point anything prototyped using int32_t has just changed its
ABI in a meaningful way (similarly for uint32_t, but unsigned).  You can see
this in the .optimized dump file:

x (long unsigned int y)
{
  unsigned int _1;
  unsigned int _2;
  long unsigned int _4;

;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  _1 = (unsigned int) y_3(D);
  _2 = __builtin_bswap32 (_1);
  _4 = (long unsigned int) _2;
  return _4;
}

Note the type of the _1 and _2.  They are both unsigned ints, so 16 bits. 


If you try this test on a bare metal target such as m68k-elf or without the
-mshort, you'll get the expected and desired result.

[Bug target/77600] M68K: gcc generates rubbish with -mshort

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #2 from Jeffrey A. Law  ---
This is a similar issue as I outlined in the other m68k -mshort BZ.  This time
we need to look at how INTPTR_TYPE, which is defined in terms of
LONG_TYPE_SIZE.   When LONG_TYPE_SIZE == 32, INTPTR_TYPE will be an "int"
-mshort changes the size of an int from 32 to 16 bits.

Thus conversions to/from sizetype are going to do things you don't expect
unless you know sizetype is 16 bits.

Again, if you configure for a bare metal target such as m68k-elf or avoid using
-mshort on your linux target, you'll get the desired and expected result.

[Bug c/78408] New: Aggressive optimization of zeroing results in incorrect behavior

[npmccallum at redhat dot com]

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

Bug ID: 78408
   Summary: Aggressive optimization of zeroing results in
incorrect behavior
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npmccallum at redhat dot com
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)

Compiling the file uses this command line:

gcc -DPACKAGE_NAME=\"clevis\" -DPACKAGE_TARNAME=\"clevis\"
-DPACKAGE_VERSION=\"1\" -DPACKAGE_STRING=\"clevis\ 1\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"\" -DPACKAGE=\"clevis\" -DVERSION=\"1\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -I.-Wall -Wextra -Werror -Wstrict-aliasing
-Wchar-subscripts -Wformat-security -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wshadow -Wsign-compare -Wstrict-prototypes
-Wtype-limits -Wno-missing-field-initializers -Wno-unused-parameter  -pthread
-I/usr/include/udisks2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-DCLEVIS_CMD_DIR=/usr/libexec/clevis -g -O2 -MT clevis-luks-udisks2.o -MD -MP
-MF $depbase.Tpo -c -o clevis-luks-udisks2.o clevis-luks-udisks2.c

The relevant code is here[1].

GCC sees that "pkt_t key" might go out of scope and therefore optimizes out the
zeroing of the struct that occurs at the end of the for loop iteration.
However, key doesn't go out of scope during loop iteration. Thus, on subsequent
loops the struct is used presuming that it contains a zero value but it
doesn't. This means that (what I take to be) perfectly valid ISO C behaves in
strange ways.

In particular, the bug that arises is as follows. When load_jwe() fails[2], the
(incorrectly) presumed zeroed key struct is sent[3] to the client. The end
result is that an invalid key (the previous successful one) is sent when an
empty UDP packet should be sent.

GCC should detect that "pkt_t key" is not going out of scope and should zero it
as requested rather than invalidly optimizing out this statement. Clang does
not have this bug, so there is at least one example of a compiler doing the
right thing.

[1] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L446
[2] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L455
[3] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L469

[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
Tracking via 68467.  What we really need here is a .i file we can feed back
into the compiler for debugging purposes.

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

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||baker at usgs dot gov

--- Comment #4 from Jeffrey A. Law  ---
*** Bug 53833 has been marked as a duplicate of this bug. ***

[Bug libgcc/78409] New: Segfault in classify_object_over_fdes when throwing and exception

[orion at cora dot nwra.com]

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

Bug ID: 78409
   Summary: Segfault in classify_object_over_fdes when throwing
and exception
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orion at cora dot nwra.com
  Target Milestone: ---

Running on Fedora rawhide with gcc-6.2.1-2.fc26

Core was generated by
`/home/orion/fedora/octave/octave-4.2.0/src/.libs/lt-octave-gui --no-init-path
-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  classify_object_over_fdes (ob=ob@entry=0x7f3a4d3d4910,
this_fde=0x7f3a6f220018)
at ../../../libgcc/unwind-dw2-fde.c:613
613   for (; ! last_fde (ob, this_fde); this_fde = next_fde (this_fde))
(gdb) print ob
$1 = (struct object *) 0x7f3a4d3d4910
(gdb) print this_fde
$2 = (const fde *) 0x7f3a6f220018
(gdb) print *this_fde
Cannot access memory at address 0x7f3a6f220018
(gdb) print *ob
$3 = {pc_begin = 0x, tbase = 0x0, dbase = 0x0, u = {single =
0x7f3a6f220018,
array = 0x7f3a6f220018, sort = 0x7f3a6f220018}, s = {b = {sorted = 0,
from_array = 0,
  mixed_encoding = 0, encoding = 255, count = 0}, i = 2040}, next =
0x7f3a4d3c3580}
(gdb) print *(fde *)0x7f3a6f220018
Cannot access memory at address 0x7f3a6f220018

(gdb) bt
#0  0x7f3a6ba7235e in classify_object_over_fdes
(ob=ob@entry=0x7f3a4d3d4910, this_fde=0x7f3a6f220018) at
../../../libgcc/unwind-dw2-fde.c:613
#1  0x7f3a6ba72859 in init_object (ob=0x7f3a4d3d4910)
at ../../../libgcc/unwind-dw2-fde.c:749
#2  0x7f3a6ba72859 in search_object (ob=ob@entry=0x7f3a4d3d4910,
pc=pc@entry=0x7f3a6ba7125d <_Unwind_RaiseException+61>) at
../../../libgcc/unwind-dw2-fde.c:961
#3  0x7f3a6ba730f6 in _Unwind_Find_registered_FDE (bases=0x7f3a516fd2c8,
pc=0x7f3a6ba7125d <_Unwind_RaiseException+61>) at
../../../libgcc/unwind-dw2-fde.c:1025
#4  0x7f3a6ba730f6 in _Unwind_Find_FDE (pc=0x7f3a6ba7125d
<_Unwind_RaiseException+61>, bases=bases@entry=0x7f3a516fd2c8) at
../../../libgcc/unwind-dw2-fde-dip.c:454
#5  0x7f3a6ba6fb93 in uw_frame_state_for
(context=context@entry=0x7f3a516fd220, fs=fs@entry=0x7f3a516fd070) at
../../../libgcc/unwind-dw2.c:1241
#6  0x7f3a6ba70db0 in uw_init_context_1
(context=context@entry=0x7f3a516fd220,
outer_cfa=outer_cfa@entry=0x7f3a516fd5d0, outer_ra=0x7f3a6c2464cc
<__cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*))+92>) at
../../../libgcc/unwind-dw2.c:1562
#7  0x7f3a6ba7125e in _Unwind_RaiseException (exc=exc@entry=0x7f3a4c5e7470)
at ../../../libgcc/unwind.inc:88
#8  0x7f3a6c2464cc in __cxxabiv1::__cxa_throw(void*, std::type_info*, void
(*)(void*)) (obj=obj@entry=0x7f3a4c5e7490, tinfo=0x7f3a6f10f320 ,
tinfo@entry=0x7f3a6ebd4a98 ,
dest=dest@entry=0x7f3a6e1849e0
)
at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:82
#9  0x7f3a6e39a5ce in error_1(octave::execution_exception &, std::ostream
&, const char *, const char *, const char *, typedef __va_list_tag
__va_list_tag *, bool) (e=..., os=..., name=name@entry=0x7f3a6e7a1625 "error",
id=id@entry=0x7f3a6e796b04 "", fmt=,
fmt@entry=0x7f3a6e79b3f7 "%s: unknown %s property %s",
args=args@entry=0x7f3a516fd710, with_cfn=false) at
libinterp/corefcn/error.cc:512
#10 0x7f3a6e39a73e in error_1(std::ostream &, const char *, const char *,
const char *, typedef __va_list_tag __va_list_tag *, bool) (os=...,
name=name@entry=0x7f3a6e7a1625 "error", id=id@entry=0x7f3a6e796b04 "",
fmt=0x7f3a6e79b3f7 "%s: unknown %s property %s",
args=args@entry=0x7f3a516fd710, with_cfn=with_cfn@entry=false) at
libinterp/corefcn/error.cc:522
#11 0x7f3a6e39a797 in verror(char const*, __va_list_tag*) (fmt=, args=args@entry=0x7f3a516fd710) at libinterp/corefcn/error.cc:528
#12 0x7f3a6e39a839 in error(char const*, ...) (fmt=fmt@entry=0x7f3a6e79b3f7
"%s: unknown %s property %s") at libinterp/corefcn/error.cc:536
#13 0x7f3a6e41f28d in validate_property_name(std::__cxx11::string const&,
std::__cxx11::string const&, std::set, std::allocator >,
std::less,
std::allocator > >, std::allocator, std::allocator > > > const&, caseless_str const&)
(who="get", what="axes", pnames=std::set with 142 elements = {...}, pname=...)
at libinterp/corefcn/graphics.cc:101


(gdb) up
#1  0x7f3a6ba72859 in init_object (ob=0x7f3a4d3d4910)
at ../../../libgcc/unwind-dw2-fde.c:749
749   count = classify_object_over_fdes (ob, ob->u.single);
(gdb) print *ob
$5 = {pc_begin = 0x, tbase = 0x0, dbase = 0x0, u = {single =
0x7f3a6f220018,
array = 0x7f3a6f220018, sort = 0x7f3a6f220018}, s = {b = {sorted = 0,
from_array = 0,
  mixed_encoding = 0, encoding = 255, count = 0}, i = 2040}, next =
0x7f3a4d3c3580}

[Bug ada/48835] porting GNAT to m68k-linux

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #59 from Jeffrey A. Law  ---
All the issues in this BZ should be addressed on the trunk.  Any further GNAT
problems on m68k should be tracked with a new BZ.

Let's avoid mega-bugs like this in the future -- instead track each distinct
problem as a distinct bug so that it's relatively easy to know the state of a
given issue.

When many bugs are blocking a single larger issue (like we've seen with this
BZ), open a bug for the large issue and make it dependent upon the individual
bugs.

[Bug tree-optimization/69270] DOM should exploit range information to create more equivalences

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
The test failure is being tracked in bug 72850.

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Do you think you could produce a smaller, stand-alone testcase that reproduces
the issue? Or at least attach the preprocessed sources to the report?

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
I did apply your second patch:

I do not get any improvement and results are diminished from current trunk, so
I am missing something. This is same machine I used showing results in 51119.
It does have avx.

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf
eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave
avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext
perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter
pfthreshold

$ gfc -static-libgfortran -finline-matmul-limit=0 -Ofast -o compare_mavx
compare.f90
$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  5.043  0.045  0.091  0.150
4  2000  1.417  0.235  0.353  0.325
8  2000  2.016  0.634  0.862  2.021
   16  2000  5.332  2.834  2.239  2.929
   32  2000  6.169  3.496  1.931  3.289
   64  2000  2.656  2.836  2.655  2.657
  128  2000  2.898  3.286  2.901  2.901
  256   477  3.157  3.429  3.156  3.157
  51259  3.082  2.356  3.133  3.126
 1024 7  3.102  1.363  3.144  3.136
 2048 1  3.099  1.685  3.144  3.140

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
Author: thopre01
Date: Thu Nov 17 20:12:13 2016
New Revision: 242559

URL: https://gcc.gnu.org/viewcvs?rev=242559&root=gcc&view=rev
Log:
Fix PR77933: stack corruption on ARM when using high registers and LR

2016-11-17  Thomas Preud'homme  

gcc/
PR target/77933
* config/arm/arm.c (thumb1_expand_prologue): Distinguish between lr
being live in the function and lr needing to be saved.  Distinguish
between already saved pushable registers and registers to push.
Check for LR being an available pushable register.

gcc/testsuite/
PR target/77933
* gcc.target/arm/pr77933-1.c: New test.
* gcc.target/arm/pr77933-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr77933-1.c
trunk/gcc/testsuite/gcc.target/arm/pr77933-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog