[Bug target/91982] gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91982

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Probably started with r276299 ?

We segfault in vect_transform_stmt in call to dominated_by_p:

  if (!slp_node && STMT_VINFO_REDUC_DEF (orig_stmt_info)
  && STMT_VINFO_REDUC_TYPE (orig_stmt_info) != FOLD_LEFT_REDUCTION
  && is_a  (STMT_VINFO_REDUC_DEF (orig_stmt_info)->stmt))
{
  gphi *phi = as_a  (STMT_VINFO_REDUC_DEF (orig_stmt_info)->stmt);
  if (dominated_by_p (CDI_DOMINATORS,
  gimple_bb (orig_stmt_info->stmt), gimple_bb (phi)))
{

because gimple_bb (orig_stmt_info->stmt) is NULL.

Thanks,
Prathamesh

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #27 from Stas Sergeev  ---
(In reply to jos...@codesourcery.com from comment #26)
> On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
> 
> > Ah, I am starting to understand.
> > So basically you mean something like this:
> > --with-sysroot=$prefix/$target --with-build-sysroot=$DESTDIR$prefix/$target
> > --with-prefix=/
> 
> It's --with-native-system-header-dir=/include not --with-prefix=/, but 
> that's the idea.

Ah, yes, indeed.
So can I assume that in the -isystem path and -B path,
the sysroot part will be swapped with the build_sysroot
during build? If so, then I would finally understand your
sysroot suggestion.

But there are still 2 more suggestions, yours and mine,
and I am not sure what is to do with them. I think your
suggestion is to add something like --with-build-time-prefix
to be able to specify the alternative location of headers
and libs for non-sysroot build.
Mine is to add --with-build-time-compiler=dir.
I think we can have both, and I can try to implement mine
(--with-build-time-compiler) if you think this is acceptable
(i.e. the _possibility_ to add an extra build stage is acceptable).

[Bug other/81334] -Wmisleading-indentation prints notes about being disabled even when already intentionally ignored

[david.bolvansky at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81334

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #4 from Dávid Bolvanský  ---
Two years passed and no fix :( Can somebody look at it?

[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #26 from joseph at codesourcery dot com  ---
On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:

> Ah, I am starting to understand.
> So basically you mean something like this:
> --with-sysroot=$prefix/$target --with-build-sysroot=$DESTDIR$prefix/$target
> --with-prefix=/

It's --with-native-system-header-dir=/include not --with-prefix=/, but 
that's the idea.

[Bug middle-end/91977] missing -Wstringop-overflow on memcpy into a pointer plus offset

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91977

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00258.html

[Bug tree-optimization/91986] New: missed loop unrolling optimization

[trass3r at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91986

Bug ID: 91986
   Summary: missed loop unrolling optimization
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trass3r at gmail dot com
  Target Milestone: ---

#include 
#include 
const int N = 4;
void bitreverse(int* data)
{
uint32_t j = 0;
for (uint32_t i = 0; i < N; ++i)
{
if (j > i)
std::swap(data[i], data[j]);

uint32_t k = N/2;
while (k <= j)
{
j -= k;
k /= 2;
}
j += k;
}
}

Even with -O3 gcc doesn't fully unroll the loop but still there are quite some
redundant instructions: https://godbolt.org/z/cA-S8J
It's similar with N=8: https://godbolt.org/z/niZPeS

Interestingly if you change the swap line slightly clang suddenly starts using
pshufd which seems quite clever: https://godbolt.org/z/5YJnJ1

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #25 from Stas Sergeev  ---
(In reply to jos...@codesourcery.com from comment #24)
> > But isn't there always a possibility to add
> > one more stage? Say, in the example above where
> > at stage1 we only have a static-only compiler,
> > we could add stage2 and stage3. stage2 is a fully-featured
> > compiler to build stage3. I think this approach
> > will always work, just use N+1 stages.
>
> It's desirable to reduce the number of stages, not increase it.

I think it depends. :) So if someone wants to
increase the amount of stages, why not to support
also that, together with the approaches you propose.
To me, its all about flexibility.

> (Bootstrapping such a GNU/Linux toolchain used to take three stages, which 
> was successfully reduced to two by fixing glibc to build with the 
> first-stage GCC.)

Reduced amount of stages is also good to support. :)
Why not to implement both ways?

> The --with-build-sysroot option gives the location of a directory that 
> uses the sysroot layout, which is not the same as that of a non-sysroot 
> $exec_prefix/$target - unless your non-sysroot layout does not use /usr.
> 
> If you set up the toolchain so that it thinks /include rather than 
> /usr/include is the native system header directory, then you can use 
> --with-sysroot and --with-build-sysroot without any temporary usr -> . 
> symlinks.

Ah, I am starting to understand.
So basically you mean something like this:
--with-sysroot=$prefix/$target --with-build-sysroot=$DESTDIR$prefix/$target
--with-prefix=/

This way we simulate the cross-layout and also are
changing the build pathes of headers and libs at once.
And if we use the default prefix, /usr, then we'd also
need to symlink everything back to $sysroot/ because,
while buildable even w/o the symlinks, we'll get the
wrong target layout, right? In which case we can add
the symlinks after the build is completed, correct?

> Those -isystem paths are the *non-sysroot* kind of paths for headers
> for a cross compiler.

So do you mean that on a sysroot build those -isystem
will look much differently? How exactly? Or will they look
similar but alterable with --with-build-sysroot? Knowing how
-isystem will behave in a sysroot case is the last piece of
the puzzle for me concerning your suggested solution.

So your suggestion is to have some option like --with-build-time-prefix,
which can be set to $DESTDIR$prefix, right? In this case
the compiler will replace $exec_prefix/$target with
$build_time_prefix/$target during build, right?

But the question is still, why not to support both
ways, if adding an extra stage is also the legal and
simple way of getting the work done.

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243

--- Comment #9 from Iain Sandoe  ---
*** Bug 57753 has been marked as a duplicate of this bug. ***

[Bug target/57753] FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Iain Sandoe  ---
closing this as a dup of 87243 (we now handle SDKROOT, and any other issues can
be picked up there)

*** This bug has been marked as a duplicate of bug 87243 ***

[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #24 from joseph at codesourcery dot com  ---
On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
> 
> --- Comment #23 from Stas Sergeev  ---
> (In reply to jos...@codesourcery.com from comment #22)
> > On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
> > And overriding like that is fundamentally unsafe, because in general in a 
> > multi-stage build (such as for a cross to GNU/Linux where the first stage 
> > is a static-only C-only compiler) the libraries have to be built with the 
> > more-fully-featured compiler built in the same stage - not with the 
> > previous stage's compiler.
> 
> But isn't there always a possibility to add
> one more stage? Say, in the example above where
> at stage1 we only have a static-only compiler,
> we could add stage2 and stage3. stage2 is a fully-featured
> compiler to build stage3. I think this approach
> will always work, just use N+1 stages.

It's desirable to reduce the number of stages, not increase it.  
(Bootstrapping such a GNU/Linux toolchain used to take three stages, which 
was successfully reduced to two by fixing glibc to build with the 
first-stage GCC.)

> > Then maybe an option is needed to find both headers and libraries in the 
> > non-sysroot case (where the option for libraries gives the top-level 
> > directory under which subdirectories for each multilib, using the multilib 
> > OS suffix, can be found).  An option to find the build-time equivalent of 
> > $exec_prefix/$target, with lib and include subdirectories, say.
> 
> And then why such an option is not called --with-build-sysroot?
> In comment #11 you say
> "there is no non-sysroot-headers equivalent of --with-build-sysroot",
> but I don't understand what do you mean. Can we use --with-build-sysroot
> w/o --with-sysroot, making it exactly an option you describe
> above?

The --with-build-sysroot option gives the location of a directory that 
uses the sysroot layout, which is not the same as that of a non-sysroot 
$exec_prefix/$target - unless your non-sysroot layout does not use /usr.

If you set up the toolchain so that it thinks /include rather than 
/usr/include is the native system header directory, then you can use 
--with-sysroot and --with-build-sysroot without any temporary usr -> . 
symlinks.  Otherwise, you can still use them, but need such symlinks 
during the build process.  That is, --with-build-sysroot already works for 
the sort of thing you want to do, provided (a) you have the usr -> . 
symlink and (b) you configure using --with-sysroot even though it's 
logically not a sysrooted toolchain.

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769

--- Comment #7 from Aurelien Jarno  ---
Thanks a lot for the fix. Would it be possible to backport it to the GCC 9
branch? Note that it requires backporting r273174 first.

[Bug c/91985] New: Unsupported DFP not diagnosed with constants or built-in functions

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985

Bug ID: 91985
   Summary: Unsupported DFP not diagnosed with constants or
built-in functions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

Code that directly uses _Decimal* types on architectures not supporting DFP is
properly diagnosed ("error: decimal floating-point not supported for this
target"), via a call to targetm.decimal_float_supported_p, if the _Decimal32,
_Decimal64 or _Decimal128 keywords are used to access it.  Use via mode
attributes is also diagnosed ("unable to emulate 'SD'").  However, it is
possible to access those types via typeof applied to constants or built-in
functions without such an error.

typedef __typeof (__builtin_fabsd32 (0)) D32;
D32 f (D32 x, D32 y) { return x + y; }

or

typedef __typeof (1.0DF) D32;
D32 f (D32 x, D32 y) { return x + y; }

I'm sure there are ways to get an ICE from this; I didn't try; when it does
compile, of course it uses a completely undefined ABI.

All ways of accessing DFP types should give an error on targets that don't
support DFP.

For built-in functions, the question of whether they should be available in
such cases might be related to that for C++ and _Float* types (bug 85518).

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #23 from Stas Sergeev  ---
(In reply to jos...@codesourcery.com from comment #22)
> On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
> And overriding like that is fundamentally unsafe, because in general in a 
> multi-stage build (such as for a cross to GNU/Linux where the first stage 
> is a static-only C-only compiler) the libraries have to be built with the 
> more-fully-featured compiler built in the same stage - not with the 
> previous stage's compiler.

But isn't there always a possibility to add
one more stage? Say, in the example above where
at stage1 we only have a static-only compiler,
we could add stage2 and stage3. stage2 is a fully-featured
compiler to build stage3. I think this approach
will always work, just use N+1 stages.

> Then maybe an option is needed to find both headers and libraries in the 
> non-sysroot case (where the option for libraries gives the top-level 
> directory under which subdirectories for each multilib, using the multilib 
> OS suffix, can be found).  An option to find the build-time equivalent of 
> $exec_prefix/$target, with lib and include subdirectories, say.

And then why such an option is not called --with-build-sysroot?
In comment #11 you say
"there is no non-sysroot-headers equivalent of --with-build-sysroot",
but I don't understand what do you mean. Can we use --with-build-sysroot
w/o --with-sysroot, making it exactly an option you describe
above?

> The build system design is that where A and B are both built at the same 
> time, and the build of B uses A, it should use the *newly built* copy of A

Lets do A --> B' --> B then. :)

> "make all-target-libstdc++-v3" or whatever).  In general, if you don't 
> want to build with the newly built copy of A you should configure and 
> build in such a way that there isn't a newly built copy of A at all.

Mm, yes, I was thinking about renaming the dirs
during build to hide stuff from configure, but
decided against doing so as being too hackish.
Would you suggest this way for the wide adoption?

[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #22 from joseph at codesourcery dot com  ---
On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:

> - The stage2 compiler is built with --prefix=/usr and
> installed with the DESTDIR set to the build dir. As the
> result, this stage2 compiler can't build its libs! (libgcc, libstdc++)
> It can't build its libs because it is never installed
> into its prefix dir on host, and so I override its
> in-tree tools with the ones from the stage1 compiler.

And overriding like that is fundamentally unsafe, because in general in a 
multi-stage build (such as for a cross to GNU/Linux where the first stage 
is a static-only C-only compiler) the libraries have to be built with the 
more-fully-featured compiler built in the same stage - not with the 
previous stage's compiler.

> > A plausible approach to fixing that if you can't use sysroots is to add a 
> > a new configure option whose purpose is to point to the build-time 
> > non-sysroot location of headers that should be used in building target 
> > libraries.
> 
> I think I tried this already, see comment #10.
> I did a hack to change the header pathes. And
> that worked, but then there are those -B options
> that prevented the libs from being found during
> configure process. So I found the change-headers-path

Then maybe an option is needed to find both headers and libraries in the 
non-sysroot case (where the option for libraries gives the top-level 
directory under which subdirectories for each multilib, using the multilib 
OS suffix, can be found).  An option to find the build-time equivalent of 
$exec_prefix/$target, with lib and include subdirectories, say.

The build system design is that where A and B are both built at the same 
time, and the build of B uses A, it should use the *newly built* copy of A 
as long as that is for $host = $build.  That applies for in-tree binutils 
(to the extent that anyone still builds those in a unified tree), and for 
in-tree host parts of GCC, and for in-tree libgcc when other target 
libraries use it, and so on - it's the universal design in the build 
system for all such dependencies.

It may be possible to hack things up to allow configuring and building an 
individual target library with an installed compiler, but that's a case 
where the tree in which you build that library is *not* one in which 
you've built host GCC at all (and then you pass a load of variables to 
"make all-target-libstdc++-v3" or whatever).  In general, if you don't 
want to build with the newly built copy of A you should configure and 
build in such a way that there isn't a newly built copy of A at all.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #21 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Thanks bug report and extending patch to cover
SNGL and DBLE.  Note, the committed patch also disables warnings
for -Wconversion-extra.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #20 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct  3 20:46:26 2019
New Revision: 276532

URL: https://gcc.gnu.org/viewcvs?rev=276532=gcc=rev
Log:
2019-10-03  Steven G. Kargl  

PR fortran/91497
* simplify.c (gfc_simplify_dble, simplify_intconv, gfc_simplify_real,
gfc_simplify_sngl): Disable -Wconversion and -Wconversion-extra
warnings for explicit conversion of literal constants.

2019-10-03  Steven G. Kargl  

PR fortran/91497
* gfortran.dg/pr91497.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91497.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-03
 Ever confirmed|0   |1
   Severity|normal  |enhancement

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #21 from Stas Sergeev  ---
Hi Joseph, thanks for your assistance!

(In reply to jos...@codesourcery.com from comment #20)
> The only case where the newly built GCC should be overridden is the 
> Canadian cross case,

Since today, this is no longer true. :)
https://code.launchpad.net/~stsp-0/+recipe/djgpp-daily
I managed to get the build working, and this build
only works when possibility exist to override the
in-tree tools.
It works as follows:
- The stage1 cross-compiler is built with --prefix=${DESTDIR}${stash_area}
and installed with DESTDIR unset (it is already in the prefix).
This is a non-sysroot build so it can work on host.
- The stage2 compiler is built with --prefix=/usr and
installed with the DESTDIR set to the build dir. As the
result, this stage2 compiler can't build its libs! (libgcc, libstdc++)
It can't build its libs because it is never installed
into its prefix dir on host, and so I override its
in-tree tools with the ones from the stage1 compiler.

> Your problem as originally described was with finding non-sysroot headers.

Yes, I attempted the 1-stage build back then.
But why not to support the 2-stage build, as this is
what I already have? It only required a tiny patch
above, and since it can't be applied as-is, I can take
a look into making it a separate option. What I want to
point out is that there is already the use for such option,
because it is already used in my build (in the form of
the --with-build-time-tools hack for now, but can be extended).

> A plausible approach to fixing that if you can't use sysroots is to add a 
> a new configure option whose purpose is to point to the build-time 
> non-sysroot location of headers that should be used in building target 
> libraries.

I think I tried this already, see comment #10.
I did a hack to change the header pathes. And
that worked, but then there are those -B options
that prevented the libs from being found during
configure process. So I found the change-headers-path
approach infeasible and implemented a 2-stage solution.
Do you still think that the path-altering games
can lead to a solution?
And since I already succeeded with overriding the
in-tree tools, why not to implement that route as
a new configure option? It looks very simple.

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243

--- Comment #8 from Iain Sandoe  ---
Author: iains
Date: Thu Oct  3 20:19:18 2019
New Revision: 276530

URL: https://gcc.gnu.org/viewcvs?rev=276530=gcc=rev
Log:
[Darwin] Pick up SDKROOT as the sysroot fallback.

For compatibility with xcrun and the behaviour of the clang driver, make use
of the setting of the SDKROOT environment variable when it is available.
This applies to both finding headers and libraries (i.e. it is also passed to
ld64).

Priority:
 1. User's command-line specified --sysroot= or -isysroot.
 2. The SDKROOT variable when set, and validated.
 3. Any sysroot provided by --with-sysroot= configuration parameter.

SDKROOT is checked thus:
  1. Presence.
  2. That it starts with "/" (i.e. 'absolute').
  3. That it is not "/" only (since that's the default).
  4. That it is readable by the process executing the driver.

This is pretty much the same rule set as used by the clang driver.

NOTE: (3) might turn out to be overly restrictive in the case that we
have configured with --with-sysroot= and then we want to run on a system
with an installation of the headers/libraries in /.  We can revisit this
if that turns out to be an important use-case.

So one can do:

xcrun --sdk macosx /path/to/gcc 

and that provides the SDK path as the sysroot to GCC as expected.

CAVEAT: An unfortunate effect of the fact that "gcc" (and "g++") are
executables in the Xcode installation, which are found ahead of any such
named in the $PATH:

PATH=/path/to/gcc/install:$PATH
xcrun --sdk macosx gcc  

does *not* work, instead that executes the clang from the xcode/commmand
line tools installation.

PATH=/path/to/gcc/install:$PATH
xcrun --sdk macosx x64_64-apple-darwinXX-gcc ... 

does work as expected, however.

gcc/ChangeLog:

2019-10-03  Iain Sandoe  

PR target/87243
* config/darwin-driver.c (maybe_get_sysroot_from_sdkroot): New.
(darwin_driver_init): Use the sysroot provided by SDKROOT when that
is available and the user has not set one on the command line.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin-driver.c

[Bug middle-end/91983] g++.dg/tree-ssa/pr61034.C regression

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91983

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Looks like it's been fixed here:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00246.html

[Bug middle-end/91983] g++.dg/tree-ssa/pr61034.C regression

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91983

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
It seems it appeared between r276441 and r276470 (we see it on aarch64)

[Bug target/91982] gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91982

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
It appeared between r276296 and r276306, might be caused by r276305:
[AArch64] Strengthen aarch64_hard_regno_call_part_clobbered

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[draganm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769

--- Comment #6 from draganm at gcc dot gnu.org ---
Author: draganm
Date: Thu Oct  3 19:17:20 2019
New Revision: 276525

URL: https://gcc.gnu.org/viewcvs?rev=276525=gcc=rev
Log:
Fix PR target/91769

This fixes the issue by checking that addr's base reg is not part of dest
multiword reg instead just checking the first reg of dest.

gcc/ChangeLog:

2019-10-03  Dragan Mladjenovic  

PR target/91769
* config/mips/mips.c (mips_split_move): Use reg_overlap_mentioned_p
instead of REGNO equality check on addr.reg.

gcc/testsuite/ChangeLog:

2019-10-03  Dragan Mladjenovic  

PR target/91769
* gcc.target/mips/pr91769.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr91769.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

--- Comment #6 from joseph at codesourcery dot com  ---
Arm only uses soft-fp for Thumb-1; otherwise it uses Arm-specific assembly 
code.

A natural fix might be, for these particular functions, in the hard-float 
case, to use the libgcc2.c versions instead; I expect that's faster than 
doing them entirely as software floating-point while respecting exceptions 
and rounding modes.  Arguably for the other functions, in the hard-float 
case, it would be best to build the t-hardfp versions to keep the libgcc 
size down, instead of the assembly versions.  In both cases you'd need to 
make sure the functions have the ABI-specified names, that they get 
properly built for the base PCS rather than the VFP variant, where the ABI 
requires that, and that any other ABI requirements are met (the default 
libgcc versions, compiled as C code, might not always follow the same 
interface as the ABI-defined functions).

The only case where soft-fp support for exceptions and rounding modes 
seems likely to be useful for Arm is those processors that do 
single-precision-only floating point in hardware, for which use of soft-fp 
for double precision would make sense in order to support exceptions and 
rounding modes (along with t-hardfp for single precision).  (Also, I 
suppose, use of soft-fp with exceptions and rounding modes would make 
sense for half-precision on hardware with floating-point support only for 
single and maybe double precision.)

[Bug fortran/91984] New: Handling of __def_init_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91984

Bug ID: 91984
   Summary: Handling of __def_init_*
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

After r276506 (PR84487) the __def_init variables are no longer in
the read-only section, but in the BSS instead. This was done because they they
could become excessively large.  However, the current solution is not ideal:

- Not having them read-only forced an xfail on
gfortran.dg/typebound_call_22.f03
- Having a variable which is (in the test cases) never used, and has only
  zeros, is not the best design.

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

Thomas Koenig  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
Summary|[8/9/10 Regression] Large   |[8/9 Regression] Large
   |rodate section increase in  |rodate section increase in
   |465.tonto with r254427  |465.tonto with r254427

--- Comment #26 from Thomas Koenig  ---
Migitated on trunk so far.

[Bug target/91982] gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91982

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-03
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I see it too.

[Bug middle-end/91983] New: g++.dg/tree-ssa/pr61034.C regression

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91983

Bug ID: 91983
   Summary: g++.dg/tree-ssa/pr61034.C regression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

The g++.dg/tree-ssa/pr61034.C test has been failing since around Sept 15, 2019.
Looking at gcc-testresults it looks like is failing on aarch64, x86, power,
and probably more.

FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times fre3 "free"
14
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times fre3 ";;
Function" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times optimized
"free" 0
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++17  scan-tree-dump-times fre3 "free"
14
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++17  scan-tree-dump-times fre3 ";;
Function" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++17  scan-tree-dump-times optimized
"free" 0
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times fre3 "free"
14
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times fre3 ";;
Function" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times optimized
"free" 0

[Bug target/91982] New: gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91982

Bug ID: 91982
   Summary: gcc.target/aarch64/sve/clastb_*.c tests failing with
segfault
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

A number of gcc.target/aarch64/sve/clastb_* tests (1-8) are failing with
segfaults.  This seems to have started around September 30, 2019.

One example:

% install/bin/gcc -O2 -ftree-vectorize -march=armv8.2-a+sve clastb_1.c
during GIMPLE pass: vect
clastb_1.c: In function 'condition_reduction':
clastb_1.c:9:1: internal compiler error: Segmentation fault
9 | condition_reduction (int *a, int min_v)
  | ^~~
0xc0103f crash_signal
../../gcc/gcc/toplev.c:326
0x7f5118 dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def
const*)
../../gcc/gcc/dominance.c:1118
0xe4dcdb vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:10903
0xe5054f vect_transform_loop_stmt
../../gcc/gcc/tree-vect-loop.c:8351
0xe5a51f vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:8578
0xe7eda7 try_vectorize_loop_1
../../gcc/gcc/tree-vectorizer.c:983
0xe7f7d3 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:1115
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #28 from Iain Sandoe  ---
Created attachment 46995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46995=edit
[c] Update mem_operand_gpr


I started tracing through mem_operand_gpr at this point and discovered that

(a) it seems that rs6000_offsettable_memref_p() will never return true for
lo_sum

(b) even if it does,  address_offset () doesn't consider lo_sum so will always
return NULL_RTX for that and therefore the check at the end of the function
won't happen.

Now, I recall Alan saying that you wanted to keep the predicate loose (which it
is on movdi_internal64) but ISTM without a working constraint LRA can't do its
job.



this patch splits mem_operand_gpr () into a path for LO_SUM and a path the
everything else.

In the LO_SUM path, for Darwin only, we call out to the function that checks
the offset *and* the symbol .. for non-Darwin, we just carry out the checks
that were in the code path before.

Now, this *will* change things for non-Darwin - since before it, I don't think
the lo_sum case could ever have been executed.

== AFAICT my m64 code is now working ≈ 120 progressions across the testsuite, a
lot in Fortran but also elsewhere.

So..
1) Have I missed somewhere else that is supposed to fix things up?
 (for the record, I instrumented legitimate_address_p, legitimise_address and
delegitimise_addres and I could not see any place that they were called that
could fix up a broken lo_sum.

2) the patch(es) are not tidy or as widely tested as would be needed to post
them ... but I can tidy/test if the direction is reasonable./

3) If this is NOT the right direction, then what is?

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #27 from Iain Sandoe  ---
Created attachment 46994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46994=edit
[b] Provide a function that checks the DS conditions for Darwin

.. so this provides a routine that checks the address offset contents for the
cases that we see in Darwin.

At this point it seemed that extending "legitimate_lo_sum_address_p" should be
enough to do the job.

We check the content stuff
We look at the symbol and see if it has enough alignment
We override that in the case of an indirection symbol, since we know that they
are always aligned to Pmode.

... this made some progression too - we lost the case of "insn not meeting
constraint"...

... but still a lot of failures for PIC.

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #35039|0   |1
is obsolete||

--- Comment #26 from Iain Sandoe  ---
Created attachment 46993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46993=edit
[a] remove the Darwin-specific lo_sum patterns

So, the lo_sum patterns in darwin.md have neither predicate nor constraint.

This means that they match anything that combine tries (via recog) and we end
up with unusable RTX.

so step one, was to remove these patterns and fall back on movdi_internal64 -
actually, this makes quite an improvement.. several of the test cases
progressed right away.

BUT.  The we see "insn doesn't match it's constraints" because LRA has fallen
back on loading a double reg ( ^d , m ) option.

This is because the Y constraint is not recognising cases that matter as
described above

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #25 from Iain Sandoe  ---
I'm going to attach 3 patches, with some comments on how the analysis and
testing arrived there - but some background;

(for the record) Mach-O/Darwin, on PPC generates code in three different
flavours:

1. -mkernel 
 - This is pretty close to ELF '-static' but (a) no TOC, (b) no common (c) use
a branch islands for long calls [with a special "jbsr" instruction and reloc].

 for this flavour we will only see lo_sum contents:
  constant
  symbol
  symbol+constant

2. -mdynamic-no-pic ('static' except for external refs)
 - This is quite similar, with the addition that some data accesses (common,
weak), and some calls are indirected.  When generating for really ancient
linkers, we can also enable symbol stubs for external refs.

 for this flavour lo_sum can contain:
  constant
  symbol
  symbol+constant
  indirection_sym

3. PIC (default)

 - in this case we construct a per function picbase label, and load the picbase
reg with that address -  and compute PC-relative addresses w.r.t this. 
 - undefined, common and weak symbols are indirected (there are some edge
cases, but those don't affect the codegen issues here)

 In principle, the lo_sum could contain

  constant
  symbol
  symbol+constant
  symbol-picbase
  indirection_sym-picbase
  symbol-picbase+constant ** I don't think we're smart enough to generate this,
in reality.

At present, we usually get something like...
  picbase => r31
  addis rx,r31, hi16(sym-picbaselabel)
  ... lo16(sym-picbaselabel)(rx)

=

For DS mode loads to be valid we need to check:
 - that any offset has the lower two bits clear
 - that the alignment of a referenced symbol is >= 4 [ we can be sure that the
picbase label will be ].

[Bug fortran/91963] Logical function does not simplify

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963

--- Comment #9 from Thomas Koenig  ---

(In reply to Thomas Koenig from comment #6)
> Somewhat reduced:
> 
> program main
>   integer, dimension(2), parameter :: n=[1,4]
>   logical, parameter :: a = logical(.true.,minval([(n(i),i=1,4)]))
> end program main
> 
> Even more reduced, without LOGICAL:
> 
> program main
>   integer, dimension(2), parameter :: n=[1,4]
>   integer, parameter :: m = minval([(n(i),i=1,4)],1)
> end program main

Both of these test cases are wrong, of course; there is no
n(3), nor is there a n(4).

The error message is bogus (which had me confused), an out-of-bounds-error
should be reported.

[Bug fortran/84487] [8/9/10 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

--- Comment #25 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Oct  3 12:39:42 2019
New Revision: 276506

URL: https://gcc.gnu.org/viewcvs?rev=276506=gcc=rev
Log:
2019-10-03  Thomas Koenig 

PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): For __def_init, set
DECL_ARTIFICAL and do not set TREE_READONLY.

2019-10-03  Thomas Koenig 

PR fortran/84487
* gfortran.dg/typebound_call_22.f03: xfail.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_call_22.f03

[Bug jit/91928] libgccjit fails on subsequent compilations in ipa-cp

[akrl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91928

--- Comment #1 from akrl at gcc dot gnu.org ---
Author: akrl
Date: Thu Oct  3 12:39:55 2019
New Revision: 276507

URL: https://gcc.gnu.org/viewcvs?rev=276507=gcc=rev
Log:
PR jit/91928

* ipa-cp.c (ipa_cp_c_finalize): Release ipcp_transformation_sum.
* ipa-prop.c (ipcp_free_transformation_sum): New function.
* ipa-prop.h (ipcp_free_transformation_sum): Add declaration.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h

[Bug inline-asm/91111] [7/8 Regression] arm64 Linux kernel panics at boot due to unexpected register assignment in inline asm

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> Bisection shows that on the trunk before r264897 we emit:
>  casalx30, x1, [x0]
> starting with r264897 we ICE and finally starting with r265398 we emit:
>  casalx30, x0, [x1]
> The problem obviously is that combine propagates the hard register into the
> memory, so we have
> (reg/v:DI 0 x0 [orig:94 x0 ] [94])
> (mem:DI (reg:DI 0 x0 [ v ]) [6 v_2(D)->counter+0 S8
> A64])
> as the outputs and IRA/LRA doesn't know what should be honored in that case
> because it can't honor both.
> Note, "Q" constraint is requesting a MEM that has a register operand.
> r265398 is certainly not backportable to 8.x or earlier, it had some many
> follow-ups that it is out of question.

That looks like it's orthogonal to inlining decisions so the kernel discussion
shouldn't be blocked on this.

[Bug inline-asm/91111] [7/8 Regression] arm64 Linux kernel panics at boot due to unexpected register assignment in inline asm

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

--- Comment #4 from Jakub Jelinek  ---
If you are looking for a workaround, perhaps replacing
  register long x0 asm ("x0") = (long)v;
with
  register long x0 asm ("x0");
  asm ("" : "=r" (x0) : "0" (v));
(i.e. affectively hiding from the compiler that x0 is set to v) will do the
job.

[Bug inline-asm/91111] [7/8 Regression] arm64 Linux kernel panics at boot due to unexpected register assignment in inline asm

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Bisection shows that on the trunk before r264897 we emit:
 casal  x30, x1, [x0]
starting with r264897 we ICE and finally starting with r265398 we emit:
 casal  x30, x0, [x1]
The problem obviously is that combine propagates the hard register into the
memory, so we have
(reg/v:DI 0 x0 [orig:94 x0 ] [94])
(mem:DI (reg:DI 0 x0 [ v ]) [6 v_2(D)->counter+0 S8
A64])
as the outputs and IRA/LRA doesn't know what should be honored in that case
because it can't honor both.
Note, "Q" constraint is requesting a MEM that has a register operand.
r265398 is certainly not backportable to 8.x or earlier, it had some many
follow-ups that it is out of question.

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

--- Comment #5 from nsz at gcc dot gnu.org ---
ok so the real problem is that libgcc does not define
FP_INIT_ROUNDMODE and FP_HANDLE_EXCEPTIONS etc for
hardfloat arm targets.

[Bug middle-end/91981] New: Speed degradation because of inlining a register clobbering function

[antoshkka at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981

Bug ID: 91981
   Summary: Speed degradation because of inlining a register
clobbering function
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example that is a simplified version of
boost::container::small_vector:


#define MAKE_INLINING_BAD 1

struct vector {
int* data_;
int* capacity_;
int* size_;

void push_back(int v) {
if (capacity_ > size_) {
*size_ = v;
++size_;
} else {
reallocate_and_push(v);
}
}

void reallocate_and_push(int v)
#if MAKE_INLINING_BAD
{
// Just some code that clobbers many registers.
// You may skip reading it
const auto old_cap = capacity_ - data_; 
const auto old_size = capacity_ - size_; 
const auto new_cap = old_cap * 2 + 1;

auto new_data_1 = new int[new_cap];
auto new_data = new_data_1;
for (int* old_data = data_; old_data != size_; ++old_data, ++new_data)
{
*new_data = *old_data;
}

delete[] data_;
data_ = new_data_1;
size_ = new_data_1 + old_size;
capacity_ = new_data_1 + new_cap;

*size_ = v;
++size_;
}
#else
;
#endif
};

void bad_inlining(vector& v) {
v.push_back(42);
}


With `#define MAKE_INLINING_BAD 0` the generated code is quite good:

bad_inlining(vector&):
  mov rax, QWORD PTR [rdi+16]
  cmp QWORD PTR [rdi+8], rax
  jbe .L2
  mov DWORD PTR [rax], 42
  add rax, 4
  mov QWORD PTR [rdi+16], rax
  ret
.L2:
  mov esi, 42
  jmp vector::reallocate_and_push(int)

However, with `#define MAKE_INLINING_BAD 1` the compiler decides to inline the
`reallocate_and_push` function that clobbers many registers. So the compiler
stores the values of those registers on the stack before doing the cmp+jbe:

bad_inlining(vector&):
  push r13 ; don't need those for the `(capacity_ > size_)` case
  push r12 ; likewise
  push rbp ; likewise
  push rbx ; likewise
  mov rbx, rdi ; likewise
  sub rsp, 8   ; likewise
  mov rdx, QWORD PTR [rdi+8]
  mov rax, QWORD PTR [rdi+16]
  cmp rdx, rax
  jbe .L2
  mov DWORD PTR [rax], 42
  add rax, 4
  mov QWORD PTR [rdi+16], rax
  add rsp, 8 ; don't need those for the `(capacity_ > size_)` case
  pop rbx ; likewise
  pop rbp ; likewise
  pop r12 ; likewise
  pop r13 ; likewise
  ret
.L2: 
  ; vector::reallocate_and_push(int) implementation goes here

This greatly degrades the performance of the first branch (more than x3
degradation in real code).


The possible fix would be to place all the push/pop operations near the inlined
`reallocate_and_push`:

bad_inlining(vector&):
  mov rax, QWORD PTR [rdi+16]
  cmp QWORD PTR [rdi+8], rax
  jbe .L2
  mov DWORD PTR [rax], 42
  add rax, 4
  mov QWORD PTR [rdi+16], rax
  ret
.L2: 
  push r13
  push r12
  push rbp
  push rbx
  mov rbx, rdi
  sub rsp, 8
  ; vector::reallocate_and_push(int) implementation goes here
  add rsp, 8
  pop rbx
  pop rbp
  pop r12
  pop r13
  ret

Godbolt playground: https://godbolt.org/z/oDutOd

[Bug c/91980] No diagnostic for type "complex"

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91980

--- Comment #3 from Keith Thompson  ---
Not surprisingly, when I modify my "complex-bug.c" changing
#include 
to
#include "complex.h"
and add a "complex.h file containing only
#define complex _Complex
the problem goes away (i.e., the correct diagnostic is printed).

[Bug inline-asm/91111] [7/8 Regression] arm64 Linux kernel panics at boot due to unexpected register assignment in inline asm

[will at kernel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

--- Comment #2 from Will Deacon  ---
Sorry to nag, but there's a discussion on LKML [1] about reducing the use of
the __always_inline attribute in favour of deferring inlining decisions to the
compiler. However, without an understanding of the root cause of this issue,
I'm very nervous about such a proposal for AArch64 targets.

Did you manage to get to the bottom of this issue, so that we can figure out
whether it could occur more widely or not (e.g. for 32-bit ARM or for register
variables used elsewhere)?

[1]
https://lore.kernel.org/lkml/20190830034304.24259-1-yamada.masah...@socionext.com/

[Bug c++/91974] function not sequenced before function argument

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Created attachment 46992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46992=edit
gcc10-pr91974.patch

The above patch broke a couple of devirtualization etc. testcases, this version
should fix that.  Untested so far except for the tests that FAILed with the
previous patch.

[Bug c++/91979] Incorrect mangling for non-template-argument nullptr expression

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91979

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #1 from Jonathan Wakely  ---
GCC trunk still produces LDn0E.

EDG agrees with Clang (and the ABI spec).

[Bug c++/91979] Incorrect mangling for non-template-argument nullptr expression

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91979

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-03
 Ever confirmed|0   |1

[Bug rtl-optimization/91976] [10 regression] RTL check: expected code 'const_int', have 'reg' in emit_block_move_hints, at expr.c:1627

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91976

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/91976] [10 regression] RTL check: expected code 'const_int', have 'reg' in emit_block_move_hints, at expr.c:1627

[dimhen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91976

--- Comment #5 from Dmitry G. Dyachenko  ---
r276503 PASS for me

Thank you, Jakub

[Bug c++/89695] unexpected copying of trivially copyable prvalue arguments

[matthijsvanduin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89695

--- Comment #4 from Matthijs van Duin  ---
(In reply to Jonathan Wakely from comment #3)
> I believe this is required by the ABI for trivially copyable types.

I don't see how that's possible, the callee can't tell the difference.

[Bug c/91980] No diagnostic for type "complex"

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91980

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||71613

--- Comment #2 from Andrew Pinski  ---
PR 71613 is one of them.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
[Bug 71613] Useful warnings silenced when macros from system headers are used

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835

--- Comment #13 from Jeremy Huddleston Sequoia  
---
Also note that  also already does the following:

/*
 * Compatibility with compilers and environments that don't support compiler
 * feature checking function-like macros.
 */
#ifndef __has_builtin
#define __has_builtin(x) 0
#endif
#ifndef __has_include
#define __has_include(x) 0
#endif
#ifndef __has_feature
#define __has_feature(x) 0
#endif
#ifndef __has_attribute
#define __has_attribute(x) 0
#endif
#ifndef __has_extension
#define __has_extension(x) 0
#endif

which might be why you see the problematic behavior sometimes but not always,
depending on header include order =/

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

 CC||jeremyhu at macports dot org

--- Comment #12 from Jeremy Huddleston Sequoia  
---
> perhaps Apple decided to ignore the report?
No.  We fix these issues when they're reported.

In the future, please file radars for these problems and ping me directly if
you want.  Issues in macOS headers don't get fixed if we don't know about them,
and I'd prefer to fix the SDK itself than have GCC use fixup hacks.

The __has_builtin() usage in Availability.h and TargetConditionals.h was
reported to me by Homebrew shortly after beta 1 and we fixed it internally
within a couple hours, landing it in a future beta.  We very much care about
the quality of the SDK, and if you run into issues, I'm more than happy to
champion them myself to avoid hacks like this in toolchains.

The __OSX_AVAILABLE_STARTING issue still exists in the GM SDK as it was never
reported to Apple AFAIK.  I've filed a radar now to track it:
.

>  unconditionally uses the availability attribute.

I'm not seeing that in the shipped SDK.  Perhaps it was filed by someone and
addressed.  If it's still an issue that I'm just not seeing, please file a
radar.