[Bug middle-end/91242] ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-24
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I'll take a look.

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

[bharath.appali at gmail dot com]

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

--- Comment #9 from bharath appali  ---
(In reply to Richard Biener from comment #5)
> It's the 0 - src computation that invokes undefined behavior and things go
> downhill from there.  Use 0 - (uint32_t)src here.

Can I please have any pointers which could explain why that particular
computation is invoking an undefined behaviour ? and also I'm interested to
know why this kind of behaviour is not seen when compiled with earlier gcc
versions.

Thanks in advance

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[law at redhat dot com]

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

--- Comment #18 from Jeffrey A. Law  ---
It's the aarch64's definition of CLEAR_RATIO that's coming into play here.

The hole in the structure is critical here to show the DSE pessimization. 
Changing the size of the object to something "nice" and eliminating the hole
defeats the whole purpose here. 

he fact that the aarch64 port is inlining the expansion essentially invalidates
the test, hence if there isn't some guidance from the aarch64 folks, I'm just
going to xfail it.

[Bug libstdc++/91243] New: is_invocable mishandles functions returning indestructible types by value

[rs2740 at gmail dot com]

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

Bug ID: 91243
   Summary: is_invocable mishandles functions returning
indestructible types by value
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

#include 

struct S { friend struct F; protected: ~S(); };
struct F { S operator()() { return {}; } };

static_assert(!std::is_invocable_v); // fires

The condition for is_invocable is

> The expression INVOKE(declval(), declval()...) is well-formed
> when treated as an unevaluated operand

This expression is not well-formed when treated as a normal unevaluated
operand. It's only well-formed when it's the operand of decltype, due to the
special rule in [dcl.type.decltype]p2.

libc++ hard errors for this case. MSVC accepts the snippet above.

[Bug c/91234] No warning on uninitialized variables

[srinivas.kakarla1 at tcs dot com]

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

--- Comment #2 from K_Srinivas  ---
Please let me know which gcc version can i use ?

[Bug c/89035] Request - builtins for unspecified and arbitrary values

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91225

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to David Brown from comment #2)
> > Yes, "int x = x;" does give an unspecified value without a warning.
> 
> Really, not even one from -Winit-self?

Martin Sebor explains in bug 91225 that "int x = x;" by itself is eliminated as
unused; x would have to actually be used after that to get the -Winit-self
warning.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[egallager at gcc dot gnu.org]

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

--- Comment #16 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #12)
> And then there is the case of endless loops in such functions (either
> unconditional, or ones the compiler is not able to detect), exit calls, both
> either directly in the const/pure function or in some function it calls.  So
> in all, I'm afraid such a warning would diagnose only the most trivial cases.

That would still be better than nothing.

[Bug other/44286] Use sentinel attributes in GCC

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Ralf Wildenhues from comment #2)
> Patch at .

Richard Sandiford approved the MIPS parts; cc-ing him

[Bug other/30920] Incorrect splaying that not assures the caching property

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Ian Blanes from comment #0)
> The current splaying implementation does a bottom up splaying but starting
> at the root (should do a top down). It works but performs worst. One example
> of this is that while in the implementation described in
> http://www.cs.cmu.edu/~sleator/papers/self-adjusting.pdf the root node ends
> at most two levels down, in the current implementation it can end at an
> arbiratry depth (example in the mailing list). So the property of keeping
> recently used nodes up doesn't work.
> 
> Interestingly it doesn't hurt performance so much. Aactually it improves the
> performance compared to the previous version (previous bottom up
> implementation) because of the recursive nature of the former one.
> 
> (patch and in depth explanation here)
> http://gcc.gnu.org/ml/gcc/2006-11/msg00074.html
> http://gcc.gnu.org/ml/gcc/2006-07/msg00210.html

Linked threads point to this other thread:
https://gcc.gnu.org/ml/gcc-patches/2005-10/msg00833.html
It says that Brian Makin is the original author, but I'm not seeing his email
address as cc-able here on Bugzilla... does he have a new one?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #95 from The Written Word  
---
(In reply to dave.anglin from comment #92)
> On 2019-07-23 5:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > Yeah, we had PR64919 applied and backed out only the "#undef
> > MAKE_DECL_ONE_ONLY" to work around the duplicate symbols error. We also have
> > fixes for PR60465, PR64919, PR66319, PR85412, PR87338, PR90714, r214747, and
> > Debian's ia64-disable-selective-scheduling.patch applied, in addition to 
> > some
> > local -O2=>-O0 workarounds.
> Maybe you could upload your full patch set so others can see details.

Done.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #94 from The Written Word  
---
Created attachment 46623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46623&action=edit
gcc-8.3.0 patches

Patches currently being used to build gcc-8.3.0 on HP-UX/IA

[Bug c++/70413] Class template names in anonymous namespaces are not globally unique

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
Bumping this.

We ran into a similar issue in GCC 6.3.0 on ARM with -flto. openSUSE enabled
LTO by default, so we added a test case for all platforms which support LTO
(including Debian with its stale packages that never get updated).

[Bug rtl-optimization/91137] [7/8/9 Regression] Wrong code with -O3

[amker at gcc dot gnu.org]

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

--- Comment #13 from bin cheng  ---
Author: amker
Date: Wed Jul 24 01:28:33 2019
New Revision: 273754

URL: https://gcc.gnu.org/viewcvs?rev=273754&root=gcc&view=rev
Log:
Backport from mainline
2019-07-18  Bin Cheng  

PR tree-optimization/91137
* tree-ssa-loop-ivopts.c (struct ivopts_data): New field.
(tree_ssa_iv_optimize_init, alloc_iv, tree_ssa_iv_optimize_finalize):
Init, use and fini the above new field.
(determine_base_object_1): New function.
(determine_base_object): Reimplement using walk_tree.

gcc/testsuite
2019-07-18  Bin Cheng  

PR tree-optimization/91137
* gcc.c-torture/execute/pr91137.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91137.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-loop-ivopts.c

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

[jiangning.liu at amperecomputing dot com]

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

Jiangning Liu  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Jiangning Liu  ---
Martin is arguing setting the no-warning bit in middle-end for this scenario is
not a robust solution at
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01525.html.

What about moving the case below to -O3? Could it be acceptable by
-Wmaybe-uninitialized tests?

tree base = get_base_address (lhs);
if (!nontrap->contains (lhs)
&& auto_var_p (base)
&& TREE_ADDRESSABLE (base)
&& optimization_level > 2)
  {
/* Do conditional store replacement by inserting a load. */
  }

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe  ---
Author: iains
Date: Tue Jul 23 23:20:31 2019
New Revision: 273749

URL: https://gcc.gnu.org/viewcvs?rev=273749&root=gcc&view=rev
Log:
[Darwin] Fix PR87030 add missed commit hunks.

Messed up the commit, and missed changes to gcc/config.gcc and to the comments
in some of the headers.

2019-07-24  Iain Sandoe  

gcc/

PR bootstrap/87030
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Move from here...
* config/i386/darwin32-biarch.h .. to here.
* config/i386/darwin64-biarch.h: Adjust comments.
* config/rs6000/darwin32-biarch.h: Likewise.
* config/rs6000/darwin64-biarch.h: Likewise.
* config.gcc: Missed commit from r273746
(*-*-darwin*): Don't include CPU t-darwin here.
(i[34567]86-*-darwin*): Adjust to use biarch files. Produce
an error message if i686-darwin configuration is attempted for
Darwin >= 18.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/i386/darwin.h
trunk/gcc/config/i386/darwin32-biarch.h
trunk/gcc/config/i386/darwin64-biarch.h
trunk/gcc/config/rs6000/darwin32-biarch.h
trunk/gcc/config/rs6000/darwin64-biarch.h

[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #6)
> The following test giveS ALSO an ICE with -m32
> 
> % cat boz_10.f90
> print *, real(b'1010101001101',10)
> end
> % gfortran -m32 boz_10.f90
> f951: internal compiler error: Segmentation fault: 11
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

I've thought about this, and think it can be fixed by
removing the use gfc_max_integer_kind variable.  Simply
convert the BOZ to an GMP mpz_t with a suitable width.
As I don't use multilib or the precision promoting
options I cannot test the change.

[Bug fortran/34392] BOZ diagnost invalid Fortran 2003 use with -std=f2003 warnings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug fortran/20585] [meta-bug] Fortran 2003 support

[kargl at gcc dot gnu.org]

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

Bug 34392 Summary: BOZ diagnost invalid Fortran 2003 use with -std=f2003 
warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34392

   What|Removed |Added

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

[Bug fortran/34392] BOZ diagnost invalid Fortran 2003 use with -std=f2003 warnings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed by r273747.
No back port.

% cat > a.f90
print *, sngl(Z'3FFF0080')
print *, float(Z'3FFF0080')
end
%  gfcx -o z a.f90
a.f90:1:14:

1 | print *, sngl(Z'3FFF0080')
  |  1
Error: 'a' argument of 'sngl' intrinsic at (1) must be REAL
a.f90:2:15:

2 | print *, float(Z'3FFF0080')
  |   1
Error: BOZ literal constant at (1) cannot appear in the FLOAT intrinsic
subprogram

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #8 from kargl at gcc dot gnu.org ---
Partially fixed by r273747.
No back port.
transfer() and storage_size() will be fixed shortly.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #93 from dave.anglin at bell dot net ---
On 2019-07-23 5:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> I'm doing some more testing with combinations of them, and so far I've found
> that if I start from a fresh 8.3 and apply only the essential ones, the fix
> here, the operand64 removal, the nftw workaround, and -O1 to work around the
> stage 2 ICE, I don't get the duplicate symbols but the compiler segfaults in
> libgcc configure tests in stage 2.
That should be easy to debug.

[Bug fortran/31237] [meta-bug] TRANSFER intrinsic

[kargl at gcc dot gnu.org]

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

Bug 54072 Summary: BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; 
two BOZ not rejected for IOR/IEOR/IAND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072

   What|Removed |Added

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

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #92 from dave.anglin at bell dot net ---
On 2019-07-23 5:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> Yeah, we had PR64919 applied and backed out only the "#undef
> MAKE_DECL_ONE_ONLY" to work around the duplicate symbols error. We also have
> fixes for PR60465, PR64919, PR66319, PR85412, PR87338, PR90714, r214747, and
> Debian's ia64-disable-selective-scheduling.patch applied, in addition to some
> local -O2=>-O0 workarounds.
Maybe you could upload your full patch set so others can see details.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #91 from dave.anglin at bell dot net ---
On 2019-07-23 5:53 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> In file included from
> /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/cmath:43,
>  from
> /opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:41:
> /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ext/type_traits.h:103:34:
> internal compiler error: Segmentation fault
>  struct __add_unsigned;
>   ^
Disable precompiled headers for now.  This will make it easier to find
problems.

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jul 23 23:02:07 2019
New Revision: 273748

URL: https://gcc.gnu.org/viewcvs?rev=273748&root=gcc&view=rev
Log:
2019-07-23  Steven G. Kargl  

 PR fortran/54072
 * check.c (gfc_invalid_boz): Fix comment.
 (illegal_boz_arg): New function.
 (gfc_check_transfer): Use to arguments.
 (gfc_check_storage_size): Ditto.
 (gfc_check_complex): Remove leftover comment from BOZ patch.
 * primary.c (match_boz_constant): Remove leftover comment. 

2019-07-23  Steven G. Kargl  

 PR fortran/54072
 * gfortran.dg/illegal_boz_arg_1.f90: New tests.

Added:
trunk/gcc/testsuite/gfortran.dg/illegal_boz_arg_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #90 from dave.anglin at bell dot net ---
On 2019-07-23 6:14 p.m., elowe at elowe dot com wrote:
> If you back out #undef MAKE_DECL_ONE_ONLY doesn't g++ generate code that
> crashes the HP linker?
Possibly but duplicate definitions are not the same as one only.  Consider a
static definition
in a weak function.  The undef is wrong.  The libstdc++ support will break
without one-only
support.

Also, hppa64-hpux uses the default elf definition.  So, I believe the HP ia64
linker can handle
weak definitions.  Check that all linker patches are installed.

[Bug fortran/58204] [F08] BOZ literals in the int function should not be treated as unsigned integers

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed by r273747.
No back port.
Details can be found at https://gcc.gnu.org/ml/fortran/2019-07/msg00054.html

[Bug fortran/91160] merge_bits is broken for BOZ arguments

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed by r273747.
No back port.

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #19 from Steve Ellcey  ---
Should this defect be reopened?  One of the tests that was added is failing for
me on aarch64.

FAIL: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized "return
15;"
FAIL: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized "return
15;"
FAIL: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized "return
15;"

[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Fixing the dependency for identical=true is a Good Thing(TM), but
will not be enough to fix the test case:

$ cat bar.f90
program main
  implicit none
  real, dimension(3,3,3) :: f,g
  integer :: three
  call random_number(f)
  three = 3
  g(1, 1:three, :) = matmul(f(2,1:3,2:3), f(3,2:3,:))
  print *, g(1,1:3,:)
end program main
$ gfortran -Warray-temporaries bar.f90
bar.f90:7:21:

7 |   g(1, 1:three, :) = matmul(f(2,1:3,2:3), f(3,2:3,:))
  | 1
Warnung: Zwischenergebnis-Feld bei (1) wird erzeugt [-Warray-temporaries]

The code in question, in gfc_conv_procedure_call, is

  /* Create a temporary to store the result.  In case the function
 returns a pointer, the temporary will be a shallow copy and
 mustn't be deallocated.  */
  callee_alloc = comp->attr.allocatable || comp->attr.pointer;
  gfc_trans_create_temp_array (&se->pre, &se->post, se->ss,
   tmp, NULL_TREE, false,
   !comp->attr.pointer, callee_alloc,
   &se->ss->info->expr->where);

We should special-case the case of result = function(...) here.

[Bug c++/91241] [7/8/9/10 Regression] internal compiler error: symtab_node::verify failed

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
clang++ points out that:
ice.C:4:37: warning: all paths through this function will call itself
[-Winfinite-recursion]
int *A::b(const int &, const int &) { b(); return 0; }

[Bug c++/91241] [7/8/9/10 Regression] internal compiler error: symtab_node::verify failed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug c++/91241] [7/8/9/10 Regression] internal compiler error: symtab_node::verify failed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Could be a dup of PR89605 but that doesn't seem to have started with r221736.

[Bug c++/91241] [7/8/9/10 Regression] internal compiler error: symtab_node::verify failed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|internal compiler error:|[7/8/9/10 Regression]
   |symtab_node::verify failed  |internal compiler error:
   ||symtab_node::verify failed

--- Comment #1 from Marek Polacek  ---
Started with r221736.

[Bug middle-end/91242] New: ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c

[sje at gcc dot gnu.org]

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

Bug ID: 91242
   Summary: ICE on aarch64 SVE tests -
gcc.target/aarch64/sve/clastb_[146].c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

I get ICE on these GCC tests:

FAIL: gcc.target/aarch64/sve/clastb_1.c -march=armv8.2-a+sve (internal compiler
error)
FAIL: gcc.target/aarch64/sve/clastb_4.c -march=armv8.2-a+sve (internal compiler 
error)
FAIL: gcc.target/aarch64/sve/clastb_6.c -march=armv8.2-a+sve (internal compiler 
error)


After this checkin:


commit 8482ddd3ae29c2c74f7e01fa0422ee697689e98c
Author: marxin 
Date:   Mon Jun 10 07:04:39 2019 +

Fix build with --enable-gather-detailed-mem-stats.

2019-06-10  Martin Liska  

* hash-map.h: Pass default value to hash_table ctor.
* hash-table.h: Add default value to call of a ctor.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@272104
138bc75d-0d04-0410-96
1f-82ee72b054a4



Compiler executable checksum: a0a240676a930bb65e6bc0ad707e5aee
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
during GIMPLE pass: dom
clastb_6.c: In function ‘condition_reduction’:
clastb_6.c:13:1: internal compiler error: in hashtab_chk_error, at
hash-table.c:137
   13 | condition_reduction (TYPE *a, TYPE min_v)
  | ^~~
0x604667 hashtab_chk_error()
../../gcc/gcc/hash-table.c:137
0xffbcaf hash_table::verify(std::pair > const*> const&, unsigned int)
../../gcc/gcc/hash-table.h:1036
0xffbcaf hash_table::find_slot_with_hash(std::pair > const*> const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:971
0xfdeacf build_poly_int_cst(tree_node*, poly_int<2u,
generic_wide_int > > const&)
../../gcc/gcc/tree.c:1681
0xfe3303 force_fit_type(tree_node*, poly_int<2u,
generic_wide_int > > const&, int, bool)
../../gcc/gcc/tree.c:1445
0x92b58b int_const_binop(tree_code, tree_node const*, tree_node const*, int)
../../gcc/gcc/fold-const.c:1196
0x93e28b const_binop
../../gcc/gcc/fold-const.c:1241
0x94080f const_binop(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:1719
0x10a7de3 gimple_resimplify2
../../gcc/gcc/gimple-match-head.c:255
0x11d122b gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc/gcc/gimple-match-head.c:930
0x99a14f gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
../../gcc/gcc/gimple-fold.c:6301
0x104f6d7 vr_values::vrp_visit_assignment_or_call(gimple*, tree_node**,
value_range*)
../../gcc/gcc/vr-values.c:2037
0x148ff0f evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
../../gcc/gcc/gimple-ssa-evrp-analyze.c:299
0xeb record_temporary_equivalences_from_stmts_at_dest
../../gcc/gcc/tree-ssa-threadedge.c:293
0xf01543 thread_through_normal_block
../../gcc/gcc/tree-ssa-threadedge.c:1064
0xf02f6f thread_across_edge
../../gcc/gcc/tree-ssa-threadedge.c:1372
0xf038bb thread_outgoing_edges(basic_block_def*, gcond*, const_and_copies*,
avail_exprs_stack*, evrp_range_analyzer*, tree_node* (*)(gimple*, gimple*,
avail_exprs_stack*, basic_block_def*))
../../gcc/gcc/tree-ssa-threadedge.c:1463
0xe0bd8b dom_opt_dom_walker::after_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-dom.c:1549
0x1463b17 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:354
0xe0e7bf execute
../../gcc/gcc/tree-ssa-dom.c:724
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug c++/91241] New: internal compiler error: symtab_node::verify failed

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91241
   Summary: internal compiler error: symtab_node::verify failed
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct A {
  int *b(const int & = []() -> int { return 0; }(), const int & = []() -> int {
return 0; }());
};
int *A::b(const int &, const int &) { b(); return 0; }

$ ./cc1plus -quiet ice.C
ice.C:4:54: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
4 | int *A::b(const int &, const int &) { b(); return 0; }
  |  ^
_ZZN1A1bERKiS1_Ed_NKUlvE_clEv/3 (A::) @0x7f4d010e7708
  Type: function definition analyzed
  Visibility: no_reorder public weak comdat
comdat_group:_ZZN1A1bERKiS1_Ed_NKUlvE_clEv one_only artificial
  previous sharing asm name: 0
  References: 
  Referring: 
  Function flags: body
  Called by: int* A::b(const int&, const int&)/6 
  Calls: 
_ZZN1A1bERKiS1_Ed_NKUlvE_clEv/0 (A::) @0x7f4d010e72d0
  Type: function definition analyzed
  Visibility: no_reorder public weak comdat
comdat_group:_ZZN1A1bERKiS1_Ed_NKUlvE_clEv one_only artificial
  next sharing asm name: 3
  References: 
  Referring: 
  Function flags: body
  Called by: int* A::b(const int&, const int&)/6 
  Calls: 
ice.C:4:54: internal compiler error: symtab_node::verify failed
0xd49c47 symtab_node::verify_symtab_nodes()
/home/mpolacek/src/gcc/gcc/symtab.c:1310
0xd7073c symtab_node::checking_verify_symtab_nodes()
/home/mpolacek/src/gcc/gcc/cgraph.h:646
0xd6e921 symbol_table::compile()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2598
0xd6ef62 symbol_table::finalize_compilation_unit()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2861
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #89 from EML  ---
If you back out #undef MAKE_DECL_ONE_ONLY doesn't g++ generate code that
crashes the HP linker?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #88 from The Written Word  
---
(In reply to The Written Word from comment #78)
> (In reply to dave.anglin from comment #77)
> >
> > I think you need to define _XOPEN_SOURCE_EXTENDED.  See for example
> > config/pa/pa-hpux11.h.
> 
> Yep. I forgot about PR66319.

Ok, that fixed the nftw issue. Anyone encounter this:
gmake[5]: Entering directory
`/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include'
mkdir -p ./ia64-hp-hpux11.31/bits/stdc++.h.gch
/opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include-x c++-header -nostdinc++ -g
-O2 
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include
-I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h \
-o ia64-hp-hpux11.31/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/cmath:43,
 from
/opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:41:
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ext/type_traits.h:103:34:
internal compiler error: Segmentation fault
 struct __add_unsigned;
  ^

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #87 from The Written Word  
---
(In reply to EML from comment #80)
> During stage0 - MPFR will ICE in GCC4.9.3 due to TLS. You need to go into
> the MPFR directory and re-run the same configure line from config.log, but
> add --disable-thread-safe.

We haven't had any issues with MPFR. We're using 3.1.6 built with the HP C
compiler.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #86 from The Written Word  
---
(In reply to C. Heide from comment #79)
> (In reply to The Written Word from comment #75)
> > 
> > I think a local patch might be doing this. Rebuild without it.
> 
> I did have some other patches applied from other PRs, from previous
> desperate attempts to get anything working, including PR90714, PR85412,
> PR87338, and tips from PR64919.
> 
> I'm doing some more testing with combinations of them, and so far I've found
> that if I start from a fresh 8.3 and apply only the essential ones, the fix
> here, the operand64 removal, the nftw workaround, and -O1 to work around the
> stage 2 ICE, I don't get the duplicate symbols but the compiler segfaults in
> libgcc configure tests in stage 2.
> 
> If I add the '#undef MAKE_DECL_ONE_ONLY' fix from PR64919 (is it even still
> relevant? It does seem to be for the stage 2 libgcc segfault symptom I
> see.), I start getting the duplicate symbols in stage 1 libstdc++.

Yeah, we had PR64919 applied and backed out only the "#undef
MAKE_DECL_ONE_ONLY" to work around the duplicate symbols error. We also have
fixes for PR60465, PR64919, PR66319, PR85412, PR87338, PR90714, r214747, and
Debian's ia64-disable-selective-scheduling.patch applied, in addition to some
local -O2=>-O0 workarounds.

[Bug tree-optimization/91240] New: Wrong code with -O3

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 91240
   Summary: Wrong code with -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

GCC produces wrong code with -O3.

Reproducer:

#include 

long long a;
int b[96][76];
int c[81];

void d(long long *e, int p2) { *e ^= p2; }

int main() {
  for (int f = 0; f < 80; ++f)
for (int g = 0; g < 76; ++g)
  b[f][g] = c[f] = 9094;

  for (int f = 6; f <= 9; f++)
for (int g = 6; g <= 75; g++)
  if (b[0][g])
c[f + 1] *= f + (unsigned)c[f];

  printf("%d\n", c[8]);
}

Error:
>$ gcc -O3 small.c ; ./a.out
1637288310
>$ gcc -O0 small.c ; ./a.out
-2106497818

GCC version is 10.0.0 (Rev: 273743)

[Bug debug/91239] New: gcc generates invalid .debug_macro sections (according to lld folks)

[romain.geissler at amadeus dot com]

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

Bug ID: 91239
   Summary: gcc generates invalid .debug_macro sections (according
to lld folks)
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

After a bug report opened to lld here
https://bugs.llvm.org/show_bug.cgi?id=42030, lld folks rejected it as invalid
based on the reason that apparently .debug_macro sections generated by gcc
don't see valid.

I am quoting them here, you can see my initial bug report to check what was my
initial problem:

 A symbol table entry with STB_LOCAL binding that is defined relative to one 
> of a group's sections, and that is contained in a symbol table section that 
> is not part of the group, must be discarded if the group members are 
> discarded. References to this symbol table entry from outside the group are 
> not allowed.


I think ld.bfd/gold/lld error if the section containing the relocation is
SHF_ALLOC. .debug* do not have the SHF_ALLOC flag and those relocations are
allowed.

lld resolves such relocations to 0. ld.bfd and gold, however, have some
CB_PRETEND/PRETEND logic to resolve relocations to the definitions in the
prevailing comdat groups. The code is hacky and may not suit lld.

I think the proper fix of this problem is to patch gdb to ignore 0
DW_MACRO_import.

=
Paul Robinson 2019-07-01 06:30:34 PDT
=
If references to comdats aren't being emitted correctly, that seems like
a compiler problem not a linker or debugger problem.  This has the feel
of bfd/gold working around a gcc issue.
END_OF_QUOTE

I am not sure to understand what they mean, I hope it's clearer for you ;)

Cheers,
Romain

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
Author: iains
Date: Tue Jul 23 20:31:26 2019
New Revision: 273746

URL: https://gcc.gnu.org/viewcvs?rev=273746&root=gcc&view=rev
Log:
[Darwin] Fix PR87030 and tidy config fragments.

This is about 32/64b host and multilib support across the range of Darwin
systems.

Prior to Darwin8 (OS X 10.4), the toolchains support only PowerPC and only 32b.

On Darwin8 it is possible to target a 64b multilib, but with support limited
to a few of the main libraries on the system (not a recommended configuration).

>From Darwin9 to Darwin17 (OSX 10.5 to 10.13) it is possible to have either
32 or 64b hosted toolchains, with support for a 64 or 32b multilib
respectively.

On Darwin9 the kernel is 32b, but with support for 64b executables, so it's
conventional to build a 32b host toolchain supporting a 64b multilib.  However
this is not enforced (merely a convention).

There is also some platform hardware supporting Darwin10/11 which is only 32b
and for which the same situation applies.  However, from Darwin10 to Darwin17,
the majority of platform hardware supports a 64b kernel and it's conventional
to build a 64b host toolchain with support for a 32b multilib.

On/from Darwin18 (OS X 10.14), the development headers (in the SDK) no longer
expose the interfaces for the 32b multilib support (although sufficient runtime
support remains installed that the testsuite can be run for a 32b multilib).

The PR is raised against this latter situation since the absence of exposed
interfaces causes a 'default' bootstrap fail regardless of the availability of
the runtimes.  Given the number of permutations, I felt it warranted a general
solution, especially since the current scheme of target headers and t-make
fragments has become somewhat messy.

The changes here enforce the single 32b PowerPC multilib for Darwin < 8 and the
single X86 64b multilib for Darwin >= 18.  This means that there is no longer
any need to configure Darwin18+ '--disable-multilib', but also that if you want
to use the ability to continue to test the compiler's 32b multilib there, you
need to make a configuration targeting an earlier OS version (and using the
SDK from that).

gcc/

PR bootstrap/87030
* config.gcc (*-*-darwin*): Don't include CPU t-darwin here.
(i[34567]86-*-darwin*): Adjust to use biarch files. Produce
an error message if i686-darwin configuration is attempted for
Darwin >= 18.
(x86_64-*-darwin*): Switch to single multilib for Darwin >= 18.
(powerpc-*-darwin*): Use biarch files where needed.
(powerpc64-*-darwin*): Likewise.
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Move to new biarch file.
(DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single
arch case.
* config/i386/darwin32-biarch.h: New.
* config/i386/darwin64.h: Rename.
* gcc/config/i386/darwin64-biarch.h: To this.
* config/i386/t-darwin: Rename.
* gcc/config/i386/t-darwin32-biarch: To this.
* config/i386/t-darwin64: Rename.
* gcc/config/i386/t-darwin64-biarch: To this.
* config/rs6000/darwin32-biarch.h: New.
* config/rs6000/darwin64.h: Rename.
* config/rs6000/darwin64-biarch.h: To this.
(DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single
arch case.
* config/rs6000/t-darwin8: Rename.
* config/rs6000/t-darwin32-biarch: To this.
* config/rs6000/t-darwin64 Rename.
* config/rs6000/t-darwin64-biarch: To this.


Added:
trunk/gcc/config/i386/darwin32-biarch.h
trunk/gcc/config/i386/darwin64-biarch.h
trunk/gcc/config/i386/t-darwin32-biarch
trunk/gcc/config/i386/t-darwin64-biarch
trunk/gcc/config/rs6000/darwin32-biarch.h
trunk/gcc/config/rs6000/darwin64-biarch.h
trunk/gcc/config/rs6000/t-darwin32-biarch
trunk/gcc/config/rs6000/t-darwin64-biarch
Removed:
trunk/gcc/config/i386/darwin64.h
trunk/gcc/config/i386/t-darwin
trunk/gcc/config/i386/t-darwin64
trunk/gcc/config/rs6000/darwin64.h
trunk/gcc/config/rs6000/t-darwin64
trunk/gcc/config/rs6000/t-darwin8
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h
trunk/gcc/config/rs6000/darwin.h

[Bug middle-end/35291] Missing DCE for union fields

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Fixed eons ago.

[Bug tree-optimization/86061] dead memset followed by strncpy and assignment not eliminated

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
This was fixed by my recent code to handle strncpy in DSE.  Note the test I
added to the testsuite has a smaller array size.  DSE does not attempt to do
byte tracking on objects larger than 256 bytes.  My recollection was that in
practice the ability to optimize in those cases was rare enough to not be worth
the trouble.

[Bug tree-optimization/86061] dead memset followed by strncpy and assignment not eliminated

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Tue Jul 23 20:05:48 2019
New Revision: 273745

URL: https://gcc.gnu.org/viewcvs?rev=273745&root=gcc&view=rev
Log:
Add PR markers to recent DSE changes.  And...

PR tree-optimization/86061
* gcc.dg/tree-ssa/pr86061.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr86061.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug d/91238] New: [9 Regression] internal compiler error: in add_expr, at tree.c:7794

[ibuclaw at gdcproject dot org]

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

Bug ID: 91238
   Summary: [9 Regression] internal compiler error: in add_expr,
at tree.c:7794
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Something has changed between initial 9.1.0 release and the current
gcc-9-branch, going to bisect.

Mechanically reduced test:

class Package
{
string name()
{
return "";
}
}
class ProjectGenerator
{
struct TargetInfo { }

void configurePackages(Package rootPackage, TargetInfo[string] targets)
{
void collectDependencies(ref TargetInfo)
{
}
collectDependencies(targets[rootPackage.name]);
}
}

[Bug middle-end/91233] Cannot build glibc for mips*r6 since r270955

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>They don't have hi and lo registers available (at least w/o dsp extension for 
>time being).

So don't use them if they are not present.

MIPSr6 seems to break backwards compatible in many ways, this is just one of
them.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[wilco at gcc dot gnu.org]

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

--- Comment #17 from Wilco  ---
(In reply to Jeffrey A. Law from comment #16)
> The issue here (of course) is that aarch64 has a different set of defaults
> for when to open-code vs loop vs function call.   My attempts to pick a
> better size for the objects results in failures on other targets.
> 
> Do we have a method on aarch64 to tune this stuff via flags?  Otherwise I'm
> likely to just xfail aarch64 and move on since DSE is doing what we want at
> this point if given sane input.

I don't know, this issue doesn't seem related to any backend setting - this is
a typical inline memset expansion.

Handling structures that are not a multiple of 4 or 8 are generally inefficient
on GCC given the mid-end can't deal with overlapping accesses of different
sizes. It's efficient if I change the size of the array to 8 rather than 7.

So there is a real issue here, but maybe you'd prefer a new bugreport for that?

[Bug rtl-optimization/91173] [9 Regression] ICE: in int_mode_for_mode, at stor-layout.c:403

[mbelivea at gcc dot gnu.org]

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

Matthew Beliveau  changed:

   What|Removed |Added

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

--- Comment #8 from Matthew Beliveau  ---
Backported

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #85 from dave.anglin at bell dot net ---
On 2019-07-23 12:15 p.m., elowe at elowe dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #83 from EML  ---
> GCC configure has --disable-tls.
Not the same.

I don't know if TLS will work on ia64 hpux.  I would disable for now.
>
> It is not passed to MPFR as --disable-thread-safe that I can determine - well 
> I
> tried it and it was not.
>
I  meant to just add --disable-thread-safe even though it's not a gcc configure
option.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #84 from dave.anglin at bell dot net ---
On 2019-07-23 12:15 a.m., cameron.heide at betasystems dot com wrote:
> If I add the '#undef MAKE_DECL_ONE_ONLY' fix from PR64919 (is it even still
> relevant? It does seem to be for the stage 2 libgcc segfault symptom I see.), 
> I
> start getting the duplicate symbols in stage 1 libstdc++.
The undef is wrong.  One only (weak) support is needed.  If HP linker support
is broken for .linkonce
sections, the default section selection (default_elf_select_section) will need
changing to place functions
differently.

[Bug fortran/91237] New: ICE in gfortran with preprocessor directives

[Melven.Roehrig-Zoellner at DLR dot de]

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

Bug ID: 91237
   Summary: ICE in gfortran with preprocessor directives
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Melven.Roehrig-Zoellner at DLR dot de
  Target Milestone: ---

I obtain a strange ICE for a very minimalistic piece of preprocessing
directives with gfortran (at least versions 4.8.5, 5.4.0, 8.1.0, 9.1.0 fail,
some tested on Ubuntu 16.04 and some on a SLED system):

Steps to reproduce:

> cat example.F90 
#ifndef ELEM
#   define ELEM 'Z'
#endif
#if ELEM == 'D'
#   define ELEM_TYPE real(kind=DT_ELEM_KIND)
#elif ELEM == 'Z'
#   define ELEM_TYPE complex(kind=ZT_ELEM_KIND)
#endif

> gfortran --version
GNU Fortran (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> gfortran -c example.F90 
: internal compiler error: Segmentation fault
0xb0e154 crash_signal
/tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/toplev.c:326
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/86050] Inline break tail-call optimization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-06-05 00:00:00 |2019-7-23

--- Comment #8 from Jonathan Wakely  ---
(In reply to Konstantin Kharlamov from comment #7)
> Oh, sorry, I didn't notice the testcase requires modification to start
> crashing. Yeah, it crashes with 9.1.0 too then.

It's unhelpful to post a reproducer for a bug that doesn't reproduce the bug.
The code provided should demonstrate the bug, without requiring changes.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #83 from EML  ---
GCC configure has --disable-tls.

It is not passed to MPFR as --disable-thread-safe that I can determine - well I
tried it and it was not.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #82 from dave.anglin at bell dot net ---
On 2019-07-23 11:06 a.m., elowe at elowe dot com wrote:
> During stage0 - MPFR will ICE in GCC4.9.3 due to TLS. You need to go into the
> MPFR directory and re-run the same configure line from config.log, but add
> --disable-thread-safe.
Can't you add --disable-thread-safe to configure options for gcc build?  I
think it will get passed to MPFR.

I usually build gmp, mpfr and mpc separately from gcc and install them where
gcc infrastructure can find them.
>
> The stage1 compiler will now build. Woot managed to build some version of gcc
> 8.3
>
> During stage1 - MPFR will ICE in the stage1 xgcc also due to TLS. Again you
> need to --disable-thread-safe for MPFR (making sure to set CC correctly)
>
> The stage2 compiler will now build - hey it managed to build itself.
>
> The stage2 compiler will ICE while building
> ../../../../gcc-8.3.0/libstdc++-v3/libsupc++/array_type_info.cc 
>
> well that was unexpected, since it did build itself once, but it failed
> apparently while building stage3.
Unfortunately, this indicates that the stage2 compiler is broken (miscompiled
by stage1).
One could compare the .s files generated by the stage1 and stage2 compilers.

We need details of ICE and preprocessed source for array_type_info.cc.  A
regression search
to find which change introduced this bug would also be very helpful.

[Bug rtl-optimization/91173] [9 Regression] ICE: in int_mode_for_mode, at stor-layout.c:403

[mbelivea at gcc dot gnu.org]

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

--- Comment #7 from Matthew Beliveau  ---
Author: mbelivea
Date: Tue Jul 23 15:56:22 2019
New Revision: 273741

URL: https://gcc.gnu.org/viewcvs?rev=273741&root=gcc&view=rev
Log:
PR rtl-optimization/91173

Backported from mainline
2019-07-16  Jeff Law  

PR rtl-optimization/91173
* tree-ssa-address.c (addr_for_mem_ref): If the base is an
SSA_NAME with a constant value, fold its value into the offset
and clear the base before calling gen_addr_rtx.
* g++.dg/pr91173.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/pr91173.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-address.c

[Bug rtl-optimization/91173] [9 Regression] ICE: in int_mode_for_mode, at stor-layout.c:403

[mbelivea at gcc dot gnu.org]

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

--- Comment #6 from Matthew Beliveau  ---
Author: mbelivea
Date: Tue Jul 23 15:52:48 2019
New Revision: 273740

URL: https://gcc.gnu.org/viewcvs?rev=273740&root=gcc&view=rev
Log:
PR rtl-optimization/91173

Backported from mainline
2019-07-16  Jeff Law  

PR rtl-optimization/91173
* tree-ssa-address.c (addr_for_mem_ref): If the base is an
SSA_NAME with a constant value, fold its value into the offset
and clear the base before calling gen_addr_rtx.
* g++.dg/pr91173.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/pr91173.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-address.c

[Bug tree-optimization/86050] Inline break tail-call optimization

[Hi-Angel at yandex dot ru]

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

--- Comment #7 from Konstantin Kharlamov  ---
(In reply to Aso Renji from comment #6)
> (In reply to Konstantin Kharlamov from comment #5)
> > Just tested with 8.3.0 version on the other PC, same there, i.e. stack space
> > does not increase when built with -O2. So this was fixed at least since
> > 8.3.0.
> 
> Tested _after_ remove __attribute__((noinline)) from code?
> g++ --version g++ (Debian 8.3.0-6) 8.3.0 bug still present for me.
> Change "static __attribute__((noinline)) void" to "static void" and:
> 
> Consumed 8384063 bytes
> Consumed 8384127 bytes
> Consumed 8384191 bytes
> Consumed 8384255 bytes
> Consumed 8384319 bytes
> Consumed 8384383 bytes
> Consumed 8384447 bytes
> Ошибка сегментирования

Oh, sorry, I didn't notice the testcase requires modification to start
crashing. Yeah, it crashes with 9.1.0 too then.

[Bug c/91234] No warning on uninitialized variables

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Jonathan Wakely  ---
I get a warning with -Wall

w.c: In function ‘main’:
w.c:11:9: warning: ‘a.x’ is used uninitialized in this function
[-Wuninitialized]
 int z = a.x;
 ^


GCC 5 is no longer supported anyway.

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The results of relational expressions (<, >, <=, and <=) involving pointers to
unrelated objects are undefined and unspecified in C and C++, respectively. 
(See 6.5.8, p5 in C 11 and [expr.rel], p3 in C++ 17).

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #81 from EML  ---
Correction

My make line is:

make  STAGE1_CFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" STAGE1_CXXFLAGS="-O0 -g
-D_XOPEN_SOURCE_EXTENDED" CFLAGS_FOR_TARGET="-O0 -g -D_XOPEN_SOURCE_EXTENDED"
STAGE1_TFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED"
BOOT_CFLAGS="-D_XOPEN_SOURCE_EXTENDED" LDFLAGS="-Wl,+allowdups"

(allowdups to work around the duplicate symbols)

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #80 from EML  ---
Starting from the top:

I have applied my patch in comment 63
I have applied dave's patch in comment 72
I have applied #undef MAKE_DECL_ONE_ONLY patch

My configure line is:
../gcc-8.3.0/configure --prefix=/usr/local/gcc8.3 --with-as=/usr/local/bin/as
--without-gnu-ld --disable-nls --disable-libgomp --disable-libgcj
--enable-shared --enable-threads=posix --with-gnu-as --with-ld=/usr/ccs/bin/ld
--enable-languages=c,c++


My Make line is:
make  STAGE1_CFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" STAGE1_CXXFLAGS="-O0 -g
-D_XOPEN_SOURCE_EXTENDED" CFLAGS_FOR_TARGET="-O0 -g -D_XOPEN_SOURCE_EXTENDED"
STAGE1_TFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED"
BOOT_CFLAGS="-D_XOPEN_SOURCE_EXTENDED"


My "system" compiler is GCC 4.9.3:
Target: ia64-hp-hpux11.31
Configured with: ../gcc-4.9.3/configure --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-shared
--enable-threads=posix --disable-libgomp --enable-languages=c,c++
SED=/usr/local/bin/sed AWK=/usr/local/bin/gawk LDFLAGS=-lunwind
AS=/usr/local/bin/as
Thread model: posix
gcc version 4.9.3 (GCC) 



During stage0 - MPFR will ICE in GCC4.9.3 due to TLS. You need to go into the
MPFR directory and re-run the same configure line from config.log, but add
--disable-thread-safe.

The stage1 compiler will now build. Woot managed to build some version of gcc
8.3

During stage1 - MPFR will ICE in the stage1 xgcc also due to TLS. Again you
need to --disable-thread-safe for MPFR (making sure to set CC correctly)

The stage2 compiler will now build - hey it managed to build itself.

The stage2 compiler will ICE while building
../../../../gcc-8.3.0/libstdc++-v3/libsupc++/array_type_info.cc 

well that was unexpected, since it did build itself once, but it failed
apparently while building stage3.

[Bug lto/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
We end with:

(gdb) bt
#0  0x0084a2d3 in tree_check (__t=0x0, __f=0x171bb40
"/home/marxin/Programming/gcc/gcc/ipa-devirt.c", __l=1006, __g=0x171c128
"warn_types_mismatch", __c=IDENTIFIER_NODE) at
/home/marxin/Programming/gcc/gcc/tree.h:3219
#1  0x00a74c9c in warn_types_mismatch (t1=0x7789edc8,
t2=0x774aa1f8, loc1=245888, loc2=491776) at
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:1006
#2  0x007ebaed in lto_symtab_merge_decls_2 (diagnosed_p=, first=) at /home/marxin/Programming/gcc/gcc/tree.h:3335
#3  lto_symtab_merge_decls_1 (first=) at
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:861
#4  lto_symtab_merge_decls () at
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:887
#5  0x007f7679 in read_cgraph_and_symbols (nfiles=,
fnames=) at
/home/marxin/Programming/gcc/gcc/lto/lto-common.c:2839
#6  0x007dde83 in lto_main () at
/home/marxin/Programming/gcc/gcc/lto/lto.c:616
#7  0x00c90f20 in compile_file () at
/home/marxin/Programming/gcc/gcc/toplev.c:456
#8  0x007b6318 in do_compile () at
/home/marxin/Programming/gcc/gcc/toplev.c:2188
#9  toplev::main (this=this@entry=0x7fffda4e, argc=,
argc@entry=17, argv=, argv@entry=0x7fffdb48) at
/home/marxin/Programming/gcc/gcc/toplev.c:2323
#10 0x007b9e3f in main (argc=17, argv=0x7fffdb48) at
/home/marxin/Programming/gcc/gcc/main.c:39

$ (gdb) p debug_tree(t1)
  constant 2432>
unit-size  constant 304>
align:64 warn_if_not_align:0 symtab:0 alias-set 5 canonical-type
0x7789edc8
fields 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x776bd348 precision:64
pointer_to_this >
nonlocal DF pr91222.ii:3:10 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
nonlocal DF pr91222.ii:4:10 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
context >
$3 = void
(gdb) p debug_tree(t2)
  constant 2432>
unit-size  constant 304>
align:64 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x774aa1f8
fields 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x776bd348 precision:64
pointer_to_this >
nonlocal DF pr91222-2.ii:3:10 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
nonlocal DF pr91222-2.ii:4:10 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
context 
pointer_to_this >

$ (gdb) p n1
$5 = (tree) 0x0
(gdb) p n2
$6 = (tree) 0x0

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Started with r273194.

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Revision r273162 was last good and first bad for me is r273235.

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-23
  Known to work||9.1.0
 Blocks||26163
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/91236] New: [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

Bug ID: 91236
   Summary: [10 Regression] ICE in walk_non_aliased_vuses at
gcc/tree-ssa-alias.c:3395 on aarch64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-linux-gnu
Target: aarch64-linux-gnu

I reduced that from 510.parest_r where with -O3 I get ICE for the following
test-case:

$ template  class e;
template  struct f;
template  struct f> { using d = c *; };
template  struct h;
struct m : f>> {
  typedef h<3> &g;
};
struct q {
  struct {
m::d k;
  } l;
};
class H : q {
public:
  void n(long, h<3>);
  m::g operator[](long) { return *l.k; }
};
template  class o;
template  struct F { static const int p = dim; };
template  struct h { int s[F::p]; };
template  class t;
class r {
  template 
  void u(t &, const o &, double, double, unsigned, bool);
};
template 
void r::u(t &, const o &, double, double, unsigned, bool) {
  H a;
  int b[48]{4, 8};
  a.n(2, h());
  for (int i;;)
for (int j = 0;; ++j)
  a[i].s[j] = b[j];
}
template void r::u(t<3> &, const o<3> &, double, double, unsigned, bool);

$ g++ ice.ii -c -O3
during GIMPLE pass: fre
ice.ii: In member function ‘void r::u(t&, const o&, double, double,
unsigned int, bool) [with int dim = 3]’:
ice.ii:27:6: internal compiler error: Segmentation fault
   27 | void r::u(t &, const o &, double, double, unsigned, bool) {
  |  ^
0xf163bf crash_signal
../../gcc/toplev.c:326
0x104def4 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, bool*), tree_node*
(*)(tree_node*), unsigned int&, void*)
../../gcc/tree-ssa-alias.c:3395
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I can't reproduce that on x86_64-linux-gnu.

valgrind --follow-children=yes g++ ice.ii -c -O3
valgrind: Unknown option: --follow-children=yes
valgrind: Use --help for more information or consult the user manual.
mliska@needle:/tmp> valgrind --trace-children=yes g++ ice.ii -c -O3
==11871== Memcheck, a memory error detector
==11871== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11871== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==11871== Command: g++ ice.ii -c -O3
==11871== 
==11872== Memcheck, a memory error detector
==11872== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11872== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==11872== Command:
/home/mliska/bin/gcc/lib/gcc/aarch64-unknown-linux-gnu/10.0.0/cc1plus
-fpreprocessed ice.ii -quiet -dumpbase ice.ii -mlittle-endian -mabi=lp64
-auxbase ice -O3 -o /tmp/ccBjIIl5.s
==11872== 
==11872== Invalid read of size 8
==11872==at 0x104DEF4: walk_non_aliased_vuses(ao_ref*, tree_node*, bool,
void* (*)(ao_ref*, tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*,
bool*), tree_node* (*)(tree_node*), unsigned int&, void*)
(tree-ssa-alias.c:3395)
==11872==  Address 0x78 is not stack'd, malloc'd or (recently) free'd
==11872== 
during GIMPLE pass: fre
ice.ii: In member function ‘void r::u(t&, const o&, double, double,
unsigned int, bool) [with int dim = 3]’:
ice.ii:27:6: internal compiler error: Segmentation fault
   27 | void r::u(t &, const o &, double, double, unsigned, bool) {
  |  ^
==11872== Invalid read of size 4
==11872==at 0x18FE8AC: aarch64_fallback_frame_state
(md-unwind-support.h:74)
==11872==by 0x18FE8AC: uw_frame_state_for (unwind-dw2.c:1257)
==11872==by 0x19001A3: _Unwind_Backtrace (unwind.inc:290)
==11872==by 0x18BA467: backtrace_full (backtrace.c:127)
==11872==by 0x185703F: diagnostic_action_after_output(diagnostic_context*,
diagnostic_t) (diagnostic.c:543)
==11872==by 0x18572F3: diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) (diagnostic.c:1033)
==11872==by 0x1857653: diagnostic_impl(rich_location*, int, char const*,
std::__va_list*, diagnostic_t) (diagnostic.c:1166)
==11872==by 0x1857FF7: internal_error(char const*, ...) (diagnostic.c:1547)
==11872==by 0xF163BF: crash_signal(int) (toplev.c:326)
==11872==by 0x5818863B: ??? (in /usr/lib64/valgrind/memcheck-arm64-linux)
==11872==  Address 0x28009 is not stack'd, malloc'd or (recently) free'd
==11872== 
==11872== 
==11872== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==11872==  Access not within mapped region at address 0x28009
==11872==at 0x18FE8AC: aarch64_fallback_frame_state
(

[Bug c++/91235] New: Array size expression is implicitly casted to unsigned long type

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 91235
   Summary: Array size expression is implicitly casted to unsigned
long type
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

[code]
void foo(char*);

inline void bar(int n)
{
if (__builtin_constant_p(n))
{
char a[(int)(n == 2 ? -1 : 0)];
foo(a);
}
}

void baz()
{
bar(2);
}
[/code]

When this is compiled with -O3 -Wall -Wextra -std=c++11 (tested via
godbolt.org), it produces following code:

[asm]
baz():
  push rbp
  mov rbp, rsp
  mov rdi, rsp
  call foo(char*)
  leave
  ret
[/asm]

During compilation gcc reported following warning:
[out]
: In function 'void baz()':

:7:14: warning: argument to variable-length array is too large
[-Wvla-larger-than=]

7 | char a[(int)(n == 2 ? -1 : 0)];

  |  ^

:7:14: note: limit is 9223372036854775807 bytes, but argument is
18446744073709551615

Compiler returned: 0
[out]

This means that gcc saw that n is constant, and then expression specified as
array size was evaluated and implicitly casted to unsigned type.

When I removed "foo(a);" line, this warning is gone, and gcc warned about
unused variable.

When -1 is specified as array size, it correctly report error that array size
is negative. Looks that only expressions causes this issue.

[Bug c/91234] New: No warning on uninitialized variables

[srinivas.kakarla1 at tcs dot com]

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

Bug ID: 91234
   Summary: No warning on uninitialized variables
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: srinivas.kakarla1 at tcs dot com
  Target Milestone: ---

No warning on z and a.x uninitialized variables

#include

struct xy {
int x;
int y;
};

int main(void) {

struct xy a;
int z = a.x;
printf(" \n %d" ,z);
printf(" \n %d ",a.x);
}

gcc : 5.4.0
OS  : Ubuntu 16.X

Regards,
Srinivas

[Bug tree-optimization/86050] Inline break tail-call optimization

[asorenji at gmail dot com]

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

--- Comment #6 from Aso Renji  ---
(In reply to Konstantin Kharlamov from comment #5)
> Just tested with 8.3.0 version on the other PC, same there, i.e. stack space
> does not increase when built with -O2. So this was fixed at least since
> 8.3.0.

Tested _after_ remove __attribute__((noinline)) from code?
g++ --version g++ (Debian 8.3.0-6) 8.3.0 bug still present for me.
Change "static __attribute__((noinline)) void" to "static void" and:

Consumed 8384063 bytes
Consumed 8384127 bytes
Consumed 8384191 bytes
Consumed 8384255 bytes
Consumed 8384319 bytes
Consumed 8384383 bytes
Consumed 8384447 bytes
Ошибка сегментирования

[Bug c++/91230] [9/10 Regression] Template function containing lambda expression that has auto parameter and uses __PRETTY_FUNCTION__ does not compile

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Mine then.

[Bug tree-optimization/86071] -O0 -foptimize-sibling-calls doesn't optimize

[Hi-Angel at yandex dot ru]

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

--- Comment #2 from Konstantin Kharlamov  ---
(In reply to Alexander Monakov from comment #1)
> In GCC there's no way to selectively enable a few optimizations with their
> -f flags at -O0 level: -O0 means that optimizations are completely disabled,
> regardless of -f flags. This is mentioned in the manual:
> 
>   "Most optimizations are only enabled if an -O level is set on the command
> line.  Otherwise they are disabled, even if individual optimization flags
> are specified."
> 
> 
> Tail call optimization sometimes is not applied because there's an escaping
> local variable (possibly from an inlined function), and GCC does not take
> into account its life range. This might be what you're seeing at -O3.
> There's a recent report: PR 86050.

That said, your quote from docs does not say that optimizations are completely
disabled regardless of -f. It only says that most optimizations are disabled.

And indeed: why to have options, if they doesn't work? So I think it still
qualifies as a bug, even if a low-priority one.

[Bug tree-optimization/86050] Inline break tail-call optimization

[Hi-Angel at yandex dot ru]

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

--- Comment #5 from Konstantin Kharlamov  ---
(In reply to Konstantin Kharlamov from comment #4)
> Works for me on gcc 9.1.0. I compile it as:
> 
> $ g++ test.cpp -o a -O2
> 
> And then running `./a` results in a bunch of:
> 
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes
> Consumed 80 bytes

Just tested with 8.3.0 version on the other PC, same there, i.e. stack space
does not increase when built with -O2. So this was fixed at least since 8.3.0.

[Bug tree-optimization/86050] Inline break tail-call optimization

[Hi-Angel at yandex dot ru]

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

--- Comment #4 from Konstantin Kharlamov  ---
Works for me on gcc 9.1.0. I compile it as:

$ g++ test.cpp -o a -O2

And then running `./a` results in a bunch of:

Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes

[Bug debug/91231] ICE in dwarf2out_inline_entry, at dwarf2out.c:27642

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/91231] ICE in dwarf2out_inline_entry, at dwarf2out.c:27642

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 23 12:14:27 2019
New Revision: 273736

URL: https://gcc.gnu.org/viewcvs?rev=273736&root=gcc&view=rev
Log:
2019-07-23  Richard Biener  

PR debug/91231
* lto-streamer-in.c (input_function): Drop inline-entry markers
that ended up with an unknown location block.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/lto-streamer-in.c

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de  ---
On Tue, 23 Jul 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
> 
> --- Comment #29 from Thomas Koenig  ---
> (In reply to rguent...@suse.de from comment #28)
> 
> > -fdump-tree-all-uid without the space 
> 
> OK, so this works.
> 
> What we have in the *.004t.original dump is
> 
> fs ();
> {
>   struct __class_f_S_p rhs.2D.3928;
> 
>   rhs.2D.3928 = c_ ();
>   resD.3913._vptrD.3910 = rhs.2D.3928._vptrD.3910;
>   resD.3913._dataD.3909 = rhs.2D.3928._dataD.3909;
> }
> 
> which looks, good and in *.005t.gimple
> 
> fs ();
> {
>   struct __class_f_S_p rhs.2D.3928;
> 
>   try
> {
>   c_.5_10 = c_D.3927;
>   rhs.2D.3928 = c_.5_10 ();
>   _11 = rhs.2D.3928._vptrD.3910;
>   resD.3913._vptrD.3910 = _11;
>   _12 = rhs.2D.3928._dataD.3909;
>   resD.3913._dataD.3909 = _12;
> }
>   finally
> {
>   rhs.2D.3928 = {CLOBBER};
> }
> }
> 
> From the naming convention, the variable c_D.3927 looks like something
> generated by the front end, but it's not there in the *.original dump:
> 
> $ grep 3927 proc_ptr_51.f90.00*
> proc_ptr_51.f90.005t.gimple:  c_.5_10 = c_D.3927;
> proc_ptr_51.f90.007t.omplower:  c_.5_10 = c_D.3927;
> proc_ptr_51.f90.008t.lower:  c_.5_10 = c_D.3927;
> 
> So, there might possibly be something wrong about
> 
>   rhs.2D.3928 = c_ ();
> 
> but what?

  c_D.3918 = cD.3925;
  c_.5_12 = c_D.3933;
  rhs.2D.4008 = c_.5_12 ();

which is what I showed.  So the initialization of 'c_' happens
to the variable with UID 3918 while the read from 'c_' happens
through the variable with UID 3933.  Looking at the fortran
source I assume 'c_' is a global variable so we should only
have one, correct?

I can see in .original (x86_64 btw!)

fs ()
{
  c_D.3918 = cD.3925;
  return;
}

MAIN__ ()
{
  extern struct __class_f_S_p (*) (void) c_D.3951;
(!)
...
  rhs.2D.3934 = c_ ();

(unfortunately we don't dump the UID here, but it's 3933).

this is gimplified to

  c_.5_10 = c_D.3933;
  rhs.2D.3934 = c_.5_10 ();

so this is yet another variable!?  (again extern declared)

So something is odd with how the frontend handles 'c_'.

The symbol table has two:

__f_MOD_c_/2 (c_) @0x7f763892d300
  Type: variable definition analyzed
  Visibility: public
  References:
  Referring: __f_MOD_fs/6 (write)
  Availability: not-ready
  Varpool flags:

__f_MOD_c_/15 (c_) @0x7f763892df80
  Type: variable
  Visibility: external public
  previous sharing asm name: 2
  References:
  Referring: MAIN__/8 (read)
  Availability: not-ready
  Varpool flags:

In principle this might work out but it seems that on powerpc
one gets a section anchor while the other not and we end up
disambiguating based on that.

So I'd say frontends are not expected to do this.  For example
the C fronted for a similar

void f(){}

void (*g)();
void bar()
{
  g = f;
}

int main()
{
  extern void (*g)();
  bar();
  g();
}

produces

bar ()
{
  gD.1909 = fD.1907;
}

main ()
{
  intD.6 D.1917;

  {
extern voidD.51 (*) () gD.1915;
^^ for debug info only

bar ();
g.0_1 = gD.1909; // g, merged with the earlier definition
g.0_1 ();
  }
  D.1917 = 0;
  return D.1917;
}

since the variables are not recorded as aliases but only
share the assembler name nothing in symtab_node::equal_address_to
fires.  On x86 you are lucky enough that load and store are not
re-ordered (even with -fschedule-insns).

[Bug lto/91228] [10 regression] Removing gnu_lto_v1 symbol name breaks LTO with Solaris ld

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Martin Liška  ---
[...]
> Meh, I made the +1 at a wrong place. The correction patch should look like:
>
> diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
> index bdee963634d..75159266596 100644
> --- a/libiberty/simple-object-elf.c
> +++ b/libiberty/simple-object-elf.c
> @@ -1388,8 +1388,8 @@ simple_object_elf_copy_lto_debug_sections
> (simple_object_read *sobj,
>(unsigned char *)strings,
>strsz, &errmsg, err);
>   /* Find first '\0' in strings.  */
> - gnu_lto = (char *) memchr (gnu_lto, '\0',
> -strings + strsz - gnu_lto + 1);
> + gnu_lto = (char *) memchr (gnu_lto + 1, '\0',
> +strings + strsz - gnu_lto);
>   /* Read the section index table if present.  */
>   if (symtab_indices_shndx[i - 1] != 0)
> {
>
> @Rainer: Does the patch work for you?

I just tried it on i386-pc-solaris2.11 (not a bootstrap from scratch,
but just applied the patch, restarted the build from there and ran the
testsuite): all LTO-related failures are gone.

Thanks.
Rainer

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[tkoenig at gcc dot gnu.org]

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

--- Comment #29 from Thomas Koenig  ---
(In reply to rguent...@suse.de from comment #28)

> -fdump-tree-all-uid without the space 

OK, so this works.

What we have in the *.004t.original dump is

fs ();
{
  struct __class_f_S_p rhs.2D.3928;

  rhs.2D.3928 = c_ ();
  resD.3913._vptrD.3910 = rhs.2D.3928._vptrD.3910;
  resD.3913._dataD.3909 = rhs.2D.3928._dataD.3909;
}

which looks, good and in *.005t.gimple

fs ();
{
  struct __class_f_S_p rhs.2D.3928;

  try
{
  c_.5_10 = c_D.3927;
  rhs.2D.3928 = c_.5_10 ();
  _11 = rhs.2D.3928._vptrD.3910;
  resD.3913._vptrD.3910 = _11;
  _12 = rhs.2D.3928._dataD.3909;
  resD.3913._dataD.3909 = _12;
}
  finally
{
  rhs.2D.3928 = {CLOBBER};
}
}

From the naming convention, the variable c_D.3927 looks like something
generated by the front end, but it's not there in the *.original dump:

$ grep 3927 proc_ptr_51.f90.00*
proc_ptr_51.f90.005t.gimple:  c_.5_10 = c_D.3927;
proc_ptr_51.f90.007t.omplower:  c_.5_10 = c_D.3927;
proc_ptr_51.f90.008t.lower:  c_.5_10 = c_D.3927;

So, there might possibly be something wrong about

  rhs.2D.3928 = c_ ();

but what?

[Bug debug/91231] ICE in dwarf2out_inline_entry, at dwarf2out.c:27642

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 23 11:17:37 2019
New Revision: 273734

URL: https://gcc.gnu.org/viewcvs?rev=273734&root=gcc&view=rev
Log:
2019-07-23  Richard Biener  

PR debug/91231
* lto-streamer-in.c (input_function): Drop inline-entry markers
that ended up with an unknown location block.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/lto-streamer-in.c

[Bug libstdc++/91170] [9/10 Regression] Crash in pdns resolver

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Martin Liška  ---
Michael Schroeder wrote:

As said I only had this issue when using pdns-recursor 4.1.13 on Tumbleweed,
but not with 4.2.0. Since 4.2.0 should reach Tumbleweed really soon I don't
know whether it's worth the effort.

Ciao, Michael.

[Bug debug/91231] ICE in dwarf2out_inline_entry, at dwarf2out.c:27642

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 23 10:45:59 2019
New Revision: 273733

URL: https://gcc.gnu.org/viewcvs?rev=273733&root=gcc&view=rev
Log:
2019-07-23  Richard Biener  

PR debug/91231
* lto-streamer-in.c (input_function): Drop inline-entry markers
that ended up with an unknown location block.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c

[Bug libstdc++/91170] [9/10 Regression] Crash in pdns resolver

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #6 from Martin Liška  ---
Hm, I can't reproduce that on my openSUSE TW which should have the problematic
package:

$ zypper info pdns-recursor
...
Version: 4.2.0-1.1  

$ /usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog
--log-timestamp=no --socket-dir=/tmp/ --config-dir=/etc/pdns/
Jul 23 12:32:37 Asked to run with pdns-distributes-queries set but no
distributor threads, raising to 1
PowerDNS Recursor 4.2.0 (C) 2001-2019 PowerDNS.COM BV
Using 64-bits mode. Built using gcc 9.1.1 20190611 [gcc-9-branch revision
272147].
PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it according to the terms of the GPL version 2.
If using IPv6, please raise sysctl net.ipv6.route.max_size, currently set to
4096 which is < 16384
NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable
Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16,
172.16.0.0/12
Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10,
169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fc00::/7, fe80::/10,
0.0.0.0/8, 192.0.0.0/24, 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24,
240.0.0.0/4, ::/96, :::0:0/96, 100::/64, 2001:db8::/32, 0.0.0.0, ::
PowerDNS Recursor itself will distribute queries over threads
Redirecting queries for zone 'cubes.nordisch.org' to: 172.16.16.1:53
Redirecting queries for zone '16.172.in-addr.arpa' to: 172.16.16.1:53
Inserting forward zone 'localhost' based on hosts file
Inserting reverse zone '1.0.0.127.in-addr.arpa' based on hosts file
Inserting forward zone 'i586' based on hosts file
Inserting reverse zone '157.122.168.192.in-addr.arpa' based on hosts file
Inserting forward zone 'i686' based on hosts file
Inserting reverse zone '243.122.168.192.in-addr.arpa' based on hosts file
Inserting rfc 1918 private space zones
Will not overwrite zone '16.172.in-addr.arpa' already loaded
Listening for UDP queries on 0.0.0.0:1154
Listening for UDP queries on [::]:1154
Enabled TCP data-ready filter for (slight) DoS protection
Listening for TCP queries on 0.0.0.0:1154
Listening for TCP queries on [::]:1154
Raised soft limit on number of filedescriptors to 4121 to match max-mthreads
and threads settings
Set effective group id to 441
Set effective user id to 446
Launching 1 distributor threads
Launching 2 worker threads
Done priming cache with root hints
Done priming cache with root hints
Done priming cache with root hints
Done priming cache with root hints
Enabled 'epoll' multiplexer

and I also build one from source files (w/ -flto and -O2):

$ ./pdns_recursor --daemon=no --write-pid=no --disable-syslog
--log-timestamp=no --socket-dir=/tmp/ --config-dir=/etc/pdns/
Jul 23 12:32:56 Asked to run with pdns-distributes-queries set but no
distributor threads, raising to 1
PowerDNS Recursor 0.0.17287.0.master.g34f3230a08 (C) 2001-2019 PowerDNS.COM BV
Using 64-bits mode. Built using gcc 9.1.1 20190703 [gcc-9-branch revision
273008] on Jul 23 2019 12:27:05 by mar...@marxinbox.suse.cz.
PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it according to the terms of the GPL version 2.
If using IPv6, please raise sysctl net.ipv6.route.max_size, currently set to
4096 which is < 16384
NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable
Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16,
172.16.0.0/12
Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10,
169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fc00::/7, fe80::/10,
0.0.0.0/8, 192.0.0.0/24, 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24,
240.0.0.0/4, ::/96, :::0:0/96, 100::/64, 2001:db8::/32, 0.0.0.0, ::
PowerDNS Recursor itself will distribute queries over threads
Redirecting queries for zone 'cubes.nordisch.org' to: 172.16.16.1:53
Redirecting queries for zone '16.172.in-addr.arpa' to: 172.16.16.1:53
Inserting forward zone 'localhost' based on hosts file
Inserting reverse zone '1.0.0.127.in-addr.arpa' based on hosts file
Inserting forward zone 'i586' based on hosts file
Inserting reverse zone '157.122.168.192.in-addr.arpa' based on hosts file
Inserting forward zone 'i686' based on hosts file
Inserting reverse zone '243.122.168.192.in-addr.arpa' based on hosts file
Inserting rfc 1918 private space zones
Will not overwrite zone '16.172.in-addr.arpa' already loaded
Listening for UDP queries on 0.0.0.0:1154
Listening for UDP queries on [::]:1154
Enabled TCP data-ready filter for (slight) DoS protection
Listening for TCP queries on 0.0.0.0:1154
Listening for TCP queries on [::]:1154
Raised soft limit on number of filedescriptors to 41

[Bug libstdc++/91170] [9/10 Regression] Crash in pdns resolver

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-23
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
I'll debug that.

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Richard Biener  ---
Fixed.

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 23 10:00:24 2019
New Revision: 273732

URL: https://gcc.gnu.org/viewcvs?rev=273732&root=gcc&view=rev
Log:
2019-07-23  Richard Biener  

PR tree-optimization/83518
* tree-ssa-sccvn.c (vn_reference_lookup_3): Handle aggregate
init from a constant even when partial defs are already recorded.

c/
* gimple-parser.c (c_parser_parse_gimple_body): When we have
a CFG also rebuild cgraph edges.

* gcc.dg/tree-ssa/ssa-fre-79.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-79.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/gimple-parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

[bharath.appali at gmail dot com]

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

--- Comment #8 from bharath appali  ---
** It solved the issue

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

[bharath.appali at gmail dot com]

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

--- Comment #7 from bharath appali  ---
Thanks @  Richard Biener

I solved the issue.

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

[bharath.appali at gmail dot com]

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

--- Comment #6 from bharath appali  ---
Thanks for pointing @ Andreas Schwab

I have tried with `-fno-strict-aliasing`

[Bug c++/91155] [9/10 Regression] __PRETTY_FUNCTION__ gets truncated when char template parameter is '\0'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
So with current trunk and simplified test-case:

template< char C > struct dummy {};
template< typename T > void test()
{
  __builtin_printf ("%s\n", __PRETTY_FUNCTION__);
}

int main()
{
test< dummy< '\0' > >();
}

We end here:

$ (gdb) bt
#0  fname_as_string (pretty_p=) at
/home/marxin/Programming/gcc/gcc/c-family/c-common.c:687
#1  0x009404ff in cp_make_fname_decl (loc=255730, id=, type_dep=1) at
/home/marxin/Programming/gcc/gcc/cp/decl.c:4501
#2  0x00a4ef90 in tsubst_expr (t=,
args=, complain=3, in_decl=, integral_constant_expression_p=) at
/home/marxin/Programming/gcc/gcc/tree.h:3335
#3  0x00a4bb2b in tsubst_expr (t=,
args=, complain=3, in_decl=, integral_constant_expression_p=) at
/home/marxin/Programming/gcc/gcc/tree-iterator.h:92
#4  0x00a4a23a in tsubst_expr (t=,
args=, complain=3, in_decl=, integral_constant_expression_p=) at
/home/marxin/Programming/gcc/gcc/tree.h:3721
#5  0x00a49ac9 in instantiate_decl (d=,
defer_ok=, expl_inst_class_mem_p=) at
/home/marxin/Programming/gcc/gcc/tree.h:3221
#6  0x00a704ec in instantiate_pending_templates
(retries=retries@entry=0) at /home/marxin/Programming/gcc/gcc/cp/pt.c:24896
#7  0x00988671 in c_parse_final_cleanups () at
/home/marxin/Programming/gcc/gcc/cp/decl2.c:4857
#8  0x00fe6a70 in compile_file () at
/home/marxin/Programming/gcc/gcc/toplev.c:456
#9  0x008b6788 in do_compile () at
/home/marxin/Programming/gcc/gcc/toplev.c:2188
#10 toplev::main (this=this@entry=0x7fffd9fe, argc=,
argc@entry=20, argv=, argv@entry=0x7fffdaf8) at
/home/marxin/Programming/gcc/gcc/toplev.c:2323
#11 0x008ba24f in main (argc=20, argv=0x7fffdaf8) at
/home/marxin/Programming/gcc/gcc/main.c:39

$ (gdb) p strname
$19 = {
  len = 38, 
  text = 0x2671870 "\"void test() [with T = dummy<'\\000'>]\""
}

and then cpp_interpret_string (parse_in, &strname, 1, &cstr, CPP_STRING)) is
called and we end up with:

$ (gdb) p cstr.text
$20 = (const unsigned char *) 0x26718a0 "void test() [with T = dummy<'"

Jason, may I ask for a help what to do here?

[Bug middle-end/91233] New: Cannot build glibc for mips*r6 since r270955

[dragan.mladjeno...@rt-rk.com]

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

Bug ID: 91233
   Summary: Cannot build glibc for mips*r6 since r270955
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dragan.mladjeno...@rt-rk.com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: mips

We cannot use lo and hi register in clobber list for inline syscalls [1] since
r270955 for r6 targets. They don't have hi and lo registers available (at least
w/o dsp extension for time being).

~ cat test.c 
void test () { __asm__ __volatile__("":::"lo"); }

~ ./gcc/xgcc -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=./gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: mipsisa64-elf
Configured with: ../src/gcc/configure --target=mipsisa64-elf
--enable-languages=c
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190710 (experimental) (GCC) 

~ ./gcc/xgcc -Bgcc -mips64r6 -mexplicit-relocs  test.c -S -o /dev/null
test.c: In function ‘test’:
test.c:1:16: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the
current target
1 | void test () { __asm__ __volatile__("":::"lo"); }
  |^~~

This will also affect other projects that provide a similar form of syscall
wrappers via inline assembly.

Is a reasonable compromise here to error out only if architecturally
unavailable "calle-saved" registers are found in the clobber list?

This should cover this use case and still prevent the backend for erroneously
trying to spill/restore unavailable register if that was the intention of the
original patch.

[1]
https://github.com/bminor/glibc/blob/7628a1b05adb1e4c6857b87c6f8b71a1d0b1d72c/sysdeps/unix/sysv/linux/mips/mips32/sysdep.h#L351

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
It's the 0 - src computation that invokes undefined behavior and things go
downhill from there.  Use 0 - (uint32_t)src here.

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #42 from Thomas Koenig  ---
Resolved, closing.

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[tkoenig at gcc dot gnu.org]

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

--- Comment #41 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jul 23 08:57:45 2019
New Revision: 273727

URL: https://gcc.gnu.org/viewcvs?rev=273727&root=gcc&view=rev
Log:
2019-07-23  Thomas König  

Backport from trunk
PR libfortran/91030
* gfortran.texi (GFORTRAN_FORMATTED_BUFFER_SIZE): Document.
(GFORTRAN_UNFORMATTED_BUFFER_SIZE): Likewise.

2019-07-23  Thomas König  

Backport from trunk
PR libfortran/91030
* io/unix.c (BUFFER_SIZE): Delete.
(BUFFER_FORMATTED_SIZE_DEFAULT): New variable.
(BUFFER_UNFORMATTED_SIZE_DEFAULT): New variable.
(unix_stream): Add buffer_size.
(buf_read): Use s->buffer_size instead of BUFFER_SIZE.
(buf_write): Likewise.
(buf_init): Add argument unformatted.  Handle block sizes
for unformatted vs. formatted, using defaults if provided.
(fd_to_stream): Add argument unformatted in call to buf_init.
* libgfortran.h (options_t): Add buffer_size_formatted and
buffer_size_unformatted.
* runtime/environ.c (variable_table): Add
GFORTRAN_UNFORMATTED_BUFFER_SIZE and
GFORTRAN_FORMATTED_BUFFER_SIZE.


Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/gfortran.texi
branches/gcc-9-branch/libgfortran/ChangeLog
branches/gcc-9-branch/libgfortran/io/unix.c
branches/gcc-9-branch/libgfortran/libgfortran.h
branches/gcc-9-branch/libgfortran/runtime/environ.c

[Bug lto/91228] [10 regression] Removing gnu_lto_v1 symbol name breaks LTO with Solaris ld

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Richard Biener from comment #3)
> I think I warned you in a followup to your mail(In reply to Martin Liška
> from comment #1)
> > Obviously mine.
> > @Richi: Have you seen anything similar to this?
> 
> I think I warned you in a followup to your mail that likely the renaming
> is going to break since the first zero byte is the same as "no name" which
> both Solaris and HPUX don't like.  I suggested to change
> 
>   /* Find the first '\0' in strings.  */
>   zero_byte = (char *) memchr (strings, '\0', strsz);
> 
> to
> 
>   /* Find the first '\0' in strings.  */
>   zero_byte = (char *) memchr (strings + 1, '\0', strsz);
> 
> but then Jeff approved the original...

Meh, I made the +1 at a wrong place. The correction patch should look like:

diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
index bdee963634d..75159266596 100644
--- a/libiberty/simple-object-elf.c
+++ b/libiberty/simple-object-elf.c
@@ -1388,8 +1388,8 @@ simple_object_elf_copy_lto_debug_sections
(simple_object_read *sobj,
   (unsigned char *)strings,
   strsz, &errmsg, err);
  /* Find first '\0' in strings.  */
- gnu_lto = (char *) memchr (gnu_lto, '\0',
-strings + strsz - gnu_lto + 1);
+ gnu_lto = (char *) memchr (gnu_lto + 1, '\0',
+strings + strsz - gnu_lto);
  /* Read the section index table if present.  */
  if (symtab_indices_shndx[i - 1] != 0)
{

@Rainer: Does the patch work for you?

> 
> See all the glory details in PR83452 which you now uncovered again.
> 
> Note that a way out would be to append 'gnu_lto_v1' to .strings and
> use the same name as before.  As said, eventually an empty name does it
> (but you can't use the empty name at offset zero).
> 
> > @Rainer: About what linker are we talking?

[Bug debug/91231] ICE in dwarf2out_inline_entry, at dwarf2out.c:27642

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aoliva at gcc dot gnu.org,
   ||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
So the location of the NOTE_INSN_INLINE_ENTRY BLOCK is zero.

# DEBUG INLINE_ENTRY __conv_op 

and the BLOCKs location is streamed as '2', when the location cache is applied
it becomes zero here:

  if (current_file == loc.file && current_line == loc.line
  && current_col == loc.col)
*loc.loc = current_loc;
  else
current_loc = *loc.loc = linemap_position_for_column (line_table,
  loc.col);

line changes.  Then linemap_position_for_column returns zero, current_loc
is 1879048191.

(gdb) p set->max_column_hint 
$43 = 0

still we're running into

  /* Otherwise, attempt to start a new line that can hold TO_COLUMN,
 with some space to spare.  This may or may not lead to a new
 linemap being created.  */
  line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP (set);
  r = linemap_line_start (set, SOURCE_LINE (map, r), to_column + 50);

and in linemap_line_start end up with add_map = true because
effective_column_bits is zero.

That is, the ultimative issue is that we run out of linemap space
(for no good reason in this case) which leads to some locations becoming
zero which we do not expect.

We can fixup at GIMPLE stmt stream-in time and drop the debug stmts which
make no sense anymore due to this and first and foremost fix the above
bug by not attempting to allocate space for 50 columns if max_column_hint
is zero and the actual column is zero as well.  Hmm, I guess it isn't
a global hint and LTO is really special by dropping column info...  Maybe
we shouldn't call linemap_position_for_column at all...

Anyway.  The following fixes the issue (yes, we do stream inline-entry
markers with NULL block):

Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c   (revision 273718)
+++ gcc/lto-streamer-in.c   (working copy)
@@ -1140,6 +1140,14 @@ input_function (tree fn_decl, struct dat
  ? !MAY_HAVE_DEBUG_MARKER_STMTS
  : !MAY_HAVE_DEBUG_BIND_STMTS))
remove = true;
+ /* In case the linemap overflows locations can be dropped
+to zero.  Thus do not keep nonsensical inline entry markers
+we'd later ICE on.  */
+ tree block;
+ if (gimple_debug_inline_entry_p (stmt)
+ && (block = gimple_block (stmt))
+ && !inlined_function_outer_scope_p (block))
+   remove = true;
  if (is_gimple_call (stmt)
  && gimple_call_internal_p (stmt))
{

As for the linemap issue we might be able to optimize the + 50 for LTO
somehow either by a new global parameter we set or by looking at past
column uses [of the same file]?

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

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

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

--- Comment #4 from Andreas Schwab  ---
*((uint32_t *)&tmpDst) = spfInt;

This is a strict-aliasing violation.

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

[bharath.appali at gmail dot com]

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

--- Comment #3 from bharath appali  ---
`-fwrapv` solved the issue. With earlier version of compilers i haven't found
this issue.

[Bug ada/91169] [10 regression] cd2a31a FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Eric Botcazou  ---
> Duplicate of PR tree-optimization 91180?

I don't think so: the failure(s) persist on both sparc-sun-solaris2.11
and i386-pc-solaris2.11 as of r273698.