http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-27 11:06:43 UTC ---
> --- Comment #18 from Richard Guenther 2012-02-27
> 10:32:28 UTC ---
> It fails everywhere. But we don't seem to be sure it is a regression
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52456
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-02 16:56:23 UTC ---
> --- Comment #1 from Paolo Carlini
> 2012-03-02 16:47:44 UTC ---
> And the undesignated symbols are...? Is the issue recent?
I suppose the symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52510
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-07 20:34:57 UTC ---
A reghunt revealed that this patch (r184876) is indeed the culprit:
2012-03-03 Jason Merrill
Core 1270
* call.c (build_aggr_conv): Call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-16 09:55:26 UTC ---
I've found that this failure on Solaris
--- FAIL: net.TestMulticastListener (0.00 seconds)
sockoptip.go:67: First ListenMulticastUDP failed: setso
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-16 11:03:28 UTC ---
> I'm now running into
>
> --- FAIL: net.TestMulticastListener (0.00 seconds)
> sockoptip.go:118: "224.0.0.254:12345" not fou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-20 13:48:51 UTC ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> 2012-03-16 09:55:26 UTC ---
[...]
> I'm now running int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 13:09:44 UTC ---
This is from my Tru64 UNIX removal patch. Could you please check if
IPPROTO_IPV6 and/or IPV6_MULTICAST_IF are defined in any system header
or if this another case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 13:32:31 UTC ---
> I don't yet know if they are related.
Now I do: I've just built a 32-bit C-only compiler on
sparc-sun-solaris2.11 at r185563 (i.e. immediate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 13:51:46 UTC ---
> --- Comment #4 from rguenther at suse dot de
> 2012-03-21 13:38:28 UTC ---
[...]
> If they are related (which I doubt), removing the call to cleanup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 15:04:51 UTC ---
> IPPROTO_IPV6 and IPV6_MULTICAST_IF are not defined in any system header
> on HP-UX 11.00. As far as I can tell, there is no IPv6 support.
Ok, but at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 15:51:23 UTC ---
> and with #if 1 they fail? As they are wrong-code regressions on
> an architecture I have no access to, can you see what is the issue here?
Right.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 16:31:41 UTC ---
> --- Comment #4 from dave.anglin at bell dot net 2012-03-21 16:22:38 UTC ---
> On 3/21/2012 11:04 AM, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
>>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-26 13:09:20 UTC ---
> HAVE_INET6 is undefined in include/config.h and classpath/include/
> config.h.
Ok, so at least we don't have another case of IPv6 being half-supp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-04-03 09:46:30 UTC ---
> --- Comment #12 from Uros Bizjak 2012-04-03
> 08:56:13 UTC ---
> Reverting:
>
> * src/c++98/compatibility-ldbl.cc: Guard with PIC
>
&
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53006
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-04-16 12:27:06 UTC ---
> Strangely, the same gdb binary works on Solaris 10 with the bundled
> libpython2.6.so, so this might be a bug in that library on Solaris 11.
Indeed when I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58722
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> I don't believe it. This is exactly what r203427 fixed. Are you sure it is
> with r203429 and it isn't r203426 or earli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58833
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Eric Botcazou ---
>> Would it be possible for GCC in Solaris to auto-configure itself as a 64-bit
>> native compiler by default (instead of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Martin Jambor ---
[...]
> If anyone is willing to test the patch on any platform but especially
> on those which I could not, I'd be very grateful.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59235
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jeffrey A. Law ---
> Ranier,
>
> The only sparc box in the farm is the painfully slow gcc54 which someone else
> is hammering so bad there's no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Martin Jambor ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #12)
>> FAIL: gfortran.fortran-torture/execute/pr32604.f90 execution, -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
This issue now causes new failures on Solaris 9 with Sun as:
FAIL: gcc.dg/atomic/c11-atomic-exec-1.c -O2 -flto (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Rolf Eike Beer ---
> I get the same problem using gcc 4.5, 4.7, and 4.8 on a Sun Fire V240 running
> Gentoo. Even if the compiler says "Gentoo&quo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Rolf Eike Beer ---
>> I don't have the least idea what's going on here, and cannot debug
>> issues on Linux/SPARC since I don'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Ian Lance Taylor ---
> This problem should be fixed now. Sorry about that.
It does for the vast majority of the 32-bit tests. I'll file separate
bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Ian Lance Taylor ---
> FYI, the point of the test is to get that segmentation violation and ensure
> that the signal handler generates a runtime panic as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've found what's going on: when I look at the failing bufio test, gdb
prints
gdb) p rfds
Cannot access memory at address 0xfd7ffe0f9f00
With pmap, I see the followin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22007
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Kai Tietz ---
> Issue seems to be solved for 32-bit and 64-bit windows on cygwin-host. I
> can't
> reproduce issue there anymore for 4.9 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959
--- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #43 from Hin-Tak Leung ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #40)
>> Please try this on your system and tell us how you end up with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-14 14:17:50 UTC ---
> --- Comment #15 from Iain Sandoe 2011-11-14
> 08:47:16 UTC ---
> Created attachment 25814
> --> http://gcc.gnu.org/bugzilla/attachme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51086
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-14 15:24:22 UTC ---
> --- Comment #3 from Hans-Peter Nilsson 2011-11-14
> 14:06:35 UTC ---
> Though the behavior is a tiny bit different, this seems to be a dup of bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51086
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-15 15:19:45 UTC ---
> --- Comment #5 from Alan Modra 2011-11-14 22:00:20
> UTC ---
> Please try http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01685.html
Works like a char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-16 18:23:22 UTC ---
> --- Comment #1 from David Edelsohn 2011-11-16
> 16:31:00 UTC ---
> Confirmed. I think this may be present on alpha-dec-osf as well.
The failure on T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-17 17:40:02 UTC ---
> --- Comment #18 from Iain Sandoe 2011-11-15
> 09:34:00 UTC ---
> (In reply to comment #16)
>> > --- Comment #15 from Iain Sandoe 2011-11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51204
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-18 18:38:11 UTC ---
> --- Comment #1 from Paolo Carlini
> 2011-11-18 18:28:17 UTC ---
> Rainer, any idea what is this about?
No, the testcase links fine for me as with bot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-21 16:50:54 UTC ---
I forgot: while one could use ACX_LARGEFILE everywhere in GCC (and I
tried that using --disable-largefile when configuring gcc works with a
default-configured gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-21 17:30:21 UTC ---
> --- Comment #5 from Paolo Bonzini 2011-11-21
> 17:25:20 UTC ---
> What's exactly the problem with gdb that requires disabling largefiles?
gdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-22 15:05:13 UTC ---
> --- Comment #1 from Andrew Macleod 2011-11-21
> 19:21:30 UTC ---
> 32 bit targets don't usually support 128 bit atomic operations natively, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-22 17:21:38 UTC ---
HJ,
with binutils 2.22 now released, could you please work to get this
fixed? IMO binutils releases need to work for bootstrapping gcc out of
the box without
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-22 17:55:15 UTC ---
But this is the common case: you cannot expect or require the bootstrap
compiler to use the same linker as you configure with. This is a
bootstrap failure which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-23 15:27:22 UTC ---
> --- Comment #23 from H.J. Lu 2011-11-22 18:03:09
> UTC ---
> (In reply to comment #22)
>> But this is the common case: you cannot expect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-23 16:53:16 UTC ---
> Checking linker version is inaccurate since this feature requires
> support in assembler, linker as well as libc. We can disable it by'
> default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-24 17:44:03 UTC ---
> This test uses the run-time test to check if .ctors and .init_array
> input sections can be mixed. Separate tests don't make much sense.
Would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 10:20:28 UTC ---
> The patch solves the problem for me.
Same on i386-pc-solaris2.8 (all gcc.misc-tests/gcov and g++.dg/gcov
tests) and alpha-dec-osf5.1b (with one except
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:04:26 UTC ---
> --- Comment #2 from Jonathan Wakely 2011-11-24
> 19:26:23 UTC ---
> (In reply to comment #0)
>> FAIL: 30_threads/thread/native_handle/typesiz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:06:10 UTC ---
> --- Comment #3 from Jonathan Wakely 2011-11-24
> 20:30:43 UTC ---
> What does this program do, compiled with -std=c++11 -pthread ?
I get
Asserti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:12:25 UTC ---
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> 2011-11-25 14:06:10 UTC ---
>> --- Comment #3 from Jonathan Wakely 2011-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:57:24 UTC ---
> --- Comment #7 from Jonathan Wakely 2011-11-25
> 14:46:07 UTC ---
> Thanks for the info - that error implies the mutex was not correctly
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 15:55:36 UTC ---
> --- Comment #10 from Jonathan Wakely 2011-11-25
> 15:17:09 UTC ---
> ah so the scan-assembler test is finding the stabs info, not actually a call
&
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 16:34:03 UTC ---
No progress yet: an attempt to handle this via specs some time ago
failed since there was some of Joseph's option work missing.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 16:35:43 UTC ---
> --- Comment #11 from Uros Bizjak 2011-11-25
> 16:26:41 UTC ---
> I have additional patch that checks cpuid bit_CMPXCHG16B (and bit_CMPXCHG8B
&g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-28 12:42:17 UTC ---
> --- Comment #13 from Jonathan Wakely 2011-11-26
> 15:18:40 UTC ---
> Does this reduced test work with -std=gnu++11 -pthread ?
Unfortunately not, I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-28 14:34:38 UTC ---
> Does this work?
No, I still get EINVAL.
> Otherwise I suppose we must not define __GTHREAD_MUTEX_INIT on Tru64, causing
> std::mutex to use the init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-28 15:40:32 UTC ---
> Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
> either.
... but doesn't help for the Go comparison failures.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-07 09:08:41 UTC ---
> --- Comment #21 from Jakub Jelinek 2011-12-07
> 09:00:47 UTC ---
> Can't reproduce that with x86_64-linux x mips-sgi-irix6.5 cross and current
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-16 16:56:55 UTC ---
> --- Comment #23 from Jakub Jelinek 2011-12-07
> 09:21:16 UTC ---
> Can't reproduce with i686-linux x mips-sgi-irix6.5 cross either.
I coul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-16 17:55:22 UTC ---
> What sort of backtrace in gdb do you get on 32-bit Solaris 8-11/x86 for the
> execution failure
> in the libitm.c++/eh-1.C test?
This one:
[Thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-16 18:04:23 UTC ---
> --- Comment #4 from Richard Henderson 2011-12-16
> 18:00:43 UTC ---
> While that might solve the ICE, the clone table doesn't actually
> get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-19 16:40:33 UTC ---
> --- Comment #25 from Andrew Pinski 2011-12-16
> 20:05:16 UTC ---
> Can you try the patch in PR 51471#c11 ? That patch fixes mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-21 16:20:12 UTC ---
With the exception of the unrelated Ada bootstrap failure (PR
ada/51624), your patch allowed a mips-sgi-irix6.5 bootstrap to succeed
(for the first time in almost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-04 13:33:20 UTC ---
> --- Comment #28 from Richard Guenther 2012-01-04
> 13:30:21 UTC ---
> Was the patch installed?
Unfortunately not, I'm currently applying it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-05 17:16:21 UTC ---
> --- Comment #5 from Jakub Jelinek 2012-01-05
> 09:41:13 UTC ---
> Can't reproduce on x86_64-linux, nor with cross from that to
> i686-sun-sola
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-11 11:16:56 UTC ---
> --- Comment #15 from Aldy Hernandez 2012-01-10
> 17:53:25 UTC ---
> Folks, I am going to close this PR since it is a potpourri of failures across
&g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51173
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-11 11:18:16 UTC ---
I think that test should be skipped instead of xfailed to avoid the
noise from
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22006
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-11 14:20:48 UTC ---
I haven't seen this in a long time, and the testcases pass since they
now use .comm instead of .space. I meant to keep the PR open to
investigate why gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48340
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-11 16:30:03 UTC ---
Great, thanks.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-11 17:37:59 UTC ---
> --- Comment #18 from Jonathan Wakely 2012-01-11
> 16:50:09 UTC ---
> Regarding the remaining failures, it appears to be a front-end issue. Fixing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-12 15:47:53 UTC ---
> --- Comment #20 from Jonathan Wakely 2012-01-11
> 17:48:25 UTC ---
> (In reply to comment #19)
>> I've just tried it with the vendor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-12 18:17:56 UTC ---
> Does adding 'noexcept' to ~__mutex_base() make that hack unnecessary?
>
> The destructor should be implicitly noexcept, but G++ doesn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-13 10:25:34 UTC ---
I've done some more digging and found that the EINVAL error is generated
inside libpthread.so, by a function called __thdIsAddrInStack. And in
fact, if I m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-16 18:58:20 UTC ---
> --- Comment #25 from Jonathan Wakely 2012-01-13
> 10:37:52 UTC ---
> Nice digging. POSIX does say the INIT macro is for use when the mutex is
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-17 16:23:07 UTC ---
> --- Comment #30 from Jakub Jelinek 2012-01-13
> 20:36:16 UTC ---
> PR51471 patch has been committed by now, can you recheck if it didn't fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-19 16:08:44 UTC ---
> --- Comment #37 from Jakub Jelinek 2012-01-19
> 10:50:13 UTC ---
> Rainer/Andrew, please test this in your configurations.
I've just successf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-19 16:27:44 UTC ---
> --- Comment #39 from Jakub Jelinek 2012-01-19
> 16:17:29 UTC ---
> (In reply to comment #38)
>> So far, ld -e 0 doesn't work:
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-19 16:36:56 UTC ---
> --- Comment #41 from Jakub Jelinek 2012-01-19
> 16:32:08 UTC ---
> It isn't mandated by the ELF spec, but if the linker doesn't do that an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-24 12:55:38 UTC ---
> --- Comment #14 from Andrew Pinski 2012-01-24
> 01:29:40 UTC ---
> Since this was fixed on the trunk, can you remove the xfail?
I already did so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-27 11:45:17 UTC ---
I've also had a look at the Solaris/SPARC failures, which are unrelated
to the 64-bit Solaris/x86 problem previously identified. I could trace
it to the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-27 12:52:29 UTC ---
The chan.go testcase also fails on 32-bit IRIX, but in a different way:
> ./chan.x
panic: runtime error: invalid memory address or nil pointer derefere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51753
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-30 17:26:47 UTC ---
> I'm uncertain if this is a code generation issue or a problem on the gdb side.
The problem still occurs unchanged with gdb 7.4. Uros, do you have
sug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Martin Liška ---
> Can the bug be marked as resolved?
No, the Solaris/x86 problem persists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jakub Jelinek ---
> So fixed with r265025 ? That commit should have referenced this PR...
Yes to both. I've now added the forgotten PR marker.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Rainer Orth ---
[...]
>> > 2. stage2 vs. stage3 diffs
[...]
> When trying a mainline bootstrap, I've run into quite a number of issues
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Jakub Jelinek ---
> That would be the
> gcc_checking_assert (TREE_TYPE (name) == t);
> assert then. So, what is TREE_TYPE (name) and wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
The revised patch (still with loads of hacks) allowed the vast majority
of Solaris 11.4/x86 gdc tests to PASS, both 32 and 64-bit:
=== gdc Summary ===
# of expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Daniel Richard G. ---
Hi Daniel,
> I tested this again with GCC 8.2.0 on the same system, using as/ld, and am
> still seeing the object diffs. Would it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> pragma(msg, pthread_mutex_t.alignof);
> pragma(msg, Mutex.alignof);
> pragma(msg, Mutex.m_hndl.offsetof);
I get
8u
4u
/homes/ro/mutex_align.d:6:13: error: class core.sync.mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Iain Buclaw ---
> Stepping through the backtrace, I see the following at Thread.initLocks
> (core/thread.d around line 1719).
[...]
> So there ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Iain Buclaw ---
>> 8, but that let the constructor already fail the first time through
>> where _d_arraycopy checks that the right amount of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Iain Buclaw ---
>> Trying to load 32 bits from a non-4 byte aligned pointer is a no-no on a
>> strict-alignment target like sparc...
>
> I saw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Johannes Pfau ---
> I guess the proper fix to the alignment problem is using
> 'https://dlang.org/phobos/std_traits.html#classInstanceAlignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Eric Botcazou ---
>> I wonder if the configure or make process should defend against the
>> possibility that the host compiler and the compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from john henning ---
>> There are 3 different switches: --build, --host and --target.
>
> Hmm. I must be looking in the wrong place for documenta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from David Malcolm ---
> (In reply to Rainer Orth from comment #4)
>> The patch broke Solaris/SPARC bootstrap:
>
> Sorry about that. Does the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Johannes Pfau ---
> For reference, this makes running the testsuite on windows/msys2 hosts
> somewhat
> more complicated:
I'm sorry for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #6 from Eric Botcazou ---
>>> I wonder if the configure or make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Gary Mills ---
> Most of the words in the title are wrong now. I'm attempting to build gcc-7
> now. The ICE occurs on both SPARC and x86 sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84478
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Martin Sebor ---
> If this is a new regression please open a new bug for it. It's probably a
How would I determine that? The testcase fails on a c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Gary Mills ---
> It's not Solaris, first of all. Solaris is a closed system once again. It's
> illumos, which is derived from Opensolaris.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I may try a build on Solaris 10 with the snv_121 assembler myself.
> The sparc mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #26 from Gary Mills ---
> I have no concerns about removal of gcc support for Solaris 10: That is an
I've only mentioned it to make clear that the oldest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88723
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Jakub Jelinek ---
> Should be fixed, I'll let you test it before closing though.
I did last night and it worked fine. Thanks.
201 - 300 of 1428 matches
Mail list logo
