https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120495
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120495
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=116400
--- Comment #17 from Iain Sandoe ---
on macOS we have to use gm4 (the installed version does not recognise -g or
--gnu).
Having said that, *developers* working on GCC on macOS most likely do have a
newer version installed, since the OS one is o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
--- Comment #12 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #10)
> my understanding is that the conclusion of CWG2563 is that this behaviour
> was not the intended design - and the resolution to this is in PR119916.
>
> (so that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
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=118074
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118074
--- Comment #10 from Iain Sandoe ---
(In reply to Weibo He from comment #9)
> Thank you for your work. I noticed the heap-use-after-free issue might still
> be present?
>
> https://godbolt.org/z/79bvTfWe5
I think this is because the design of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118903
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118903
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118074
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
--- Comment #11 from Iain Sandoe ---
so... if I add this - non-coroutine ...
LazyTask
foo (detail::LazyTaskPromise& p)
{
decltype(auto) Gro = p.get_return_object();
return Gro;
}
we essentially get the same fail;
../temp-coro-tests/pr1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
Iain Sandoe changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
--- Comment #7 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #6)
> Interesting if I change the lambda into a normal function:
> ```
> auto coro() ->LazyTask
> {
> co_await []() -> Task {}();
> }
> ```
>
> GCC 15 rejects i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
--- Comment #5 from Iain Sandoe ---
thanks for the report.
Note that GCC-15 is not doing the correct operations in respect of the CWG2563
discussions (see PR119916 and PR115908).
However, this can still be a new issue (not analysed so far).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
--- Comment #10 from Iain Sandoe ---
my understanding is that the conclusion of CWG2563 is that this behaviour was
not the intended design - and the resolution to this is in PR119916.
(so that, unless there's new information, this bug would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #14 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Francois-Xavier Coudert from comment #12)
> > Created attachment 61532 [details]
> > Regeneration script
> >
> > Attached is a shell script, to be pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #13 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #12)
> Created attachment 61532 [details]
> Regeneration script
>
> Attached is a shell script, to be placed in libgfortran/, that can be run in
> that direc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #9 from Iain Sandoe ---
If the Fortran maintainers prefer to revert the patch then I shall not
complain.
The configure version was changed in GCC-9 and no-one had stepped forward to
update the Fortran build code even by GCC-15. I (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #6 from Iain Sandoe ---
(In reply to kargls from comment #4)
> FX, Iain,
>
> Can one of you please fix this bug or revert your patch?
It would be unfortunate to return to the situation where we cannot use
autoreconf to regenerate t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #16 from Iain Sandoe ---
(In reply to Jason Merrill from comment #15)
> Created attachment 61520 [details]
> updated fix
>
> Here's a better version of the patch, also sent to gcc-patches.
replied on-list, this also resolves the is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177
--- Comment #25 from Iain Sandoe ---
(In reply to Janko Dedic from comment #24)
> It seems like P2014 is no longer being pursued.
>
> https://github.com/cplusplus/papers/issues/750#issuecomment-2657897866
I spoke with the author, the paper has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120409
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2025-05-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #23 from Iain Sandoe ---
what is the "waiting" status for?
( I don't see any trunk commits recently for us to test )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #12 from Iain Sandoe ---
(In reply to Richard Biener from comment #11)
> D_V_E? DECL_VALUE_EXPR?
yes..
> I guess we should indeed treat those as having
> side-effects.
struct F {
bool b;
};
int foo (F *a)
{
if (a && !a->b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #10 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > I think if you set TREE_SIDE_EFFECTS on the decls that have a D_V_E, then it
> > might just work.
>
> i can also tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #7)
> I think if you set TREE_SIDE_EFFECTS on the decls that have a D_V_E, then it
> might just work.
i can also try that (but I'd want to avoid doing something that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > that is TRUTH_ANDIF_EXPR being converted into TRUTH_AND_EXPR in fold because
> > fold thinks coro_before_return and c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #4 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #3)
> that is TRUTH_ANDIF_EXPR being converted into TRUTH_AND_EXPR in fold because
> fold thinks coro_before_return and cond don't have side effects as they are
> normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
Iain Sandoe changed:
What|Removed |Added
Version|15.0|16.0
--- Comment #1 from Iain Sandoe ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
--- Comment #8 from Iain Sandoe ---
(In reply to Alisdair Meredith from comment #7)
> For a short term workaround adding `-D_Alignof=alignof` to your command
> lines should work -- at least according to my quick testing.
>
> If gcc were to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
Bug ID: 120400
Summary: C++ FE optimisations reorder && operands.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #7 from Iain Sandoe ---
update:
It seems not simply the inlining of the actor into the ramp
but also when the result of that is then inlined into main()
If I apply DECL_DISREGARD_INLINE_LIMITS() to the actor - so that it is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #6 from Iain Sandoe ---
a slightly modified testcase (without the lambda, so the dumps are easier to
read)
#include
struct coro {
struct promise_type {
promise_type() = default;
std::suspend_never initial_sus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273
--- Comment #10 from Iain Sandoe ---
Maybe something like this:
diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc
index fef6ae6f457..43054f105ea 100644
--- a/gcc/c-family/c-lex.cc
+++ b/gcc/c-family/c-lex.cc
@@ -109,6 +109,10 @@ get_fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed|2025-05-20 00:00:00 |2025-5-21
--- Comment #9 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2025-05-20
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #5 from Iain Sandoe ---
we synthesise the same code, but the revised builder uses
start_preparsed_function()/finish_function() and the latter introduces an extra
try block. Investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #4 from Iain Sandoe ---
(In reply to Patrick Palka from comment #3)
> Started with r15-3148-g6303cd7e41546e "c++, coroutines: Separate the
> analysis, ramp and outlined function synthesis."
thanks; (unfortunately) not fixed by the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
--- Comment #17 from Iain Sandoe ---
(In reply to Robert Dubner from comment #13)
> Thanks. Sadly, that didn't tell me anything useful.
>
> The front-end code that's failing is slated to be completely eliminated when
> Jim gets a chance to wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed|2025-03-21 00:00:00 |2025-5-12
--- Comment #10 from Iain Sando
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
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=105404
--- Comment #17 from Iain Sandoe ---
(In reply to Joel Sherrill from comment #16)
> Over at RTEMS.org, we have a report from a Mac user that the gcc zlib needs
> updating or patched to build there. We are seeing this with GCC 13 but the
> versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930
--- Comment #7 from Iain Sandoe ---
coroutine lowering is not (other than FE folding) dependent on the opt level.
So this is likely something related to inlining.
The only "special" thing about coroutines is that they have return edges
[intent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98935
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106973
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113457
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110635
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109682
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #5 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #22 from Iain Sandoe ---
Given that Rainer reports that this is a regression from GCC-10, I was looking
into back porting it for GCC-14.3. However, it does not seem that either the
pr115905 or the test case here fail with current re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
--- Comment #17 from Iain Sandoe ---
(In reply to Jason Merrill from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > hmm .. EWG does seem to iterate at times ... maybe I can reach out to Lewis
> > for the example (and to ask him ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
--- Comment #15 from Iain Sandoe ---
hmm .. EWG does seem to iterate at times ... maybe I can reach out to Lewis for
the example (and to ask him how Ville's request is intended to be handled).
This got discussed in some depth during the work on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
--- Comment #13 from Iain Sandoe ---
[IMO] I would suggest that GCC's behaviour (now) is the correct one [intended
by the design].
Consider a request such as made by Ville "I want the ramp return object to be
able to tell me if the coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
--- Comment #12 from Iain Sandoe ---
noting the CWG issue, this is a tricky area since [current] tests might be
expecting either the existing clang/MSVC (and previous GCC) behaviour - or the
revised GCC behaviour.
What seems clear to me is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
--- Comment #12 from Iain Sandoe ---
(In reply to Jason Merrill from comment #11)
> Created attachment 61123 [details]
> fix
>
> This seems like an appropriate fix, can someone test it on an affected
> target?
A spot-check on x86_64 darwin21 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #10 from Iain Sandoe ---
fixed on trunk, backports to follow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119524
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2025-04-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #17 from Iain Sandoe ---
(In reply to Robert Dubner from comment #16)
> Mainframe programmers sometimes think differently, I believe.
>
> If my understanding from discussions with an old-school mainframe programmer
> -- who admitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #5 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #4)
> (In reply to Iain Sandoe from comment #2)
> > it's always been broken, unfortunately (for a start, it gets the range
> > wrong)
> > At that stage, there were not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #2 from Iain Sandoe ---
(In reply to Peter Bergner from comment #1)
> (In reply to Sergey Fedorov from comment #0)
> > :info:build ld: bl out of range (-16839456 max is +/-16M) from
> > __ZN10hash_tableI19default_hash_traitsIP11cgrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #15 from Iain Sandoe ---
(In reply to rdubner from comment #14)
> > -Original Message-
> > From: iains at gcc dot gnu.org
> > Sent: Wednesday, April 9, 2025 11:19
> > To: rdub...@gcc.gnu.org
> > Subject: [Bug cobol/119414] c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #12 from Iain Sandoe ---
(In reply to rdubner from comment #11)
> COBOL comes from long ago, and far away. And the vast bulk of code that I
> never forget is where my boss, paying my salary, hopes to someday actually
> make some m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #8 from Iain Sandoe ---
(In reply to Robert Dubner from comment #7)
> The commit has the comment, "...the options had been added during development
> to handle specific cases, they are no longer needed..."
> That turns out not t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
Iain Sandoe changed:
What|Removed |Added
Attachment #61030|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
Iain Sandoe changed:
What|Removed |Added
Attachment #52980|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119647
--- Comment #5 from Iain Sandoe ---
this seems odd, ICU is a system component - so presumably the version released
on Apple's Open Source repo should be buildable by the system. What version of
ICU are you trying to build (and where from)?
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
Iain Sandoe changed:
What|Removed |Added
Assignee|iains at gcc dot gnu.org |unassigned at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
--- Comment #16 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #15)
> This still does not work with gcc-14.2.0.
>
> ```
> :info:build In file included from
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
--- Comment #7 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #6)
> (In reply to Iain Sandoe from comment #2)
> > I have posted patches (which need an update [on my shorter TODO] that
> > implement the availability attribute). Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
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=93469
--- Comment #13 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #12)
> (In reply to Jonathan Wakely from comment #10)
>
> The same error happens even without the macro in question being passed, at
> least explicitly. Getting it wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119595
--- Comment #5 from Iain Sandoe ---
Very encouraging
I put this patch (with obvious amendments) on top of my posted patches for
libquadmath support - and then adjusted the sorry in cobol1 (so that it only
required float128).
x86_64-darwin1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
Bug 119364 depends on bug 119242, which changed state.
Bug 119242 Summary: cobol Front end requires __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119242
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119242
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
--- Comment #4 from Iain Sandoe ---
on Darwin the newly-added tests:
INSPECT_ISO_Example_1, 2, 3, 4, 5-f, 5-r, 6 and 7 fail with the same symptoms.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296
--- Comment #2 from Iain Sandoe ---
r15-9183-gb6aafe9a5b1452f3 has replacements for strfromf32/64. Support for
f128 on targets which can support __float128 can be provided by libquadmath
which has conversion functions).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
Bug 119217 depends on bug 119295, which changed state.
Bug 119295 Summary: cobol, libcobol uses random_r which is GLIBC specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
Iain Sandoe changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #5 from Iain Sandoe
1 - 100 of 1297 matches
Mail list logo
