[Bug tree-optimization/78210] [7 regression] slsr-8.c scan-tree-dump-times optimized fails

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
I confirm the problem is now fixed.

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[venkataramanan.kumar at amd dot com]

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

--- Comment #4 from Venkataramanan  ---
Created attachment 39976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39976&action=edit
Test case for noncanonical gimple formation at tree if conversion.

The test case is simulated from primal_bea_mpp of 429.mcf.

gcc version 7.0.0 20161106

 snip from test.c.155t.ifcvt
;;   basic block 30, loop depth 1, count 0, freq 407, maybe hot
;;prev block 29, next block 31, flags: (NEW, REACHABLE, VISITED)
;;pred:   28 [64.0%]  (FALSE_VALUE,EXECUTABLE)
  _96 = _67 == 2;
  _29 = if_conversion_var_66 > 0;
  _12 = _96 & _29; <== Non canonical gimple
  if (_12 != 0)
goto ;
  else
goto ;
-snip ends-

[Bug middle-end/78224] ICE at -O2(-O1 on gcc6) and above in verify_loop_structure, at cfgloop.c:1646

[rimvydas.jas at gmail dot com]

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

--- Comment #1 from Rimvydas (RJ)  ---
Same ICE+segv is triggered at -O2 on:
gcc version 4.9.2 (Debian 4.9.2-10)
gcc version 4.8.5 (SUSE Linux)

Works fine at -O3 on:
$ CCVER=gcc47 g++ -v
Using built-in specs.
COLLECT_GCC=/usr/libexec/gcc47/g++
Target: x86_64-pc-dragonflybsd
Configured with: DragonFly/x86_64 system compiler (c, c++, objc, LTO)
Thread model: posix
gcc version 4.7.4 [DragonFly] Release/2014-06-12

[Bug target/78230] Compile pr66178.c fail for mips64el-elf with N64 abi

[npickito at gmail dot com]

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

--- Comment #2 from Kito Cheng  ---
Ya, In fact I am working on RISV-V 64, and it's seem cause by
TRULY_NOOP_TRUNCATION (32, 64) == false.

[Bug target/78230] Compile pr66178.c fail for mips64el-elf with N64 abi

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely the testcase fails on all LP64 targets.

[Bug c/78230] New: Compile pr66178.c fail for mips64el-elf with N64 abi

[npickito at gmail dot com]

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

Bug ID: 78230
   Summary: Compile pr66178.c fail for mips64el-elf with N64 abi
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npickito at gmail dot com
  Target Milestone: ---

Configure:
--with-abi=64 --target=mips64el-elf

$ mips64el-elf-gcc  pr66178.c 
pr66178.c: In function ‘test’:
pr66178.c:3:21: error: initializer element is not computable at load time
 static int a =  ((char *)&&l1-(char *)&&l2)-1;
 ^

[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 #16 from Bill Schmidt  ---
Created attachment 39975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39975&action=edit
WIP patch for outer-loop vectorization

[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 #15 from Bill Schmidt  ---
(In reply to rguent...@suse.de from comment #14)
> On November 5, 2016 4:31:54 PM GMT+01:00, "wschmidt at gcc dot gnu.org"
>  wrote:
> 
> >Notable degradations:
> >  403.gcc: -1.8%
> >
> >Other results in noise (+/- 1.0%)
> >
> >Thus, not too bad for a simple patch, though we don't like seeing
> >403.gcc
> >degrade.
> 
> Analyzing would be useful, I suspect missed RTL if-conversion opportunities.

Agreed; however, I may not be able to get to that this week, unfortunately.

> 
> >I've made some progress on the outer loop vectorization issue, but
> >haven't
> >completely solved it yet.  I'll try to have something to look at there
> >in the
> >next couple of days.
> 
> I'd try detecting the outer loop vect CFG shape the vectorizer handles in
> if-combersion and then simply version the outer loop...  Of course needs
> handling of the VECTORIZED conditional on an outer loop in the vectorizer.

Right, that's the direction I've been exploring.  Unfortunately the loop
analysis seems pretty dependent on the shape, and things get ugly inside
vect_mark_stmts_to_be_vectorized.  Eventually I run into the following that
defeats outer loop vectorization:

/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: def_stmt: curr_a_20 = PHI 
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: type of def: unknown
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: Unsupported pattern.
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: not vectorized: unsupported use in stmt.
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: unexpected pattern.

Here the PHI in question is in the loop header for the inner unoptimized loop,
which is unexpected by the analysis and becomes vect_unknown_def_type.  Thus we
hit the "Unsupported pattern" in vect_is_simple_use and we're done.

I tried an egregious hack to just ignore such PHIs in nested loops to see what
would happen.  We end up blowing up deep in the analyze_overlapping_iterations
code during data-ref analysis.

I'm somewhat at a dead end here, so I'll attach the patch thus far and call it
a night.  I'd appreciate any thoughts on any better direction.  The hunk in
vect_is_simple_use is the egregious hack; it needs to be removed before the
test case will compile.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

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

--- Comment #16 from Dmitry Vyukov  ---
> The stack size limit in my box is 8M. I have also checked /proc/limits.

So, is increasing stack size help?
Tsan increases stack consumption. 8MB is not that much provided that you have
1MB frames.

> By enabling -fstack-protector-all, in gdb it still may get segfault here (at 
> function entry).

Stack protector will not help to detect/prevent stack overflow. It only
prevents PC overwrite on buffer overflows.

[Bug rtl-optimization/78229] New: [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[doko at gcc dot gnu.org]

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

Bug ID: 78229
   Summary: [6/7 Regression]  ICE in redirect_eh_edge_1, at
tree-eh.c:2305
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with gcc-6-branch 20161103 r241817, works with -O1 instead of -O2, test
case extracted from blender 2.77:

$ g++ -mavx -mavx2 -mfma -mlzcnt -mbmi -mbmi2 -mf16c -c -O2 -fopenmp -fPIC
-funsigned-char -fno-strict-aliasing -ffast-math kernel_avx2.ii
kernel_avx2.ii: In function 'void fn3()':
kernel_avx2.ii:8:6: internal compiler error: in redirect_eh_edge_1, at
tree-eh.c:2305
 void fn3() {
  ^~~
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat kernel_avx2.ii
void a();
inline int b(int c) {
  int d = c;
  return __builtin_ia32_tzcnt_u32(d);
}
struct e {};
int f, g, h;
void fn3() {
  float j;
  &j;
  {
e k;
while (h) {
  if (g == 0)
continue;
  int i = b(g);
  f = i;
}
a();
  }
}

[Bug target/78227] ICE: unrecognizable insn: in extract_insn, at recog.c:2311 with -mavx512bw and vector comare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/78227] ICE: unrecognizable insn: in extract_insn, at recog.c:2311 with -mavx512bw and vector comare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
ICEs starting with r213811 when -mavx512bw option has been introduced.

[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
Could you please mail me the back ports?

Dominique

> Le 6 nov. 2016 à 22:35, iains at gcc dot gnu.org  a 
> écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710
> 
> --- Comment #11 from Iain Sandoe  ---
> posted;
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00545.html
> I have backports for 6.x and 5.x
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
posted;
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00545.html
I have backports for 6.x and 5.x

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov  6 21:27:32 2016
New Revision: 241887

URL: https://gcc.gnu.org/viewcvs?rev=241887&root=gcc&view=rev
Log:
2016-11-06  Thomas Koenig  

PR fortran/78226
resolve.c (build_loc_call): Add location to return value.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug middle-end/78228] [6/7 Regression] fstrict-overflow breaks code without overflow?

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|c   |middle-end
  Known to work||5.4.0
   Target Milestone|--- |6.3
Summary|fstrict-overflow breaks |[6/7 Regression]
   |code without overflow?  |fstrict-overflow breaks
   ||code without overflow?
  Known to fail||6.2.0

[Bug c/78228] fstrict-overflow breaks code without overflow?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely
If (i>0) i=-i;
Is being turned into -abs (i). Which means it should be turned into uabs
instead.

[Bug c/78228] New: fstrict-overflow breaks code without overflow?

[adl at gnu dot org]

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

Bug ID: 78228
   Summary: fstrict-overflow breaks code without overflow?
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adl at gnu dot org
  Target Milestone: ---

I'm compiling for x86_64.

These two functions used to work fine in gcc-5.4.1, but behave incorrectly with
gcc-6.2 when optimizations are turned on.  

The job is to compute the number of characters needed to display a signed
integer when represented in base 10.  Assuming int is 32bits, this is most
efficiently done using a series of comparisons (int_width_7) that can even be
vectorized (int_width_8).  Positive input values are negated before the
comparisons start; working with negative values instead of positive values is a
way to *avoid* signed overflow when processing INT_MIN.

Because i = -i is the only operation done on int, and it is only applied to
positive values, I don't think there is any undefined behavior in the following
code, isn't it?

#include 
#include 

__attribute__((noinline))
unsigned int_width_7(int i)
{
  unsigned width = i < 0;
  if (i > 0)
i = -i;
  if (i <= -10)
return width + 10;
  if (i <= -1)
return width + 9;
  if (i <= -1000)
return width + 8;
  if (i <= -100)
return width + 7;
  if (i <= -10)
return width + 6;
  if (i <= -1)
return width + 5;
  if (i <= -1000)
return width + 4;
  if (i <= -100)
return width + 3;
  if (i <= -10)
return width + 2;
  return width + 1;
}

__attribute__((noinline))
unsigned int_width_8(int i)
{
  unsigned width = i < 0;
  if (i > 0)
i = -i;

  static const int v[] = { -10, -1, -1000, -100,
   -10, -1, -1000, -100, -10, 0 };
  for (int vi = 0; vi < sizeof(v)/sizeof(*v); ++vi)
width += (i <= v[vi]);
  return width;
}


int main()
{
  printf("%d %d\n", int_width_7(INT_MIN), int_width_8(INT_MIN));
}


% gcc-6 -Wall -O foo.c && ./a.out
11 11
% gcc-6 -Wall -O2 foo.c && ./a.out
2 11
% gcc-6 -Wall -O3 foo.c && ./a.out
2 10


The changes between -O and -O2 seems to be due to -fstrict-overflow:

% gcc -Wall -O -fstrict-overflow foo.c && ./a.out
2 11



Looking into the assembly generated code for int_width_7, we can see that the
following -O output 

int_width_7:
.LFB11:
.cfi_startproc
movl%edi, %eax
shrl$31, %eax
movl%edi, %edx
sarl$31, %edx
xorl%edx, %edi
subl%edi, %edx
cmpl$-9, %edx
jl  .L12
cmpl$-, %edx
jl  .L13
cmpl$-999, %edx
jl  .L14
cmpl$-99, %edx
jl  .L15
cmpl$-9, %edx
jl  .L16
cmpl$-, %edx
jl  .L17
cmpl$-999, %edx
jl  .L18
cmpl$-99, %edx
jl  .L19
leal1(%rax), %ecx
addl$2, %eax
cmpl$-10, %edx
cmovg   %ecx, %eax
ret


becomes as follows once compiled with -O -fstrict-overflow:

int_width_7:
.LFB11:
.cfi_startproc
movl%edi, %eax
shrl$31, %eax
movl%edi, %edx
sarl$31, %edx
xorl%edx, %edi
subl%edx, %edi
cmpl$9, %edi
jg  .L12
cmpl$, %edi
jg  .L13
cmpl$999, %edi
jg  .L14
cmpl$99, %edi
jg  .L15
cmpl$9, %edi
jg  .L16
cmpl$, %edi
jg  .L17
cmpl$999, %edi
jg  .L18
cmpl$99, %edi
jg  .L19
leal2(%rax), %edx
addl$1, %eax
cmpl$10, %edi
cmovge  %edx, %eax
ret


Somehow, gcc decided to work with positive integers instead, even though that
cannot work MIN_INT?

I have not looked at the problem with int_width_8 in details: I can see that
the constants are still negative, yet the result is clearly incorrect.

[Bug target/78227] New: ICE: unrecognizable insn: in extract_insn, at recog.c:2311 with -mavx512bw

[zsojka at seznam dot cz]

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

Bug ID: 78227
   Summary: ICE: unrecognizable insn: in extract_insn, at
recog.c:2311 with -mavx512bw
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mavx512bw testcase.c 
testcase.c: In function 'foo':
testcase.c:7:1: error: unrecognizable insn:
 }
 ^
(insn 8 7 9 2 (set (reg:V32HI 87 [ _2 ])
(unspec:SI [
(reg:V32HI 90)
(reg:V32HI 89)
] UNSPEC_MASKED_GT)) "testcase.c":6 -1
 (nil))
testcase.c:7:1: internal compiler error: in extract_insn, at recog.c:2311
0xb62d03 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0xb62d9b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:116
0xb18967 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2311
0x8ca4bd instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.c:1581
0x8ca4bd instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.c:1948
0x8ca4bd execute
/repo/gcc-trunk/gcc/function.c:1997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-241681-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-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 --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-241681-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161029 (experimental) (GCC)

[Bug fortran/69544] [5/6/7 Regression] Internal compiler error with -Wall and where

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug fortran/69544] [5/6/7 Regression] Internal compiler error with -Wall and where

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov  6 20:30:31 2016
New Revision: 241886

URL: https://gcc.gnu.org/viewcvs?rev=241886&root=gcc&view=rev
Log:
2016-11-06  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* gfortran.dg/where_5.f90:  New test.
* gfortran.dg/where_6.f90:  New test.

2016-11-06  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* match.c (match_simple_where):  Fill in locus for assigment
in simple WHERE statement.
(gfc_match_where):  Likewise.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/where_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/where_6.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/match.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/78178] ICE in WHERE statement with diagnostic

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov  6 20:30:31 2016
New Revision: 241886

URL: https://gcc.gnu.org/viewcvs?rev=241886&root=gcc&view=rev
Log:
2016-11-06  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* gfortran.dg/where_5.f90:  New test.
* gfortran.dg/where_6.f90:  New test.

2016-11-06  Thomas Koenig  

Backport from trunk
PR fortran/69544
PR fortran/78178
* match.c (match_simple_where):  Fill in locus for assigment
in simple WHERE statement.
(gfc_match_where):  Likewise.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/where_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/where_6.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/match.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[iains at gcc dot gnu.org]

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

--- Comment #29 from Iain Sandoe  ---

posted 
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00541.html

I have backports for 6.x and 5.x if wanted.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #44 from Iain Sandoe  ---
posted:

https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00536.html
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00537.html
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00538.html
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00539.html
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00540.html

I have back-ports to 6.x and 5.x if anyone needs then urgently

[Bug fortran/78226] New: Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

Bug ID: 78226
   Summary: Fill out location information everywhere
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39973&action=edit
Patch to expose missing locations

It would be nice if we could consistently fill in the
location information everywhere. Missing information can
lead to bugs such as PR 69544.

I have made a separate front-end pass for finding pieces
of code where location information is not filled in
(see attachment). With this, it is rather easy to find
the offending pieces of code (sometimes less easy to
find where the location should have been set :-)

Once we have a trunk that passes cleanly with this patch,
we could then include something this pass (but only when
--enable-checking=yes is active) to make sure that when
a new piece of code is added, people don't forget the
location information.  The gfc_warning_now calls at the
moment are there so that a) the testsuite fails and b)
I can still get a dump with -fdump-fortran-original.
These would probably be changed to gfc_internal_error.

[Bug middle-end/78225] New: [7 Regression] FAIL: gcc.dg/gomp/pr27573.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 78225
   Summary: [7 Regression] FAIL: gcc.dg/gomp/pr27573.c (internal
compiler error)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdir
/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/gomp/pr27573.c   
-fno-diagnost
ics-show-caret -fdiagnostics-color=never   -O2 -fopenmp -fprofile-generate -S
-o 
pr27573.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objd
ir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/gomp/pr27573.c
-fno-diagnosti
cs-show-caret -fdiagnostics-color=never -O2 -fopenmp -fprofile-generate -S -o
pr2
7573.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/gomp/pr27573.c: In function
'main._om
p_fn.0':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/gomp/pr27573.c:12:9: internal
compile
r error: in convert_memory_address_addr_space_1, at explow.c:284
0x122187 convert_memory_address_addr_space_1(machine_mode, rtx_def*, unsigned
cha
r, bool, bool)
../../gcc/gcc/explow.c:284
0x345883 convert_memory_address_addr_space_1(machine_mode, rtx_def*, unsigned
cha
r, bool, bool)
../../gcc/gcc/explow.c:386
0x345883 convert_memory_address_addr_space(machine_mode, rtx_def*, unsigned
char)
../../gcc/gcc/explow.c:385
0x231cf3 get_builtin_sync_mem../../gcc/gcc/builtins.c:4933
0x23211f expand_builtin_atomic_fetch_op../../gcc/gcc/builtins.c:5452
0x23d287 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:68580x36023b expand_expr_real_1(tree_node*,
rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)
../../gcc/gcc/expr.c:10773
0x361a57 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rt
x_def**, bool)
../../gcc/gcc/expr.c:8088
0x3699c3 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node
*)
../../gcc/gcc/expr.c:5548
0x36a93b expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:53170x258c5b expand_call_stmt
../../gcc/gcc/cfgexpand.c:2666
0x258c5b expand_gimple_stmt_1../../gcc/gcc/cfgexpand.c:3581
0x258c5b expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:37470x25a11b expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5754
0x25f5b3 execute
../../gcc/gcc/cfgexpand.c:6368
Please submit a full bug report,
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/gomp/pr27573.c (internal compiler error)
FAIL: gcc.dg/gomp/pr27573.c (test for excess errors)

dave@mx3210:~/gnu/gcc/objdir$ ./xgcc -B./ -v
-bash: ./xgcc: No such file or directory
dave@mx3210:~/gnu/gcc/objdir$ cd gcc
dave@mx3210:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa-linux-gnu
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--enable-multiarch --enable-linker-build-id --build=hppa-linux-gnu
--host=hppa-linux-gnu --target=hppa-linux-gnu
--prefix=/home/dave/opt/gnu/gcc/gcc-7 --with-local-prefix=/home/dave/opt/gnu
--enable-threads=posix --enable-__cxa_atexit --build=hppa-linux-gnu
--enable-clocale=gnu --enable-checking=release
--enable-languages=c,c++,objc,fortran,obj-c++,ada,lto,go
Thread model: posix
gcc version 7.0.0 20161105 (experimental) [trunk revision 241877] (GCC) 

r241785 was okay.

[Bug c++/78224] New: ICE at -O2(-O1 on gcc6) and above in verify_loop_structure, at cfgloop.c:1646

[rimvydas.jas at gmail dot com]

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

Bug ID: 78224
   Summary: ICE at -O2(-O1 on gcc6) and above in
verify_loop_structure, at cfgloop.c:1646
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Created attachment 39972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39972&action=edit
bare minimum testcase, to show ICE

Attached is reduced testcase of failing voxelands port compilation.

$ g++-trunk -v
Reading specs from /zzz/gcc/gcc_git/build/gcc/specs
COLLECT_GCC=/zzz/gcc/gcc_git/build/gcc/xg++
COLLECT_LTO_WRAPPER=/zzz/gcc/gcc_git/build/gcc/lto-wrapper
Target: x86_64-unknown-dragonfly4.7
Configured with: ../configure --enable-bootstrap --disable-multilib
--disable-nls --enable-gnu-indirect-function
--enable-languages=c,c++,fortran,lto,objc --enable-threads=posix
--enable-libquadmath --with-system-zlib --with-as=/usr/local/bin/as
--with-ld=/usr/local/bin/ld --disable-libgcj --disable-libcilkrts
Thread model: posix
gcc version 7.0.0 20161106 (experimental) [trunk revision
ddd81c4:9ac4416:5055cc9834c33b5a7b9ec57194454c9b558dbf25] (GCC)

$ g++-trunk -c testcase6.cpp -O1
$ g++-trunk -c testcase6.cpp -O2
testcase6.cpp: In function 'void the_game(float)':
testcase6.cpp:35:6: error: loop with header 3 not in loop tree
 void the_game(float turn_amount)
  ^~~~
testcase6.cpp:35:6: internal compiler error: in verify_loop_structure, at
cfgloop.c:1646
0x9660c7 verify_loop_structure()
../../gcc/cfgloop.c:1646
0xbf1121 checking_verify_loop_structure
../../gcc/cfgloop.h:611
0xbf1121 loop_optimizer_init(unsigned int)
../../gcc/loop-init.c:128
0xefd2ba tree_ssa_cs_elim
../../gcc/tree-ssa-phiopt.c:116
0xefd2ba execute
../../gcc/tree-ssa-phiopt.c:2500
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.

Exact same ICE happen with gcc5 -O2 and gcc6 -01.

_# /usr/local/gcc6-aux/bin/g++ -c testcase6.cpp 
_# /usr/local/gcc6-aux/bin/g++ -c testcase6.cpp -O1
testcase6.cpp: In function 'void the_game(float)':
testcase6.cpp:35:6: internal compiler error: Segmentation fault
 void the_game(float turn_amount)
  ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

gcc6 behaves the same on Arch linux(gcc version 6.2.1 20160830 (GCC)).

[Bug fortran/50069] FORALL fails on a character array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||lkrupp at gcc dot gnu.org

--- Comment #8 from Dominique d'Humieres  ---
Related to pr55086, but the two tests are not fixed by the patch at
https://gcc.gnu.org/ml/fortran/2016-10/msg00228.html even when compiled with
the option -fforce-forall-temp.

[Bug fortran/70601] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|WAITING |NEW
 CC||janus at gcc dot gnu.org

[Bug fortran/77596] [F03] procedure pointer with implicit interface in type pointing to a function can be 'called'

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |NEW
 CC||janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to toK from comment #0)
> I guess that in an ideal world, the compiler should generate code to cause a
> run-time error in a situation like in the following snippet:

It should already be rejected at compile time, I think. When using "implicit
none", a "procedure(), pointer" can only point to a subroutine, IIRC.


Slightly modified example (with a plain procedure pointer instead of a PPC):


program xxx
  implicit none
  call ass()

contains

  function ff(x)
integer, intent(in) :: x
integer :: ff
print *, ''
  end function ff

  subroutine ass()
procedure(), pointer :: fp
fp=>ff
call fp(3)
  end subroutine ass

end program xxx


This is correctly rejected with:

 fp=>ff
1
Error: Interface mismatch in procedure pointer assignment at (1): 'ff' is not a
subroutine

[Bug driver/70419] descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

[balint at balintreczey dot hu]

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

--- Comment #2 from Balint Reczey  ---
(In reply to Balint Reczey from comment #1)
> Also please fix the error message emitted when trying to link a non-PIE
> non-PIC static library to a position independent executable:
> 
> $ cat m.c
> #include 
> 
> int main() {
>   gzopen(0,0);
>   return 1;
> }
> 
> $gcc -pie m.c -lz
> /usr/bin/ld: /tmp/cchMINoQ.o: relocation R_X86_64_PC32 against undefined
> symbol `gzopen' can not be used when making a shared object; recompile with
> -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> $ gcc --version
> gcc (Debian 6-20160228-1) 6.0.0 20160228 (experimental) [trunk revision
> 233789]
> 
> One better error message could be:
> `gzopen' can not be used when making a position independent executable;
> recompile with -fPIC or -fPIE
> 
> I can open a separate bug for that but this is closely related to the
> clarifications asked here.

The correct myself the error was about not compiling m.c with -fPIE but the
error is still misleading.

The fix is the following, compiling as PIE, linking with shared libz:
$gcc -pie -fPIE  m.c -lz

The other misleading error message about the static library lacking -fPIE can
be triggered this way:
$ gcc -pie -fPIE  m.c  /usr/lib/x86_64-linux-gnu/libz.a
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libz.a(gzlib.o): relocation R_X86_64_32S
against `.rodata' can not be used when making a shared object; recompile with
-fPIC
/usr/lib/x86_64-linux-gnu/libz.a: error adding symbols: Bad value

[Bug c++/78223] New: struct containing default member initializer fails constexpr test in aggregate initialization

[colu...@gmx-topmail.de]

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

Bug ID: 78223
   Summary: struct containing default member initializer fails
constexpr test in aggregate initialization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colu...@gmx-topmail.de
  Target Milestone: ---

constexpr struct X {
X const& x = *this; 
} y {{}};



This is valid as of core issue 1454's resolution.

[Bug driver/70419] descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

[balint at balintreczey dot hu]

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

Balint Reczey  changed:

   What|Removed |Added

 CC||balint at balintreczey dot hu

--- Comment #1 from Balint Reczey  ---
Also please fix the error message emitted when trying to link a non-PIE non-PIC
static library to a position independent executable:

$ cat m.c
#include 

int main() {
  gzopen(0,0);
  return 1;
}

$gcc -pie m.c -lz
/usr/bin/ld: /tmp/cchMINoQ.o: relocation R_X86_64_PC32 against undefined symbol
`gzopen' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
$ gcc --version
gcc (Debian 6-20160228-1) 6.0.0 20160228 (experimental) [trunk revision 233789]

One better error message could be:
`gzopen' can not be used when making a position independent executable;
recompile with -fPIC or -fPIE

I can open a separate bug for that but this is closely related to the
clarifications asked here.

[Bug middle-end/34475] TLS and PIE don't mix on x86_64

[balint at balintreczey dot hu]

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

Balint Reczey  changed:

   What|Removed |Added

 CC||balint at balintreczey dot hu

--- Comment #3 from Balint Reczey  ---
Seems to work with Debian Jessie's 4.9
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2

[Bug libstdc++/78156] constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length

[suokkos at gmail dot com]

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

--- Comment #3 from Pauli  ---
Could __builtin_constant_p help to select different code for compile time and
runtime?

Something like:

string_view(const _CharT* __str) :
  _M_len(/*null check*/__builtin_constant_p(__str /*or __str[0]?*/) ?
  recursive_strlen<_CharT>(__str) : /*or
traits_type::__constexpr_length()*/
  traits_type::length()),
  _M_str(__str)
{}

[Bug target/78222] New: target-tilegx: Incorrect bundle: let addli in y pipe

[gang.chen.5i5j at gmail dot com]

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

Bug ID: 78222
   Summary: target-tilegx: Incorrect bundle: let addli in y pipe
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gang.chen.5i5j at gmail dot com
  Target Milestone: ---
  Host: chroot ubuntu 15.10 under Android 5.1 x86_64
Target: tilegx
 Build: Just building, use the latest version

1. Version:

COLLECT_GCC=/upstream/build-gcc/./gcc/xgcc
COLLECT_LTO_WRAPPER=/upstream/build-gcc/./gcc/lto-wrapper
Target: tilegx-gchen-linux
Configured with: ../gcc/configure --target=tilegx-gchen-linux --disable-nls
--enable-languages=c --disable-threads --disable-shared --disable-libssp
--disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/upstream/release-tile --disable-multilib
--with-headers=/upstream/release-tile/include
Thread model: single
gcc version 7.0.0 20161105 (experimental) (GCC)


2. Contents of test.c:

typedef int DItype __attribute__ ((mode (DI)));
typedef unsigned int UTItype __attribute__ ((mode (TI)));

UTItype test (UTItype *rp)
{
  union
  {
DItype low;
UTItype ll;
  } uu, nn, dd, rr;

  UTItype w, r;
  DItype c1, c2, d0 = dd.low, n1 = nn.low;

  if (uu.low < 0)
c1 = ~c1, c2 = ~c2, uu.ll = -uu.ll;

  rr.low = n1 % d0;
  w = rr.ll;

  if (c1)
r = -r;
  if (c2)
r = -r;
  *rp = r;
  return w;
}


3. Compiling issue:

/upstream/build-gcc/./gcc/xgcc -B/upstream/build-gcc/./gcc/
-B/upstream/release-tile/tilegx-gchen-linux/bin/
-B/upstream/release-tile/tilegx-gchen-linux/lib/ -O2 -c test.c
-fnon-call-exceptions -save-temps

test.s: Assembler messages:
test.s:84: Error: Invalid combination of instructions for bundle.


4. Contents of output (test.s):

  1 .file   "test.c"
  2 .global __moddi3
  3 .text
  4 .align 8
  5 .global test
  6 .type   test, @function
  7 test:
  8 .LFB0:
  9 .cfi_startproc
 10 {
 11 st  sp, lr
 12 .cfi_offset 55, 0
 13 mover29, sp
 14 addir28, sp, -120
 15 }
 16 addisp, sp, -128
 17 .cfi_def_cfa_offset 128
 18 {
 19 st  r28, r29
 20 addir27, sp, 120
 21 addir26, sp, 112
 22 }
 23 {
 24 st  r27, r34
 25 .cfi_offset 34, -8
 26 addir25, sp, 104
 27 addir10, sp, 16
 28 }
 29 {
 30 st  r26, r33
 31 .cfi_offset 33, -16
 32 addir24, sp, 96
 33 addir11, sp, 48
 34 }
 35 {
 36 st  r25, r32
 37 .cfi_offset 32, -24
 38 addir27, r27, -32
 39 }
 40 ld  r10, r10
 41 st  r24, r31
 42 .cfi_offset 31, -32
 43 {
 44 ld  r1, r11
 45 addir11, sp, 32
 46 cmpltsi r12, r10, 0
 47 }
 48 {
 49 st  r27, r30
 50 .cfi_offset 30, -40
 51 mover30, r0
 52 }
 53 {
 54 ld  r0, r11
 55 movei   r11, -1
 56 }
 57 cmovnez r33, r12, r11
 58 {
 59 cmovnez r34, r12, r11
 60 jal __moddi3
 61 }
 62 {
 63 addir10, sp, 72
 64 mz  r31, r33, r31
 65 }
 66 {
 67 ld  r1, r10
 68 mz  r32, r33, r32
 69 }
 70 beqzr34, .L4
 71 {
 72 sub r31, zero, r31
 73 sub r32, zero, r32
 74 }
 75 cmpne   r10, r31, zero
 76 sub r32, r32, r10
 77 .L4:
 78 mover10, r30
 79 st_add  r10, r31, 8
 80 {
 81 st  r10, r32
 82 addir28, sp, 120
 83 addli   r29, sp, 128
 84 }
 85 {
 86 ld  r34, r28
 87 addir27, sp, 112
 88 addir26, sp, 104
 89 }
 90 {
 91 addir25, sp, 96
 92 addir28, r28, -32
 93 ld  lr, r29
 94 }
 95 ld  r33, r27
 96 ld  r32, r26
 97 ld  r31, r25
 98 ld  r30, r28
 99 {
100 addli   sp, sp, 128
101 .cfi_restore 54
102 .cfi_restore 30
103 .cfi_restore 31
104 .cfi_restore 32
105 .cfi_restore 33
106 .cfi_restore 34
107 .cfi_restore 55
108 .cfi_def_cfa_offset 0
109 jrp lr
110 }
111 .cfi_endproc
112 .LFE0:
113 .size   test, .-test
114 .ident  "GCC: (GNU) 7.0.0 20161105 (experimental)"
115 .section.note.GNU-stack,"",@progbits

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Conversion is done during the matching phase, so this is
when we warn.

The problem here, as with PR 67219, was that these warning
may be issued, and then the statement may be rejected.
If that happens, we should throw away the warning.
By using gfc_warning instead of gfc_warning_now, the
warning is first queued.

In this case, after matching the real part, a
comma is expected. When this is not encountered, the
warning is cleared, and the attempt at maching is finished.
This part was already installed as part of the fix for
PR 67219.

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[howarth.at.gcc at gmail dot com]

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

Jack Howarth  changed:

   What|Removed |Added

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

--- Comment #3 from Jack Howarth  ---
(In reply to Andrew Pinski from comment #2)
> GCC by default looks to /usr/local unless you use with-local-prefix option.

Actually on darwin this isn't that simple. If you use --with-local-prefix= set
to anything other than /usr/lcoal, a potential header/library mismatch
situation is made possible because the compiler no longer searches
/usr/local/include for headers bu the linker command does still search
/usr/local/lib. Fortunately, this glitch is trivial to solve without resorting
to the --with-local-prefix hack. The simple change...

--- gcc/incpath.c.bak   2015-01-05 07:33:28.0 -0500
+++ gcc/incpath.c   2016-11-06 07:25:20.0 -0500
@@ -256,7 +256,7 @@
   if (stat (cur->name, &st))
{
  /* Dirs that don't exist are silently ignored, unless verbose.  */
- if (errno != ENOENT)
+ if ((errno != ENOENT) && (errno != EPERM))
cpp_errno (pfile, CPP_DL_ERROR, cur->name);
  else
{

eliminates the compiler bootstrap failures and later compiler operation
failures when run under an Apple sandbox with file access to /usr/local denied.

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #6)
> This looks promising:

Indeed! I can confirm that this fixes the bogus warning on comment 0 and 4 and
also in a larger code base, where I first observed it (four-fold).

Thanks for the quick fix! That patch is ok for trunk and gcc-6 from my side.

Could you explain how/why it fixes the problem? Or where the problem came from
in the first place?

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov  6 12:27:51 2016
New Revision: 241884

URL: https://gcc.gnu.org/viewcvs?rev=241884&root=gcc&view=rev
Log:
2016-11-06  Thomas Koenig  

PR fortran/78221
* arith.c (gfc_complex2real):  Change gfc_warning_now to
gfc_warning.

2016-11-06  Thomas Koenig  

PR fortran/78221
* gfortran.dg/warn_conversion_9.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_conversion_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
This looks promising:

Index: arith.c
===
--- arith.c (Revision 241747)
+++ arith.c (Arbeitskopie)
@@ -2369,10 +2369,10 @@ gfc_complex2real (gfc_expr *src, int kind)
   /* See if we discarded an imaginary part.  */
   if (mpfr_cmp_si (mpc_imagref (src->value.complex), 0) != 0)
{
- gfc_warning_now (w, "Non-zero imaginary part discarded "
-  "in conversion from %qs to %qs at %L",
-  gfc_typename(&src->ts), gfc_typename (&result->ts),
-  &src->where);
+ gfc_warning (w, "Non-zero imaginary part discarded "
+  "in conversion from %qs to %qs at %L",
+  gfc_typename(&src->ts), gfc_typename (&result->ts),
+  &src->where);
  did_warn = true;
}

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

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On November 5, 2016 4:31:54 PM GMT+01:00, "wschmidt at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
>
>--- Comment #13 from Bill Schmidt  ---
>SPEC cpu2006 on powerpc64le-unknown-linux-gnu with the simple patch:
>
>Geomean, integer:  +0.2%
>Geomean, float:+0.5%
>Geomean, overall:  +0.4%
>
>Notable improvements:
>  454.calculix:+3.7%
>  453.povray:  +3.4%
>  458.sjeng:   +1.4%
>  429.mcf: +1.2%
>  445.gobmk:   +1.2%
>  471.omnetpp: +1.2%
>
>Notable degradations:
>  403.gcc: -1.8%
>
>Other results in noise (+/- 1.0%)
>
>Thus, not too bad for a simple patch, though we don't like seeing
>403.gcc
>degrade.

Analyzing would be useful, I suspect missed RTL if-conversion opportunities.

>I've made some progress on the outer loop vectorization issue, but
>haven't
>completely solved it yet.  I'll try to have something to look at there
>in the
>next couple of days.

I'd try detecting the outer loop vect CFG shape the vectorizer handles in
if-combersion and then simply version the outer loop...  Of course needs
handling of the VECTORIZED conditional on an outer loop in the vectorizer.

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
I have an idea where this comes from, and how to fix it.

Probably similar to PR 67219.

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> likely r224190 (pr47359).

Yes, that's the commit where Thomas introduced this warning. The new diagnostic
apparently reveals an underlying problem, namely: Why does the addition of
parentheses around a COMPLEX expression cause a conversion to REAL?

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Luckily, it seems that the generated code is correct after all and the
imaginary part is in fact *not* discarded, as shown by this small test:

complex, parameter :: i = (0.,1.)
print *,i
print *,(i)
end

This triggers the same warnings as comment 0 and prints:

 (0.,1.)
 (0.,1.)

i.e. both expressions, with or without parentheses, yield the same result, as
expected. Thus it's only a diagnostics problem, not wrong code.