Re: New "Diving into GCC internals" section in newbies guide

[Sam James via Gcc]

> On 10 Jun 2022, at 22:58, David Malcolm via Gcc  wrote:
> 
> I've written a large new chunk of documentation for my GCC newbies
> guide, called "Diving into GCC internals", which can be seen at:
> 
> https://gcc-newbies-guide.readthedocs.io/en/latest/diving-into-gcc-internals.html
> 
> Hope this is helpful; please let me know if you see any mistakes, or if
> there's room for improvement
> 

I didn't even realise the guide existed at all!

This looks really interesting, thanks!

> Dave
> 



signature.asc
Description: Message signed with OpenPGP

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Sam James via Gcc]

> On 8 Nov 2022, at 13:55, Martin Liška  wrote:
> 
> Hi.
> 
> Tomorrow in the morning (UTC time), I'm going to migrate the documentation
> to Sphinx. The final version of the branch can be seen here:
> 
> $ git fetch origin refs/users/marxin/heads/sphinx-final
> $ git co FETCH_HEAD
> 
> URL: https://splichal.eu/gccsphinx-final/
> 
> TL;DR;
> 
> After the migration, people should be able to build (and install) GCC even
> if they miss Sphinx (similar happens now if you miss makeinfo). However, 
> please
> install Sphinx >= 5.3.0 (for manual and info pages - only *core* package is 
> necessary) [1]
> 
> Steps following the migration:
> 
> 1) update of web HTML (and PDF documentation) pages:
>   I prepared a script and tested our server has all what we need.
> 2) gcc_release --enable-generated-files-in-srcdir: here I would like
>   to ask Joseph for cooperation

Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
even for snapshots? Pretty please? :)

> 3) URL for diagnostics (used for warning) - will utilize [3]
> 4) package source tarballs - https://gcc.gnu.org/onlinedocs/ (listed here)
> 5) updating links from gcc.gnu.org that point to documentation
> 6) removal of the further Texinfo leftovers
> ...
> 

Thanks for working on this. Very excited.

> Cheers,
> Martin

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Sam James via Gcc]

> On 9 Nov 2022, at 00:00, Joseph Myers  wrote:
> 
> On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> 
>> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
>> even for snapshots? Pretty please? :)
> 
> I think we want snapshots to come out weekly even if the compiler or
> documentation build fails, which makes anything involving a build as part
> of the snapshot process problematic.

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.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 10 Nov 2022, at 21:10, Michael Orlitzky  wrote:
> 
> On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote:
>> 
>> Nobody has a whole lot of time to work on Autoconf at present, but I
>> would like to ask, anyway, what Autoconf could potentially do to make
>> this transition easier.
> 
> While everyone else is discussing big ideas, it would be helpful for me
> personally if autoconf just made a release with the latest bugfixes.
> 
> I report these compatibility issues upstream, and it's awkward to have
> to tell the maintainers that they must cherry-pick a git commit,
> rebuild autoconf, and then autoreconf their project before they can
> even even think about exporting CFLAGS="-Werror=..." to build-test
> their project.
> 
> 

Before I dive into the rest of this thread: yes, this is one of
my main thoughts on the matter. Autoconf has a huge network
effect problem and letting the existing fixes start to propagate
would be most helpful.

Like it or not (and I don't like it), various software tries
to jam in -Werror (and sometimes -pedantic-errors, see rsync!) to their
configure scripts which means even prototype issues end up
causing problems.

Note that in autoconf git, we've also got 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
which is going to affect time_t efforts too, but that's
for another thread on libc-alpha at some point
when I want to bring up some issues.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 11 Nov 2022, at 03:33, Zack Weinberg  wrote:
> 
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky  wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the latest bugfixes.
>> 
>> Before I dive into the rest of this thread: yes, this is one of
>> my main thoughts on the matter. Autoconf has a huge network
>> effect problem and letting the existing fixes start to propagate
>> would be most helpful.
> 
> It would be relatively easy for me to take a couple hours this weekend and 
> put out a 2.72 release with everything that's already in trunk and nothing 
> else.  Anyone have reasons I _shouldn't_ do that?
> [...]
> 
> I have not been following the y2038 work closely.  Is it going to affect 
> things in a good way or a bad way??

I've started a discussion on libc-alpha about this, but I think it depends on 
how you view
the migration. I've come to the conclusion it's probably good but only after 
thinking
about it a lot. I wish it'd been discussed on the mailing lists first, as it's 
not obvious
that it's okay, and I'm not sure if others will even share my view.

Let's have the conversation there as it'll be easier to track.

Thanks for prompting me to write this up finally.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 10 Nov 2022, at 17:16, Zack Weinberg  wrote:
> 
> I’m the closest thing Autoconf has to a lead maintainer at present.
> 
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable several “legacy” C language features by
> default in a near-future release (GCC 14, Clang 16) (see the Fedora
> wiki link for a list).  I understand that this change potentially
> breaks a lot of old dusty code, and in particular that
> Autoconf-generated configure scripts use constructs that may *silently
> give the wrong answer to a probe* when a stricter compiler is in use.

Thank you for asking. The fixes in git get us there, I think, as far
as you can, with the exception of the stuff you (and I) mention below.

> 
> [...]
> 
> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.
> 
> How important do you think it is for this to be fixed?
> 
> Are there any other changes you would like to see in a near-future
> Autoconf 2.72 in order to make this transition easier?

This might be a WONTFIX but let me mention it just for
the record:
1. AC_CHECK_FUNCS is, as you've noticed, very noisy.

I would support having a hardcoded list for certain CHOSTs
as Rich suggests to reduce noise, but I don't think we can
do this accurately very quickly.

I think for Gentoo's efforts, I might just build up a set
of cache variables for glibc/musl on each arch to
reduce the noise in logs. But that's time consuming
and brittle still, so I'm not sure.

(Note that Gentoo and Fedora are taking two complementary
but different approaches here:
we're diffing config.logs and other compiler
output, in addition to build logs, while Florian for Fedora
Is building a list of functions which *we know* are available
In a specific environment and patching gcc to spit out
logs when something in said list is missing. This mitigates
noise for things like functions in libbsd, which I'm finding
a bit of a pain.)

I'll see what others say.

2. I often have to set the following cache variables to
reduce noise in logs:
* ac_cv_c_undeclared_builtin_options="none needed"
* ac_cv_header_sys_types_h_makedev=no
* gl_cv_compiler_check_decl_option="-Werror=implicit-function-declaration" 
(obviously this is gnulib)
* gl_cv_minmax_in_limits_h=no

I don't know if we can do anything to make these tests smarter
or just leave it as-is. It's fine if we can't, as exporting the cache
vars is not a bad workaround for us when doing testing.

> 
> zw
> 
> p.s. GCC and Clang folks: As long as you’re changing the defaults out
> from under people, can you please also remove the last few predefined
> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
> -std=gnuXX modes?

I support this as well. This kind of thing has led to endless
bugs in userland, see https://reviews.llvm.org/D137511.



signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 11 Nov 2022, at 03:33, Zack Weinberg  wrote:
> 
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky  wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the latest bugfixes.
>> 
>> Before I dive into the rest of this thread: yes, this is one of
>> my main thoughts on the matter. Autoconf has a huge network
>> effect problem and letting the existing fixes start to propagate
>> would be most helpful.
> 
> It would be relatively easy for me to take a couple hours this weekend and 
> put out a 2.72 release with everything that's already in trunk and nothing 
> else.  Anyone have reasons I _shouldn't_ do that?
> 
>> Note that in autoconf git, we've also got
>> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
>> which is going to affect time_t efforts too
> 
> I have not been following the y2038 work closely.  Is it going to affect 
> things in a good way or a bad way??
> 

Back to the original thread: I suspect it might be a better idea to 
(temporarily) revert the two changes
and omit it from 2.72 to allow the other changes to get out.

That's not a judgement on whether the changes will ultimately remain in 
autoconf, I'm just
hesitant to allow a discussion I've kicked off to derail something that we were 
planning
on doing anyway.

What do you think?


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 12 Nov 2022, at 03:40, Zack Weinberg  wrote:
> 
> Florian Weimer  writes:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more.  This
>> means that as an autoconf maintainer, you unfortunately won't be able to
>> help us much.
> 
> I’m sadly not surprised.
> 
> This is definitely more work than I can see myself doing on a volunteer
> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
> cherry pick the changes needed to support the newer compilers (and
> also newer Perl and Bash and M4) is a thing that could happen.

I didn't want to ask you to do this because I felt fortunate enough
you were volunteering to handle 2.72, but this would indeed be a help,
because then I won't have to try persuade people they should totally upgrade,
and it should happen naturally enough with distro upgrades.

If you are willing, that would be welcome.

Of course, we'll have to go lobby them, but that is what it is :)



signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 12 Nov 2022, at 00:53, Paul Eggert  wrote:
> 
> On 2022-11-11 15:25, Sam James wrote:
>> That's not a judgement on whether the changes will ultimately remain in 
>> autoconf, I'm just
>> hesitant to allow a discussion I've kicked off to derail something that we 
>> were planning
>> on doing anyway.
>> What do you think?
> 
> I'm hesitant to do that partly because the changes to _TIME_BITS are already 
> released in multiple packages and need to be dealt with, regardless of 
> whether they're backed out of Autoconf. This is because they've been in 
> Gnulib since July and several packages based on these Gnulib changes have 
> been released since then. Current Gnulib assumes these changes will appear in 
> the next Autoconf release; if that's not true, we'll need to upgrade Gnulib 
> and in the meantime the other packages released since July would still have 
> the changes whatever we do with Gnulib and/or Autoconf.
> 
> Since distros need to deal with the issue anyway, regardless of what Autoconf 
> and/or Gnulib does, I don't see why backing the changes out of Autoconf will 
> help all that much.
> 
> It should pretty easy for a distro to say "hold on, I don't want 64-bit 
> time_t yet" without changing either Autoconf or Gnulib so if you want to go 
> that route please feel free to do so.

The fact it's already shipped in gnulib & that the "real problem" is in glibc 
IMO means that I don't feel
strongly about reverting it.

You're right that distros have the toggle so as long as we mention this 
prominently enough in NEWS,
I don't have a strong objection to master being released as-is.


signature.asc
Description: Message signed with OpenPGP

Re: C89isms in the test suite

[Sam James via Gcc]

> On 21 Oct 2022, at 09:40, Florian Weimer via Gcc  wrote:
> 
> What should we do about these when they are not relevant to what's being
> tested?  For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
> has this:
> 
>  int main ()
>  {
>if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) != -1.0)
>  abort ();
>exit (0);
>  }
> 
> but no include files, so abort and exit are implicitly declared.
> 
> Should we inject a header with -include with the most common
> declarations (which includes at least abort and exit)?  Or add the
> missing #include directives?  But the latter might not work for
> freestanding targets.
> 
> Implicit ints and function declarations without prototypes are also
> common (not just for main).
> 
> Other tests look like they might be intended to be built in C89 mode,
> e.g.  gcc/testsuite/gcc.c-torture/compile/386.c, although it's not
> immediately obvious to me what they test.

Would you be able to backport 6be2672e4ee41c566a9e072088a263bab5f7
and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
branches?

Thanks,
sam


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
> 
> On 2022-11-11 07:11, Aaron Ballman wrote:
>> We believe the runtime behavior is sufficiently dangerous to
>> warrant a conservative view that any call to a function will be a call
>> that gets executed at runtime, hence a definitive signature mismatch
>> is something we feel comfortable diagnosing (in some form) by default.
> 
> As long as these diagnostics by default do not cause the compiler to exit 
> with nonzero status, we should be OK with Autoconf-generated 'configure' 
> scripts. Although there will be problems with people who run "./configure 
> CFLAGS='-Werror'", that sort of usage has always been problematic and 
> unsupported by Autoconf, so we can simply continue to tell people "don't do 
> that".
> 

Is there somewhere in the autoconf docs we actually say this?

I've seen a few instances of folks adding it themselves very
early in their configure scripts (which is a pain for distros
anyway) which then ends up affecting the rest.


signature.asc
Description: Message signed with OpenPGP

Re: C89isms in the test suite

[Sam James via Gcc]

> On 14 Nov 2022, at 08:19, Florian Weimer  wrote:
> 
> * Sam James:
> 
>> Would you be able to backport 6be2672e4ee41c566a9e072088a263bab5f7
>> and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
>> branches?
> 
> Jakub, okay to backport these two (to 12, 11, 10 I presume)?

(Yes please. It's also given me something to poke at as I didn't log
the failure and only noticed when libasan wasn't installed...)

Thanks.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 15 Nov 2022, at 13:30, Zack Weinberg  wrote:
> 
> On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>>> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
>>> 
>>> Although there will be problems with people who run "./configure 
>>> CFLAGS='-Werror'", that sort of usage has always been problematic and 
>>> unsupported by Autoconf, so we can simply continue to tell people "don't do 
>>> that".
>>> 
>> 
>> Is there somewhere in the autoconf docs we actually say this?
>> 
>> I've seen a few instances of folks adding it themselves very
>> early in their configure scripts (which is a pain for distros
>> anyway) which then ends up affecting the rest.
> 
> It's mentioned in the NEWS entry for 2.70: 
> https://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS#n170

Thanks, sorry, I didn't think to check NEWS. This is good enough for me to link 
folks to, anyway, for the time being.

> Note that there have been bug reports for cases where running builds with 
> more warnings than configure uses (and I think also -Werror), means that 
> configure checks spuriously succeed (i.e. configure reports that something is 
> available, but then you get compiler errors on the code that tries to use 
> it).  I can't remember any concrete examples right now, though.

I can totally imagine that, don't stress about the examples.



signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 16 Nov 2022, at 15:27, Richard Biener  wrote:
> 
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc  wrote:
>> 
>> Hey,
>> 
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>> 
 The idea is so obvious that I'm probably missing something, why autoconf
 can't use that idiom instead.  But perhaps the (historic?) reasons why it
 couldn't be used are gone now?
>>> 
>>> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
>>> and thus no symbol reference remains in the resulting assembly.
>> 
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>> 
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>ptr = foobar;
>>return ptr != 0;
>> }
> 
> using printf for foobar this works even with GCC 2.95.2 and with trunk
> and -Wall diagnoses
> 
> t.c:1:6: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
>1 | char printf(void);
>  |  ^~
> t.c:1:1: note: 'printf' is declared in header ''
>  +++ |+#include 
>1 | char printf(void);
> 
> so without -Werror this should be fine.
> 
Unrelated but I was a bit tempted to ask for throwing in 
-Wbuiltin-declaration-mismatch
to default -Werror while Clang 16 was at it, but I suppose we don't want the 
world to
burn too much, and it's got a very obvious usecase (this one) whereas implicit
func decls are too hard to justify.

> Richard.


signature.asc
Description: Message signed with OpenPGP

Re: avx512erintrin.h: uninitialized variable warning (optimized build)

[Sam James via Gcc]

> On 12 Jan 2023, at 00:26, James Addison via Gcc  wrote:
> 
> Hi,
> 
> During GCC 12.2.0 compilation of a file that includes[1] immintrin.h
> with both code-optimization and uninitialized-variable-warnings
> enabled, a warning is emitted:
> 
>/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:55:20:
> warning: ‘__W’ is used uninitialized [-Wuninitialized]
> 
> The minimal repro compilation command appears to be:
> 
>gcc -O -Wuninitialized -mavx512er -mavx512pf
> ./numpy/distutils/checks/cpu_avx512_knl.c
> 
> My question is: does the warning indicate a possible bug that should
> be reported, or is there a reason that the relevant code[2] does not
> initialize the variable (for example, for performance reasons)?

See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593, might
be the same thing?


signature.asc
Description: Message signed with OpenPGP

Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

[Sam James via Gcc]

> On 29 Jan 2023, at 19:36, Jerry D via Gcc  wrote:
> 
> I had this show up today. I have no idea what this is about.
> 
> Please advise.
> 

Sorry Jerry, false positive -- something went wrong with the builder. Disregard.

We're still setting things up there.


> Jerry

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

[Sam James via Gcc]

> On 30 Jan 2023, at 06:27, Steve Kargl via Gcc  wrote:

Hi Steve,

> Please remove the skull and cross bones in the subject line.

This is a sourceware project so I've CC'd the buildbot mailing list where we 
discuss
these matters.

Does the emoji bother you, or is it the skull and crossbones specifically 
(which is
a recognised symbol for a hazard)?

Note that this is the default upstream from the Buildbot project (we use their
software) too. We haven't chosen it ourselves.

Thanks,
sam


signature.asc
Description: Message signed with OpenPGP

Re: Missed warning (-Wuse-after-free)

[Sam James via Gcc]

> On 17 Feb 2023, at 01:05, Alejandro Colomar via Gcc  wrote:
> 
> On 2/17/23 02:04, Alejandro Colomar wrote:
>> [CC: Added those who contributed to the discussion in linux-man@,
>> and also the authors of N2861 for C2x]
> 
> [...]
> 
>> 
>> There was a discussion in linux-man@ some years ago, which now I realize it
>> didn't end up being applied (I thought we had applied a patch, but it seems 
>> we
>> didn't).  I'll check if we still need such a patch (and I guess we do, since
>> we're having this conversation).
> 
> I forgot to link:
> 
> 

See also 
https://siddhesh.in/posts/that-is-not-a-number-that-is-a-freed-object.html.


signature.asc
Description: Message signed with OpenPGP

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Sam James via Gcc]

Palmer Dabbelt  writes:

> Based on some discussions, it looks like a handful of vendors are
> planning on maintaining GCC-13 branches that include various
> performance-related backports (ie, patches not suitable for the
> standard GCC-13 release branch).
>
> I don't think we'd actually agreed to a set of branch rules, but it
> seems like the following were where the discussion ended up:
>
> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>   but "riscv/gcc-13-perf" seems fine to me.
> * Regularly rebase the branch on the GCC-13 release branch.
> * Only accept backports that have landed on trunk.

I'm a bit concerned about how distributions are supposed to handle this.

I can see riscv enthusiasts asking us to package the vendor branch -
which presumably won't get automatic snapshots created, so that's a bit
more manual work already. But supposing we switched to it entirely for
riscv, that might be ok. But what if there's also users who want the
conservative setup?

This feels (not to be a downer, sorry!) like a mess in the making
from the distribution perspective.

I've got to ask: given riscv isn't yet (as far as I understand), a
"premier platform" in GCC terms, couldn't you just be more liberal
with backports for riscv at least up until 13.2, or similar?

This is also a lot of work for a platform I don't even have access to
(we have Gentoo developers with riscv hardware, but not sure any of
it is powerful enough to be regularly testing this in addition to
the regular branch for riscv). If even a handful of other arches started
doing this, I would be completely overwhelmed with work.

Would this also be a long-term thing or just for 13?

>
> There's a few others that I'd like to add, just based on poking around:
>
> * No new regressions for anything that's backported.
> * Use "git cherry-pick -x" from the trunk commit.
>
> We're starting to land some gcc-14 patches already, so I'd prefer to
> make the branch sooner rather than later.  Unless there's any
> objections, I'll push what's at
> github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.

thanks,
sam


signature.asc
Description: PGP signature

Re: GCC 13 release date

[Sam James via Gcc]

"Vaish, Mayank via Gcc"  writes:

> [AMD Official Use Only - General]
>
> Hi,
>
> Looking out for GCC 13 release date. GCC Development 
> plan only mention about GCC 13 
> Stage 4 development.
>
> Please comment on the formal GCC 13 release date.

I'm just an observer, but RC1 is likely to be today and if nothing goes
badly, GCC 13 will follow a week after that.

This was covered on this mailing list in the last status report a few
days ago: https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html.

>
> Thanks.
> Mayank

thanks,
sam


signature.asc
Description: PGP signature

Re: GCC 13 release date

[Sam James via Gcc]

"Vaish, Mayank"  writes:

> [AMD Official Use Only - General]
>

Hi Mayank,

> Thanks Sam for your prompt response. 
>
> The status message https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html. 
> mentions GCC 13.0.1 report. Is there any stable GCC 13.0.0 tag/branch 
> available for general use. 

It means that GCC 13.1 will be tagged in a week from the
releases/gcc-13 branch. No GCC 13.0 release will exist.

(It's a 13.0.1 status report because releases/gcc-13 is 13.0.1 (for development)
until it officially becomes 13.1 and is released. 13.0.x would never be 
released.)

I hope that helps.

TL;DR: GCC 13 is coming out in a week, if everything goes OK. And it
will be called '13.1' officially.

>
> Regards, 
> Mayank
>
> -Original Message-
> From: Sam James  
> Sent: Wednesday, April 19, 2023 11:02 AM
> To: Vaish, Mayank 
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC 13 release date
>
>
> "Vaish, Mayank via Gcc"  writes:
>
>> [AMD Official Use Only - General]
>>
>> Hi,
>>
>> Looking out for GCC 13 release date. GCC Development 
>> plan only mention about GCC 13 
>> Stage 4 development.
>>
>> Please comment on the formal GCC 13 release date.
>
> I'm just an observer, but RC1 is likely to be today and if nothing goes 
> badly, GCC 13 will follow a week after that.
>
> This was covered on this mailing list in the last status report a few days 
> ago: https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html.
>
>>
>> Thanks.
>> Mayank
>
> thanks,
> sam



signature.asc
Description: PGP signature

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Sam James via Gcc]

Palmer Dabbelt  writes:

> We talked about this a bit on IRC, but just to reflect it to the
> mailing lists:
>
> On Tue, 18 Apr 2023 05:34:11 PDT (-0700), s...@gentoo.org wrote:
>>
>> Palmer Dabbelt  writes:
>>
>>> Based on some discussions, it looks like a handful of vendors are
>>> planning on maintaining GCC-13 branches that include various
>>> performance-related backports (ie, patches not suitable for the
>>> standard GCC-13 release branch).
>>>
>>> I don't think we'd actually agreed to a set of branch rules, but it
>>> seems like the following were where the discussion ended up:
>>>
>>> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>>>   but "riscv/gcc-13-perf" seems fine to me.
>>> * Regularly rebase the branch on the GCC-13 release branch.
>>> * Only accept backports that have landed on trunk.
>>
>> I'm a bit concerned about how distributions are supposed to handle this.
>>
>> I can see riscv enthusiasts asking us to package the vendor branch -
>> which presumably won't get automatic snapshots created, so that's a bit
>> more manual work already. But supposing we switched to it entirely for
>> riscv, that might be ok. But what if there's also users who want the
>> conservative setup?
>>
>> This feels (not to be a downer, sorry!) like a mess in the making
>> from the distribution perspective.
>
> No problem, that's why we have these sorts of threads.
>
>> I've got to ask: given riscv isn't yet (as far as I understand), a
>> "premier platform" in GCC terms, couldn't you just be more liberal
>> with backports for riscv at least up until 13.2, or similar?
>
> We've been pretty liberal about backports, but there's always some
> stuff that's just too much to for the standard branch.  It's looking
> like 14 is shaping up to be a big one because of all the vector work
> going on, a lot of which is likely to touch core GCC code.
>

Fair point.

>> This is also a lot of work for a platform I don't even have access to
>> (we have Gentoo developers with riscv hardware, but not sure any of
>> it is powerful enough to be regularly testing this in addition to
>> the regular branch for riscv). If even a handful of other arches started
>> doing this, I would be completely overwhelmed with work.
>>
>> Would this also be a long-term thing or just for 13?
>
> We've essentailly done this for every release, it's just been at the
> RISC-V github.  Ideally we'll stop needing to be special, but given
> the history that might take a while.  The difference here is that
> we're trying to keep this at sourceware intsead of the RISC-V github,
> but that's really just because we've had so many headaches with RVI.
>
> As to whether or not distros ship it: I've always been against distros
> shipping the RISC-V branches, as they're full of stuff that's not
> suitable for normal GCC releases and those policies are in place for a
> reason.  I know there's some vendors who ship them, but that's mostly
> in the embedded space and folks tend to have out of tree patches
> anyway so no big deal.
>
> I treat these as more of a performance preview of the next GCC
> release, a handful of vendors were maintaining those internally.  I'd
> love if we could just use trunk for that, but it's generally not
> viable because too much stuff fails to build.

Thanks Palmer, I didn't realise this context - having this to refer to
is enough for me, because if nothing else, if someone asks me about it,
I can cite this :)

That makes sense to me & thank you for explaining!

>
>>> There's a few others that I'd like to add, just based on poking around:
>>>
>>> * No new regressions for anything that's backported.
>>> * Use "git cherry-pick -x" from the trunk commit.
>>>
>>> We're starting to land some gcc-14 patches already, so I'd prefer to
>>> make the branch sooner rather than later.  Unless there's any
>>> objections, I'll push what's at
>>> github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.
>>
>> thanks,
>> sam

best,
sam


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

David Edelsohn via Gcc  writes:

> On Tue, May 9, 2023 at 8:16 AM Florian Weimer via Gcc 
> wrote:
>
>> TL;DR: This message is about turning implicit-int,
>> implicit-function-declaration, and possibly int-conversion into errors
>> for GCC 14.
>>
>> A few of you might remember that I've been looking into turning some
>> type errors from warnings into errors by default.  Mainly I've been
>> looking at implicit function declarations because in too many cases, the
>> synthesized declaration does not match the prototype used at function
>> definition and can cause subtle ABI issues.
>>
>> To recap, the main challenge is that GCC has to serve disparate groups
>> of users: some use GCC for writing programs themselves, but others just
>> need GCC to build sources that they have obtained from somewhere.  The
>> first group benefits from more type errors because they catch errors
>> earlier during development (experience shows that compiler warnings are
>> easy to miss in a long build log).  The second group might find these
>> errors challenging because the sources they have no longer build.
>>
>
> Hi, Florian
>
> Thanks for working on this and proposing this.
>
> Yes, GCC has two, distinct user groups / use cases, but GCC also has a very
> unique and crucial role, as the foundation for a large portion of the
> GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.

Florian did note this already - ABI. Implicit function declarations are
pretty horrible in a number of cases:
- they prevent fortification (_FORTIFY_SOURCE)
- they prevent time64 and LFS migrations from working correctly
- they break with different ABIs (see e.g. Apple's arm64 ABI)
- they can cause runtime crashes when combined wtih bfd's default of
not warning on underlinking

int-conversion generally indicates severe runtime problems as well. Many
of the cases I've seen on musl absolutely do not work at runtime and
weren't caught by any other warnings (often because of padding mismatches).

>
> GCC needs to be proactive, not reactive, without annoying and frustrating
> its user base.

That's why Fedora and Gentoo have been aggressively working on this
before even proposing it. We are being proactive in making sure that
common things are fixed.

> Clang has been making some aggressive changes in warnings,
> but its constituency expects that.  Developers who want that experience
> already will use Clang, so why annoy developers who prefer the GCC
> experience and behavior?  The new warnings and errors help some developers
> and improve software security, but also drive some developers away, or at
> least cause them to reass their choice of toolchain.

I don't know if it's that aggressive to drop something which was
removed in C99 because of how dangerous it is.

Also, keep in mind, Florian went around and asked many of the first
group (the foundational folks) who didn't object.

Not that this is a strong argument, and I don't like making it, but
if Clang is doing it and GCC does too, it's not like they can reassess
their choices anyway.

>
> Maybe we need additional front-end aliases "gcclang" and "gcclang++" for
> GCC to provide an experience more like Clang for those who desire that.
> GCC isn't Clang and I fear that GCC is going down a path that annoys and
> frustrates both user groups -- it's not sufficiently aggressive for those
> who prefer Clang and it's too aggressive for those who wish backward
> compatibility.

Sounds similar (although a bit different) to the
https://gcc.gnu.org/wiki/boringcc idea.

thanks,
sam


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Jakub Jelinek  writes:

> On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
>> 
>> 
>> > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>> > 
>> > TL;DR: This message is about turning implicit-int,
>> > implicit-function-declaration, and possibly int-conversion into errors
>> > for GCC 14.
>> 
>> I suppose the goal is to not need to rely on altering CFLAGS but change the 
>> default behavior with still being able to undo this using -Wno-error= or 
>> -Wno-?
>
> Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
> these errors that way?

This is what we've been doing for hopeless projects and it's probably my
preference, but I'm fine with Florian's -fpermissive suggestion too.

(The point about inline semantics is important but you can handle that
with other flags anyway.)

best,
sam



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Zaretskii via Gcc  writes:

>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Tue, 09 May 2023 18:38:05 +0200
>> From: Arsen Arsenović via Gcc 
>> 
>> You're actively dismissing the benefit.
>
> Which benefit?
>
> No one has yet explained why a warning about this is not enough, and
> why it must be made an error.  Florian's initial post doesn't explain
> that, and none of the followups did, although questions about whether
> a warning is not already sufficient were asked.
>
> That's a simple question, and unless answered with valid arguments,
> the proposal cannot make sense to me, at least.

My email covers this:
https://gcc.gnu.org/pipermail/gcc/2023-May/241269.html.

I'd also note that some of the issues I've seen were already flagged
in people's CI but they didn't notice because it was just a warning.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> * Richard Biener:
>
>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>>> 
>>> TL;DR: This message is about turning implicit-int,
>>> implicit-function-declaration, and possibly int-conversion into errors
>>> for GCC 14.
>>
>> I suppose the goal is to not need to rely on altering CFLAGS but
>> change the default behavior with still being able to undo this using
>> -Wno-error= or -Wno-?
>
> That's what Clang does (and the defaults chang along with -std=
> settings). To me, -Werror by default for some warnings seems rather
> hackish.  But that's just my personal preference, I do not have a strong
> objection to doing it that way.

Not that we have to follow Clang, but deviating by adding -fpermissive
(which is a GCC-only flag) for C may not be desirable, and following
Clang would let people use the same method for silencing known-bad
codebases for now.

>
> One downside with -Wno- is that some developers jump on this rather
> quickly instead of fixing the real problem.  So far, I've seen this in
> both Chromium and the kernel, in fringe areas admittedly, but still.
> The advantage is that there is a familiar workaround to get things
> compiling quickly again, of course.
>

I've not seen very much of this so far, FWIW. Only for the more annoying
C23 warnings which have well-documented problems (and unrelated to this,
so I won't go on about it anymore).

But -fpermissive does have a nice property in that it's immediately
obvious you're doing something *terrible* if you use it.

>> I think instead of hard-coding a set of changes would it be possible
>> to alter the default setting of diagnostic options during GCC
>> configuration?  And maybe even note that when diagnosing?
>
> I'd be worried about our package maintainers if we do something like
> that.  We'd like them to report build failures upstream, and if it's
> just one or two distributions doing that and not GCC upstream, well, I
> guess we just got a preview of how some upstreams are going to react.
> Package maintainers tend to be volunteer or junior engineering roles, I
> think, so this doesn't seem fair to me.

Yeah, this is one of those things where we need it happening in CI for
people and at the point of development.

(Such an option might be nice in general, but not for this if its
default didn't include these warnings or if distributions were likely
to override it to something weaker.)

thanks,
sam



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Jason Merrill  writes:

> On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc  
> wrote:
>>
>> * Richard Biener:
>>
>> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn :
>> > >
>> > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc  
>> > > wrote:
>> > >
>> > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
>> > > >
>> > > >
>> > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc 
>> > > > > :
>> > > > >
>> > > > > TL;DR: This message is about turning implicit-int,
>> > > > > implicit-function-declaration, and possibly int-conversion into 
>> > > > > errors
>> > > > > for GCC 14.
>> > > >
>> > > > I suppose the goal is to not need to rely on altering CFLAGS but
>> > > > change the default behavior with still being able to undo this
>> > > > using -Wno-error= or -Wno-?
>> > >
>> > > Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not 
>> > > get
>> > > these errors that way?
>> > >
>> > > As Florian mentioned:
>> > >
>> > > "Presently, we
>> > > cannot use -std=gnu89 etc. to opt out because there are packages which
>> > > require both C89-only language features and C99-style inlining, which is
>> > > currently not a combination supported by GCC (but maybe that could be
>> > > changed). "
>> >
>> > But surely it would reduce the number of packages to fix?  So I
>> > support both having only C99 and up reject no longer valid code _and_
>> > having -fpermissive be forgiving (demoting errors to warnings).
>>
>> It makes sense to disable the new erros in C89 mode.  It's what I did in
>> the instrumented compiler.  It also gives you yet another way to disable
>> the errors, using CC=c89, which works for some packages that do not
>> honor CFLAGS and do not support whitespace in CC.
>>
>> The part David quoted above is about this:
>>
>> $ gcc -fno-gnu89-inline -std=gnu89 t.c
>> cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode
>>
>> And some packages need -fno-gnu89-inline, but also rely on implicit ints
>> and implicit function declarations heavily.  With a purely C89-based
>> opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
>> compile these self-contradictory programs.  Hence the idea of
>> -fpermissive, in addition to the -std=gnu89 escape hatch.
>>
>> But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
>> remaining reason for -fpermissive would be a flag that is accepted by
>> both gcc and g++, in case a package build system passes CFLAGS to g++ as
>> well, which sometimes happens.  And -fno-gnu89-inline is currently not
>> accepted by g++.  But in the Fedora package set, this (some C++ and a
>> C89 requirement) must be exceedingly rare because it's a subset of the
>> already tiny set of -fno-gnu89-inline -std=gnu89 packages.
>
> Another reason for -fpermissive is ease of use.  So if someone just
> wants to get an older package to build, they can add -fpermissive
> without having to figure out more detailed flags.
>
> Alternatively, if we go the default -Werror=various route, adding
> -Wno-error without any =foo to override everything might also be
> fairly convenient.

In addition to this, this made me realise something similar to what
Florian was saying wrt whitespace. Passing -Wno-error=... doesn't
always work with some poorly-written build scripts because they split
on '=' (this happens with some CMake when poorly written).


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eric Gallager via Gcc  writes:

> On 5/9/23, Jonathan Wakely via Gcc  wrote:
>> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>>> We are currently using gcc 12 and specifying C11.  To experiment with
>>> these stricter warnings and slowly address them, would we need to build
>>> with a newer C version?
>>
>> No, the proposed changes are to give errors (instead of warnings) for
>> rules introduced in C99. GCC is just two decades late in enforcing the
>> C99 rules properly!
>>
>>
>>> What practices might the GCC community recommend to a project
>>> wanting to discover the issues uncovered and slowly address them? I
>>
>> -Werror=implicit-int
>> -Werror=implicit-function-declaration
>> -Werror=int-conversion
>>
>
> Idea for a compromise: What if, instead of flipping the switch on all
> 3 of these at once, we staggered them so that each one becomes a
> default in a separate release? i.e., something like:
>
> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> - GCC 15: -Werror=implicit-int gets added to the defaults
> - GCC 16: -Werror=int-conversion gets added to the defaults
>
> That would give people more time to catch up on a particular warning,
> rather than overwhelming them with a whole bunch all at once. Just an
> idea.

I think this might be more frustrating than not, althuogh I appreciate
the intent.

Neal Gompa wasn't keen on the idea at
https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=od5dh+h9aqzge_4ghzgx_ow4ryjvpw...@mail.gmail.com/
because it'd feel like essentially "repeated punches".

Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 
having
implicit-function-declaration,implicit-int (these are so closely related
that it's not worth dividing the two up) and then say, GCC 15 having 
int-conversion and maybe
incompatible-pointer-types. But spreading it out too much is likely 
counterproductive.


signature.asc
Description: PGP signature

Re: Tags not allowed in user repository - Mildly urgent

[Sam James via Gcc]

Ondřej Kubánek via Gcc  writes:

> Hello,
>
> I have tried to push a tag to my user space /tags/ ref in the GCC repo. The
> tag is annotated but the push was rejected. Here is the command
>
> git push origin master:refs/users/kubaneko/tags/Thesis Thesis
>
> and here is the response
>
> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
> remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace
> 'refs/users') are not allowed in this repository.
> remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate.
> remote: error: hook declined to update refs/users/kubaneko/tags/Thesis
> To git+ssh://gcc.gnu.org/git/gcc.git
>  ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
> (hook declined)
> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'
>
> Is this expected behaviour? Do I need a gpg key to sign the tag?

Note that you probably want to use a 'namespaced' tag (i.e. something
with a prefix). The version you pushed is simply called 'Thesis' which
is likely to be confusing to people.



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Zaretskii via Gcc  writes:

>> Date: Wed, 10 May 2023 10:49:32 +0200
>> From: David Brown via Gcc 
>> 
>> > People who ignore warnings will use options that disable these new
>> > errors, exactly as they disable warnings.  So we will end up not
>> > reaching the goal, but instead harming those who are well aware of the
>> > warnings.
>> 
>> My experience is that many of the people who ignore warnings are not 
>> particularly good developers, and not particularly good at 
>> self-improvement.  They know how to ignore warnings - the attitude is 
>> "if it really was a problem, the compiler would have given an error 
>> message, not a mere warning".  They don't know how to disable error 
>> messages, and won't bother to find out.  So they will, in fact, be a lot 
>> more likely to fix their code.
>
> If some developers want to ignore warnings, it is not the business of
> GCC to improve them, even if you are right in assuming that they will
> not work around errors like they work around warnings (and I'm not at
> all sure you are right in that assumption).  But by _forcing_ these
> errors on _everyone_, GCC will in effect punish those developers who
> have good reasons for not changing the code.
>
>> > IOW, if we are targeting people for whom warnings are not enough, then
>> > we have already lost the battle.  Discipline cannot be forced by
>> > technological means, because people will always work around.
>> > 
>> 
>> Agreed.  But if we can make it harder for them to release bad code, 
>> that's good overall.
>
> I'm okay with making it harder, but without making it too hard for
> those whose reasons for not changing the code are perfectly valid.
> This proposal crosses that line, IMNSHO.

Could you give an example of how to make it harder without crossing
the line for you?


signature.asc
Description: PGP signature

Re: Tags not allowed in user repository - Mildly urgent

[Sam James via Gcc]

Andreas Schwab  writes:

> On Mai 10 2023, Sam James via Gcc wrote:
>
>> Ondřej Kubánek via Gcc  writes:
>>
>>> Hello,
>>>
>>> I have tried to push a tag to my user space /tags/ ref in the GCC repo. The
>>> tag is annotated but the push was rejected. Here is the command
>>>
>>> git push origin master:refs/users/kubaneko/tags/Thesis Thesis
>>>
>>> and here is the response
>>>
>>> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
>>> remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace
>>> 'refs/users') are not allowed in this repository.
>>> remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate.
>>> remote: error: hook declined to update refs/users/kubaneko/tags/Thesis
>>> To git+ssh://gcc.gnu.org/git/gcc.git
>>>  ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
>>> (hook declined)
>>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'
>>>
>>> Is this expected behaviour? Do I need a gpg key to sign the tag?
>>
>> Note that you probably want to use a 'namespaced' tag (i.e. something
>> with a prefix). The version you pushed is simply called 'Thesis' which
>> is likely to be confusing to people.
>
> It already uses a prefix (users/kubaneko) which is not fetched by
> default.

Ah, thanks, the UI in the tags section at 
https://gcc.gnu.org/git/?p=gcc.git;a=summary
confused me. But it's likely to confuse others as well.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Zaretskii via Gcc  writes:

>> From: Eric Gallager 
>> Date: Wed, 10 May 2023 06:40:54 -0400
>> Cc: j...@rtems.org, David Edelsohn , Eli Zaretskii 
>> , 
>>  Jakub Jelinek , Arsen Arsenović , 
>>  "gcc@gcc.gnu.org" 
>> 
>> Idea for a compromise: What if, instead of flipping the switch on all
>> 3 of these at once, we staggered them so that each one becomes a
>> default in a separate release? i.e., something like:
>> 
>> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
>> - GCC 15: -Werror=implicit-int gets added to the defaults
>> - GCC 16: -Werror=int-conversion gets added to the defaults
>> 
>> That would give people more time to catch up on a particular warning,
>> rather than overwhelming them with a whole bunch all at once. Just an
>> idea.
>
> What do we tell those who cannot possibly "catch up", for whatever
> valid reasons?  E.g., consider a program written many years ago, which
> is safety-critical, and where making any changes requires so many
> validations and verifications that it is simply impractical, and will
> never be done.  Why would we want to break such programs?

Upgrading the toolchain is a change which requires validation, surely.

They can then test it at the same time as porting to modern C. Or simply
set the required options (as we're discussing) to allow older,
to-be-rejected constructs.

(It's also not clear to me that they're entitled to a GCC which always
works for them forever. People who like the behaviour of older GCCs
and refuse to change anything about their environment (not necessarily
their code) are able to stick with old versions if they wish.)


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

"James K. Lowden"  writes:

> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc  wrote:
>
>> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>> > We are currently using gcc 12 and specifying C11.  To experiment
>> > with these stricter warnings and slowly address them, would we need
>> > to build with a newer C version?
>> 
>> No, the proposed changes are to give errors (instead of warnings) for
>> rules introduced in C99. GCC is just two decades late in enforcing the
>> C99 rules properly!
>
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.  Code that can be
> compiled correctly, per the specification, but might not be what the
> user intended, is a candidate for a warning.  
>
> If the proposed changes catch true errors -- not just dubious
> constructs -- that were previously allowed, well, that's the price of
> progress.  That's the compiler getting better at distinguishing between
> code conformant and not.  
>
> Section 2.1 "C Language" of the manual states that, with no option
> specified on the command line, the default standard is -std=gnu17.  
>
> Part of the proposal IIUC is to treat undeclared functions as an error.
> Function prototypes have been required afaik since c99.  If
> that's correct, then letting them pass without error is a mistake for
> -std=c99 and above.  
>
> As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
> GNU extensions -- includes ignoring missing function prototypes?  That
> to me would be an odd definition of "extension".  
>
> The user who has old code that does not meet the c99 standard but Just
> Works nonetheless has a direct route to compiling that code without
> complaint: -std=c90.  It says so right there in the fine manual.  
>
> It's that simple.  The code is either in spec and compiles without
> error, or it is not and does not.  The only debate is over what "the
> spec" is, and what warnings the user might want for conforming code.  

jwakely's already dispatched with these claims, but I'd note that
if this were the case, we'd all be arguing about whether Clang
is currently conformant.

(There is a fair point in all of this about how much we want to
consider some of these constructs extensions. I'm relieved to see
that e.g. implicit func. decls weren't ever considered "real"
GNU extensions, rather something which was added for compat. for
a while, rather than something deliberately and explicitly
supported as a GNU extension forever, even just for certain Cs.)



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.
>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?
>
>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The code is conforming, it simply relies on extensions to the Standard.
> Implicit int does not break any strictly conforming program, so a C
> implementation implemented it continues to be conforming, along with
> those programs relying on implicit int.  See this wording in the
> Standard:
>
>   A conforming implementation may have extensions (including additional
>   library functions), provided they do not alter the behavior of any
>   strictly conforming program.
>
> You are not trying to reject non-conforming C code.  You are, for better
> or worse, trying to impose your personal preferences on users of GCC.
>
> Let's debate the real problem at hand instead of using the Standard as a
> boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
> good idea.

Much of the thread (including the original post) does discuss that and
it's not limited to implicit-int.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.

No, we're talking about "things which ISO C made invalid in 1999, but
GCC kept supporting for a while". We're discussing terminating that
support. The "standard" part here is not about deference to the standard
and claiming extensions can never be made, but rather that we're keeping
something which was explicitly removed.

>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?

These aren't things which were in the standard and then got removed
because of how terrible they are. They're things that are considered
a part of GNU C as proper GNU extensions.

Note that, per the rest of the thread, the constructs we're discussing
here to be banned are not considered "proper GNU extensions".




signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> dje@gmail.com (David Edelsohn) writes:
>
>> This seems to be the core tension.  If developers cared about these issues,
>> they would enable appropriate warnings and -Werror.
>>
>> The code using these idioms is not safe and does create security
>> vulnerabilities.  And software security is increasingly important.
>
> Oh please.  By this definition, every bug is a security issue.
> What bugs have been caused by implicit int?
>
>> The concern is using the good will of the GNU Toolchain brand as the tip of
>> the spear or battering ram to motivate software packages to fix their
>> problems. It's using GCC as leverage in a manner that is difficult for
>> package maintainers to avoid.  Maybe that's a necessary approach, but we
>> should be clear about the reasoning.  Again, I'm not objecting, but let's
>> clarify why we are choosing this approach.
>
> You will simply make life annoying for people who already have working
> code.  People do not like it when others do that!
>
> If you make it too annoying to turn off the new diagnostics, you will
> not convince people who have not stopped writing traditional C code to
> stop doing so.
>
> Instead, they will use an older version of GCC, or license a proprietary
> compiler which allows them to keep writing use language as they always
> did.  My organization eventually chose the latter when GCC removed
> `-traditional', and to this day we continue to write code which relies
> on float arithmetic being promoted to double, unsigned narrow types
> being promoted to unsigned int, and string constants being writable.

Nobody here is suggesting that the ability to compile this code at
all would be removed. Throughout this thread, people discuss methods
like e.g. adding -fpermissive to allow it.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> So let's do it. Let's write a statement saying that the GCC developers
>> consider software security to be of increasing importance, and that we
>> consider it irresponsible to default to accepting invalid constructs in the
>> name of backwards compatibility. State that we will make some changes which
>> were a break from GCC's traditional stance, for the good of the ecosystem.
>
> I'm sorry you think that way.
>
>> Given recent pushes to discourage or outright ban the use of memory-safe
>> languages in some domains, I think it would be good to make a strong
>> statement about taking the topic seriously. And not just make a statement,
>> but take action too.
>>
>> If we don't do this, I believe it will harm GCC in the long run. The vocal
>> minority who want to preserve the C they're used to, like some kind of
>> historical reenactment society, would get their wish: it would become a
>> historical dead end and go nowhere.
>
> Vocal minority? Do you have any evidence to back this claim?
>
> What I see is that some reasonable organizations have already chosen
> other C compilers which are capable of supporting their existing large
> bodies of C code that have seen significant investment over many years,
> while others have chosen to revise their C code with each major change
> to the language.
>
> The organizations which did not wish to change their code did not
> vocally demand changes to GCC after GCC became unsuitable, but quietly
> arranged to license other compilers.
>
> Those that continue write traditional C code know what they are doing,
> and the limitations of traditional C do not affect the quality of their
> code.  For example, on the Unix systems at my organization, the SGS is
> modified so that it will not link functions called through a declaration
> with no parameter specification with a different set of parameters than
> it was defined with.

I think the group of people dedicated enough to patch their linker would
be able to pass a flag to the compiler to allow old constructs.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Schwartz via Gcc  writes:

> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>>> Date: Wed, 10 May 2023 23:14:20 -0400
>>> From: Eli Schwartz via Gcc 
>>>
>>> Second of all, why is this GCC's problem? You are not a user of GCC,
>>> apparently.
>> 
>> He is telling you that removing support for these old features, you
>> draw users away from GCC and towards proprietary compilers.
>> 
>> One of the arguments in this thread _for_ dropping that support was
>> that by not rejecting those old programs, GCC draws some users away
>> from GCC.  He is telling you that this change will, perhaps, draw some
>> people to GCC, but will draw others away from GCC.  The difference is
>> that the former group will start using Clang, which is still free
>> software (at least some of its versions), whereas the latter group has
>> nowhere to go but to proprietary compilers.  So the FOSS community
>> will have suffered a net loss.  Something to consider, I think.
>
>
> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>

And I would not want to see that happen either, nor do I think Florian
would, or many of the other participants in this thread.

Indeed, for some projects, where it's hopeless^Wlots of work,
we're using -std=c89 or -std=gnu89 as appropriate - as already stated.

But most things are easy to fix.

Our interest is purely in making the default stricter for better UX,
reducing the net amount of these bugs in the wild, and avoiding
regressions when we fix these problems. Trying to remove C89 entirely
would, if nothing else, be needlessly antagonistic, but some of the
replies seem to act as if we have.



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu  writes:

> Sam James  writes:
>
>> And I would not want to see that happen either, nor do I think Florian
>> would, or many of the other participants in this thread.
>>
>> Indeed, for some projects, where it's hopeless^Wlots of work,
>> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>>
>> But most things are easy to fix.
>>
>> Our interest is purely in making the default stricter for better UX,
>> reducing the net amount of these bugs in the wild, and avoiding
>> regressions when we fix these problems. Trying to remove C89 entirely
>> would, if nothing else, be needlessly antagonistic, but some of the
>> replies seem to act as if we have.
>
> But programs are not using c89 or gnu89, right? They are using gnu99 and
> gnu11.

They're using > c89/gnu89 often because defaults have changed (a point
others have raised, including Arsen and Eli Schwartz) even though they
weren't intended to be compiled with newer C.

A fair amount of other projects do explicitly ask for either c99/gnu99
or c11/gnu11 and if they're doing that, they shouldn't be getting
something which was removed from the C standard. But if they really want
it, they can either downgrade to C89 (rather drastic), or set the
proposed -fpermissive.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> Eli Schwartz  writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

I've seen 0 instances of this. All of the fixes we've made have been
proper and all the fixes I've seen when I report but don't fix an
issue have been proper.

We wouldn't have proposed this if that was the case. Maybe you should
take your case to the C committee that removed the feature in the first
place and tell them to reinstate it because of.. ^


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> Eli Schwartz  writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

In addition to Jason's point about just setting CC, I'd also expect
there to be a few centralised places where the flags are set in most
projects anyway.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> * Jason Merrill:
>
>> On Fri, May 12, 2023 at 11:03 AM Florian Weimer  wrote:
>>>
>>> * Joseph Myers:
>>>
>>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>>> >
>>> >> That is not the case we are discussing, AFAIU.  Or at least no one has
>>> >> yet explained why accepting those old K&R programs will adversely
>>> >> affect the ability of GCC to compile C2x programs.
>>> >
>>> > At block scope,
>>> >
>>> >   auto x = 1.5;
>>> >
>>> > declares x to have type double in C2x (C++-style auto), but type int in
>>> > C89 (and is invalid for versions in between).  In this case, there is an
>>> > incompatible semantic change between implicit int and C++-style auto.
>>> > Giving an error before we make -std=gnu2x the default seems like a
>>> > particularly good idea, to further alert anyone who has been ignoring the
>>> > warnings about implicit int that semantics will change incompatibly.
>>>
>>> Obviously makes sense to me.
>>
>> Agreed.  But we could safely continue to accept
>>
>>   static x = 42;
>>
>> or even
>>
>>   auto x = 42; // meaning of 'auto' changes, meaning of the declaration does 
>> not
>>
>> We might make -Wimplicit-int an error by default only if the
>> initializer has a type other than 'int'.
>
> Based on what I saw fixing Fedora, these cases are not very common.
> Sure, sometimes common program such as valgrind have an instance
> , but that's really an
> exception.
>
> Implicit int is common as the return type of main (especially in
> autoconf tests), and due to a missing declaration list entry of an
> old-style function definition.  The main case could be treated as an
> exception.  The old-style function definition case is a common source
> of bugs and therefore worth fixing.  The addition of unnamed function
> parameters as an extension actually created a new class of bugs here
> (a typo in the type name of a single unnamed parameter results in an
> old-style function definition by accident).
>
>>> > In cases where the standard requires a diagnostic, some are errors, some
>>> > are pedwarns-by-default or unconditional pedwarns, some are
>>> > pedwarns-if-pedantic - the choice depending on how suspicious the
>>> > construct in question is and whether it corresponds to a meaningful
>>> > extension (this is not making an automatic choice for every such situation
>>> > in the standard, it's a case-by-case judgement by maintainers).  By now,
>>> > the cases discussed in this thread are sufficiently suspicious -
>>> > sufficiently likely to result in unintended execution at runtime (not, of
>>> > course, reliably detected because programs with such dodgy code are very
>>> > unlikely to have thorough automated tests covering all their code) - that
>>> > is it in the interests of users for them to be errors by default (for C99
>>> > and later modes, in the cases that were valid in C89).
>>>
>>> Just to recap, those are controlled by
>>> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
>>> -Wincompatible-pointer-types, roughly in increasing order of
>>> compatibility impact with old sources.
>>
>> What would the impact be of making -Wint-conversion an error by
>> default only if the types are different sizes?
>
> From a distribution perspective, it does not change anything because
> we build everything on 64-bit anyway.  Unlike e.g. Fedora, Debian
> doesn't require all builds to succeed before the new package can be
> installed, but given that the primary targets are 64 bit, I don't
> think a restricted -Wint-conversion error would be much of a
> simplification.  The target-dependent nature of the warning is
> probably more confusing.

I don't see us really gaining anything from restricting it. Like you
said, the cases in the wild are actually all of the same "class".


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> [...]
> In summary, all these seems to be good candidates for errors by default:
>
> * int-conversion as errors (already raised separately
> * -Wint-conversion for ?:
> * parameter names in non-prototype function declarations
> * the union wait function pointer compatibility kludge
> * return-with-out-value for non-void functions
> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>
> This are more “maybe“:
>
> * incompatible-pointer-types as errors (already raised separately)
> * int-conversion and incompatible-pointer-types in comparisons
> * return with value in a function returning void

-Wreturn-type tends to bite people with C++. Obviously the behaviour
is different for C, but it's a serious code smell. I've been playing
with it for C for a while and I don't get that many hits with it of
this type.

> * dereferencing void *
> * taking the address of void

I think I've seen these but they've been accompanied by other issues.

> * "function types not truly compatible in ISO C"
>   and "types are not quite compatible" (depending on what they actually mean)
> * qualifier mismatches (may need separate opt-out)

This has been common for func. ptrs. but not too bad. I haven't
got any data on other cases but am a bit worried about how noisy it'll
be for those.

> * sign mismatches in pointers (definitely needs separate opt-out)
>


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> * Sam James:
>
>> Florian Weimer  writes:
>>
>>> [...]
>>> In summary, all these seems to be good candidates for errors by default:
>>>
>>> * int-conversion as errors (already raised separately
>>> * -Wint-conversion for ?:
>>> * parameter names in non-prototype function declarations
>>> * the union wait function pointer compatibility kludge
>>> * return-with-out-value for non-void functions
>>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>>
>>> This are more “maybe“:
>>>
>>> * incompatible-pointer-types as errors (already raised separately)
>>> * int-conversion and incompatible-pointer-types in comparisons
>>> * return with value in a function returning void
>>
>> -Wreturn-type tends to bite people with C++.
>
> Sorry, what do you mean?

Falling off the end of a function in C++ is UB and people fall
victim to it often, but in C, it's only UB if you try to use
its return value.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 is one
example of many.

What I meant was: I see this a lot in C++ and sometimes in C
but it's usually trivial to fix, even if it's less harmful
for some of the instances.

Re: Will GCC eventually support SSE2 or SSE4.1?

[Sam James via Gcc]

"Stefan Kanthak"  writes:

> "Jonathan Wakely"  wrote:
>
>> On Fri, 26 May 2023, 08:01 Andrew Pinski via Gcc,  wrote:
>>
>>> On Thu, May 25, 2023 at 11:56?PM Stefan Kanthak 
>>> wrote:

 Hi,

 compile the following function on a system with Core2 processor
 (released January 2008) for the 32-bit execution environment:

 --- demo.c ---
 int ispowerof2(unsigned long long argument)
 {
 return (argument & argument - 1) == 0;
 }
 --- EOF ---

 GCC 13.3: gcc -m32 -O3 demo.c

 NOTE: -mtune=native is the default!
>>>
>>> You need to use -march=native and not -mtune=native  to turn on
>>> the architecture features.
>
> That's what I call a REALLY EPIC FAILURE!

Please read https://gcc.gnu.org/bugs/ carefully.



signature.asc
Description: PGP signature

Re: New version of gnu assembler

[Sam James via Gcc]

jacob navia  writes:

> Hi
>
> I have developed a new version of the gnu assembler for riscv machines.
>
> Abstract:
> ———
>
> The GNU assembler (gas) is centered on flexibility and portability. These two 
> objectives have quite a cost in program readability, code size  and execution 
> time. 
>
> I have developed a « tiny » version of the GNU assembler focusing on 
> simplicity and speed.
>
> I have picked up from the several hundreds of megabytes of binutils just the 
> routines that are needed to a functional assembler, for the use case of 
> compiler generated assembler text for a single machine. That meant:

If you've taken files from Binutils BFD, please make sure you preserve
the copyright headers too.

Re: How can I run xg++ from its build location?

[Sam James via Gcc]

Michael Welsh Duggan via Gcc  writes:

> I am attempting to debug an issue in gcc (PR 110827, if curious).  In
> order to do this I have built a stage 1 compiler with debugging and
> without optimization as discussed here:
>
> https://gcc.gnu.org/wiki/DebuggingGCC#Building_a_Debuggable_Compiler
>
> I would like run the compiler from its build location without installing
> it, but I cannot determine how to have gcc look for its include files
> and libraries from within its source and build trees.  My first problem
> was that it looked for for cc1plus in the wrong location; my next
> problems involved include paths.
>

You can try something like:
./xgcc -B$(pwd) -I$(pwd) ... # (may need to add some more include
directives in)

I know someone was interested in adding a proper wrapper for this
so it Just Worked.

But for now, I'd really just...

> Is it possible to do this without extensive command-line options, or
> does this need to be installed?  If the latter, what target do I use to
> install the unoptimized stage 1 compiler?

Is there a particular reason you can't install it to a temporary prefix,
like ./configure --prefix=/opt/foo or even /tmp/foo?

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Sam James via Gcc]

Florian Weimer via Gcc  writes:

> My understanding of the consensus goes as follows:
>
> * We want to make some changes in this area for GCC 14.
> * We should do the same thing that Clang does: default to the relevant
>   -Werror= options.
> * Unlike regular warnings, these warnings-as-errors should also apply
>   to system headers.
> * At least implict-int and implicit-function-declaration should be
>   upgraded to errors in this way.
> * It's too early to make the () changes and bool-as-keyword from C2X
>   for GCC 14.
> * We should fix the missing scope of the int-conversion warnings
>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
>
> Is this summary accurate?
>

I wasn't there, but this reflects my understanding & what I would've
said if I could've attended.

> I think the open issues are:
>
> * Do we want to implement something else beside implicit-int and
>   implicit-function-declaration?  (Candidates are int-conversion and
>   incompatible-pointer-types, and the void vs non-void part of
>   return-type, maybe others as previously discussed on the list.)

Ideally, I'd like both int-conversion + incompatible-pointer-types in
this cycle, but if we have to defer one, I'd say to keep int-conversion.

A lot of the low hanging fruit is already fixed there, with the only
big remaining blocker being Vala (which is a
compiler/transpiler). They've indicated they're not that fussed
unless/until GCC changes.

Putting it another way: I don't think waiting a year or two
would actually help the situation much.

> * How do we divide up the test suite cleanup work?

Once there's some patches to work with, I'm happy to do a good
chunk (obviously).

IIRC Jakub and others indicated that the priority is to preserve
the test cases (and hence pass appropriate flags) rather than fix them
up, to avoid inadvertently testing the wrong thing.

>
> Thanks,
> Florian

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Sam James via Gcc]

Jeff Law via Gcc  writes:

> On 9/26/23 02:28, Florian Weimer via Gcc wrote:
>> My understanding of the consensus goes as follows:
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>-Werror= options.
>> * Unlike regular warnings, these warnings-as-errors should also apply
>>to system headers.
>> * At least implict-int and implicit-function-declaration should be
>>upgraded to errors in this way.
>> * It's too early to make the () changes and bool-as-keyword from C2X
>>for GCC 14.
>> * We should fix the missing scope of the int-conversion warnings
>>(PR109827).  Likweise for incompatible-pointer-types (PR109826).
>> Is this summary accurate?
> I wasn't there, so I can't attest to accuracy.  It does look like a
> reasonable plan for gcc-14 though.
>
>> I think the open issues are:
>> * Do we want to implement something else beside implicit-int and
>>implicit-function-declaration?  (Candidates are int-conversion and
>>incompatible-pointer-types, and the void vs non-void part of
>>return-type, maybe others as previously discussed on the list.)
>> * How do we divide up the test suite cleanup work?
> Not to open a can of worms, but shouldn't these be evaluated along the
> same basic criteria?  ie, what's Clang doing here, are these
> warnings-as-errors and thus apply to system headers, etc.  ANd the
> biggie, do any of these issues tend to mask correctness errors in the
> wild at a level roughly similar to implicit
> int/implicit-function-declaration?

My experience from doing the big rebuilds in Gentoo and working on
patches is that int-conversion often comes up with completely broken code
like wrong strerror_r variant (glibc vs musl) or with structs being
initialised with the wrong members (not using C99 desig. initialisers
and then differences with padding or similar). I don't think I can
recall a harmless hit.

Incompatible pointer types are a mix - sometimes it's harmless, but
a lot of the infringers aren't great (again often indicating wrong
prototypes being used or missing feature test macros). It's helped
to find a lot of typos as well. The only real snag (which isn't
a big deal IMO) is that it'll flag up attribute mismatches for
function pointer types, at least with Clang, but that's not a big
deal.

Clang has done both of these (technically Clang has only done
incompatible *function* pointer types rather than all incompatible
pointer types, at least for now though).

>
> Jeff

Re: -Wint-conversion as errors seems doable for GCC 14

[Sam James via Gcc]

Florian Weimer via Gcc  writes:

> I completed a Fedora rawhide rebuild with an instrumented GCC (~14,500
> packages).  156 packages failed to build with a logged -Wint-conversion
> error.  This number is much lower than what I expected, and I think we
> should include -Wint-conversion in the GCC 14 changes.
>
>[...]
>
> That's why I think the number of failing builds 156 is really quite low,
> and we should be able to manage on the Fedora side.

Yeah, this was my conclusion as well. For glibc in particular, it was
very low impact indeed - and for musl, the hits were all really broken
code.

Given we still, in theory, have some time (although not much) here,
would you mind scheduling a build with -Wincompatible-pointer-types
just to see what the fallout is on your end? Mainly interested in
the numbers. But I won't push my luck if you either don't have
time to run that or the list is large.

For us, it's been clouded by the fact that Vala is broken (so
a lot of bugs have the same root cause), and then the other
stuff was mixed.

thanks,
sam

Re: Update on GCC 14 C type safety changes/warnings as errors

[Sam James via Gcc]

Florian Weimer via Gcc  writes:

> [...]
> Numbers do not tally up because one package can have multiple issues.
> The autoconf column counts packages where file-name based heuristics
> suggest the critical errors are in autoconf-style feature probes, where
> they are ignored and could silently alter the results.  My focus will be
> on fixing those packages.

incompatible-pointer-types at least suffers from some expected errors
with e.g. strerror_r which you may want to just export the cache var for in a
glibc environment at least for testing.

Mine as well.

>
> These numbers include a certain amount of false positives, especially
> for implicit-function-declaration and incompatible-pointer-types, but
> the GCC instrumentation has improved somewhat and now uses unrelated
> errors (e.g., about unknown types, or incorrect number of function
> errors) to suppress logging of the critical errors.
>
> Looking at the numbers, everything seems quite doable except
> incompatible-pointer-types.  (Keep in mind that these numbers are based
> on over 15,000 packages.)  Instead of the incompatible-pointer-types
> error, Clang only went with a subset (not yet implemented by GCC) called
> incompatible-function-pointer-types, but I'm not sure if it would result
> in a substantial amount of work reduction.  The status as a warning for
> non-function pointers definitely hides real bugs (for example, an
> out-of-bounds write in PyTables on 32-bit architectures).
>
> I suggest we put in the incompatible-pointer-types upgrade for now
> (pending review), and see how it goes in Fedora.  I plan to backport
> these changes to GCC 13 as used in our current development version, so
> that we can gain some feedback from package maintainers before we import
> GCC 14 (which is expected to happen well before the GCC upstream
> release).  If feedback is overly negative, I'm going to suggest that GCC
> disables it again for the GCC 14 release, although that would run
> counter to the request for one transition only.
>
> Thoughts?

This sounds fair and in line with my observations. I lean towards us
being able to pull it off but if needed, reverting that specific change
later on in 14 development isn't the end of the world.

Of course, you've added -fpermissive for a reason anyway, so we have
that too.

I hadn't considered exposing a patched GCC 13 to developers and might do
the same, not sure how much take up there'd be on our end without some
runtime toggle instead. Will have a think, but not really worried about
it anyway, as the tinderboxes have great covergae & will run whatever
version we want.

> [...]

Thank you again for doing this Florian.

sam

Re: Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

[Sam James via Gcc]

Florian Weimer via Gcc  writes:

> I feel like I have asked this before.  Currently, GCC uses calls to
> __tls_get_addr to obtain the address of global-dynamic TLS variables.
> On other architectures with support for GNU2 TLS descriptors, those are
> used by default.
>
> Should we flip the default to GNU2 descriptors?  Support has been
> available in glibc for a long, long time.  Is there any other reason for
> not doing this?  On the glibc side, the behavior regarding lazy
> initialization and symbol binding does not change whether the old or new
> interface is used.
>

I was planning on bringing this up but I was worried there was some
reason we hadn't done it given it's been so long. Thank you!

Re: Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

[Sam James via Gcc]

Florian Weimer via Gcc  writes:

> [...]
> On other architectures with support for GNU2 TLS descriptors, those are
> used by default.
>

It looks like arm32 defaults to gnu, not gnu2. andrew mentioned fdpic
will be an issue there but maybe we could carve that out.

> Should we flip the default to GNU2 descriptors?
> [...]

thanks,
sam

Re: [PATCH] libstdc++: hashtable: No need to update before begin node in _M_remove_bucket_begin

[Sam James via Gcc]

Huanghui Nie  writes:

> Hi.

Please CC the libstdc++ LM for libstdc++ patches, per
https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html#list.patches.

> [...]

Re: Help needed with maintainer-mode

[Sam James via Gcc]

Mark Wielaard  writes:

> Hi Christophe,

Hi Mark, Christophe, et. al,

>
> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>> > > > And it was indeed done this way because that way the files are
>> > > > regenerated in a reproducible way. Which wasn't the case when using 
>> > > > --enable-maintainer-mode (and autoreconfig also doesn't work).
>> > >
>> > > I see. So it is possibly incomplete, in the sense that it may lack
>> > > some of the steps that maintainer-mode would perform?
>> > > For instance, gas for aarch64 has some *opcodes*.c files that need
>> > > regenerating before committing. The regeneration step is enabled in
>> > > maintainer-mode, so I guess the autoregen bots on Sourceware would
>> > > miss a problem with these files?
>> >
>> > Yes, it is certainly incomplete. But it is done this way because it is
>> > my understanding that even the gcc release maintainers do the
>> > automake/autoconf invocations by hand instead of running with configure
>> > --enable-maintainer-mode.
>> 
>> After a discussion on IRC, I read
>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>> which basically says "run autoreconf in every dir where there is a
>> configure script"
>> but this is not exactly what autoregen.py is doing. IIRC it is based
>> on a script from Martin Liska, do you know/remember why it follows a
>> different process?
>
> CCing Sam and Arsen who helped refine the autoregen.py script, who
> might remember more details. We wanted a script that worked for both
> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
> work in all directories. We also needed to skip some directories that
> did contain a configure script, but that were imported (gotools,
> readline, minizip).

What we really need to do is, for a start, land tschwinge/aoliva's patches [0]
for AC_CONFIG_SUBDIRS.

Right now, the current situation is janky and it's nowhere near
idiomatic autotools usage. It is not a comfortable experience
interacting with it even as someone who is familiar and happy with using
autotools otherwise.

I didn't yet play with maintainer-mode myself but I also didn't see much
point given I knew of more fundamental problems like this.

[0] https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/

>
> Cheers,
>
> Mark

best,
sam


signature.asc
Description: PGP signature

Re: Sourceware mitigating and preventing the next xz-backdoor

[Sam James via Gcc]

Paul Eggert  writes:

> On 4/9/24 14:40, Jeffrey Walton wrote:
>> Code provenance and code integrity was not enforced. Part of the
>> problem is the Autotools design. It is from a bygone era.
>
> No, Andreas is right. This isn't an Autotools-vs-Meson thing.
>
> Most of the Autotools-based projects I help maintain would have been
> immune to this particular exploit, partly because they don't maintain
> their own of Gnulib .m4 files. Conversely, any Meson-based project
> that had the same sort of out-of-repository sloppiness and lack of
> review that xz had, would be vulnerable to similar attacks.
>

While it could indeed happen via a variety of methods, it's still worth
talking about how to reduce places for it to hide in, and make review
easier, I think.

>> No one should be able to override a named, GNU supplied m4 macro.
>
> That ship sailed long ago, for Autoconf and for Meson and for every
> other widely-available build tool I know of. Everyone can write and
> run their own code, whether it comes from GNU or not. That's a feature
> that developers want and need. Although this feature can be misused,
> it's not a bug per se.

Meson doesn't allow user-defined functions and macros to avoid
metaprogramming hell:
https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros.

Re: Sourceware mitigating and preventing the next xz-backdoor

[Sam James via Gcc]

Jonathon Anderson via Gdb  writes:

> On Tue, 2024-04-09 at 16:11 -0400, Paul Koning wrote:
>>
>> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc 
>> <[gcc@gcc.gnu.org](mailto:gcc@gcc.gnu.org)> wrote:
>>
>> > CMake has its own sandbox and rules and escapes (granted, much more of
>> > them). But regardless, the injection code would be committed to the
>> > repository (point 2) and would not hold up to a source directory mounted
>> > read-only (point 3).
>> 
>> Why would the injection code necessarily be committed to the
>> repository?  It wasn't in the xz attack -- one hole in the
>> procedures is that the kits didn't match the repository and no
>> checks caught this.  I don't see how a different build system would
>> cure that issue.  Instead, there needs to be some sort of audit that
>> verifies there aren't rogue or modified elements in the kit.
>
> In Autotools, `make dist` produces a tarball that contains many files
> not present in the source respoitory, it includes build system core
> files and this fact was used for the xz attack. In contrast, for newer
> build systems the "release tarball" is purely a snapshot of the source
> repository: there is no `cmake dist`, and `meson dist` is essentially
> `git archive`
> ([docs](https://mesonbuild.com/Creating-releases.html)). Thus for the
> injection code to be present in the release tarball, it needs to have
> first been checked into the repository.

(Of course, one could modify it after, but the point here is that it's by
design reproducible so any differences are suspicious, just to be
clear.)

>
> In fact, packagers don't *need* to use the tarballs, they can (and
> should) use the Git history from the source repository itself. In
> Debian this is one workflow implemented by the popular
> git-buildpackage
> ([docs](https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html)).
>  The
> third-party package manager
> [Spack](https://spack.readthedocs.io/en/latest/packaging_guide.html#git)
> clones directly from the source repository. Others may have support
> for this as well, this isn't a novel idea.
>
> -Jonathon


signature.asc
Description: PGP signature

Re: Sourceware mitigating and preventing the next xz-backdoor

[Sam James via Gcc]

Jonathon Anderson  writes:

> On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote:
>
>  On 4/9/24 14:40, Jeffrey Walton wrote:
>
>  Code provenance and code integrity was not enforced. Part of the problem is 
> the Autotools design. It is from a
>  bygone era.
>
>  No, Andreas is right. This isn't an Autotools-vs-Meson thing.
>
>  Most of the Autotools-based projects I help maintain would have been
>  immune to this particular exploit, partly because they don't maintain
>  their own of Gnulib .m4 files. Conversely, any Meson-based project that
>  had the same sort of out-of-repository sloppiness and lack of review
>  that xz had, would be vulnerable to similar attacks.
>
> Xz doesn't either, the exploit was unique to the distributed make dist 
> tarballs. Which is an Autotools quirk present in
> all Autotools projects.
>
> I won't deny that a project could use Meson and be sloppy, a project could 
> use SSL/TLS/whatever and be completely
> insecure. But Autotools encourages and semi-requires this sloppy behavior, 
> and CMake and Meson strongly discourage this
> behavior.

Indeed. Talking about things in the context of "how can we make it
easier to spot" is a good thing. Obviously if we're trying to resist a
state actor, things are very hard. It doesn't mean don't bother.

>
> -Jonathon

thanks,
sam


signature.asc
Description: PGP signature

Re: Sourceware mitigating and preventing the next xz-backdoor

[Sam James via Gcc]

Paul Eggert  writes:

> On 4/9/24 14:58, Sam James wrote:
>> Meson doesn't allow user-defined functions
>
> Meson has ways to execute arbitrary user-defined code, so it's not
> immune to this sort of exploit.

To be clear - not saying it's immune. Just that it scopes the
user-defined code part to clearly defined sections.

I think it makes sense to optimise for ease of review.

>
> It's of course better (all other things being equal) to use a build
> system with a smaller attack surface. However, any surface of nonzero
> size is attackable, so I'm not convinced that Meson is significantly
> safer against a determined insider. Although the xz exploit was tricky
> and is now famous (hey! the front page of the New York Times!)
> fundamentally it was sloppy and amateurish and it succeeded only
> because xz's project management was even sloppier.
>
> Yes, we need to defend against amateurish attacks. But we shouldn't
> waste valuable developer time on defenses that won't work against
> obvious future attacks and that will likely cost more than they'll
> benefit. That's just security theater.

Right, I'm not advocating that. It's just easy to go too far the other
way too and not change anything because it won't hold up against a state
actor.


signature.asc
Description: PGP signature

Re: What is the purpose of these two fixincludes?

[Sam James via Gcc]

Andi Kleen via Gcc  writes:

> FX Coudert via Gcc  writes:
>
>> Hi,
>>
>> I am trying to reduce the number of unneeded fixincludes that are used
>> on darwin (because fixincluded headers make it impossible to change
>> SDK once the compiler is built, which is common practice in the macOS
>> world, and quite useful).
>
> It's the same problem on Linux.  You get all kinds of strange problems
> with previously installed gccs once you upgrade the system. I'm not sure
> in fact any modern target gcc or clang as the standard compiler needs
> fixincludes at all.
>
> I usually just install with install-no-fixedincludes, but really this
> should probably be a configure option and default to on.

See --disable-fixincludes from r13-2319-gbe9dd80f933480. Long overdue
but we got it :)

>
> -Andi

thanks,
sam

Re: Building libgccjit with -fno-semantic-interposition? ( was Re: 1.76% performance loss in VRP due to inlining)

[Sam James via Gcc]

Andrea Corallo via Gcc  writes:

>> FWIW I've no idea if any libgccjit users are using semantic
>> interposition; I suspect the answer is "no one is using it".
>> 
>> Antoyo, Andrea [also CCed]: are either of you using semantic
>> interposition of symbols within libgccjit?
>
> Hi David,
>
> AFAIU in Emacs we are not relying on interposition of symbols.

FWIW, I've built GCC (inc. libgccjit for Emacs) with
-fno-semantic-interposition for a few years now and had no issues.

It's worth considering, I think, given the above.

>
> Thanks
>
>   Andrea

[RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

Hi!

This comes up in #gcc on IRC every so often, so finally
writing an RFC.

What?
---

I propose that MAINTAINERS be modified to be of the form,
adding an extra field for their GCC/sourceware account:
  
  Joe Bloggsjoeblo...@example.com  jblo...@gcc.gnu.org

Further, that the field must not be blank (-> must have a BZ account;
there were/are some without at all)!

Why?
---

1) This is tied to whether or not people should use their committer email
on Bugzilla or a personal email. A lot of people don't seem to use their
committer email (-> no permissions) and end up not closing bugs, so
pinskia (and often myself these days) end up doing it for them.

2) It's standard practice to wish to CC the committer of a bisect result
- or to CC someone who you know wrote patches on a subject area. Doing
this on Bugzilla is challenging when there's no map between committer
<-> BZ account.

Specifically, there are folks who have git committer+author as
joeblo...@example.com (or maybe even coold...@example.com) where the
local part of the address has *no relation* to their GCC/sw account,
so finding who to CC is difficult without e.g. trawling through gcc-cvs
mails or asking overseers for help.

Summary
---

TL;DR: The proposal is:

1) MAINTAINERS should list a field containing either the gcc.gnu.org
email in full, or their gcc username (bikeshedding semi-welcome);

2) It should become a requirement that to be in MAINTAINERS, one must
possess a Bugzilla account (ideally using their gcc.gnu.org email).

thanks,
sam


signature.asc
Description: PGP signature

Re: [RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

Arsen Arsenović  writes:

> Hi,
>
> Richard Biener  writes:
>
>> [snip]
>>> I was also proposing (and would like to re-air that here) enforcing
>>> that the committer field of each commit is a (valid) @gcc.gnu.org
>>> email.  This can be configured repo-locally via:
>>>
>>>   $ git config committer.email @gcc.gnu.org
>>>
>>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
>>> (v2.22.0).
>>>
>>> This makes a permanent association of each commit to its authors
>>> Sourceware account.
>>
>> I'd welcome this - care to create a patch for
>> contrib/gcc-git-customization.sh?
>
> Sure - I've attached a partial patch.  I didn't find the hook which runs
> on each push to check commits, so the current patch is minimal.  Is that
> also in the tree?  I could try hacking it to check commits.

See https://github.com/AdaCore/git-hooks.

Re: [RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

"Richard Earnshaw (lists)"  writes:

> On 24/06/2024 22:34, Sam James via Gcc wrote:
>> Hi!
>> 
>> This comes up in #gcc on IRC every so often, so finally
>> writing an RFC.
>> 
>> What?
>> ---
>> 
>> I propose that MAINTAINERS be modified to be of the form,
>> adding an extra field for their GCC/sourceware account:
>>   > account>
>>   Joe Bloggsjoeblo...@example.com  jblo...@gcc.gnu.org
>> 
>> Further, that the field must not be blank (-> must have a BZ account;
>> there were/are some without at all)!
>> 
>> Why?
>> ---
>> 
>> 1) This is tied to whether or not people should use their committer email
>> on Bugzilla or a personal email. A lot of people don't seem to use their
>> committer email (-> no permissions) and end up not closing bugs, so
>> pinskia (and often myself these days) end up doing it for them.
>> 
>> 2) It's standard practice to wish to CC the committer of a bisect result
>> - or to CC someone who you know wrote patches on a subject area. Doing
>> this on Bugzilla is challenging when there's no map between committer
>> <-> BZ account.
>> 
>> Specifically, there are folks who have git committer+author as
>> joeblo...@example.com (or maybe even coold...@example.com) where the
>> local part of the address has *no relation* to their GCC/sw account,
>> so finding who to CC is difficult without e.g. trawling through gcc-cvs
>> mails or asking overseers for help.
>> 
>> Summary
>> ---
>> 
>> TL;DR: The proposal is:
>> 
>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
>> email in full, or their gcc username (bikeshedding semi-welcome);
>> 
>> 2) It should become a requirement that to be in MAINTAINERS, one must
>> possess a Bugzilla account (ideally using their gcc.gnu.org email).
>> 
>> thanks,
>> sam
>
>
> How does this work for cases where:
> 1) Committer is pushing to a personal or other copy of the repository
> 2) Developers who have used the 'fetch' model to pull another developer's 
> patches from 1 above?
>
> Forcing these to be rewritten will break the hashes.

To be clear, my proposal doesn't touch on the actual git metadata people
should use, although Arsen's followup one does.

>
> R.

thanks,
sam

Re: [RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

Gerald Pfeifer  writes:

> On Mon, 24 Jun 2024, Jonathan Wakely via Gcc wrote:
>>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
>>> email in full, or their gcc username (bikeshedding semi-welcome);
>> I like the proposal. I'd say it should be fine to just put the gcc
>> username (without the @gcc.gnu.org part) because the lines are long
>> enough already, and repeating the domain on every line is redundant.
>
> Plus it would look like an e-mail address to use which in many cases 
> (like mine) may not be desirable.
>
> Now, a bigger question: Why would anyone need to know my gcc.gnu.org 
> username (or e-mail address) in the Bugzilla context? 

Isn't it answered in the original proposal? It makes CCing the committer
of a bisect result way easier.

Re: [RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

Gerald Pfeifer  writes:

> On Wed, 3 Jul 2024, Sam James wrote:
>>> Now, a bigger question: Why would anyone need to know my gcc.gnu.org 
>>> username (or e-mail address) in the Bugzilla context? 
>> Isn't it answered in the original proposal? It makes CCing the committer 
>> of a bisect result way easier.
>
> No, it's not. And no, it does not in my case, for example.
>
> Hence my counter proposal (with emphasis added):
>   
>   A counter proposal for the original request would be an OPTIONAL field 
>   to include in case the e-mail address listed in the MAINTAINERS file 
>   does NOT serve as the Bugzilla account.

I don't think this helps the usecase I mentioned though.

There are a bunch of developers who have a blank or unrelated "real
name" on Bugzilla, so you can't go from a committing email -> Bugzilla
account easily. If every developer has to use @gcc.gnu.org on Bugzilla,
and we normalise on @gcc.gnu.org, things become easier to map.

So, for example with your counter proposal, this doesn't aid me if
someone committed with a third email they use for commits/authorship, as
MAINTAINERS won't provide any information in mapping it to a Bugzilla
account (as I have no idea what to lookup).

Re: [RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

Sam James via Gcc  writes:

> Gerald Pfeifer  writes:
>
>> On Mon, 24 Jun 2024, Jonathan Wakely via Gcc wrote:
>>>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
>>>> email in full, or their gcc username (bikeshedding semi-welcome);
>>> I like the proposal. I'd say it should be fine to just put the gcc
>>> username (without the @gcc.gnu.org part) because the lines are long
>>> enough already, and repeating the domain on every line is redundant.
>>
>> Plus it would look like an e-mail address to use which in many cases 
>> (like mine) may not be desirable.
>>
>> Now, a bigger question: Why would anyone need to know my gcc.gnu.org 
>> username (or e-mail address) in the Bugzilla context? 

Also, as I pointed out, there are *very few* accounts which are
n...@gcc.gnu.org with Bugzilla permissions, and on IRC, Jakub et. al
expressed a reluctance in adding more of those. So most people not using
their @gcc.gnu.org email on BZ aren't able to close or modify bugs anyway, which
isn't good.

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

[Sam James via Gcc]

Jonathan Wakely via Gcc  writes:

> On Fri, 5 Jul 2024 at 17:02, Xi Ruoyao via Gcc  wrote:
>>
>> On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote:
>> > At least, I hope there's consensus that while current GCC doesn't warn
>> > about this, ideally it should, which means it should warn for valid uses
>> > of strtol(3), which means strtol(3) should be fixed, in all of ISO,
>> > POSIX, and glibc.
>>
>> It **shouldn't**.  strtol will only violate restrict if it's wrongly
>> implemented, or something dumb is done like "strtol((const char*) &p,
>> &p, 0)".
>>
>> See my previous reply.
>
> Right, is there a valid use of strtol where a warning would be justified?
>
> Showing that you can contrive a case where a const char* restrict and
> char** restrict can alias doesn't mean there's a problem with strtol.

I still don't understand why it'd be appropriate for GCC and glibc to
override this without it even being *brought to* the committee, either.

Re: [RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

Richard Sandiford  writes:

> Sam James via Gcc  writes:
>> Hi!
>>
>> This comes up in #gcc on IRC every so often, so finally
>> writing an RFC.
>>
> [...]
>> TL;DR: The proposal is:
>>
>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
>> email in full, or their gcc username (bikeshedding semi-welcome);
>>
>> 2) It should become a requirement that to be in MAINTAINERS, one must
>> possess a Bugzilla account (ideally using their gcc.gnu.org email).
>
> How about the attached as a compromise?  (gzipped as a poor protection
> against scraping.)
>

Thanks! This would work for me. A note on BZ below.

> It adds the gcc.gnu.org/bugzilla account name, without the @gcc.gnu.org,
> as a middle column to the Write After Approval section.  I think this
> makes it clear that the email specified in the last column should be
> used for communication.
>
> [..]
>
> If this is OK, I'll need to update check-MAINTAINERS.py.

For Bugzilla, there's two issues:
1) If someone uses an alternative (n...@gcc.gnu.org) email on Bugzilla,
unless an exception is made (and Jakub indicated he didn't want to add
more - there's very few right now), they do not have editbugs and cannot
assign bugs to themselves or edit fields, etc.

This leads to bugs being open when they don't need to be anymore, etc,
and pinskia and I often have to clean that up.

People with commit access are usually very happy to switch to
@gcc.gnu.org when I let them know it grants powers!

2) CCing someone using a n...@gcc.gnu.org email is a pain, but *if* they
have to use a n...@gcc.gnu.org email, it might be OK if they use the
email that is listed in MAINTAINERS otherwise. If they use a third email
then it becomes a pain though, but your proposal helps if it's just two
emails in use.

(But I'd still really encourage them to not do that, given the lack of
perms.)

I care about both but 1) > 2) for me, some others here care a lot about 2)
if they're the ones doing triage and bisecting.

thanks,
sam

Re: [RFC] MAINTAINERS: require a BZ account field

[Sam James via Gcc]

Richard Sandiford  writes:

> Sam James  writes:
>> Richard Sandiford  writes:
>>
>>> Sam James via Gcc  writes:
>>>> Hi!
>>>>
>>>> This comes up in #gcc on IRC every so often, so finally
>>>> writing an RFC.
>>>>
>>> [...]
>>>> TL;DR: The proposal is:
>>>>
>>>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
>>>> email in full, or their gcc username (bikeshedding semi-welcome);
>>>>
>>>> 2) It should become a requirement that to be in MAINTAINERS, one must
>>>> possess a Bugzilla account (ideally using their gcc.gnu.org email).
>>>
>>> How about the attached as a compromise?  (gzipped as a poor protection
>>> against scraping.)
>>>
>>
>> Thanks! This would work for me. A note on BZ below.
>>
>>> It adds the gcc.gnu.org/bugzilla account name, without the @gcc.gnu.org,
>>> as a middle column to the Write After Approval section.  I think this
>>> makes it clear that the email specified in the last column should be
>>> used for communication.
>>>
>>> [..]
>>>
>>> If this is OK, I'll need to update check-MAINTAINERS.py.
>>
>> For Bugzilla, there's two issues:
>> 1) If someone uses an alternative (n...@gcc.gnu.org) email on Bugzilla,
>> unless an exception is made (and Jakub indicated he didn't want to add
>> more - there's very few right now), they do not have editbugs and cannot
>> assign bugs to themselves or edit fields, etc.
>>
>> This leads to bugs being open when they don't need to be anymore, etc,
>> and pinskia and I often have to clean that up.
>>
>> People with commit access are usually very happy to switch to
>> @gcc.gnu.org when I let them know it grants powers!
>>
>> 2) CCing someone using a n...@gcc.gnu.org email is a pain, but *if* they
>> have to use a n...@gcc.gnu.org email, it might be OK if they use the
>> email that is listed in MAINTAINERS otherwise. If they use a third email
>> then it becomes a pain though, but your proposal helps if it's just two
>> emails in use.
>>
>> (But I'd still really encourage them to not do that, given the lack of
>> perms.)
>>
>> I care about both but 1) > 2) for me, some others here care a lot about 2)
>> if they're the ones doing triage and bisecting.
>
> Ah, yeah, I agree with all of the above.  By "communication" I meant
> "normal email" -- sorry for the bad choice of words.

Ah, great!

>
> For me, the point of the new middle column is to answer "which gcc.gnu.org
> account should I use in bugzilla PRs?".  But adding "@gcc.gnu.org" to each
> entry might encourage people to use it for normal email too.
>
> After:
>
>   To report problems in GCC, please visit:
>
> http://gcc.gnu.org/bugs/
>
> how about adding something like:
>
>   If you wish to CC a maintainer in bugzilla, please add @gcc.gnu.org
>   to the account name given in the Write After Approval section below.
>   Please use the email address given in <...> for direct email communication.
>

Sounds good to me -- thank you! This seems like a solid compromise (or
even a better way of doing what I wanted to begin with).

> Richard

thanks,
sam

RFC: Changing Bugzilla updates at release time

[Sam James via Gcc]

Hi!

This came out of some discussion with Arsen and prompted by some other
comments on IRC.

At the moment, during release time, maintainer-scripts/branch_changer.py
is run by release managers and causes a large amount of bugmail to be
sent both to CCs/assignees but also to the gcc-bugs ML. The activity
comes from the RM's personal account. In the past, I've missed real
activity on bugs (including a question to me) as well as some other
email drowned out in the notification emails.

What do people think about possibly having a special 'GCC releases'
account which only the RMs have an API key to, possibly suppresses
sending email to begin with, and is ignored by gcc-bugs? It would allow
easier filtering out of the mail.

(I'm familiar enough with BZ to say it should be trivially doable, with
the exception of suppressing *sending* the mail to begin with, which I'd
have to investigate.)

thanks,
sam


signature.asc
Description: PGP signature

Re: gcc-regression script build fail info

[Sam James via Gcc]

"Jiang, Haochen"  writes:

> Ping for this thread.
>
> Any ideas? If no, I will change the generated info with command following
> if we take r15-1643 as example and see if it is clearer:
>
> head -26 makelog.r15-1643.x86_64.native | tail -7 > 1.log;
> grep -E "(error:|Error)" makelog.r15-1643.x86_64.native >> 1.log;
> echo " Detailed Info around error (+- 10 Lines) 
> " >> 1.log;
> grep -C 10 -E "error:" makelog.r15-1643.x86_64.native >> 1.log;
>

This plan sounds good to me, although I was hoping someone might speak
up ;)

I will keep an eye on the failures afterwards and then see if it looks
OK too.

(Sorry if you were waiting on me, I may have misunderstood.)

> Thx,
> Haochen
>
>> -Original Message-
>> From: Jiang, Haochen
>> Sent: Thursday, July 18, 2024 3:57 PM
>> To: 'Sam James' 
>> Cc: 'gcc-regress...@gcc.gnu.org' ; 'gcc-
>> testresu...@gcc.gnu.org' ; 'gcc@gcc.gnu.org'
>> 
>> Subject: RE: gcc-regression script build fail info
>> 
>> 
>> 
>> > -Original Message-
>> > From: Jiang, Haochen
>> > Sent: Thursday, July 18, 2024 3:46 PM
>> > To: 'Sam James' 
>> > Cc: 'gcc-regress...@gcc.gnu.org' ; 'gcc-
>> > testresu...@gcc.gnu.org' ; gcc@gcc.gnu.org
>> > Subject: gcc-regression script build fail info
>> >
>> > > > For future reports, would it be possible to change the grep to
>> > > > something
>> > > > like:
>> > > >
>> > > > grep -E "(error:|Error)" or just grep -rsin "error" -w or something.
>> > > >
>> > > > This would allow catching the actual compile error in libbacktrace
>> > > > if it's not going to fit in the last N lines from make.
>> > >
>> > > Hi Sam,
>> > >
>> > > Let me change that in the script and see if it is much clearer.
>> > >
>> > > This bug report definitely seems not clear for me also.
>> >
>> > Hi all,
>> >
>> > Sam just mentioned in another thread that the current log for build fail in
>> gcc-
>> > regression is not clear at all, like the problem in:
>> > https://gcc.gnu.org/pipermail/gcc-regression/2024-July/080272.html
>> > The 100 bottom line didn't give any info for why it runs into a build fail.
>> >
>> > As Sam suggested, we might change the build fail info part which is 
>> > currently
>> > using 'tail -100' to 'grep -E "(error:|Error)"' to get some clear info.
>> >
>> > Does any one still needs the 'tail -100' for some more info? Or if the 
>> > output
>> for
>> > 'grep -E "(error:|Error)" is enough?
>> >
>> > For example, for r15-2116, overall report will be:
>> 
>> Made a typo here, the report is generated from r15-1643.
>> 
>> >
>> > make[2]: Entering directory '/home/haochenj/src/gcc-regression'
>> > rm -rf bld
>> > mkdir -p bld
>> > cd bld; \
>> >  RUNTESTFLAGS="--target_board='unix{-m32,}'" ../src-master/configure \
>> > --with-arch=native --with-cpu=native --enable-clocale=gnu --with-
>> system-
>> > zlib --enable-shared --enable-cet --with-demangler-in-ld --enable-libmpx --
>> > prefix=/usr/gcc-15.0.0 --with-fpmath=sse checking build system type...
>> > x86_64-pc-linux-gnu
>> > grep "Error " makelog.r15-1643.x86_64.native >> makelog.r15-
>> > 1643.x86_64.native.mail; \
>> > make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
>> 1
>> > (ignored)
>> > make[6]: [Makefile:1831: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
>> 1
>> > (ignored)
>> > make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
>> 1
>> > (ignored)
>> > ../../src-master/gcc/config/i386/i386.cc:107:12: error: 'rtx_def*
>> > legitimize_dllimport_symbol(rtx, bool)' declared 'static' but never 
>> > defined [-
>> > Werror=unused-function]
>> > ../../src-master/gcc/config/i386/i386.cc:108:12: error: 'rtx_def*
>> > legitimize_pe_coff_extern_decl(rtx, bool)' declared 'static' but never 
>> > defined
>> [-
>> > Werror=unused-function]
>> > make[6]: *** [Makefile:2557: i386.o] Error 1
>> > make[5]: *** [Makefile:5108: all-stage2-gcc] Error 2
>> > make[4]: *** [Makefile:30031: stage2-bubble] Error 2
>> > make[3]: *** [Makefile:30275: bootstrap] Error 2
>> > make[2]: *** [Makefile:313: bootstrap] Error 2
>> > make[1]: *** [Makefile:409: one] Error 1
>> > make: *** [Makefile:406: one-master] Error 2
>> >
>> > Thx,
>> > Haochen
>> >
>> > >
>> > > Thx,
>> > > Haochen
>> > >
>> > > >
>> > > > (Not needed here as ILT already fixed the issue on master).
>> > > >
>> > > > thanks,
>> > > > sam


signature.asc
Description: PGP signature

Re: Fixing dormant bugs in obstack code

[Sam James via Gcc]

Andrew Pinski via Gcc  writes:

> On Wed, Aug 28, 2024 at 2:37 PM David Malcolm via Gcc  wrote:
>>
>> I've been debugging a use-immediately-after-free bug involving obstacks
>> (the bug isn't in trunk; I found it whilst testing one of my patches).
>>
>> It was only visible as a crash when it happened that the call to
>> obstack_free led to the underlying buffer being freed.  Most of the
>> time, the bug was dormant, since the obstack_free was merely unwinding
>> the "high water mark" of allocation within a buffer, and so the
>> "obstack_free"d memory was still accessible to the process.
>>
>> Is there a way to make the obstack code "fussier" e.g. a debug option
>> that on obstack_free fills the freed memory with a canary garbage
>> value, so that this kind of bug immediately leads to a crash? (probably
>> only in a checking build).  Similarly, filling obstack memory with
>> "not-yet-initialized" etc.  I wonder if there's a way to "teach"
>> valgrind about obstacks.
>
> Note obstack upstream is technically glibc.
> Sam had filed a GCC bug report asking adding valgrind notations
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116246) but he found
> that there is already a bug report opened against gdb for it though:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30114 .
>
> Also libiberty upstream is technically gcc git repo; though most
> patches are posted to either the GCC mailing list or to gdb and the
> GCC mailing or to binutils and gcc mailing list.


BTW, I have a sync for libiberty/ with gnulib. I just haven't posted it
yet. But I don't mind rebasing after dmalcolm's work either.

>
> Thanks,
> Andrew Pinski
>
>
>>
>> I can try my hand at a patch if people think it's a good idea.  It's
>> part of libiberty, so which mailing list "owns" obstack development?

Yes please!

>>
>> Thanks
>> Dave
>>

Re: Is -Wtraditional obsolete?

[Sam James via Gcc]

Joseph Myers via Gcc  writes:

> One issue that showed up as test failures with a default of -std=gnu23 is 
> that -std=gnu23 -Wtraditional produces a "traditional C rejects ISO C 
> style function definitions" warning for function definitions with empty 
> parentheses, as they are treated like (void) in C23, so resulting in 
> failure of several -Wtraditional tests.
>
> Clearly that's a bug (that warning should only be given for literal 
> (void), not for () meaning (void)) and wouldn't be hard to fix.  But is 
> there actually any current use for the -Wtraditional option?  It seems 
> extremely unlikely now that compatibility with pre-C89 compilers would be 
> relevant.  So maybe it would make more sense to remove -Wtraditional 
> support (remove all the logic implementing the option, make it an option 
> marked with Ignore in c.opt to do nothing so as not to break any build 
> systems that hardcode this option) rather than fixing this bug with an 
> option that's probably no longer useful.

Given the other messages in the thread, I'd like to share some anecdotal
data:
* I see 0 instances of -Wtraditional appearing in my cache of build
logs;

* I see 0 non-trivial (e.g. comments or bundled autoconf macros)
references to -Wtraditional in my collection of repositories;

* There are some, but not many, references on Debian code search:
  .
  
  Note that a chunk of the references are the kind of macros I
  mentioned, copies of GCC, or NEWS/ChangeLogs;
  
* Not to say that such warnings are useless to ever attempt, but people
  who need compatibility with such compilers should really test with
  them anyway, so this is merely a convenience thing. It's not like it
  actually guarantees such compilers will work (to give another example,
  -std=gnu89 still lets you use headers which weren't in C89).

Re: On pull request workflows for the GNU toolchain

[Sam James via Gcc]

Carlos O'Donell  writes:

> On 9/19/24 11:51 AM, Joseph Myers wrote:
>> 1. Introduction
>
> Thanks for writing this up!
>
> [...]
> Agreed.
>

I just want to say the same. My sentiments match Carlos.

Re: [CAULDRON] Topics for the Toolchain and Linux kernel BoF

[Sam James via Gcc]

"Jose E. Marchesi via Gcc"  writes:

> Hello people!
>
> This year we will be having a kernel BoF at Cauldron.  It is scheduled
> for Saturday from 15:30 to 16:30.  There will be several kernel
> maintainers and hackers in attendance, and the goal of the BoF is to
> discuss and collect feedback about several toolchain-related issues that
> are of current interest for the kernel.  The output of the discussions
> and the feedback collected will then be used as a basis for further
> discussions at the Linux Plumbers conference that will be held the next
> week in Vienna.  The idea is to get kernel and toolchain hackers
> together and advance on these topics.
>
> Find below some of the topics we will be discussing.  Many of them are
> relevant to GCC, and we ask you to consider attending if you are coming
> to the Cauldron.  The list of topics is of course not closed, and you
> are very welcome to bring your own, specially if your work would benefit
> from feedback from the kernel hackers.
>
> - LTO and inline asm symbols
>
>   A lot of assembler statements reference C symbols, which need to be
>   externally_visible and global for GCC LTO, otherwise they can end up in the
>   wrong asm file and cause missing symbols.
>
>   Goal of the discussion:
>
>   Provide an assessment of the reported problem, and discuss the two
>   alternatives already proposed in the bugzillas below: one ad-hoc solution
>   based on parsing symbol references in inline asm strings, another is to
>   allow top-level extended asm that can get input arguments.
>
>   References:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045

We didn't end up having time to discuss this in the BoF *but* the videos
from this year's Cauldron are now available at
https://www.youtube.com/@gnutoolscauldron7666.

It looks like Honza's IPA/LTO/FDO BoF did cover this for a while and
some interesting ideas came up -- see https://youtu.be/bWH4_in2s0o?t=1450
onwards.

A lot of the discussion was around the biggest blocker (handling global
asm) and the format of some possible gas extensions & diagnostics
required.

thanks,
sam

Re: x86_64 regression tests arbitrary failing?

[Sam James via Gcc]

Arsen Arsenović via Gcc  writes:

> Hi,
>
> Georg-Johann Lay  writes:
>
>> For a trivial change that I'd like to bootstrap + regtest, I am
>> am getting FAILs like:
>>
>> $ diff xxx/gcc/testsuite/gcc/gcc.sum  yyy/gcc/testsuite/gcc/gcc.sum
>> 164656c164656
>> < PASS: c-c++-common/tsan/atomic_stack.c   -O0  output pattern test
>> ---
>>> FAIL: c-c++-common/tsan/atomic_stack.c   -O0  output pattern test
>> 164659c164659
>> < FAIL: c-c++-common/tsan/atomic_stack.c   -O2  output pattern test
>> ---
>>> PASS: c-c++-common/tsan/atomic_stack.c   -O2  output pattern test
>> 164662c164662
>> < PASS: c-c++-common/tsan/bitfield_race.c   -O0  output pattern test
>> ---
>>> FAIL: c-c++-common/tsan/bitfield_race.c   -O0  output pattern test
>> 164668c164668
>> < PASS: c-c++-common/tsan/fd_pipe_race.c   -O0  output pattern test
>> ---
>>> FAIL: c-c++-common/tsan/fd_pipe_race.c   -O0  output pattern test
>> 164674c164674
>> < FAIL: c-c++-common/tsan/free_race.c   -O0  output pattern test
>> ---
>>> PASS: c-c++-common/tsan/free_race.c   -O0  output pattern test
>>
>> Is there anything special so that these tests don't arbitrary flip
>> their PASS/FAIL state?
>>
>> The GCC version that's being tested is current trunk.
>> The build compiler is GCC v14.2.1.
>>
>> The two testsuites (one for xxx and one for yyy) are being run
>> at the same time (in their tmux panes).  For what I know tests
>> may run at the same time when they are in different build
>> directories.
>
> They can.  That's fine.
>
>> The configure command is basically
>>
>> $ ../../source/gcc/configure
>>
>> The command to run the testsuites is
>>
>> $ make check
>>
>> from the respective top level build directory.
>
> For TSAN tests, this might happen on some machines, for a reason I am
> yet to determine (I've also seen it on cfarm420, but not on my PC).
>
> If you wish to confirm this is spurious, you could rerun that part of
> the testsuite on the same source tree and compare the results.  I expect
> you'll get differences again (and not the same ones as the ones you
> showed above).

In the past, TSAN tests (like the rest of the sanitizers) have been
sensitive to kernel version, config, and sysctl toggles. But I agree
it's a bit odd that these keep flip-flopping (I've seen it too).

I know Jakub plans a libsanitizer sync at some point for trunk, so
probably worth investigating after that happens.

Re: [committed] c: Default to -std=gnu23

[Sam James via Gcc]

Florian Weimer  writes:

> * Sam James:
>
>>> Has anyone performed experiments to determine the impact of this change
>>> on typical free software distributions?
>>
>> I filed https://gcc.gnu.org/PR117298 for an issue Joseph noticed in one
>> of the GCC tests (that is actually an improvement, but a missed opt for
>> older standards). I haven't done any sort of testing but am curious
>> about it as well.
>>
>> I could do such a test for code size en-masse (and perhaps maybe even
>> check where the image changed at all). Runtime performance is far harder
>> for me to do at scale though. We can use significant code size changes
>> as a proxy for interesting candidates to investigate though.
>>
>> What are you thinking of?
>
> Mostly compatibility with older configure scripts.  There are the new
> keywords bool/true/false, and the -Werror=deprecated-non-prototype
> default that could alter configure test outcomes.  Maybe there's
> something else I'm missing?
>
> Some estimate of the build failure would also be helpful.  Is it the
> same as, e.g. the GCC 12 to GCC 13 update, or is it igher?

It's pretty large so far. Between 12 and 13, the main issues were:
libstdc++ transitive include changes and a small number of -Werror
breakages.

See https://bugs.gentoo.org/show_bug.cgi?id=880545 and
https://bugs.gentoo.org/showdependencytree.cgi?id=880545&hide_resolved=1
(*).

I think there'll be a lot more, the testers are currently blocked on
some core packages not building. I've done no configure test checking
yet, but I have seen a handful (3, I think) of packages which failed to build 
that
indicate a configure test went wrong.

(*) That tracker was started initially for when Clang started warning
about it and so on and didn't have that many blockers until I revived it
when the GCC default changed the other week.

thanks,
sam

Re: libdiagnostics name clash

[Sam James via Gcc]

David Malcolm via Gcc  writes:

> I merged libdiagnostics to GCC trunk on Monday:
>   https://gcc.gnu.org/wiki/libdiagnostics
>
> Unfortunately I've since discovered there's at least one libdiagnostics
> .so already in Debian:
> https://tracker.debian.org/pkg/diagnostics
> https://packages.debian.org/search?searchon=contents&keywords=libdiag&mode=filename&suite=unstable&arch=any

FWIW, we don't have that packaged and at a glance, we never have.

>
> so I've been asked to change the name.
>
> I'd prefer to avoid having "gcc" in the name.
>
> Some name ideas:
>
> * libdiag
> * libgdiagnostics (where we can be ambiguous about what the "g" stands
> for)
> * libgdiag (less typing)
> * libcomplain
> * libcomplaint
> * libwhining
> * libwhine (but sounds like the Windows compat software)

I like libwhine > libgdiag > libdiag (libdiag feels too prone to
collision again, and whine has a bit of fun personality).

I worry that complain gives the impression of like, libabrt/apport or
whatever (those crash reporting libraries/programs).

But really, all of these sound fine and I'll go with whatever.

>
> Any ideas?
>
> Thanks
> Dave

thanks,
sam

Re: [committed] c: Default to -std=gnu23

[Sam James via Gcc]

Florian Weimer  writes:

> * Joseph Myers:
>
>> Change the default language version for C compilation from -std=gnu17
>> to -std=gnu23.  A few tests are updated to remove local definitions of
>> bool, true and false (where making such an unconditional test change
>> seemed to make more sense than changing the test conditionally earlier
>> or building it with -std=gnu17); most test issues were already
>> addressed in previous patches.  In the case of
>> ctf-function-pointers-2.c, it was agreed in bug 117289 that it would
>> be OK to put -std=gnu17 in the test and leave more optimal BTF / CTF
>> output for this test as a potential future improvement.
>>
>> Since the original test fixes, more such fixes have become necessary
>> and so are included in this patch.  More noinline attributes are added
>> to simulate-thread tests where () meaning a prototype affected test
>> results, while gcc.dg/torture/pr117496-1.c (a test declaring a
>> function with () then calling it with arguments) gets -std=gnu17
>> added.
>>
>> Bootstrapped with no regressions for x86_64-pc-linux-gnu.
>
> Has anyone performed experiments to determine the impact of this change
> on typical free software distributions?

I filed https://gcc.gnu.org/PR117298 for an issue Joseph noticed in one
of the GCC tests (that is actually an improvement, but a missed opt for
older standards). I haven't done any sort of testing but am curious
about it as well.

I could do such a test for code size en-masse (and perhaps maybe even
check where the image changed at all). Runtime performance is far harder
for me to do at scale though. We can use significant code size changes
as a proxy for interesting candidates to investigate though.

What are you thinking of?

>
> Thanks,
> Florian

thanks,
sam

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

[Sam James via Gcc]

Andrew Pinski via Gcc  writes:

> On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc  
> wrote:
>>
>> Hello everyone.
>>
>> I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
>> originally done by Cupertino Miranda [2].
>>
>> I encountered issues compiling BPF objects for selftests/bpf with
>> recent GCC 15 snapshots. An additional test runner binary is supposed
>> to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
>> set to a directory with GCC binaries for BPF backend. The runner
>> binary depends on BPF binaries, which are produced by GCC.
>>
>> The first issue is compilation errors on vmlinux.h:
>>
>> In file included from progs/linked_maps1.c:4:
>> 
>> /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9: 
>> error: expected identifier before ‘false’
>>  8483 | false = 0,
>>   | ^
>>
>> A snippet from vmlinux.h:
>>
>> enum {
>> false = 0,
>> true = 1,
>> };
>>
>> And:
>>
>> 
>> /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15: 
>> error: two or more data types in declaration specifiers
>> 23539 | typedef _Bool bool;
>>   |   ^~~~
>>
>> Full log at [3], and also at [4].
>
>
> These are simple, the selftests/bpf programs need to compile with
> -std=gnu17 or -std=gnu11 since GCC has changed the default to C23
> which defines false and bool as keywords now and can't be redeclared
> like before.

Yes, the kernel has various issues like this:
https://lore.kernel.org/linux-kbuild/20241119044724.GA2246422@thelio-3990X/.

Unfortunately, not all the Makefiles correctly declare that they need
gnu11.

Clang will hit issues like this too when they change default to gnu23.

>
> Thanks,
> Andrew Pinski
>
>>
>> You can easily reproduce the errors with a dummy program:
>>
>> #include "vmlinux.h"
>>
>> int main() {
>> return 0;
>> }
>>
>> The vmlinux.h is generated from BTF, produced by pahole v1.28 from
>> DWARF data contained in the vmlinux binary. The vmlinux binary I used
>> in these experiments is v6.12 (adc218676eef) compiled with gcc 13.3.0
>> (default Ubuntu installation).
>>
>> You can download the specific vmlinux.h I tried using a link below [5].
>>
>> I bisected recent GCC snapshots and determined that the errors related
>> to the bool declarations started happening on GCC 15-20241117.
>>
>> Older versions compile the dummy program without errors, however on
>> attempt to build the selftests there is a different issue: conflicting
>> int64 definitions (full log at [6]).
>>
>> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
>>  from /usr/include/x86_64-linux-gnu/bits/socket.h:29,
>>  from /usr/include/x86_64-linux-gnu/sys/socket.h:33,
>>  from /usr/include/linux/if.h:28,
>>  from /usr/include/linux/icmp.h:23,
>>  from progs/test_cls_redirect_dynptr.c:10:
>> /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: error: 
>> conflicting types for ‘int64_t’; have ‘__int64_t’ {aka ‘long long int’}
>>27 | typedef __int64_t int64_t;
>>   |   ^~~
>> In file included from progs/test_cls_redirect_dynptr.c:6:
>> 
>> /ci/workspace/bpfgcc.20240922/lib/gcc/bpf-unknown-none/15.0.0/include/stdint.h:43:24:
>>  note: previous declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
>>43 | typedef __INT64_TYPE__ int64_t;
>>   |^~~
>>
>> This is on a typical ubuntu:noble system:
>>
>> $ dpkg -s libc6 | grep Version
>> Version: 2.39-0ubuntu8.3
>>
>> I got this with snapshots 15-20241110 and 15-20240922 (the oldest I
>> tested). This problem may or may not be present in the most recent
>> versions, I can't tell for sure.
>>
>> GCC team, please investigate and let me know if you're aware of
>> workarounds or if there is a specific GCC version that you know is
>> capable of building BPF programs in selftests/bpf.
>>
>> If you suspect something might be wrong with the includes for BPF
>> programs, or GCC snapshot build etc, please also let me know. I mostly
>> relied on Cupertino scripts when setting that up, and assumed the
>> selftests/bpf/Makefile is handling BPF_GCC correctly.
>>
>> Thank you, and happy holidays!
>>
>> [1] https://github.com/libbpf/ci/pull/164
>> [2] https://github.com/libbpf/ci/pull/144
>> [3] https://gist.github.com/theihor/98883c4266b3489cee69e5d5aa532e79
>> [4] https://github.com/libbpf/ci/actions/runs/12522053128/job/34929897322
>> [5] https://gist.github.com/theihor/785bb250dd1cce3612e70b5f6d258401
>> [6] https://gist.github.com/theihor/a8aa7201b30ac6b48df77bb1ea3ec0b2
>>
>>

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

[Sam James via Gcc]

Ihor Solodrai  writes:

> On Monday, December 30th, 2024 at 12:36 PM, Sam James  wrote:
>
>> 
>
>> 
>
>> Andrew Pinski via Gcc gcc@gcc.gnu.org writes:
>> 
>
>> > On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc gcc@gcc.gnu.org 
>> > wrote:
>> > 
>
>> > > Hello everyone.
>> > > 
>
>> > > I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
>> > > originally done by Cupertino Miranda [2].
>> > > 
>
>> > > I encountered issues compiling BPF objects for selftests/bpf with
>> > > recent GCC 15 snapshots. An additional test runner binary is supposed
>> > > to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
>> > > set to a directory with GCC binaries for BPF backend. The runner
>> > > binary depends on BPF binaries, which are produced by GCC.
>> > > 
>
>> > > The first issue is compilation errors on vmlinux.h:
>> > > 
>
>> > > In file included from progs/linked_maps1.c:4:
>> > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
>> > >  error: expected identifier before ‘false’
>> > > 8483 | false = 0,
>> > > | ^
>> > > 
>
>> > > A snippet from vmlinux.h:
>> > > 
>
>> > > enum {
>> > > false = 0,
>> > > true = 1,
>> > > };
>> > > 
>
>> > > And:
>> > > 
>
>> > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
>> > >  error: two or more data types in declaration specifiers
>> > > 23539 | typedef _Bool bool;
>> > > | ^~~~
>> > > 
>
>> > > Full log at [3], and also at [4].
>> > 
>
>> > These are simple, the selftests/bpf programs need to compile with
>> > -std=gnu17 or -std=gnu11 since GCC has changed the default to C23
>> > which defines false and bool as keywords now and can't be redeclared
>> > like before.
>> 
>
>> 
>
>> Yes, the kernel has various issues like this:
>> https://lore.kernel.org/linux-kbuild/20241119044724.GA2246422@thelio-3990X/.
>> 
>
>> Unfortunately, not all the Makefiles correctly declare that they need
>> gnu11.
>> 
>
>> Clang will hit issues like this too when they change default to gnu23.
>
> Andrew, Sam, thank you for a swift response.

Thank you for working on CI for this!

>
> vmlinux.h is generated code, so for the booleans perhaps it's more
> appropriate to generate a condition, for example:
>
> #if __STDC_VERSION__ < 202311L
> enum {
>   false = 0,
>   true = 1,
> };
> #endif
>
> Any drawbacks to this?
>

I think this is fine (enough), given the kernel isn't interested in using _Bool
as far as I know.

> Also if vmlinux was built with GCC C23 then I assume DWARF wouldn't
> contain the debug info for the enum, hence it wouldn't be present in
> vmlinux.h.
>
> I don't think downgrading the standard for a relatively new backend
> makes sense, especially in the context of CI testing.

The issue is that the kernel overall isn't yet worried about being built
as C23.

>
>> 
>
>> > [...]

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

[Sam James via Gcc]

Thomas Koenig via Gcc  writes:

> Hello world,
>
> looking at a few Fortran bug reports, I found some cases where
> it was not clear if the program in question was standard-conforming
> or not.  I would propose to add a keyword for that, tentatively
> called "interp".
>
> Comments? Suggestions for a different name?  Should I just go ahead
> and create it?

The discussion reminds me a bit of some of the issues raised in
https://shafik.github.io/c++/llvm/2024/10/17/triaging-clang-fronend-bugs.html.

"diverges-from" (-gcc, -msvc, we could have edg, etc), "extension:gnu", 
"extension:microsoft" are some that
LLVM uses.

thanks,
sam

Re: Announcement: GCC BPF is now being tested on BPF CI

[Sam James via Gcc]

Ihor Solodrai via Gcc  writes:

> On Friday, January 17th, 2025 at 2:44 AM, Jose E. Marchesi 
>  wrote:
>
>> [...]
>>
>> > Ok. I disabled the execution of the test_progs-bpf_gcc test runner for now.
>> > 
>> > I think we should check on the state of the tests again after decl_tags
>> > support is landed.
>> 
>> 
>> Thank you. Sounds like a plan :)
>> 
>> Is it possible to configure the CI to send an email to certain
>> recipients when the build of the selftests with GCC fails? That would
>> help us to keep an eye on the patches and either fix GCC or provide
>> advise on how to fix the selftest in case it contains bad C.
>
> In principle, yes. In practice email notifications are not that
> straightforward.
>
> Currently a BPF patch submitter gets a notification about the status
> of the CI pipeline for their patch. This makes sense, recipient is
> obvious in this case.
>
> In case of GCC (or any other CI dependency for that matter), it is
> necessary to determine the potential cause before sending
> notifications. There are all kinds of things that might have caused a
> failure independent of the target being tested: could be a bug in CI
> scripts, or github could have changed runner configuration, or a merge
> commit from (Linux) upstream broke something, etc.
>
> Point is, dependency maintainers (GCC team in this case) don't want to
> get notifications for *all* such failures, because you will have to
> ignore most of them, and so they become noise. A boy crying wolf kind
> of thing.
>
> The other issue is that maintaining email notifications is an
> operational overhead, meaning that the system managing the
> notifications needs to be looked after. Currently for BPF CI it's
> Kernel Patches Daemon instance maintained by Meta engineers [1].
>
> As it stands, if there is problem with GCC that affects BPF CI, you
> can be assured it'll be reported, because it will block the testing of
> the BPF patches.
>
> I suggest GCC BPF team to think about setting up your own automated
> testing infrastructure, focused on testing the GCC compiler. Maybe you
> already have something like that, I don't know. You certainly
> shouldn't rely exclusively on BPF CI for testing the BPF backend.

I think Jose is asking from the angle of wanting to make GCC support as
painless as possible for you upstream, not to ask you to provide a
substitute for our own CI. i.e. We don't want you to feel burdened by
providing that and we're happy to look into any problems as soon as they
arsie.

>
> [1] https://github.com/facebookincubator/kernel-patches-daemon
>
>> 
>> > Thanks.
>> > 
>> > [...]

Re: Announcement: GCC BPF is now being tested on BPF CI

[Sam James via Gcc]

Wonderful news! Massive thanks for working on this.

> but if there are specific people who should be notified
> please let me know.

Please feel free to include me on that list too.

Re: [Draft] GSoC 2025 Proposal: Implementing Clang's -ftime-trace Feature in GCC

[Sam James via Gcc]

Jakub Jelinek via Gcc  writes:

> On Tue, Mar 25, 2025 at 07:21:32AM +0300, Eldar Kusdavletov via Gcc wrote:
>> *Dear GCC Mentoring Team,*
>> I am writing to submit my proposal for the Google Summer of Code (GSoC)
>> 2025 program, aiming to contribute to the GCC project by implementing a
>> feature similar to Clang's -ftime-trace. This feature generates performance
>> reports detailing the compiler's time distribution across various
>> compilation phases, providing valuable insights for optimization.
>
> How is that different from GCC's -ftime-report or -ftime-report-details?
> We've been tracking the time spent by different compilation phases for the
> last 25 years...

-ftime-report* gives overall timings on phases, it does not give a
line-by-line breakdown alongside the user's code.

i.e. -ftime-trace helps to answer "which parts of my program are causing
slow compilation?"

See https://gcc.gnu.org/PR92396.

Re: GSOC interest in Extend the static analysis pass, [OpenACC]

[Sam James via Gcc]

Kaaden Ruman via Gcc  writes:

> Hello, my name is Kaaden and I am a student at the University of Alberta in 
> Canada. I am interested in pursuing the "Extend the static analysis pass" 
> idea as a medium size project. 
>
> I have cloned and built gcc and ran the testsuite and would like a
> nudge in the direction of what to look at next. I searched in bugzilla
> for terms like "OpenACC" and "static analysis". Bug 118627 looks like
> it might be a good candidate for a first patch. Any guidance on the
> former or suggestions for files that would be most helpful for me to
> read and try to understand would be greatly appreciated. I am open to
> any input.

Note that PR118627 is a report *using* static analysis (not GCC's static
analyzer, either). It's not a bug for enhancing GCC's static analyzer 
(-fanalyzer).

I'm afraid I don't have suggestions for this, though, and I defer to
Thomas and David.

>
> Also, I noticed that this link in the project idea description is dead: 
> https://mid.mail-archive.com/875yp9pyyx.fsf@euler.schwinge.homeip.net
>
> More about me, I have previous experience in compilers (and working in
> large codebases) from interning at IBM where I worked on their COBOL
> compiler and binary optimiser (mostly backend). I have also taken a
> compiler course with a project of an LLVM based compiler (mostly
> frontend).
>
> I also have taken and enjoyed a GPU programming course so extending
> checks for OpenACC caught my eye. In that course we mainly worked with
> CUDA but discussed other tools such as OpenACC as well, so I have some
> familiarity.
>
> Thanks,
> Kaaden

Re: [PATCH v2] gcc: do not apply store motion on loop with no exits.

[Sam James via Gcc]

ywgrit  writes:

> I encountered one problem with loop-im pass.
> I compiled the program dhry2reg which belongs to 
> unixbench(https://github.com/kdlucas/byte-unixbench).
>
> The gcc used
> gcc (GCC) 12.3.0
>
> The commands executed as following
> make
> ./Run -c -i 1 dhry2reg
>
> The results are shown below.
> Dhrystone 2 using register variables  0.1 lps   (10.0 s, 1 
> samples)
>
> System Benchmarks Partial Index  BASELINE   RESULTINDEX
> Dhrystone 2 using register variables 116700.0  0.1  0.0
>
> System Benchmarks Index Score (Partial Only)   10.0
>
> Obviously, the "INDEX" is abnormal.
> I wrote a demo named dhry.c based on the dhry2reg logic.

It's best to file a bug report so we can:
a) discuss the validity of the testcase, and
b) reference it in review of the commit & even once it is in

.. but that said, I thought this looked familiar, and I found PR117695
which is marked as INVALID.

> [...]

FWIW, all the analysis should go in the commit message, as well as
including a testcase in the commit itself. The commit message should
also have a ChangeLog. See these links:
* https://gcc.gnu.org/contribute.html
* https://gcc.gnu.org/codingconventions.html

But these are general remarks. I can't approve the patch (that is for
others) but I'm not sure if the testcase is valid anyway.

> [...]

thanks,
sam

Re: We need to remove the Sphinx HTML docs

[Sam James via Gcc]

Gerald Pfeifer  writes:

> On Tue, 4 Feb 2025, Jonathan Wakely wrote:
> :
>>> ./gnat_ugn/_static/
>>> ./libgccjit/_static/
>>> ./libgdiagnostics/_static/
>>> ./libgomp/_static/
> :
>> N.B. there's ./jit/_static which should stay, because jit still uses
>> sphinx for its docs.
>

I found 
https://gcc.gnu.org/onlinedocs/gccint/link-time-optimization/lto-file-sections.html
just now as well.

Re: We need to remove the Sphinx HTML docs

[Sam James via Gcc]

Gerald Pfeifer  writes:

> On Sat, 26 Apr 2025, Jonathan Wakely wrote:
>> $ grep -R  'generator.*Docutils' libgomp | wc -l
>> 136
>> $ grep -R  'generator.*Docutils' libitm | wc -l
>> 8
>> $ grep -R  'generator.*Docutils' gdc | wc -l
>> 7
>> $ grep -R  'generator.*Docutils' gfc-internals | wc -l
>> 4
>
> I yanked all these, including
>
>   _sources/ 
>   searchindex.js
>   objects.inv 
>
> in each of these subdirectories - further leftovers from Sphinx.
>
> Similarly I removed gdc/invoking-gdc/, 
> gfc-internal/generating-the-intermediate-language-for-later-stages/ ,
> and a couple of similiar subdirectories under libgomp/ where docs were 
> generated/stored.
>

Thanks Gerald. The
https://gcc.gnu.org/onlinedocs/gccint/link-time-optimization/lto-file-sections.html
page I mentioned above seems to still be there.

It looks like it should match the grep if run in a higher up directory:
https://docutils.sourceforge.io/"; />

sam

Re: Introduction & Interest in GCC Rust Frontend GSoC Project

[Sam James via Gcc]

Basile Starynkevitch  writes:

> Hello Bright Andoh,
>
>> 
>> My name is Bright Andoh, and I’m a Computer Engineering student at the
>> University of Alabama. I’m wrapping up my freshman year and have
>> experience working with Rust and C. Last fall, I collaborated on some
>> Rust projects with a friend, and I’m eager to deepen my understanding,
>> especially in compiler development and large codebases.
>> 
>
> Long time ago, I did contribute to GCC (its plugin infrastructure).
> https://arxiv.org/pdf/1109.0779 (perhaps this paper could be relevant to you)
>
> A possible approach to your goal might be:
>
> become familiar with GCC code base so be able to compile it (on a Linux
> computer) from source code. Be prepared to spend a few days on that.
>
> be able to run the GDB debugger on the GCC compiler (actually its cc1). Be
> prepared to spend a few days on that.
>
> study the source code of the existing Rust compiler 
> https://www.rust-lang.org/,
> only the front-end (e.g. macros & ownership things).
>
> Adapt it to GCC using libgccjit. This means understanding the current rust
> compiler internals and using libgccjit to feed GCC.
>
> https://gcc.gnu.org/onlinedocs/jit/
>
> so my suggestion could be to prototype your Rust frontend as a GCC plugin (and
> reuse as much as possible existing frontend from  https://www.rust-lang.org/)
>

I'm sorry, but this advice is mistaken/misplaced.

GCC *has* a rust frontend in-tree and it's one of our listed GSoC ideas
to help contribute to it at 
https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas.

Not only that, there is additionally a libgccjit backend for the
rust-lang.org implementation of rustc, see
https://github.com/rust-lang/rustc_codegen_gcc.

But this contributor is asking about the former.

> Be sure to put your experimental code on some publicly available website 
> (github
> or something else) for other to review it.
>
> BTW my current open source project is an inference engine, on
> https://github.com/RefPerSys/RefPerSys/
>
>
> Thanks

Re: GSOC: Guidance on LTO, and Static Analysis Projects

[Sam James via Gcc]

Yatindra Indoria via Gcc  writes:

> Hello,
>
> I am an engineering student. I’ve worked on high frequency trading systems,
> and (research) on the Linux kernel I/O and memory subsystems. I am looking
> to start contributing to GCC, for quite some time now, as my work utilises
> it extensively :)
>
> But GCC is complex, I believe the mentorship from GSOC will enable me to
> start. I have of course gone through the “Before you Apply” section (also
> built GCC, and executed test suite). I’d also like to mention that David’s
> newbie guide and Prof Uday Khedkar’s content have played a huge role in
> motivating me to apply.

Those are both excellent resources! David's guide especially helped me a lot.

>
> I wish to know what contributions I can make towards Link-Time
> Optimizations? It would be amazing if someone can point out who I should
> discuss this with.

You want Jan Hubicka (Honza) and Martin Jambor, CC'd.

>
> Additionally, I went through the linked issues in “Extend the static
> analysis pass” mentored by David Malcom. Refactoring the format-string
> logic will familiarise me with the GCC codebase. And my experience with
> Linux kernel and CPython APIs may come of use in integrating the checker
> there.
>
> I’m hence looking into both for now, and intend to decide as per the
> information I get for LTO hereon.

Thank you for your interest!

>
> Thanks and regards,
> Yatindra Indoria

Re: GSOC interest in Extend the static analysis pass

[Sam James via Gcc]

Basile Starynkevitch  writes:

> hello
>
> You could take (and improve/refactor) some obsolete code from
> https://github.com/bstarynk/bismon
> and read the below draft report
> http://www.starynkevitch.net/Basile/bismon-chariot-doc.pdf
>
> I am no more working on that code base.
>

Let's not suggest obsolete (or non-GCC) projects to people asking about
how to work on GCC itself for GSoC, please.

> My current open source project is https://github.com/RefPerSys/RefPerSys/ (an
> inference engine project, GPL licensed) which you could use to test/improve 
> your
> static analysis part.
>
> Be of course aware of https://frama-c.com/ (I was part of that team at www-
> list.cea.fr before my retirement in nov 2023)
>
> regards
>
> Regards.

Re: Current trunk fails to build gmp

[Sam James via Gcc]

Rainer Emrich  writes:

> Since some time in November last year trunk fails to build gmp.
> Last successfull build was 30th of October last year.
>
> The issue seems to be a failing configure test. From config.log:

Please see
https://gmplib.org/list-archives/gmp-bugs/2024-November/005550.html.

Building GMP with -std=gnu17 is a workaround.

Re: Proposed GSoC project to enhance the GCC GNAT Ada front end

[Sam James via Gcc]

Tucker Taft via Gcc  writes:

> Proposal: Google Summer of Code on GCC Ada Front end
>
>-
>
>Goal : Implement some of the light-weight parallelism features of Ada
>2022 in the GNAT front end
>-
>
>Contributor: Ethan Luis McDonough, PSU '2025 (
>ethanluismcdono...@gmail.com)
>-
>
>Mentors: S. Tucker Taft (Lexington, MA -- tucker.t...@gmail.com) and
>Richard Wai (Toronto, ON -- rich...@annexi-strayline.com)

I assume you're already aware, but just saying in case (better than
someone missing out): one must apply to Google's GSoC programme with
this proposal as well, and then the GCC GSoC administrators review the
proposals if Google accepts the proposal as a potential project.

(It does sound like an excellent project.)

Re: Generating compile_commands.json for GCC source code

[Sam James via Gcc]

Yuao Ma via Gcc  writes:

> Hello GCC developers,
> I am trying to generate a compile_commands.json file for the GCC source code. 
> This file is very useful for various development tools and IDE integrations.
> Since GCC uses a Makefile-based build system, I attempted to use bear 
> (https://github.com/rizsotto/Bear) to capture the compilation commands. My 
> workflow was as follows:

What version of bear did you use? You'll need >=3.1.6 as that contains
https://github.com/rizsotto/Bear/commit/c18c8eef1e74bd253302d57dbcf908394566d93b.

>
> ../configure --enable-languages=c,c++,fortran --disable-bootstrap 
> --disable-multilib
> bear -- make -j$(nproc)
>
>
> However, this approach did not produce the expected compile_commands.json 
> file with the correct compilation commands for the source files.

Did you get one generated at all? If so, what was missing, or what was
wrong with it?

Re: Review for gcc-15/changes.html

[Sam James via Gcc]

Heiko Eißfeldt  writes:

> Hi,
>
> here is a patch for some mostly minor typos in
> https://gcc.gnu.org/gcc-15/changes.html.
> My fixes might be wrong of course, so they are just suggestions.
>
> Also, the linked page https://gcc.gnu.org/gcc-15/porting_to.html
> contains the now outdated
> "Note: GCC 15 has not been released yet, so this document is a
> work-in-progress."
> which is luckily not true anymore.

Thanks for doing this. Do you plan to post an updated patch (ideally to
gcc-patches)?

>
> Greetings and thanks, Heiko
>
> [2. text/x-patch; Changes_Rel15.0.html.diff]...
>
> [3. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x6C5B5E2DE9D181E2.asc]...

Re: smtgcc mid-year update

[Sam James via Gcc]

Krister Walfridsson via Gcc  writes:

> I have continued working on my translation validator, smtgcc [1]. Here
> is an update of what I have done since the end-of-year update.
>
>
> smtgcc-tv-backend
> -
> The main focus has been improving the smtgcc-tv-backend tool which
> checks that the generated assembly is a refinement of the final GIMPLE
> IR.
>
> Highlights:
>  * Implemented most AArch64 SVE instructions
>  * Implemented most RISC-V vector instructions
>  * Improved performance
>
> There are still some limitations in the ABI support. This is not too
> problematic, as smtgcc reports "not implemented" instead of trying to
> analyze, so it avoids false positives. But it does restrict the range
> of code it can handle.
>
> The tool also still generates overly complicated SMT formulas for some
> common instructions, which makes tests time out unnecessarily.
>
>
> Add SMTGCC_ASM environment variable
> ---
> The smtgcc-tv-backend tool verifies that the generated assembly is a
> refinement of the final GIMPLE IR. It is now possible to override the
> file used for reading the assembly by setting the SMTGCC_ASM
> environment variable. This is useful for testing the implementation of
> smtgcc, but can also be used to verify hand-written assembly by
> letting smtgcc-tv-backend compare the GIMPLE from the C function
> against the provided assembly code instead of the compiler-generated
> output.
>
>
> Caching
> ---
> smtgcc can now cache SMT queries in a Redis database, and use the
> cached result when an identical query is submitted. This speeds up
> continuous testing of GCC a lot.
>
>
> GCC testing
> ---
> I am continuing with weekly runs of the GCC test suite. The testing is
> done with -fno-strict-aliasing and, for AArch64 and RISC-V,
> -fno-section-anchors, as type-based aliasing and section anchors are
> not yet supported by smtgcc.
>
> The tests are done on optimization levels:
>  * -O3
>  * -O2
>  * -Os
>  * -O1
>  * -O0
> and for the following target flags (where I typically only run a
> subset of targets each week):
>  * x86_64:
> - 
> - -march=x86-64-v2
> - -march=x86-64-v3
> - -march=x86-64-v4
> - -m32
>  * AArch64
> - 
> - -march=armv8.9-a
> - -march=armv9.5-a
>  * RISC-V
> - -march=rv64gcbv
> - -march=rv64gcv
> - -march=rv64gcb
> - -march=rv64gc
> - -march=rv32gcbv
> - -march=rv32gcv
> - -march=rv32gcb
> - -march=rv32gc
>
> Please let me know if there are additional configurations you would
> like me to include in the testing.
>

We sometimes get interesting bugs, especially with UBSAN
(-fsanitize=undefined), with SAVE_EXPR. PR120471 is one example and
PR120837 is another.

These two are FE issues though, so may not really be applicable.

It might be interesting to try -fhardened occasionally (which wraps up
several options that distributions build with).

I think anything that introduces instrumentation (so -fprofile-generate
may be another candidate, or in a sense, -fnon-call-exceptions) could be
interesting.

sam

Re: Switching x86-64 to GNU2 TLS descriptors

[Sam James via Gcc]

Florian Weimer  writes:

> * H. J. Lu:
>
>> Compilers will never know since the build-time glibc is independent of
>> the run-time glibc.   If compilers want to be 100% sure that the run-time
>> is GNU2 TLS bug-free, they can require linkers which generate the
>> GLIBC_ABI_GNU2_TLS dependency.
>
> (Such a linker requirement could be enforced by requiring that the
> linker recognizes a command option specific to GLIBC_ABI_GNU2_TLS, and
> that current linkers treat as an error.)
>
> Would such an unconditional requirement be acceptable to GCC 16?  I
> don't think so.  So we'd still have to design a configure option for it.
> And that requires further compiler changes.  It's also not entirely
> clear how this would interact with -fuse-ld.

Note that doing it automagically based on bfd version at configure-time
would be fine enough. We already did this for gas for .base64 in 15.

Is that good? Bad? I don't know, but there's precedent, and nobody died
when we did it.

-fuse-ld indeed makes it more complicated and we'd have to suppress it
for that, but my point is that the option isn't outlandish.

I'm still forming an opinion on the rest.

sam

Re: Could we enhance the ifcombine pass?

[Sam James via Gcc]

ywgrit via Gcc  writes:

> Sure, I'll give an example of the performance gains that can be gained with
> an ifcombine pass in the bugreport and cc you and Andrew Pinski on the
> email.

(Please file it on our Bugzilla.)