[Bug target/91767] [10 regression] After r274953, clang-compiled xgcc segfaults during RTL pass: stv

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Isn't that a clang bug though?  hash_map has a constructor which should be
invoked by the general_scalar_chain constructor...

[Bug libgcc/91737] On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().

2019-09-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
This has been discussed over and over again.  This is an issue in the libc and
not in GCC.  In your case in libmusl.
Glibc has a similar bug and been discussed how to fix it.
The way Glibc is going to fix it (though it has not yet) is that libpthread.a
will be really just include one object file which includes all of the pthread
library.

libmusl should fix it a similar way.

[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64

2019-09-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||aarch64-linux-gnu

--- Comment #2 from Andrew Pinski  ---
room is a common symbol which causes issues.

[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64

2019-09-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766

--- Comment #1 from Andrew Pinski  ---
Try -fno-common.

[Bug target/91767] After r274953, clang-compiled xgcc segfaults during RTL pass: stv

2019-09-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767

--- Comment #1 from Andrew Pinski  ---
If anything, one of the general_scalar_chain objects is not being constructed
correctly.

That is:
hash_map defs_map;
not being done correctly.

[Bug libgomp/82391] [openacc] acc_on_device not folded at -O0

2019-09-13 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82391

--- Comment #4 from Tom de Vries  ---
Thomas, could you update this PR with the current state?

[Bug fortran/91729] [10 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6586

2019-09-13 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91729

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This patch avoids the ICE.

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 275703)
+++ gcc/fortran/match.c (working copy)
@@ -6510,7 +6510,7 @@ gfc_match_select_rank (void)
   char name[GFC_MAX_SYMBOL_LEN];
   gfc_symbol *sym, *sym2;
   gfc_namespace *ns = gfc_current_ns;
-  gfc_array_spec *as;
+  gfc_array_spec *as = NULL;

   m = gfc_match_label ();
   if (m == MATCH_ERROR)
@@ -6583,12 +6583,20 @@ gfc_match_select_rank (void)
  return m;
}

-  sym = expr1->symtree->n.sym;
-  as = sym->ts.type == BT_CLASS ? CLASS_DATA (sym)->as : sym->as;
+  if (expr1->symtree)
+   {
+ sym = expr1->symtree->n.sym;
+ as = sym->ts.type == BT_CLASS ? CLASS_DATA (sym)->as : sym->as;
+   }
+
   if (expr1->expr_type != EXPR_VARIABLE
  || !(as && as->type == AS_ASSUMED_RANK))
-   gfc_error_now ("The SELECT RANK selector at %C must be an assumed "
-  "rank variable");
+   {
+ gfc_error ("The SELECT RANK selector at %C must be an assumed "
+"rank variable");
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
 }

   m = gfc_match (" )%t");

[Bug fortran/91566] [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103

2019-09-13 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91566

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Sep 13 20:19:40 2019
New Revision: 275704

URL: https://gcc.gnu.org/viewcvs?rev=275704=gcc=rev
Log:
2019-09-13  Steven G. Kargl  

PR fortran/91566
* simplify.c (gfc_simplify_merge): Need to simplify expression
after insertation of parenthesis.

2019-09-13  Steven G. Kargl  

PR fortran/91566
* gfortran.dg/pr91566.f90:

Added:
trunk/gcc/testsuite/gfortran.dg/pr91566.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/91767] New: After r274953, clang-compiled xgcc segfaults during RTL pass: stv

2019-09-13 Thread dimitry at andric dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767

Bug ID: 91767
   Summary: After r274953, clang-compiled xgcc segfaults during
RTL pass: stv
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitry at andric dot com
  Target Milestone: ---

As reported in https://bugs.freebsd.org/240387, after the gcc10-devel port was
updated from the 20190825 snapshot to the 20190901 snapshot, bootstrapping
started to fail due to a segfault, when the host compiler is clang 8.0.

Bisecting showed that the segfaults start appearing after r274953.

The error appears for different source files, when building libgcc with xgcc,
but it always looks like:

during RTL pass: stv
/home/dim/src/gcc/libgcc/config/libbid/bid128_fma.c: In function
'bid128_ext_fma':
/home/dim/src/gcc/libgcc/config/libbid/bid128_fma.c:3569:1: internal compiler
error: Segmentation fault
 3569 | }
  | ^

Running under valgrind shows:

==19771== Invalid read of size 1
==19771==at 0x82D7DC: gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u,
unsigned long>) (src/gcc/gcc/emit-rtl.c:1013)
==19771==by 0xFFE42E: make_vector_copies
(src/gcc/gcc/config/i386/i386-features.c:716)
==19771==by 0xFFE42E: (anonymous
namespace)::general_scalar_chain::convert_registers()
(src/gcc/gcc/config/i386/i386-features.c:1173)
==19771==by 0xFFC3B8: convert
(src/gcc/gcc/config/i386/i386-features.c:1192)
==19771==by 0xFFC3B8: convert_scalars_to_vector
(src/gcc/gcc/config/i386/i386-features.c:1629)
==19771==by 0xFFC3B8: (anonymous namespace)::pass_stv::execute(function*)
(src/gcc/gcc/config/i386/i386-features.c:1767)
==19771==by 0xB3463D: execute_one_pass(opt_pass*)
(src/gcc/gcc/passes.c:2494)
==19771==by 0xB35047: execute_pass_list_1(opt_pass*)
(src/gcc/gcc/passes.c:2580)
==19771==by 0xB35059: execute_pass_list_1(opt_pass*)
(src/gcc/gcc/passes.c:2581)
==19771==by 0xB27164: execute_pass_list(function*, opt_pass*)
(src/gcc/gcc/passes.c:2591)
==19771==by 0x768E5A: cgraph_node::expand() (src/gcc/gcc/cgraphunit.c:2194)
==19771==by 0x76C4DD: expand_all_functions (src/gcc/gcc/cgraphunit.c:2332)
==19771==by 0x76C4DD: symbol_table::compile()
(src/gcc/gcc/cgraphunit.c:2688)
==19771==by 0x76CA4F: symbol_table::finalize_compilation_unit()
(src/gcc/gcc/cgraphunit.c:2868)
==19771==by 0xC150F3: compile_file() (src/gcc/gcc/toplev.c:481)
==19771==by 0xC14BCE: do_compile (src/gcc/gcc/toplev.c:2166)
==19771==by 0xC14BCE: toplev::main(int, char**) (src/gcc/gcc/toplev.c:2301)
==19771==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
==19771==

Unfortunately this does not give much more information than simply running
under gdb.  It looks like an entry in a hash map is searched for, but
unexpectedly returns NULL.  This NULL value is then passed as a rtx_def pointer
to gen_rtx_SUBREG(), which attempts to access one of the struct elements, and
this causes the segfault.

[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

2019-09-13 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708

--- Comment #14 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Sep 13 17:22:04 2019
New Revision: 275701

URL: https://gcc.gnu.org/viewcvs?rev=275701=gcc=rev
Log:
2019-09-13  Bernd Edlinger  

PR middle-end/91708
* cse.c (cse_insn): Do not replace anything with a
MEM.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c

[Bug go/91764] [10 regression] libgo build broken with Solaris grep

2019-09-13 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91764

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed by revision 275700.  I once again forgot to annotate the commit
message with the PR number.

[Bug c/91766] New: -fvisibility=hidden during -fpic still uses GOT indirection on arm64

2019-09-13 Thread blu.dark at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766

Bug ID: 91766
   Summary: -fvisibility=hidden during -fpic still uses GOT
indirection on arm64
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blu.dark at gmail dot com
  Target Milestone: ---

Passing -fvisibility=hidden does not stop GOT round-trips for global symbols
during -fpic. Example:

#if DO_HIDE
#define HIDE __attribute__ ((visibility("hidden")))
#else
#define HIDE
#endif

int room[2] HIDE;

int* foo()
{
int* p = room;
*p = 0;
return p;
}

$ gcc-8.2 -Ofast -fvisibility=hidden -fpic

foo:
adrpx1, _GLOBAL_OFFSET_TABLE_
ldr x1, [x1, #:gotpage_lo15:room]
mov x0, x1
str wzr, [x1]
ret

Explicitly hiding it via DO_HIDE works as expected:

$ gcc-8.2 -Ofast -fvisibility=hidden -fpic -DDO_HIDE

foo:
adrpx1, room
add x0, x1, :lo12:room
str wzr, [x1, #:lo12:room]
ret

Here's the godbolt link: https://godbolt.org/z/HCd2LT

[Bug c/91765] New: -Wredundant-decls conflicts with __attribute__((alias))

2019-09-13 Thread rth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91765

Bug ID: 91765
   Summary: -Wredundant-decls conflicts with
__attribute__((alias))
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

/* Header file */
extern int bar;

/* Source file */
static int foo;
extern int bar __attribute__((alias("foo")));

--

For this test case, "gcc -c -Wredundant-decls z.c" produces

z.c:6:12: warning: redundant redeclaration of ‘bar’ [-Wredundant-decls]
6 | extern int bar __attribute__((alias("foo")));
  |^~~
z.c:2:12: note: previous declaration of ‘bar’ was here
2 | extern int bar;
  |^~~

However, the alias line is not a redundant decl, but rather the
actual definition of the symbol "bar".  The syntax of the alias,
for whatever reason, requires the use of the extern keyword.

Remove the extern from the alias and we get

z.c:6:5: error: ‘bar’ defined both normally and as ‘alias’ attribute
6 | int bar __attribute__((alias("foo")));
  | ^~~

This also seems like a bug, but it's probably years too late to
change the syntax of the definition of aliases.

[Bug go/91764] [10 regression] libgo build broken with Solaris grep

2019-09-13 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91764

--- Comment #1 from Andreas Schwab  ---
That should use grep -E and ERE.

[Bug fortran/91752] BOZ constant outside DATA/INT/REAL/DBLE/CMPLX flagged as error

2019-09-13 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752

--- Comment #5 from Steve Kargl  ---
On Fri, Sep 13, 2019 at 07:34:11AM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752
> 
> --- Comment #4 from Jürgen Reuter  ---
> (In reply to kargl from comment #3)
> > See the documentation.  -fallow-invalid-boz reduces the error to a warning. 
> > The warning can only be silenced by -w.  This was done with intent.
> 
> Actually not all of them, this one is still flagged as an error:
> implicit none
> integer :: h
> h = B"11"
> select case (h)
> case (B"11")
>print *, "Found"
> end select
> end
> 

That is the intended behavior.  I did not try to
allow every previous invalid use of BOZ.  When I
made BOZ work 15 years ago, I implemented the
requirement of F95 that a BOZ is converted to the
integer with the widest decimal range (ie, either
INTEGER(8) or INTEGER(16)).  A BOZ was parsed and
immediately converted, so a BOZ could appear in any
place that an INTEGER could appear.  That was a mistake,
and undocumented behavior.  I have corrected that
mistake.

This used to compile with gfortran where INTEGER(8)
is the integer with widest kind:

module m
  interface prn
module procedure prn4
module procedure prn8
  end interface prn
  contains
subroutine prn4(i)
   integer(4), intent(in) :: i
   print *, i
end subroutine prn4
subroutine prn8(i)
   integer(8), intent(in) :: i
   print *, i
end subroutine prn8
end module m

program foo
  use m
  call prn(B'11')
end program foo

It now issues an error and -fallow-invalid-boz will
not downgrade the error in this case.  Because a BOZ
is a typeless and kindless entity, there is no way
to resolve the interface.

Sure, you can argue that if gfortran use to compile
some garbage code, it should always compile that
garbage code.  My stance is gfortran should reject
the garbage.

[Bug go/91764] [10 regression] libgo build broken with Solaris grep

2019-09-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91764

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug go/91764] New: [10 regression] libgo build broken with Solaris grep

2019-09-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91764

Bug ID: 91764
   Summary: [10 regression] libgo build broken with Solaris grep
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
Target: *-*-solaris2.11

When I first tried to bootstrap on Solaris 11.3 after the Go 1.13 import,
bootstrap was broken building libgo.  This can be seen e.g. building 
internal/cpu: the .dep file is created with

/usr/gnu/bin/mkdir -p internal; files=`echo
/vol/gcc/src/hg/trunk/local/libgo/go
/internal/cpu/cpu.go
/vol/gcc/src/hg/trunk/local/libgo/go/internal/cpu/cpu_386.g
o /vol/gcc/src/hg/trunk/local/libgo/go/internal/cpu/cpu_no_init.go
/vol/gcc/src/
hg/trunk/local/libgo/go/internal/cpu/cpu_ppc64x.go
/vol/gcc/src/hg/trunk/local/l
ibgo/go/internal/cpu/cpu_x86.go cpugen.go 

which includes quite a number of files that shouldn't be there due to build 
tags (like cpu_no_init.go and cpu_ppc64x.go on i386-pc-solaris2.11).

This leads to compilation failures like

/vol/gcc/src/hg/trunk/local/libgo/go/internal/cpu/cpu_ppc64x.go:27:1: error:
redefinition of 'doinit'
   27 | func doinit() {
  | ^
/vol/gcc/src/hg/trunk/local/libgo/go/internal/cpu/cpu_no_init.go:16:1: note:
previous definition of 'doinit' was here
   16 | func doinit() {
  | ^
/vol/gcc/src/hg/trunk/local/libgo/go/internal/cpu/cpu_x86.go:39:1: error:
redefinition of 'doinit'
   39 | func doinit() {
  | ^

and many more which turns out to be due to this change:

diff --git a/libgo/match.sh b/libgo/match.sh
--- a/libgo/match.sh
+++ b/libgo/match.sh
@@ -135,7 +135,7 @@ for f in $gofiles; do

 if test x$tag1 != xnonmatchingtag -a x$tag2 != xnonmatchingtag; then
# Pipe through cat so that `set -e` doesn't affect fgrep.
-   tags=`sed '/^package /q' < $f | grep '^// +build ' | cat`
+   tags=`sed '/^package /q' < $f | grep '^// \?+build ' | cat`
[...]
@@ -143,7 +143,7 @@ for f in $gofiles; do
case $tag in
"//")
;;
-   "+build")
+   "+build" | "//+build")

While the old form of the RE (^// +build ) matches the build tags with both
Solaris grep (/bin/grep) and GNU grep, the second form only works with GNU
grep, effectively breaking build tags.

For the moment, I've worked around this by installing GNU grep, but there
should
be a better way, especially given that this has worked correctly for years.

[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs

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

--- Comment #2 from Richard Biener  ---
The disambiguation needs "translation" (vn_reference_lookup_3 using the
original
ref for path-based disambiguation), but we do not allow this when looking
across backedges in the maybe_skip_until walk and the loop we have to cross
in alias disambiguation looks like

 do
   {
  if (n <= i)
break;
  ptr->a[i].foo = 1; // this stmt to disambiguate against
   }
 while (1);

but then DOM is happy with this structure because it valueizes in the IL
itself.  So the guard against backedges must be too conservative since
DOM also walks across them.  I've added this as fix for PR87132.

[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018

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

--- Comment #11 from Richard Biener  ---
Created attachment 46880
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46880=edit
prototype

This improves code-gen to use pextrw where possible but that doesn't make any
measurable difference on runtime.  Maybe the example loop isn't representative
or the improvement isn't big enough.

[Bug middle-end/91753] Bad register allocation of multi-register types

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

--- Comment #4 from Wilco  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Wilco from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > lower-subreg should have be able to help here.  I wonder why it did not 
> > > ...
> > 
> > I'm not sure how it can help. 
> 
> I think you misunderstood what this pass does.
> It does exactly what you think it should do:
> /* Decompose multi-word pseudo-registers into individual
>pseudo-registers when possible and profitable.  This is possible
>when all the uses of a multi-word register are via SUBREG, or are
>copies of the register to another location.  Breaking apart the
>register permits more CSE and permits better register allocation.
> 
> The only difference is the creating part which missing.

Yes but the issue is that you can't remove all the subregs since the TBX
instructions really need a 512-bit register. The slim dump for x1 =
vqtbx4q_u8(x1, table,x1):

   30: r94:XI#0=r105:V16QI
   31: r95:XI=r94:XI
  REG_DEAD r94:XI
   32: r95:XI#16=r101:V16QI
   33: r96:XI=r95:XI
  REG_DEAD r95:XI
   34: r96:XI#32=r102:V16QI
   35: r97:XI=r96:XI
  REG_DEAD r96:XI
   36: r97:XI#48=r106:V16QI
   38: r100:V16QI=unspec[r100:V16QI,r97:XI,r100:V16QI] 186
  REG_DEAD r97:XI

As you can see it creates the 512-bit XI register via a complex sequence of 4
subreg lvalues.

[Bug target/91749] [10 Regression] ICE in arm_asm_trampoline_template, at config/arm/arm.c:3973

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

--- Comment #3 from Martin Liška  ---
Yes, the known-to-work is a bit misleading here.
Anyway, the cross compiler is configured like this:

$ ~/BIG/bin/arm/dev/shm/buildbot/install/gcc/bin/arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/marxin/BIG/bin/arm/dev/shm/buildbot/install/gcc/bin/arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/marxin/BIG/bin/arm/dev/shm/buildbot/install/gcc/bin/../lib/gcc/arm-linux-gnueabi/10.0.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with:
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--disable-multilib --enable-checking=release
--prefix=/dev/shm/buildbot/install/gcc --target=arm-linux-gnueabi
--with-as=/usr/bin/arm-suse-linux-gnueabi-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190912 (experimental)
22116957c80879f7e46949c5bb65d174d375c43f (GCC)

[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-13
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It works fine on x86_64-linux with {,-m32} but fails with
-fno-use-linker-plugin.
This causes the global vars to not resolve to constants.  With -fno-tree-vrp
it passes because DOM optimizes the bptr2->a[ij].bar load.  FRE misses this
for some reason, I'll investigate why.

[Bug fortran/91716] [9/10 Regression] ICE in output_constant, at varasm.c:5026

2019-09-13 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91716

--- Comment #3 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Sep 13 11:33:18 2019
New Revision: 275698

URL: https://gcc.gnu.org/viewcvs?rev=275698=gcc=rev
Log:
2019-09-13  Bernd Edlinger  

PR fortran/91716
* trans-array.c (gfc_conv_array_initializer): Always assign the
array type of the field to the string constant.

testsuite:
2019-09-13  Bernd Edlinger  

PR fortran/91716
* gfortran.dg/pr91716.f90: New test.

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

[Bug c++/91761] Overloaded new operator compiled with -O3 option distorts original C++ code

2019-09-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91761

--- Comment #5 from Andrew Pinski  ---
(In reply to Dávid Bolvanský from comment #4)
> But GCC 5.5 could remove one malloc-free pair
> https://godbolt.org/z/fDJZs0
> 
> New optimization in gcc 6 actually made the code worse..

But the code is undefined.  the old GCC did not take into account that fact and
was able to optimize it away.  In new GCC it takes into account that before the
constructor is run, the object values is undefined.

Plus this change is actually documented in the porting to guide of GCC 6:
https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse

With almost your exact testcase.

[Bug lto/91763] [10 regression] go.go-torture/execute/printnil.go FAILs

2019-09-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug lto/91763] New: [10 regression] go.go-torture/execute/printnil.go FAILs

2019-09-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763

Bug ID: 91763
   Summary: [10 regression] go.go-torture/execute/printnil.go
FAILs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ian at airs dot com, marxin at gcc dot gnu.org, rguenth at 
gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11

Between 20190910 (r275594) and 20190911 (r275651),
go.go-torture/execute/printnil.go
began to FAIL on Solaris/x86 and Solaris/SPARC:

+FAIL: go.go-torture/execute/printnil.go execution, -flto

(only with -flto, 32 and 64-bit sparc, 32-bit only x86, only when using gas).

SIGABRT: abort
PC=0xfcfb9715 m=0 sigcode=18446744073709551615

goroutine 1 [running]:
__sighndlr
:0
__lwp_sigqueue
:0

Thread 8 received signal SIGABRT, Aborted.
[Switching to Thread 6 (LWP 6)]
0xfcfb9715 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfcfb9715 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfcfb1fbf in thr_kill () from /lib/libc.so.1
#2  0xfcef92fa in raise () from /lib/libc.so.1
#3  0xfcecb226 in abort () from /lib/libc.so.1
#4  0xfdaa67b5 in runtime.throwException ()
at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:128
#5  0xfdf4d907 in runtime.unwindStack ()
at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:521
#6  runtime.gopanic (e=...)
at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:715
#7  0xfdaa7639 in runtime_panicstring (s=0xfda87a15 "nil pointer dereference")
at /vol/gcc/src/hg/trunk/local/libgo/runtime/panic.c:49
#8  0xfdaa54c8 in __go_runtime_error (i=6)
at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-runtime-error.c:95
#9  0x08053c43 in main.MyType.String (pointer=0x0)
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/printnil.go:11
#10 0xfdc04049 in fmt.pp.handleMethods (p=0x8ee, verb=115)
at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:630
#11 0xfdc032ec in fmt.pp.printArg (p=0x8ee, arg=..., verb=115)
at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:713
#12 0xfdc05d8e in fmt.pp.doPrintf (p=0x8ee, format=..., a=...)
at /vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:1030
#13 0xfdc06866 in fmt.Sprintf (format=..., a=...) at
/vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go:219
#14 0x08053ccc in main.main () at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/printnil.go:16

A reghunt identified this patch

2019-09-11  Richard Biener  

* lto-opts.c (lto_write_options): Stream -g when debug is enabled.
* lto-wrapper.c (merge_and_complain): Pick up -g.
(append_compiler_options): Likewise.
(run_gcc): Re-instantiate handling -g0 at link-time.
* doc/invoke.texi (flto): Document debug info generation.

as the culprit.  I haven't dug further yet.

[Bug c++/91761] Overloaded new operator compiled with -O3 option distorts original C++ code

2019-09-13 Thread david.bolvansky at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91761

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #4 from Dávid Bolvanský  ---
But GCC 5.5 could remove one malloc-free pair
https://godbolt.org/z/fDJZs0

New optimization in gcc 6 actually made the code worse..

[Bug fortran/91752] BOZ constant outside DATA/INT/REAL/DBLE/CMPLX flagged as error

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

--- Comment #4 from Jürgen Reuter  ---
(In reply to kargl from comment #3)
> See the documentation.  -fallow-invalid-boz reduces the error to a warning. 
> The warning can only be silenced by -w.  This was done with intent.

Actually not all of them, this one is still flagged as an error:
implicit none
integer :: h
h = B"11"
select case (h)
case (B"11")
   print *, "Found"
end select
end

[Bug target/91749] [10 Regression] ICE in arm_asm_trampoline_template, at config/arm/arm.c:3973

2019-09-13 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91749

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #2 from Christophe Lyon  ---
Thumb-1 is not supported when using FDPIC.

In arm_option_override, we have:
  if (TARGET_FDPIC)
{
  arm_pic_register = FDPIC_REGNUM;
  if (TARGET_THUMB1)
sorry ("FDPIC mode is not supported in Thumb-1 mode");
}

but using -mflip-thumb overrides this check, and forces thumb-1 mode, hence the
failures.