Domain Name

[Mashood Ali via Gcc]

Hello Sir,
The domain name (g95).org has expired and is going to be deleted soon.
Once it gets deleted, anyone can register it and misuse it.

I want to buy this domain name and create an educational cum programming
website out of it.

Are you willing to sell the above domain name?
Please reply

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Mark Wielaard]

Hi,

On Wed, Nov 09, 2022 at 08:49:22AM +0100, Richard Biener via Gcc wrote:
> On Wed, Nov 9, 2022 at 1:09 AM Sam James via Gcc-patches
>  wrote:
> > > On 9 Nov 2022, at 00:00, Joseph Myers  wrote:
> > > On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> >
> > If that's your expectation, that's fine, but I'd regard it as pretty
> > serious if one didn't build, and I don't remember a time when it didn't.
> >
> > It's not like it's that much use if it fails to build on a bog-standard
> > amd64 platform anyway, as if nothing else, you'd get a deluge
> > of duplicate bug reports.
> 
> I'd say that doing a trunk snapshot build every day as CI would be nice, we
> can then publish one once a week, skipping days where the build failed.
> 
> For release branches having generated files in the snapshots would be
> even more useful and I very much hope the build there always succeeds.

The current buildbot CI jobs already run various builds which just do
a simple non-bootstrap build (plus some that do a full build and make
check) to see if things work:
https://builder.sourceware.org/buildbot/#/builders?tags=gcc&tags=gcc-full

If we make sure the relevant machine/containers contain the necessary
prerequirements then can add the configure flags to some builders to
make sure the docs are generated:
https://sourceware.org/git/?p=builder.git;a=blob;f=README

And make it sent warning emails (to gcc-testresults) when things break.

Cheers,

Mark

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/20/22 18:43, Joseph Myers wrote:
> On Thu, 20 Oct 2022, Martin Liška wrote:
> 
>>> Also, but not strictly part of the release issue:
>>>
>>> (d) Builds with missing or old Sphinx should work regardless of whether 
>>> such files are in the source directory - but if they aren't in the source 
>>> directory, the effect of missing or old Sphinx (detected at configure 
>>> time) should be to disable building and installing documentation.
>>
>> All right Joseph, is it something you're willing to help me once we start
>> using Sphinx? Apparently, there will be many consequent steps after we 
>> switch.
> 
> Sure, but most of the conditionals are *already* present, just need 
> updating as part of the Sphinx transition.  E.g. gcc/Makefile.in has 
> BUILD_INFO and GENERATED_MANPAGES conditionals based on configure tests 
> for whether relevant tools are present and new enough; the rules for 
> $(DESTDIR)$(infodir)/%.info quietly allow the info files not to be 
> present, so installing also works without the info files or tools to build 
> them, and the rules for installing man pages similarly ignore errors; and 
> there are srcinfo and srcman rules, enabled based on @GENINSRC@, to copy 
> those built files to the source directory, which are what's used when 
> --enable-generated-files-in-srcdir is used as part of building a release 
> tarball.
> 
> The main thing I've suggested that I think may actually be new is an error 
> for trying to build a release tarball without new-enough Sphinx (I think 
> the current rules would quietly not copy info / man pages to the source 
> directory if build tools were missing - but having those tools missing 
> when building a release tarball is much less likely than not having 
> new-enough Sphinx).
> 

Hello Joseph.

So the transition is done and I would to ask you Joseph for help with the
following 2 items:

1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am.
Apparently, I modified the generated Makefile.in file with the rules like:

doc/info/texinfo/libitm.info: $(SPHINX_FILES)
+ if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
  make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
else true; fi

Can you please modify Makefile.am in the corresponding manner and re-generate 
Makefile.in?

2) Adding proper support --enable-generated-files-in-srcdir in gcc_release:

As mentioned above in the quoted email.

Thanks in advance,
Martin

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Joseph Myers]

On Wed, 9 Nov 2022, Richard Biener via Gcc wrote:

> I'd say that doing a trunk snapshot build every day as CI would be nice, we
> can then publish one once a week, skipping days where the build failed.

Note that each snapshot should have diffs relative to the previous 
published snapshot.  Not relative to some other one that was not 
published, for example.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Joseph Myers]

On Wed, 9 Nov 2022, Martin Liška wrote:

> 1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am.
> Apparently, I modified the generated Makefile.in file with the rules like:
> 
> doc/info/texinfo/libitm.info: $(SPHINX_FILES)
>   + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
> make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
> BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
>   else true; fi
> 
> Can you please modify Makefile.am in the corresponding manner and re-generate 
> Makefile.in?

I think someone else had best look at this.

> 2) Adding proper support --enable-generated-files-in-srcdir in gcc_release:

It looks like all the GENINSRC rules / conditionals are still present.  
So maybe there are details where the paths are wrong, or where fixes are 
needed to ensure the files get installed from the source directory when 
available in the source directory but not available in the build directory 
because Sphinx isn't available, but much of the code for the feature is 
still there.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Richard Biener via Gcc]

On Wed, Nov 9, 2022 at 6:11 PM Joseph Myers  wrote:
>
> On Wed, 9 Nov 2022, Richard Biener via Gcc wrote:
>
> > I'd say that doing a trunk snapshot build every day as CI would be nice, we
> > can then publish one once a week, skipping days where the build failed.
>
> Note that each snapshot should have diffs relative to the previous
> published snapshot.  Not relative to some other one that was not
> published, for example.

Sure, but diffs can be created from the two snapshot tarballs at
publishing time.

Richard.

>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar via Gcc]

Hi Martin,

On 9/3/22 17:31, Martin Uecker wrote:

My experience is that if one wants to see something fixed,
one has to push for it.  Standardization is meant
to standardize existing practice, so if we want to see
this improved, we can not wait for this.


I fully agree with you.  I've been ruminating these patches for some time, for 
having some more time to think about them.  Now, I like them enough to push. 
So, after a few minor cosmetic issues detected by some linters, I've pushed the 
changes to document all of man2 and man3 with hypothetical VLA syntax.


Now, I've released man-pages-6.01 very recently (just a few weeks ago), and I 
don't plan to release again in a year or two, so there's time to do the 
implementation in GCC.  From my side, please consider this an ACK or even 
somewhat of a push to get things done in the compiler side of things :)


I'll show here an excerpt of what kind of syntax has been pushed.  Of course, 
there's room for improving/fixing, since it's not seen an official release, but 
for now, this is what's up there:



   int strncmp(const char s1[.n], const char s2[.n], size_t n);

   long mbind(void addr[.len], unsigned long len, int mode,
  const unsigned long nodemask[(.maxnode + ULONG_WIDTH ‐ 1)
   / ULONG_WIDTH],
  unsigned long maxnode, unsigned int flags);

   int cacheflush(void addr[.nbytes], int nbytes, int cache);


I've shown the three kinds of prototypes that have been changed:

-  Normal VLA; nothing fancy except for the '.'.
-  Complex size expressions.
-  'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).


Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar via Gcc]

On 11/10/22 01:06, Alejandro Colomar wrote:

Hi Martin,

On 9/3/22 17:31, Martin Uecker wrote:

My experience is that if one wants to see something fixed,
one has to push for it.  Standardization is meant
to standardize existing practice, so if we want to see
this improved, we can not wait for this.


I fully agree with you.  I've been ruminating these patches for some time, for 
having some more time to think about them.  Now, I like them enough to push. So, 
after a few minor cosmetic issues detected by some linters, I've pushed the 
changes to document all of man2 and man3 with hypothetical VLA syntax.


Now, I've released man-pages-6.01 very recently (just a few weeks ago), and I 
don't plan to release again in a year or two, so there's time to do the 
implementation in GCC.  From my side, please consider this an ACK or even 
somewhat of a push to get things done in the compiler side of things :)


I'll show here an excerpt of what kind of syntax has been pushed.  Of course, 
there's room for improving/fixing, since it's not seen an official release, but 
for now, this is what's up there:



    int strncmp(const char s1[.n], const char s2[.n], size_t n);

    long mbind(void addr[.len], unsigned long len, int mode,
   const unsigned long nodemask[(.maxnode + ULONG_WIDTH ‐ 1)
    / ULONG_WIDTH],
   unsigned long maxnode, unsigned int flags);

    int cacheflush(void addr[.nbytes], int nbytes, int cache);


I've shown the three kinds of prototypes that have been changed:

-  Normal VLA; nothing fancy except for the '.'.
-  Complex size expressions.
-  'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).


Oops: sizeof(void)==1



Cheers,

Alex



--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:

> I've shown the three kinds of prototypes that have been changed:
> 
> -  Normal VLA; nothing fancy except for the '.'.
> -  Complex size expressions.
> -  'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).

That doesn't cover any of the tricky issues with such proposals, such as 
the choice of which entity is referred to by the parameter name when there 
are multiple nested parameter lists that use the same parameter name, or 
when the identifier is visible from an outer scope (including in 
particular the case where it's declared as a typedef name in an outer 
scope).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Thu, 10 Nov 2022, Joseph Myers wrote:

> On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
> 
> > I've shown the three kinds of prototypes that have been changed:
> > 
> > -  Normal VLA; nothing fancy except for the '.'.
> > -  Complex size expressions.
> > -  'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).
> 
> That doesn't cover any of the tricky issues with such proposals, such as 
> the choice of which entity is referred to by the parameter name when there 
> are multiple nested parameter lists that use the same parameter name, or 
> when the identifier is visible from an outer scope (including in 
> particular the case where it's declared as a typedef name in an outer 
> scope).

In fact I can't tell from these examples whether you mean for a '.' token 
after '[' to have special semantics, or whether you mean to have a special 
'. identifier' form of expression valid in certain context (each of which 
introduces its own complications; for the former, typedef names from outer 
scopes are problematic; for the latter, it's designated initializers where 
you get complications, for example).  Designing new syntax that doesn't 
cause ambiguity is generally tricky, and this sort of language extension 
is the kind of thing where you'd expect to so through at least five 
iterations of a WG14 paper before you have something like a sound 
specification.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Martin Uecker via Gcc]

Am Donnerstag, den 10.11.2022, 01:39 + schrieb Joseph Myers:
> On Thu, 10 Nov 2022, Joseph Myers wrote:
> 
> > On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
> > 
> > > I've shown the three kinds of prototypes that have been changed:
> > > 
> > > -  Normal VLA; nothing fancy except for the '.'.
> > > -  Complex size expressions.
> > > -  'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).
> > 
> > That doesn't cover any of the tricky issues with such proposals, such as 
> > the choice of which entity is referred to by the parameter name when there 
> > are multiple nested parameter lists that use the same parameter name, or 
> > when the identifier is visible from an outer scope (including in 
> > particular the case where it's declared as a typedef name in an outer 
> > scope).
> 
> In fact I can't tell from these examples whether you mean for a '.' token 
> after '[' to have special semantics, or whether you mean to have a special 
> '. identifier' form of expression valid in certain context (each of which 
> introduces its own complications; for the former, typedef names from outer 
> scopes are problematic; for the latter, it's designated initializers where 
> you get complications, for example).  Designing new syntax that doesn't 
> cause ambiguity is generally tricky, and this sort of language extension 
> is the kind of thing where you'd expect to so through at least five 
> iterations of a WG14 paper before you have something like a sound 
> specification.

I am not sure what Alejandro has in mind exactly, but my idea of using
a new notation [.identifier] would be to limit it to accessing other
parameter names in the same parameter list only, so that there is 

1) no ambiguity what is referred to  and  
2) one can access parameters which come later 

If we want to specify something like this, I think we should also
restrict what kind of expressions one allows, e.g. it has to
be side-effect free.  But maybe we want to make this even more
restrictive (at least initially).

One problem with WG14 papers is that people put in too much,
because the overhead is so high and the standard is not updated
very often.  It would be better to build such feature more
incrementally, which could be done more easily with a compiler
extension.  One could start supporting just [.x] but not more
complicated expressions.

Later WG14 can still accept or reject or modify this proposal
based on the experience we get.

(I would also be happy with using GNU forward declarations, and
I am not sure why people dislike them so much.) 


Martin