https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113968
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||iains at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Iain Sandoe ---
fixed on trunk, no back port planned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98935
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-10-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880
--- Comment #5 from Iain Sandoe ---
Created attachment 59220
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59220&action=edit
patch under test
Here is what I'm testing - if you have a chance to test it in your scenario
that would be great
00:00:00 |2024-9-29
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Comment #4 from Iain Sandoe ---
(In reply to Sergei Trofimovich from comment #3)
> Bisected it down to r15-3146-g47dbd69b1b31d3.
That was what I expected as noted on IRC.
I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853
--- Comment #4 from Iain Sandoe ---
fixed on Darwin, if it also works for Solaris then please feel free to close
the BZ.
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: jason at gcc dot gnu.org, redi at gcc dot gnu.org
Target Milestone: ---
Three fails of the form:
/scratch/12-mon-rosetta/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #4 from Iain Sandoe ---
(In reply to Rainer Orth from comment #3)
> The patch also broke Solaris bootstrap; will report that separately.
likewise *-darwin* (also have a report in preparation).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #30 from Iain Sandoe ---
(In reply to Chris Jones from comment #29)
> Iains, I was not trying to suggest with my last post what you should
> support, that is entirely up to you and we are very grateful for what you do
> do.
>
> I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #28 from Iain Sandoe ---
Folks - we all want ponies...
... but remember this is a toolchain - it is quite complex; expecting any
random permutation of things that you happen to choose to DTRT will probably
disappoint you.
Xcode doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #25 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > OK. I don't want to argue about the details / usability etc. etc. ( but note
> > that __symbols are for the implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #23 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #22)
> (In reply to Iain Sandoe from comment #21)
> > Thta is quite surprising - since the SDK should reflect the symbols exported
> > by the libraries installed on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #21 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #20)
> Created attachment 59189 [details]
> Patch for macOS 14/Xcode 16
>
> (In reply to GCC Commits from comment #19)
> > The master branch has been updated by Iain D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #7 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > > #if defined(__has_feature) && __has_feature(modules)
> >
> > This is a bug. If __has_feature is _not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775
--- Comment #6 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #4)
> So, e.g. co_await_find_in_subtree/await_statement_expander/find_any_await
> and maybe other coroutines.cc cp_walk_tree callbacks could use some helper
> for CALL_E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #16 from Iain Sandoe ---
FAOD:
- The current patch is to remove at macOS-15
- I have tested on systems that need to keep the lib
- FX is testing on macOS 15.
* I have already pushed the dependent patch that limits the libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #14 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #12)
> Created attachment 59179 [details]
> Drop removed unwind symbols
>
> This implements what I referred to as my preferred option in comment 10. It
> should apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #11 from Iain Sandoe ---
Indeed, all of this is well-known;
NOTE: there is no change proposed for any OS < macOS 15.
We actually bumped our libgcc_s version some time ago because GCC has for a
while now been pulling the unwinder di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116237
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #9 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #8)
> (In reply to Iain Sandoe from comment #2)
> > Created attachment 59176 [details]
> > Patch under test
>
> Does not apply to upstream GCC. I think it nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #7 from Iain Sandoe ---
Created attachment 59177
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59177&action=edit
patch for GCC-14 (***untested)
this is against the current darwin gcc-14 branch - it is completely untested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #4 from Iain Sandoe ---
(In reply to Chris Jones from comment #3)
> CN you prepare a version of the patch for the current gcc14 release ?
I guess you tried applying the attached patch and it does not ?
you mean for the Arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #1 from Iain Sandoe ---
yeah..
the compiler will not (for some several revisions) actually refer to
libgcc_s.1.dylib - it is only there to support existing built exes from older
compilers.
Probably dropping it after macOS 14 is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777
--- Comment #7 from Iain Sandoe ---
as noted in several places; the long-term solution for Darwin (in general since
there's an installed /usr/lib/libstdc++.6.dylib even on modern systems) - is
for use to use an inline namespace for libstdc++ (al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #14 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> looking like a GTY issue:
>
> (gdb) p target->u.fld[1]->rt_mem
> $7 = (mem_attrs *) 0xafafafaf
> (gdb) p target->u.fld[1]->rt_mem->align
>
> that seems to be the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #13 from Iain Sandoe ---
looking like a GTY issue:
(gdb) p target->u.fld[1]->rt_mem
$7 = (mem_attrs *) 0xafafafaf
(gdb) p target->u.fld[1]->rt_mem->align
that seems to be the tell-tale value for a free ptr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #12 from Iain Sandoe ---
hmm .. this is initialising the ramp return object (which is a handle) and when
I look at the to and from trees they seem to have the requisite alignment (the
from value is a return from operator new). I'm a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #10 from Iain Sandoe ---
unfortunately, (or ...) I Have not succeeded in reproducing this - so will need
some help to identify what's being done differently from you.
I built: r15-3667-gf5448384a213 (also on my Darwin17+ set, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #8 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> > --- Comment #6 from Iain Sandoe ---
> > (In reply to Rainer Orth from comment #5)
> >> The new test causes a SIGBUS on 32-bit Solaris/SPARC
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #6 from Iain Sandoe ---
(In reply to Rainer Orth from comment #5)
> The new test causes a SIGBUS on 32-bit Solaris/SPARC (sparc-sun-solaris2.11):
Is this reproducible on any current cfarm machine?
(or, I guess, on a cross?)
||2024-08-29
Status|UNCONFIRMED |NEW
CC||iains at gcc dot gnu.org
--- Comment #3 from Iain Sandoe ---
after discussion, we are all agreed that the current behaviour is not per
standard (or any supposed intent thereof).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
--- Comment #7 from Iain Sandoe ---
(In reply to Arsen Arsenović from comment #6)
> I think it'd be okay to just add the testcase as a regression test consider
> this resolved. WDYT, Iain?
yes - if it's no longer reproducible - then adding the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116506
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
--- Comment #8 from Iain Sandoe ---
(In reply to Artyom Kolpakov from comment #7)
> (In reply to Iain Sandoe from comment #6)
> > fixed on trunk, waiting for possible back-port
>
> I'm not sure if I should write this here, but now a warning has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #10 from Iain Sandoe
gcc dot gnu.org |iains at gcc dot gnu.org
--- Comment #5 from Iain Sandoe ---
fixed on trunk, waiting for possible back-port
||iains at gcc dot gnu.org
--- Comment #3 from Iain Sandoe ---
fixed on trunk, waiting for possible back-port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116482
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116482
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-08-26
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
--- Comment #5 from Iain Sandoe ---
(In reply to Peter Damianov from comment #4)
> Seems like this is fixed on trunk, it no longer ICEs.
>
> https://godbolt.org/z/9oGrGq7xq
It's fixed (or, at least has become latent) on 14.1 and trunk - probab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101976
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #8 from Iain Sandoe ---
Created attachment 58946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58946&action=edit
patch under test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378
--- Comment #13 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #12)
> Created attachment 58943 [details]
> Proposed fix v8
>
> Here is a proposed patch for PR 116181, I was wondering how this patch
> affects darwin? git master + t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378
--- Comment #10 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #9)
> Created attachment 58934 [details]
> Proposed fix
>
> Many thanks Iain and Andrew for your investigation and diagnosis, here is a
> patch based on your analysis:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #7)
> For glibc (even though the Linux kernel might have a different mode_t idea,
> some targets are unsigned short, e.g. arm-linux-eabi) is always:
> #define __MODE_T_T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378
--- Comment #5 from Iain Sandoe ---
Perhaps there's a need for some target-specific code?
I see entries for Glibc - but nothing for 'posix' or 'windows' - so is the
Glibc code supposed to be generic?
-
In file included from /src-local/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-darwin
no analysis so far, but the fixes in PR116181 do not resolve this:
make[3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115660
--- Comment #5 from Iain Sandoe ---
(In reply to Arsen Arsenović from comment #4)
> this PR was fixed by r14-8437-g44868e7298de50 (fix for PR c++/109227).
>
> iain, jason, should we backport that patch? (and resolve that PR?)
seems reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #10 from Iain Sandoe ---
(In reply to Eric Gallager from comment #9)
> Ah, looking at gcc/ada/gcc-interface/Makefile.in, perhaps the issue is that
> I need to set GNATLINK in my environment, too, besides just GNATMAKE and
> GNATBIND.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #8 from Iain Sandoe ---
(In reply to Eric Gallager from comment #7)
> Well ok, could someone send me a binary x86_64 build of GCC for darwin20
> with Ada support that they can bootstrap with successfully, then, so that I
> can get ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981
--- Comment #5 from Iain Sandoe ---
(In reply to Arsen Arsenović from comment #4)
> the latter seems OK to me - mind proposing a patch?
I am planning on doing some rework on the ramp code-gen in the (very) near
future - so can pick this up on t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872
--- Comment #2 from Iain Sandoe ---
fixed on trunk, not sure if we need to back port, leaving open for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871
--- Comment #2 from Iain Sandoe ---
fixed on trunk, not sure if we need to back port, leaving open for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434
--- Comment #3 from Iain Sandoe ---
fixed on trunk, not sure if we need to back port - but leaving open for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #2 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #1)
> NOTE: my compiler builds and tests do not include any macports or homebrew
> components. The only additional content in my PATH is 1) texinfo-6.7 2)
> dejagnu and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #1 from Iain Sandoe ---
The problem with fixing this is that I cannot reproduce it; we are still trying
to determine if there's some dependency on environment - or maybe something
bizarre like the installed version of some utility li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
at gcc dot gnu.org |iains at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #7 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #6)
> Looking at a current discussion of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95517
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104051
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
Bug 16994 depends on bug 101765, which changed state.
Bug 101765 Summary: ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100772
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99710
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #30 from Iain Sandoe ---
blocks have support from 10.6 [Apple gcc-4.2] (although there is/was 'after
market' support for 10.5).
you should be able to find plenty of examples in the Apple Developer doc.
This is now becoming more of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102454
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
CC||iains at gcc dot gnu.org
CC||iains at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108917
--- Comment #4 from Iain Sandoe ---
I think the problem here is related to the setting of DECL_ABSTRACT_ORIGIN on
the contract checking functions.
"
DECL_ABSTRACT_ORIGIN, if non-NULL, points to the original (abstract)
..._DECL node of wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434
--- Comment #1 from Iain Sandoe ---
note that the example uses the new syntax, but the issue applies equally to the
attribute syntax in trunk.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
This applies to void functions and coroutines (which usually have a return
object but do not have a return statement).
e.g:
void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
--- Comment #8 from Iain Sandoe ---
(In reply to Eric Botcazou from comment #7)
> They might come from https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r15-615
> and, in particular, the change made to libgnarl/s-osinte__darwin.ads, in
> which case t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
--- Comment #6 from Iain Sandoe ---
a quick look at current results for other platform versions suggests that:
* x86_64-darwin10 [64b runtimes, but 32b kernel] is also affected but
* from darwin11+ [64 kernel] the main fail is FAIL: cxa4001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115292
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Iain Sandoe ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
--- Comment #4 from Iain Sandoe ---
Created attachment 58322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58322&action=edit
between 856 and 889
likewise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
--- Comment #3 from Iain Sandoe ---
Created attachment 58321
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58321&action=edit
between 792 and 856
likewise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
--- Comment #2 from Iain Sandoe ---
Created attachment 58320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58320&action=edit
between 644 and 792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
--- Comment #1 from Iain Sandoe ---
Created attachment 58319
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58319&action=edit
between 386 and 644
the results have been somewhat turbulent - so posting the ranges I have in case
it helps
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Created attachment 58318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58318&acti
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Host: i686-darwin17
Target: i686-darwin17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #17 from Iain Sandoe ---
however, the opover.o mismatch is a symptom - rather than the cause.
If all the objects for the D FE are built by D, then that would tend to point
to miscompilation of something in common code (that is built
1 - 100 of 1331 matches
Mail list logo
