[Bug fortran/68053] lower bound of implied shape array restricted too much

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/68053] lower bound of implied shape array restricted too much

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Nov  9 06:06:52 2015
New Revision: 229993

URL: https://gcc.gnu.org/viewcvs?rev=229993&root=gcc&view=rev
Log:
2015-11-08  Steven g. Kargl  

PR fortran/68053
* decl.c (add_init_expr_to_sym):  Try to reduce initialization
expression
before testing for a constant value.

2015-11-08  Steven g. Kargl  

PR fortran/68053
* gfortran.dg/pr68053.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68053.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68053] lower bound of implied shape array restricted too much

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Nov  9 05:50:24 2015
New Revision: 229992

URL: https://gcc.gnu.org/viewcvs?rev=229992&root=gcc&view=rev
Log:
2015-11-08  Steven g. Kargl  

PR fortran/68053
* decl.c (add_init_expr_to_sym):  Try to reduce initialization
expression
before testing for a constant value.

2015-11-08  Steven g. Kargl  

PR fortran/68053
* gfortran.dg/pr68053.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68053.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/68182] [6 Regression] ICE in reorder_basic_blocks_simple building libitm/beginend.cc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/68182] [6 Regression] ICE in reorder_basic_blocks_simple building libitm/beginend.cc

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Mon Nov  9 03:57:19 2015
New Revision: 229983

URL: https://gcc.gnu.org/viewcvs?rev=229983&root=gcc&view=rev
Log:
Fix bb-reorder problem with degenerate cond_jump (PR68182)

The code mistakenly thinks any cond_jump has two successors.  This is
not true if both destinations are the same, as can happen with weird
patterns as in the PR.


PR rtl-optimization/68182
* gcc/bb-reorder.c (reorder_basic_blocks_simple): Treat a conditional
branch with only one successor just like unconditional branches.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Let me put it differently.

At the C level, your asm statement outputs to an integer register.
Internally, the asm outputs to a condition reg, and the C statement
is expanded to also do a move from that condition reg to the integer
register.  This move is then later optimised away in your example.

On "cc0" targets, every asm has an implicit "cc" clobber.  x86 is not
a cc0 target (that is ancient technology and one day it will be gone
completely, hopefully).  However, it used to be a cc0 target long ago,
and to ease transition of old user code, the target code adds a cc
clobber always.

If you look at the generated RTL (with -da, say), you will see that
the cc output overrides the cc clobber.  There is no conflict.

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

--- Comment #3 from David  ---
> "=@ccc"(r) does not output to the "cc" register, it 
> outputs to a general register.  

Actually, I don't believe it does.

In v5, you *did* have to use "setc %0" with a general register AND it generated
an extra "cmp" instruction (very irritating).  But this code:

int main()
{
   int x;

   do {
  asm volatile("setc" : "=@ccc"(x) : : "cc");
   } while (!x);
}

Compiled with -O2, now outputs:

.L2:
/APP
setc
/NO_APP
jnc .L2

No general register required.  It really is just using the flags.  

So it still looks to me like we are both clobbering flags (implying that they
are changed but not output) and outputting them.  Allowing both at once seems
bad.

> The "cc" clobber is not deprecated, not on other targets anyway.

As I look at final_scan_insn() in final.c, it appears to always call
CC_STATUS_INIT for both basic and extended asm.  And while not all platforms
may implement CC_STATUS_INIT, my assumption was that if the platform supported
the "cc" clobber, this was where the implementation was.

If there is no way to NOT clobber, then "cc" becomes an unenforced comment,
rather than a directive to change the behavior of the compiler.  If that's
true, updating the docs to say so seems reasonable.

[Bug target/36557] -m32 -mpowerpc64 produces better code than -m64 for a!=0

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
We now do

cntlzw 3,3
srwi 3,3,5
xori 3,3,0x1
blr

which is still not optimal (and not what -m32 / -m32 -mpowerpc64 do).

[Bug rtl-optimization/68250] New: wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 68250
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu (in
64-bit mode)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O2
and -O3 in the 64-bit mode (but not in the 32-bit mode). 

This is a regression from 5.2.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151107 (experimental) [trunk revision 229937] (GCC) 
$ 
$ gcc-trunk -m64 -Os small.c; ./a.out
1
$ gcc-trunk -m32 -O2 small.c; ./a.out
1
$ gcc-5.2 -m64 -O2 small.c; ./a.out
1
$ 
$ gcc-trunk -m64 -O2 small.c
$ ./a.out
0
$ 





int printf (const char *, ...); 

char a, b, h, k, l, m, o;
short c, d, n;
int e, f, g, j, q;

void
fn1 ()
{
  int p = b || a;
  n = o > 0 || d > 1 >> o ? d : d << o;
  for (; j; j++)
m = c < 0 || m || c << p;
  l = f + 1;
  for (; f < 1; f = 1)
k = h + 1;
}

int
main ()
{
  char i;
  for (; e < 1; e++)
{
  fn1 ();
  if (k)
i = k;
  if (i > q)
g = 0;
}
  printf ("%d\n", k);
  return 0;
}

[Bug tree-optimization/68249] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 68249
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O2
and -O3 in both 32-bit and 64-bit modes. 

It also affects 4.9.x and later, and is a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151107 (experimental) [trunk revision 229937] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
$ gcc-4.8 -O2 small.c; ./a.out
$ 
$ gcc-trunk -O2 small.c
$ ./a.out
Aborted (core dumped)
$ 
$ gcc-4.9 -O2 small.c  
$ ./a.out
Aborted (core dumped)
$ 


-


int a, b, c, g, k, l, m, n;
char h;

void
fn1 ()
{
  for (; k; k++)
{
  m = b || c < 0 || c > 1 ? : c;
  g = l = n || m < 0 || (m > 1) > 1 >> m ? : 1 << m;
}
  l = b + 1;
  for (; b < 1; b++)
h = a + 1;
}

int
main ()
{
  char j; 
  for (; a < 1; a++)
{
  fn1 ();
  if (h)
j = h;
  if (j > c)
g = 0;
}

  if (h != 1) 
__builtin_abort (); 

  return 0;
}

[Bug rtl-optimization/54110] lower-subreg related code quality for long long function return

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

  Known to work||4.8.3, 6.0

--- Comment #1 from Segher Boessenkool  ---
Works with 4.8.3 and 6.0; I don't have in between versions handy.

[Bug other/66259] Combined gcc and binutils build from git-master fails, with gas/as-new not existing

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Is this fixed now?  Michael, could you test again?

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #16 from Jerry DeLisle  ---
For what its worth:

$ gfc pr51119.f90 -lblas -fno-external-blas -Ofast -march=native 
$ ./a.out 
 Time, MATMUL:21.2483196   21.25444964601 1.5055670945599979
 Time, dgemm:33.2441711   33.24308728902  .96260614189671445

This is on a laptop not taking any advantage of a tuned BLAS.  If I replace
-Ofast with -O2 I get:

$ ./a.out 
 Time, MATMUL:43.6199570   43.625358022970.73351833543988521
 Time, dgemm:33.2262650   33.22696145301 0.96307331759072967 

-O3 brings performance back to match with -Ofast. It seems odd to me that -O2
does not do well.

Regardless, the internal MATMUL is doing better than BLAS on this platform, but
1.5 gflops is pretty lame either way.

[Bug tree-optimization/68248] New: ICE on valid code at -O3 on x86_64-linux-gnu in uniform_vector_p, at tree.c:10807

[su at cs dot ucdavis.edu]

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

Bug ID: 68248
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
uniform_vector_p, at tree.c:10807
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151107 (experimental) [trunk revision 229929] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-5.2 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn2’:
small.c:10:1: internal compiler error: in uniform_vector_p, at tree.c:10807
 fn2 ()
 ^

0xd6841f uniform_vector_p(tree_node const*)
../../gcc-trunk/gcc/tree.c:10807
0xcf9c9c expand_vector_operations_1
../../gcc-trunk/gcc/tree-vect-generic.c:1530
0xcf9c9c expand_vector_operations
../../gcc-trunk/gcc/tree-vect-generic.c:1732
0xcf9c9c execute
../../gcc-trunk/gcc/tree-vect-generic.c:1816
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


int a, b, c, d;

int
fn1 (int p1)
{
  return a > 0 ? p1 : p1 >> a;
}

void
fn2 ()
{
  char e;
  for (; c; c++)
{
  e = fn1 (!d ^ 2);
  b ^= e;
}
}

[Bug target/43437] ICE in CSE, during libgcc build

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #24 from Segher Boessenkool  ---
S+Core support has been removed in r215889.  Closing.

[Bug target/61298] redundant compare instructions for powerpc64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

  Known to work||6.0

--- Comment #7 from Segher Boessenkool  ---
Fixed (or hidden) on trunk with r222855.

[Bug libfortran/68115] [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2015-11-08, at 12:44 PM, dominiq at lps dot ens.fr wrote:

> It looks target specific. Any progress?

It's not possible to implement on hpux.  We have a kernel helper on linux.

Dave
--
John David Anglin   dave.ang...@bell.net

[Bug fortran/68053] lower bound of implied shape array restricted too much

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Testing a patch now.

[Bug driver/68181] djgpp: minor linker invocation issues

[andris.pavenis at iki dot fi]

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

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris.pavenis at iki dot fi

--- Comment #1 from Andris Pavenis  ---
Linker script djgpp.djl have not been used any more for DJGPP port for very
long time. The problem is that DJGPP related changes have not been git into
official GCC sources. Current version of djgpp.h and other related DJGPP files
are rather different from official ones.

Built cross-compiler from trunk version today (Centos 6 x86_64). Currently
native DJGPP build is ongoing.

Most configuration changes do not touch other stuff except avoiding using
LINK_COMMAND_SPEC. I defined additional POST_LINK_SPEC in gcc/gcc.c and that
could be a problem in current time.

So I need finally try to get changes into GCC sources (at least part of them)

[Bug rtl-optimization/67864] [6 Regression] CSiBE size regression

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Segher Boessenkool  ---
Fixed (checked the CSiBE graphs and log).

[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/68151] ICE on using select case with function of wrong type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/68224] ICE on referencing parameter array with dimension null

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for bug report.

[Bug c++/67813] [C++14] copy-initialization of object with pointer member fails in constexpr function

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
Shouldn't this be resolved as fixed?

[Bug fortran/68224] ICE on referencing parameter array with dimension null

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Nov  8 18:05:30 2015
New Revision: 229960

URL: https://gcc.gnu.org/viewcvs?rev=229960&root=gcc&view=rev
Log:
2015-11-08  Steven G. Kargl  

PR fortran/68224
* array.c (match_array_element_spec): Check of invalid NULL().
While here, fix nearby comments.

2015-11-08  Steven G. Kargl  

PR fortran/68224
* gfortran.dg/pr68224.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68224.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/array.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/68231] [6 Regression] bootstrap failure after placement new

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
The ILP32 failure should be fixed in r229959.  I tested it with -m32 on x86_64
but not on AIX/powerpc, so I'll leave this open until test results confirm that
the test passes.

[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Nov  8 17:53:36 2015
New Revision: 229958

URL: https://gcc.gnu.org/viewcvs?rev=229958&root=gcc&view=rev
Log:
2015-11-08  Steven G. Kargl  

PR fortran/68153
* check.c (gfc_check_reshape): Improve check for valid SHAPE argument.

2015-11-08  Steven G. Kargl  

PR fortran/68153
* gfortran.dg/pr68153.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68153.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/check.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/67942] diagnose placement new buffer overflow

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Sun Nov  8 17:53:51 2015
New Revision: 229959

URL: https://gcc.gnu.org/viewcvs?rev=229959&root=gcc&view=rev
Log:
Clean up fallout on ILP32 from r229831.

gcc/
PR c++/67942 
* cp/init.c (warn_placement_new_too_small): Convert integer
operand of POINTER_PLUS_EXPR to ssize_t to determine its signed
value.

c-family/
* c.opt (Wplacement-new): Add a period to the end of
a sentence.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c

[Bug fortran/68009] [6 Regression] prototype for gfortran_runtime_error with inline matmul

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Could this PR be made more explicit about what should be done?

[Bug libfortran/68115] [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
It looks target specific. Any progress?

[Bug fortran/68151] ICE on using select case with function of wrong type

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Nov  8 17:43:29 2015
New Revision: 229957

URL: https://gcc.gnu.org/viewcvs?rev=229957&root=gcc&view=rev
Log:
2015-11-08  Steven G. Kargl  

PR fortran/68151
* match.c (match_case_selector):  Check for invalid type.

2015-11-08  Steven G. Kargl  

PR fortran/68151
* gfortran.dg/pr68151.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68151.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/67202] Fortran FE should load scalar pass-by-reference intent-in arguments at the beginning of a function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-08
 Blocks||36854
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Is there an easy way to check than a scalar pass-by-reference intent-in
argument has been loaded at the beginning of the function?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug fortran/68218] ALLOCATE with size given by a module function

[vehre at gcc dot gnu.org]

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

--- Comment #3 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sun Nov  8 17:37:42 2015
New Revision: 229956

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

2015-11-08  Andre Vehreschild  

PR fortran/68218
* trans-array.c (gfc_array_init_size): Add gfc_evaluate_now() when
array spec in allocate is a function call.

gcc/testsuite/ChangeLog:

2015-11-08  Andre Vehreschild  

PR fortran/68218
* gfortran.dg/allocate_with_arrayspec_1.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_arrayspec_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68184] [4.9/5/6 Regression] Exception from a virtual function does not get caught

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
Works with gcc 4.6.4, fails with 4.7.4, 4.8.5, 4.9.3, 5.2.1, and 6.0.0.  The
failure started with r173517 -- a chunk of exception handling meta-data and
code disappears with that revision.

[Bug fortran/55858] When scalarizing contiguous whole-arrays, consider folding into a single loop

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-08
 Blocks||36854
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
If I am not mistaken, there is still two nested loops in the code optimized
with -O at revision r229941 (trunk 6.0).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug fortran/68224] ICE on referencing parameter array with dimension null

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Nov  8 17:25:16 2015
New Revision: 229955

URL: https://gcc.gnu.org/viewcvs?rev=229955&root=gcc&view=rev
Log:
2015-11-08  Steven G. Kargl  

PR fortran/68224
* array.c (match_array_element_spec): Check of invalid NULL().
While here, fix nearby comments.

2015-11-08  Steven G. Kargl  

PR fortran/68224
* gfortran.dg/pr68224.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68224.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/55980] missed optimizations with internal_pack

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Does this PR still make sense after two years and a half without activity. If
yes, I think some test(s) showing the issue should be provided.

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
(In reply to Joost VandeVondele from comment #14)
> (In reply to Markus Trippelsdorf from comment #13)
> > *** Bug 68127 has been marked as a duplicate of this bug. ***
> 
> just FYI, for me (PR68127) the issue pops up in a non-deterministic way, I
> don't know why, but this might be useful to keep in mind while reducing /
> bisecting.

Yes. This is the reason why my previous bisecting attempts landed on 
commits that have probably nothing to do with this nasty heisenbug.

[Bug fortran/68196] [4.9/5/6 Regression] ICE on function result with procedure pointer component

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Sun Nov  8 16:47:58 2015
New Revision: 229954

URL: https://gcc.gnu.org/viewcvs?rev=229954&root=gcc&view=rev
Log:
2015-11-08  Paul Thomas  

PR fortran/68196
* class.c (has_finalizer_component): Prevent infinite recursion
through this function if the derived type and that of its
component are the same.
* trans-types.c (gfc_get_derived_type): Do the same for proc
pointers by ignoring the explicit interface for the component.

PR fortran/66465
* check.c (same_type_check): If either of the expressions is
BT_PROCEDURE, use the typespec from the symbol, rather than the
expression.

2015-11-08  Paul Thomas  

PR fortran/68196
* gfortran.dg/proc_ptr_47.f90: New test.

PR fortran/66465
* gfortran.dg/pr66465.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr66465.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_47.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/class.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/66465] Procedure pointer component & non-component interpreted as different type or kind

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Sun Nov  8 16:47:58 2015
New Revision: 229954

URL: https://gcc.gnu.org/viewcvs?rev=229954&root=gcc&view=rev
Log:
2015-11-08  Paul Thomas  

PR fortran/68196
* class.c (has_finalizer_component): Prevent infinite recursion
through this function if the derived type and that of its
component are the same.
* trans-types.c (gfc_get_derived_type): Do the same for proc
pointers by ignoring the explicit interface for the component.

PR fortran/66465
* check.c (same_type_check): If either of the expressions is
BT_PROCEDURE, use the typespec from the symbol, rather than the
expression.

2015-11-08  Paul Thomas  

PR fortran/68196
* gfortran.dg/proc_ptr_47.f90: New test.

PR fortran/66465
* gfortran.dg/pr66465.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr66465.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_47.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/class.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #14 from Joost VandeVondele  
---
(In reply to Markus Trippelsdorf from comment #13)
> *** Bug 68127 has been marked as a duplicate of this bug. ***

just FYI, for me (PR68127) the issue pops up in a non-deterministic way, I
don't know why, but this might be useful to keep in mind while reducing /
bisecting.

[Bug fortran/57262] Optimize bound intrinsics with dim=var for rank one arrays

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-08
 Blocks||36854
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Not convinced, but let me move it to NEW.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug fortran/57992] Pointless packing of contiguous arrays for simply contiguous functions results as actual arguments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-08
 Blocks||36854
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed. I did not test the patch.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug fortran/36854] [meta-bug] fortran front-end optimization

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
Bug 36854 depends on bug 54238, which changed state.

Bug 54238 Summary: If possible, TRANSFER should use assignment instead of MEMCPY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54238

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

[Bug fortran/54238] If possible, TRANSFER should use assignment instead of MEMCPY

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Blocks||36854
 Resolution|--- |WONTFIX

--- Comment #2 from Dominique d'Humieres  ---
> Though the memcpy does get optimized to a VCE:
>   addr.9_4 = (integer(kind=8)) ivtmp.29_28;
>   D.1913_24 = VIEW_CONVERT_EXPR(addr.9_4);

Compiling the code in comment 0 with '-fdump-tree-optimized -O' gives the
following optimized dump for r229946

  :
  transfer.1_25 = (integer(kind=8)) &array;
  i.5_6 = i;
  _7 = i.5_6 * 32;
  _8 = _7 / 8;
  _9 = (integer(kind=8)) _8;
  addr.8_10 = _9 + transfer.1_25;
  transfer.2_27 = (void *) addr.8_10;
  dt_parm.3.common.filename = &"pr54238.f90"[1]{lb: 1 sz: 1};
  dt_parm.3.common.line = 13;
  dt_parm.3.common.flags = 128;
  dt_parm.3.common.unit = 6;
  _gfortran_st_write (&dt_parm.3);
  _gfortran_transfer_integer_write (&dt_parm.3, &i, 4);
  _gfortran_transfer_character_write (&dt_parm.3, &": "[1]{lb: 1 sz: 1}, 2);
  _gfortran_transfer_integer_write (&dt_parm.3, transfer.2_27, 4);
  _gfortran_st_write_done (&dt_parm.3);
  dt_parm.3 ={v} {CLOBBER};
  i.9_21 = i.5_6 + 1;
  i = i.9_21;
  if (i.5_6 == 3)
goto ;
  else
goto ;

  :

So the __builtin_memcpy are aleready optimized with -O.

> So it might not be important enough to do at the front-end level.

Agreed. Closing as WONTFIX.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug fortran/55100] FORALL: If the RHS is scalar, not array temporary is needed

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-08
 Blocks||36854
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Compiling the test in comment 0 with '-Warray-temporaries
-fcheck-array-temporaries' does not report any temporary at compile time nor at
run time.

Do I miss something?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug fortran/64962] Use "nonnull"/"returns_nonnull" attribute annotation for procedures (user code + libgfortran)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-08
 Blocks||36854
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Let me mark it as NEW.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-08
 Blocks||36854
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
The following patch

@@ -1842,7 +1843,8 @@
   DECL_EXTERNAL (fndecl) = 0;

   if (!current_function_decl
-  && !sym->attr.entry_master && !sym->attr.is_main_program)
+  && !sym->attr.entry_master && !sym->attr.is_main_program
+  && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label))
 TREE_PUBLIC (fndecl) = 1;

   attributes = add_attributes_to_decl (attr, NULL_TREE);

has been applied at revision r186223 (pr40973 and pr52751). Modified at r186464
(pr52916) by

--- trunk/gcc/fortran/trans-decl.c  2012/04/08 07:15:01 186223
+++ trunk/gcc/fortran/trans-decl.c  2012/04/15 05:52:51 186464
@@ -1844,7 +1844,8 @@

   if (!current_function_decl
   && !sym->attr.entry_master && !sym->attr.is_main_program
-  && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label))
+  && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label
+ || sym->attr.public_used))
 TREE_PUBLIC (fndecl) = 1;

   attributes = add_attributes_to_decl (attr, NULL_TREE);

Thus the patch at http://gcc.gnu.org/ml/fortran/2011-01/msg00094.html no longer
applies.

I have tested

--- ../_clean/gcc/fortran/trans-decl.c  2015-10-29 18:20:14.0 +0100
+++ gcc/fortran/trans-decl.c2015-11-08 13:23:12.0 +0100
@@ -2075,7 +2075,7 @@ build_function_decl (gfc_symbol * sym, b
   if (!current_function_decl
   && !sym->attr.entry_master && !sym->attr.is_main_program
   && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label
- || sym->attr.public_used))
+ || sym->attr.public_used || sym->binding_label[0] != '\0'))
 TREE_PUBLIC (fndecl) = 1;

   if (sym->attr.referenced || sym->attr.entry_master)

but it caused a lot of regressions (ICEs).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug 36854] [meta-bug] fortran front-end optimization

[Bug other/68247] New: Remove pass_first_instance

[vries at gcc dot gnu.org]

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

Bug ID: 68247
   Summary: Remove pass_first_instance
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The compiler contains a variable first_pass_instance:
...
$ grep -d skip first_pass_instance gcc/* | grep -v ChangeLog
gcc/passes.c:bool first_pass_instance;
gcc/passes.c:  first_pass_instance = (flags & TODO_mark_first_instance) != 0;
gcc/tree-object-size.c:   if (first_pass_instance)
gcc/tree-pass.h:extern bool first_pass_instance;
gcc/tree-ssa-ccp.c:   || first_pass_instance)))
gcc/tree-ssa-dom.c:  cfg_altered |= thread_through_all_blocks
(first_pass_instance);
gcc/tree-ssa-reassoc.c:  if (!first_pass_instance
gcc/tree-ssa-reassoc.c:   if (first_pass_instance
gcc/tree-vrp.c:  if (warn_array_bounds && first_pass_instance)
...

[ See also related discussion at
https://gcc.gnu.org/ml/gcc-patches/2012-07/msg00452.html ]

I think it's a bad idea to have passes behave differently based on the location
in the pass list. It makes it harder to reason about the effect of the pass
list.

Take f.i. pass_dominator:
...
  /* Thread jumps, creating duplicate blocks as needed.  */
  cfg_altered |= thread_through_all_blocks (first_pass_instance);
...

Where thread_through_all_blocks has parameter may_peel_loop_headers:
...
bool
thread_through_all_blocks (bool may_peel_loop_headers)
...

Looking at the pass list, there's nothing suggesting that the first pass
instance behaves different from the second pass instance:
...
  NEXT_PASS (pass_dominator);
  ...
  NEXT_PASS (pass_dominator);
...

So it would be more clear to have this in the pass list:
...
  NEXT_PASS (pass_dominator);
  ...
  NEXT_PASS (pass_dominator_no_peel_loop_headers);
...

The problem there is that we have to add another pass, which will have a
different dump file (something that was mentioned in the related discussion as
a drawback).

I propose a different solution. We can parametrize the pass instance creation:
...
  NEXT_PASS_WITH_ARG (pass_dominator, true /* may_peel_loop_headers */);
  ...
  NEXT_PASS_WITH_ARG (pass_dominator, false /* may_peel_loop_headers */);
...

This way, it's clear in the pass list what each pass instance does and when,
and the two pass instances still share the same dump file.

[Bug fortran/58787] ICE (error recovery) in check_proc_interface

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2013-12-21 00:00:00 |2015-11-8
 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
I just stumbled across the same bug.

[Bug fortran/44348] ICE in build_function_decl

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #10 from Dominique d'Humieres  ---
*** Bug 66494 has been marked as a duplicate of this bug. ***

[Bug fortran/66494] [4.9/5/6 Regression] ICE on using same name for embedded subroutine

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dominique d'Humieres  ---
The second test in comment 0 is the one in comment 2 of pr44348. Thus closing
as duplicate.

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

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Variant: If one adds a
>   subroutine test()
> print *, get(1)
>   end subroutine test
> in the module itself, one gets an ICE:
>
> foo.f90:18:0: internal compiler error: in gfc_generate_function_code,
> at fortran/trans-decl.c:4378

The ICE is still there with the patch. It is at the same location as for the
test in comment 2 of pr44348 and the one in pr66494.

[Bug fortran/66577] ICE in generate_finalization_wrapper, at fortran/class.c:1567

[neil.n.carlson at gmail dot com]

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

--- Comment #5 from neil.n.carlson at gmail dot com ---
> Error: Function result 'intsuccess' at (1) cannot have an initializer

> I don't understand.

C506 -- the type specification for a function result cannot have an
initialization.

[Bug libgomp/68242] [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c -DACC_DEVICE_TYPE_host=1 execution test

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
(In reply to Nathan Sidwell from comment #3)
> I think my firstprivate patch resolves this one.

That is unlikely: the report here is about issues with the test cases
themselves, on gomp-4_0-branch.

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

  Attachment #22202|0   |1
is obsolete||

--- Comment #5 from Dominique d'Humieres  ---
Created attachment 3
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3&action=edit
Updated patch

I have updated the patch on revision r229946. I have a regression for
gfortran.dg/pr65045.f90. Without the patch the errors are

...
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:11:6:

end if! { dg-error "Expecting END BLOCK statement" }
  1

Error: Expecting END BLOCK statement at (1)
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:13:8:

 print*,i ! { dg-error "not appropriate for an expression" }
1

Error: Symbol 'i' at (1) is not appropriate for an expression

With the patch I have two more errors

/opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:11:6:

end if! { dg-error "Expecting END BLOCK statement" }
  1

Error: Expecting END BLOCK statement at (1)
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:12:3:

 end block i
   1

Error: Expecting END PROGRAM statement at (1)
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:13:8:

 print*,i ! { dg-error "not appropriate for an expression" }
1

Error: Symbol at (1) is not appropriate for an expression
f951: Error: Unexpected end of file in
'/opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90'

I don't understand why the patch changes the errors, but the test can be easily
adjusted.

[Bug fortran/50406] ld undefined reference to __MOD_str

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of pr44265.

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

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 50406 has been marked as a duplicate of this bug. ***

[Bug fortran/68243] QOI: no warning about unused entities in submodules

[paul.richard.thomas at gmail dot com]

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

--- Comment #4 from paul.richard.thomas at gmail dot com  ---
Sorry! Wrong PR.

On 8 November 2015 at 11:18, pault at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68243
>
> --- Comment #3 from Paul Thomas  ---
> (In reply to Paul Thomas from comment #2)
>> That's a wierd one! I'll take a look later on.
>
> I presume that I have to lay out the common block with the pointer and the
> string length variable together? It's the only way that I can see to do this.
>
> It works with the "other brand".
>
> Cheers
>
> Paul
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug fortran/68243] QOI: no warning about unused entities in submodules

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
(In reply to Paul Thomas from comment #2)
> That's a wierd one! I'll take a look later on.

I presume that I have to lay out the common block with the pointer and the
string length variable together? It's the only way that I can see to do this.

It works with the "other brand".

Cheers

Paul

[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion

[mikpelinux at gmail dot com]

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

--- Comment #7 from Mikael Pettersson  ---
(In reply to Mikael Pettersson from comment #6)
> Started with r208165 (on x86_64-linux with -O3).

And the subsequent fix in r208222 does not help for this test case.

[Bug fortran/66494] [4.9/5/6 Regression] ICE on using same name for embedded subroutine

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
This is the ICE as the one for there in comment 2 of pr44348. Duplicate?

[Bug rtl-optimization/68185] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
 Status|NEW |ASSIGNED
 CC||thopre01 at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org