[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203

2019-04-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Suppose Bin will handle this.

[Bug tree-optimization/90020] [7/8/9 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

2019-04-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.5

[Bug c++/90019] [8 regression] Bogus ambiguous overload error for NTTP pack of disjoint enable_ifs unless there is an unsupplied default argument

2019-04-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90019

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.4.0, 9.0
Version|9.0 |8.3.0
   Keywords||rejects-valid
   Last reconfirmed||2019-04-09
 Ever confirmed|0   |1
   Target Milestone|--- |8.4
  Known to fail||8.1.0, 8.3.0

--- Comment #1 from Richard Biener  ---
Also seems to work on trunk, but it seems it was only fixed recently.  So maybe
this one has a duplicate.

[Bug tree-optimization/90018] [8/9 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90018

--- Comment #5 from Martin Liška  ---
> Martin, if you can help with a testcase that would be great (in case you
> have a working setup / methology to track this down).  Otherwise I'll of
> course see to do that myself.

I'll do it for you.

[Bug tree-optimization/90018] [8/9 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

2019-04-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90018

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
 Status|NEW |ASSIGNED
  Known to work||8.2.0, 9.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[8 Regression] r265453  |[8/9 Regression] r265453
   |miscompiled 527.cam4_r in   |miscompiled 527.cam4_r in
   |SPEC CPU 2017   |SPEC CPU 2017
  Known to fail||8.3.0

--- Comment #4 from Richard Biener  ---
Mine.  Even though the issue doesn't appear on trunk the referenced revision
doesn't fix a bug but a missed optimization so the issue must be latent on
trunk.

Martin, if you can help with a testcase that would be great (in case you have a
working setup / methology to track this down).  Otherwise I'll of course see to
do that myself.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-09 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #43 from Iain Sandoe  ---
Created attachment 46110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46110=edit
Proof-of-principle path

Does this work for you?
 - my local testing says it generates the right wrapped include file.

(perhaps the constraint on darwin version was too tight in Erik's case)

[Bug c++/90010] [8/9 Regression] valgrind error with snprintf and -Wall

2019-04-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90010

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2

[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2

2019-04-09 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834

--- Comment #16 from Wilco  ---
(In reply to kugan from comment #15)
> (In reply to Wilco from comment #11)
> > There is also something odd with the way the loop iterates, this doesn't
> > look right:
> > 
> > whilelo p0.s, x3, x4
> > incwx3
> > ptest   p1, p0.b
> > bne .L3
> 
> I am not sure I understand this. I tried with qemu using an execution
> testcase and It seems to work.
> 
> whilelo   p0.s, x4, x5
>   incwx4
>   ptest   p1, p0.b
>   bne .L3
> In my case I have the above (register allocation difference only) incw is
> correct considering two vector word registers? Am I missing something here?

I'm talking about the completely redundant ptest, where does that come from?

[Bug c++/89900] [9 Regression] ICE: Segmentation fault (in check_instantiated_arg)

2019-04-09 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89900

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P4  |P1

--- Comment #3 from Paolo Carlini  ---
Uhm, unfortunately a tiny modification of the original testcase uncovers an ICE
on valid:

template void
fk (XE..., int/*SW*/);

void
w9 (void)
{
  fk (0);
}

[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203

2019-04-09 Thread amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021

--- Comment #2 from bin cheng  ---
We have {{0, +, 1}_6, +, 1}_4 in this case, and _6 is an outer loop of
loop_nest.  Function add_multivariate_self_dist was intentionally skipped in
PR89725 patch, but control flow gets to it because
  1) In analyze_miv_subscript, equal access_fn case is specially handled,
rather than general miv analysis.
  2) In add_other_self_distances, evolution_function_is_univariate_p returns
false for above access_fn.

It looks we can also introduce another parameter loopnum to
evolution_function_is_univariate_p, just like
evolution_function_is_affine_multivariate_p to consider outer loop's chrec as
invariant symbol here.  OTOH, making changes in add_multivariate_self_dist
still doesn't seem right in this case.

[Bug tree-optimization/46590] long compile time with -O2 and many loops

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #55 from Martin Liška  ---
Just for the record, it improved significantly compile time of test-cases
provided in PR69609, PR38518, PR36262:

https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=11.603.8
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=11.618.8
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=11.630.8

[Bug c++/90010] [8/9 Regression] valgrind error with snprintf and -Wall

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90010

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-09
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.4
Summary|valgrind error with |[8/9 Regression] valgrind
   |snprintf and -Wall  |error with snprintf and
   ||-Wall
 Ever confirmed|0   |1
  Known to fail||8.3.0, 9.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r247401.

[Bug preprocessor/64965] __FILE__ doesn't work if the filename contains newline

2019-04-09 Thread rv at rasmusvillemoes dot dk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64965

Rasmus Villemoes  changed:

   What|Removed |Added

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

--- Comment #8 from Rasmus Villemoes  ---
Fixed by r253605

[Bug tree-optimization/90020] [7/8/9 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020

--- Comment #6 from Martin Liška  ---
I bisected GCC 4.9.x branch and it started with r215059, which is a backport of
3 patches. I reverted changes in:
patching file gcc/recog.c
patching file gcc/tree-ssa-loop-niter.c
patching file gcc/tree-vect-slp.c

and so that it points to backport of PR61672.

[Bug gcov-profile/90023] The coverage of a label is incorrect when it is after a return statement and followed by a blank statement

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90023

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-09
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, but again it's very low priority as it contains an empty basic
block.

[Bug tree-optimization/90018] [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90018

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Richi do you want a help with a test-case reduction? Or is it a known issue
that has been fixed on trunk?

[Bug tree-optimization/90020] [7/8/9 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug tree-optimization/90020] [7/8/9 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020

--- Comment #5 from Martin Liška  ---
Created attachment 46109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46109=edit
Reduced test-case #1

[Bug tree-optimization/90020] [7/8/9 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||rguenth at gcc dot gnu.org
Summary|[8 regression] -O2 -Os  |[7/8/9 regression] -O2 -Os
   |x86-64 wrong code generated |x86-64 wrong code generated
   |for GNU Emacs   |for GNU Emacs
  Known to fail||7.4.0, 8.3.0, 9.0

--- Comment #3 from Martin Liška  ---
I can confirm that even though the code is not so nice :)
I have 2 versions of the reduced test-case:

1)
$ gcc emacs0.c -Os -fno-strict-aliasing -g && valgrind ./a.out
==20746== Memcheck, a memory error detector
==20746== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==20746== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==20746== Command: ./a.out
==20746== 
==20746== Invalid read of size 8
==20746==at 0x4011CF: select_window (emacs0.c:116)
==20746==by 0x40105A: main (emacs0.c:126)
==20746==  Address 0xa is not stack'd, malloc'd or (recently) free'd

fails for 4.8.0+ except 4.9.x releases.

2)
$ gcc emacs.c -Os -fno-strict-aliasing && ./a.out

started failing with r238242

The problematic transformation:

   [local count: 1073741824]:
  _1 = PSEUDOVECTORP (window_6(D));
  pretmp_9 = MEM[(struct window *)window_6(D)].contents;
  if (_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

happens in PRE. Richi can you please take a look?

[Bug tree-optimization/90020] [7/8/9 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020

--- Comment #4 from Martin Liška  ---
Created attachment 46108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46108=edit
Reduced test-case #0

[Bug gcov-profile/90023] New: The coverage of a label is incorrect when it is after a return statement and followed by a blank statement

2019-04-09 Thread yangyibiao at nju dot edu.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90023

Bug ID: 90023
   Summary: The coverage of a label is incorrect when it is after
a return statement and followed by a blank statement
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

$ cat small.c
#include 

int foo(int a)
{
  void *l = &

  if(a == 4)
; //goto *l;

  return 150;

error:
;//  return a;
}

int main(int argc, char **argv)
{
  printf("value: %d\n", foo(argc));

  return 0;
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov 
value: 150
File 'small.c'
Lines executed:100.00% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:int foo(int a)
-:4:{
1:5:  void *l = &
-:6:
-:7:  if(a == 4)
-:8:; //goto *l;
-:9:
2:   10:  return 150;
-:   11:
1:   12:error:
-:   13:;//  return a;
-:   14:}
-:   15:
1:   16:int main(int argc, char **argv)
-:   17:{
1:   18:  printf("value: %d\n", foo(argc));
-:   19:
1:   20:  return 0;
-:   21:}

Line #12 is wrongly marked as executed and Line #10 is wrongly marked as
executed twice. 

When, Line #8 and Line #13 are not commented, the coverage is correct as:

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:int foo(int a)
-:4:{
1:5:  void *l = &
-:6:
1:7:  if(a == 4)
#:8:goto *l;
-:9:
1:   10:  return 150;
-:   11:
#:   12:error:
#:   13:  return a;
-:   14:}
-:   15:
1:   16:int main(int argc, char **argv)
-:   17:{
1:   18:  printf("value: %d\n", foo(argc));
-:   19:
1:   20:  return 0;
-:   21:}

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-09 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #42 from Jürgen Reuter  ---
I filed an APPLE bug report:
https://bugreport.apple.com/web/?problemID=49727047

[Bug target/90015] riscv: typo "intterupt" in diagnostic

2019-04-09 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90015

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893

--- Comment #34 from Martin Liška  ---
> It seems your solution works. But it doesn't work if I add
> "-fno-strict-aliasing" through 'export CFLAGS="$CFLAGS -O3
> -fno-strict-aliasing..." export CXXFLAGS="$CXXFLAGS -O3
> -fno-strict-aliasing..." ...', maybe they are overridden. Thank you very
> much for your help.

Please consult questions about nodejs build system with their developers.

[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745

2019-04-09 Thread kangshan0910 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893

--- Comment #33 from 康 珊  ---
(In reply to Martin Liška from comment #32)
> I can confirm it works for me with:
> 
> diff --git a/common.gypi b/common.gypi
> index 9502e92..3d8f04f 100644
> --- a/common.gypi
> +++ b/common.gypi
> @@ -195,8 +195,8 @@
>  'ldflags': ['<(pgo_use)'],
>},],
>['enable_lto=="true"', {
> -'cflags': ['<(lto)'],
> -'ldflags': ['<(lto)'],
> +'cflags': ['<(lto) -fno-strict-aliasing'],
> +'ldflags': ['<(lto) -fno-strict-aliasing'],
>},],
>  ],
>},],

It seems your solution works. But it doesn't work if I add
"-fno-strict-aliasing" through 'export CFLAGS="$CFLAGS -O3
-fno-strict-aliasing..." export CXXFLAGS="$CXXFLAGS -O3
-fno-strict-aliasing..." ...', maybe they are overridden. Thank you very much
for your help.

[Bug fortran/90022] Issue with CFI_is_contigous and CFI base address

2019-04-09 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90022

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-09
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
I will be submitting a patch for this shortly.

Paul

[Bug fortran/90022] New: Issue with CFI_is_contigous and CFI base address

2019-04-09 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90022

Bug ID: 90022
   Summary: Issue with CFI_is_contigous and CFI base address
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: pault at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

See https://gcc.gnu.org/ml/fortran/2019-04/msg00013.html for the issue and a
testcase.

Paul

[Bug tree-optimization/90020] [8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Let me take a look.

[Bug target/90015] riscv: typo "intterupt" in diagnostic

2019-04-09 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90015

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  9 06:38:07 2019
New Revision: 270221

URL: https://gcc.gnu.org/viewcvs?rev=270221=gcc=rev
Log:
PR target/90015
* config/riscv/riscv.c (riscv_get_interrupt_type): Fix comment typo.
(riscv_merge_decl_attributes): Fix typo in diagnostics.  Remove
trailing period from it too.

* gcc.target/riscv/interrupt-conflict-mode.c (foo): Adjust expected
diagnostics.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/riscv/riscv.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/riscv/interrupt-conflict-mode.c

[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203

2019-04-09 Thread amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021

--- Comment #1 from bin cheng  ---
Sorry for the breakage, I will have a look.

[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2019-4-9
 CC||amker at gcc dot gnu.org
  Known to work||8.3.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug tree-optimization/90021] New: [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203

2019-04-09 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021

Bug ID: 90021
   Summary: [9 Regression] ICE in index_in_loop_nest, at
tree-data-ref.h:587 since r270203
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I see following ICE:

$ cat ice.f90
MODULE a
  INTEGER b
CONTAINS
  SUBROUTINE bar(c)
REAL c(1)
INTEGER d, e, f 
DO g = 1,3
  DO f = 1,1
DO e = 1,3
  DO d = 1,1
c(f-1+d) = c(f-1+d)*b
  END DO
END DO
  END DO
END DO
  END  
  END  

$ gcc ice.f90 -fno-tree-loop-ivcanon -O1 -floop-interchange -fno-tree-ccp
-fno-tree-ch -fipa-pta -c
ice.f90:7:7:

7 | DO g = 1,3
  |   1
Warning: Deleted feature: Loop variable at (1) must be integer
during GIMPLE pass: linterchange
ice.f90:4:0:

4 |   SUBROUTINE bar(c)
  | 
internal compiler error: in index_in_loop_nest, at tree-data-ref.h:587
0x78219b index_in_loop_nest
/home/marxin/Programming/gcc/gcc/tree-data-ref.h:587
0x7837a7 index_in_loop_nest
/home/marxin/Programming/gcc/gcc/tree.h:3176
0x7837a7 add_multivariate_self_dist
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:4392
0x7837a7 add_other_self_distances
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:4445
0x7837a7 build_classic_dist_vector
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:4565
0x7837a7 subscript_dependence_tester
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:4798
0x7837a7 compute_affine_dependence(data_dependence_relation*, loop*)
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:4853
0x156cf48 tree_loop_interchange_compute_ddrs
/home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:1855
0x156cf48 prepare_perfect_loop_nest
/home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:2031
0x156cf48 execute
/home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:2072
0x156cf48 execute
/home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:2060

[Bug d/90013] wrong quotes in diagnostics

2019-04-09 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90013

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Buclaw  ---
It was the fault of the pot generator (well me I guess) that these sources got
picked up in the first place.

They are no longer part of gcc.pot.  I don't know how this gets merged into
each individual .po, but they should not be present anymore.

[Bug d/90012] untranslateable placeholder in expressionsem.c

2019-04-09 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90012

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Buclaw  ---
It was the fault of the pot generator (well me I guess) that these sources got
picked up in the first place.

They are no longer part of gcc.pot.  I don't know how this gets merged into
each individual .po, but they should not be present anymore.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-09 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #41 from Iain Sandoe  ---
inconclusive so far, it's agreed that _Atomic is not a C++ keyword, but not
clear what is best solution to the SDK use.

If you filed a radar, please copy the number here (no-one else can see it, but
at least we can point the Apple devs to it - so they can look internally).

<    1   2