> -Original Message-
> From: Rainer Orth
> Sent: Friday, April 11, 2025 05:17
> To: gcc-patches@gcc.gnu.org
> Cc: Robert Dubner ; James K. Lowden
>
> Subject: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]
>
> All users of symbols.h fail to compile o
On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote:
> fine with me. This way there's no hurry with the other patches for fear
> of either breaking the build on non-Linux platforms or impacting COBOL
> on Linux.
No rush, sure, on the other side, better resolve all those in stage1...
Jakub Jelinek writes:
> On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote:
>> fine with me. This way there's no hurry with the other patches for fear
>> of either breaking the build on non-Linux platforms or impacting COBOL
>> on Linux.
>
> No rush, sure, on the other side, better reso
Hi Jakub,
> On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote:
>> what about trunk then? Right now, cobol still doesn't build there on
>> Solaris/amd64 because 3 patches are missing:
>>
>> cobol: Don't require GLOB_BRACE etc. [PR119217]
>> https://gcc.gnu.org/pipermail/gcc
On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote:
> what about trunk then? Right now, cobol still doesn't build there on
> Solaris/amd64 because 3 patches are missing:
>
> cobol: Don't require GLOB_BRACE etc. [PR119217]
> https://gcc.gnu.org/pipermail/gcc-patches/2025-Apr
Hi Richard,
> On Tue, Apr 22, 2025 at 12:31 PM Sam James wrote:
>>
>> Jakub Jelinek writes:
>>
>> > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
>> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>> >> >
>> >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wr
On Tue, Apr 22, 2025 at 12:31 PM Sam James wrote:
>
> Jakub Jelinek writes:
>
> > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
> >> >
> >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >> > > That's o
Jakub Jelinek writes:
> On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
>> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>> >
>> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> > > That's one option, but maybe it's better the other way round: instead of
>
On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote:
> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
> >
> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> > > That's one option, but maybe it's better the other way round: instead of
> > > excluding known-bad targe
Jakub Jelinek writes:
> On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote:
>> Sam James writes:
>>
>> > Richard Biener writes:
>> >
>> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>> >>>
>> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> >>> > That's one
On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote:
> Sam James writes:
>
> > Richard Biener writes:
> >
> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
> >>>
> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >>> > That's one option, but maybe it's better the
On Mon, Apr 21, 2025 at 11:16 AM Sam James wrote:
>
> Sam James writes:
>
> > Richard Biener writes:
> >
> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
> >>>
> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >>> > That's one option, but maybe it's better the other
Sam James writes:
> Richard Biener writes:
>
>> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>>>
>>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>>> > That's one option, but maybe it's better the other way round: instead of
>>> > excluding known-bad targets, restrict co
Richard Biener writes:
> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>>
>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> > That's one option, but maybe it's better the other way round: instead of
>> > excluding known-bad targets, restrict cobol to known-good ones
>> >
On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote:
>
> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> > That's one option, but maybe it's better the other way round: instead of
> > excluding known-bad targets, restrict cobol to known-good ones
> > (i.e. x86_64-*-linux* and aarch6
; gcc-patches@gcc.gnu.org; Robert Dubner
> >> ; James K. Lowden
> >> Subject: Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]
> >>
> >> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >> > That's one option, but maybe it
Robert Dubner writes:
>> -Original Message-
>> From: Jakub Jelinek
>> Sent: Friday, April 18, 2025 14:10
>> To: Rainer Orth
>> Cc: Richard Biener ; Andreas Schwab
>> ; gcc-patches@gcc.gnu.org; Robert Dubner
>> ; James K. Lowden
>>
> -Original Message-
> From: Jakub Jelinek
> Sent: Friday, April 18, 2025 14:10
> To: Rainer Orth
> Cc: Richard Biener ; Andreas Schwab
> ; gcc-patches@gcc.gnu.org; Robert Dubner
> ; James K. Lowden
> Subject: Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR
On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> That's one option, but maybe it's better the other way round: instead of
> excluding known-bad targets, restrict cobol to known-good ones
> (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
>
> I've been using the following for this
Hi Jakub,
> On Fri, Apr 18, 2025 at 01:53:25PM +0200, Rainer Orth wrote:
>> Unless this can be figured out quickly, I suspect the safest solution
>> for now would be to replace the (not filename-related) NAME_MAX by it's
>> Linux definition of 255. Something like this would be
>> required to unb
On Fri, Apr 18, 2025 at 01:53:25PM +0200, Rainer Orth wrote:
> Unless this can be figured out quickly, I suspect the safest solution
> for now would be to replace the (not filename-related) NAME_MAX by it's
> Linux definition of 255. Something like this would be
> required to unbreak Solaris/amd6
Richard Biener writes:
> On Fri, Apr 11, 2025 at 2:14 PM Rainer Orth
> wrote:
>>
>> Andreas Schwab writes:
>>
>> > On Apr 11 2025, Rainer Orth wrote:
>> >
>> >> All users of symbols.h fail to compile on Solaris:
>> >>
>> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
>>
Andreas Schwab writes:
> On Apr 11 2025, Rainer Orth wrote:
>
>> All users of symbols.h fail to compile on Solaris:
>>
>> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
>> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’
>> was not declared in this
On Fri, Apr 11, 2025 at 2:14 PM Rainer Orth
wrote:
>
> Andreas Schwab writes:
>
> > On Apr 11 2025, Rainer Orth wrote:
> >
> >> All users of symbols.h fail to compile on Solaris:
> >>
> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
> >> /vol/gcc/src/hg/master/local/gcc/co
> You're right: seems to be all about COBOL function names. No idea
what value is appropriate/required here, though.
if this is about COBOL internal function names: ISO says and GnuCOBOL
therefore defines
/* Maximum length of COBOL words */
#define COB_MAX_WORDLEN 63
Note that _extern
All users of symbols.h fail to compile on Solaris:
/vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
/vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’ was
not declared in this scope
1365 | char name[NAME_MAX];
| ^~~~
NAME_MAX be
On Apr 11 2025, Rainer Orth wrote:
> All users of symbols.h fail to compile on Solaris:
>
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’
> was not declared in this scope
> 1365 | char name[NAME_
27 matches
Mail list logo
