[Bug libstdc++/90277] Debug Mode test failures

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-06
 Ever confirmed|0   |1

--- Comment #3 from François Dumont  ---
As stated in my message this patch can be consider as a fix for this PR as it
reserve buckets for 11 buckets so iterators are not invalidated during
execution of the tests. You shouldn't have anymore failures, do you ?

But maybe you would prefer to make those tests independent of this
implementation detail. I'll do that too.

[Bug middle-end/90356] Missed optimization for variables initialized to 0.0

[no...@turm-lahnstein.de]

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

--- Comment #3 from ead  ---
I guess -0.0+0.0=0.0 is the reason we have to add it once. I think there is no
need to add 0.0 twice.


Btw. compiled with -fno-signed-zeros, the code gets optimized to 

doit:
ret

as expected.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of arrays is incorrect

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-05
   Target Milestone|--- |8.4
Summary|Small inlined function has  |[7/8/9/10 Regression]
   |local variables in invalid  |Partition of arrays is
   |stack location  |incorrect
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Partition 0: size 4 align 8
in  buf

That is wrong, it should have been two seperate ones.
Confirmed with:
gcc version 9.0.1 20190310 (experimental) [master revision
449a19898aa:0239598e3c8:8fe074cf790f632b22e59c24f102e528407bb04e] (GCC)

On aarch64-linux-gnu, I don't see any changes to the expand sources after that
point.

I could not reproduce it with Ubuntu's 7.3.0 but can with a non modified
version of GCC 7.3.0 on mips64-linux-gnu:
Partition 0: size 4 align 8
in  buf

[Bug middle-end/90356] Missed optimization for variables initialized to 0.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Or 0.0+a+0.0 to just 0.0+a.

I don't know enough about fp rules when a is -0.0 to understand the rules here
if this is valid optimization or not.

[Bug c/90356] Missed optimization for variables initialized to 0.0

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
So the optimization asked for in this case is:
a+0.0+0.0 to just a+0.0

[Bug c/90356] New: Missed optimization for variables initialized to 0.0

[no...@turm-lahnstein.de]

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

Bug ID: 90356
   Summary: Missed optimization for variables initialized to 0.0
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no...@turm-lahnstein.de
  Target Milestone: ---

For the following example:

float doit(float k){
float c[2]={0.0};
c[1]+=k;
return c[0]+c[1];
}

the resulting assembler (-O2) is (https://gcc.godbolt.org/z/sSi9OC):

doit:
pxor%xmm1, %xmm1
addss   %xmm1, %xmm0
addss   %xmm1, %xmm0
ret

but should be more like:

doit:   # 
pxor%xmm1, %xmm1  ; or maybe xorps
addss   %xmm1, %xmm0
retq


because c[0] is 0.0.

[Bug fortran/90355] New: Uninitialized read in gfortran.dg/ISO_Fortran_binding_4.f90 test

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

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

Bug ID: 90355
   Summary: Uninitialized read in
gfortran.dg/ISO_Fortran_binding_4.f90 test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: pault at gcc dot gnu.org
  Target Milestone: ---

The second argument of gfc_desc_to_cfi_desc is not fully initialized, the
initializer for the span field is missing.

$ valgrind ./ISO_Fortran_binding_4.exe 
==29601== Memcheck, a memory error detector
==29601== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29601== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==29601== Command: ./ISO_Fortran_binding_4.exe
==29601== 
==29601== Conditional jump or move depends on uninitialised value(s)
==29601==at 0x505E10D: _gfortran_cfi_desc_to_gfc_desc
(ISO_Fortran_binding.c:56)
==29601==by 0x400882: ctg (ISO_Fortran_binding_4.f90:18)
==29601==by 0x400A5F: p (ISO_Fortran_binding_4.f90:27)
==29601==by 0x400A5F: main (ISO_Fortran_binding_4.f90:21)
==29601== 
==29601== Use of uninitialised value of size 8
==29601==at 0x4008A4: ctg (ISO_Fortran_binding_4.f90:11)
==29601==by 0x400A5F: p (ISO_Fortran_binding_4.f90:27)
==29601==by 0x400A5F: main (ISO_Fortran_binding_4.f90:21)
==29601== 
 OK
==29601== Use of uninitialised value of size 8
==29601==at 0x400917: ctg (ISO_Fortran_binding_4.f90:17)
==29601==by 0x400A5F: p (ISO_Fortran_binding_4.f90:27)
==29601==by 0x400A5F: main (ISO_Fortran_binding_4.f90:21)
==29601== 
==29601== Use of uninitialised value of size 8
==29601==at 0x40091E: ctg (ISO_Fortran_binding_4.f90:17)
==29601==by 0x400A5F: p (ISO_Fortran_binding_4.f90:27)
==29601==by 0x400A5F: main (ISO_Fortran_binding_4.f90:21)
==29601== 
==29601== Conditional jump or move depends on uninitialised value(s)
==29601==at 0x505E10D: _gfortran_cfi_desc_to_gfc_desc
(ISO_Fortran_binding.c:56)
==29601==by 0x400A6E: p (ISO_Fortran_binding_4.f90:27)
==29601==by 0x400A6E: main (ISO_Fortran_binding_4.f90:21)
==29601== 
==29601== 
==29601== HEAP SUMMARY:
==29601== in use at exit: 0 bytes in 0 blocks
==29601==   total heap usage: 22 allocs, 22 frees, 13,944 bytes allocated
==29601== 
==29601== All heap blocks were freed -- no leaks are possible
==29601== 
==29601== For counts of detected and suppressed errors, rerun with: -v
==29601== Use --track-origins=yes to see where uninitialised values come from
==29601== ERROR SUMMARY: 6 errors from 5 contexts (suppressed: 0 from 0)

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[toon at moene dot org]

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

--- Comment #9 from Toon Moene  ---
> So with this suggestion, this procedure would be generated without the hidden 
> length argument. The brokenness comes from

> call foo("ab")

> which would generate a call to a procedure WITH the hidden string length 
> argument. However, this code is perfectly standard conforming, F2018 15.5.2.4 
> says that a character dummy argument must have a length less than or equal to 
> the actual argument, which is fulfilled by the above (1 <= 2). That is, we 
> can't special case len=1 procedures and calls in any way.

And this happens *a lot* in the LAPACK code itself.

Just do a grep -i sgemm on it and you will see it in action.

Perhaps this is the reason why this occurs in the R -> LAPACK boundary code ...

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
(In reply to Thomas Koenig from comment #5)
> Hi Paul,
> 
> > I am sure that the array part is OK. Otherwise, why have a type code for
> > strings?
> 
> It 
> 
>  18.5  The source file ISO_Fortran_binding.h
> 18.5.1 Summary of contents
> 
>  The source file ISO_Fortran_binding.h shall contain the C structure
> definitions, typedef declarations, macro
> definitions, and function prototypes specified in 18.5.2 to 18.5.5. The
> definitions and declarations in ISO_-
> Fortran_binding.h can be used by a C function to interpret and manipulate a
> C descriptor. These provide a
> means to specify a C prototype that interoperates with a Fortran interface
> that has a non-interoperable dummy
> variable (18.3.6).
> 
> And the length of the character should be passed as element_len in
> the various CFI_* functions.
> 
> > I guess scalars can be handled by passing to an assumed rank array.
> 
> An array of character*1 is interoperable, yes.
> 
> Regards
> 
> Thomas

Concerning CFI descriptors:

NOTE 18.24
The value of elem_len for a Fortran CHARACTER object is equal to the character
length times the number of bytes of a single character of that kind. If the
kind is C_CHAR, this value will be equal to the character length.

This what I have implemented.

I have been trying and so far failing to pick up substrings directly as CFI
descriptors rather than using copy-in and copy out. For some reason the saved
descriptor is inaccessible.

I will investigate a wee while longer before committing. What I have works and
clears all the problems, except for the missing optional issue - I'll sort out
the latter before submission.

Cheers

Paul


Cheers

Paul

[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
This fixes it:

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18881,7 +18881,8 @@ tsubst_copy_and_build (tree t,
if (thisarg)
  {
/* Shift the other args over to make room.  */
-   vec_safe_push (call_args, (*call_args)[nargs-1]);
+   tree last = (*call_args)[nargs - 1];
+   vec_safe_push (call_args, last);
for (int i = nargs-1; i > 0; --i)
  (*call_args)[i] = (*call_args)[i-1];
(*call_args)[0] = thisarg;

[Bug fortran/90344] [7 Regression] small code that compiles and runs in 7.3.0 but not 7.4.1

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Beats me how this became a regression, but at least it is
fixed now.

Thanks for the bug report!

[Bug fortran/90344] [7 Regression] small code that compiles and runs in 7.3.0 but not 7.4.1

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Sun May  5 14:01:51 2019
New Revision: 270883

URL: https://gcc.gnu.org/viewcvs?rev=270883=gcc=rev
Log:
2019-05-05  Thomas Koenig  

PR fortran/90344
* frontend-passes.c (create_var): Bring into sync with gcc 8.

2019-05-05  Thomas Koenig 

PR fortran/90344
* gfortran.dg/pr90344.f90: New test


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr90344.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/frontend-passes.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/90344] [7 Regression] small code that compiles and runs in 7.3.0 but not 7.4.1

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Sun May  5 13:53:24 2019
New Revision: 270882

URL: https://gcc.gnu.org/viewcvs?rev=270882=gcc=rev
Log:
2019-05-05  Thomas Koenig 

PR fortran/90344
* gfortran.dg/pr90344.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr90344.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Hi Paul,

> I am sure that the array part is OK. Otherwise, why have a type code for
> strings?

It 

 18.5  The source file ISO_Fortran_binding.h
18.5.1 Summary of contents

 The source file ISO_Fortran_binding.h shall contain the C structure
definitions, typedef declarations, macro
definitions, and function prototypes specified in 18.5.2 to 18.5.5. The
definitions and declarations in ISO_-
Fortran_binding.h can be used by a C function to interpret and manipulate a C
descriptor. These provide a
means to specify a C prototype that interoperates with a Fortran interface that
has a non-interoperable dummy
variable (18.3.6).

And the length of the character should be passed as element_len in
the various CFI_* functions.

> I guess scalars can be handled by passing to an assumed rank array.

An array of character*1 is interoperable, yes.

Regards

Thomas

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  ---
(In reply to Janne Blomqvist from comment #3)
> 1) When compiling an external procedure, for character(len=1) arguments we
> don't generate the hidden string length argument. And similarly when calling
> an external procedure, if a len=1 character is passed, we omit the hidden
> string length argument. This, I believe, is what Paul is suggesting in the
> previous comment?

Having already shot down my (2) proposal, I thought a bit more about this one,
that is omitting the hidden length argument for dummy arguments with len=1, and
when calling a procedure with a len=1 argument.

Unfortunately, beyond being a somewhat fragile heuristic, it's also
fundamentally broken. Consider

subroutine foo(a)
character(len=1) :: a
...
end subroutine foo

So with this suggestion, this procedure would be generated without the hidden
length argument. The brokenness comes from

call foo("ab")

which would generate a call to a procedure WITH the hidden string length
argument. However, this code is perfectly standard conforming, F2018 15.5.2.4
says that a character dummy argument must have a length less than or equal to
the actual argument, which is fulfilled by the above (1 <= 2). That is, we
can't special case len=1 procedures and calls in any way.

[Bug fortran/90344] [7 Regression] small code that compiles and runs in 7.3.0 but not 7.4.1

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Hi Thomas,

>  if the type is character, interoperability also requires that the length
> type parameter be omitted or be specified by an initialization
> expression whose value is one. 
> 
> F2008, 15.3.2 has the same language, as does F2018, 18.3.1.

I found this as well - thanks. I will restore the error by will restrict it to
scalar entities.

> 
> While no diagnostic is required (not a constraint), it is an error,
> and it would be good to flag it as such.
> 
> [I'll look up the array part later]

I am sure that the array part is OK. Otherwise, why have a type code for
strings?

I guess scalars can be handled by passing to an assumed rank array.

Cheers

Paul

[Bug c++/90354] [7.3 regression] Skip the not first insn when traversing the insn node

[zhongyunde at huawei dot com]

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

vfdff  changed:

   What|Removed |Added

 CC||zhongyunde at huawei dot com

--- Comment #1 from vfdff  ---
Created attachment 46298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46298=edit
mis-handling of DW_CFA_restore_state

right picture: generate DW_CFA_restore_state
left picture: mis-handling of DW_CFA_restore_state and bring into runtime fail.

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
(In reply to Paul Thomas from comment #2)
> This is already fixed on my working branch.
> 
> This used to be the error message:
> 
> Character argument ‘c’ at (1) must be length 1 because procedure ‘bar’ is
> BIND(C)
> 
> Is this required by the standard?

F2003 has

 15.2.1  Interoperability of intrinsic types

[...]

 if the type is character, interoperability also requires that the length type
parameter be omitted or be specified by an initialization
expression whose value is one. 

F2008, 15.3.2 has the same language, as does F2018, 18.3.1.

While no diagnostic is required (not a constraint), it is an error,
and it would be good to flag it as such.

[I'll look up the array part later]

[Bug fortran/90344] [7 Regression] small code that compiles and runs in 7.3.0 but not 7.4.1

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||10.0, 7.3.0, 8.3.0, 9.1.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2019-05-05
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|small code that compiles|[7 Regression] small code
   |and runs in 7.3.0 but not   |that compiles and runs in
   |7.4.1   |7.3.0 but not 7.4.1
  Known to fail||7.4.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 7.4. I did not find any other failing revision.

Workaround: use -fno-frontend-optimize.

[Bug tree-optimization/90328] Wrong loop distribution with aliasing

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
dr_may_alias_p says a and b cannot alias because:
(gdb) p addr_a->base.u.dependence_info 
$13 = {clique = 2, base = 0}
(gdb) p addr_b->base.u.dependence_info 
$14 = {clique = 2, base = 1}

which comes from
https://gcc.gnu.org/viewcvs/gcc?view=revision=260383

So I can simplify the testcase to

void g(int*__restrict x, int*y){*x=*y;}
void f(int* a,int* b){
for(int i=0;i<1024;++i)
g(a+i,b+i);
}

and the question becomes: with restrict, is it legal to call g(a+1,a)? I
believe it is, there is a clear example in the C standard that does the same
thing. And restrict is not supposed to imply anything for statements outside of
g. Maybe inlining is supposed to reset something?

I wonder how much optimization we will miss if the alias machinery is changed
to be more conservative on this testcase...

[Bug middle-end/90348] Small inlined function has local variables in invalid stack location

[mcccs at gmx dot com]

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

MCCCS  changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #2 from MCCCS  ---
/*Below's the compiler testsuite code with no headers.

Here's the assembly difference (because the difference is very small. The one
on the left works (-O1 only) while the one on the right has `-O1
-finline-small-functions`): https://www.diffchecker.com/hAYLeoPV

I've also tested it on macOS 10.14 with GCC 8, it failed too.

In addition, on Aarch64 - Raspberry/Raspbian using GCC 6 and GCC 9: GCC 9 also
failed on ARM, but GCC 6 didn't cause assertion fail, thus it's clearly a
7/8/9/10 regression.*/

/* { dg-do run } */
/* { dg-options "-O2" } */

void __attribute__ ((noinline)) set_one (unsigned char* ptr)
{
*ptr = 1;
}

int __attribute__ ((noinline)) check_nonzero (unsigned char const* in, unsigned
int len)
{
for (unsigned int i = 0; i < len; ++i) {
if (in[i] != 0) return 1;
}
return 0;
}

void set_one_on_stack () {
unsigned char buf[1];
set_one (buf);
}

int main () {
for (int i = 0; i < 5; ++i) {
unsigned char in[4];
for (int j = 0; j < i; ++j) {
in[j] = 0;
set_one_on_stack ();
}
if (check_nonzero (in, i)) {
__builtin_abort ();
}
}
}


//~ MCCCS  (DesWurstes)

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
This is already fixed on my working branch.

This used to be the error message:

Character argument ‘c’ at (1) must be length 1 because procedure ‘bar’ is
BIND(C)

Is this required by the standard?

What about?

subroutine bar(c,d) BIND(C)
  character (len=*) c(:)
  character (len=2) d(:)
end

I have been working on passing CFI descriptors to such a procedure. I guess
that the old error only pertains to scalars?

Cheers

Paul

[Bug c++/90354] New: [7.3 regression] Skip the not first insn when traversing the insn node

[zhongyunde at huawei dot com]

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

Bug ID: 90354
   Summary: [7.3 regression] Skip the not first insn when
traversing the insn node
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

simplified testcase base on g++.eh/ia64-1.C:
~/ICE » cat exp1.C 
   
zhongyunde@linux-125

#include 

using namespace std;

extern "C" void abort();
extern "C" void bar(long a0, long a1, long a2, long a3, long a4);
extern "C" void foo(long a0);

int l_0, l_1, l_2;

#define A(x,y,n) register int *x##n = ##_##n;
#define C(x,n) asm volatile ("" : "=r" (x##n) : "0" (x##n));
#define E(x,y,n) if (x##n != ##_##n) abort ();


void foo(long a0)
{
  A(p,l,0) A(p,l,1) A(p,l,2)
  C(p,0) C(p,1) C(p,2)
  bar (0, 1, 2, 3, 4);
  if (a0 == 0)
throw exception();
  C(p,0) C(p,1) C(p,2)
  E(p,l,0) E(p,l,1) E(p,l,2)
}


in function scan_trace of GCC source, we use NEXT_INSN (insn) to traversing all
the insn nodes

  for (prev = insn, insn = NEXT_INSN (insn);
   insn;
   prev = insn, insn = NEXT_INSN (insn))
{
  rtx_insn *control;

  ...
}

while in .nothrow dump, the jump_insn may in sequence but not the first insn of
the sequence , so we'll omit it and don't generate CFI label ?

(insn 121 120 51 (sequence [
(insn:TI 45 120 74 3 (set (reg:CC 158 tb)
(eq:CC (reg:SI 24 a24 [orig:180 p0 ] [180])
(reg:SI 12 a12))) exp1.C:25 960 {tsteq}
 (expr_list:REG_CYCLE (const_int 24 [0x18])
(expr_list:REG_DEAD (reg:SI 24 a24 [orig:180 p0 ] [180])
(expr_list:REG_DEAD (reg:SI 12 a12)
(nil)
(insn 74 45 46 3 (set (reg:SI 1 a1)
(plus:SI (reg:SI 0 a0)
(const_int 4 [0x4]))) exp1.C:25 4 {addsi3}
 (expr_list:REG_CYCLE (const_int 24 [0x18])
(expr_list:REG_DEAD (reg:SI 0 a0)
(nil
(jump_insn 46 74 51 3 (set (pc)
(if_then_else (eq (reg:CC 158 tb)
(const_int 0 [0]))
(label_ref:SI 52)
(pc))) exp1.C:25 57 {cbranchcc4}
 (expr_list:REG_CYCLE (const_int 24 [0x18])
(expr_list:REG_INTRA_COF (nil)
(expr_list:REG_DEAD (reg:CC 158 tb)
(expr_list:REG_BR_PROB (const_int 4 [0x4])
(nil)
 -> 52)
]) exp1.C:25 -1
 (nil))


here is the final assemble, it lacks an CFI lable.
.LVLWLABEL8:{
tsteq@ags   a24, a12
addi@agsa1, a0, 4
bf@pcu  .L4, 1   ## Not the first insn in sequence
}

...
retrr@pcu
  expect an LCFIx: here !! 
.L4:
call0@pcu   abort, 0

[Bug target/90340] Not optimal code when compiling C library for vsnprintf, code size increase 17%

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #2 from Fredrik Hederstierna 
 ---
Created attachment 46297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46297=edit
Stripped down testcase, gives +35% code size increase

Stripped down testcase, gives +35% code size increase.

[Bug target/90340] Not optimal code when compiling C library for vsnprintf, code size increase 17%

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #1 from Fredrik Hederstierna 
 ---
Stripped down the testcase some, this version gives +35% code size increase.
With gcc-8.2.0 it was 536 bytes, when gcc-9.1.0 gives 724 bytes (+188 bytes).

[Bug c++/90353] No warning on unused exception parameter with -Wall -Wextra

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(from https://stackoverflow.com/q/55977431/1918193)
Thanks.

except.c (initialize_handler_parm) says:

  /* Make sure we mark the catch param as used, otherwise we'll get a
 warning about an unused ((anonymous)).  */
  TREE_USED (decl) = 1;
  DECL_READ_P (decl) = 1;

But removing the TREE_USED line generates a nice "warning: unused variable
'k'". Running the testsuite with such a patch may help locate a testcase that
explains why this code is there.

[Bug rtl-optimization/90168] context-sensitive local register allocation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> How about adjusting REG_FREQ_MAX to be same as BB_FREQ_MAX? Now
> REG_FREQ_MAX/BB_FREQ_MAX is 1/10.

The way out is probably to use a 64-bit fixed-point type like profiling.

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||8.3.0
Version|unknown |9.1.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2019-05-05
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

--- Comment #1 from Dominique d'Humieres  ---
Likely a fall out of r269156: no ICE with -std=f2008.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
(In reply to Thomas Koenig from comment #6)
> (In reply to Janne Blomqvist from comment #5)
> > (In reply to Thomas Koenig from comment #4)
> > > Currently, I am leaning towards using an option with a mandatory
> > > warning (no way to turn it off) which does not push any string lenghts
> > > onto the stack at all, something like -fbroken-character-abi,
> > > which we would use for external procedures without an explicit interface.
> > 
> > Hmm, wouldn't this completely break procedures with "character(len=*)" dummy
> > arguments?
> 
> Yes :-(
> 
> This would be more or less equivalent to a -fbind-c flag.
> 
> >Or did mean that it would be used only for length=1 strings?
> 
> Unfortunately, the callee does not know the string length
> passed by the caller.
>  
> > > I can also extend -fc-prototypes so that it also issues prototypes
> > > for any global procedures outside of BIND(C), or add a new option.
> > 
> > This might be useful.
> 
> I just noticed that -fc-prototypes does not issue a prototype
> for a global BIND(C) procedure. I'll probably fix that one soon.

Just for the record, I have long since thought that passing the string length
as a hidden argument is a design error just as awkward of the poor array
descriptor design. We should be passing the data field of a descriptor as the
address of the string, so that there is a known offset to the string length.
This could be a generalised improvement, since it could also be used in general
for f77 argument passing and would allow us to get rid in the initialisation
and hidden descriptors nonsense in dummy handling. Storing all entities as
descriptors would eliminate huge quantities of code in trans-*.c :-)

Dream on, Paul Maybe for 11-branch?

Paul

[Bug c++/90353] No warning on unused exception parameter with -Wall -Wextra

[mark.z.harrison at gmail dot com]

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

--- Comment #1 from Mark Harrison  ---
Created attachment 46296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46296=edit
Preprocessed file created with -save-temps

[Bug c++/90353] New: No warning on unused exception parameter with -Wall -Wextra

[mark.z.harrison at gmail dot com]

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

Bug ID: 90353
   Summary: No warning on unused exception parameter with -Wall
-Wextra
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark.z.harrison at gmail dot com
  Target Milestone: ---

Created attachment 46295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46295=edit
Source file demonstrating bug

~ > cat unused.cpp 
int main()
{
try
{
throw 0;
}
catch(int k)
{
}

return 0;
}


Compile with: g++ -Wall -Wextra unused.cpp

No warnings are produced about the unused exception parameter k.

===

Version: 8.3.0

System: Manjaro Linux (variant of Arch Linux)

Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto

[Bug fortran/90352] New: [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[tkoenig at gcc dot gnu.org]

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

Bug ID: 90352
   Summary: [9/10 Regression] ICE on BIND(C) subroutine with
characters with len /= 1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

$ cat bar.f90
subroutine bar(c,d) BIND(C)
  character (len=*) c
  character (len=2) d
end
$ ~/Gcc/9-bin/gcc/f951 bar.f90
 barbar.f90:4:0:

4 | end
  | 
interner Compiler-Fehler: in gfc_trans_deferred_vars, bei
fortran/trans-decl.c:4928
0x5f20af gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc-9/gcc/fortran/trans-decl.c:4928
0x730c1d gfc_generate_function_code(gfc_namespace*)
../../gcc-9/gcc/fortran/trans-decl.c:6760
0x6be0ce translate_all_program_units
../../gcc-9/gcc/fortran/parse.c:6134
0x6be0ce gfc_parse_file()
../../gcc-9/gcc/fortran/parse.c:6337
0x706ebf gfc_be_parse_file
../../gcc-9/gcc/fortran/f95-lang.c:204
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode, wenn es dienlich ist.
Please include the complete backtrace with any bug report.
Weitere Hinweise finden Sie unter »«.
$ gfortran bar.f90
bar.f90:4:0:

4 | end
  | 
interner Compiler-Fehler: in gfc_trans_deferred_vars, bei
fortran/trans-decl.c:4928
0x5f20af gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc-9/gcc/fortran/trans-decl.c:4928
0x730c1d gfc_generate_function_code(gfc_namespace*)
../../gcc-9/gcc/fortran/trans-decl.c:6760
0x6be0ce translate_all_program_units
../../gcc-9/gcc/fortran/parse.c:6134
0x6be0ce gfc_parse_file()
../../gcc-9/gcc/fortran/parse.c:6337
0x706ebf gfc_be_parse_file
../../gcc-9/gcc/fortran/f95-lang.c:204
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode, wenn es dienlich ist.
Please include the complete backtrace with any bug report.
Weitere Hinweise finden Sie unter »«.
$ /usr/bin/gfortran-8 bar.f90
bar.f90:1:16:

 subroutine bar(c,d) BIND(C)
1
Fehler: Zeichenargument »c« bei (1) muss Länge 1 haben, da Prozedur »bar«
BIND(C) ist
bar.f90:1:18:

 subroutine bar(c,d) BIND(C)
  1
Fehler: Zeichenargument »d« bei (1) muss Länge 1 haben, da Prozedur »bar«
BIND(C) ist

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |9.2

[Bug fortran/90351] New: -fc-prototypes does not dump prototypes for external procedures

[tkoenig at gcc dot gnu.org]

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

Bug ID: 90351
   Summary: -fc-prototypes does not dump prototypes for external
procedures
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Came across this when looking at PR 90329. This is with recent trunk.

$ cat foo.f90
subroutine foo() BIND(C)
end subroutine foo
$ gfortran -c -fc-prototypes foo.f90
$ 

Probably looking at the wrong namespaces somewhere.

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[fxue at os dot amperecomputing.com]

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

--- Comment #9 from Feng Xue  ---
(In reply to Feng Xue from comment #5)
> >   I would say that top-down algorithm behaves better than bottom-up one.  I
> > implemented Callahan-Koblentz (bottom-up algorithm) in GCC about 10 years
> > ago and it behaved worse than the current one.  I think adding an additional
> Intuitively, it's better to give preference to regions with higher frequency
> to let them pick up registers earlier and with more freedom, which matches
> with bottom-up coloring strategy.
> 
> > pass over regions probably would solve the problem but it will complicate
> > already complicated RA (which is about 60K lines now). In any case I'll
> > think about this problem.
> > 
> >   The problem you are mentioning in this code is quite insignificant (one
> > memory access in the top most region).
> But it will be significant inside multi-level loop. Actually, the problem is
> exposed by a 8-level loop in a real Fortran application. 
> 
> >   
> >   I also checked the attachments.  What I see is GCC generates a better big
> > loop body (a loop with high register pressure).  GCC generated loop body has
> > 50 x86-64 insns with 22 memory accesses vs 56 with 26 memory access for 
> > LLVM.
> As far as how to spilling live range at loop boundary is concerned, gcc is
> not very efficient. To make loop body not be the focus, when we remove two
> live-range variables in original case, we can get same amount of memory
> accesses for gcc and llvm, both of which generates 9 register spills in loop
> body. I attached modified case and assembly files.

For the modified case, allocation of llvm and gcc remain nearly the same for
loop body, but as to 'lv0', llvm gets better spill/split result over gcc.

[Bug rtl-optimization/90168] context-sensitive local register allocation

[fxue at os dot amperecomputing.com]

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

--- Comment #4 from Feng Xue  ---
(In reply to Andrew Pinski from comment #3)
> >or to use float type to hold frequency?
> 
> This won't work correctly as floating point is different between hosts. 
> There has been some usage of floating point inside of GCC which was removed
> because of that issue.  I thought that was documented somewhere too.

How about adjusting REG_FREQ_MAX to be same as BB_FREQ_MAX? Now
REG_FREQ_MAX/BB_FREQ_MAX is 1/10.

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[fxue at os dot amperecomputing.com]

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

--- Comment #8 from Feng Xue  ---
Created attachment 46294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46294=edit
asm file 2 generated by llvm

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[fxue at os dot amperecomputing.com]

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

--- Comment #7 from Feng Xue  ---
Created attachment 46293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46293=edit
asm file 2 generated by gcc

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[fxue at os dot amperecomputing.com]

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

--- Comment #6 from Feng Xue  ---
Created attachment 46292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46292=edit
test case with less live ranges

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[fxue at os dot amperecomputing.com]

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

--- Comment #5 from Feng Xue  ---
>   I would say that top-down algorithm behaves better than bottom-up one.  I
> implemented Callahan-Koblentz (bottom-up algorithm) in GCC about 10 years
> ago and it behaved worse than the current one.  I think adding an additional
Intuitively, it's better to give preference to regions with higher frequency to
let them pick up registers earlier and with more freedom, which matches with
bottom-up coloring strategy.

> pass over regions probably would solve the problem but it will complicate
> already complicated RA (which is about 60K lines now). In any case I'll
> think about this problem.
> 
>   The problem you are mentioning in this code is quite insignificant (one
> memory access in the top most region).
But it will be significant inside multi-level loop. Actually, the problem is
exposed by a 8-level loop in a real Fortran application. 

>   
>   I also checked the attachments.  What I see is GCC generates a better big
> loop body (a loop with high register pressure).  GCC generated loop body has
> 50 x86-64 insns with 22 memory accesses vs 56 with 26 memory access for LLVM.
As far as how to spilling live range at loop boundary is concerned, gcc is not
very efficient. To make loop body not be the focus, when we remove two
live-range variables in original case, we can get same amount of memory
accesses for gcc and llvm, both of which generates 9 register spills in loop
body. I attached modified case and assembly files.