gcc-12-20230428 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20230428 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20230428/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 458bda5432d352469e258f1c0e4c2a37c853575a

You'll find:

 gcc-12-20230428.tar.xz   Complete GCC

  SHA256=a1d7281b58493ff316f5cb9817816abefbcbb09d3b8b75100c164cae1a67f727
  SHA1=48f3dd697b3ce38f5f3f54e7797a43ac861f15fe

Diffs from 12-20230421 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: can-be-null can-not-be-null break-instruction for better handling pointers.

[Christopher Bazley via Gcc]

Hi,

I agree with you that C would benefit from a new type qualifier to
indicate pointer nullability, although not with your suggestion that
such a qualifier should indicate the property cannot-be-null.

If you just want a syntax for declaring that a function parameter is
not a null pointer, C already supports that (with the same limitation
as for C++ references, that the type of the referenced object cannot
be void):

int get_vector_size(struct vector vec[static 1])
{
   return vec->size;
}

You can even implement the other behaviour of C++ references, which is
that they can only point to one object during their lifetime:

int get_vector_size(struct vector vec[const static 1])
{
   return vec->size;
}

In GCC, -Wnonnull is required to get a warning about passing null to
such a function, and (in my experience) it won't warn about
non-trivial cases where the null pointer isn't passed as an immediate
constant.

Regardless of what the language formally guarantees, most C source
code in the real world already assumes that pointers are not null in
the absence of information to the contrary. This assumption is
necessary, for example, because the first argument to every function
in a C language interface is typically a pointer which fulfils the
same role as 'this' (aka 'self') in an object-oriented language. You
will also see, if you study the C standard library, that functions
which have well-defined behaviour for null pointer values are in a
minority.

I recently wrote a paper on this topic, which proposes a new qualifier
as well as modified semantics for the unary & operator. This paper is
currently with the relevant ISO committee for consideration.

My related article on Medium examines a lot of prior art in the area,
as well as explaining why I think none of the existing solutions is
adequate: https://itnext.io/why-c-needs-a-new-type-qualifier-61ad553cbe71
The article contains links (at the end) to my paper, as well as to a
working prototype implementation of the functionality I propose
(albeit using Clang rather than GCC).

I previously posted on this mailing list to enquire about whether it
would be worthwhile to implement the same functionality in GCC, but
got slapped down. It seems to me that the era of compiler extensions
informing the language standardization process (rather than vice
versa) is over, but that's just my perception based on limited
feedback.

There's a reason why C programmers haven't replaced all of their 'int
*ip' pointer arguments with 'int ip[const static 1]' during the past
24 years, and I don't think they ever will. It doesn't resemble
Kernighan & Ritchie's "pleasant, expressive, and versatile" language
which featured "economy of expression". Nor does it conform to K&R's
intent that declaration syntax be mnemonic, since 'int ip[const static
1]' doesn't resemble anything: neither a pointer declaration in any
other context, nor a real array declaration, nor the syntax for array
usage in expressions.

Best regards,
-- 
Christopher Bazley

Re: libsanitizer: sync from master

[Bernhard Reutner-Fischer via Gcc]

On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran 
 wrote:
>* Martin Liška:

>But that's okay for me as well.

Even better.

Re: Hosting our gfortran MatterMost workspace

[Mark Wielaard]

Hi Jerry, Hi Andrew,

On Fri, Apr 28, 2023 at 09:16:12AM -0700, Andrew Pinski via Gcc wrote:
> On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran  
> wrote:
> >
> > Hello all and gcc overseers,
> >
> > I received a notice that the MasterMost server providers decided to drop
> > their free service. Unfortunate and understandable.
> >
> > I plan to contact the Open Software Lab folks at Oregon State University
> > to see if they can host for us.
> >
> > If anyone else has any suggestions of possible places we can host an
> > instance, please let me know.  The software for the platform is open
> > source many folks self host, so we can do this.
> >
> > I am not sure where gcc.gnu.org is hosted, but that might be a logical
> > place.
> 
> Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 .
> gcc.gnu.org is currently hosted as part of sourceware so ...

OSUOSL already provides some machines for sourceware/gcc. If you could
put a bit more technical details into that bugzilla issue, with expected usage
(how many people, groups, moderation?) then we can coordinate and put
it on the overseers agenda.

Thanks,

Mark

Re: Hosting our gfortran MatterMost workspace

[Andrew Pinski via Gcc]

On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran  wrote:
>
> Hello all and gcc overseers,
>
> I received a notice that the MasterMost server providers decided to drop
> their free service. Unfortunate and understandable.
>
> I plan to contact the Open Software Lab folks at Oregon State University
> to see if they can host for us.
>
> If anyone else has any suggestions of possible places we can host an
> instance, please let me know.  The software for the platform is open
> source many folks self host, so we can do this.
>
> I am not sure where gcc.gnu.org is hosted, but that might be a logical
> place.

Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 .
gcc.gnu.org is currently hosted as part of sourceware so ...

Thanks,
Andrew

>
> Best regards,
>
> Jerry

Hosting our gfortran MatterMost workspace

[Jerry D via Gcc]

Hello all and gcc overseers,

I received a notice that the MasterMost server providers decided to drop 
their free service. Unfortunate and understandable.


I plan to contact the Open Software Lab folks at Oregon State University 
to see if they can host for us.


If anyone else has any suggestions of possible places we can host an 
instance, please let me know.  The software for the platform is open 
source many folks self host, so we can do this.


I am not sure where gcc.gnu.org is hosted, but that might be a logical 
place.


Best regards,

Jerry

Re: GCC/Clang attributes guiding warnings about unused entities

[Stephan Bergmann via Gcc]

On 4/28/23 11:55, Florian Weimer wrote:

* Stephan Bergmann via Gcc:


[cross-posting this to both the GCC and Clang communities]


I don't see your post here:

   


I don't think this is expected to work from a Discourse point of view.


Yeah, that experiment apparently failed miserably, unfortunately.


* __attribute__((unused)) behaves mostly the same as [[maybe_unused]].

The one difference is that __attribute__((unused)) applied to a type
does not warn about that type being unused, but rather warns about
unreferenced variables of that type.  And it appears that both GCC and
Clang implement [[maybe_unused]] with the same semantics as
__attribute__((unused)), and cause [[maybe_unused]] applied to a type
to warn about unreferenced variables of that type.  The mailing list
thread starting at

"[[maybe_unused]] classes" discussed this, and argues that those
special semantics of __attribute__((unused)) and [[maybe_unused]]
applied to a type are not actually useful:  The GCC documentation
cites as a use case "lock or thread classes, which are usually defined
and then not referenced, but contain constructors and destructors that
have nontrivial bookkeeping functions".  But the presence of those
non-trivial con-/destructors will already prevent the compiler from
emitting warnings about seemingly unused variables of such types.  So
applying __attribute__((unused)) to such types looks like it does not
bring any additional value.  Or what do other people think?


Not sure if I quite understand this.  If the attribute cannot be used to
mark (indirectly) variables of type (say) std::string as worthy of
warnings if they are unused, I think these special cases are not useful.


Not sure if I in turn understand you here.  __attribute__((unused)) and 
[[maybe_unused]] are not meant to "mark [...] variables [...] as worthy 
of warnings if they are unused" anyway?



* __attribute__((warn_unused)) (which can be applied to class types)
   is meant to allow warnings about unreferenced variables of the given
   type, where the compiler could otherwise not infer that those
   variables are truely unused (because the type has non-trivial
   con-/destructors). (This attribute does not have a standard
  counterpart.)

Similarly to how [[nodiscard]] can be applied to individual
constructors, it looks beneficial to me to allow
__attribute__((warn_unused)) to be applied to individual constructors,
too.  One example use case is a RAII class that has one constructor
that does not acquire a resource (often the default constructor) and
another constructor that does acquire a resource.  So the class itself
cannot be marked __attribute__((warn_unused)).  But if the
non-acquiring constructor could individually be marked
__attribute__((warn_unused)), the compiler could warn about
unreferenced variables that are initialized via that constructor.
 "Allow
`__attribute__((warn_unused))` on individual constructors" would
implement that for Clang---but was met with some reservation for now,
due to the already somewhat confusing landscape of standard and
GCC/Clang-specific attributes guiding warnings about unused entities
as outlined in this post.  What do other people think about it?  Would
it be something that GCC would also want to implement?


How does this interact with deriving warn_unused for std::vector if T
is warn_unused?  That seems like a useful feature, and appears to
require that this is a type property, not a constructor property.


Applying __attribute__((warn_unused)) to types would still be possible. 
The only change would be that, in addition, also individual constructors 
can be marked __attribute__((warn_unused)) (to be used in cases where 
the whole class type can't be).


So this would be largely orthogonal to deriving warn_unused for 
std::vector from T.  (Do we even have such a feature?)  (One could, 
of course, envision an additional feature where warn_unused for the 
construction of a std::vector variable could be derived from whether 
the T constructors used to initialize all the individual vector elements 
are warn_unused.)



And maybe there is a trend to use constructor functions for these guard
variables and auto?  So

   auto g = make_guard(obj);

instead of:

   guard g(obj);


I'm not sure I understand what you want to bring up with this example. 
If guard(T) were a constructor that could benefit from being marked 
__attribute__((warn_unused)) (which it usually wouldn't be, though), 
then, yes, wrapping that in a make_guard function would generally stop 
the compiler from being able to warn about the unused variable g.  (As 
the knowledge which constructor had been used inside make_guard is 
generally lost at the point where the variable g is initialized; and not 
to mention intervening copy/move constructor invocations).


(Maybe, to make t

Re: GCC/Clang attributes guiding warnings about unused entities

[Florian Weimer via Gcc]

* Stephan Bergmann via Gcc:

> [cross-posting this to both the GCC and Clang communities]

I don't see your post here:

  


I don't think this is expected to work from a Discourse point of view.

> * __attribute__((unused)) behaves mostly the same as [[maybe_unused]].
>
> The one difference is that __attribute__((unused)) applied to a type
> does not warn about that type being unused, but rather warns about
> unreferenced variables of that type.  And it appears that both GCC and
> Clang implement [[maybe_unused]] with the same semantics as
> __attribute__((unused)), and cause [[maybe_unused]] applied to a type
> to warn about unreferenced variables of that type.  The mailing list
> thread starting at
> 
> "[[maybe_unused]] classes" discussed this, and argues that those
> special semantics of __attribute__((unused)) and [[maybe_unused]]
> applied to a type are not actually useful:  The GCC documentation
> cites as a use case "lock or thread classes, which are usually defined
> and then not referenced, but contain constructors and destructors that
> have nontrivial bookkeeping functions".  But the presence of those
> non-trivial con-/destructors will already prevent the compiler from
> emitting warnings about seemingly unused variables of such types.  So
> applying __attribute__((unused)) to such types looks like it does not
> bring any additional value.  Or what do other people think?

Not sure if I quite understand this.  If the attribute cannot be used to
mark (indirectly) variables of type (say) std::string as worthy of
warnings if they are unused, I think these special cases are not useful.

The assumption might be that compilers need to suppress warnings for
RAII guard variables, but GCC does not warn for them anyway.  This is
discussed occasionally, and the assumption is that such warnings would
not be useful.

> * __attribute__((warn_unused_result)) (which can only be applied to
>   functions) behaves the same as [[nodiscard]] applied to functions.

This is not entirely accurate because warn_unused_result is much harder
to suppress at the call site (at least in GCC).

> * __attribute__((warn_unused)) (which can be applied to class types)
>   is meant to allow warnings about unreferenced variables of the given
>   type, where the compiler could otherwise not infer that those
>   variables are truely unused (because the type has non-trivial
>   con-/destructors). (This attribute does not have a standard
>  counterpart.)
>
> Similarly to how [[nodiscard]] can be applied to individual
> constructors, it looks beneficial to me to allow
> __attribute__((warn_unused)) to be applied to individual constructors,
> too.  One example use case is a RAII class that has one constructor
> that does not acquire a resource (often the default constructor) and
> another constructor that does acquire a resource.  So the class itself
> cannot be marked __attribute__((warn_unused)).  But if the
> non-acquiring constructor could individually be marked
> __attribute__((warn_unused)), the compiler could warn about
> unreferenced variables that are initialized via that constructor.
>  "Allow
> `__attribute__((warn_unused))` on individual constructors" would
> implement that for Clang---but was met with some reservation for now,
> due to the already somewhat confusing landscape of standard and
> GCC/Clang-specific attributes guiding warnings about unused entities
> as outlined in this post.  What do other people think about it?  Would
> it be something that GCC would also want to implement?

How does this interact with deriving warn_unused for std::vector if T
is warn_unused?  That seems like a useful feature, and appears to
require that this is a type property, not a constructor property.

And maybe there is a trend to use constructor functions for these guard
variables and auto?  So

  auto g = make_guard(obj);

instead of:

  guard g(obj);

Thanks,
Florian

Re: libsanitizer: sync from master

[Florian Weimer via Gcc]

* Martin Liška:

> On 4/26/23 20:31, Florian Weimer wrote:
>> * Martin Liška:
>> 
>>> On 11/15/22 16:47, Martin Liška wrote:
 Hi.

 I've just pushed libsanitizer update that was tested on x86_64-linux and 
 ppc64le-linux systems.
 Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
 abidiff.
>>>
>>> Hello.
>>>
>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>> 
>> So … we have the issue that involves interceptors outside of libc.so.6,
>> namely crypt, crypt_r, and I posted an upstream patch for this:
>> 
>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>   
>> 
>> Can we just apply this downstream for now?  It blocks various folks from
>> using the sanitizers in their projects.
>
> Hello.
>
> Your upstream revision has been already accepted, so please apply it
> and I'm going to do one more merge from upstream in the following
> days. Does it work for you?

It's moving in a different direction now: 

But that's okay for me as well.

Thanks,
Florian

Re: GCC 13.1 Released

[Andrew Lilley via Gcc]

Download failed 3 times. Deleteing GCC


From: gcc-announce  on 
behalf of Richard Biener via gcc-announce 
Sent: 26 April 2023 09:20
To: gcc-annou...@gcc.gnu.org ; gcc@gcc.gnu.org 
; info-...@gnu.org 
Cc: Richard Biener 
Subject: GCC 13.1 Released

The GCC developers are proud to announce a new major GCC release, 13.1.

This release integrates a frontend for the Modula-2 language which
was previously available separately and lays foundation for a
frontend for the Rust language which will be available in a future
release.

Support for emitting the STABS debugging format was removed.  GCC
supports DWARF in almost all configurations.

The C frontend got support for several C23 features, the C++ frontend
for C++23 features.  The C++ standard library experimental support for
C++20 and C++23 was enhanced.  For the C family of languages you can now
use -fstrict-flex-arrays[=level] to control the behavior for the various
legacy forms of specifying flexible array members.

GCCs static analyzer has been greatly improved with 20 new diagnostic
kinds.

Link-time optimization now makes automatic use of GNU makes jobserver
when that supports named pipes which it does starting with version 4.4.
It is no longer required to alter makefiles.

Support for new CPU features in the ARM, x86 family, RISC-V and LoongArch
were added.  Notably RISC-V supports vector intrinsics as specified in
the 0.11 specification and OpenMP/OpenACC offloading to AMD Instinct MI200
series devices has been added.

Some code that compiled successfully with older GCC versions might require
source changes, see http://gcc.gnu.org/gcc-13/porting_to.html for
details.

See

  https://gcc.gnu.org/gcc-13/changes.html

for more information about changes in GCC 13.1.

This release is available from the WWW and FTP servers listed here:

 https://sourceware.org/pub/gcc/releases/gcc-13.1.0/
 https://gcc.gnu.org/mirrors.html

The release is in the gcc-13.1.0/ subdirectory.

If you encounter difficulties using GCC 13.1, please do not contact me
directly.  Instead, please visit http://gcc.gnu.org for information about
getting help.

Driving a leading free software project such as GCC would not be possible
without support from its many contributors.
Not only its developers, but especially its regular testers and users which
contribute to its high quality.  The list of individuals
is too large to thank individually!