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
> &
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
--- Comment #4 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #3)
> So something fixincludes should fix?
looks like another case where having a single FE for c-family makes it easy to
mistakenly accept C in C++ and vice versa
At
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #32 from Iain Sandoe ---
I am being asked (by build systems folks) to make it possible to build back to
10.13 with the current [XC 16] SDKs (which are supposed to support that - but
do not include these symbols).
This seems a reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119172
--- Comment #3 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #2)
> fixed on trunk so far, back ports to follow.
this also needs r15-8244-gfc728cfd569e29, which corrects my typos, to be back
ported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119218
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794
--- Comment #4 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #3)
> I wonder if this could be described as a thunk.
My mental image is more of a trampoline..
.. since the fundamental issue is that some ABIs need registers updated f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Target: *-darwin*
gg_printf outputs code that attempts to call fprintf (stderr, ...) on the
target.
this is used by "P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #34 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #33)
> (In reply to Eric Gallager from comment #31)
> This does not help us much though, unfortunately, since that support appears
> rudimentary and, importantly, won
||https://gcc.gnu.org/piperma
||il/gcc-patches/2025-March/6
||78599.html
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Comment #4 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #20 from Iain Sandoe ---
(In reply to Michael Duggan from comment #19)
> I submitted a patch.
Yes a saw that - thanks, it does need other people to review it though,
> I also recently thought of another potential solution.
> We co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119435
--- Comment #5 from Iain Sandoe ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Iain Sandoe from comment #1)
> > In the meantime, you have no solution except to make the priority attribute
> > conditional on !defined(__APPLE__).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119435
--- Comment #3 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #2)
> (In reply to Iain Sandoe from comment #1)
> > I am actually surprised we don't have an enhancement bug for this.
> >
> > The reason we do not have this is becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119435
Iain Sandoe changed:
What|Removed |Added
Severity|normal |enhancement
Target|powerpc-ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88319
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
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=88319
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #18 from Iain Sandoe ---
(In reply to Michael Duggan from comment #17)
> Gcov doesn't have access to the function declaration, only to the
> information that has been output to the count and graph files. Neither of
> those contain a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #16 from Iain Sandoe ---
(In reply to Michael Duggan from comment #15)
> Would it be possible for one of these to make it into version 15?
I'd prefer the change that teaches gcov about coroutines, I fear the change to
the status of
: normal
Priority: P3
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
The following options are added unconditionally by gcobolspec.cc and either
need conditionalising or removing:
(plus some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #28 from Iain Sandoe ---
did not succeed in testing on powerpc64le (it built OK, but the testsuite does
not run because of PR119308)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
Iain Sandoe changed:
What|Removed |Added
Attachment #60792|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #26 from Iain Sandoe ---
Also .. I'm a bit fuzzy still about the absolute requirements.
Is there any specific reason (apart from "people don't like it") that this
would not work with native __ibm128 long double?
granted, at present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #25 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #24)
> Created attachment 60792 [details]
> v2 patch with support for long double and literal suffix wrapping.
>
> This tries to pick up Jakub's suggestion as to how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
Iain Sandoe changed:
What|Removed |Added
Attachment #60777|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #23 from Iain Sandoe ---
(In reply to Richard Biener from comment #21)
> (In reply to Richard Biener from comment #19)
> > I'll cook up a preliminary patch for the Q vs. f128 change.
>
> Note it seems libgfortran LIBGFOR_CHECK_FLOAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #20 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #18)
> I think s390x-linux is similar to aarch64-linux here, neither has
> libquadmath support.
However, libquadmath works fine on aarch64-darwin, so it is a possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #15 from Iain Sandoe ---
(In reply to Richard Biener from comment #14)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Richard Biener from comment #11)
> > > I'll note this also affects s390x-linux where libgcobol curre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #12 from Iain Sandoe ---
(In reply to Richard Biener from comment #11)
> I'll note this also affects s390x-linux where libgcobol currently fails to
> build due to
>
> ../../../gcc/libgcobol/intrinsic.cc:984:3: error: unsupported non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
--- Comment #10 from Iain Sandoe ---
In my patches for Darwin/macOS - I did it in a more long-winded way by removing
the CPPFLAGS def completely and then adding:
+CFLAGS-cobol/cobol1.o += -I$(LIB_SOURCE)
+CFLAGS-cobol/genutil.o += -I$(LIB_SOU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #7 from Iain Sandoe ---
(In reply to Robert Dubner from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > In my experiments with x86_64 Darwin and Linux, I have managed to convert
> > the library to use libquadmath.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119172
Iain Sandoe changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 from Iain Sando
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|iains at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #9 from Iain Sandoe ---
Created attachment 60777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60777&action=edit
Initial patch (working on x86_64 darwin and linux)
The relationship between the library and the FE remains uncle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
--- Comment #6 from Iain Sandoe ---
Created attachment 60776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60776&action=edit
Patch to remove std= and forced lib paths
This removes these from the CPPSPEC in the cobol Make-lang.in and also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|iains at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295
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=119295
--- Comment #1 from Iain Sandoe ---
Created attachment 60775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60775&action=edit
Patch tested on x86_64 Darwin and Linux
Unfortunately, we don't have a fallback on Darwin other than to use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|iains at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #5 from Iain Sandoe ---
In my experiments with x86_64 Darwin and Linux, I have managed to convert the
library to use libquadmath.
I started to try and apply Jakub's suggestions to the FE for this BZ, since
what it is doing at the mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283
--- Comment #3 from Iain Sandoe ---
Created attachment 60770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60770&action=edit
Add implementation of memrchr to libiberty
This is a trial implementation of adding memrchr to libiberty,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250
--- Comment #7 from Iain Sandoe ---
Created attachment 60766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60766&action=edit
patch under test
This makes the configure test for basename use the same process as in libiberty
so that the res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119218
Iain Sandoe changed:
What|Removed |Added
Attachment #60727|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301
--- Comment #3 from Iain Sandoe ---
Created attachment 60764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60764&action=edit
patch under test
this works on Darwin... but not tested more widely yet/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301
--- Comment #4 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #1)
> https://www.gnu.org/software/libc/manual/html_node/Working-Directory.html
>
> Describes how get_current_dir_name could be implemented.
>
> Since this is in the f
Priority: P3
Component: cobol
Assignee: iains at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
I think we can fix this by falling back to getcwd() which libiberty provides if
it's not available on $host.
Priority: P3
Component: cobol
Assignee: iains at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
This is a build failure on non-Linux platforms.
(working on a draft work-around)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: cobol
Assignee: iains at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
this is a build failure on platforms without support
(working on a work-around)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283
--- Comment #2 from Iain Sandoe ---
(In reply to Richard Biener from comment #1)
> I wonder if it could just use strrchr as fallback?
IDK if cobol strings are always null-terminated?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2025-03-14
Status|UNCONFIRMED
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
lexio.cc and scan-ante.h make unconditional use of memrchr which is not
available on all host platforms and currently not available via libiberty.
Since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
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=119241
Iain Sandoe changed:
What|Removed |Added
CC||jklowden at schemamania dot
org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250
--- Comment #6 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > Does anyone know why libiberty doe not install the build-time config file
> > and have libiberty.h include it?
>
> T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119218
--- Comment #15 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #14)
> Created attachment 60727 [details]
> Patch under test
>
> Please could you let me know if this works for Solaris too.
>
> (note that this does not fix the cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250
--- Comment #4 from Iain Sandoe ---
there seems to be a fundamental inconsistency here;
* libiberty is configured (and determines the availability of the POSIX
basename). If that is not found, then it provides and publishes the fall-back
(but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119218
--- Comment #14 from Iain Sandoe ---
Created attachment 60727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60727&action=edit
Patch under test
Please could you let me know if this works for Solaris too.
(note that this does not fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250
--- Comment #3 from Iain Sandoe ---
this:
# gcc_AC_CHECK_DECLS doesn't support overloaded functions, so use the
# normal autoconf function for these. But force definition of
# HAVE_DECL_BASENAME like gcc_AC_CHECK_DECLS does, to suppress the bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250
Iain Sandoe changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 f
1 - 100 of 1514 matches
Mail list logo
