Re: More C type errors by default for GCC 14

[Eric Gallager via Gcc]

On 5/15/23, Richard Earnshaw (lists) via Gcc  wrote:
> On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
>>> From: Arsen Arsenović 
>>> Cc: Eli Zaretskii , Jakub Jelinek ,
>>>   jwakely@gmail.com, gcc@gcc.gnu.org
>>> Date: Tue, 09 May 2023 22:21:03 +0200
>>>
 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.
>>>
>>> Both the GNU Toolchain and the GNU Toolchain users will benefit from a
>>> stricter toolchain.
>>>
>>> People can and have stopped using the GNU Toolchain due to lackluster
>>> and non-strict defaults.  This is certainly not positive for the brand,
>>> and I doubt it buys it much good will.
>>
>> It is not GCC's business to force developers of packages to get their
>> act together.  It is the business of those package developers
>> themselves.  GCC should give those developers effective and convenient
>> means of detecting any unsafe and dubious code and of correcting it as
>> they see fit.  Which GCC already does by emitting warnings.  GCC
>> should only error out if it is completely unable to produce valid
>> code, which is not the case here, since it has been producing valid
>> code for ages.
>>
>> It is a disservice to GCC users if a program that compiled yesterday
>> and worked perfectly well suddenly cannot be built because GCC was
>> upgraded, perhaps due to completely unrelated reasons.  It would be a
>> grave mistake on the part of GCC to decide that part of its mission is
>> to teach package developers how to write their code and when and how
>> to modify it.
>
> That argument doesn't really wash.  We already upgrade the 'default'
> language version (-std=...) from time to time and that can impact
> existing programs (eg we changed from gnu-inline to std-inline model).
>
> If this really isn't legal C, then my suggestion would be to tie this to
> a setting of -std, so -std=c2 would default to being more
> aggressive in enforcing this (via changing the warning to -werror=) and
> then -std=gnu2 might follow a bit behind that.
> Furthermore, we can trail this aggressively in release notes so that
> nobody can really claim to be surprised.
>

I support this plan for using -Werror= and having it be split based on
whether -std= is set to a strict ANSI option or a GNU option; is there
a way to do that in the optfiles, or would it have to be handled at
the specs level instead?

> At some point that std setting will become the default and the overall
> goal is achieved.
>
> R.
>

Re: [wish] Flexible array members in unions

[Qing Zhao via Gcc]

> On May 12, 2023, at 2:16 AM, Richard Biener via Gcc  wrote:
> 
> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc  wrote:
>> 
>> On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
>>> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
>>> 
 On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> On 5/11/23 18:07, Alejandro Colomar wrote:
> [...]
>> Would you allow flexible array members in unions?  Is there any
>> strong reason to disallow them?
 
 Yes please!! And alone in a struct, too.
 
 AFAICT, there is no mechanical/architectural reason to disallow them
 (especially since they _can_ be constructed with some fancy tricks,
 and they behave as expected.) My understanding is that it's disallowed
 due to an overly strict reading of the very terse language that created
 flexible arrays in C99.
>>> 
>>> Standard C has no such thing as a zero-size object or type, which would
>>> lead to problems with a struct or union that only contains a flexible
>>> array member there.
>> 
>> Ah-ha, okay. That root cause makes sense now.
> 
> Hmm. but then the workaround
> 
> struct X {
>  int n;
>  union u {
>  char at_least_size_one;
>  int iarr[];
>  short sarr[];
>  };
> };
> 
> doesn't work either.  We could make that a GNU extension without
> adverse effects?

I think that this might be  a very nice extension, which addresses the standard 
C’s restriction  on the zero-size object, and also can resolve kernel’s need. 
(And also other users’s similar programming need?)
And maybe it’s also possible to add such extension later to Standard C?

Similar as flexible array member in Standard C, we should limit such union as 
the last field of another structure.  (Since basically this union can be treated
As a flexible array member)

Qing

> 
> Richard.
> 
>> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
>> question is: what's needed to support the idea of a zero-sized object?
>> 
>> --
>> Kees Cook

Sourceware joins Software Freedom Conservancy

[Mark Wielaard]

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

After various discussions and lots of positive feedback [1] [2] [3] [4]
Software Freedom Conservancy and Sourceware proudly announce that
Sourceware today joins SFC as a member project!

As the fiscal host of Sourceware, Software Freedom Conservancy will
provide a home for fundraising, legal protection and governance that
will benefit all projects under Sourceware's care.  We share one mission:
developing, distributing and advocactingfor Software Freedom.  Together
we will offer a worry-free, friendly home for core toolchain and
developer tool projects.

We are happy to discuss this in #overseers on irc.libera.chat now
18:00-19:00 UTC. And we will also start regular Overseers Open Office
Hours every second Friday of the month on irc at the same time.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

To support the Software Freedom Conservancy, please become a Sustainer
https://sfconservancy.org/sustainer

You can also donate directly to Sourceware:
https://sfconservancy.org/members/current/#Sourceware
as a directed donation (mention Sourceware in the comment or memo line)

See https://sfconservancy.org/donate/ for other ways to donate.

[1] https://sourceware.org/pipermail/overseers/2022q3/018802.html
[2] https://sourceware.org/pipermail/overseers/2022q3/018804.html
[3] https://sourceware.org/pipermail/overseers/2022q3/018834.html
[4] 
https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

Sourceware, one of the longest standing Free Software hosting platforms,
joins SFC

Important Free Software infrastructure project finds non-profit home

   May 15, 2023

   As a home for Free Software projects since 1998, Sourceware is a
   keystone in Free Software infrastructure. For almost 25 years
   Sourceware has been the long-time home of various core toolchain
   project communities. Projects like Cygwin, a UNIX API for Win32
   systems, the GNU Toolchain, including GCC, the GNU Compiler Colection,
   two C libraries, glibc and newlib, binary tools, binutils and elfutils,
   debuggers and profilers, GDB, systemtap and valgrind. Sourceware also
   hosts standard groups like gnu-gabi and the DWARF Debugging Standard.
   See the full list project hosted and services provided on the
   [1]Sourceware projects page.

   Becoming an SFC member project will improve future operations carried
   out by dedicated volunteers to and furthering the mission of Free
   Software hosting. This will accelerate the Sourceware [2]technical
   roadmap to improve and modernize the infrastructure.

   As the fiscal host of Sourceware, Software Freedom Conservancy will
   provide a home for fundraising, legal assistance and governance that
   will benefit all projects under Sourceware's care. We share one
   mission: developing, distributing and advocating for Software Freedom.
   And to offer a worry-free, friendly home for Free Software communities.
   We see a bright future working together. With Conservancy as fiscal
   sponsor, Sourceware will also be able to fundraise and have the
   community of volunteers work together with paid contractors and enter
   into contracts for managed infrastructure where appropriate.

   SFC looks to Sourceware's years of experience in providing outstanding
   infrastructure as an inspiration for improving the Free Software
   ecosystem both for other SFC projects, and also in furthering SFC's
   mission around campaigns to promote Software Freedom Infrastructure.
   For decades, Sourceware has shown that hosting Free Software projects
   with Free Software infrastructure is not only possible, but helps
   create and fosters the growth of relationships and networks within the
   Free Software communities. SFC is thrilled to join the powerful history
   of demonstrable experience to grow hosting options that are 100% free
   software, in the future to bring in new ideas, communities, and
   projects!

   Projects hosted by Sourceware are part of the core toolchain for
   GNU/Linux distros, embedded systems, the cloud and, through Cygwin,
   Windows. Back in 1984 Ken Thompson's Reflections on Trusting Trust
   already described how making the source code for these tools available
   is essential to create what today we call secure software supply
   chains. Sourceware provides robust infrastructure and services for
   projects to adopt secure collaboration and release policies. We forsee
   future cooperation with other Conservancy member projects, such as the
   [3]Reproducible Builds project which provides an
   independently-verifiable path to supply chain security. Additionally,
   Sourceware will leverage Conservancy advisory role in how community
   projects are impacted by and can comply with regulations l

Re: For GCC, newlib combined tree, newlib build-tree testing, use standard search paths

[Jeff Johnston via Gcc]

Sounds fine Thomas.  Thanks.

-- Jeff J.

On Mon, May 15, 2023 at 4:01 AM Thomas Schwinge 
wrote:

> Hi!
>
> On 2023-05-08T21:50:56+0200, I wrote:
> > Ping: OK to push to newlib main branch the attached
> > "For GCC, newlib combined tree, newlib build-tree testing, use standard
> search paths"?
> > Or, has anybody got adverse comments/insight into this?
>
> Given that nobody has any comments, I'll push this later this week.
> (..., and be available to address any issue this, unlikely, may cause.)
>
>
> Grüße
>  Thomas
>
>
> > On 2023-04-14T22:03:28+0200, I wrote:
> >> Hi!
> >>
> >> OK to push to newlib main branch the attached
> >> "For GCC, newlib combined tree, newlib build-tree testing, use standard
> search paths"
> >> -- or is something else wrong here, or should this be done differently?
> >> (I mean, I'm confused why this doesn't just work; I'm certainly not the
> >> first person to be testing such a setup?)
> >>
> >> I'm not doing anything special here: just symlink 'newlib' into the GCC
> >> source directory, build the combined tree, and then run 'make check', as
> >> mentioned in the attached Git commit log.
> >>
> >>
> >> Grüße
> >>  Thomas
>
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
> Registergericht München, HRB 106955
>

Re: More C type errors by default for GCC 14

[Richard Earnshaw (lists) via Gcc]

On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote:

On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:

One fairly big GCC-internal task is to clear up the C test suite so that
it passes with the new compiler defaults.  I already have an offer of
help for that, so I think we can complete this work in a reasonable time
frame.


I'd prefer to keep at least significant portion of those tests as is with
-fpermissive added (plus of course we need new tests that verify the errors
are emitted), so that we have some testsuite coverage for those.


Whilst there is historical precedent for -fpermissive, I have to say 
that I don't like it.  The problem is that it is too imprecise as to 
what it means (and changes over time).  It also becomes the lazy way to 
paper over the problems being exposed and, in future, may mean that 
other (perhaps more important) issues that are detectable will be 
silently ignored if it becomes widely used.


R.

Re: More C type errors by default for GCC 14

[Michael Matz via Gcc]

Hello,

On Fri, 12 May 2023, Florian Weimer wrote:

> * Alexander Monakov:
> 
> > This is not valid (constraint violation):
> >
> >   unsigned x;
> >
> >   int *p = &x;
> >
> > In GCC this is diagnosed under -Wpointer-sign:
> >
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
> 
> Thanks for the reference.  I filed:
> 
>   -Wpointer-sign must be enabled by default
>   

Can you please not extend the scope of your proposals in this thread but 
create a new one?

(FWIW: no, this should not be an error, a warning is fine, and I actually 
think the current state of it not being in Wall is the right thing as 
well)


Ciao,
Michael.

Re: More C type errors by default for GCC 14

[Michael Matz via Gcc]

Hello,

On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote:

> On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > > One fairly big GCC-internal task is to clear up the C test suite so that
> > > it passes with the new compiler defaults.  I already have an offer of
> > > help for that, so I think we can complete this work in a reasonable time
> > > frame.
> 
> I'd prefer to keep at least significant portion of those tests as is with
> -fpermissive added (plus of course we need new tests that verify the errors
> are emitted), so that we have some testsuite coverage for those.

Yes, this!  Try to (!) never change committed testcase souces, however 
invalid they may be (changing how they are compiled, including by 
introducing new dg-directives and using them in comments, is of course 
okay).

(And FWIW: I'm fine with Florians proposal.  I personally think the 
arguments for upgrading the warnings to errors are _not_ strong enough, 
but I don't think so very strongly :) )


Ciao,
Michael.

Re: More C type errors by default for GCC 14

[Richard Earnshaw (lists) via Gcc]

On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:

From: Arsen Arsenović 
Cc: Eli Zaretskii , Jakub Jelinek ,
  jwakely@gmail.com, gcc@gcc.gnu.org
Date: Tue, 09 May 2023 22:21:03 +0200


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.


Both the GNU Toolchain and the GNU Toolchain users will benefit from a
stricter toolchain.

People can and have stopped using the GNU Toolchain due to lackluster
and non-strict defaults.  This is certainly not positive for the brand,
and I doubt it buys it much good will.


It is not GCC's business to force developers of packages to get their
act together.  It is the business of those package developers
themselves.  GCC should give those developers effective and convenient
means of detecting any unsafe and dubious code and of correcting it as
they see fit.  Which GCC already does by emitting warnings.  GCC
should only error out if it is completely unable to produce valid
code, which is not the case here, since it has been producing valid
code for ages.

It is a disservice to GCC users if a program that compiled yesterday
and worked perfectly well suddenly cannot be built because GCC was
upgraded, perhaps due to completely unrelated reasons.  It would be a
grave mistake on the part of GCC to decide that part of its mission is
to teach package developers how to write their code and when and how
to modify it.


That argument doesn't really wash.  We already upgrade the 'default' 
language version (-std=...) from time to time and that can impact 
existing programs (eg we changed from gnu-inline to std-inline model).


If this really isn't legal C, then my suggestion would be to tie this to 
a setting of -std, so -std=c2 would default to being more 
aggressive in enforcing this (via changing the warning to -werror=) and 
then -std=gnu2 might follow a bit behind that. 
Furthermore, we can trail this aggressively in release notes so that 
nobody can really claim to be surprised.


At some point that std setting will become the default and the overall 
goal is achieved.


R.

RISC-V V C Intrinsic API v1.0 release meeting reminder (May 15th, 2023)

[Eop Chen via Gcc]

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 is going to
be held later on 2023/05/15 7AM (GMT -7) / 10PM (GMT +8).

The agenda can be found in the second page of the meeting slides (link 
).
Please join the calendar to be constantly notified - Google calender link 
,
 ICal 

We also have a mailing list now hosted by RISC-V International (link 
).

Regards,

eop Chen

GCC 11.3.1 Status Report (2023-05-15)

[Jakub Jelinek via Gcc]

Status
==

The gcc-11 branch is open for regression and documentation fixes.

It's time to do the annual release from the branch, GCC 12.4.
I'd like to make the first release candidate on Monday, May 22nd,
and a release one week later if all goes well.

Please look through bugzilla and see which of your regression fixes
for GCC 12 are also applicable for the GCC 11 branch and do the
necessary backporting.  GCC 10.5 release will follow afterwards.


Quality Data


Priority  #   Change from last report
---   ---
P10
P2  489   +  61
P3   60   +   5
P4  214   -  18
P5   24   -   2
---   ---
Total P1-P3 549   +  66
Total   787   +  46


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2022-April/238572.html

Re: For GCC, newlib combined tree, newlib build-tree testing, use standard search paths

[Thomas Schwinge]

Hi!

On 2023-05-08T21:50:56+0200, I wrote:
> Ping: OK to push to newlib main branch the attached
> "For GCC, newlib combined tree, newlib build-tree testing, use standard 
> search paths"?
> Or, has anybody got adverse comments/insight into this?

Given that nobody has any comments, I'll push this later this week.
(..., and be available to address any issue this, unlikely, may cause.)


Grüße
 Thomas


> On 2023-04-14T22:03:28+0200, I wrote:
>> Hi!
>>
>> OK to push to newlib main branch the attached
>> "For GCC, newlib combined tree, newlib build-tree testing, use standard 
>> search paths"
>> -- or is something else wrong here, or should this be done differently?
>> (I mean, I'm confused why this doesn't just work; I'm certainly not the
>> first person to be testing such a setup?)
>>
>> I'm not doing anything special here: just symlink 'newlib' into the GCC
>> source directory, build the combined tree, and then run 'make check', as
>> mentioned in the attached Git commit log.
>>
>>
>> Grüße
>>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From e56b38625929c3cf62c71d3fbd9264aaeef39d0c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 14 Apr 2023 21:26:32 +0200
Subject: [PATCH] For GCC, newlib combined tree, newlib build-tree testing, use
 standard search paths

For example, for GCC/GCN target (AMD GPUs), target libraries are built
individually per supported hardware ISA ('-march=[...]').  Testing such a
toolchain via, for example:

$ make RUNTESTFLAGS='--target_board=[...]/-march=gfx90a' check[...]

... does work fine for all 'check-gcc-[...]' as well as GCC-provided target
libraries, 'check-target-[...]'.  Just for 'check-target-newlib', for the
example above, not the '-march=gfx90a' newlib libraries are linked in, but
instead always the default ones, which results in link FAILure.  This is cured
simply by skipping use of 'newlib/testsuite/lib/flags.exp', so that the
standard search paths as determined by GCC, DejaGnu are used for newlib, too.
---
 newlib/testsuite/lib/flags.exp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/newlib/testsuite/lib/flags.exp b/newlib/testsuite/lib/flags.exp
index e1e9acb18..697291e7a 100644
--- a/newlib/testsuite/lib/flags.exp
+++ b/newlib/testsuite/lib/flags.exp
@@ -4,6 +4,13 @@
 # is freely granted, provided that this notice is preserved.
 #
 
+if [info exists env(XGCC_FLAGS_FOR_TARGET)] {
+verbose "GCC, newlib combined tree, build-tree testing; using standard search paths"
+# ... instead of the search paths built here, based on 'objdir' as set in
+# newlib's 'site.exp', which always points to the default multilib.
+return
+}
+
 # flags.exp: overrides the dejagnu versions of libgloss_link_flags,
 # newlib_link_flags, and newlib_include_flags.
 
-- 
2.25.1