Re: Meaning of flag_pic

[Jakub Jelinek via Gcc]

On Thu, Sep 26, 2024 at 11:20:15PM +0200, Enrico via Gcc wrote:
> I am trying to understand how 'flag_pic' works.
> It is used extensively in TARGET_OPTION_OVERRIDE functions in the form 'if
> (flag_pic) ... '.
> The flags fPic and fpic have a default value of -1, so as far as I
> understand, if the two flags are not set in the command line, all 'if
> (flag_pic)' will be true because of the default value -1 (since I can see
> that flag_pic is a define to global_options.x_flag_pic)
> 
> It doesn't look correct to me, but this test is used so many times that I
> am sure I am missing something.

Yes, you are missing gcc/opts.cc (finish_options)
  if (!opts->x_flag_opts_finished)
{
  /* We initialize opts->x_flag_pie to -1 so that targets can set a
 default value.  */
  if (opts->x_flag_pie == -1)
{
  /* We initialize opts->x_flag_pic to -1 so that we can tell if
 -fpic, -fPIC, -fno-pic or -fno-PIC is used.  */
  if (opts->x_flag_pic == -1)
opts->x_flag_pie = (opts->x_flag_hardened
? /*-fPIE*/ 2 : DEFAULT_FLAG_PIE);
  else
opts->x_flag_pie = 0;
}
  /* If -fPIE or -fpie is used, turn on PIC.  */
  if (opts->x_flag_pie)
opts->x_flag_pic = opts->x_flag_pie;
  else if (opts->x_flag_pic == -1)
opts->x_flag_pic = 0;
  if (opts->x_flag_pic && !opts->x_flag_pie)
opts->x_flag_shlib = 1;
  opts->x_flag_opts_finished = true;
}
The -1 value just means the state of this option hasn't been finalized yet.

Jakub

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

[Jakub Jelinek via Gcc]

On Thu, Sep 12, 2024 at 06:09:53PM +0200, Jose E. Marchesi via Gcc wrote:
> - "noreturn" and jump tables run-time hints
> 
>   It has been expressed on the kernel side the desire of having the C compiler
>   emit run-time hints marking functions that are not supposed to return and
>   also to provide annotations on jump tables.  This is for the benefit of
>   objtool in arm64, see references below.
> 
>   Goal of the discussion:
> 
>   Collect and assess the requirements of these features, discuss their
>   pertinence and the way it could be best implemented.  The outcome of the
>   discussion will then be used to continue the discussion with the clang/llvm
>   and kernel hackers at LPC.
> 
>   References:
>   
> https://lore.kernel.org/linux-arm-kernel/yylmhuxtuanza...@hirez.programming.kicks-ass.net/

What I was suggesting is something like (completely untested, GPL v2.0+ in
case you'd like to use anything from that):
#include "gcc-common.h"

__visible int plugin_is_GPL_compatible;

static struct plugin_info mark_noreturn_plugin_info = {
.version= PLUGIN_VERSION,
.help   = "mark noreturn plugin\n",
};

static unsigned int mark_noreturn_execute(void)
{
if (flags_from_decl_or_type(current_function_decl) & ECF_NORETURN) {
const char *name = 
IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(current_function_decl));
name = targetm.strip_name_encoding(name);
name = concat("__noreturn_function.", name, NULL);
tree decl = build_decl(UNKNOWN_LOCATION, FUNCTION_DECL,
   get_identifier(name), 
TREE_TYPE(current_function_decl));
DECL_ARTIFICIAL(decl) = 1;
TREE_PUBLIC(decl) = 0;
DECL_WEAK(decl) = DECL_WEAK(current_function_decl);
assemble_alias(current_function_decl, decl);
}
return 0;
}

#define PASS_NAME mark_noreturn

#define NO_GATE

#include "gcc-generate-gimple-pass.h"

__visible int plugin_init(struct plugin_name_args *plugin_info, struct 
plugin_gcc_version *version)
{
int i;
const char * const plugin_name = plugin_info->base_name;
const int argc = plugin_info->argc;
const struct plugin_argument * const argv = plugin_info->argv;
bool enable = true;

PASS_INFO(mark_noreturn, "optimized", 0, PASS_POS_INSERT_BEFORE);

if (!plugin_default_version_check(version, &gcc_version)) {
error(G_("incompatible gcc/plugin versions"));
return 1;
}

for (i = 0; i < argc; ++i) {
if (!strcmp(argv[i].key, "no-mark-noreturn")) {
enable = false;
continue;
}
error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, 
argv[i].key);
}

register_callback(plugin_name, PLUGIN_INFO, NULL, 
&mark_noreturn_plugin_info);

if (!enable)
return 0;

#if BUILDING_GCC_VERSION < 6000
register_callback(plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL, 
&mark_noreturn_pass_info);
#endif

return 0;
}

Basically just create a __noreturn_function.foobarbaz alias to foobarbaz
function if that function is noreturn.  Haven't investigated if all Linux
kernel arches will be happy with . in the name, other options are $ or
_ or conditionally one of them e.g. based on NO_DOT_IN_LABEL/NO_DOLLAR_IN_LABEL
macros.

> - Struct layout randomization (-frandomize-struct-layout) and debug info
> 
>   The GCC plugin hooks in a way that emitted debug info doesn't match with the
>   resulting randomized structs.  It works in clang because it generates DWARF
>   later in the compilation process.
> 
>   References:
> 
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
> 
>   Goal of the discussion:
> 
>   Determine how to best fix this in the plugin, or by using a different
>   approach.  The outcome of the discussion will then be used to continue the
>   discussion with the clang/llvm and kernel hackers at LPC.
> 
> - Userland stack unwinding from within the Linux kernel
> 
>   There are reasons for wanting to unwind both userland and kernel
>   stacks from within the kernel.  Currently the kernel can unwind kernel
>   stacks based on ORC (which is revese-engineered from kernel compiled
>   objects by objtool) and userland stacks provided stack frame pointers
>   are present.  SFrame is a format similar to ORC, but general enough to
>   be used in userspace, and there is an on-going effort to introduce a
>   SFrame based unwinder in the kernel.  This will require some glibc
>   support as well.
> 
>   References:
> 
>   First prototype (V1) from Josh Poimboeuf:
>   https://lkml.kernel.org/lkml/cover.1699487758.git.jpoim...@kernel.org/

As discussed, either submit a patch to add another plugin callback event
after a new structure is almost ready to be finali

Re: Promote -Wno-sizeof-array-argument to an error

[Jakub Jelinek via Gcc]

On Fri, Aug 09, 2024 at 03:42:06PM +0200, Jakub Jelinek via Gcc wrote:
> On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote:
> > The problem with that is that the error will still be enforced _after_
> > GCC would change the behavior of sizeof(aparam).
> 
> I don't think it should unless C2Y requires that.
> 
> > Admittedly, I could write configure checks to determine if I have a
> > version of GCC where sizeof(aparam) is bad and only enable the error
> > there.
> > 
> > > but there is nothing wrong about using sizeof on function
> > > argument with array type if you know what you're doing,
> > 
> > I have doubts here.  Does anyone have an idea of what kind of program
> > would be interested in that value?
> 
> Any time you use some macro on such parameters where the macro internals use
> sizeof for whatever reason.
> E.g. if it wants to cast the pointer to some integer type and decides based
> on sizeof what integer type that would be, ...
> I mean, what you are suggesting is similar to making an error from
> sizeof (char), that is by definition 1, so there is no point for users to
> use it.  It makes sense in macros...

E.g. consider GCC
#define iterative_hash_object(OB,INIT) iterative_hash (&OB, sizeof (OB), INIT)
macro.
If one uses it on the function parameters declared as arrays but turned into
pointers and you know what you are doing, why not.
If using sizeof in that case is an error, you'd need to know, I can use this
macro on everything except this special case.

Jakub

Re: Promote -Wno-sizeof-array-argument to an error

[Jakub Jelinek via Gcc]

On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote:
> The problem with that is that the error will still be enforced _after_
> GCC would change the behavior of sizeof(aparam).

I don't think it should unless C2Y requires that.

> Admittedly, I could write configure checks to determine if I have a
> version of GCC where sizeof(aparam) is bad and only enable the error
> there.
> 
> > but there is nothing wrong about using sizeof on function
> > argument with array type if you know what you're doing,
> 
> I have doubts here.  Does anyone have an idea of what kind of program
> would be interested in that value?

Any time you use some macro on such parameters where the macro internals use
sizeof for whatever reason.
E.g. if it wants to cast the pointer to some integer type and decides based
on sizeof what integer type that would be, ...
I mean, what you are suggesting is similar to making an error from
sizeof (char), that is by definition 1, so there is no point for users to
use it.  It makes sense in macros...

Jakub

Re: Promote -Wno-sizeof-array-argument to an error

[Jakub Jelinek via Gcc]

On Fri, Aug 09, 2024 at 02:19:26PM +0200, Alejandro Colomar via Gcc wrote:
> On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote:
> > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar:
> > > Hi Martin,
> > > 
> > > Can we promote -Wno-sizeof-array-argument to a hard error?  I don't
> > > think there's any legitimate use sizeof() on such a parameter.
> > 
> > I am a bit worried that it might prevent people from adding size information
> > to arguments, by transforming later use of sizeof on such a pointer argument
> > into a hard error.
> 
> I've been thinking about it, and I'm not convinced.
> 
> 
> If we don't have an error, at some point, sizeof(array_param) would
> change meaning without prior notice.  If a program uses that new
> feature, it will silently compile in older compiler versions, producing
> bogus results.  To prevent that, the configure scripts would need to
> test the compiler and reject compilers that have the old behavior.
> 
> However, if we introduce a mandatory compiler error, programs won't need
> to be careful about the feature.  If the compiler supports it, it will
> compile, and if it doesn't, it will fail.
> 
> 
> Since I don't see any legitimate uses of sizeof(aparam) as of today, I
> don't expect having any consequences on existing code.  (But please
> point me wrong if there are any, maybe in generic macros.)
> 
> 
> What do you think?

You can compile your sources with -Werror=sizeof-array-argument if you want
it to be an error, but there is nothing wrong about using sizeof on function
argument with array type if you know what you're doing, and sizeof should be
usable on anything that has a size, not on everything except this special
case, so please don't enforce it on others.

Jakub

GCC 14.2 Released

[Jakub Jelinek via Gcc]

The GNU Compiler Collection version 14.2 has been released.

GCC 14.2 is a bug-fix release from the GCC 14 branch
containing important fixes for regressions and serious bugs in
GCC 14.1 with more than 102 bugs fixed since the previous release.

This release is available from the FTP servers listed here:

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

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Second GCC 14.2 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The second release candidate for GCC 14.2 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240729/
 ftp://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240729/

and shortly its mirrors.  It has been generated from git commit
r14-10521-gda7f0be91e2ae15.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 14.2 on Thursday, Aug 1st.

GCC 14.2 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The first release candidate for GCC 14.2 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/
 ftp://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/

and shortly its mirrors.  It has been generated from git commit
r14-10504-ga544898f6dd6a16.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 14.2 on Tuesday, Jul 30th.

Re: GCC 14.1.1 Status Report (2024-07-11)

[Jakub Jelinek via Gcc]

On Sun, Jul 14, 2024 at 08:07:02PM +0800, LIU Hao via Gcc wrote:
> 在 2024-07-11 15:56, Jakub Jelinek via Gcc 写道:
> > Status
> > ==
> > 
> > The gcc-14 branch is open for regression and documentation fixes.
> > 
> > It's time to plan for a GCC 14.2 release which should follow
> > roughly two to three months after the .1 release.  The plan is
> > to do a release candidate for GCC 14.2 on Tuesday, Jul 23rd
> > with the release following a week after that on Tuesday, Jul 30th.
> > 
> > That leaves some (but not plenty) of time to backport regression fixes
> > from trunk.  Please make sure to go over the list of your assigned
> > bugreports and consider backporting where that seems safe.
> 
> Would you please take a look at PR115049 and decide whether it should block
> the release? Although this issue is reported about mingw-w64, I suspect
> Linux may be affected too.

A blocker for GCC 14.2 is by definition a bug which didn't exist in GCC 14.1
and was only introduced after the release.  That from the PR doesn't seem to
be the case.
And it must affect primary targets (which this one doesn't either).
The bug doesn't even have bisection where it started, it feels like it is a
bug that existed for years on Windows and on the testcase was just
unfortunate enough that it started triggerring in 14.x.
-fipa-ra is more than 9 years old, and I don't see recent changes to
decl_binds_to_current_def_p/default_binds_local_p* in the last 9 years
(except for ifuncs which aren't involved in the testcase and Windows doesn't
support).  i386_pe_binds_local_p has been changed more recently, 8 years
ago.  So, if it is not correct for mingw, the fix would most likely go to
i386_pe_binds_local_p.

Jakub

GCC 14.1.1 Status Report (2024-07-11)

[Jakub Jelinek via Gcc]

Status
==

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

It's time to plan for a GCC 14.2 release which should follow
roughly two to three months after the .1 release.  The plan is
to do a release candidate for GCC 14.2 on Tuesday, Jul 23rd
with the release following a week after that on Tuesday, Jul 30th.

That leaves some (but not plenty) of time to backport regression fixes
from trunk.  Please make sure to go over the list of your assigned
bugreports and consider backporting where that seems safe.


Quality Data


Priority  #   Change from last report
---   ---
P10
P2  603-   2
P3  125+  53
P4  211-   6
P5   24-   1
---   ---
Total P1-P3 728+  51
Total   963+  44


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2024-May/243920.html

Re: WG14 paper for removing restrict from nptr in strtol(3)

[Jakub Jelinek via Gcc]

On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > > restrict, as of what -Wrestrict warns about, seems a reasonable
> > > thing.
> > > 
> > > How about a [[gnu::restrict()]] attribute, similar to
> > > [[gnu::access()]],
> > > which is simpler than the qualifier?  Since restrict is only
> > > meaningful
> > > in function boundaries, it would make sense to have a function
> > > attribute.  We don't want a qualifier that must follow discarding
> > > rules.
> > 
> > If it doesn't have the same meaning as "restrict" then perhaps call the
> > proposed attribute something other than "restrict"?
> 
> Yup, I was thinking that maybe noalias is a better name.

Name is one thing, but you'd also need to clearly define what it means.
When restrict is access based, it is clear what it means.

If you want something else which is not based on accesses and which should
allow warnings in the callers, I suppose you need to specify not just the
pointer but the extent as well (and maybe stride) or that it is an '\0'
terminated string, because if you want to say that for
void foo (char *, const char *, int);
the 2 pointers don't really alias, the size information is missing.  So,
shall the new warning warn on
struct S { char a[1024]; char b[1024]; } s;
foo (s.a, s.b, 512);
or not?  Or foo (s.a, s.a + 512, 512);

Jakub

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

[Jakub Jelinek via Gcc]

On Fri, Jul 05, 2024 at 09:38:21PM +0800, Xi Ruoyao via Gcc wrote:
> On Fri, 2024-07-05 at 15:03 +0200, Alejandro Colomar wrote:
> > ISO C specifies these APIs as accepting a restricted pointer in their
> > first parameter:
> > 
> > $ stdc c99 strtol
> > long int strtol(const char *restrict nptr, char **restrict endptr, int 
> > base);
> > $ stdc c11 strtol
> > long int strtol(const char *restrict nptr, char **restrict endptr, int 
> > base);
> > 
> > However, it should be considered a defect in ISO C.  It's common to see
> > code that aliases it:
> > 
> > char str[] = "10 20";
> > 
> > p = str;
> > a = strtol(p, &p, 0);  // Let's ignore error handling for
> > b = strtol(p, &p, 0);  // simplicity.
> 
> Why this is wrong?

I don't see anything wrong with it either.  The function only reads
the string starting with nptr and then stores some pointer to *endptr,
if the caller doesn't make nptr point to what endptr points to or vice
versa, that should be fine.

Jakub

Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

[Jakub Jelinek via Gcc]

On Tue, Jul 02, 2024 at 12:54:09PM -0400, David Malcolm via Gcc wrote:
> Back in 2007 glibc gained some logic to implement "error" and
> "error_at_line" by splitting into zero and non-zero cases, with the
> nonzero case calling a "noreturn" function [1].
> 
> This doesn't seem to work. I tested back to 4.8.1 with Compiler
> Explorer [2], which seems to be the earliest GCC that supports -fdump-
> tree-original=stderr.
> 
> What happens is that glibc's 
> 
> __extern_always_inline void
> error (int __status, int __errnum, const char *__format, ...)
> {
>   if (__builtin_constant_p (__status) && __status != 0)
> __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
>   else
> __error_alias (__status, __errnum, __format, __va_arg_pack ());
> }
> 
> comes out of GCC's C frontend as:
> 
> {
>   if (0)
> {
>   __error_noreturn (__status, __errnum, __format, __builtin_va_arg_pack 
> ());
> }
>   else
> {
>   __error_alias (__status, __errnum, __format, __builtin_va_arg_pack ());
> }
> }
> 
> since __status is not a builtin constant,

At -O0 sure, that is how __builtin_constant_p works.
The above is intended for optimized compilation, and I think it works just
fine then.
The fact that in some cases the function after optimization appears to be
noreturn isn't something one can really rely on, just pass a function
parameter or something that will not optimize into a constant and it will be
fallthrough as well...

Jakub

GCC 12.4 Released

[Jakub Jelinek via Gcc]

The GNU Compiler Collection version 12.4 has been released.

GCC 12.4 is a bug-fix release from the GCC 12 branch
containing important fixes for regressions and serious bugs in
GCC 12.3 with more than 84 bugs fixed since the previous release.

This release is available from the FTP servers listed here:

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

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Re: check_qualified_type

[Jakub Jelinek via Gcc]

On Mon, Jun 17, 2024 at 03:53:41PM +0200, Martin Uecker wrote:
> > If c_update_type_canonical is only ever called for the main variants of the
> > type and they always have !TYPE_QUALS (t), then yes.
> > But if we rely on that, perhaps we should gcc_checking_assert that.
> > So
> >   gcc_checking_assert (t == TYPE_MAIN_VARIANT (t) && !TYPE_QUALS (t));
> > or something similar at the start of the function.
> 
> It calls itself recursively on pointers to the type.  But to
> me the third branch looks dead in any case, because the first
> two cover all possibilities.

Yes, but the pointers built by build_pointer_type should still be hopefully
the unqualified versions, if one wants a qualified pointer, that would be
build_qualified_type (build_pointer_type (...), ...)

The checks cover all the possibilities only if the canonical type has
the same quals as t.

> > Then we could also change the
> >   for (tree x = TYPE_MAIN_VARIANT (t); x; x = TYPE_NEXT_VARIANT (x))
> > to
> >   for (tree x = t; x; x = TYPE_NEXT_VARIANT (x))
> > and
> >   if (TYPE_QUALS (x) == TYPE_QUALS (t))
> > ...
> > to
> >   if (!TYPE_QUALS (x))
> > TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> >   else
> > build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
> > 

Jakub

Re: check_qualified_type

[Jakub Jelinek via Gcc]

On Mon, Jun 17, 2024 at 03:33:05PM +0200, Martin Uecker wrote:
> > I've done that and that was because build_qualified_type uses that
> > predicate, where qualified types created by build_qualified_type have
> > as TYPE_CANONICAL the qualified type of the main variant of the canonical
> > type, while in all other cases TYPE_CANONICAL is just the main variant of
> > the type.
> > Guess we could also just do
> >   if (TYPE_QUALS (x) == TYPE_QUALS (t))
> > TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> >   else if (TYPE_CANONICAL (t) != t
> >|| TYPE_QUALS (x) != TYPE_QUALS (TYPE_CANONICAL (t)))
> > TYPE_CANONICAL (x)
> >   = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
> >   else
> > TYPE_CANONICAL (x) = x;
> > 
> 
> Ok, that works. I think the final "else" is then then impossible to reach
> and can be eliminated as well, because if TYPE_CANONICAL (t) == t then 
> TYPE_QUALS (x) == TYPE_QUALS (TYPE_CANONICAL (t)) is identical to
> TYPE_QUALS (x) == TYPE_QUALS (t) which is the first case.

If c_update_type_canonical is only ever called for the main variants of the
type and they always have !TYPE_QUALS (t), then yes.
But if we rely on that, perhaps we should gcc_checking_assert that.
So
  gcc_checking_assert (t == TYPE_MAIN_VARIANT (t) && !TYPE_QUALS (t));
or something similar at the start of the function.
Then we could also change the
  for (tree x = TYPE_MAIN_VARIANT (t); x; x = TYPE_NEXT_VARIANT (x))
to
  for (tree x = t; x; x = TYPE_NEXT_VARIANT (x))
and
  if (TYPE_QUALS (x) == TYPE_QUALS (t))
...
to
  if (!TYPE_QUALS (x))
TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
  else
build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));

Jakub

Re: check_qualified_type

[Jakub Jelinek via Gcc]

On Mon, Jun 17, 2024 at 02:42:05PM +0200, Richard Biener wrote:
> > > > I am trying to understand what check_qualified_type
> > > > does exactly. The direct comparison of TYPE_NAMES seems incorrect
> > > > for C and its use is c_update_type_canonical then causes
> > > > PR114930 and PR115502.  In the later function I think
> > > > it is not really needed and I guess one could simply remove
> > > > it, but I wonder if it works incorrectly in other cases 
> > > > too?
> > > 
> > > TYPE_NAMES is compared because IIRC typedefs are recorded as variants
> > > and 'const T' isn't the same as 'const int' with typedef int T.
> > 
> > so if it is intentional that it differentiates between 
> > 
> > struct foo
> > 
> > and
> > 
> > typedef struct foo bar
> > 
> > then I will change c_update_type_canonical to not use it,
> > because both types should have the same TYPE_CANONICAL
> 
> The check is supposed to differentiate between variants and all variants
> have the same TYPE_CANONICAL so I'm not sure why you considered using
> this function for canonical type compute?

I've done that and that was because build_qualified_type uses that
predicate, where qualified types created by build_qualified_type have
as TYPE_CANONICAL the qualified type of the main variant of the canonical
type, while in all other cases TYPE_CANONICAL is just the main variant of
the type.
Guess we could also just do
  if (TYPE_QUALS (x) == TYPE_QUALS (t))
TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
  else if (TYPE_CANONICAL (t) != t
   || TYPE_QUALS (x) != TYPE_QUALS (TYPE_CANONICAL (t)))
TYPE_CANONICAL (x)
  = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
  else
TYPE_CANONICAL (x) = x;
or so.

Jakub

Re: gcc git locked out for hours second day in a row

[Jakub Jelinek via Gcc]

On Wed, Jun 12, 2024 at 04:53:38PM +0200, Mikael Morin wrote:
> > Perhaps you could create a mirror version of the repo and do some 
> > experiments locally on that to identify where the bottle-neck is coming 
> > from?
> > 
> Not sure where to start for that.Are the hooks published somewhere?

Yes: https://github.com/AdaCore/git-hooks/tree/master

Note, we use some tweaks on top of that, but that is mostly for the
release branches and trunk, so it would be interesting to just try
to reproduce that with the stock AdaCore git hooks.

Jakub

gcc git locked out for hours second day in a row

[Jakub Jelinek via Gcc]

Hi!

Yesterday the gcc git repository was locked for 3 hours
locked by user mikael at 2024-06-11 13:27:44.301067 (pid = 974167)
78:06 python hooks/update.py refs/users/mikael/tags/fortran-dev_merges/r10-1545 
 
c2f9fe1d8111b9671bf0aa8362446516fd942f1d
process until overseers killed it but today we have the same
situation for 3 ours and counting again:
locked by user mikael at 2024-06-12 08:35:48.137564 (pid = 2219652)
78:06 python hooks/update.py refs/users/mikael/tags/toto 
 
cca005166dba2cefeb51afac3ea629b3972acea3

It is possible we have some bug in the git hook scripts, but it would
be helpful trying to understand what exactly you're trying to commit
and why nobody else (at least to my knowledge) has similarly stuck commits.

The effect is that nobody can push anything else to gcc git repo
for hours.

Jakub

Re: How to avoid some built-in expansions in gcc?

[Jakub Jelinek via Gcc]

On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> (Well, and without reverse-recognition of isfinite-like idioms in the 
> sources.  That's orthogonal as well.)

Why?  If isfinite is better done by a libcall, why isn't isfinite-like
idiom also better done as a libcall?

Jakub

Re: configure adds -std=gnu++11 to CXX variable

[Jakub Jelinek via Gcc]

On Tue, May 28, 2024 at 07:35:43AM -0700, Paul Eggert wrote:
> On 2024-05-28 01:20, Jonathan Wakely wrote:
> > I am not aware of any distro ever changing the default -std setting for g++
> > or clang++. Are you attempting to solve a non-problem, but introducing new
> > ones?
> 
> If it's a non-problem for C++, why does Autoconf upgrade to C++11 when the
> default is C++98? Autoconf has done so since Autoconf 2.70 (2020), with
> nobody complaining as far as I know.
> 
> Was the Autoconf 2.70 change done so late that it had no practical effect,
> because no distro was defaulting to C++98 any more? If so, it sounds like

That seems to be the case.
Dunno about clang++ defaults, but GCC defaults to
-std=gnu++98 (before GCC 6), or
-std=gnu++14 starting with GCC 6 (April 2016), or
-std=gnu++17 starting with GCC 11 (April 2021).
So, if autoconf in 2020 c++98 default to c++11, bet it didn't affect almost
anything.  RHEL 7 uses GCC 4.8, which partially but not fully supports c++11
(e.g. GCC which is written in C++11 these days can build using GCC 4.8.5
as oldest compiler, has to use some workarounds because the C++11 support
isn't finished there, the library side even further from that).  And trying
to enable C++11 on GCC 4.4 (RHEL 6) wouldn't be a good idea, too much was
missing there.
With C++20 in GCC 14, from core most of the features are in except that
modules still need further work, for library side at least cppreference
says it is complete too but I think the ABI hasn't been declared stable yet,
so C++17 is still the default, dunno if it will change in GCC 15 or not.

> Autoconf should go back to its 2.69 behavior and not mess with the C++
> version as that's more likely to hurt than help.

Yes.

> For background on that Autoconf 2.70 change, see this 2013 thread:
> 
> https://lists.gnu.org/r/autoconf/2013-01/msg00016.html

>From what I can see, the change was proposed when the C++11 support wasn't
complete and didn't expect compilers will actually change their defaults
when the support is sufficiently stable.
Note, even for C GCC updates the default, -std=gnu99 default was changed to
-std=gnu11 in GCC 5 (April 2015) and -std=gnu17 in GCC 8 (May 2018).
-std=gnu23 support is still incomplete even in GCC 14.

Jakub

Re: configure adds -std=gnu++11 to CXX variable

[Jakub Jelinek via Gcc]

On Mon, May 27, 2024 at 12:04:40PM -0700, Paul Eggert wrote:
> On 2024-05-27 03:35, Florian Weimer wrote:
> > Does this turn on experimental language modes by default?  That's
> > probably not what we want.
> 
> What do C++ developers want these days? Autoconf should have a reasonable
> default, and C++11 is surely not a good default anymore.

Maybe respect the carefully chosen compiler default (unless explicitly
overridden in configure.ac)?

Jakub

GCC 12.3.1 Status Report (2024-05-24)

[Jakub Jelinek via Gcc]

Status
==

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

It's time to do the annual release from the branch, GCC 12.4, and
the plan is to do a release candidate on June 13th followed
by the actual release a week after that.

Please look through bugzilla and see which of your regression fixes
for GCC 13 are also applicable for the GCC 12 branch and do the
necessary backporting.  Note that the closing release from the 11 branch
will follow as well.

Quality Data


Priority  #   Change from last report
---   ---
P10
P2  619   + 118
P3   77   +  23
P4  200   -  32
P5   24
---   ---
Total P1-P3 696   + 141
Total   920   + 109


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-May/241260.html

GCC 13.3 Released

[Jakub Jelinek via Gcc]

The GNU Compiler Collection version 13.3 has been released.

GCC 13.3 is a bug-fix release from the GCC 13 branch

  
containing important fixes for regressions and serious bugs in
GCC 13.2 with more than 173 bugs fixed since the previous release.  

  

This release is available from the FTP servers listed here:

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

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Re: GCC 13.3 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

On Tue, May 14, 2024 at 06:31:19PM +0200, Jakub Jelinek via Gcc wrote:
> If all goes well, we'd like to release 13.3 on Thursday, May 21st.

Tuesday, May 21st.  Sorry for the pasto.

Jakub

GCC 13.3 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The first release candidate for GCC 13.3 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/

and shortly its mirrors.  It has been generated from git commit
r13-8774-g1db45e83021a8a.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 13.3 on Thursday, May 21st.

Re: FE C++ requirement

[Jakub Jelinek via Gcc]

On Tue, May 07, 2024 at 04:40:55PM -0400, James K. Lowden wrote:
> /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not
> found (required by build-O2/gcc/cobol1

The cc1/cc1plus/f951/... binaries are normally linked with
-static-libstdc++ -static-libgcc in second and later stages (first
stage is linked against the host libstdc++, so not a problem, but
even that stage is often linked with it).
See e.g. --with-static-standard-libraries configure option in toplevel
configury.

Perhaps you don't link cobol1 with the correct make variables
as other FEs are linked?

I think it is $(LDFLAGS) that is needed:
grep ^LDFLAGS *gcc/Makefile
gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
prev-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
stage1-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
but better follow what other FEs do in Make-lang.in
E.g. the linking of the FE binaries need to be specially chained for
--enable-link-serialization
or
--enable-link-serialization=N
such that only N binaries are linked together, etc.
c++.serial = cc1plus$(exeext)
...
cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) 
$(LIBDEPS) $(c++.prev)
@$(call LINK_PROGRESS,$(INDEX.c++),start)
+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
  $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) \
$(LIBS) $(BACKENDLIBS)
@$(call LINK_PROGRESS,$(INDEX.c++),end)
does that (the lang.serial line, $(lang.prev) dependency, the
LINK_PROGRESS.lang calls, using $(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) ...
$(BACKEND) $(BACKENDLIBS) $(LIBS) too.

Jakub

Re: Error in gcc 14 porting document

[Jakub Jelinek via Gcc]

On Wed, May 08, 2024 at 01:15:21PM +0200, Matthias Urlichs via Gcc wrote:
> On 08.05.24 11:50, Richard Biener wrote:
> > > "With the |-fpermissive| option, programs can use C99 inlining semantics
> > > and features that were removed from C99"
> > > 
> > > Umm, what? this sentence doesn't make sense.
> > In the context of mentioning the -std=gnu89/-std=c89 workarounds
> 
> I thought as much, but shouldn't it then say "programs can use *C89*
> inlining semantics that were removed from C99"?

There was no C89 inline semantics, only GNU89 one.  Only C99 introduced
inline keyword into the standard.

Jakub

Second GCC 14.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The second release candidate for GCC 14.1 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/
 ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/

and shortly its mirrors.  It has been generated from git commit
r14-10165-g3b4d6b6ecd79df790.

The https://gcc.gnu.org/PR114935 bug has been reported and determined
a release blocker, so we'd like to get extra testing on it prior to
the release.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, we'd still like to release 14.1 on Tuesday, May 7th.

Re: 1.76% performance loss in VRP due to inlining

[Jakub Jelinek via Gcc]

On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote:
> On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc  
> wrote:
> >
> > In implementing prange (pointer ranges), I have found a 1.74% slowdown
> > in VRP, even without any code path actually using the code.  I have
> > tracked this down to irange::get_bitmask() being compiled differently
> > with and without the bare bones patch.  With the patch,
> > irange::get_bitmask() has a lot of code inlined into it, particularly
> > get_bitmask_from_range() and consequently the wide_int_storage code.
> ...
> > +static irange_bitmask
> > +get_bitmask_from_range (tree type,
> > + const wide_int &min, const wide_int &max)
> ...
> > -irange_bitmask
> > -irange::get_bitmask_from_range () const
> 
> My guess is that this is the relevant change: the old function has
> external linkage, and is therefore interposable, which inhibits
> inlining.  The new function has internal linkage, which allows
> inlining.

Even when a function is exported, when not compiled with -fpic/-fPIC
if we know the function is defined in current TU, it can't be interposed,
Try
int
foo (int x)
{
  return x + 1;
}

int
bar (int x, int y)
{
  return foo (x) + foo (y);
}
with -O2 -fpic -fno-semantic-interposition vs. -O2 -fpic vs. -O2 -fpie vs.
-O2.

> Relatedly, I wonder if we want to build GCC with -fno-semantic-interposition?

It could be useful just for libgccjit.  And not sure if libgccjit users
don't want to interpose something.

Jakub

GCC 13.2.1 Status Report (2024-04-30)

[Jakub Jelinek via Gcc]

Status
==

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

It's time to do the annual release from the branch, GCC 13.3, and
the plan is to do a release candidate in two weeks, around May 14th,
following with the actual release around May 21st.

Please look through bugzilla and see which of your regression fixes
for GCC 14/15 are also applicable for the GCC 13 branch and do the
necessary backporting.  Note that releases from the older branches
will follow as well.


Quality Data


Priority  #   Change from last report
---   ---
P12   +   2
P2  512   + 115
P3   96   -  30
P4  216   +   2
P5   24
---   ---
Total P1-P3 725   +  87
Total   965   +  89


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-July/242150.html

GCC 14.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The first release candidate for GCC 14.1 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/
 ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/

and shortly its mirrors.  It has been generated from git commit
r14-10154-g7a00c459cbb913a.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 14.1 on Tuesday, May 7th.

GCC 15.0.0 Status Report (2024-04-26)

[Jakub Jelinek via Gcc]

Status
==

The trunk has branched for the GCC 14 release and is now open
again for general development, stage 1.  Please consider not
disrupting it too much during the RC phase of GCC 14 so it
is possible to test important fixes for 14.1 on it.


Quality Data


Priority  #   Change from last report
---   ---
P16-   8
P2  607+ 101
P3   58- 186
P4  219-   9
P5   25-   1
---   ---
Total P1-P3 671-  93
Total   915- 103


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html

GCC 14.0.1 Status Report (2023-04-26)

[Jakub Jelinek via Gcc]

Status  

  
==  

  


  
We have reached zero P1 regressions today and releases/gcc-14 branch has

  
been created.  GCC 14.1-rc1 will be built likely on Tuesday.


The branch is now frozen for blocking regressions and documentation 

  
fixes only, all changes to the branch require a RM approval now.

  


  
If no show stoppers appear, we'd like to release 14.1 around May 7th,   

   
or soon after that, if any important issues are discovered and  

  
fixed, rc2 could be released next week. 

  


Quality Data


Priority  #   Change from last report
---   ---
P10-  14
P2  606+ 100
P3   57- 187
P4  219-   9
P5   25-   1   
---   ---
Total P1-P3 663- 101
Total   907- 111


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html

Re: [PATCH] Fix rust on *-w64-mingw32

[Jakub Jelinek via Gcc]

On Thu, Apr 25, 2024 at 07:16:31PM +0800, LIU Hao via Gcc wrote:
> --- a/gcc/rust/parse/rust-parse.cc
> +++ b/gcc/rust/parse/rust-parse.cc
> @@ -89,7 +89,7 @@ extract_module_path (const AST::AttrVec &inner_attrs,
>// Source: rustc compiler
>// 
> (https://github.com/rust-lang/rust/blob/9863bf51a52b8e61bcad312f81b5193d53099f9f/compiler/rustc_expand/src/module.rs#L174)
>  #if defined(HAVE_DOS_BASED_FILE_SYSTEM)
> -  path.replace ('/', '\\');
> +  std::replace(path.begin(), path.end(), '/', '\\');

This should be
  std::replace (path.begin (), path.end (), '/', '\\');
(at least if gcc/rust/ follows normal GCC coding conventions).

Jakub

Re: Patches submission policy change

[Jakub Jelinek via Gcc]

On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote:
> Any concerns/objections?

I'm all for it, in fact I've been sending it like that myself for years
even when the policy said not to.  In most cases, the diff for the
regenerated files is very small and it helps even in patch review to
actually check if the configure.ac/m4 etc. changes result just in the
expected changes and not some unrelated ones (e.g. caused by user using
wrong version of autoconf/automake etc.).
There can be exceptions, e.g. when in GCC we update from a new version
of Unicode, the regenerated ucnid.h diff can be large and
uname2c.h can be huge, such that it can trigger the mailing list size
limits even when the patch is compressed, see e.g.
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636427.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636426.html
But I think most configure or Makefile changes should be pretty small,
usual changes shouldn't rewrite everything in those files.

Jakub

Re: gcc 3.2.3 x64 negative indexes

[Jakub Jelinek via Gcc]

On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote:
> I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:

Don't, gcc 3.2.3 is not supported for more than 20 years already.

> int fff(char *x)
> {
> return (x[-1]);
> }
> 
> 
> It is generating:
> 
> .globl fff
> fff:
> .LFB2:
> movl$4294967295, %eax
> movsbl  (%rax,%rcx),%eax

That said, I can't reproduce it and get
movsbl  -1(%rdi),%eax
ret
from 3.2.3.

Jakub

(in)consistency of libgcc symbol versions

[Jakub Jelinek via Gcc]

Hi!

Seems libgcc mostly uses triplets after GCC_ in symbol version names in the
last few years (looking at GCC 5+):

find -name \*.ver -o -name \*.ver.in | xargs grep 
'GCC_[156789][0-9]*\.[0-9]*\.[0-9]* '
./config/i386/libgcc-glibc.ver:%inherit GCC_12.0.0 GCC_7.0.0
./config/i386/libgcc-glibc.ver:GCC_12.0.0 {
./config/i386/libgcc-glibc.ver:%inherit GCC_13.0.0 GCC_12.0.0
./config/i386/libgcc-glibc.ver:GCC_13.0.0 {
./config/i386/libgcc-glibc.ver:%inherit GCC_14.0.0 GCC_13.0.0
./config/i386/libgcc-glibc.ver:GCC_14.0.0 {
./config/i386/libgcc-bsd.ver:GCC_7.0.0 {
./config/i386/libgcc-sol2.ver:GCC_7.0.0 {
./config/i386/libgcc-darwin.ver:%inherit GCC_12.0.0 GCC_7.0.0
./config/i386/libgcc-darwin.ver:GCC_12.0.0 {
./config/ia64/libgcc-glibc.ver:GCC_7.0.0 {
./config/aarch64/libgcc-softfp.ver:%inherit GCC_13.0.0 GCC_11.0.0
./config/aarch64/libgcc-softfp.ver:GCC_13.0.0 {
./config/pru/libgcc-eabi.ver:GCC_9.0.0 {
./libgcc-std.ver.in:%inherit GCC_7.0.0 GCC_4.8.0
./libgcc-std.ver.in:GCC_7.0.0 {
./libgcc-std.ver.in:%inherit GCC_14.0.0 GCC_7.0.0
./libgcc-std.ver.in:GCC_14.0.0 {

But there are some outliers to this:

find -name \*.ver -o -name \*.ver.in | xargs grep 
'GCC_[156789][0-9]*\(\|\.[0-9]*\) '
./config/mips/libgcc-mips.ver:GCC_14.0 {
./config/i386/libgcc-mingw.ver:GCC_13 {
./config/aarch64/libgcc-softfp.ver:GCC_11.0 {
./config/aarch64/libgcc-sme.ver:GCC_14.0 {
./config/rs6000/libgcc-aix-cxa.ver:GCC_5 {

I guess it is too late for the GCC 5, 11 and 13 symvers now, but shouldn't
we at least change the GCC_14.0 symvers to GCC_14.0.0 (i.e. aarch64 and
mips)?

./config/aarch64/libgcc-softfp.ver even contains weirdness like
GCC_11.0 {
...
%inherit GCC_13.0.0 GCC_11.0.0
but bet that is too late too.

Jakub

Re: Regarding OMPD

[Jakub Jelinek via Gcc]

On Thu, Jan 18, 2024 at 02:36:02PM +0200, Mohamed Atef via Gcc wrote:
> I'm sorry for not getting back to you this long time. As I mentioned
> The military service here is a must. Thank God I finished my military
> service.
> I am still interested in working on OMPD. Are there any plans for OMPD,
> soon?

GCC is currently in regression bugfixing stage (until end of April or so),
so I think most maintainers will be busy with bugfixing until then.
And not just that, but new feature work such as OMPD can't be added to gcc
trunk , it can only be worked on on some development or private git branch.

If you have time for OMPD work even earlier, I think some limited patch
review is possible, but once GCC is in stage 1 (when GCC 14 is released),
I can certainly try to participate more.

Jakub

Re: I am causing valgrind errors...

[Jakub Jelinek via Gcc]

On Wed, Jan 10, 2024 at 02:47:08PM -0600, Robert Dubner wrote:
> Here's the thing:  when I run valgrind on the compilation -- not on the 
> executable, but on the compiler with the COBOL front end -- I am getting a 
> bunch of errors that look like variations of this:
> 
> ==1232157== Command: /home/bob/repos/gcc-cobol/build/gcc/cobol1 
> playpen.cbl -quiet -dumpbase 
> playpen.cbl -mtune=generic -march=x86-64 -ggdb -O0 -o playpen.s -cmain
> ==1232157==
> ==1232157== Conditional jump or move depends on uninitialised value(s)
> ==1232157==at 0xABA0CB: sparseset_bit_p (sparseset.h:146)
> ==1232157==by 0xABA0CB: mark_pseudo_regno_live(int) (ira-lives.cc:326)
> ==1232157==by 0xABBDC0: process_bb_node_lives(ira_loop_tree_node*) 

That is normal and not a bug.
If you want to avoid that, you need to configure the compiler with
--enable-valgrind-annotations
(and have valgrind development installed before you configure/build).

Jakub

Re: Stage 4 date

[Jakub Jelinek via Gcc]

On Sun, Jan 07, 2024 at 03:12:32PM -0700, Jeff Law via Gcc wrote:
> On 1/7/24 08:48, waffl3x via Gcc wrote:
> > https://gcc.gnu.org/develop.html#timeline
> > The date for stage 4 is listed as the 8th on here, is that date final?
> > There is at least 1 patch pending (mine) that is complete but Jason
> > Merril hasn't been active for a few days. He had expressed to me that
> > he expected the date to be next week on the 14th. Is it possible to
> > push back the date for stage 4 a little bit? I've been working hard on
> > my patch and would be very disappointed if it did not make it in for
> > GCC14.

> Note there is generally allowances made for patches that were posted before
> the deadline, but are still going through the review/iterate process.

Also, not really sure why the stage 4 start is relevant to this patch,
it is a new feature, not a bug fix, which admittedly had some versions
posted already during stage 1, so if Jason accepts it soon I have no problem
with it getting in (in fact I'd appreciate if it got in soon), but end of
stage 3 is deadline for patches which are fixing bugs but not regression bugs.

Jakub

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

[Jakub Jelinek via Gcc]

On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote:
> > On Dez 01 2023, Richard Biener via Gcc wrote:
> > 
> > > Hmm, so why's it then referenced and not "GCed"?
> > 
> > This has nothing to do with garbage collection.  It's just the way
> > libgcc avoids having too many source files.  It would be exactly the
> > same if every function were in its own file.
> 
> THe ifdef machinery makes every function to go insto its own .o file
> which are then archived.  So if user code never calls to fork, the .o
> file with fork wrapper should not be picked by linker and we should not
> have link error.
> 
> If user code calls fork, then the .o file with wrapper should be picked
> and we will get linker error on missing fork.  So I think it ought to
> work as it is now.  Does mingw linker behave somehow differently with
> archives?  Or is there problem with a libgcov being DLL or something?

The problem is that the changes to switch to modern C result in calls to
unprototyped function being an error rather than just warning as before.
int foo (void) { return fork (); }
warning: implicit declaration of function ‘fork’ 
[-Wimplicit-function-declaration]
previously, now
error: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
(by default in C99+).

So, as has been discussed earlier, either we should use __builtin_fork ()
rather than fork (), or we need in configure to test for fork prototype and
if missing, prototype it ourselves, or ensure _gcov_fork.o is not compiled
on targets which don't have fork prototyped.

Jakub

Re: gcc/DATESTAMP not updated since 20231109

[Jakub Jelinek via Gcc]

On Tue, Nov 14, 2023 at 09:30:21AM +0100, Rainer Orth wrote:
> For the last couple of days (since 2023-11-09), gcc/DATESTAMP hasn't
> been updated.

I'll have a look.  Probably some bad commit again.

Jakub

Re: Emacs ChangeLog generation and commit messages

[Jakub Jelinek via Gcc]

On Mon, Nov 06, 2023 at 05:38:40PM +0100, Florian Weimer via Gcc wrote:
> Emacs has a very useful facility.  You press “C-x 4 a” in a place where
> you make changes, and the editor automatically opens the right ChangeLog
> file and adds a draft entry to it, like this:
> 
> 2023-11-06  Florian Weimer  
> 
>   * c-opts.cc (c_common_post_options): █
> 
> Is there something like this that works with commit messages and
> produces output compatible with GCC's expectations?

contrib/mklog.py ?

Jakub

Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz

[Jakub Jelinek via Gcc]

On Thu, Nov 02, 2023 at 04:44:30PM +, Joseph Myers wrote:
> On Thu, 2 Nov 2023, Richard Biener via Gcc wrote:
> 
> > Note the semantic of __builtin_clz is _not_ altered by
> > CLZ_DEFINED_VALUE_AT_ZERO, the behavior
> > of __builtin_clz (x) is that is has undefined result for x == 0.
> 
> Note also the discussion in bug 111309 of possible future type-generic 
> versions of operations such as clz (under a different name because 
> __builtin_clz is already taken), in order to support _BitInt, where 
> there's a plausible argument for defining the result for all argument 
> values rather than leaving it undefined at 0.

I plan to work on that soon.
The current plan is to let the users choose what they want, by having
the type-generic variants of the builtin support either one or two
arguments (just for clz/ctz obviously), if only one is provided,
it is undefined at 0, if two are provided, then the second argument is
the value to be returned for 0.

So, __builtin_clzg (0uwb) or __builtin_clzg (0ULL) would be UB,
while __builtin_clzg (0uwb, 42) would return 42.
We'd need something like __builtin_widthof as well because _Bitwithof
or something similar hasn't been standardized yet, so people can use
the type-generic function in macro and ask for the number of bits
to be returned for 0 (or something based on that).

Jakub

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Jakub Jelinek via Gcc]

On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc 
> wrote:
> 
> > Are these code fragments valid C89 code?
> >
> >   int i1 = 1;
> >   char *p1 = i;
> >
> >   char c;
> >   char *p2 = &c;
> >   int i2 = p2;
> >
> > Or can we generate errors for them even with -std=gnu89?
> >
> > (It will still be possible to override this with -fpermissive or
> > -Wno-int-conversion.)
> >
> 
> Given that C89 code is unlikely to be actively maintained, I think we
> should be permissive by default in that mode.  People compiling with an old
> -std flag are presumably doing it to keep old code compiling, and it seems
> appropriate to respect that.

Yeah, complete agreement here.

> I'm also (though less strongly) inclined to be permissive in C99 mode, and
> only introduce the new strictness by default for C11/C17 modes.

Especially when the default is -std=gnu17 that can be an option as well.

There might be some code in the wild compiled with -std=gnu99 or -std=c99 just
because it wanted to use C99 features back 15-20 years ago and hasn't been
adjusted since then, but it might be better to adjust that if needed and keep
using those flags only when they are needed because the code isn't C11/C17/C2X
ready.

Jakub

Re: Test with an lto-build of libgfortran.

[Jakub Jelinek via Gcc]

On Thu, Sep 28, 2023 at 09:03:39PM +0200, Toon Moene wrote:
> > > The full question of "lto-ing" run time libraries is more
> > > complicated than just "whether it works" as those who attended the
> > > BoF will recall.
> > 
> > I didn't attend the Cauldron (but that discussion would have been
> > very interesting).  I think for libgfortran, a first step would be
> > additional work to get declarations on both sides to agree (which is
> > worth doing anyway).
> > 
> > Best regards
> > 
> >  Thomas
> 
> The big problem in *distributing* GCC (i.e., the collection) with lto'd
> run-time libraries is that the format of the lto structure changes with
> releases. If a compiler (by accident) picks up a run time library with
> non-matching lto objects, it might crash (or "introduce subtle errors in a
> once working program").

It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Though, admittedly GCC is the single package that actually could get away
with LTO in lib*.a libraries, at least in some packagings (if the static
libraries are in gcc specific subdirectories rather than say /usr/lib{,64}
or similar and if the packaging of gcc updates both the compiler and
corresponding static libraries in a lock-step.  Because in that case LTO
in there will be always used only by the same snapshot from the release
branch and so should be compatible with the LTO in it.

Jakub

Re: Test with an lto-build of libgfortran.

[Jakub Jelinek via Gcc]

On Thu, Sep 28, 2023 at 09:29:02AM +0200, Tobias Burnus wrote:
> the following works for me. I have only tried a normal build (where it
> does silence the same warning) and not an LTO build and I just believed
> the comment - see attached patch. Comments?
> 
> On 28.09.23 08:25, Richard Biener via Fortran wrote:
> 
> > This particular place in libgfortran has
> > 
> >/* write_z, which calls xtoa_big, is called from transfer.c,
> >   formatted_transfer_scalar_write.  There it is passed the kind as
> >   argument, which means a maximum of 16.  The buffer is large
> >   enough, but the compiler does not know that, so shut up the
> >   warning here.  */
> > #pragma GCC diagnostic push
> > #pragma GCC diagnostic ignored "-Wstringop-overflow"
> >*q = '\0';
> > #pragma GCC diagnostic pop
> > 
> > so obviously the #pragma doesn't survive through LTO.  Somehow I think
> > this is a known bug, but maybe I misremember (I think we are not streaming
> > any of the ad-hoc location parts).
> 
> I have replaced it now by the assert that "len <= 16", i.e.
> 
> +  if (len > 16)
> +__builtin_unreachable ();
> 
> Build + tested on x86-64-gnu-linux
> Comment? OK for mainline?

Is it just that in correct programs len can't be > 16, or that it is really
impossible for it being > 16?  I mean, we have that artificial kind 17 for
powerpc which better should be turned into length of 16, but isn't e.g.
_gfortran_transfer_integer etc. just called with a kind argument?  Does
anything error earlier if it is larger?  I mean, say user calling
_gfortan_transfer_integer by hand with kind 1024?

Sure, we could still say it is UB to do that kind of thing and
__builtin_unreachable () would be a way to turn that UB into manifestly
reproducable UB.

Jakub

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

[Jakub Jelinek via Gcc]

On Tue, Sep 26, 2023 at 10:28:34AM +0200, 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.

I think it doesn't have to be necessarily using defaulting to -Werror=,
-Werror= involves diagnostic_classify_diagnostic etc.
It could very well be also just testing if the corresponding warning
option isn't explicitly (OPTION_SET_P) disabled and isn't explicitly
-Wno-error=OPTION and c99 or later and conditionally based on that
use error (which would print the [-W...] part though) or warning.
The former would be in system headers too, the latter wouldn't.
We need to decide what exact options we want to turn those errors (and/or
warnings) off or on, -Wno-implicit-int, -w, -Wno-error,
-Wno-error=implicit-int, ...

Jakub

Re: Concerns regarding the -ffp-contract=fast default

[Jakub Jelinek via Gcc]

On Mon, Sep 18, 2023 at 01:26:54PM +0200, Martin Uecker wrote:
> > I think that changing the default to =standard without -ffast-math is
> > reasonable.
> > IIRC the standard allows such default if it's indicated, so it doesn't 
> > require
> > =off anywhere.
> 
> The C standard requires a pragma to turn control it on and off, 
> which GCC does not support.  The default is then implementation
> defined.

Perhaps we should add some initial hammer approach for the pragma, like
if you ever use the pragma to turn it somewhere off, it is turned off
globally, or ditto per function.  Might be far easier than trying to
make it precise that contraction is allowed in this expression and not in
this subexpression of that etc.  Of course, making it precise is the
ultimate goal.

Jakub

Re: CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false

[Jakub Jelinek via Gcc]

On Fri, Sep 01, 2023 at 10:13:40AM +0200, Richard Biener via Gcc wrote:
> The value of .CLZ (0) is undefined then.  I belive your analysis is correct in
> that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
> the range for _35.  I wonder why we don't elide _36 ? _31 : 1 with that info
> (possibly no range-op for .CLZ?), of course it would be wrong to do so.
> 
> Can you open a bugreport please?

Seems similar to 
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/thread.html#612214
except that case is at RTL level.
But arguably, I think at least at GIMPLE level we should just emit here
GIMPLE_COND + separate bb around it rather than COND_EXPR.

Jakub

Re: Analyzer failure due to missing header

[Jakub Jelinek via Gcc]

On Wed, Aug 30, 2023 at 11:10:57AM +0200, FX Coudert via Gcc wrote:
> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not 
> available because  is not included. The following patch fixes the 
> build for me:
> 
> diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
> index 4f31a6dcf0f..1ca8c8839bf 100644
> --- a/gcc/analyzer/region-model.cc
> +++ b/gcc/analyzer/region-model.cc
> @@ -20,6 +20,7 @@ along with GCC; see the file COPYING3.  If not see
>#include "config.h"
>  #define INCLUDE_MEMORY
> +#define INCLUDE_ALGORITHM
>  #include "system.h"
>  #include "coretypes.h"
>  #include "make-unique.h”
> 
> 
> Could you check it is what you intended, and push it?

Note, when using libstdc++ headers,  isn't needed,
because  includes bits/stl_algobase.h which defines std::min/max.

Another possibility is of course use MIN/MAX macros instead of std::min/max.

Jakub

Re: Testsuite issue and warning about floating-point conversion

[Jakub Jelinek via Gcc]

On Sat, Aug 19, 2023 at 11:58:31AM +0200, Jakub Jelinek via Gcc wrote:
> well.  So, if aarch64-darwin wants 64-bit long double, the question is if
> it should have __float128 support and q suffix support at all.  If it
> should, then it needs to initialize float128t_type_node to a distinct type
> if NULL like i386, ia64 and rs6000 backends do (i.e. for C++).

Oh, and as the comment say, one needs to decide how to mangle the types.
long_double_type_node, even when distinct from double_type_node, will
mangle unless overridden as e (double d), and float128_type_node as DF128_.
__float128 should mangle per Itanium ABI mangling as g (unless overridden)
but backend needs to do that.
Also, one needs to decide what _Float16 and __bf16 mangles as, whether
the Itanium ABI DF16_ and DF16b or something different (aarch64-linux
mangles the latter as u6__bf16 instead).
See what clang does as well...

Jakub

Re: Testsuite issue and warning about floating-point conversion

[Jakub Jelinek via Gcc]

On Sat, Aug 19, 2023 at 10:25:50AM +0100, Jonathan Wakely wrote:
> On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc  wrote:
> >
> > Hello,
> >
> > On the WIP aarch64-darwin port of GCC 
> > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite 
> > failures which are due to the following:
> >
> > 1. The testsuite check_effective_target_has_q_floating_suffix check tries 
> > to compile the code "float dummy = 1.0q;” to determine if the q suffix is 
> > allowed on floating-point types.
> >
> > 2. The check should pass on aarch64-darwin, and indeed the code compiles, 
> > because the q suffix matches the _Float128 type.
> >
> > 3. However, a warning is emitted which makes the test fail:
> >
> > a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater 
> > conversion rank
> > 1 | float dummy = 1.0q;
> >   |   ^~~~
> >
> >
> > 4. Therefore, the expectations of the different tests fail.
> >
> >
> > Now, I am not sure why other targets are not affected in the same way, for 
> > example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning 
> > warranted here? If so, we should adjust the check to silence warnings, or 
> > use a cast. Or is the warning emitted in error?
> 
> It's probably because 1.0q produces __float128 on those targets, not
> _Float128. In C++23 _Float128 (and _Float32 etc.) have special rules
> about implicit conversions to other floating-point types.
> 
> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.

That seems like a bug in the aarch64-darwin port.
1.0q should definitely be __float128 rather than _Float128.

The c-lex.cc code has:
/* For Q suffix, prefer float128t_type_node (__float128) type
   over float128_type_node (_Float128) type if they are distinct.  */
if (type == float128_type_node && float128t_type_node)
  type = float128t_type_node;
Now, the generic tree.cc initialization will initialize float128_type_node
(i.e. _Float128) to some floating point type if there is IEEE quad mode
backend support, and float128t_type_node (i.e. __float128) to 
float128_type_node,
and c-family/c-common.cc later on will:
  /* For C, let float128t_type_node (__float128 in some backends) be the
 same type as float128_type_node (_Float128), for C++ let those
 be distinct types that mangle and behave differently.  */
  if (c_dialect_cxx ())
float128t_type_node = NULL_TREE;
i.e. __float128 and _Float128 are the same type for C and for C++ distinct,
then i386, ia64 and rs6000 backends create their own float128t_type_node
as distinct types.
q/w suffixes aren't supported at all unless the backend overrides
c.mode_for_suffix target hook, and besides the above 3 arches only
aarch64 and pa do that. pa does that iff it it registers __float128
type as an alias to long double and aarch64 except for Darwin does that as
well.  So, if aarch64-darwin wants 64-bit long double, the question is if
it should have __float128 support and q suffix support at all.  If it
should, then it needs to initialize float128t_type_node to a distinct type
if NULL like i386, ia64 and rs6000 backends do (i.e. for C++).

Jakub

Re: GCC support for extensions from later standards

[Jakub Jelinek via Gcc]

On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klauser wrote:
> Thanks for the answers!
> 
> There are a few really interesting extensions that I would like to use:
> 
> - inline variables
> - variable templates
> - `if constexpr`
> - fold expressions
> - conditional explicit
> - static operator()

There are multiple problems.

cat /tmp/test.h
#pragma GCC system_header
inline int a = 1;
template  int b = N;
void foo () { if constexpr (true) {} }
template  bool bar (A... a) { return (... + a); }
struct S { template  explicit (N == 42) S (int (&)[N]) {} };
struct T { static constexpr bool operator () (S const &x, S const &y) { return 
false; }; };
void baz () { auto a = [](int x, int y) static { return x + y; }; }
cat /tmp/test.C
#include "/tmp/test.h"
g++ -S -std=c++11 -o /tmp/test.{s,C}

The above with GCC 13 doesn't give any warnings, but does with -Wsystem-headers:
In file included from /tmp/test.C:1:
/tmp/test.h:2:1: warning: inline variables are only available with ‘-std=c++17’ 
or ‘-std=gnu++17’ [-Wc++17-extensions]
2 | inline int a = 1;
  | ^~
/tmp/test.h:3:22: warning: variable templates only available with ‘-std=c++14’ 
or ‘-std=gnu++14’ [-Wc++14-extensions]
3 | template  int b = N;
  |  ^
/tmp/test.h: In function ‘void foo()’:
/tmp/test.h:4:18: warning: ‘if constexpr’ only available with ‘-std=c++17’ or 
‘-std=gnu++17’ [-Wc++17-extensions]
4 | void foo () { if constexpr (true) {} }
  |  ^
/tmp/test.h: In function ‘bool bar(A ...)’:
/tmp/test.h:5:59: warning: fold-expressions only available with ‘-std=c++17’ or 
‘-std=gnu++17’ [-Wc++17-extensions]
5 | template  bool bar (A... a) { return (... + a); }
  |   ^
/tmp/test.h: At global scope:
/tmp/test.h:6:29: warning: ‘explicit(bool)’ only available with ‘-std=c++20’ or 
‘-std=gnu++20’ [-Wc++20-extensions]
6 | struct S { template  explicit (N == 42) S (int (&)[N]) {} };
  | ^~~~
/tmp/test.h:7:34: warning: ‘static constexpr bool T::operator()(const S&, const 
S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ 
[-Wc++23-extensions]
7 | struct T { static constexpr bool operator () (S const &x, S const &y) { 
return false; }; };
  |  ^~~~
/tmp/test.h: In function ‘void baz()’:
/tmp/test.h:8:41: warning: ‘static’ only valid in lambda with ‘-std=c++23’ or 
‘-std=gnu++23’ [-Wc++23-extensions]
8 | void baz () { auto a = [](int x, int y) static { return x + y; }; }
  | ^~
and with -pedantic-errors -Wsystem-headers even errors:
./xg++ -B ./ -S /tmp/test.C -std=c++11 -pedantic-errors -Wsystem-headers
In file included from /tmp/test.C:1:
/tmp/test.h:2:1: error: inline variables are only available with ‘-std=c++17’ 
or ‘-std=gnu++17’ [-Wc++17-extensions]
2 | inline int a = 1;
  | ^~
/tmp/test.h:3:22: error: variable templates only available with ‘-std=c++14’ or 
‘-std=gnu++14’ [-Wc++14-extensions]
3 | template  int b = N;
  |  ^
/tmp/test.h: In function ‘void foo()’:
/tmp/test.h:4:18: error: ‘if constexpr’ only available with ‘-std=c++17’ or 
‘-std=gnu++17’ [-Wc++17-extensions]
4 | void foo () { if constexpr (true) {} }
  |  ^
/tmp/test.h: In function ‘bool bar(A ...)’:
/tmp/test.h:5:59: error: fold-expressions only available with ‘-std=c++17’ or 
‘-std=gnu++17’ [-Wc++17-extensions]
5 | template  bool bar (A... a) { return (... + a); }
  |   ^
/tmp/test.h: At global scope:
/tmp/test.h:6:29: error: ‘explicit(bool)’ only available with ‘-std=c++20’ or 
‘-std=gnu++20’ [-Wc++20-extensions]
6 | struct S { template  explicit (N == 42) S (int (&)[N]) {} };
  | ^~~~
/tmp/test.h:7:34: error: ‘static constexpr bool T::operator()(const S&, const 
S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ 
[-Wc++23-extensions]
7 | struct T { static constexpr bool operator () (S const &x, S const &y) { 
return false; }; };
  |  ^~~~
/tmp/test.h: In function ‘void baz()’:
/tmp/test.h:8:41: error: ‘static’ only valid in lambda with ‘-std=c++23’ or 
‘-std=gnu++23’ [-Wc++23-extensions]
8 | void baz () { auto a = [](int x, int y) static { return x + y; }; }
  | ^~
(so one would need to figure out if __extension__ somewhere around would be
able to quite that up or not, or
#pragma GCC diagnostic ignored "-Wc++14-extensions" (and 17, 20 and 23).

Also, static operator () is only in GCC 13 and later, earlier versions will
error on that.  The -Wc++*-extensions separate warnings are only in GCC 12
and later, before that it will be harder to quiet the warnings selectively.
Similarly, conditional explicit is 

GCC 13.2.1 Status Report (2023-07-27)

[Jakub Jelinek via Gcc]

Status
==

GCC 13.2 has been released, the releases/gcc-13 branch is open again
for regression and documentation bugfixing.  GCC 13.3 can be expected
in spring next year unless something serious changes the plans.


Quality Data


Priority  #   Change from last report
---   ---
P10
P2  512   +   1
P3  126   +   6
P4  214
P5   24
---   ---
Total P1-P3 638   +   7
Total   876   +   7


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-July/242117.html

GCC 13.1.1 Status Report (2023-07-20)

[Jakub Jelinek via Gcc]

Status
==

The GCC 13 branch is frozen for the release of GCC 13.2 with
a first release candidate published.  All changes require
release manager approval.

Quality Data


Priority  #   Change from last report
---   ---
P10   -   2
P2  511   -   3
P3  120   +  11
P4  214   -   2
P5   24
---   ---
Total P1-P3 631   +   6
Total   869   +   4


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html

GCC 13.2 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The first release candidate for GCC 13.2 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.2.0-RC-20230720/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.2.0-RC-20230720/

and shortly its mirrors.  It has been generated from git commit
r13-7597-g9aac37ab8a7b91.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 13.2 on Thursday, July 27th.

Re: Ju-Zhe Zhong and Robin Dapp as RISC-V reviewers

[Jakub Jelinek via Gcc]

On Tue, Jul 18, 2023 at 09:25:44AM +0800, juzhe.zh...@rivai.ai wrote:
> Thanks Jeff. 
> I will wait after Robin updated his MAINTAINERS (since I don't known what 
> information I need put in).

Add
riscv port  Juzhe Zhong 
line to the Reviewers section of MAINTAINERS file (alphabetically before
RTL optimizers) and remove your line from Write After Approval section.

Jakub

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

[Jakub Jelinek via Gcc]

On Sat, Jul 15, 2023 at 10:58:40PM +0200, Martin Jambor wrote:
> Hi,
> 
> On Sat, Jul 15 2023, FX Coudert via Gcc wrote:
> > Hi,
> >
> > I am finding it very hard to reliably compare test results and regressions 
> > with the very large number of gcc.dg/guality test failures that are 
> > apparently the new norm on x86_64-linux: more than one hundred on 13.1, and 
> > several hundreds on 14. Is there any on-going discussion about this?
> >
> > I mean, from an almost-external point of view, these tests should probably 
> > be xfail'ed and a PR opened against them to reenable them.
> >
> 
> As far as I understand it, the main problem is that it is not really
> possible to XFAIL a test for one combination of options (say "-O2
> -flto") and not others.

It is far worse than that.  We have the target vs. different ISA options
vs. different -O? options vs. different versions of gdb matrix and maintaining
what cases from those are supposed to pass and what are expected to fail
is really hard.
Which is why people should just compare testsuite results from earlier run
on the same configuration to watch for regressions, especially in the
guality testsuite.

Jakub

Re: Different ASM for ReLU function between GCC11 and GCC12

[Jakub Jelinek via Gcc]

On Tue, Jun 20, 2023 at 03:03:19PM +, Michael Matz via Gcc wrote:
> Hello,
> 
> On Tue, 20 Jun 2023, Jakub Jelinek via Gcc wrote:
> 
> > ce1 pass results in emit_conditional_move with
> > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84)
> > operands in the GCC 11 case and so is successfully matched by
> > ix86_expand_fp_movcc as ix86_expand_sse_fp_minmax.
> > But, in GCC 12+, emit_conditional_move is called with
> > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (const_double:SF 
> > 0.0 [0x0.0p+0])
> > instead (reg:SF 84 in both cases contains the (const_double:SF 0.0 
> > [0x0.0p+0])
> > value, in the GCC 11 case loaded from memory, in the GCC 12+ case set
> > directly in a move.  The reason for the difference is exactly that
> > because cheap SSE constant can be moved directly into a reg, it is done so
> > instead of reusing a pseudo that contains that value already.
> 
> But reg84 is _also_ used as operand of emit_conditional_move, so there's 
> no reason to not also use it as third operand.  It seems more canonical to 
> call a function with
> 
>   X-containing-B, A, B
> 
> than with
> 
>   X-containing-B, A, something-equal-to-B-but-not-B
> 
> so either the (const_double) RTL should be used in both, or reg84 should, 
> but not a mix.  Exactly so to ...

If ifcvt.cc knows that, then sure, but it can't be (easily) worked around on the
backend side...

Jakub

Re: Different ASM for ReLU function between GCC11 and GCC12

[Jakub Jelinek via Gcc]

On Tue, Jun 20, 2023 at 10:15:37AM +0200, Richard Biener wrote:
> On Mon, Jun 19, 2023 at 9:45 PM Jakub Jelinek via Gcc  wrote:
> >
> > On Mon, Jun 19, 2023 at 09:10:53PM +0200, André Günther via Gcc wrote:
> > > I noticed that a simple function like
> > > auto relu( float x ) {
> > > return x > 0.f ? x : 0.f;
> > > }
> > > compiles to different ASM using GCC11 (or lower) and GCC12 (or higher). On
> > > -O3 -mavx2 the former compiles above function to
> >
> > Such reports should go into gcc.gnu.org/bugzilla/, not to the mailing list,
> > if you are convinced that loading the constant from memory is faster.
> > Another possibility is
> > vxorps xmm1, xmm1, xmm1
> > vmaxss xmm0, xmm0, xmm1
> > ret
> > which doesn't need to wait for the memory.
> > This changed with https://gcc.gnu.org/r12-7693
> 
> I guess we previously were able to see that one operand of
> the comparison was not NaN.  Maybe some REG_EQUAL
> note can come to the rescue here?

ce1 pass results in emit_conditional_move with
(gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84)
operands in the GCC 11 case and so is successfully matched by
ix86_expand_fp_movcc as ix86_expand_sse_fp_minmax.
But, in GCC 12+, emit_conditional_move is called with
(gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (const_double:SF 0.0 
[0x0.0p+0])
instead (reg:SF 84 in both cases contains the (const_double:SF 0.0 [0x0.0p+0])
value, in the GCC 11 case loaded from memory, in the GCC 12+ case set
directly in a move.  The reason for the difference is exactly that
because cheap SSE constant can be moved directly into a reg, it is done so
instead of reusing a pseudo that contains that value already.
In the latter case ix86_expand_fp_movcc is called even not with the
const_double because the expander doesn't allow immediates, but with
it forced into some other register, so it can't really find out it is
actually a minmax.  Even if it allowed the cheap SSE constants,
it wouldn't know that r84 is also zero (unless the expander checks that
it is a pseudo with a single setter and verifies it or something similar).

Jakub

Re: Different ASM for ReLU function between GCC11 and GCC12

[Jakub Jelinek via Gcc]

On Mon, Jun 19, 2023 at 09:10:53PM +0200, André Günther via Gcc wrote:
> I noticed that a simple function like
> auto relu( float x ) {
> return x > 0.f ? x : 0.f;
> }
> compiles to different ASM using GCC11 (or lower) and GCC12 (or higher). On
> -O3 -mavx2 the former compiles above function to

Such reports should go into gcc.gnu.org/bugzilla/, not to the mailing list,
if you are convinced that loading the constant from memory is faster.
Another possibility is
vxorps xmm1, xmm1, xmm1
vmaxss xmm0, xmm0, xmm1
ret
which doesn't need to wait for the memory.
This changed with https://gcc.gnu.org/r12-7693

> 
> relu(float):
> vmaxss xmm0, xmm0, DWORD PTR .LC0[rip]
> ret
> .LC0:
> .long 0
> 
> which is what I would naively expect and what also clang essentially does
> (clang actually uses an xor before the maxss to get the zero). The latter,
> however, compiles the function to
> 
> relu(float):
> vxorps xmm1, xmm1, xmm1
> vcmpltss xmm2, xmm1, xmm0
> vblendvps xmm0, xmm1, xmm0, xmm2
> ret
> 
> which looks like a missed optimisation. Does anyone know if there's a
> reason for the changed behaviour?

Jakub

Re: C/C++ extension for SIMD proposal

[Jakub Jelinek via Gcc]

On Sat, Jun 10, 2023 at 07:51:10PM +0200, Jakub Juszczakiewicz via Gcc wrote:
> Hi all,
> 
>     I don't know is here right place for sharing ideas, but I don't have
> idea, where I can send it.
> I have simple idea. When I turned on OpenMP, for parallelly execute simple
> for it's enough when I add line like this before loop:
> 
> #pragma omp parallel for
> for (size_t i = 0; i < 100; i++)
>    vec_c[i] = vec_a[i] * vec_b[i];
> 
> Why don't use similar idea for show compiler that, it can by done by SIMD
> CPU extension? e.g.
> 
> #pragma simd for

Use
#pragma omp simd
for that.
That is part of OpenMP for years.

Jakub

Re: GCC 11.4 documentation 404's

[Jakub Jelinek via Gcc]

On Mon, May 29, 2023 at 02:50:06PM +, Felix LeClair via Gcc wrote:
> Hi everyone, 
> 
> Quick note that it seems like the freshly updated docs for GCC 11.4 seem to 
> be hitting a 404 error when attempting to access them. 
> 
> Links that 404 for me: 
> 
> https://gcc.gnu.org/onlinedocs/gcc-11.4.0/gcc/
> https://gcc.gnu.org/onlinedocs/gcc-11.4.0/libquadmath/
> 
> quick way to get there: 
> 
> https://gcc.gnu.org/gcc-11/ 
> followed by 
> https://gcc.gnu.org/onlinedocs/11.4.0/
> at which point tabbing/clicking over any of the docs will return a 404

Sorry, the command to generate those I've run earlier today must have then
failed, possibly because of the incorrect permissions temporary directory
issue in the repo we had since Saturday.
I've rerun it now and it worked.
Note, libstdc++ documentation isn't there yet, that will need to wait till
tomorrow because UK has public holiday today.

Jakub

GCC 11.4 Released

[Jakub Jelinek via Gcc]

The GNU Compiler Collection version 11.4 has been released.

GCC 11.4 is the first bug-fix release from the GCC 11 branch containing
important fixes for regressions and serious bugs in GCC 11.3 with more
than 110 bugs fixed since the previous release.

This release is available from the WWW servers listed here:

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

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Re: Another epic optimiser failure

[Jakub Jelinek via Gcc]

On Sat, May 27, 2023 at 11:04:11PM +0200, Stefan Kanthak wrote:
> OUCH: popcnt writes the WHOLE result register, there is ABSOLUTELY
>   no need to clear it beforehand nor to clear the higher 24 bits
>   afterwards!

Except that there is.  See https://gcc.gnu.org/PR62011 for details.

Jakub

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

[Jakub Jelinek via Gcc]

On Fri, May 26, 2023 at 03:07:59PM +0100, Jonathan Wakely wrote:
> > These points are obvious.
> > NOT obvious is but that -m -march= does not clear any
> >  not supported in , i.e the last one does NOT win here.
> 
> The last -march option selects the base set of instructions. The -mISA
> options modify that base.

And for -m32 it is also the last option that wins, but as with many other
cases just last one from certain set of options.  In the -m32 case,
last one of -m{32,64,x32,m16} option wins.  In the -march= case, the
last -march= option wins.  In say the PIC/PIE options case, last one
of -f{,no-}{pic,PIC,pie,PIE} option wins.  The -mISA options are processed
left to right after setting base from -march=.

Jakub

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

[Jakub Jelinek via Gcc]

On Fri, May 26, 2023 at 02:19:54PM +0200, Stefan Kanthak wrote:
> > I find it very SURPRISING that you're only just learning the basics of
> > how to use gcc NOW, after YELLING about all the OUCH.
> 
> I'm NOT surprised that you don't grok it!
> 
> gcc -msse4.1 -m32 -march=core2 ...
> 
> Which -m* options win here?
> Do -m32 or -march=core2 override -msse4.1?

Jonathan told you what to use to find it out (-Q --help=target).
-m32/-m64/-mx32/-m16 options don't affect the ISA, they switch the
main ABI (ilp32 32-bit code, lp64 64-bit code, ilp32 code running
in 64-bit mode, 16-bit code).  -march= options selects the ISA base (which
CPU family to compile form as minimum),
if you don't supply it, the default from how gcc has been configured
is selected (e.g. if you configure --with-arch-32=core2, then that
will be the -m32 default, if you configure --with-arch=x86-64, that will
be the -march default if --with-arch-32= isn't specified, etc.).
If more than one -march= is specified, the last one wins.
And, the -mISA options then tweak the ISA set.  Most ISAs have dependencies,
say -msse4.1 enables -mssse3 which enables -msse3 which enables -msse2 etc.,
and similarly the -mno-ISA options disable what ISAs depend on it, so
-mno-avx disables -mno-avx2 which disables -mno-avx512f which disables ...
-mtune= option specifies for which CPU family the code should be tuned,
it will still run on any code compatible with the implicit or explicit
-march=, but will schedule instructions or choose from alternative forms
from the selected ISAs to perform best on the -mtune=  family.

Jakub

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

[Jakub Jelinek via Gcc]

On Fri, May 26, 2023 at 10:59:03AM +0200, Stefan Kanthak wrote:
> 3) SSE4.1 is supported since Core2, but -march=core2 fails to enable it.
>That's bad, REALITY CHECK, please!

You're wrong.
SSE4.1 first appeared in the 45nm versions of Core2, the 65nm versions
didn't have it.
The supported CPU names don't distinguish between core2 submodels,
so if you have core2 with sse4.1, you should either be using -march=native
if compiling on such a machine, or use -march=core2 -msse4.1,
there is no -march={conroe,allendale,wolfdale,merom,penryn,...}.
> 
> 4) If the documenation is right, then the behaviour of GCC is wrong: it
>doesn't allow to use SSE4.1 without SSE4.2!

If you aren't able to read the documentation, it is hard to argue.

Jakub

GCC 11.4 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The first release candidate for GCC 11.4 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/11.4.0-RC-20230522/
 ftp://gcc.gnu.org/pub/gcc/snapshots/11.4.0-RC-20230522/

and shortly its mirrors.  It has been generated from git commit
r11-10806-gfcf62b96ec9ae3.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 11.4 on Monday, May 29th.

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
> 
> On Tue, 16 May 2023, Florian Weimer wrote:
> 
> > > (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)
> 
> (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
> 
> > I don't understand why we do not warn by default and warn with -Wall.  I
> > would expect this to be either a documented extension (no warning with
> > -Wall), or a warning by default (because it's a conformance issue).  Is
> > there any conformance issue that is treated in the same way?
> 
> Another one is -Wpointer-arith (pointer arithmetic on 'void *').

That is a documented GNU extension, so we shouldn't increase severity of
the diagnostics from the current state.

Jakub

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: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

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.

> So, a note to all users of cvise, creduce, delta etc.: Add appropriate
> -Werror flags to your checking scripts so that we don't add more of this :-)

While it is true that for C cvise/creduce/delta often end up with the
implicit ints/implicit function declarations/int-conversions because it
happens to still compile without errors, I and others routinely fix up those
testcases back to valid C provided they still reproduce the reported
problem, so I think it isn't that bad in our testsuite.
But for cvise/creduce/delta reduced testcases with GCC 14 the nice things is
that most of the time these constructs will be gone ;)

Note, using -Werror for all warnings for testsuite reduction often results
in much slower reduction process and larger end result compared to allowing
some warnings but then fixing them up by hand where possible if it still
reproduces.

Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > From: Arsen Arsenović 
> > Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org
> > Date: Thu, 11 May 2023 21:25:53 +0200
> > 
> > >> This seems like a good route to me - it facilitates both veterans
> > >> maintaining code and beginners just learning how to write C.
> > >
> > > No, it prefers beginners (which already have the warnings, unless they
> > > deliberately turn them off) to veterans who know what they are doing,
> > > and can live with those warnings.
> > 
> > Indeed.  I said facilitates, not treats equally.  I think the veterans
> > here won't lose much by having to pass -fpermissive, and I think that's
> > a worthwhile sacrifice to make, to nurture the new without pressuring
> > the old very much.
> 
> Let's keep in mind that veterans are much more likely to have to deal
> with very large programs than newbies, and so dealing with breakage
> for them is much harder than doing that in a toy program.  Thus, the
> proposal does "pressure the old very much".

Pressure for something they should have done decades ago if the code was
really maintained.
Anyway, I don't understand why these 3 (implicit fn declarations,
implicit ints and int-conversions) are so different from anything that
one needs to change in codebases every year as documented in
gcc.gnu.org/gcc-NN/porting_to.html .  It is true that for C++ there are
more such changes than for C, but say GCC 12 no longer accepts
computed gotos with non-pointer types, GCC 10 changed default from
-fcommon to -fno-common for C which also affects dusty codebases
significantly, GCC 9 changed the lifetime of block scope compound literals
(again, affected various old codebases), GCC 5 broke bad user expectations
regarding preprocessor behavior by adding extra line markers to represent
whether certain tokens come from system headers or not, etc.
And of course compiler optimizations added every year can turn previously
"working" code with undefined behaviors in it into code not working as user
expected.  E.g. compared to the above 3 that are easily fixed, it is obvious
what the problem is, tracking undefined behavior in code even when one
has sanitizers etc. is much more time consuming.

Can we stop this thread.  I'm afraid everything has been said multiple
times, it is up to the GCC Steering Committee to decide this if there is
disagreement on it among GCC developers, but my current understanding is
that that is not the case here and that the active GCC developers agree on
it.

Jakub

Re: std::format not listed on the C++ Standards support page

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 06:45:55PM +0200, Jakub Jelinek via Gcc wrote:
> On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote:
> > Hello, just a note that support for std::format (P0645R10) does
> > not seem to be listed anywhere on the current C++ Standards
> > Support page (https://gcc.gnu.org/projects/cxx-status.html).
> > 
> > I was trying to figure out if it was supposed to be in the 12.3
> > release or not, but based on PR104166 I guess it's 13+ only. But
> > just in case anyone else is looking for this info... :)
> 
> It is a library feature, and https://gcc.gnu.org/projects/cxx-status.html
> only documents core language features.
> Library feature implementation status is documented in the libstdc++
> manual, so
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#manual.intro.status.iso

Though, that page hasn't been updated for std::format yet.
https://en.cppreference.com/w/cpp/compiler_support documents that though.

Jakub

Re: std::format not listed on the C++ Standards support page

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote:
> Hello, just a note that support for std::format (P0645R10) does
> not seem to be listed anywhere on the current C++ Standards
> Support page (https://gcc.gnu.org/projects/cxx-status.html).
> 
> I was trying to figure out if it was supposed to be in the 12.3
> release or not, but based on PR104166 I guess it's 13+ only. But
> just in case anyone else is looking for this info... :)

It is a library feature, and https://gcc.gnu.org/projects/cxx-status.html
only documents core language features.
Library feature implementation status is documented in the libstdc++
manual, so
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#manual.intro.status.iso

Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 11:36:10AM -0500, Joel Sherrill wrote:
> On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek  wrote:
> 
> > On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > > > 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
> > > >
> > >
> > > Thanks. We already  use -Wall which is documented to turn on the top two
> > > as warnings at least.
> > >
> > > Is int-conversion turned on as part of any of the more general -W
> > arguments
> > > (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> > > wondering
> > > if that was right or an oversight. Given this discussion, I would have
> > > expected it
> > > to be in -Wall.
> >
> > -Wint-conversion is enabled by default.  You get the warning whenever not
> > using -w or -Wno-int-conversion, and error with -pedantic-errors.
> >
> 
> Thanks. That isn't clear in the manual.
> 
> Is there a list of warnings included by default? I'm guessing that it might
> be all the ones where the manual lists only -Wno-ABC.
> 
> And again, I don't mind getting poked when the code does something
> questionable or undefined. Doesn't make it easy to fix or even magically
> give us all time to address the issues but better to know.

awk '/^W/{w=$1;getline;if ($0 ~ /Init\(1\)/)print w}' gcc/{,*/}*.opt | sort -u
Waddress-of-packed-member
Waggressive-loop-optimizations
Walign-commons
Wanalyzer-allocation-size
Wanalyzer-deref-before-check
Wanalyzer-double-fclose
Wanalyzer-double-free
Wanalyzer-exposure-through-output-file
Wanalyzer-exposure-through-uninit-copy
Wanalyzer-fd-access-mode-mismatch
Wanalyzer-fd-double-close
Wanalyzer-fd-leak
Wanalyzer-fd-phase-mismatch
Wanalyzer-fd-type-mismatch
Wanalyzer-fd-use-after-close
Wanalyzer-fd-use-without-check
Wanalyzer-file-leak
Wanalyzer-free-of-non-heap
Wanalyzer-imprecise-fp-arithmetic
Wanalyzer-infinite-recursion
Wanalyzer-jump-through-null
Wanalyzer-malloc-leak
Wanalyzer-mismatching-deallocation
Wanalyzer-null-argument
Wanalyzer-null-dereference
Wanalyzer-out-of-bounds
Wanalyzer-possible-null-argument
Wanalyzer-possible-null-dereference
Wanalyzer-putenv-of-auto-var
Wanalyzer-shift-count-negative
Wanalyzer-shift-count-overflow
Wanalyzer-stale-setjmp-buffer
Wanalyzer-tainted-allocation-size
Wanalyzer-tainted-array-index
Wanalyzer-tainted-assertion
Wanalyzer-tainted-divisor
Wanalyzer-tainted-offset
Wanalyzer-tainted-size
Wanalyzer-unsafe-call-within-signal-handler
Wanalyzer-use-after-free
Wanalyzer-use-of-pointer-in-stale-stack-frame
Wanalyzer-use-of-uninitialized-value
Wanalyzer-va-arg-type-mismatch
Wanalyzer-va-list-exhausted
Wanalyzer-va-list-leak
Wanalyzer-va-list-use-after-va-end
Wanalyzer-write-to-const
Wanalyzer-write-to-string-literal
Wattribute-alias=
Wattributes
Wattribute-warning
Wbuiltin-declaration-mismatch
Wbuiltin-macro-redefined
Wc++11-extensions
Wc++14-extensions
Wc++17-extensions
Wc++20-extensions
Wc++23-extensions
Wcannot-profile
Wchanges-meaning
Wclass-conversion
Wcomplain-wrong-lang
Wconversion-null
Wcoverage-invalid-line-number
Wcoverage-mismatch
Wcpp
Wdelete-incomplete
Wdeprecated
Wdeprecated-declarations
Wdesignated-init
Wdiscarded-array-qualifiers
Wdiscarded-qualifiers
Wdiv-by-zero
Wendif-labels
Wexceptions
Wfree-nonheap-object
Wif-not-aligned
Wignored-attributes
Winaccessible-base
Wincompatible-pointer-types
Winherited-variadic-ctor
Winit-list-lifetime
Wint-conversion
Winterference-size
Wint-to-pointer-cast
Winvalid-memory-model
Winvalid-offsetof
Wliteral-suffix
Wlto-type-mismatch
Wmissing-profile
Wmissing-requires
Wmissing-template-keyword
Wnonportable-cfstrings
Wnon-template-friend
WNSObject-attribute
Wobjc-root-class
Wodr
Woverflow
Woverride-init-side-effects
Woverwrite-recursive
Wpmf-conversions
Wpointer-compare
Wpointer-to-int-cast
Wpragmas
Wprio-ctor-dtor
Wproperty-assign-default
Wprotocol
Wpsabi
Wreturn-local-addr
Wscalar-storage-order
Wshadow-ivar
Wshift-count-negative
Wshift-count-overflow
Wsizeof-array-argument
Wstringop-overread
Wsubobject-linkage
Wswitch-bool
Wswitch-outside-range
Wswitch-unreachable
Wsync-nand
Wterminate
Wtsan
Wunderflow
Wunicode
Wunused-result
Wvarargs
Wvexing-parse
Wvirtual-move-assign
Wxor-used-as-pow

Of course, e.g. the -Wanalyzer* warnings are doing something only if
-fanalyzer, or say -Wtsan if -fsanitize=thread etc.

Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 06:30:40PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 May 2023 16:22:26 +0200
> > From: Jakub Jelinek 
> > Cc: Gabriel Ravier , jwakely@gmail.com,
> > fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me
> > 
> > > > Are you seriously saying that no accepts-invalid bug should ever be 
> > > > fixed under any circumstances on the basis that some programmers might 
> > > > rely on code exploiting that bug ??
> > > 
> > > Sorry, I'm afraid I don't understand the question.  What are
> > > "accepts-invalid bugs"?
> > 
> > They are bugs where compiler accepts something that isn't valid in
> > the selected language nor considered valid extension.
> > So, after the fix we reject something that has been accepted before.
> 
> If some program is plainly invalid, not just because the criteria of
> validity have shifted, then yes, such a program should be rejected.

Many of the accepts-invalid cases are when something used to be valid in some
older standard and is not valid in a newer standard, often even changes
meaning completely in even newer standard.
Examples include e.g. the auto keyword, which means something completely
different in C++11 and later than what it meant in C++98, or say comma in
array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 2)]
in C++17, got deprecated in C++20 and is ill-formed or changed meaning
in C++23 (multi-dimensional array operator).
Or any time something that wasn't a keyword in older standard version
and is a keyword in a newer standard.
alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23,
char16_t/char32_t/constexpr/decltype/noexcept in C++11,
constinit/consteval in C++20,
bool/false/true/typeof_unqual in C23.

int bool = 1;
is completely valid C17 if one doesn't include  header,
or
int static_assert = 2;
valid C17 if one doesn't include 
etc.  These used to compile and will no any longer wheen using -std=c2x or
in a few years when -std=gnu23 becomes the default will not compile by
default, even when it used to be valid C17.
And here are talking about code that wasn't valid already in C99...

Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > 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
> >
> 
> Thanks. We already  use -Wall which is documented to turn on the top two
> as warnings at least.
> 
> Is int-conversion turned on as part of any of the more general -W arguments
> (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> wondering
> if that was right or an oversight. Given this discussion, I would have
> expected it
> to be in -Wall.

-Wint-conversion is enabled by default.  You get the warning whenever not
using -w or -Wno-int-conversion, and error with -pedantic-errors.

Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 05:14:43PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 May 2023 14:41:27 +0200
> > Cc: jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org,
> >  ar...@aarsen.me
> > From: Gabriel Ravier 
> > 
> > >>> Because GCC is capable of compiling it.
> > >> That is not a good argument.  GCC is capable of compiling any code in all
> > >> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
> > >> mean those bugs shouldn't be fixed.
> > > Fixing those bugs, if they are bugs, is not the job of the compiler.
> > > It's the job of the programmer, who is the one that knows what the
> > > code was supposed to do.  If there's a significant risk that the code
> > > is a mistake or might behave in problematic ways, a warning to that
> > > effect is more than enough.
> > 
> > Are you seriously saying that no accepts-invalid bug should ever be 
> > fixed under any circumstances on the basis that some programmers might 
> > rely on code exploiting that bug ??
> 
> Sorry, I'm afraid I don't understand the question.  What are
> "accepts-invalid bugs"?

They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c&keywords=accepts-invalid&keywords_type=allwords&list_id=382024&query_format=advanced&resolution=FIXED&target_milestone=10.0&target_milestone=10.2&target_milestone=10.3&target_milestone=10.4&target_milestone=10.5&target_milestone=11.0&target_milestone=11.2&target_milestone=11.3&target_milestone=11.4&target_milestone=11.5&target_milestone=12.0&target_milestone=12.2&target_milestone=12.3&target_milestone=12.4&target_milestone=12.5&target_milestone=13.0
82 such bugs in C++:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c%2B%2B&keywords=accepts-invalid&keywords_type=allwords&list_id=382025&query_format=advanced&resolution=FIXED&target_milestone=10.0&target_milestone=10.2&target_milestone=10.3&target_milestone=10.4&target_milestone=10.5&target_milestone=11.0&target_milestone=11.2&target_milestone=11.3&target_milestone=11.4&target_milestone=11.5&target_milestone=12.0&target_milestone=12.2&target_milestone=12.3&target_milestone=12.4&target_milestone=12.5&target_milestone=13.0
and a couple in other languages.

E.g. today I've committed a C++ FE fix, where we erroneously accepted
e.g.
template 
[[noreturn...]]
int foo ();
and handled it as if the ... after the attribute wasn't present.
In this case also you were able to compile such code in the past GCC
versions and it will not compile in G++ 14.1 anymore.

What we are talking in this thread is also something not valid in C99 or
later, for the int-conversion stuff not even valid in C89, in the past
accepted just for K&R legacy reasons.

Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 02:30:07PM +0300, Eli Zaretskii wrote:
> > From: Jonathan Wakely 
> > Date: Wed, 10 May 2023 09:04:12 +0100
> > Cc: Florian Weimer , "gcc@gcc.gnu.org" 
> > , 
> > Jakub Jelinek , Arsen Arsenović 
> > 
> > void foo(int);
> > void bar() { foo("42"); }
> > 
> > Why should this compile?
> 
> Because GCC is capable of compiling it.

That is not a good argument.  GCC is capable of compiling any code in all
the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
mean those bugs shouldn't be fixed.

C99 for the above says:
6.5.2.2/7
"If the expression that denotes the called function has a type that does 
include a prototype,
the arguments are implicitly converted, as if by assignment, to the types of the
corresponding parameters, taking the type of each parameter to be the 
unqualified version
of its declared type."
and
"One of the following shall hold:
— the left operand has qualified or unqualified arithmetic type and the right 
has
arithmetic type;
— the left operand has a qualified or unqualified version of a structure or 
union type
compatible with the type of the right;
— both operands are pointers to qualified or unqualified versions of compatible 
types,
and the type pointed to by the left has all the qualifiers of the type pointed 
to by the
right;
— one operand is a pointer to an object or incomplete type and the other is a 
pointer to a
qualified or unqualified version of void, and the type pointed to by the left 
has all
the qualifiers of the type pointed to by the right;
— the left operand is a pointer and the right is a null pointer constant; or
— the left operand has type _Bool and the right is a pointer."
For the above case, none of that holds and it isn't something desirable to
be supported as GNU extension, because while it could happen to work as the
user wanted after cast back to pointer in foo on ilp32 architectures, it
doesn't make any sense on lp64 or llp64 architectures.

Note, this isn't valid even in C89 and is already rejected with
-pedantic-errors for years.
The proposal is essentially to stop accepting this as a GNU extension
which was added for K&R compatibility I assume and do that only for C99 and
later.

> It compiles today with a warning, so that whoever is interested to fix
> the code, can do that already.  The issue at hand is not whether to
> flag the code as highly suspicious, the issue at hand is whether
> upgrade the warning to errors.  So let's talk about the issue at hand,
> not about something else, okay?

We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.
Yes, it is done far less in C, but still, as the above is invalid already in
C89, users had over 3 decades to fix their code, and in many cases they
didn't and without this move they will never bother.
A lot of such broken code has been even written in those 3 decades, doesn't
predate it, but because the compiler just warned on it, it still appeared in
the code bases.  If we wait with this change another 2 decades, nothing will
change and we'll have the same problem then.

Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
> > From: Jonathan Wakely 
> > Date: Tue, 9 May 2023 18:15:59 +0100
> > Cc: Arsen Arsenović , gcc@gcc.gnu.org
> > 
> > On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
> > >
> > > 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.
> > 
> > People ignore warnings. That's why the problems have gone unfixed for
> > so many years, and will continue to go unfixed if invalid code keeps
> > compiling.
> 
> People who ignore warnings will use options that disable these new
> errors, exactly as they disable warnings.  So we will end up not

Some subset of them will surely do that.  But I think most people will just
fix the code when they see hard errors, rather than trying to work around
them.

Jakub

Re: End of subscription

[Jakub Jelinek via Gcc]

On Tue, May 09, 2023 at 09:44:08PM +0530, Ruchit Raushan via Gcc wrote:
> Don't want to receive further emails.

Each mail on the mailing list tells that in the headers:
List-Unsubscribe: ,

  


Jakub

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

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?

Jakub

Re: GCC 12.3 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

On Thu, May 04, 2023 at 10:31:21AM -0400, Jason Merrill via Gcc wrote:
> My patch for 106890 caused 109666, so I'd like to revert the 106890 patch
> (r12-9441-g94569d91bd4c60) for 12.3.

Ok.
Guess we should do RC2 either tonight or tomorrow then, there are I think
2 other commits that could get some wider testing as well.

Jakub

Re: Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20

[Jakub Jelinek via Gcc]

On Thu, Apr 27, 2023 at 11:35:23AM +0200, Helmut Zeisel wrote:
> >Von: "Jakub Jelinek" 
> >An: "Helmut Zeisel" 
> >Cc: gcc@gcc.gnu.org
> >Betreff: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20
> >On Thu, Apr 27, 2023 at 11:09:19AM +0200, Helmut Zeisel via Gcc wrote:
> >> I compiled GCC 13.1.0 with GCC 12 and had the environment variable 
> >> CXXFLAGS set to -std=c++20
> >> This gives the error (both linux and cygin)
> >>
> >> gcc-13.1.0/libstdc++-v3/src/c++98/bitmap_allocator.cc:51:23: error: ISO 
> >> C++17 does not allow dynamic exception specifications
> >> 51 | _M_get(size_t __sz) throw(std::bad_alloc)
> >>
> >> After
> >>
> >> unset CXXFLAGS
> >>
> >> compilation works
> 
> >Don't do it. 
> 
> Dont do *what*?
> export CXXFLAGS=... ?

Include explicit -std= settings in such exported variables, especially when
building GCC.  Packages should decide themselves in which language version
they are written in, or if they are written in common subset, they should
just defer to the compiler default.
Note, doing that would break building even much older GCC versions.

> unset CXXFLAGS ?
> Compile GCC 13 with GCC 12?

Jakub

Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20

[Jakub Jelinek via Gcc]

On Thu, Apr 27, 2023 at 11:09:19AM +0200, Helmut Zeisel via Gcc wrote:
> I compiled GCC 13.1.0 with GCC 12 and had the environment variable CXXFLAGS 
> set to -std=c++20
> This gives the error (both linux and cygin)
> 
> gcc-13.1.0/libstdc++-v3/src/c++98/bitmap_allocator.cc:51:23: error: ISO C++17 
> does not allow dynamic exception specifications
>51 |   _M_get(size_t __sz) throw(std::bad_alloc)
> 
> After
> 
>unset CXXFLAGS
> 
> compilation works

Don't do it.  libstdc++ carefully decides which parts of it should be
compiled by which C++ standard version.  By forcing it to use
something it wasn't designed to work with you are breaking its assumptions.
Obviously  c++98 code can use C++98 features...

Jakub

Second GCC 13.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The second release candidate for GCC 13.1 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC2-20230419/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC2-20230419/

and shortly its mirrors.  It has been generated from git commit
r13-7226-g68997d4323cdcb.

The https://gcc.gnu.org/PR108969 fix didn't work out as intended,
so we had to revert the changes.  Please don't use the first
GCC 13.1 release candidate for anything, it contains symbols
13.1 final release will not contain.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, we'd still like to release 13.1 on Wednesday, April 26th.

GCC 13.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The first release candidate for GCC 13.1 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC-20230419/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC-20230419/

and shortly its mirrors.  It has been generated from git commit
r13-7224-g865d712a9a20ee.

I have so far bootstrapped and tested the release candidate on
x86_64-linux, i686-linux, powerpc64le-linux and aarch64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 13.1 on Wednesday, April 26th.

GCC 14.0.0 Status Report (2023-04-17)

[Jakub Jelinek via Gcc]

Status
==

The trunk has branched for the GCC 13 release and is now open
again for general development, stage 1.  Please consider not
disrupting it too much during the RC phase of GCC 13 so it
is possible to test important fixes for 13.1 on it.


Quality Data


Priority  #   Change from last report
---   ---
P10   -  32
P2  494   +   2
P3   57   -  20
P4  241   -  14
P5   24
---   ---
Total P1-P3 551   -  50
Total   816   -  64


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-February/240765.html

GCC 13.0.1 Status Report (2023-04-17)

[Jakub Jelinek via Gcc]

Status
==

We have reached zero P1 regressions today and releases/gcc-13 branch has
been created.  GCC 13.1-rc1 will be built likely tomorrow.
The branch is now frozen for blocking regressions and documentation
fixes only, all changes to the branch require a RM approval now.

If no show stoppers appear, we'd like to release 13.1 next week,
or soon after that, if any important issues are discovered and
fixed, rc2 could be released next week.


Quality Data


Priority  #   Change from last report
---   ---
P10   -  32
P2  492
P3   57   -  20
P4  241   -  14
P5   24
---   ---
Total P1-P3 549   -  52
Total   814   -  66


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-February/240765.html

Re: [GSoC] gccrs Unicode support

[Jakub Jelinek via Gcc]

On Sat, Mar 18, 2023 at 05:59:34PM +0900, Raiki Tamura wrote:
> 2023年3月18日(土) 17:47 Jonathan Wakely :
> 
> > On Sat, 18 Mar 2023, 08:32 Raiki Tamura via Gcc,  wrote:
> >
> >> Thank you everyone for your advice.
> >> Some kinds of names are restricted to unicode alphabetic/numeric in Rust.
> >>
> >
> > Doesn't it use the same rules as C++, based on XID_Start and XID_Continue?
> > That should already be supported.
> >
> 
> Yes, C++ and Rust use the same rules for identifiers (described in UAX#31)
> and we can reuse it in the lexer of gccrs.
> I was talking about values of Rust's crate_name attributes, which only
> allow Unicode alphabetic/numeric characters.
> (Ref:
> https://doc.rust-lang.org/reference/crates-and-source-files.html#the-crate_name-attribute
> )

That is a pretty simple thing, so no need to use an extra library for that.
As is documented in contrib/unicode/README, the Unicode *.txt files are
already checked in and there are several generators of tables.
libcpp/makeucnid.cc already creates tables based on the
UnicodeData.txt DerivedNormalizationProps.txt DerivedCoreProperties.txt
files, including NFC/NKFC, it is true it doesn't currently compute
whether a character is alphanumeric.  That is either Alphabetic
DerivedCoreProperties.txt property, or for numeric Nd, Nl or No category
(3rd column) in UnicodeData.txt.  Should be a few lines to add that support
to libcpp/makeucnid.cc, the only question is if it won't make the ucnranges
array much larger if it differentiates based on another ALPHANUM flag.
If it doesn't grow too much, let's put it there, if it would grow too much,
perhaps we should emit it in a separate table.

Jakub

Re: [GSoC] gccrs Unicode support

[Jakub Jelinek via Gcc]

On Thu, Mar 16, 2023 at 01:58:57PM +0100, Mark Wielaard wrote:
> On Thu, 2023-03-16 at 10:28 +0100, Thomas Schwinge wrote:
> > I'm now also putting Mark Wielaard in CC; he once also started discussing
> > this topic, "thinking of importing a couple of gnulib modules to help
> > with UTF-8 processing [unless] other gcc frontends handle [these things]
> > already in a way that might be reusable".  See the thread starting at
> > 
> > "rust frontend and UTF-8/unicode processing/properties".
> 
> Thanks. BTW. I am not currently working on this.
> Note the responses in the above thread by Ian and Jason who pointed out
> that some of the requirements of the gccrs frontend might be covered in
> the go frontend and libcpp, but not really in a reusable way.

libcpp can be certainly linked into the gccrs FE and specific functions
called from it even if libcpp isn't used as a preprocessor for the language.
Small changes to libcpp are obviously possible as well to make it work.

Jakub

Re: [GSoC] gccrs Unicode support

[Jakub Jelinek via Gcc]

On Wed, Mar 15, 2023 at 11:00:19AM +, Philip Herron via Gcc wrote:
> Excellent work on getting up to speed on the rust front-end. From my
> perspective I am interested to see what the wider GCC community thinks
> about using https://www.gnu.org/software/libunistring/ library within GCC
> instead of rolling our own, this means it will be another dependency on GCC.
> 
> The other option is there is already code in the other front-ends to do
> this so in the worst case it should be possible to extract something out of
> them and possibly make this a shared piece of functionality which we can
> mentor you through.

I don't know what exactly Rust FE needs in this area, but e.g. libcpp
already handles whatever C/C++ need from Unicode support POV and can handle
it without any extra libraries.
So, if we could avoid the extra dependency, it would be certainly better,
unless you really need massive amounts of code from those libraries.
libcpp already e.g. provides mapping of unicode character names to code
points, determining which unicode characters can appear at the start or
in the middle of identifiers, etc.

Jakub

Re: POWER __builtin_add_overflow/__builtin_mul_overflow with u64

[Jakub Jelinek via Gcc]

Hi!

CCing Segher and David on this.
rs6000 indeed doesn't implement {,u}{add,sub,mul}v4_optab for
any mode and thus leaves it to the generic code.

On Tue, Feb 14, 2023 at 04:48:42AM +0100, Simon Richter wrote:
> I'm looking at the generated code for these builtins on POWER:
> 
> add 4,3,4
> subfc 3,3,4
> subfe 3,3,3
> std 4,0(5)
> rldicl 3,3,0,63
> blr
> 
> and
> 
> mulld 10,3,4
> mulhdu 3,3,4
> addic 9,3,-1
> std 10,0(5)
> subfe 3,9,3
> blr
> 
> The POWER architecture has variants of these instructions with builtin
> overflow checks (addo/mulldo), but these aren't listed in the .md files, and
> the builtins don't generate them either.
> 
> Is this intentional (I've found a few comments that mulldo is microcoded on
> CellBE and should be avoided there)?

Jakub

Re: libquadmath, glibc, and the Q format flag

[Jakub Jelinek via Gcc]

On Wed, Feb 01, 2023 at 12:29:02PM +0100, Florian Weimer via Gcc wrote:
> >> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
> >> depends on libquadmath.
> >
> > Not anymore.
> > If GCC is configured against new enough glibc (with _Float128 support)
> > libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
> > is added only --as-needed to ld command line, so if all the Fortran object
> > files that need real(kind=16) (or quad complex) are built by such configured
> > GCC, -lquadmath is not linked in (just needs to be present).
> 
> Hmm, I missed that recent change.
> 
> Would it make sense to drop the libgfortran RPM dependency on
> libquadmath in Fedora rawhide?

This is a downstream question.
We could drop it from libgfortran (package that contains just the shared
library), but we still need it on gcc-gfortran (as the library is used
during linking for backwards compatibility reasons).

Jakub

Re: libquadmath, glibc, and the Q format flag

[Jakub Jelinek via Gcc]

On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
> I recently discovered that libquadmath registers custom printf callbacks
> on load.  As far as I can tell, this is done so that the Q format flag
> can be used to print floating point numbers, using format strings such
> as "%Qf".  To enable Q flag processing, libquadmath has to register
> replacements for all floating point format specifiers (aAeEfFgG).
> 
> Unfortunately, this has the side effect that even with out the Q flag,
> printing any floating point number enters a generic, slow path in glibc,
> prior to the number formatting itself.  The effect is quite pronounced.
> For example this admittedly silly benchmarking script
> 
> for i=1,500 do
> print(i, i * math.pi)
> end
> 
> runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
> system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
> seconds.
> 
> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
> depends on libquadmath.

Not anymore.
If GCC is configured against new enough glibc (with _Float128 support)
libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
is added only --as-needed to ld command line, so if all the Fortran object
files that need real(kind=16) (or quad complex) are built by such configured
GCC, -lquadmath is not linked in (just needs to be present).
And, even for C, users can just use the standard glibc _Float128 support
(if they don't mind strfromf128) if they target new enough glibc.
So, libquadmath should be left over for non-glibc uses or uses with old
glibc.

> Would it make sense to transplant the implementation of the Q specifier
> from libquadmath to glibc, and disable the registration code in
> libquadmath if glibc is recent enough?  At least for the targets that
> today have float128 support in glibc?

Thus I'm not sure it is worth it.

Jakub

Re: struct sockaddr_storage

[Jakub Jelinek via Gcc]

On Mon, Jan 23, 2023 at 05:03:00PM +0100, Alejandro Colomar via Gcc wrote:
> Hi Stefan,
> 
> On 1/23/23 08:40, Stefan Puiu wrote:
> > > > > According to strict aliasing rules, if you declare a variable of type 
> > > > > 'struct
> > > > > sockaddr_storage', that's what you get, and trying to access it later 
> > > > > as some
> > > > > other sockaddr_8 is simply not legal.  The compiler may assume those 
> > > > > accesses
> > > > > can't happen, and optimize as it pleases.
> > > > 
> > > > Can you detail the "is not legal" part?
> > > 
> > > I mean that it's Undefined Behavior contraband.
> > 
> > OK, next question. Is this theoretical or practical UB?
> 
> 
> Since the functions using this type are not functions that should be
> inlined, since the code is rather large, they are not visible to the
> compiler, so many of the optimizations that this UB enables are not likely
> to happen.  Translation Unit (TU) boundaries are what keeps most UB
> invokations not be really dangerous.
> 
> Also, glibc seems to be using a GCC attribute (transparent_union) to make
> the code avoid UB even if it were inlined, so if you use glibc, you're fine.
> If you're using some smaller libc with a less capable compiler, or maybe
> C++, you are less lucky, but TU boundaries will probably still save your
> day.

Please see transparent_union documentation in GCC documentation.
E.g. 
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Type-Attributes.html#index-transparent_005funion-type-attribute
transparent_union doesn't change anything regarding type punning, it is
solely about function arguments, how arguments of that type are passed
(as first union member) and that no casts to the union are needed from
the member types.
And, with LTO TU boundaries are lost, inlining or other IPA optimizations
(including say modref) work in between TUs.

Jakub

Re: GOMP: OMP 5.1: simd construct for non-pointer random access iterators

[Jakub Jelinek via Gcc]

On Thu, Dec 15, 2022 at 09:31:50PM +0100, Grosse-Bley, Paul Leonard wrote:
> 
> Hi together,
> 
> I just ran into the issue that `#pragma omp simd` does not work on C++ 
> iterator loops (godbolt).
> >From going through the specifications I understand that this restriction was 
> >part of 4.5 and 5.0, but was dropped with 5.1.
> As I couldn't find this change in the table of 5.1 (or 5.2) features for 
> libgomp, I wanted to ask if this is on the horizon.

That is not the case.
OpenMP 5.1 has the restriction on p. 137 l. 22:
"The only random access iterator types that are allowed for the associated 
loops are pointer
types."
OpenMP 5.2 has the same thing on p. 235 l. 31.
Even TR11 (first OpenMP 6.0 draft) has the same wording on p. 246 l. 2.

Jakub