https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Buclaw ---
> I think it should be done in r270485.
Indeed. It works fine on i386-pc-solaris2.11 and sparc-sun-solaris2.11
with gas. I do get BUS err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Iain Buclaw ---
> It ended up being a little more work, as the proposed patch had a bug in it.
No wonder given that I just started with D ;-)
> But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Paul Thomas ---
> Created attachment 46216
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46216&action=edit
> Patch for the remaining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I've just applied the patch to trunk, rebuilt f951 on
> sparc-sun-solar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Rainer Orth ---
> However, 64-bit testing on Solaris 10/x86 only works with gld since ld doesn't
> support -z relax=transtls. What's worse, due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jonathan Wakely ---
> We just use the AC_PROG_LN_S test from autoconf, see
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
>> --- Comment #6 from Rainer Orth ---
>> The patch consists primarily of additions to
>> DRUNTIME_LIBRARIES_DL_ITERATE_PHDR
>> to detect the situation, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Christian Jullien ---
> IMHO, the only thing you may want to add is a test on working ln and refuse to
> continue otherwise.
This doesn't belong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jonathan Wakely ---
> I considered mentioning it as a caveat on
> https://gcc.gnu.org/install/prerequisites.html but since it only affects an
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90503
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Ian Lance Taylor ---
> Is this still worth investigating given that we've dropped support for Solaris
> 10?
It depends: this single bug accounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Does malloc guarantee sufficient alignment for long long?
It does: 8 bytes for 32-bit, 16 bytes for 64-bit with the libc malloc.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jakub Jelinek ---
> Created attachment 46418
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46418&action=edit
> gcc10-pr90641.pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Iain Sandoe ---
> does the existing availability hack work [below]?
It won't: one major problem was the use of __OSX_AVAILABLE and
__OSX_AVAILAB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> I don't have 10.15 or xcode 11 yet ..
No worry: I just happened to upgrade for reasons unrelated to gcc work
and gave it a whirl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jorn Wolfgang Rennecke ---
> Created attachment 46574
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46574&action=edit
> patch fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I haven't yet gotten around to looking closer, sorry.
I'll report once I've found something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Just for the record: according to gcc-testresults, the test also FAILs
on hppa64-hp-hpux11.11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Martin Sebor ---
> r262923 adds the missing logic to prevent the "unknown bound" kind of warning
> unless -Walloca-larger-than has been e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86659
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
A reghunt now identified this patch as the culprit:
2018-07-24 Richard Biener
* match.pd: Add BIT_FIELD_REF canonicalizations.
Comparing the assembler output, I find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Iain Sandoe ---
> I think this is a dup of 81033 - please try the attached patch(es) there.
A x86_64-apple-darwin11.4.2 bootstrap with that patch appl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #16 from Iain Sandoe ---
[...]
> I am going to suggest that this is dup-ed to 81033 (and please try the revised
> patch there - I already checked it's OK o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Paul Thomas ---
[...]
> Does the attachment fix the problem?
Seems I completely missed this, sorry.
I've just ran sparc-sun-solaris2.11 and i386-pc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jonathan Wakely ---
> (In reply to Rainer Orth from comment #0)
>> Thew new 18_support/new_aligned.cc test FAILs on Solaris 10 (sparc and x86),
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jonathan Wakely ---
> Great, thanks for testing it. Is it fixed for 64-bit as well as 32-bit? I was
> concerned that "the size of a word"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86996
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Bernd Edlinger ---
> is this a target where wchar_t is 16-bit wide?
No, wchar_t is always 32-bit. Cf. gcc/config/sol2.h:
/* wchar_t is called differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from qinzhao at gcc dot gnu.org ---
> which sparc machine was used to repeat the failure, and what's the configure
> and make options?
I just saw there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #2 from Richard Biener ---
You also might want to test the patch from PR87132.
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> If you disable bootstrap does it work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> You also might want to test the patch from PR87132.
I had it in my tree already last night. I've now retried the exact same
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from rguenther at suse dot de ---
[...]
> I wonder if you can run the testsuite in the not bootstrapped tree
> and look for sth suspicious.
I did that now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from qinzhao at gcc dot gnu.org ---
> the latest patch to this test bug has just been checked in at:
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from rguenther at suse dot de ---
[...]
>> > What's your host compiler? Do you use custom STAGE1_CFLAGS?
>>
>> Just a vanilla i386-pc-so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE > Hmm, GCC 7.1.0 of course makes me raise eyebrows. Do you by chance
>> have another host compiler to cross-test wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Richard Biener ---
> So I've applied a patch that might fix the originally reported segfault.
It doesn't help unfortunately: I'm still seei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jonathan Wakely ---
> Jay, is the original problem on SunOS still happening?
>
> Rainer, any insight into that build failure? Are some Solaris patche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Eric Botcazou ---
>> > On SPARC/Solaris?
>>
>> Yes please, on an arbitrary input you see the segbus/segfault.
>
> It was a rh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Richard Biener ---
> Fixed.
Indeed: I've just successfully completed a i386-pc-solaris2.11 bootstrap
without the workaround (preloaded libumem.so),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87339
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ktkachov at gcc dot gnu.org ---
> Fixed on arm and aarch64 with r264392.
> If you can confirm this fixes the other platforms please close this off.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87439
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Uroš Bizjak ---
> Following patch should fix the problem:
[...]
It did indeed: bootstrapped without regressions on i386-pc-solaris2.11.
Thanks.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84317
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Alexandre Oliva ---
> Rainer, thanks for the report.
> do you still get this with after revision 257562? it may very well have fixed
> this too,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84317
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I'm currently running a couple of bootstraps (Solaris 10, 11.3, 11.3
> with as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84317
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE > Uni-Bielefeld.DE> ---
> [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84317
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Alexandre Oliva ---
> The corrected patch, that I emailed you just after I got your email and
> realized I'd posted the patch without that fix, h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84288
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> * If DejaGnu is installed into a non-system directory, dejagnu.h isn't found
> compiling the tests. I've hacked around this by hardcoding a matching -I
> opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from bin.cheng ---
> a proposed patch @https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02419.html
I've regtested the patch on sparc-sun-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from rsandifo at gcc dot gnu.org gnu.org> ---
[...]
> Could you try the attached patch? It should restore the ability
> to look through steps when try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84288
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from David Malcolm ---
> I'm not sure if r258388 fixes the linker issue on Solaris, but it should make
> it much easier to fix; e.g. to apply your patch h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #62 from Richard Biener ---
> Waiting for Solaris engineer input... (or a machine to be able to debug this
I'll send it along shortly: just didn't m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from comment #9)
>> So GCC's definition of max_align_t is not consistent with malloc in So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from joseph at codesourcery dot com dot com> ---
> On Wed, 21 Mar 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
>
>> Joseph, any suggestions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Jonathan Wakely ---
> We *could* make the libstdc++ operator new call malloc repeatedly until it
> gets
> something aligned to max_align_t, so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85191
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> possibly the vect_perm_short case? how do you configure targets? Shouldn't
> have affected ia64 though... maybe my TCL fu wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85190
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from amker at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #0)
[...]
> Hmm, what options did you use?
Nothing special in the Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from Eric Gallager ---
[...]
> Did this fix it?
It seems so, both according to my own testing and gcc-testresults
postings.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Paul Thomas ---
> Created attachment 44781
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44781&action=edit
> Possible fix
>
> Doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Martin Liška ---
> It probably looks that there's missing profile file *.gcda. Can you check it's
> generate in -fprofile-generate run?
It i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Martin Liška ---
[...]
> When the executable is executed, the *.gcda file should be created. Please
> check why the file is not generated.
Sorry, I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Bernd Edlinger ---
> Rainer, can you try this?
Looks good so far: an i386-pc-solaris2.11 build has successfully linked
libgnat-9.so, but the bootstrap is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Martin Liška ---
[...]
>> Sorry, I've been doing too many things at once and not been paying close
>> enough attention. Besides, the g++.log f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Martin Liška ---
[...]
> You can use gcov-dump -l to dump content of the files. However, it's not
> problem as the file exists. The warning should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #1 from Bernd Edlinger ---
>> Rainer, can you try this?
>
> Looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
This looks like it could be due to
2018-10-18 Richard Biener
* config/i386/i386.c (ix86_builtin_vectorization_cost): Do not
feed width-specific load/store costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Richard Biener ---
> Not that word_mode vectorization costing in the backend is in any way
> correct...
With that patch, the i686-pc-linux-gnu bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> This is part of the dmd frontend which as no interaction with gcc. So
> gcc_unreachable() can't be used here.
I see. However, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> Is there another way to get a section in earlier versions of Solaris?
What I initially did in LLVM's compiler-rt (which prompted the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Buclaw ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #2)
>> > --- Comment #1 from Iain Buclaw ---
>> > This is part o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87880
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Dominique d'Humieres ---
> WORKSFORME on x86_64-apple-darwin18.2.0 configured with
> --with-sysroot=/Applications/Xcode-6.2.app/Contents/Devel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87880
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Dominique d'Humieres ---
>> Weird: can you check where the definition of
>> ___cxa_rethrow_primary_exception is coming from in your case? On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Iain Buclaw ---
> It required removing all system includes from all dmd frontend sources, but I
> think this OK now. I have verified that gcc_assert()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> I backported a fix from the D sources so it should no longer segfault at
> least.
It doesn't indeed.
> From what I can see,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> (In reply to Rainer Orth from comment #0)
>>
>> The problem obviously is that the native assemblers don't support UTF-8 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79975
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Martin Liška ---
> Rainer: Can the bug be marked as resolved?
I don't think so: as I wrote in Comment #7, the compiler still SEGVs,
which is only avo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88104
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Martin Sebor ---
> The failing tests are compile-only (don't involve the assembler), and would
> pass even with a default-configured GCC. The reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84288
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Martin Liška ---
> Rainer: Can the bug be marked as resolved?
No, there are quite a number of issues still open:
* the total_sz_out printing,
* hardcod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88090
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> Created attachment 45037
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45037&action=edit
> gcc9-pr88090.pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Iain Sandoe ---
> (In reply to Martin Liška from comment #20)
>> Iain: Can the bug be marked as resolved?
>
> I'd assume it can
> Rai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Eric Botcazou ---
> I have a bunch of sanitizer failures on SPARC/Solaris 11.3:
[...]
This is weird: this test PASSes for me on Solaris 11.3, 11.4 and 11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #21 from Iain Sandoe ---
>> (In reply to Martin Liška from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88104
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Martin Sebor ---
> Agreed. If you already have a bug tracking this change to the harness please
> feel free to resolve this one. Otherwise I suggest to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88091
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Martin Sebor ---
> Patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01674.html
I tested the patch on i386-pc-solaris2.11: all failures are gone.
Btw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Martin Sebor ---
> Patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01661.html
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11: failures gone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Iain Buclaw ---
[...]
> I'm not sure given them an encoded mangle in similar vain to Go would be a
> desirable direction, so better off relegating th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from joseph at codesourcery dot com dot com> ---
> On Mon, 19 Nov 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
>
>> However, there's anoth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #26 from Rainer Orth ---
> (In reply to Eric Botcazou from comment #25)
>> > The new tests fail at execution on armeb and aarch64_be:
>> > FAI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #28 from Jakub Jelinek ---
> Would:
[...]
> fix this? Don't have easy access to arm32 right now to verify if even with
> that change it still FAILs w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Eric Botcazou ---
>> Anybody should be able to reproduce this problem. My guess is a logic error.
>
> I'm not sure whether we still support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
A couple of issues in the patch bear commenting:
* The core/sys/solaris/dlfcn.d change was needed to silence
/vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/sections_elf_shared.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> Thanks, I will write up a small documentation of how the sections modules
> interacts with runtime - along with compiler support.
Grea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
>> --- Comment #1 from Iain Buclaw ---
>> Is there another way to get a section in earlier versions of Solaris?
>
> What I initially did in LLVM's compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Iain Buclaw ---
> Based on what you described is the problem, I think this is done.
I'm pretty certain it is. I've successfully been using the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>>> --- Comment #1 from Iain Buclaw ---
>>> Is there another way to get a sectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Eric Botcazou ---
>> The only asan execution failures I see on Solaris 11/SPARC are
[...]
> I only have:
>
> c-c++-common/asan/pointer-compare-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Eric Botcazou ---
>> I only have:
[...]
>> as execution test failures, but I have a bunch of output pattern test
>> failures.
>
> Rain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87807
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Eric Botcazou ---
> Thanks for reporting the problem.
Great, thanks for the quick fix.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from Eric Botcazou ---
> (> These are often just off-by-one errors in the line numbers; I believe I
>> have a patch around somewhere to fix at leas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88369
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
[...]
> Only those two and not the 4 other ones?
It's 5 for me actually:
g++.dg/vect/pr33426-ivdep-2.cc
g++.dg/v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Jakub Jelinek ---
> I think it is important to find out why there are those differences in line
> numbers. Is libbacktrace broken on Solaris, or not us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Eric Botcazou ---
>> I think it is important to find out why there are those differences in line
>> numbers. Is libbacktrace broken on Solaris,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #26 from Jakub Jelinek ---
> Try -fno-delayed-branch then? The debug info and unwind info for delayed
> slots
> isn't really well defined...
For a qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #28 from Eric Botcazou ---
[...]
>> -fno-delayed-branch made no difference.
>
> What about -fasynchronous-unwind-tables?
Is already included in sol2.h (ASAN_CC1_SPEC).
401 - 500 of 1428 matches
Mail list logo
