[Bug go/88406] [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL

2019-05-20 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406

Rainer Orth  changed:

   What|Removed |Added

Summary|[9/10 regression] Many  |[9 regression] Many 64-bit
   |64-bit Solaris 10/SPARC |Solaris 10/SPARC execution
   |execution tests FAIL|tests FAIL

--- Comment #6 from Rainer Orth  ---
Not a GCC 10 regression: Solaris 10 support already removed.

[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c

2019-05-17 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/90518] New: ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c

2019-05-17 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518

Bug ID: 90518
   Summary: ICE: in emit_move_insn, at expr.c:3745 in
gcc.dg/gimplefe-40.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11, mips64el-unknown-linux-gnu,
s390x-ibm-linux-gnu, ia64-suse-linux-gnu

Between 20190515 (r271254) and 20190516 (r271294), gcc.dg/gimplefe-40.c began
to ICE on 64-bit Solaris/SPARC:

+FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
+FAIL: gcc.dg/gimplefe-40.c (test for excess errors)

There are also reports for a couple more targets.

during RTL pass: expand
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/gimplefe-40.c: In function
'load':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/gimplefe-40.c:6:1: internal
compiler error: in emit_move_insn, at expr.c:3745
0x6fdf57 emit_move_insn(rtx_def*, rtx_def*)
/vol/gcc/src/hg/trunk/local/gcc/expr.c:3745
0x71131f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/vol/gcc/src/hg/trunk/local/gcc/expr.c:9721
0x5a1037 expand_gimple_stmt_1
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3798
0x5a1037 expand_gimple_stmt
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3859
0x5a810b expand_gimple_basic_block
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5895
0x5aa9ab execute
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:6518

[Bug target/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

2019-05-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90503

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/90503] New: [10 regression] gcc.target/i386/pr22076.c FAILs

2019-05-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90503

Bug ID: 90503
   Summary: [10 regression] gcc.target/i386/pr22076.c FAILs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86, x86_64

Between 20190514 (r271183) and 20190515 (r271254), the
gcc.target/i386/pr22076.c
testcase regressed on several x86 targets:

+FAIL: gcc.dg/tree-ssa/vector-6.c scan-tree-dump-times ccp1 "Now a gimple
register: v" 4

I'm seeing it on 64-bit Solaris/x86, but there are also reports for Linux/x86
and Darwin/x86_64.

[Bug middle-end/90502] [10 regression] gcc.dg/tree-ssa/vector-6.c FAILs

2019-05-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90502

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/90502] New: [10 regression] gcc.dg/tree-ssa/vector-6.c FAILs

2019-05-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90502

Bug ID: 90502
   Summary: [10 regression] gcc.dg/tree-ssa/vector-6.c FAILs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86, x86_64, aarch64, powerpc, powerpc64le

Between 20190514 (r271183) and 20190515 (r271254), the
gcc.dg/tree-ssa/vector-6.c
testcase regressed on several targets:

+FAIL: gcc.dg/tree-ssa/vector-6.c scan-tree-dump-times ccp1 "Now a gimple
register: v" 4

I'm seeing it on both 32 and 64-bit Solaris/x86, but there are also several
other
gcc-testresults reports.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

2019-05-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/90501] New: [10 regression] ICE: address taken, but ADDRESSABLE bit not set

2019-05-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501

Bug ID: 90501
   Summary: [10 regression] ICE: address taken, but ADDRESSABLE
bit not set
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ibuclaw at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11, i386-pc-solaris2.11

Between 20190514 (r271183) and 20190515 (r271254), a single D testcase started
to FAIL on both 32-bit Solaris/SPARC and x86:

+FAIL: gdc.test/runnable/mars1.d -O2   (internal compiler error)
+FAIL: gdc.test/runnable/mars1.d -O2 -finline-functions   (internal compiler
error)

In function 'test14782':
d21: error: address taken, but ADDRESSABLE bit not set
PHI argument

for PHI node
_21 = PHI <(2), _22(4)>
during GIMPLE pass: einline
d21: internal compiler error: verify_ssa failed
0x937fdd9 verify_ssa(bool, bool)
/vol/gcc/src/hg/trunk/local/gcc/tree-ssa.c:1193
0x90296e8 execute_function_todo
/vol/gcc/src/hg/trunk/local/gcc/passes.c:1970
0x902a3b2 do_per_function
/vol/gcc/src/hg/trunk/local/gcc/passes.c:1638
0x902a4a0 execute_todo
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2017

[Bug libstdc++/90440] [8/9 regression] Solaris/SPARC 10 fails to find

2019-05-15 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #14 from Rainer Orth  ---
Nothing to be sensibly done in gcc.

[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS

2019-05-15 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug go/90482] New: [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS

2019-05-15 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482

Bug ID: 90482
   Summary: [10 regression] Many 32-bit Solaris/SPARC tests FAIL
with SIGBUS
   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: sparc*-sun-solaris2.11

Between 20190426 (r270592) and 20190502 (r270801), quite a number of 32-bit
libgo tests started to FAIL on Solaris 11/SPARC:

+FAIL: archive/tar
+FAIL: archive/zip
+FAIL: cmd/go/internal/cache
+FAIL: cmd/go/internal/generate
+FAIL: cmd/go/internal/get
+FAIL: cmd/go/internal/imports
+FAIL: cmd/go/internal/load
+FAIL: cmd/go/internal/modconv
+FAIL: cmd/go/internal/modfetch
+FAIL: cmd/go/internal/modfetch/codehost
+FAIL: cmd/go/internal/modfile
+FAIL: cmd/go/internal/modload
+FAIL: cmd/go/internal/mvs
+FAIL: cmd/go/internal/search
+FAIL: cmd/go/internal/web2
+FAIL: cmd/go/internal/work
+FAIL: crypto/ecdsa
+FAIL: crypto/elliptic
+FAIL: crypto/tls
+FAIL: crypto/x509
+FAIL: encoding/json
+FAIL: go/constant
+FAIL: go/doc
+FAIL: go/importer
+FAIL: go/internal/gccgoimporter
+FAIL: go/internal/gcimporter
+FAIL: go/internal/srcimporter
+FAIL: go/parser
+FAIL: go/types
+FAIL: image/draw
+FAIL: index/suffixarray
+FAIL: internal/x/net/http/httpproxy
+FAIL: io/ioutil
+FAIL: log
+FAIL: mime/multipart
+FAIL: mime/quotedprintable
+FAIL: net/http/fcgi
+FAIL: net/http/httptest
+FAIL: net/http/httputil
+FAIL: reflect
+FAIL: regexp
+FAIL: regexp/syntax
+FAIL: runtime/pprof/internal/profile

A reghunt revealed that this was caused by

The first bad revision is:
changeset:   52654:1c7bcc41ff5f
user:ian@138bc75d-0d04-0410-961f-82ee72b054a4
date:Wed May 01 21:34:16 2019 +
summary: compiler,runtime: do more direct interfaces
unexpected fault address 49
fatal error: fault
[signal SIGBUS: bus error code=1 addr=49 pc=4272022460]

goroutine 1 [running, locked to thread]:
runtime.dopanic_m
/var/gcc/reghunt/trunk/libgo/go/runtime/panic.go:1037
runtime.fatalthrow
/var/gcc/reghunt/trunk/libgo/go/runtime/panic.go:906
runtime.throw
/var/gcc/reghunt/trunk/libgo/go/runtime/panic.go:877
runtime.sigpanic
/var/gcc/reghunt/trunk/libgo/go/runtime/signal_unix.go:347
runtime.sighandler
/var/gcc/reghunt/trunk/libgo/go/runtime/signal_sighandler.go:100
runtime.sigtrampgo
/var/gcc/reghunt/trunk/libgo/go/runtime/signal_unix.go:314
__sighndlr
:0
regexp..z2fsyntax.ranges.Less
/var/gcc/reghunt/trunk/libgo/go/regexp/syntax/parse.go:1868
sort.medianOfThree
/var/gcc/reghunt/trunk/libgo/go/sort/sort.go:76
sort.doPivot
/var/gcc/reghunt/trunk/libgo/go/sort/sort.go:105
sort.quickSort
/var/gcc/reghunt/trunk/libgo/go/sort/sort.go:190
sort.Sort
/var/gcc/reghunt/trunk/libgo/go/sort/sort.go:218
syntax.cleanClass
/var/gcc/reghunt/trunk/libgo/go/regexp/syntax/parse.go:1631
regexp..z2fsyntax.parser.parseClass
/var/gcc/reghunt/trunk/libgo/go/regexp/syntax/parse.go:1617
regexp..z2fsyntax.Parse
/var/gcc/reghunt/trunk/libgo/go/regexp/syntax/parse.go:774
regexp.compile
/var/gcc/reghunt/trunk/libgo/go/regexp/regexp.go:168
regexp.Compile
/var/gcc/reghunt/trunk/libgo/go/regexp/regexp.go:131
regexp.MustCompile
/var/gcc/reghunt/trunk/libgo/go/regexp/regexp.go:270
cmd..z2fgo..z2finternal..z2fmodfile..import
/var/gcc/reghunt/trunk/libgo/go/cmd/go/internal/modfile/rule.go:157
__go_init_main
   
/var/gcc/reghunt/libgo32/52654/sparc-sun-solaris2.11/libgo/gotest8213/test/_testmain.go:1
runtime.main
/var/gcc/reghunt/trunk/libgo/go/runtime/proc.go:209

goroutine 4 [syscall]:
goroutine in C code; stack unavailable
created by os..z2fsignal.os..z2fsignal..init0
/var/gcc/reghunt/trunk/libgo/go/os/signal/signal_unix.go:29 +36
/var/gcc/reghunt/trunk/libgo/testsuite/gotest[689]: wait: 8385: Terminated
Keeping gotest8213
FAIL: cmd/go/internal/modload

gdb shows

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfe97d644 in regexp..z2fsyntax.ranges.Less (ra=..., i=0, j=28)
at /var/gcc/reghunt/trunk/libgo/go/regexp/syntax/parse.go:1868
1868return p[i] < p[j] || p[i] == p[j] && p[i+1] > p[j+1]
(gdb) where
#0  0xfe97d644 in regexp..z2fsyntax.ranges.Less (ra=..., i=0, j=28)
at /var/gcc/reghunt/trunk/libgo/go/regexp/syntax/parse.go:1868
#1  0xfea1e3bc in sort.medianOfThree (data=..., m1=0, m0=14, m2=27)
at /var/gcc/reghunt/trunk/libgo/go/sort/sort.go:76
#2  0xfea1e4a8 in sort.doPivot (hi=, lo=0, data=...)
at /var/gcc/reghunt/trunk/libgo/go/sort/sort.go:105
#3  sort.quickSort (data=..., a=0, b=, maxDepth=9)
at /var/gcc/reghunt/trunk/libgo/go/sort/sort.go:190
#4  0xfea1e9c8 in sort.Sort (data=...)
 

[Bug libstdc++/90440] [8/9 regression] Solaris/SPARC 10 fails to find

2019-05-14 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440

Rainer Orth  changed:

   What|Removed |Added

Summary|[8/9/10 regression] |[8/9 regression]
   |Solaris/SPARC 10 fails to   |Solaris/SPARC 10 fails to
   |find  |find 

--- Comment #11 from Rainer Orth  ---
Removing gcc 10 from the summary: Solaris 10 support is just being dropped.

[Bug d/88238] libphobos compile problems on Solaris 10

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #46309|0   |1
is obsolete||

--- Comment #6 from Rainer Orth  ---
Created attachment 46331
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46331=edit
Fix libphobos compilation on Solaris 10 (PR d/88238)

Apart from a few cleanups and minor bug fixes, this patch adds to the previous
version a workaround for the lack of dl_iterate_phdr in 64-bit Solaris 10/SPARC
libdl.  The function is missing simply due to a packaging mistake: it actually
lives in ld.so.1, libdl.so.1 only being a filter on that.  Since one cannot
link
to ld.so.1 directly and getting at dl_iterate_phdr using dlsym fails due to
another
bug, I'm again using a libgdc_s.so.1 helper library which implements that
filter.

Since it uses a Solaris ld-specific linker map file, it can only be built with
ld directly, not the linker gcc was configured with, and thus not with libtool.
The patch consists primarily of additions to DRUNTIME_LIBRARIES_DL_ITERATE_PHDR
to detect the situation, the mapfile and libdruntime/Makefile.am code to create
the helper lib.

It was tested on sparc-sun-solaris2.10 and sparc-sun-solaris2.11 and as in the
x86 case, testsuite results between the two are now almost identical.

If deemed appropriate, the patch would only go onto the gcc-9 branch since
Solaris 10 support on mainline is about to be ripped out.

[Bug d/88238] libphobos compile problems on Solaris 10

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

--- Comment #5 from Rainer Orth  ---
Created attachment 46329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46329=edit
Use __tls_get_addr indirectly on 64-bit Solaris/x86

This patch addresses the execution failures on 64-bit Solaris/x86 when
-z relax=transtls is not available (as on Solaris 10 and Illumos).  It's based
on the observation that the linker bug losing the call to __tls_get_addr only
occurs when linking an executable, while shared objects (and position
independent
exeutables, which aren't supported on Solaris 10) are unaffected.  So the
workaround
consists in always funneling the call to __tls_get_addr through a helper shared
object, libgdc_s.so.1, which provides __tls_get_addr_s and passes its args to
the real __tls_get_addr.

The attached patch implements this, and bootstrap on i386-pc-solaris2.10 and
i386-pc-solaris2.11 provided almost exactly the same libphobos and gdc test
results.

There are a few rough edges at the moment:

* That new libgdc_s should only be used with -static-libphobos.  The shared
  libgdruntime.so isn't affected from the ld bug.  It would be silly to depend
  no that helper lib if it's not really needed.  Still need to figure out how
  to do this.

* A few comment cleanups are in order.

With that fixed, the patch could go onto mainline, thus benefitting Illumos,
and the gcc-9 branch as a prerequisite should we decide to add the rest of the
Solaris 10 support there.

[Bug d/88238] libphobos compile problems on Solaris 10

2019-05-07 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238

Rainer Orth  changed:

   What|Removed |Added

  Attachment #45109|0   |1
is obsolete||

--- Comment #3 from Rainer Orth  ---
Created attachment 46309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46309=edit
Clean patch

This patch allowed me to build and test libphobos on Solaris 10/x86 and Solaris
10/SPARC.
However, 64-bit testing on Solaris 10/x86 only works with gld since ld doesn't
support -z relax=transtls.  What's worse, due to some packagaing accident or
some
such,
Solaris 10/SPARC has dl_iterate_phdr in the 32-bit libdl.so.1, but the 64-bit
libdl.so.1 is older and lacks the function.

Apart from that, test results are not too bad, so I wanted the patch recorded
for posteriority ;-)

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

2019-04-23 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #9 from Rainer Orth  ---
Reopening as explained in Comment 7.

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

2019-04-23 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139

--- Comment #8 from Rainer Orth  ---
Created attachment 46231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46231=edit
gcc 8 reduced testcase

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

2019-04-23 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139

--- Comment #7 from Rainer Orth  ---
While my original testcase fails on gcc 7, 8, and 9, the one reduced using gcc
9
only failed on trunk.  I've now ran creduce with the original testcase against
both gcc 7 and 8.  Each run produced a different reduced testcase, neither of
which is fixed by applying the trunk patch to the branches.

[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601

2019-04-23 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139

--- Comment #6 from Rainer Orth  ---
Created attachment 46230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46230=edit
gcc 7 reduced testcase

[Bug middle-end/90139] New: ICE in emit_block_move_hints, at expr.c:1601

2019-04-18 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139

Bug ID: 90139
   Summary: ICE in emit_block_move_hints, at expr.c:1601
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

Created attachment 46194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46194=edit
reduced testcase

The following reduced testcase ICEs on trunk:

$ ./xg++ -B./ -S -m64 -O skcms.ii
during RTL pass: expand
skcms.ii: In function ‘void m()’:
skcms.ii:7:6: internal compiler error: in emit_block_move_hints, at expr.c:1601
7 | void m() {
  |  ^
0x9a8f4f emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long long, unsigned long long, unsigned long long, unsigned long
long)
/vol/gcc/src/hg/trunk/local/gcc/expr.c:1601
0x9a9043 emit_block_move(rtx_def*, rtx_def*, rtx_def*, block_op_methods)
/vol/gcc/src/hg/trunk/local/gcc/expr.c:1655
0xe8dd23 emit_partition_copy
/vol/gcc/src/hg/trunk/local/gcc/tree-outof-ssa.c:226
0xe8dd23 insert_part_to_rtx_on_edge
/vol/gcc/src/hg/trunk/local/gcc/tree-outof-ssa.c:391
0xe8dd23 elim_create
/vol/gcc/src/hg/trunk/local/gcc/tree-outof-ssa.c:677
0xe8dd23 eliminate_phi
/vol/gcc/src/hg/trunk/local/gcc/tree-outof-ssa.c:735
0xe8dd23 expand_phi_nodes(ssaexpand*)
/vol/gcc/src/hg/trunk/local/gcc/tree-outof-ssa.c:988
0x84bd23 execute
/vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:6486

While the original testcase shows the same ICE back to gcc 5, this one also
ICEs on mainline.

[Bug d/90130] New: gdc.test/runnable/test12.d FAILs

2019-04-17 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130

Bug ID: 90130
   Summary: gdc.test/runnable/test12.d FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-solaris2.11

The gdc.test/runnable/test12.d test FAILs on Solaris 11/SPARC with Robin's
big-endian
patches applied:

FAIL: gdc.test/runnable/test12.d -finline-functions -funittest -g   execution
test

core.exception.AssertError@runnable/test12.d(630): Assertion failure

/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/deh.d:499 _d_throw
[0x1001bb58f]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:441
onAssertError [0x1001b880b]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:641
_d_assert [0x1001b8e13]
runnable/test12.d:630 int test12.hoge(test12.S29) [0x100112ddf]
runnable/test12.d:642 void test12.test29() [0x100112e4b]
runnable/test12.d:1220 _Dmain [0x100114fc7]

Thread 2 hit Breakpoint 1, test12.hoge(test12.S29) (s=...)
at runnable/test12.d:624
624 char[10] b;
(gdb) n
625 printf("%x\n", s);
(gdb) p s
$1 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) n
ffbfe4d0
626 sprintf(b.ptr, "%x", s);
(gdb) n
630 assert(b[0 .. 7] == "1020304");
(gdb) p b
$2 = "ffbfe4d0\000\377"

This ia another call-by-value vs. call-by-reference issue: the test assumes
that passing a small struct (struct S29) happens by value.  While this is true
in some ABIs, it's certainly not in others (like the 32-bit SPARC one) where
even small structs are passed by reference.  PR d/90079 is another instance
of the same problem.

(gdb) p/x *
$11 = {a = 0x1, b = 0x2, c = 0x3, d = 0x4}
(gdb) p s
$12 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) p/x *(int *)
$13 = 0x1020304

However, the test also FAILs on 64-bit SPARC where small structs *are* passed
by value:

(gdb) p s
$1 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) p b
$2 = "\000\000\000\000\000\000\000\000\000"
(gdb) n
625 printf("%x\n", s);
(gdb) n
0
626 sprintf(b.ptr, "%x", s);
(gdb) n
630 assert(b[0 .. 7] == "1020304");
(gdb) p b
$3 = "0\000\377\377\377\377\377\377\377\377"
(gdb) p/x *(int *)
$9 = 0x1020304

I don't fully see why yet, however all this strongly argues that this part of
testcase is bogus: you cannot pass a struct to sprintf whose format string
expects an int.

[Bug d/90130] gdc.test/runnable/test12.d FAILs

2019-04-17 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC

2019-04-15 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079

Rainer Orth  changed:

   What|Removed |Added

  Attachment #46161|0   |1
is obsolete||
  Attachment #46162|0   |1
is obsolete||

--- Comment #4 from Rainer Orth  ---
Created attachment 46171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46171=edit
Revised working patch

[Bug d/90063] druntime DSO first assertion fails on Solaris/SPARC

2019-04-15 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Orth  ---
(In reply to ibuclaw from comment #1)
> After others have been committed, can you post a new stacktrace for this?

After the move to gcc/sections, rt/bss_section.c is gone and so are both
rt_get_bss_start and the assert.  I've bootstrapped on sparc-sun-solaris2.11
with the additonal big-endian and Solaris/SPARC patches and the problem is
gone.

[Bug d/88150] Use sections_elf_shared.d on Solaris

2019-04-14 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150

--- Comment #14 from Rainer Orth  ---
Author: ro
Date: Sun Apr 14 09:30:42 2019
New Revision: 270347

URL: https://gcc.gnu.org/viewcvs?rev=270347=gcc=rev
Log:
Work around lack of dlpi_tls_modid before Solaris 11.5

2019-04-14  Rainer Orth  
Iain Buclaw  

PR d/88150
* m4/druntime/os.m4 (DRUNTIME_OS_DLPI_TLS_MODID): New macro.
* configure.ac: Use it.
Call AC_USE_SYSTEM_EXTENSIONS.
* configure: Regenerate.
* Makefile.in, libdruntime/Makefile.in, src/Makefile.in,
testsuite/Makefile.in: Regenerate.
* libdruntime/gcc/config.d.in (OS_Have_Dlpi_Tls_Modid): Define.
* libdruntime/gcc/sections/elf_shared.d: Import gcc.config.
(scanSegments)  [OS_Have_Dlpi_Tls_Modid]: Use
dlpi_tls_modid.
[Solaris]: Use dlinfo(RTLD_DI_LINKMAP) to get rt_tlsmodid.
Otherwise clear pdso._tlsMod, pdso._tlsSize.
(getTLSRange) [Solaris && !OS_Have_Dlpi_Tls_Modid]: Readjust mod.

Modified:
trunk/libphobos/ChangeLog
trunk/libphobos/Makefile.in
trunk/libphobos/configure   (contents, props changed)
trunk/libphobos/configure.ac
trunk/libphobos/libdruntime/Makefile.in
trunk/libphobos/libdruntime/gcc/config.d.in
trunk/libphobos/libdruntime/gcc/sections/elf_shared.d
trunk/libphobos/m4/druntime/os.m4
trunk/libphobos/src/Makefile.in
trunk/libphobos/testsuite/Makefile.in

[Bug d/88150] Use sections_elf_shared.d on Solaris

2019-04-14 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150

--- Comment #13 from Rainer Orth  ---
Author: ro
Date: Sun Apr 14 09:18:42 2019
New Revision: 270345

URL: https://gcc.gnu.org/viewcvs?rev=270345=gcc=rev
Log:
Use gcc/sections/elf_shared.d on Solaris 11.5 (PR d/88150)

PR d/88150
* libdruntime/gcc/sections/elf_shared.d [Solaris] (SharedELF): Set
to true.
Import core.sys.solaris.dlfcn, core.sys.solaris.link,
core.sys.solaris.sys.elf, core.sys.solaris.sys.link.
(dummy_ref): Declare.
(initSections): Initialize dummy_ref.
(getDependencies): Set strtab.
(handleForName): Don't dlclose handle.
(findDSOInfoForAddr): Set IterateManually.
(getprogname): Declare.
(progname): Use it.
* libdruntime/gcc/sections/package.d [Solaris]: Import
gcc.sections.elf_shared instead of gcc.sections.solaris.
* libdruntime/gcc/sections/solaris.d: Remove.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES): Remove
gcc/sections/solaris.d.

Removed:
trunk/libphobos/libdruntime/gcc/sections/solaris.d
Modified:
trunk/libphobos/ChangeLog
trunk/libphobos/libdruntime/Makefile.am
trunk/libphobos/libdruntime/Makefile.in
trunk/libphobos/libdruntime/gcc/sections/elf_shared.d
trunk/libphobos/libdruntime/gcc/sections/package.d

[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC

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

--- Comment #2 from Rainer Orth  ---
Created attachment 46162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46162=edit
Working patch

This patch not only compiles, but gives way better results.  I need to analyze
them in detail, but it seems that most of the remaining failures are either
generic Solaris issues that also exist on Solaris/x86 or big-endian problems
also seen, e.g., on S/390.

[Bug d/90079] New: SEGV in _aaKeys, _aaValues on 32-bit SPARC

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

Bug ID: 90079
   Summary: SEGV in _aaKeys, _aaValues on 32-bit SPARC
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-*

Created attachment 46161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46161=edit
Trial patch

All aa tests currently SEGV on 32-bit Solaris/SPARC, e.g.

FAIL: libphobos.aa/test_aa.d execution test

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x0009c9b0 in rt.aaA.Impl.length() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:87
87  assert(used >= deleted);
(gdb) where
#0  0x0009c9b0 in rt.aaA.Impl.length() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:87
#1  0x0009c960 in rt.aaA.AA.empty() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:44
#2  0x0009e83c in _aaValues (aa=..., keysz=4, valsz=1, 
tiValueArray=0x718fc ) at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:513
#3  0x00082688 in object.values!(test_aa.testKeysValues1().T[int],
test_aa.testKeysValues1().T, int).values(test_aa.testKeysValues1().T[int])
(aa=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:2171
#4  0x00077a9c in test_aa.testKeysValues1() ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/libphobos.aa/test_aa.d:56
#5  0x00077604 in D main ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/libphobos.aa/test_aa.d:3

1: x/i $pc
=> 0x9c9b0 <_D2rt3aaA4Impl6lengthMxFNaNbNdNiZk+32>: ld  [ %g1 + 8 ], %g2
(gdb) p/x $g1
$1 = 0x8

(gdb) up
#1  0x0009c960 in rt.aaA.AA.empty() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:44
44  return impl is null || !impl.length;
(gdb) p impl
$2 = (rt.aaA.Impl *) 0x8

(gdb) up
#2  0x0009e864 in _aaValues (aa=..., keysz=4, valsz=1, 
tiValueArray=0x718fc ) at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:513
513 if (aa.empty)
(gdb) p aa
$2 = {impl = 0x8}

(gdb) up
#3  0x000826b0 in object.values!(test_aa.testKeysValues1().T[int],
test_aa.testKeysValues1().T, int).values(test_aa.testKeysValues1().T[int])
(aa=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:2171
2171auto a = cast(void[])_aaValues(cast(inout(void)*)aa, Key.sizeof,
Value.sizeof, typeid(Value[]));
(gdb) p aa
$3 = {ptr = 0xfef11000}

Closer investigation reveals object.d calls _aaValues (and _aaKeys)
incorrectly:

While the implementation expects a struct AA

libdruntime/rt/aaA.d:extern (C) inout(void[]) _aaValues(inout AA aa, in size_t
keysz, in size_t valsz,

the call passes a void * instead:
libdruntime/object.d:inout(void)[] _aaValues(inout void* p, in size_t
keysize, in size_t valuesize, const TypeInfo tiValArray) pure nothrow;
libdruntime/object.d:auto a = cast(void[])_aaValues(cast(inout(void)*)aa,
Key.sizeof, Value.sizeof, typeid(Value[]));

The problem is that on 32-bit SPARC small structs are passed by reference, so
there's a mismatch between caller and callee.

On 64-bit SPARC instead, they are passed by value, so the mismatch doesn't
matter and the tests PASS.

So far, I've not yet managed to figure out the correct way to fix this, though:
while the attached patch allows libdruntime to compile, test_aa.d fails:

libdruntime/object.d:2172: error: cannot cast expression aa of type T[int] to
inout(AA)
testsuite/libphobos.aa/test_aa.d:56: error: template instance
object.values!(T[int], T, int) error instantiating
libdruntime/object.d:2150: error: cannot cast expression aa of type int[T] to
inout(AA)
testsuite/libphobos.aa/test_aa.d:66: error: template instance
object.keys!(int[T], int, T) error instantiating
libdruntime/object.d:2150: error: cannot cast expression aa of type int[string]
to inout(AA)
testsuite/libphobos.aa/test_aa.d:75: error: template instance
object.keys!(int[string], int, string) error instantiating
libdruntime/object.d:2172: error: cannot cast expression aa of type int[string]
to inout(AA)

[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90065] Unaligned accesses on strict-alignment targets

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90065] New: Unaligned accesses on strict-alignment targets

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065

Bug ID: 90065
   Summary: Unaligned accesses on strict-alignment targets
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-*

Created attachment 46153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46153=edit
src/std/math.d alignment hack

I see a couple of tests FAIL due to the same issue on Solaris/SPARC: they die
with SIGBUS due to unaligned access, which is a no-no on strict-alignment
targets.

FAIL: libphobos.phobos_shared/std/math.d execution test

Segmentation fault while running unittests:

/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:492 extern
(C) void core.runtime.runModuleUnitTests().unittestSegvHandler(int,
core.sys.posix.signal.siginfo_t*, void*) [0x590cd287]
??:? __sighndlr [0x7eee41bf]
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178 pure
nothrow @nogc @trusted real std.math.NaN(ulong) [0x10003744c]
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:1052
nothrow @nogc @safe void std.math.__unittestL1001_11() [0x100037273]
/var/gcc/gcc-9.0.1-20190408/11.5-gcc-gas-libphobos/sparc-sun-solaris2.11/libphobos/testsuite/libphobos9/:1
void std.math.__modtest() [0x1000697c3]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558
__foreachbody2 [0x590cd3c7]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599 __lambda2
[0x590f4a2b]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777
__foreachbody2 [0x5910f63f]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69
int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref
rt.sections_elf_shared.DSO)) [0x5911444f]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770 int
rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*)))
[0x5910f527]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1598 int
object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*))
[0x590f26fb]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:548
runModuleUnitTests [0x590cd0b3]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:484 runAll
[0x5910323b]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:460 tryExec
[0x5910317b]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:493 _d_run_main
[0x59103073]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/__entrypoint.di:44 main
[0x100069b3f]
??:? _start [0x100032e8b]

truss shows the SIGBUS

Incurred fault #5, FLTACCESS  %pc = 0x10003734C
  siginfo: SIGBUS BUS_ADRALN addr=0x7FFFD942
Received signal #10, SIGBUS [default]
  siginfo: SIGBUS BUS_ADRALN addr=0x7FFFD942

but gdb currently mis-reports it as SIGSEGV (as does the libdruntime signal
handler).

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00010003734c in std.math.NaN(ulong) (payload=291)
at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178
6178*cast(ulong*)(2+cast(ubyte*)()) = v;
(gdb) where
#0  0x00010003734c in std.math.NaN(ulong) (payload=291)
at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178
#1  0x000100037174 in std.math.__unittestL1001_11() ()
at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:1052
#2  0x0001000696c4 in std.math.__modtest() () at :1
#3  0x57bcd3c8 in __foreachbody2 (this=0x7fffdfe8, 
m=0x1001bfb38 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558
#4  0x57bf4a2c in object.ModuleInfo.__lambda2 (
this=0x7fffdf10, 
m=0x1001bfb38 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599
#5  0x57c0f640 in rt.minfo.__foreachbody2 (this=0x7fffde38, 
sg=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777
#6  0x57c14450 in rt.sections_elf_shared.DSO.opApply(scope int(ref
rt.sections_elf_shared.DSO) delegate) (dg=...)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69
#7  0x57c0f528 in rt.minfo.moduleinfos_apply(scope
int(immutable(object.ModuleInfo*)) delegate) (dg=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770
#8  0x57bf26fc in object.ModuleInfo.opApply(scope
int(object.ModuleInfo*) delegate) (dg=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1598
#9  0x57bcd0b4 in runModuleUnitTests ()
at /vol/gcc/src/hg/trunk/solaris/libpho

[Bug d/90064] InSituRegion lacks SPARC64 support

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90064] New: InSituRegion lacks SPARC64 support

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064

Bug ID: 90064
   Summary: InSituRegion lacks SPARC64 support
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-*

Created attachment 46152
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46152=edit
InSituRegion SPARC64 support

This tests only FAILs on 64-bit SPARC:

FAIL:
libphobos.phobos_shared/std/experimental/allocator/building_blocks/bitmapped_block.d
(test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/solaris/libphobos/src/std/experimental/allocator/building_blocks/region.d:402:
error: undefined identifier 'growDownwards'
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/experimental/allocator/building_blocks/bitmapped_block.d:698:
error: template instance
std.experimental.allocator.building_blocks.region.InSituRegion!(10240LU, 64LU)
error instantiating
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/experimental/allocator/building_blocks/bitmapped_block.d:700:
note: while evaluating: static assert(hasMember!(InSituRegion!(10240LU, 64LU),
"allocateAll"))

The fix is trivial: just handle SPARC64 like SPARC.  The attached patch does
that.

[Bug d/90063] druntime DSO first assertion fails on Solaris/SPARC

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90063] New: druntime DSO first assertion fails on Solaris/SPARC

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063

Bug ID: 90063
   Summary: druntime DSO first assertion fails on Solaris/SPARC
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

The next issue with Solaris 11/SPARC execution tests is

FAIL: libphobos.druntime_shared/core/internal/hash.d execution test

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x5e858a5c in gc_malloc (sz=80, ba=0, 
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gc/proxy.d:117
117 return instance.malloc(sz, ba, ti);
(gdb) where
#0  0x5e858a5c in gc_malloc (sz=80, ba=0, 
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gc/proxy.d:117
#1  0x5e7cc74c in core.memory.GC.malloc(ulong, uint, const(TypeInfo)) (
sz=80, ba=0, 
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/memory.d:380
#2  0x5e803b60 in _d_newclass (
ci=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/lifetime.d:96
#3  0x5e7c9df8 in onAssertError (file=..., line=398)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:441
#4  0x5e7ca444 in _d_assert (file=..., line=398)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:641
#5  0x5e815684 in _d_dso_registry (data=0x7fffcfa0)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:398
#6  0x000137cc in gdc.dso_ctor () at :1
#7  0x00012db8 in global constructors keyed to 4core8internal4hash ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/internal/hash.d:1
#8  0x7f3253f0 in call_array () from /usr/lib/sparcv9/ld.so.1
#9  0x7f325590 in call_init () from /usr/lib/sparcv9/ld.so.1
#10 0x7f335524 in elf_bndr () from /usr/lib/sparcv9/ld.so.1
#11 0x7f316488 in elf_rtbndr () from /usr/lib/sparcv9/ld.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

#5  0x5e815684 in _d_dso_registry (data=0x7fffcfa0)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:398
398 assert(handleForAddr(data._slot) ==
handleForAddr(_get_bss_start));

(gdb) p data
$2 = (rt.sections_elf_shared.CompilerDSOData *) 0x7fffcfa0
(gdb) p *data
$3 = {_version = 1, _slot = 0x1001043d8 , 
  _minfo_beg = 0x1001043b0 <__start_minfo>, _minfo_end = 0x1001043c8}

I haven't dug further yet why this fails on Solaris/SPARC, but not on
Solaris/x86.

For the moment, I've just disabled the assert.

[Bug d/90062] SPARC stack alignment is wrong

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90062] New: SPARC stack alignment is wrong

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062

Bug ID: 90062
   Summary: SPARC stack alignment is wrong
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-*

Created attachment 46151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46151=edit
Correct SPARC stack alignment

Even after the ucontext_t and makecontext patches, Solaris/SPARC execution
tests
were still FAILing (seem to have lost the notes about the details ;-(). 
However,
I found that stack alignment was less than the SPARC ABI requires, i.e.
doubleword
alignment (also cf. sparc/sparc.h (SPARC_STACK_ALIGN)).

The attached patch fixes that.  However, I've been lazy and always use the
existing
16-byte alignment code, although strictly speaking 32-bit SPARC only needs 8
bytes.

[Bug d/90060] libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90060] New: libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060

Bug ID: 90060
   Summary: libphobos.druntime_shared/core/thread.d FAILs on
Solaris/SPARC
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

Created attachment 46150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46150=edit
Use __makecontext_v2 on Solaris/SPARC

With PR d/90059 fixed, (at least) the core.thread unittest FAILs:

FAIL: libphobos.druntime_shared/core/thread.d execution test

Segmentation fault while running unittests:


Program terminated with signal SIGSEGV, Segmentation fault.
#0  sparc64_is_sighandler (nframes=, 
cfa=0x7fffd470, pc=0x7f5c3fc8) at ./md-unwind-support.h:39
39  ./md-unwind-support.h: No such file or directory.
[Current thread is 2 (Thread 1 (LWP 1))]
(gdb) where
#0  sparc64_is_sighandler (nframes=, 
cfa=0x7fffd470, pc=0x7f5c3fc8) at ./md-unwind-support.h:39
#1  sparc64_fallback_frame_state (fs=0x7fffbf40, 
context=0x7fffbb50) at ./md-unwind-support.h:271
#2  uw_frame_state_for (context=context@entry=0x7fffbb50, 
fs=fs@entry=0x7fffbf40)
at
/builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind-dw2.c:1257
#3  0x73b0ed50 in _Unwind_Backtrace (
trace=0x5d362438 , 
trace_argument=0x7fffc6d0)
at
/builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind.inc:290
#4  0x5d3624dc in backtrace_simple (state=0x7f5e8000, 
skip=, callback=0x5d2e40c4 , 
error_callback=0x5d2e4c28 , 
data=0x7fffc860)
at /vol/gcc/src/hg/trunk/solaris/libbacktrace/simple.c:106
#5  0x5d2e521c in gcc.backtrace.LibBacktrace.this(int) (
this=0x7fffc860, firstFrame=1)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/backtrace.d:227
#6  0x5d2cd248 in
core.runtime.runModuleUnitTests().unittestSegvHandler(int,
core.sys.posix.signal.siginfo_t*, void*) (signum=11, 
info=0x7fffd370, ptr=0x7fffd060)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:492
#7  
#8  0x7ef261b0 in memset%sun4v-hwcap4 () from /lib/64/libc.so.1
#9  0x7ede9108 in makecontext () from /lib/64/libc.so.1
#10 0x000100015bbc in core.thread.Fiber.initStack() (
this=0x7f1f6000)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5051
#11 0x000100015930 in core.thread.Fiber.reset() (this=0x7f1f6000)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4294
#12 0x00010001536c in core.thread.Fiber.reset(void() delegate) (
this=0x7f1f6000, dg=...)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4309
#13 0x0001000152a4 in core.thread.Fiber.this(void() delegate, ulong, ulong)
(this=0x7f1f6000, dg=..., sz=32768, guardPageSize=8192)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4157
#14 0x00010001620c in core.thread.TestFiber.this() (
this=0x7f1f6000)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5175
#15 0x000100016300 in core.thread.runTen() ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5195
#16 0x000100016578 in core.thread.__unittestL5218_20() ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5220
#17 0x000100018cf8 in core.thread.__modtest() () at :1
#18 0x5d2cd388 in __foreachbody2 (this=0x7fffe308, 
m=0x1001208b8 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558
#19 0x5d2f49ec in object.ModuleInfo.__lambda2 (
this=0x7fffe230, 
m=0x1001208b8 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599
#20 0x5d30f600 in rt.minfo.__foreachbody2 (this=0x7fffe158, 
sg=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777
#21 0x5d314410 in rt.sections_elf_shared.DSO.opApply(scope int(ref
rt.sections_elf_shared.DSO) delegate) (dg=...)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69
#22 0x5d30f4e8 in rt.minfo.moduleinfos_apply(scope
int(immutable(object.ModuleInfo*)) delegate) (dg=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770
#23 0x5d2f26bc in object.ModuleInfo.opApply(scope
int(object.ModuleInfo*) delegate) (dg=...)
at /vol/gcc/

[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059

--- Comment #1 from Rainer Orth  ---
Created attachment 46149
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46149=edit
Correct Solaris mcontext_t, ucontext_t declarations

[Bug d/90059] New: Solaris mcontext_t, ucontext_t declarations are wrong

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059

Bug ID: 90059
   Summary: Solaris mcontext_t, ucontext_t declarations are wrong
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.*

Initially, all Solaris 11/SPARC execution tests (both 32 and 64-bit) FAILed
like
this:

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfec37d08 in rw_wrlock_impl () from /lib/libc.so.1
(gdb) where
#0  0xfec37d08 in rw_wrlock_impl () from /lib/libc.so.1
#1  0xfec3e62c in sigaction () from /lib/libc.so.1
#2  0x000a8be4 in runModuleUnitTests ()
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:506
#3  0x0007bfac in runAll (this=this@entry=0xffbfe78c)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:484
#4  0x0007ba9c in tryExec (this=0xffbfe78c, dg=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:460
#5  0x0007bcb4 in _d_run_main (argc=1, argv=, 
mainFunc=)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:493
#6  0x000686d4 in main (argc=1, argv=0xffbfe864)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/__entrypoint.di:44
#7  0x000684c4 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

with libphobos built with -g3 -O0:

   0xfec37cec : save  %sp, -96, %sp
   0xfec37cf0 :   ld  [ %g7 + 0x54 ], %i5
   0xfec37cf4 :   sethi  %hi(0x2800), %i3
   0xfec37cf8 :  mov  %g7, %l6
   0xfec37cfc :  add  %i3, 0x146, %i2
   0xfec37d00 :  rd  %pc, %i4
   0xfec37d04 :  sethi  %hi(0x6a000), %g1
=> 0xfec37d08 :  ldsb  [ %i5 + %i2 ], %l7
(gdb) p/x $i5
$14 = 0x0
(gdb) p/x $i2
$15 = 0x2946

The first arg (an rwlock_t *) should never be NULL.

After some debugging, this turned out to be memory corruption happening after
the call to swapcontext in fiber_switchContext.  The root cause was that the
declarations
of mcontext_t and ucontext_t in core.sys.posix.ucontext are badly wrong for
Solaris/SPARC.  After correcting them as in the attached patch, those SEGVs
are gone.

Solaris/x86 is mostly right, the only correction being the introduction of the
uc_xrs member of struct ucontext_t.  This doesn't change either size or
alignment, so it's primarily a cosmetic issue.

This again seems strongly to argue for an approach like libgo's (generating
Go structure declarations from the system headers at build time) or at least
libsanitizer's (verifying struct sizes and member offsets at runtime) to avoid
such isses.

[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong

2019-04-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug bootstrap/89982] [9 regression] SEGV in stage2 gengtype

2019-04-05 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89982

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug bootstrap/89982] New: [9 regression] SEGV in stage2 gengtype

2019-04-05 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89982

Bug ID: 89982
   Summary: [9 regression] SEGV in stage2 gengtype
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, x86_64-apple-darwin11.4.2

Between 20190404 (r270144) and 20490405 (r270162), bootstrap started to fail
on many targets: during stage2 gengtype SEGVs:

build/gengtype  \
-S /vol/gcc/src/hg/trunk/local/gcc -I gtyp-input.list -w
tmp-gtype.state
make[3]: *** [Makefile:2642: s-gtype] Segmentation Fault

On Linux/x86_64, I see

Program received signal SIGSEGV, Segmentation fault.
0x77cf7cfa in __strlen_sse2 () from /lib64/libc.so.6
(gdb) where
#0  0x77cf7cfa in __strlen_sse2 () from /lib64/libc.so.6
#1  0x004076c5 in adjust_field_type(type*, options*) ()
#2  0x00407c29 in create_field_at(pair*, type*, char const*, options*,
fileloc*) ()
#3  0x0040f379 in type(options**, bool) ()
#4  0x00410137 in parse_file(char const*) ()
#5  0x0040416b in main ()
(gdb) up
#1  0x004076c5 in adjust_field_type(type*, options*) ()

Starting a reghunt as we speak since the obvious candidate patch didn't cause
it.

[Bug lto/89884] New: g++.dg/lto/pr89335 FAILs

2019-03-29 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89884

Bug ID: 89884
   Summary: g++.dg/lto/pr89335 FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.*

The new g++.dg/lto/pr89335 test FAILs on Solaris with the vendor ld, both 32
and
64-bit sparc and x86:

+FAIL: g++.dg/lto/pr89335 cp_lto_pr89335_0.o assemble, -O2 -flto
-Wsuggest-final-methods

/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/pr89335_0.C:9:7: warning:
Declaring virtual destructor of 'struct List' final would enable
devirtualization of 1 call [-Wsuggest-final-methods]

The failure can also be reproduced on Linux/x86_64 with -fno-use-linker-plugin.

[Bug lto/89884] g++.dg/lto/pr89335 FAILs

2019-03-29 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89884

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug testsuite/89834] New test case gcc.dg/vect/pr81740-2.c introduced in r269938 fails

2019-03-27 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89834

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-27
 CC||ro at gcc dot gnu.org
Summary|New test case   |New test case
   |gcc.dg/vect/pr81740-2.c |gcc.dg/vect/pr81740-2.c
   |introduced in r269938 fails |introduced in r269938 fails
   |on power 7  |
 Ever confirmed|0   |1

--- Comment #6 from Rainer Orth  ---
sparc-sun-solaris2.11 had the same failure, and the proposed fix turned the
testcase
UNSUPPORTED, too.

[Bug target/87007] [8 Regression] 10% slowdown with -march=skylake-avx512

2019-02-24 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #9 from Rainer Orth  ---
(In reply to H.J. Lu from comment #8)
> Fixed on trunk so far.

However the new tests FAIL for 32-bit (seen on i386-pc-solaris2.11):

+FAIL: gcc.target/i386/pr87007-1.c scan-assembler-times
vxorps[^\\n\\r]*xmm[0-9] 1
+FAIL: gcc.target/i386/pr87007-2.c scan-assembler-times
vxorps[^\\n\\r]*xmm[0-9] 1

[Bug go/89447] libgo largefile support is incomplete and inconsistent

2019-02-22 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89447

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug go/89447] libgo largefile support is incomplete and inconsistent

2019-02-22 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89447

--- Comment #1 from Rainer Orth  ---
Created attachment 45796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45796=edit
Initial patch

[Bug go/89447] New: libgo largefile support is incomplete and inconsistent

2019-02-22 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89447

Bug ID: 89447
   Summary: libgo largefile support is incomplete and inconsistent
   Product: gcc
   Version: 9.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.*

When investigating the remaining libgo testsuite failures on Solaris, I came
across a group with a common root cause.  E.g.

--- FAIL: TestSharedLibName (0.00s)
build_test.go:182: not owner
build_test.go:182: not owner
FAIL
/vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[685]: wait: 8433: Terminated
FAIL: cmd/go/internal/work

The failure is from a call to os.RemoveAll.  It turns out that removeAllFrom
returns early because statInfo.Mode_IFMT != syscall.S_IFDIR which is
weird given that tmpGopath *is* a directory.

I find that fstatat is called

Thread 15 hit Breakpoint 1, 0xfdb71b7c in fstatat () from /lib/libc.so.1
(gdb) where
#0  0xfdb71b7c in fstatat () from /lib/libc.so.1
#1  0xfe7c2da8 in internal..z2fsyscall..z2funix.Fstatat (dirfd=dirfd@entry=3, 
path=..., stat=stat@entry=0x6ca280, flags=flags@entry=4096)
at /vol/gcc/src/hg/trunk/local/libgo/go/internal/syscall/unix/at.go:70
#2  0xfe947680 in os.removeAllFrom (parent=parent@entry=0xd050060, path=...)
at /vol/gcc/src/hg/trunk/local/libgo/go/os/removeall_at.go:66
#3  0xfe947e04 in os.RemoveAll (
path=)
at /vol/gcc/src/hg/trunk/local/libgo/go/os/removeall_at.go:48

which seems broken: given that this is a 32-bit program and sysinfo.go was
built with -D_FILE_OFFSET_BITS=64 (and thus the struct that is passed in is
actually struct stat64), this should be a call to fstatat64 instead.

And indeed the contents of Stat_t is off:
$4 = {Dev = 4292345858, st_pad1 = {0, 0, 0}, Ino = 2669371652487266752, 
  Mode = 3, Nlink = 2110, Uid = 1004, Gid = 4294967295, Rdev = 0, st_pad2 = {
0, 177}, Size = 6660097377203678494, Atim = {Sec = 1550674759, 
Nsec = 566076105}, Mtim = {Sec = 1550674759, Nsec = 566076105}, Ctim = {
Sec = 8192, Nsec = 16}, Blksize = 1953329254, Blocks = 0, 
  st_fstype = '\000' , st_pad4 = {0, 0, 0, 0, 0, 0, 0, 0}}

with Mode = 3 and Nlink = 2110 (which is really Uid!).

It turns out that there are more instances of the same problem: looking for
references to functions that have unused largefile equivalents in libc, I found
creat, getdents, mmap, openat, sendfile, and mkstemp (x86 only).

The attached initial patch fixes many of those by adding largefile equivalents.
Afterwards, only calls to mmap (from closures.o, i.e. libffi_convenience.a 
and mem_gccgo.go) and mkstemp (again from closures.o) are left.  ISTM that they
are ok, given that they don't use the Offset_t etc. types from sysinfo.go, but
the underlying 32-bit ones.  With the exception of getdents (which is
Solaris-specific
anyway), all those largefile functions are present on Linux, too, but I suspect
the build tags aren't right yet.

Bootstrapped on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu (both multilibs each).  No regressions on Linux/x86_64
and many related testsuite failures in both libgo and gotools are gone on
Solaris.

[Bug middle-end/89415] New: gcc.dg/sinatan-1.c FAILs

2019-02-20 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415

Bug ID: 89415
   Summary: gcc.dg/sinatan-1.c FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11, aarch64-unknown-linux-gnu,
hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11,
i586-unknown-freebsd11.2,   ia64-suse-linux-gnu,
moxie-unknown-elf, s390x-ibm-linux-gnu,
spu-unknown-elf, x86_64-unknown-freebsd11.2,
x86_64-w64-mingw32

Between 20190218 (r268990) and 20190219 (r269021), the gcc.dg/sinatan-1.c began
to FAIL:

+FAIL: gcc.dg/sinatan-1.c execution test

I see it on 32 and 64-bit Solaris/SPARC, but quite a number of other targets is
affected, too.

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec7e740 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfec7e740 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfebb99f0 in raise () from /lib/libc.so.1
#2  0xfeb8b2d0 in abort () from /lib/libc.so.1
#3  0x0001126c in main ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/sinatan-1.c:85

Maybe this is due to

2019-02-19  Richard Biener  

PR middle-end/88074
* toplev.c (do_compile): Initialize mpfr's exponent range
based on available float modes.

* gcc.dg/pr88074.c: New testcase.

[Bug middle-end/89415] gcc.dg/sinatan-1.c FAILs

2019-02-20 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

2019-02-14 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #11 from Rainer Orth  ---
Fixed for GCC 9.1.

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

2019-02-14 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864

--- Comment #10 from Rainer Orth  ---
Author: ro
Date: Thu Feb 14 17:47:49 2019
New Revision: 268886

URL: https://gcc.gnu.org/viewcvs?rev=268886=gcc=rev
Log:
Provide __start_minfo/__stop_minfo for linkers that don't (PR d/87864)

libphobos:
PR d/87864
* configure.ac (DRTSTUFF_SPEC): New variable.
Substitute it.
* libdruntime/m4/druntime/os.m4 (DRUNTIME_OS_MINFO_BRACKETING):
New automake conditional.
* configure: Regenerate.
* libdruntime/gcc/drtstuff.c: New file.
* libdruntime/Makefile.am [!DRUNTIME_OS_MINFO_BRACKETING]
(DRTSTUFF, toolexeclib_DATA): New variables.
(gcc/drtbegin.lo, gcc/drtend.lo): New rules.
(libgdruntime_la_LDFLAGS): Use -Wc instead of -Xcompiler.
Add -dstartfiles -B../src -Bgcc.
(libgdruntime_la_DEPENDENCIES): New variable.
(unittest_static_LDFLAGS): Use -Wc instead of -Xcompiler.
(libgdruntime_t_la_LDFLAGS): Likewise.
(unittest_LDFLAGS): Likewise.
* src/Makefile.am (libgphobos_la_LDFLAGS): Use -Wc instead of
-Xcompiler.
Add -dstartfiles -B../libdruntime/gcc.
(unittest_static_LDFLAGS): Use -Wc instead of -Xcompiler.
(libgphobos_t_la_LDFLAGS): Likewise.
(unittest_LDFLAGS): Likewise.
* libdruntime/Makefile.in, src/Makefile.in: Regenerate.
* Makefile.in, testsuite/Makefile.in: Regenerate.
* libdruntime/rt/sections_elf_shared.d (Minfo_Bracketing): Don't
assert.
* libdruntime/gcc/config.d.in (Minfo_Bracketing): Remove.
* src/drtstuff.spec: New file.
* src/libgphobos.spec.in (DRTSTUFF_SPEC): Substitute.
(*lib): Only pass SPEC_PHOBOS_DEPS without -debuglib, -defaultlib,
-nophoboslib.
* testsuite/testsuite_flags.in <--gdcldflags> (GDCLDFLAGS): Add
-B${BUILD_DIR}/libdruntime/gcc.

gcc/d:
PR d/87864
* lang.opt (dstartfiles): New option.
* d-spec.cc (need_spec): New variable.
(lang_specific_driver) : Enable need_spec.
(lang_specific_pre_link): Also load libgphobos.spec if need_spec.

gcc/testsuite:
PR d/87864
* lib/gdc.exp (gdc_link_flags): Add path to drtbegin.o/drtend.o if
present.

Added:
trunk/libphobos/libdruntime/gcc/drtstuff.c
trunk/libphobos/src/drtstuff.spec
Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-spec.cc
trunk/gcc/d/lang.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/gdc.exp
trunk/libphobos/ChangeLog
trunk/libphobos/configure   (contents, props changed)
trunk/libphobos/configure.ac
trunk/libphobos/libdruntime/Makefile.am
trunk/libphobos/libdruntime/Makefile.in
trunk/libphobos/libdruntime/gcc/config.d.in
trunk/libphobos/libdruntime/rt/sections_elf_shared.d
trunk/libphobos/m4/druntime/os.m4
trunk/libphobos/src/Makefile.am
trunk/libphobos/src/Makefile.in
trunk/libphobos/src/libgphobos.spec.in
trunk/libphobos/testsuite/testsuite_flags.in   (contents, props changed)

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

2019-02-14 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2019-01/msg01666.ht |patches/2019-02/msg01019.ht
   |ml  |ml
   Last reconfirmed||2019-02-14
   Assignee|ibuclaw at gdcproject dot org  |ro at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Rainer Orth  ---
Mine, slightly revised patch posted.

[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524

2019-02-11 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294

Rainer Orth  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||x86_64-pc-linux-gnu
   Host|i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||x86_64-pc-linux-gnu
  Build|i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||x86_64-pc-linux-gnu

--- Comment #1 from Rainer Orth  ---
Seeing the same on Linux/x86_64.

[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524

2019-02-11 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug middle-end/89294] New: [9 regression] ICE in valid_constant_size_p, at tree.c:7524

2019-02-11 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294

Bug ID: 89294
   Summary: [9 regression] ICE in valid_constant_size_p, at
tree.c:7524
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11

Between 20190210 (r268749) and 20190211 (r268774), a couple of Ada testcases
regressed on Solaris/x86 (both 32 and 64-bit):

+FAIL: gnat.dg/vect1.adb (test for excess errors)
+FAIL: gnat.dg/vect1.adb 3 blank line(s) in output
+UNRESOLVED: gnat.dg/vect1.adb scan-tree-dump-times vect "vectorized 1 loops"
15
+FAIL: gnat.dg/vect2.adb (test for excess errors)
+FAIL: gnat.dg/vect2.adb 3 blank line(s) in output
+UNRESOLVED: gnat.dg/vect2.adb scan-tree-dump-times vect "vectorized 1 loops"
15
+FAIL: gnat.dg/vect3.adb (test for excess errors)
+FAIL: gnat.dg/vect3.adb 3 blank line(s) in output
+UNRESOLVED: gnat.dg/vect3.adb scan-tree-dump-times vect "vectorized 1 loops"
15
+FAIL: gnat.dg/vect4.adb (test for excess errors)
+FAIL: gnat.dg/vect4.adb 3 blank line(s) in output
+UNRESOLVED: gnat.dg/vect4.adb scan-tree-dump-times vect "vectorized 1 loops"
15
+FAIL: gnat.dg/vect5.adb (test for excess errors)
+FAIL: gnat.dg/vect5.adb 3 blank line(s) in output
+UNRESOLVED: gnat.dg/vect5.adb scan-tree-dump-times vect "vectorized 1 loops"
15
+FAIL: gnat.dg/vect6.adb (test for excess errors)
+FAIL: gnat.dg/vect6.adb 3 blank line(s) in output
+UNRESOLVED: gnat.dg/vect6.adb scan-tree-dump-times vect "vectorized 1 loops"
15

FAIL: gnat.dg/vect2.adb 3 blank line(s) in output
FAIL: gnat.dg/vect2.adb (test for excess errors)
Excess errors:
+===GNAT BUG DETECTED==+
| 9.0.1 20190211 (experimental) [trunk revision 268774] (i386-pc-solaris2.11)
GCC error:|
| tree check: expected class 'constant', have 'binary' (mult_expr) in  |
| valid_constant_size_p, at tree.c:7524|
| Error detected at vect2.ads:24:51  

I'm not seeing this failure on sparc-sun-solaris2.11.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-02-08 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/89255] New: libphobos.unittests multilib handling broken

2019-02-08 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

Bug ID: 89255
   Summary: libphobos.unittests multilib handling broken
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

The libphobos.unittests tests don't run properly for the non-default multilib
(seen on both Solaris/SPARC and x86 as well as Linux/x86_64 and Linux/i686, but
not dependent on the specific target).

* E.g. on Solaris/x86 for the -m64 multilib, I see

ld.so.1: unittest: fatal: libgdruntime_t.so.0: open failed: No such file or
directory

  which not only produces confused libphobos.sum output

Running
/vol/gcc/src/hg/trunk/local/libphobos/testsuite/libphobos.unittests/unittests.exp
...
FAIL: libphobos.unittests/druntime/shared/ld.so.1:
FAIL: libphobos.unittests/druntime/shared/unittest:
FAIL: libphobos.unittests/druntime/shared/fatal:
FAIL: libphobos.unittests/druntime/shared/libgdruntime_t.so.0:
FAIL: libphobos.unittests/druntime/shared/open
FAIL: libphobos.unittests/druntime/shared/failed:
FAIL: libphobos.unittests/druntime/shared/No
FAIL: libphobos.unittests/druntime/shared/such
FAIL: libphobos.unittests/druntime/shared/file
FAIL: libphobos.unittests/druntime/shared/or
FAIL: libphobos.unittests/druntime/shared/directory

  which later turns up in mail-report.log, but

* indeed libgdruntime_t.so isn't built for non-default multilibs. 
libgdruntime_t.la
  is only built during make check, but the toplevel check targets lacks
  multilib handling.

[Bug d/89254] std.net.curl and std.parallelism unittests hang

2019-02-08 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89254

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/89254] New: std.net.curl and std.parallelism unittests hang

2019-02-08 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89254

Bug ID: 89254
   Summary: std.net.curl and std.parallelism unittests hang
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i686-pc-linux-gnu

When building on Linux/i686, the std.net.curl and std.parallelism unitests
hang and never time out.  Unfortunately, when trying to investigate with pstack
or gdb, those hang too and need to be killed explicitly.

strace shows

[pid 4] write(1, "bc_start_main [0xf2a7a742]\n", 27bc_start_main
[0xf2a7a742]
) = 27
[pid 4] write(1, "??:? ???[0x8049312]\n", 20??:? ???[0x8049312]
) = 20
[pid 4] rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0},
NULL, 8) = 0
[pid 4] rt_sigaction(SIGBUS, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0},
NULL, 8) = 0
[pid 4] futex(0xf2936ba8, FUTEX_WAIT, 40001, NULL

This is ugly because the complete build/test never finishes without manual
investigation.  To make things worse, each test is run twice when running a
multilibbed build due to broken multilib handling of libphobos.unittests
(to be reported separately).

[Bug tree-optimization/85947] gcc.dg/vect/bb-slp-div-1.c XPASSes

2019-02-08 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85947

Rainer Orth  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Rainer Orth  ---
The issue persists, only happening on sparc.

[Bug tree-optimization/89250] [9 regression] gcc.dg/vect/vect-24.c XPASSes

2019-02-08 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89250

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/89250] New: [9 regression] gcc.dg/vect/vect-24.c XPASSes

2019-02-08 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89250

Bug ID: 89250
   Summary: [9 regression] gcc.dg/vect/vect-24.c XPASSes
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: armv8l, i?86, ia64, mips*el, powerpc*, s390x, x86_64

gcc.dg/vect/vect-24.c has started to XPASS between 20180810 (r263461) and
20180813 (r263511)
on quite a number of targets:

+XPASS: gcc.dg/vect/vect-24.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 3 loops" 1
+XPASS: gcc.dg/vect/vect-24.c scan-tree-dump-times vect "vectorized 3 loops" 1

It would be good to get rid of this testsuite noise.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2019-02-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #14 from Rainer Orth  ---
Author: ro
Date: Wed Feb  6 18:54:16 2019
New Revision: 268588

URL: https://gcc.gnu.org/viewcvs?rev=268588=gcc=rev
Log:
Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

PR debug/87451
* gcc.dg/debug/dwarf2/inline5.c: Allow for non-comment before
"(DIE (0x[0-9a-f]*) DW_TAG_variable".
xfail scan-assembler-not with Solaris as.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

2019-01-29 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-01/msg01666.ht
   ||ml

--- Comment #6 from Rainer Orth  ---
Patch posted.

[Bug d/88150] Use sections_elf_shared.d on Solaris

2019-01-29 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-01/msg01661.ht
   ||ml

--- Comment #7 from Rainer Orth  ---
Patch posted, together with followups:

https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01663.html
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01664.html

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

2019-01-15 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #33 from Rainer Orth  ---
Unless I'm mistaken, we've now established that there's no bug in gcc here.
Thus closing as invalid.

[Bug debug/88723] [9 regression] PR debug/88635 patch breaks testsuite_shared.cc compilation

2019-01-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88723

--- Comment #2 from Rainer Orth  ---
Created attachment 45355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45355=edit
preprocessed input

Sure.  The cc1plus invocation is

cc1plus -fpreprocessed testsuite_shared.ii -quiet -dumpbase testsuite_shared.cc
-mcpu=v9 -auxbase testsuite_shared -g -O2 -w -std=gnu++98 -version
-fdiagnostics-color=never -fchecking=1 -fmessage-length=0 -fno-show-column
-ffunction-sections -fdata-sections -fno-inline -fPIC
-fno-diagnostics-show-caret -o testsuite_shared.s

[Bug debug/88723] [9 regression] PR debug/88635 patch breaks testsuite_shared.cc compilation

2019-01-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88723

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug debug/88723] New: [9 regression] PR debug/88635 patch breaks testsuite_shared.cc compilation

2019-01-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88723

Bug ID: 88723
   Summary: [9 regression] PR debug/88635 patch breaks
testsuite_shared.cc compilation
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11

Between 20190104 (r267571) and 20190105 (r267602), libstdc++ testing got broken
on Solaris/SPARC:

+ERROR: could not compile testsuite_shared.cc
+ERROR: tcl error sourcing
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.

The log shows

In file included from
/var/gcc/regression/trunk/11.5-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11/bits/gthr.h:148,
 from
/var/gcc/regression/trunk/11.5-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/ext/atomicity.h:35,
 from
/var/gcc/regression/trunk/11.5-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/basic_string.h:39,
 from
/var/gcc/regression/trunk/11.5-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/string:55,
 from
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/util/testsuite_shared.cc:18:
/var/gcc/regression/trunk/11.5-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11/bits/gthr-default.h:
In function 'int __gthread_active_p()':
/var/gcc/regression/trunk/11.5-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11/bits/gthr-default.h:181:
note: non-delegitimized UNSPEC UNSPEC_MOVE_GOTDATA (14) found in variable
location

and many more, and all compiler output lets target_compile think there's an
error, although the compilation succeeds otherwise.

It turns out that reverting just the dwarf2out.c partof

PR debug/88635
* dwarf2out.c (const_ok_for_output_1): Reject MINUS that contains
SYMBOL_REF, CODE_LABEL or UNSPEC in subexpressions of second argument.
Reject PLUS that contains SYMBOL_REF, CODE_LABEL or UNSPEC in
subexpressions of both operands.
(mem_loc_descriptor): Handle UNSPEC if target hook acks it and all the
subrtxes are CONSTANT_P.

Allows the compilation to succeed without error or messages.

[Bug bootstrap/88721] [9 regression] -Wmaybe-uninitialized warnings in sparc.c

2019-01-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721

--- Comment #1 from Rainer Orth  ---
Created attachment 45354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45354=edit
Possible patch

This patch allowed the bootstrap to finish.

[Bug bootstrap/88721] [9 regression] -Wmaybe-uninitialized warnings in sparc.c

2019-01-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug bootstrap/88721] New: [9 regression] -Wmaybe-uninitialized warnings in sparc.c

2019-01-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721

Bug ID: 88721
   Summary: [9 regression] -Wmaybe-uninitialized warnings in
sparc.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11

Between 20190104 (r267571) and 20190105 (r267602), Solaris/SPARC bootstrap
began
to fail:

/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c: In function 'rtx_def*
sparc_function_incoming_arg(cumulative_args_t, machine_mode, const_tree,
bool)':
/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:7417:39: error: 'regno'
may be used uninitialized in this function [-Werror=maybe-uninitialized]
 7417 |   return function_arg_union_value (size, mode, slotno, regno);
  |  ~^~~
/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:7386:15: note: 'regno' was
declared here
 7386 |   int slotno, regno, padding;
  |   ^

/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c: In function 'void
sparc_function_arg_advance(cumulative_args_t, machine_mode, const_tree, bool)':
/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:7603:14: error: 'padding'
may be used uninitialized in this function [-Werror=maybe-uninitialized]
 7603 |   cum->words += padding;
  |   ~~~^~

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

2019-01-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535

--- Comment #16 from Rainer Orth  ---
Author: ro
Date: Thu Jan  3 11:28:27 2019
New Revision: 267551

URL: https://gcc.gnu.org/viewcvs?rev=267551=gcc=rev
Log:
Update config.guess, config.sub (PR target/88535)

PR target/88535
* config.guess: Import upstream version 2019-01-03.
* config.sub: Import upstream version 2019-01-01.

Modified:
trunk/ChangeLog
trunk/config.guess   (contents, props changed)
trunk/config.sub   (contents, props changed)

[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386

2019-01-02 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84478

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ro at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #5 from Rainer Orth  ---
The new testcase FAILs e.g. on i386-pc-solaris2.11 and sparc-sun-solaris2.11
(32-bit only) at -O1 and above:

+FAIL: gcc.c-torture/execute/pr84478.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O2 -flto  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O2 -flto -flto-partition=none 
execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O3 -g  execution test

According to gcc-testresult postings, the same happens on a couple of other
targets, including i686-pc-linux-gnu.

[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators

2018-12-19 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
The patch broke Solaris/SPARC bootstrap:


/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c: In function 'void
scan_trace(dw_trace_info*, bool)':
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2541:43: error: self-comparison
always evaluates to false [-Werror=tautological-compare]
 2541 |   && DEFAULT_INCOMING_FRAME_SP_OFFSET != INCOMING_FRAME_SP_OFFSET)
  | 

Except for i386 and stormy16, no target defines
DEFAULT_INCOMING_FRAME_SP_OFFSET,
so they get the dwarf2cfi.c default

#define DEFAULT_INCOMING_FRAME_SP_OFFSET INCOMING_FRAME_SP_OFFSET

[Bug target/88535] New: sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

2018-12-18 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535

Bug ID: 88535
   Summary: sparcv9 gcc 7 causes comparison failure in sparc gcc 8
dwarf2out.o
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparcv9-sun-solaris2.11

I've gotten a report that building gcc 8.2.0 on Solaris 11.4/SPARC with the
bundled gcc 7.3.0 failed with a comparison failure:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/dwarf2out.o differs
make[2]: *** [Makefile:22905: compare] Error 1

Since I'd never seen the like of that before, it took me quite some time to
reproduce.  In the end, it turned out that gcc 7.4.0 configured with

--with-as=/usr/gnu/bin/as --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld
--enable-languages=c,c++ sparcv9-sun-solaris2.11

(i.e. 64-bit default) causes the failure, while the same gcc 7.4.0 configured
with

--with-as=/usr/gnu/bin/as --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld
--enable-languages=c,c++

(i.e. 32-bit default) does not.

gcc 8.2.0 was configured with

--with-as=/usr/gnu/bin/as --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld
--enable-languages=c,c++

in both cases. There are considerable codegen differences in
dwarf2out.c:output_file_names.
I haven't yet tried to reduce the testcase or try something similar on
mainline,
but certainly can if that's helpful.

[Bug d/87824] x86_64-linux multilib issues

2018-12-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824

--- Comment #17 from Rainer Orth  ---
(In reply to Iain Buclaw from comment #6)
[...]
> > Running target unix
> > FAIL: runnable/cppa.d   execution test
> > FAIL: runnable/cppa.d -g   execution test
> > FAIL: runnable/cppa.d -g -shared-libphobos   execution test
> > FAIL: runnable/cppa.d -shared-libphobos   execution test
> 
> Have now reproduced, the test checks old behaviour that I dropped support
> for long ago.  The first failed attempt to have a type that maps to C 'long'
> and 'unsigned long' had a 'struct __c_long' type that expected the compiler
> to magically pass it around as the correct integer type.  This had
> passed/gone unnoticed on x86_64 because 'struct{long}' and 'long' are passed
> in the same way.
> 
> Support should have been removed from the dmd front-end when it was dropped
> from the library, but it still lives on in the testsuite.

I'm seeing the same not only on Linux/x86_64, but also on Solaris/x86, only
for the non-default multilib.

The failure is the same however:

In file included from runnable/extra-files/cppb.cpp:36:^M
/vol/gcc/src/hg/trunk/dist/gcc/testsuite/../../libstdc++-v3/libsupc++/exception:37:10:
fatal error: bits/c++config.h: No such file or directory^M


Looking at the -I flags passed, it's obvious that they are wrong: on
Linux/x86_64 there is

-I/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/32

while on Solaris/x86 it's

-I/var/gcc/regression/trunk/11.3-gcc-gas/build/i386-pc-solaris2.11/amd64/libstdc++-v3/include/amd64

neither of which exist: the last component should be $target_triplet instead
of $target.  Fixing this as in the attached patch lets the test PASS for me
on both x86_64-pc-linux-gnu and i386-pc-solaris2.11 (32 and 64-bit each).

[Bug d/87824] x86_64-linux multilib issues

2018-12-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #16 from Rainer Orth  ---
Created attachment 45231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45231=edit
Patch for cppa.d with non-default multilib failure

[Bug testsuite/88041] gdc.test tests should include that prefix in test names

2018-12-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #4 from Rainer Orth  ---
Fixed for 9.0.

[Bug testsuite/88041] gdc.test tests should include that prefix in test names

2018-12-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041

--- Comment #3 from Rainer Orth  ---
Author: ro
Date: Thu Dec 13 14:41:34 2018
New Revision: 267094

URL: https://gcc.gnu.org/viewcvs?rev=267094=gcc=rev
Log:
Include gdc.test prefix in test names (PR testsuite/88041)

PR testsuite/88041
* lib/gdc-dg.exp (gdc-dg-test): Strip gdc.test prefix.
* gdc.test/gdc-test.exp (gdc-do-test): Create $subdir link.
Include $subdir in filename.
Cleanup generated source.
* gdc.test/compilable/ddoc9676a.d (EXTRA_SOURCES): Don't use
absolute path.
* gdc.test/compilable/depsOutput9948.d: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gdc.test/compilable/ddoc9676a.d
trunk/gcc/testsuite/gdc.test/compilable/depsOutput9948.d
trunk/gcc/testsuite/gdc.test/gdc-test.exp
trunk/gcc/testsuite/lib/gdc-dg.exp

[Bug testsuite/88041] gdc.test tests should include that prefix in test names

2018-12-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-12/msg00903.ht
   ||ml
   Last reconfirmed||2018-12-13
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #2 from Rainer Orth  ---
Mine, patch posted.

[Bug d/88462] All D execution tests FAIL on Solaris/SPARC

2018-12-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/88462] New: All D execution tests FAIL on Solaris/SPARC

2018-12-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462

Bug ID: 88462
   Summary: All D execution tests FAIL on Solaris/SPARC
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.*

Even with the latest patch for PR d/88150 to use sections_elf_shared.d on
Solaris,
which allows the vast majority of gdc execution tests to PASS on Solaris
11.4/x86,
I have no such luck on Solaris 11.5/SPARC: all tests FAIL with

Aborting from local/libphobos/libdruntime/core/sync/mutex.d(95) Error:
pthread_mutex_init failed.

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec7e044 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfec7e044 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfebb9898 in raise () from /lib/libc.so.1
#2  0xfeb8b1d0 in abort () from /lib/libc.so.1
#3  0x000c150c in core.internal.abort.abort(immutable(char)[],
immutable(char)[], uint) (msg=..., 
filename=, 
line=95)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/internal/abort.d:44
#4  0x000fe32c in core.sync.mutex.Mutex.this!(core.sync.mutex.Mutex).this(bool)
(this=0x12de34 , _unused_=true)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/sync/mutex.d:94
#5  0x000fdeac in core.sync.mutex.Mutex.this() (
this=0x12de34 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/sync/mutex.d:63
#6  0x000c64d0 in core.thread.Thread.initLocks() ()
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/thread.d:1726
#7  0x000c69d8 in thread_init ()
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/thread.d:2022
#8  0x000a232c in gc_init ()
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gc/proxy.d:56
#9  0x00080684 in rt_init ()
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:187
#10 0x000810c8 in runAll (this=0xffbfe904)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:485
#11 0x00081020 in tryExec (this=0xffbfe904, dg=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:461
#12 0x00080f2c in _d_run_main (argc=1, argv=0xffbfea34, 
mainFunc=0x6b2bc )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:494
#13 0x0006b24c in main (argc=1, argv=0xffbfea34)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/__entrypoint.di:44
#14 0x0006b014 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

!pthread_mutex_init(cast(pthread_mutex_t*) _hndl, ) ||
abort("Error: pthread_mutex_init failed.");

After much digging and head scratching, I found what's wrong:
pthread_mutex_init
expects the mutex to be long long (i.e. 8 byte) aligned.  I'd thought this
would happen automatically given the declaration in core/sys/posix/sys/types.d
with the ulong __pthread_mutex_data field which has a natural alignment of
64 bits.  Whatever I do, however, I only end up with the mutex being 4-byte
aligned:

* apply align(8): at the beginning of the pthread_mutex_t fields,

* apply align(8) to the struct pthread_mutex_t declaration, or

* apply align(8) to the m_hndl member of Class Mutex in core/sync/mutex.d.

To guard against incomplete dependencies that could lead to some parts not
being recompiled when they should, I've always recompiled all of libphobos to
be sure I didn't miss something.

I've no idea what I'm doing wrong here.

[Bug d/88150] Use sections_elf_shared.d on Solaris

2018-12-12 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150

Rainer Orth  changed:

   What|Removed |Added

  Attachment #45067|0   |1
is obsolete||

--- Comment #5 from Rainer Orth  ---
Created attachment 45211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45211=edit
Revised patch

[Bug middle-end/88448] [9 regression] gnat.dg/opt66.adb etc. FAIL

2018-12-11 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88448

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug middle-end/88448] New: [9 regression] gnat.dg/opt66.adb etc. FAIL

2018-12-11 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88448

Bug ID: 88448
   Summary: [9 regression] gnat.dg/opt66.adb etc. FAIL
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11, i386-pc-solaris2.11

Between 20181209 (r266930) and 20181210 (r266959), three Ada tests regressed:

+FAIL:  cb4009a

cb4009a.adb: In function 'CB4009A.P2':
cb4009a.adb:114:5: error: BB 16 can not throw but has an EH edge
+===GNAT BUG DETECTED==+
| 9.0.0 20181210 (experimental) [trunk revision 266959] (i386-pc-solaris2.11)
GCC error:|
| verify_flow_info failed  |
| Error detected around cb4009a.adb:114:5
[...]
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407
gnatmake: "cb4009a.adb" compilation error

+FAIL: gnat.dg/opt66.adb (test for excess errors)
+FAIL: gnat.dg/opt66.adb 3 blank line(s) in output

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb: In function
'Opt66':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb:13:4: error: BB 12
can not throw but has an EH edge
+===GNAT BUG DETECTED==+
| 9.0.0 20181210 (experimental) [trunk revision 266959] (i386-pc-solaris2.11)
GCC error:|
| verify_flow_info failed  |
| Error detected around
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb:13:4|
[...]
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407
gnatmake: "/vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb"
compilation error

This might be from

2018-12-10  Richard Biener  

PR middle-end/88415
* gimple.c (gimple_assign_set_rhs_with_ops): Transfer EH
info to a newly allocated stmt.

* gcc.dg/gomp/pr88415.c: New testcase.

[Bug go/56431] -lpthread should be added to -lgo

2018-12-10 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
I'm seeing the same link error on Linux/x86_64 on mainline when configured with
--disable-shared:

/vol/gcc/bin/gld-2.31:
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/libgcc.a(generic-morestack.o):
in function `__morestack_block_signals':
/vol/gcc/src/hg/trunk/local/libgcc/generic-morestack.c:661: undefined reference
to `pthread_sigmask'

linking e.g. test2json.

[Bug other/66955] Bootstrap error: libcc1 compiled as shared library despite --disable-shared

2018-12-10 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66955

Rainer Orth  changed:

   What|Removed |Added

 Target|x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
   ||i?86-pc-solaris2.11,
   ||amd64-pc-solaris2.11
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
  Component|libgcc  |other
 CC||aoliva at gcc dot gnu.org,
   ||ro at gcc dot gnu.org
   Host|x86_64-unknown-linux-gnu|
 Ever confirmed|0   |1
  Build|x86_64-unknown-linux-gnu|

--- Comment #4 from Rainer Orth  ---
Confirmed on all of Linux/x86_64 and Solaris/x86.  Recategorizing: libcc1 has
nothing to do with libgcc.  There's no category for it and the MAINTAINERS file
lists none.

[Bug ada/88429] New: Ada bootstrap fails with --disable-shared

2018-12-10 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88429

Bug ID: 88429
   Summary: Ada bootstrap fails with --disable-shared
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: amd64-pc-solaris2.11, x86_64-pc-linux-gnu

Prompted by PR bootstrap/65725 (a Solaris bootstrap failure with
--disable-shared),
I tried both Solaris/amd64 and Linux/x86_64 bootstraps with --disable-shared:
both fail in the same way:

cp -p /vol/gcc/src/hg/trunk/local/gcc/tsystem.h rts_32
rm -f ../stamp-gnatlib-rts_32
touch ../stamp-gnatlib1-rts_32
rm -f rts_32/s-oscons-tmplt.i rts_32/s-oscons-tmplt.s
(cd rts_32 ; \
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/xgcc
-B/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/
-B/vol/gcc/x86_64-pc-linux-gnu/bin/ -B/vol/gcc/x86_64-pc-linux-gnu/lib/
-isystem /vol/gcc/x86_64-pc-linux-gnu/include -isystem
/vol/gcc/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO  -m32 -E -C
-DTARGET=\"x86_64-pc-linux-gnu\" -iquote /vol/gcc/src/hg/trunk/local/gcc/ada
/vol/gcc/src/hg/trunk/local/gcc/ada/s-oscons-tmplt.c > s-oscons-tmplt.i ; \
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/xgcc
-B/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/
-B/vol/gcc/x86_64-pc-linux-gnu/bin/ -B/vol/gcc/x86_64-pc-linux-gnu/lib/
-isystem /vol/gcc/x86_64-pc-linux-gnu/include -isystem
/vol/gcc/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO  -m32 -S s-oscons-tmplt.i ; \
../bldtools/oscons/xoscons s-oscons)
/bin/bash: line 0: cd: rts_32: Not a directory

Unlike the default (--enable-shared) case, it seems that the rts directory for
the non-default multilib is created incorrectly: with --enable-shared, I see

make THREAD_KIND=native setup-rts
make[9]: Entering directory
'/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/gcc/ada'
rm -rf rts_32
mkdir -p rts_32
chmod u+w rts_32

while with --disable-shared, I get the creation of rts twice.

This may be related to libada/configure.ac referencing a gnatlib-plain
target for --disable-shared, which I couldn't find elsewhere.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

2018-12-10 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725

Rainer Orth  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
(In reply to Fredrik Nyström from comment #3)
> (In reply to Daniel Richard G. from comment #0)
> > 1. Missing libgcc-unwind.map file
> 
> 1. Is caused by LINK_LIBGCC_MAPFILE_SPEC being set in gcc/config/sol2.h even
> if configured with --disable-shared. This has been around since PR
> target/59788.
> 
> I've had success on solaris 10, both sparc and x86 with following fix.
> 
> --- gcc/config/sol2.h.orig  2014-05-28 13:37:50.0 +0200
> +++ gcc/config/sol2.h   2015-09-03 14:23:19.950566000 +0200
> @@ -174,7 +174,7 @@
>  #define RDYNAMIC_SPEC "--export-dynamic"
>  #endif
>  
> -#ifndef USE_GLD
> +#if !defined(USE_GLD) && defined(ENABLE_SHARED_LIBGCC)
>  /* With Sun ld, use mapfile to enforce direct binding to libgcc_s unwinder.
> */
>  #define LINK_LIBGCC_MAPFILE_SPEC \
>"%{shared|shared-libgcc:-M %slibgcc-unwind.map}"

Thanks for the patch. It makes perfect send and I've now installed it on
mainline.

> > 2. stage2 vs. stage3 diffs
> 
> Are you sure you want /usr/ccs/bin/as on solaris x86?
> Have you tried with gnu as?
> --with-gnu-as
> --with-as=/usr/sfw/bin/gas

There's something to be said for using gas, but the Solaris 10 gas is ancient
by today' standards.  That said, I regularly bootstrap gcc on Solaris 10 with
both as and gas, and both work for me.

When trying a mainline bootstrap, I've run into quite a number of issues
(libcc1 and ada not building), but once I've worked around those, I could
bootstrap on amd64-pc-solaris2.11 (admittedly) with as/ld without comparison
failures.  This was without --with-pic, which I'll try next.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

2018-12-10 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725

--- Comment #5 from Rainer Orth  ---
Author: ro
Date: Mon Dec 10 09:49:02 2018
New Revision: 266946

URL: https://gcc.gnu.org/viewcvs?rev=266946=gcc=rev
Log:
Don't try to use libgcc-unwind.map with --disable-shared (PR bootstrap/65725)

2018-12-10  Fredrik Nyström  

PR bootstrap/65725
* config/sol2.h: Only use libgcc-unwind.map if
ENABLE_SHARED_LIBGCC.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sol2.h

[Bug go/88406] [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL

2018-12-07 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug go/88406] New: [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL

2018-12-07 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406

Bug ID: 88406
   Summary: [9 regression] Many 64-bit Solaris 10/SPARC execution
tests FAIL
   Product: gcc
   Version: 9.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: sparc*-sun-solaris2.10

Since the Go 1.11 merge, many (all?) 64-bit Solaris 10/SPARC execution tests
FAIL with

FAIL: cmd/go/internal/cache
runtime: memory allocated by OS [18446744071360741376, 18446744071427850240)
not
 in usable address space: base outside usable address space
fatal error: memory reservation exceeds address space limit

runtime stack:

:0

:0

:0

:0

:0

:0

:0

:0
[...]
:0
main
/vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:57
_start
:0

Solaris 11/SPARC and Solaris/x86 are fine, though.

[Bug c++/88390] [9 regression] g++.dg/tree-prof/pr57451.C FAILs

2018-12-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88390

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/88390] [9 regression] g++.dg/tree-prof/pr57451.C FAILs

2018-12-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88390

--- Comment #1 from Rainer Orth  ---
Created attachment 45171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45171=edit
pr57451.s @ r266584, SIGILL

  1   2   3   4   5   6   7   8   9   10   >