[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small

[dcb314 at hotmail dot com]

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

--- Comment #10 from David Binderman  ---
(In reply to Martin Liška from comment #9)
> I've got a patch candidate for it.

Ping Martin. Anything happened with that patch ?

[Bug c++/91964] New: Wrong -Wint-in-bool-context warning for enum constant

[joerg.rich...@pdv-fs.de]

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

Bug ID: 91964
   Summary: Wrong -Wint-in-bool-context warning for enum constant
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

cat > t.cc <(C) ) return true;   // 3
  if( static_cast(C) ) return true;  // 4
  if( static_cast( static_cast(C) ) ) return true;  // 5
  return false;
}
EOF

gcc -c -o t.cc.o t.cc -Wall

 

Gives: warning: enum constant in boolean context [-Wint-in-bool-context]

GCC 9.2 warns for all cases.
GCC 8.3 warns for case 2 & 4.

I think all warnings are wrong because nowhere is a enum constant in a boolean
context.

Enums 'A' and 'B' dont seem to trigger the warning.

[Bug middle-end/91957] [10 Regression] ICE in lra_assign building libgcc for csky-linux-gnuabiv2 soft-float

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Oct  2 07:37:10 2019
New Revision: 276440

URL: https://gcc.gnu.org/viewcvs?rev=276440&root=gcc&view=rev
Log:
[LRA] Don't make eliminable registers live (PR91957)

One effect of https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00802.html
was to strengthen the sanity check in lra_assigns so that it checks
whether reg_renumber is consistent with the whole conflict set.
This duly tripped on csky for a pseudo that had been allocated
to the eliminated frame pointer.  (csky doesn't have a separate
hard frame pointer.)

lra-lives uses:

/* Set of hard regs (except eliminable ones) currently live.  */
static HARD_REG_SET hard_regs_live;

to track the set of live directly-referenced hard registers, and it
correctly implements the exclusion when setting up the initial set:

  hard_regs_live &= ~eliminable_regset;

But later calls to make_hard_regno_live and make_hard_regno_dead
would process eliminable registers like other registers, recording
conflicts for them and potentially making them live.  (Note that
after r266086, make_hard_regno_dead adds conflicts for registers
that are already marked dead.)  I think this would have had the
effect of pessimising targets without a separate hard frame pointer.

2019-10-02  Richard Sandiford  

gcc/
PR middle-end/91957
* lra-lives.c (make_hard_regno_dead): Don't record conflicts for
eliminable registers.
(make_hard_regno_live): Likewise, and don't make them live.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug bootstrap/91949] [10 Regression] bootstrap failure on arm-linux-gnueabihf and s390x-linux-gnu (cannot convert 'bool' to 'const predefined_function_abi*')

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c/91951] goto + mixed declarations + cleanup attribute considered harmful

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-02
Version|unknown |9.2.1
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
gcc never warned for this, but it's an error with C++ to jump over a
declaration.

[Bug c/91952] [rfe] __attribute__((__default_value__()))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-10-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
How do you think GCC can "set" the default value if the initialization is
skipped?  Is the desired semantics that the allocation and initialization
of the variable happens at function start then plus a re-init when the
declaration is actually reached?

Thus, you need to better specify your proposal.

It sounds sth like

autostatic int x = 5;

thus have "static" (but auto at the same time) storage but reduced
visibility.

[Bug tree-optimization/91954] gcc.dg/vect/pr66142.c should not need early inlining to be vectorized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Hmm.

> make check-gcc RUNTESTFLAGS="--target_board=unix/-fno-early-inlining 
> vect.exp=pr66142.c"
...
=== gcc Summary ===

# of expected passes4

so it works? (ok, this is on the gcc 9 branch)

[Bug ipa/91956] [10 Regression] ICE: verify_cgraph_node failed (error: comdat-local function called by __ct .isra outside its comdat)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug middle-end/91957] [10 Regression] ICE in lra_assign building libgcc for csky-linux-gnuabiv2 soft-float

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Assuming fixed.

[Bug fortran/91963] Logical function does not simplify

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Richard Biener  ---
But is it valid fortran?

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

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
For the record, this has moved to
https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jörg Richter from comment #0)
> I think all warnings are wrong because nowhere is a enum constant in a
> boolean context.

The warning is documented as diagnosing "using non-boolean integer constants in
boolean context". C has the value 2 in all cases, no matter what form of cast
you use, which is a "non-boolean" value.

> Enums 'A' and 'B' dont seem to trigger the warning.

A and B have values 0 and 1.

The warning seems to be behaving as intended.

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[ktkachov at gcc dot gnu.org]

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

--- Comment #24 from ktkachov at gcc dot gnu.org ---
Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on aarch64
with -flto in the same place:
 995   gcc_assert (TYPE_NAME (t1)
 996   && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL);

[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 #2 from Thomas Koenig  ---
(In reply to Richard Biener from comment #1)
> But is it valid fortran?

I had to check, but yes.

LOGICAL is an elemental type conversion function, which has only constant
arguments, so it should be simplified.

There are also simpler cases where this works as expected:

program main
  logical, parameter :: l1 = .true.
  logical, parameter :: l4 = logical(l1, 4)
end program main

As does this:

program main
  integer, parameter, dimension(1) :: ar = [4]
  logical, parameter :: l1 = .true.
  logical, parameter :: l4 = logical(l1, ar(1))
end program main

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[joerg.rich...@pdv-fs.de]

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

--- Comment #2 from Jörg Richter  ---
The only boolean context I see is the if(...).
The if() is never used with enum constants/types, but only bool-s and int-s.
So according to the warning name (int-in-bool-context) the warning can
be expected in cases 1&3.  But not in the cases with explicit bool-casts.

But if cases 1&3 should warn for 'C'.  I don't see a point to not warn for 'A'
or 'B'.

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at ucw dot cz]

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

--- Comment #25 from Jan Hubicka  ---
> --- Comment #24 from ktkachov at gcc dot gnu.org ---
> Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on aarch64
> with -flto in the same place:
>  995   gcc_assert (TYPE_NAME (t1)
>  996   && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL);
Sorry to hear that seems cactusBSSN triggers a lot of interesting
behaviour here.  This conditional should fix it.

Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 276420)
+++ ipa-devirt.c(working copy)
@@ -986,8 +986,8 @@ warn_types_mismatch (tree t1, tree t2, l
   || (type_with_linkage_p (TYPE_MAIN_VARIANT (t2))
  && type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t2
 {
-  if (type_with_linkage_p (TYPE_MAIN_VARIANT (t1))
- && !type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t1)))
+  if (!type_with_linkage_p (TYPE_MAIN_VARIANT (t1))
+ || !type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t1)))
{
  std::swap (t1, t2);
  std::swap (loc_t1, loc_t2);

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||edlinger at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
I think the documentation could certainly be improved, because the description
of the warning option has incorrect grammar and punctuation, and it doesn't
accurately match the cases that are diagnosed by the warning.

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The warning was introduced for PR 77434 and the current behaviour by the fix
for PR 77700.

[Bug tree-optimization/91940] __builtin_bswap16 loop optimization

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Oct  2 10:18:50 2019
New Revision: 276442

URL: https://gcc.gnu.org/viewcvs?rev=276442&root=gcc&view=rev
Log:
PR tree-optimization/91940
* tree-vect-patterns.c: Include tree-vector-builder.h and
vec-perm-indices.h.
(vect_recog_rotate_pattern): Also handle __builtin_bswap16, either by
unpromoting the argument back to uint16_t, or by converting into a
rotate, or into shifts plus ior.

* gcc.dg/vect/vect-bswap16.c: Add -msse4 on x86, run on all targets,
expect vectorized 1 loops message on both vect_bswap and sse4_runtime
targets.
* gcc.dg/vect/vect-bswap16a.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-bswap16a.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-bswap16.c
trunk/gcc/tree-vect-patterns.c

[Bug tree-optimization/91940] __builtin_bswap16 loop optimization

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #1)
> The loop with the rotate is vectorized, while the one with __builtin_bswap16
> is not.

It is a bit surprising that we do not canonicalize one to the other somewhere
in the middle-end.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||81091

--- Comment #2 from Jonathan Wakely  ---
Since libstdc++ is not built with large file support, stat::off_t is only a
32-bit type, and the operation fails before any truncation to size_t would
happen:

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot get file size: Value too large for defined
data type [/mnt/scratch/jwakely/tmp/large_file_for_testing_std_filesystem]
Aborted (core dumped)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091
[Bug 81091] libstdc++ not built with large file support

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

[stsp at users dot sourceforge.net]

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

--- Comment #16 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #15)
> For the record, this has moved to
> https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html

Thanks, I also would like to apologize to Joseph for
not following his suggestion and instead keeping to
fight with the gcc build system. I can't help feeling
there is a bug here, and I think I am quite close to
getting it solved, so I'd be upset having to change the
approach after so many investigations, at least for now.

I've found this patch of Paolo Bonzini:
https://gcc.gnu.org/ml/gcc-patches/2006-01/msg00823.html
---
(GCC_TARGET_TOOL): Do not use a host tool if we found a target tool
with a complete path in either $with_build_time_tools or $exec_prefix.
---

That made me think that --with-build-time-tools=
should override the in-tree tools, but it is
not what actually happens. More details here:
https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html
Basically, the idea was to build one djgpp on host,
and then use that one for building the target libs
in another build tree. But it doesn't pick up the
host-installed tools.
After looking at the Paolo's patch, I tried the following
change:

--- config/acx.m4.old  2019-10-02 02:39:31.976773572 +0300
+++ config/acx.m4  2019-10-02 02:08:57.223563920 +0300
@@ -522,7 +522,7 @@
   fi
 else
   ifelse([$4],,,
-  [ok=yes
+  [ok=no
   case " ${configdirs} " in
 *" patsubst([$4], [/.*], []) "*) ;;
 *) ok=no ;;


And indeed got the build done, as --with-build-time-tools=
now found all the host tools in preference of the in-tree tools.
So currently I suspect Paolo's patch is at fault.

[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

Stas Sergeev  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---
Summary|--with-build-sysroot|--with-build-time-tools
   |doesn't work as expected|doesn't work as expected

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Wed Oct  2 10:54:10 2019
New Revision: 276448

URL: https://gcc.gnu.org/viewcvs?rev=276448&root=gcc&view=rev
Log:
2019-10-02  Richard Biener  

PR c++/91606
* decl.c (build_ptrmemfunc_type): Mark pointer-to-member
fat pointer structure members as DECL_NONADDRESSABLE_P.

* g++.dg/torture/pr91606.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr91606.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 regression]   |[9 regression] Optimization
   |Optimization leads to   |leads to invalid code
   |invalid code|
  Known to fail||9.2.0

--- Comment #11 from Richard Biener  ---
Fixed on trunk sofar.

[Bug libstdc++/81091] libstdc++ not built with large file support

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #0)
> libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses
> fopen/open
> in fstream and friends that can fail not only because of large files but
> files with large inode numbers depending on the underlying filesystem.

Richi, are you sure about that?

config/io/basic_file_stdio.cc does:

#ifdef _GLIBCXX_USE_LFS
if ((_M_cfile = fopen64(__name, __c_mode)))
#else
if ((_M_cfile = fopen(__name, __c_mode)))
#endif

And that macro should be set during configure, via:

dnl
dnl Check whether LFS support is available.
dnl
AC_DEFUN([GLIBCXX_CHECK_LFS], [
  AC_LANG_SAVE
  AC_LANG_CPLUSPLUS
  ac_save_CXXFLAGS="$CXXFLAGS"
  CXXFLAGS="$CXXFLAGS -fno-exceptions"
  AC_MSG_CHECKING([for LFS support])
  AC_CACHE_VAL(glibcxx_cv_LFS, [
GCC_TRY_COMPILE_OR_LINK(
  [#include 
   #include 
   #include 
  ],
  [FILE* fp;
   fopen64("t", "w");
   fseeko64(fp, 0, SEEK_CUR);
   ftello64(fp);
   lseek64(1, 0, SEEK_CUR);
   struct stat64 buf;
   fstat64(1, &buf);],
  [glibcxx_cv_LFS=yes],
  [glibcxx_cv_LFS=no])
  ])
  if test $glibcxx_cv_LFS = yes; then
AC_DEFINE(_GLIBCXX_USE_LFS, 1, [Define if LFS support is available.])
  fi
  AC_MSG_RESULT($glibcxx_cv_LFS)
  CXXFLAGS="$ac_save_CXXFLAGS"
  AC_LANG_RESTORE
])

So I think fstream is OK.

However, there are some bugs elsewhere due to not checking _GLIBCXX_USE_LFS and
so not using the largefile APIs:

src/c++11/random.cc:_M_fd = ::open(fname, O_RDONLY);
src/c++11/random.cc:_M_file = static_cast(std::fopen(fname, "rb"));

This should be OK in practice, because fname is guaranteed to be either
"/dev/random" or "/dev/urandom" (it seems unlikely that those devices will have
inode numbers that don't fit in 32 bits).

Nothing in src/filesystem and std/c++17/fs_* checks _GLIBCXX_USE_LFS or uses
the LARGEFILE64 APIs. I think those files should be built with
_FILE_OFFSET_BITS=64 so that stat, lstat, open, truncate etc. handle large
files automatically, without having to remember to use the LARGEFILE64 versions
explicitly.

[Bug libstdc++/81091] libstdc++ not built with large file support

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/81091] libstdc++ not built with large file support

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Richard Biener from comment #0)
> > libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses
> > fopen/open
> > in fstream and friends that can fail not only because of large files but
> > files with large inode numbers depending on the underlying filesystem.
> 
> Richi, are you sure about that?

I think I looked at all unresolved symbols of libstdc++.so and there were
some not using the LFS interfaces.  I didn't actually see you are "manually"
selecting the API.

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[joerg.rich...@pdv-fs.de]

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

--- Comment #5 from Jörg Richter  ---
There needs to be at least a way to suppress the warning with a cast 
or some other construct (not pragma).

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[zavadovsky.yan at gmail dot com]

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

--- Comment #11 from Zavadovsky Yan  ---
>We can set it as a default behavior for all FPU-capable SH4 variants, 
>but that will pessimize it for everything.

>The other option is to enable this only for your specific CPU (ST-40), 
>which would require you to use the -m4-300 option, not the -m4 option

If behavior of hardware is variative for this fpscr register switching it by
some option sounds as good idea.


>Would that be feasible for you?

Yes.
Any variant - I can add more compiler options to "makefiles" or rebuild whole
toolchain.

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[ktkachov at gcc dot gnu.org]

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

--- Comment #26 from ktkachov at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #25)
> > --- Comment #24 from ktkachov at gcc dot gnu.org ---
> > Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on 
> > aarch64
> > with -flto in the same place:
> >  995   gcc_assert (TYPE_NAME (t1)
> >  996   && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL);
> Sorry to hear that seems cactusBSSN triggers a lot of interesting
> behaviour here.  This conditional should fix it.
> 
> Index: ipa-devirt.c
> ===
> --- ipa-devirt.c  (revision 276420)
> +++ ipa-devirt.c  (working copy)
> @@ -986,8 +986,8 @@ warn_types_mismatch (tree t1, tree t2, l
>|| (type_with_linkage_p (TYPE_MAIN_VARIANT (t2))
> && type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t2
>  {
> -  if (type_with_linkage_p (TYPE_MAIN_VARIANT (t1))
> -   && !type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t1)))
> +  if (!type_with_linkage_p (TYPE_MAIN_VARIANT (t1))
> +   || !type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t1)))
>   {
> std::swap (t1, t2);
> std::swap (loc_t1, loc_t2);

Thanks! That fixes the benchmark build (and the rest of SPEC builds fine with
-flto). It also bootstraps and tests on aarch64-none-linux-gnu fine.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[fregloin at gmail dot com]

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

--- Comment #3 from Fregl  ---
In out product we use 32 bit toolchain, but work with large files.
So there is only solution to use direct stat call insted fs::file_size?
It seems this is firm limitation.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Huh, I thought I'd already fixed this a while ago.

I was thinking of Bug 85632 which is different.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Fregl from comment #3)
> It seems this is firm limitation.

It's a bug, you just have to wait for it to be fixed.

[Bug tree-optimization/91965] New: missing simplification for (C - a) << N

[amonakov at gcc dot gnu.org]

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

Bug ID: 91965
   Summary: missing simplification for (C - a) << N
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

Noticed this issue when preparing a testcase for PR 87047.  We do not simplify
(1048575ull - x) << 44 on GIMPLE:

unsigned long long foo(unsigned long long a)
{
return (1048575 - a) << 44;
}
void bar(unsigned long long *a)
{
for (int i = 0; i < 1024; i++)
a[i] = foo(a[i]);
}

we use (~a)<<44 for 'foo', but that is thanks to combine, in 'bar' combine
doesn't make the same transform (the 1048575 constant is moved into a pseudo in
another BB, and combine doesn't know that's the only use):

foo:
movq%rdi, %rax
notq%rax
salq$44, %rax
ret
bar:
leaq8192(%rdi), %rcx
movl$1048575, %edx
.L4:
movq%rdx, %rax
subq(%rdi), %rax
addq$8, %rdi
salq$44, %rax
movq%rax, -8(%rdi)
cmpq%rcx, %rdi
jne .L4
ret

Do we want to handle this early on via match.pd? Perhaps also applies to
simplifying (a +- C) << N.

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at gcc dot gnu.org]

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

--- Comment #27 from Jan Hubicka  ---
Author: hubicka
Date: Wed Oct  2 12:41:36 2019
New Revision: 276454

URL: https://gcc.gnu.org/viewcvs?rev=276454&root=gcc&view=rev
Log:
PR c++/91222
* ipa-devirt.c (warn_types_mismatch): Fix conditional on anonymous
namespace types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at ucw dot cz]

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

--- Comment #28 from Jan Hubicka  ---
> Thanks! That fixes the benchmark build (and the rest of SPEC builds fine with
> -flto). It also bootstraps and tests on aarch64-none-linux-gnu fine.
Thanks! My testing concluded independently so I went ahead and comitted
the patch.  Funilly enough I have problem to get some reduced testcase,
perhaps Martin will chime in.

The main confusion here was the fact that I did not assume anonymous
namespace type to be ever matched agains non-C++ type, but in the
testcase it happens which triggered two not so well tought out code
paths.

Honza

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[edlinger at gcc dot gnu.org]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Jörg Richter from comment #5)
> There needs to be at least a way to suppress the warning with a cast 
> or some other construct (not pragma).

That is simple: if ( C != A ) ...

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[joerg.rich...@pdv-fs.de]

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

--- Comment #7 from Jörg Richter  ---
Yes, I changed our code already to 
if( C != Enum() )

But I still think that an explicit cast should always silence this warning.

[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets

[gr.audio at gmail dot com]

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

--- Comment #5 from Guillaume  ---
I think I found a work-around for the time being.

If you define your packed structs with the 'volatile' qualifier, the bug
doesn't seem to show up. May not be completely ideal, but it appears to work,
and the reason why makes sense.

Like so: typedef volatile struct __attribute__((__packed__)) { ... }

Of course, would still be nice to fix the misalignment check...

[Bug fortran/91716] [9 Regression] ICE in output_constant, at varasm.c:5026

[edlinger at gcc dot gnu.org]

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

--- Comment #8 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Oct  2 13:22:37 2019
New Revision: 276458

URL: https://gcc.gnu.org/viewcvs?rev=276458&root=gcc&view=rev
Log:
2019-10-02  Bernd Edlinger  

Backport from mainline

2019-09-13  Bernd Edlinger  

PR fortran/91716
* trans-array.c (gfc_conv_array_initializer): Always assign the
array type of the field to the string constant.

PR fortran/91716
* gfortran.dg/pr91716.f90: New test.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-array.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91716] [9 Regression] ICE in output_constant, at varasm.c:5026

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Bernd Edlinger  ---
now also for fixed in gcc-9 branch

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[m.cencora at gmail dot com]

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

--- Comment #13 from m.cencora at gmail dot com ---
You can remove my_array from the test case. I put there only to show that using
it instead of std::array allows to workaround the bug.

[Bug fortran/91963] Logical function does not simplify

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> But is it valid fortran?

Yes.  It's valid.  gfortran has poor handling of implied-do loops
in initialization expression.

[Bug fortran/91963] Logical function does not simplify

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Wed, Oct 02, 2019 at 02:03:21PM +, kargl at gcc dot gnu.org wrote:
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #1)
> > But is it valid fortran?
> 
> Yes.  It's valid.  gfortran has poor handling of implied-do loops
> in initialization expression.
> 

Actually, the testcase submitted here in BZ is the
one of three posted in c.l.f that is invalid.  C_BOOL
is the only interoperable type for ISO BIND C, so the
use of C_SIZEOF is invalid.

[Bug c++/91966] New: pack expansion for Cartesian product breaks if certain indirections are involved

[ecrypa at posteo dot de]

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

Bug ID: 91966
   Summary: pack expansion for Cartesian product  breaks if
certain indirections are involved
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ecrypa at posteo dot de
  Target Milestone: ---

The following metaprogramming produces an unexpected output: see the types
`computed` and `expected` at the end.

https://godbolt.org/z/pX7WxD

BEGIN_CODE

// Reduced to this include-free example. Further reduction is hard: Either
// the bug(?) disappears, or the program becomes meaningless.

template
struct list {};

struct nil;



template
struct number {
  constexpr /*implicit*/ operator int() const { return n; }
  using type = number;
};

using false_ = number<0>;
using true_ = number<1>;

static_assert(!false_{}, "");
static_assert(true_{}, "");

template using numbers = list...>;



template
struct less_impl;

template
struct less_impl, number>
  : number<(lhs < rhs)> {};

template using less = typename less_impl::type;



template
struct sum_impl {
  static_assert(sizeof...(vs) == 0, "see specialization");
  using type = v0;
};

template
struct sum_impl, number, vs...>
  : sum_impl, vs...> {};

template using sum = typename sum_impl::type;



template
struct conditional_impl {
  static_assert(num{}, "see specialization");

  template
  using type = T;
};

template<>
struct conditional_impl {
  template
  using type = F;
};

template
using conditional = typename conditional_impl::template type;



template
struct min_filter_impl;

template
struct min_filter_impl> {
  template
  using count_better_mins = sum...>;

  using type = list, nil, nums>...>;

  using debug = list, nil, void>...>;

// error: expansion pattern 'conditional...>::type, nil, void>' contains no parameter packs

};

template using min_filter = typename min_filter_impl::type;



void test_min_filter() {
  using computed = min_filter>;
  using expected = list, nil, number<2>>;
  (void)(computed{} = expected{});// compiles for identical types

// error: no match for 'operator=' (operand types are 'computed' {aka
'list, number<7>, number<2> >'} and 'expected' {aka 'list,
nil, number<2> >'})

}

int main() {}

END_CODE

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

  Attachment #46987|0   |1
is obsolete||

--- Comment #12 from Oleg Endo  ---
Created attachment 46989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46989&action=edit
Proposed patch

(In reply to Zavadovsky Yan from comment #11)
> 
> Yes.
> Any variant - I can add more compiler options to "makefiles" or rebuild
> whole toolchain.

Great!  That makes things simpler.

The attached patch implements the ST40 special case for fabs and fneg
instructions.  You have to specify -m4-300 or -m4-300-single.  It will also
enable the fpchg instruction which is supported by ST40.

Please try it out.  Let me know what you find.  I'll briefly test it and commit
it to GCC 10, GCC 9, GCC 8, GCC 7 if there are no problems.  Although this
issue has been introduced in the SH FPU code refactoring in GCC 5...

[Bug c++/91967] New: gtest from google generates incorrect assembly code on x86 solaris

[bobw at cristie dot com]

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

Bug ID: 91967
   Summary: gtest from google generates incorrect assembly code on
x86 solaris
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobw at cristie dot com
  Target Milestone: ---

I compile the latest version of gtest (from google) under cmake on Solaris 11.3
(x86), I see ...

cd
/export/home/jenkins/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest
&& /usr/local/bin/c++  -DBOOST_ALL_DYN_LINK -DBOOST_ASIO_DYN_LINK
-DBOOST_AUTO_LINK_NOMANGLE -DBOOST_NETWORK_ENABLE_HTTPS
-DBOOST_NO_VARIADIC_TEMPLATES -D_GLIBCXX_HAS_GTHREADS -D_GLIBCXX__PTHREADS
-D_XPG6 -D__EXTENSIONS__ -Dsunos
-I/export/home/jenkins/work/3rdparty/trunk/cmake/../common/include
-I/export/home/jenkins/work/3rdparty/trunk/cmake/../common/basic
-I/export/home/jenkins/work/3rdparty/trunk/cmake/../unix/common/include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/../include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/build/openssl_1_1_1c/include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/sqlite_3_28_0
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/gtest_1_9_0/googletest/include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/gtest_1_9_0/googletest
-isystem
/export/home/jenkins/work/3rdparty/trunk/cmake/../3rdparty/boost_1_70_0 -DCMAKE
-fPIC -Wall -Wextra -Dunix -pthread -std=c++11 -Wno-unused-parameter
-Wno-unknown-pragmas -O2 -DNDEBUG   -Wall -Wshadow -Werror
-Wno-error=dangling-else -DGTEST_HAS_PTHREAD=1 -fexceptions -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -std=c++11 -o
CMakeFiles/gtest.dir/src/gtest-all.cc.o -c
/export/home/jenkins/work/3rdparty/trunk/3rdparty/gtest_1_9_0/googletest/src/gtest-all.cc
Assembler: gtest-all.cc
"/var/tmp//ccc2a4pF.s", line 84753 : Illegal mnemonic
Near line: "int3"
"/var/tmp//ccc2a4pF.s", line 84753 : Syntax error
Near line: "int3"

jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$
g++ --version
g++ (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$
uname -a
SunOS solaris 5.11 11.3 i86pc i386 i86pc
jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$
grep TOPLEVEL_CONFIGURE_ARGUMENTS ~/src/gcc/gcc-9.2.0/config.log
TOPLEVEL_CONFIGURE_ARGUMENTS='./configure'
jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$

[Bug c++/91967] gtest from google generates incorrect assembly code on x86 solaris

[bobw at cristie dot com]

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

--- Comment #1 from bob wilkinson  ---
Created attachment 46990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46990&action=edit
output of g++ with save-temps

[Bug testsuite/91842] new test case gcc.dg/ipa/ipa-sra-19.c in r275982 has compilation error

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Author: jamborm
Date: Wed Oct  2 15:09:37 2019
New Revision: 276465

URL: https://gcc.gnu.org/viewcvs?rev=276465&root=gcc&view=rev
Log:
[PR testsuite/91842] Skip gcc.dg/ipa/ipa-sra-19.c on power

2019-10-02  Martin Jambor  

PR testsuite/91842
* gcc.dg/ipa/ipa-sra-19.c: Skip on powerpc.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c

[Bug testsuite/91842] new test case gcc.dg/ipa/ipa-sra-19.c in r275982 has compilation error

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Jambor  ---
Fixed by skipping the test on power.

[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 #17 from Stas Sergeev  ---
Created attachment 46991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46991&action=edit
the fix

Attached is the patch that I think is correct.
It also seems to work properly, i.e. the full
build process passes (previous patches were only
tested for the part of the build process that
was failing).

This patch allows --with-build-time-tools=
to override the in-tree compiler, which I
think this option is for.
Please let me know if it is good or bad.

[Bug rtl-optimization/87047] [7/8/9/10 Regression] performance regression because of if-conversion

[amonakov at gcc dot gnu.org]

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

--- Comment #14 from Alexander Monakov  ---
Author: amonakov
Date: Wed Oct  2 15:37:12 2019
New Revision: 276466

URL: https://gcc.gnu.org/viewcvs?rev=276466&root=gcc&view=rev
Log:
ifcvt: improve cost estimation (PR 87047)

PR rtl-optimization/87047
* ifcvt.c (average_cost): New static function.  Use it...
(noce_process_if_block): ... here.

testsuite/
* gcc.dg/pr87047.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr87047.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/ifcvt.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/65438] Unnecessary ptr check

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|cesar at gcc dot gnu.org   |burnus at gcc dot 
gnu.org

[Bug rtl-optimization/87047] [7/8/9 Regression] performance regression because of if-conversion

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

Summary|[7/8/9/10 Regression]   |[7/8/9 Regression]
   |performance regression  |performance regression
   |because of if-conversion|because of if-conversion

--- Comment #15 from Alexander Monakov  ---
Fixed on the trunk, I'll ask about backporting to gcc-9 branch after a month or
so.

[Bug debug/91968] New: DW_AT_low_pc missing for DW_TAG_label with LTO

[keiths at redhat dot com]

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

Bug ID: 91968
   Summary: DW_AT_low_pc missing for DW_TAG_label with LTO
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keiths at redhat dot com
  Target Milestone: ---

Compilers tested: gcc version 10.0.0 20190930, several Fedora system compilers,
e.g., Fedora 29 (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1).

Consider the simple program (from GDB's test suite,
gdb/testsuite/gdb.base/label.c):

#include 

int
main (int argc, char **argv)
{
  int i = 0;
  goto there;

here:
  printf("not here\n");
  i = 1;

there:
  printf("but here\n");
  if (i == 0)
goto here;

done:
  return 0;
}

If this is compiled with LTO (gcc -g -flto label.c)[1], GDB is unable to set a
breakpoint at any of the labels. This is because GDB is looking for
DW_AT_low_pc, but this attribute is missing from the DIEs for the labels:

 <2>: Abbrev Number: 8 (DW_TAG_label)
   DW_AT_name: (indirect string, offset: 0xfe): there
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 13
   DW_AT_decl_column : 1
 <2>: Abbrev Number: 8 (DW_TAG_label)
<100>   DW_AT_name: (indirect string, offset: 0xff): here
<104>   DW_AT_decl_file   : 1
<105>   DW_AT_decl_line   : 9
<106>   DW_AT_decl_column : 1
 <2><107>: Abbrev Number: 8 (DW_TAG_label)
<108>   DW_AT_name: (indirect string, offset: 0xc6): done
<10c>   DW_AT_decl_file   : 1
<10d>   DW_AT_decl_line   : 18
<10e>   DW_AT_decl_column : 1

Is GDB supposed to deal with this in some other way?

[1] Alternatively, if you have a GDB build lying around:
$ make check RUNTESTFLAGS="--target_board unix/-flto" \
   TESTS=gdb.base/label.exp
That test will show several internal errors (assertion failures) as a result of
this.

[Bug libstdc++/91653] ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not

[lh_mouse at 126 dot com]

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

Liu Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #5 from Liu Hao  ---
This may be inconsistency (if not necessarily a defect) in the C++ standard,
since both `basic_ostream::{put,write}`, as UnformattedOutputFunctions, set
`badbit` in case of output failure, but `operator<<(basic_streambuf*)` doesn't.
Nevertheless GCC is doing the right thing and conform to all standards.

It should also be noted that if `operator<<(basic_streambuf*)` could not
extract any character, `failbit` is set on the output stream. Thus correct use
of this function requires a loop, as follows:

```
bool copy_stream(std::ostream& os, std::istream& is)
  {
while(os && (is.rdbuf()->sgetc()
 != std::istream::traits_type::eof()))
  os << is.rdbuf();
return !!os;
  }
```

Anyway, it is not a bug in libstdc++.

[Bug gcov-profile/91969] New: Compiling testsuite/g++.dg/ipa/pr85421.C with -fdump-ipa-inline ICEs

[jamborm at gcc dot gnu.org]

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

Bug ID: 91969
   Summary: Compiling testsuite/g++.dg/ipa/pr85421.C with
-fdump-ipa-inline ICEs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

If you compile testsuite/g++.dg/ipa/pr85421.C with -fdump-ipa-inline, the
compiler hits an assert gcc_checking_assert(initialized_p()) in
profile_count::to_gcov_type():

$ /home/mjambor/gcc/icln/obj/gcc/testsuite/g++/../../xg++
-B/home/mjambor/gcc/icln/obj/gcc/testsuite/g++/../../
/home/mjambor/gcc/icln/src/gcc/testsuite/g++.dg/ipa/pr85421.C -nostdinc++
-I/home/mjambor/gcc/icln/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/mjambor/gcc/icln/obj/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/mjambor/gcc/icln/src/libstdc++-v3/libsupc++
-I/home/mjambor/gcc/icln/src/libstdc++-v3/include/backward
-I/home/mjambor/gcc/icln/src/libstdc++-v3/testsuite/util -fmessage-length=0  
-O3 -std=gnu++1y -w  -S -o pr85421.s  -fdump-ipa-inline   
during IPA pass: inline
/home/mjambor/gcc/icln/src/gcc/testsuite/g++.dg/ipa/pr85421.C:131:1: internal
compiler error: in to_gcov_type, at profile-count.h:757
  131 | } // namespace bk
  | ^
0xd64624 profile_count::to_gcov_type() const
/home/mjambor/gcc/icln/src/gcc/profile-count.h:757
0x21d73f1 recursive_inlining
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:1554
0x21d8b50 inline_small_functions
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:2039
0x21da828 ipa_inline
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:2550
0x21db6cc execute
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:2958
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This happens when GCC attempts to dump stuff in recursive_inlining when it
attempts to dump count of cgraph_edge:

 *.LTHUNK0/8>

[Bug target/91970] New: 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

Bug ID: 91970
   Summary: arm: 64bit int to double conversion does not respect
rounding mode
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

on arm-* with

#include 
#include 
int main()
{
long long x = (1LL << 60) - 1;
double y;
fesetround(FE_DOWNWARD);
__asm__ __volatile__ ("" : "+m" (x));
y = x;
__asm__ __volatile__ ("" : "+m" (y));
fesetround(FE_TONEAREST);
printf("%a\n", y);
}

i get

0x1p60

instead of

0x1.fp+59

i assume this is because the conversion is handled by __aeabi_l2d
(also known as __floatdidf in libgcc) which is not rounding mode
aware.

this affects hardfloat targets which otherwise support directed
rounding modes.

[Bug gcov-profile/91971] New: Profile directory concatenated with object file path

[qinzhao at gcc dot gnu.org]

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

Bug ID: 91971
   Summary: Profile directory concatenated with object file path
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

we noticed that the profile directory will be concatenated with object file
path.

the following small example explain this behavior:

[qinzhao@localhost small]$ cat t
#! /bin/bash
CC=/home/qinzhao/Install/latest/bin/gcc
opt="-O3 -fprofile-generate"
opt="$opt -fprofile-dir=/home/qinzhao/prof_dir" 
opt="$opt -c -o /home/qinzhao/obj_dir/t.o"
tf="t.c"

echo $CC $opt $tf
$CC $opt $tf
strings /home/qinzhao/obj_dir/t.o | grep prof_dir
[qinzhao@localhost small]$ sh t
/home/qinzhao/Install/latest/bin/gcc -O3 -fprofile-generate
-fprofile-dir=/home/qinzhao/prof_dir -c -o /home/qinzhao/obj_dir/t.o t.c
/home/qinzhao/prof_dir//home/qinzhao/obj_dir/t.gcda
[qinzhao@localhost small]$ 


From the above, we can see:

when specifying the profiling directory with -fprofile-dir as
“/home/qinzhao/prof_dir”,  the user expects that the profiling data will 
be stored in this specific directory.  However, GCC concatenates  the profiling
directory “/home/qinzhao/prof_dir” with the path for the 
object file “/home/qinzhao/obj_dir” together. As a result, the profiling data
will be stored to:

/home/qinzhao/prof_dir/home/qinzhao/obj_dir/

instead of 

/home/qinzhao/prof_dir

This looks like a bug to me.

[Bug other/91972] New: Bootstrap should use -Wmissing-declarations

[amonakov at gcc dot gnu.org]

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

Bug ID: 91972
   Summary: Bootstrap should use -Wmissing-declarations
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

In the good old days when gcc was written in C, bootstrap stage2/3 enabled
-Wmissing-prototypes and so it caught attempted definitions of functions that
should be static, but were not declared so.

Transition to C++ did not change -Wmissing-prototypes to
-Wmissing-declarations, so over time several violations crept in. In particular
this penalizes optimization during non-LTO bootstrap (the compiler has to
assume the function might be used in another TU, even though in reality all
uses are in current file and it simply misses the 'static' keyword).

[Bug fortran/91963] Logical function does not simplify

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Wed, Oct 02, 2019 at 07:07:08AM -0700, Steve Kargl wrote:
> On Wed, Oct 02, 2019 at 02:03:21PM +, kargl at gcc dot gnu.org wrote:
> > --- Comment #3 from kargl at gcc dot gnu.org ---
> > (In reply to Richard Biener from comment #1)
> > > But is it valid fortran?
> > 
> > Yes.  It's valid.  gfortran has poor handling of implied-do loops
> > in initialization expression.
> > 
> 
> Actually, the testcase submitted here in BZ is the
> one of three posted in c.l.f that is invalid.  C_BOOL
> is the only interoperable type for ISO BIND C, so the
> use of C_SIZEOF is invalid.
> 

Here's valid code that shows the same problem

   use, intrinsic :: iso_fortran_env, only : logical_kinds
   integer :: i
   integer, parameter :: minkind = logical_kinds(minloc([( storage_size( &
   &   a=[ logical(.false., logical_kinds(i))] ), &
   &   i = 1, size(logical_kinds) )], dim=1))
   print *, "logical_kinds = ", logical_kinds
   print *, "minkind = ", minkind
end

[Bug c/91973] New: gcc failed for Multiple level macro expansion

[qinzhao at gcc dot gnu.org]

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

Bug ID: 91973
   Summary: gcc failed for Multiple level macro expansion
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

GCC cannot compile the following small testing case:

[qinzhao@localhost]$ cat t1.c
extern void boo (void *addr);

#define  foo(addr) \
  boo (addr)

#define bar(instr, addr)  \
  (instr) (addr)

void check (void *addr)
{
  bar(foo, addr);
}

[qinzhao@localhost]$ sh t
/home/qinzhao/Install/latest/bin/gcc -O -S t1.c
t1.c: In function ‘check’:
t1.c:11:7: error: ‘foo’ undeclared (first use in this function); did you mean
‘boo’?
   11 |   bar(foo, addr);
  |   ^~~
t1.c:7:4: note: in definition of macro ‘bar’
7 |   (instr) (addr)
  |^
t1.c:11:7: note: each undeclared identifier is reported only once for each
function it appears in
   11 |   bar(foo, addr);
  |   ^~~
t1.c:7:4: note: in definition of macro ‘bar’
7 |   (instr) (addr)
  |^

However, if I delete the parantheses from the macro bar as following:

#define bar(instr, addr)  \
  instr (addr)

The compilation succeed. 

also icc can successfully compile the original small testing case.

[Bug tree-optimization/90839] Detect lsb ones counting loop (final value replacement?)

[dpochepk at gmail dot com]

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

Dmitrij Pochepko  changed:

   What|Removed |Added

 CC||dpochepk at gmail dot com

--- Comment #2 from Dmitrij Pochepko  ---
aarch64 won't be necessarily faster with such fix.
531.deepsjeng_r on ThunderX2 shows about 0.5% slower numbers with 31-clz(a).

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

[barry.revzin at gmail dot com]

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

Bug ID: 91974
   Summary: function not sequenced before function argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

>From StackOverflow (https://stackoverflow.com/q/58204296/2069064), reduced:

extern void call(int);

void a(int) {
call(0);
}

void b(int) {
call(1);
}

int main() {
using T = void(*)(int);

T f = a;
f((f=b,0));
}

This is a well-defined (if weird) program that should a - that is call(0). With
gcc, it invokes call(1) (that is, the assignment that happens in the
initialization of the function parameter happens before the load of the
function itself). On -O2, the codegen is:

main:
sub rsp, 8
mov edi, 1
callcall(int)
xor eax, eax
add rsp, 8
ret

[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 #1 from nsz at gcc dot gnu.org ---
floating-point exceptions are also missing for the same reason.

[Bug target/89012] SH2 (FDPIC) duplicate symbols in generated assembly.

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo  ---
(In reply to Rich Felker from comment #9)
> I think it's actually just a matter of removing the patterns for generating
> bsrf, but I may be mistaken. Generating jsr should be what happens "by
> default" in some sense if GCC just has to load the address, no?

I think so, yes.

> Of course 
> that would also explicitly load the GOT pointer for the callee which we
> don't need since it's local.

Can you make an example?  Maybe it can get optimized away afterwards, if it's
not used?

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

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
Don't you need #pragma STDC FENV_ACCESS?

[Bug fortran/91943] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:01:30 2019
New Revision: 276471

URL: https://gcc.gnu.org/viewcvs?rev=276471&root=gcc&view=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91943
* match.c (gfc_match_call): BOZ cannot be an actual argument in
a subroutine reference.
* resolve.c (resolve_function): BOZ cannot be an actual argument in
a function reference.

2019-10-02  Steven G. Kargl  

PR fortran/91943
gfortran.dg/pr91943.f90

Added:
trunk/gcc/testsuite/gfortran.dg/pr91943.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91942] ICE in match_vtag, at fortran/io.c:1485

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:04:57 2019
New Revision: 276472

URL: https://gcc.gnu.org/viewcvs?rev=276472&root=gcc&view=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91942
* io.c (match_vtag): Check for non-NULL result->symtree.
(match_out_tag): Check for invalid constant due to inquiry parameter.
(match_filepos): Instead of a syntax error, go to cleanup to get better
error messages.

2019-10-02  Steven G. Kargl  

PR fortran/91942
* gfortran.dg/pr91587.f90: Update dg-error regex.
* gfortran.dg/pr91942.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91942.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr91587.f90

[Bug tree-optimization/91965] missing simplification for (C - a) << N

[amonakov at gcc dot gnu.org]

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

--- Comment #1 from Alexander Monakov  ---
On a related thought, I wonder if we can canonicalize (x << CST) to (x * CST')
where CST' is 1<

[Bug fortran/91785] ICE in check_assumed_size_reference, at fortran/resolve.c:1601

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:09:45 2019
New Revision: 276473

URL: https://gcc.gnu.org/viewcvs?rev=276473&root=gcc&view=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91785
* primary.c (gfc_match_varspec): Ensure an inquiry parameter has
it locus set.

2019-10-02  Steven G. Kargl  

PR fortran/91785
* gfortran.dg/pr91785.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91785.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91816] [7/8/9/10 Regression] Arm generates out of range conditional branches in Thumb2

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||sudi at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |sudi at gcc dot gnu.org
Summary|Arm generates out of range  |[7/8/9/10 Regression] Arm
   |conditional branches in |generates out of range
   |Thumb2  |conditional branches in
   ||Thumb2

[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 #3 from nsz at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #2)
> Don't you need #pragma STDC FENV_ACCESS?

yes, for iso c conformance you need it, but gcc does not
handle it anyway, instead it requires -frounding-math.

however if double prec instructions are available, using them
may be even faster in the difficult inexact case, e.g.

double uconv64(uint64_t x)
{
double lo = uconv32(x); // single instruction, always exact
double hi = uconv32(x>>32);
return lo + hi*0x1p32;
}

so i would not make the fix depend on -frounding-math,
just always use hardfloat instructions on hardfloat targets
to do the conv.

(i suspect it affects more than just armhf)

[Bug fortran/91784] ICE in gfc_real2complex, at fortran/arith.c:2208

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:17:55 2019
New Revision: 276474

URL: https://gcc.gnu.org/viewcvs?rev=276474&root=gcc&view=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91784
* simplify.c (gfc_convert_constant): Simplify expression if the
expres  ion type is EXPR_OP.

2019-10-02  Steven G. Kargl  

PR fortran/91784
* gfortran.dg/pr91784.f90: New test.

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

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I dont think this is well defined.  A call and its arguments are not sequence
points.  Yes there is a sequence point between the assignment and 0 but nothing
else.  Note c++17 does change the rules and I have not read them yet.

[Bug fortran/91963] Logical function does not simplify

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-02
 Ever confirmed|0   |1

--- Comment #6 from Thomas Koenig  ---
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

log.f90:3:27:

3 |   integer, parameter :: m = minval([(n(i),i=1,4)],1)
  |   1
Error: transformational intrinsic 'minval' at (1) is not permitted in an
initialization expression

You're right, Steve, the problem lies in the simplification
of the implied DO loop (the error message is a catch-all
which is somewhat misleading here).

[Bug tree-optimization/91965] missing simplification for (C - a) << N

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Alexander Monakov from comment #0)
> Do we want to handle this early on via match.pd? Perhaps also applies to
> simplifying (a +- C) << N.

What exact transformation do you want? Canonicalize the constant C to something
like C % (1 << (bitsize - N))?

(In reply to Alexander Monakov from comment #1)
> On a related thought, I wonder if we can canonicalize (x << CST) to (x *
> CST') where CST' is 1<

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

[barry.revzin at gmail dot com]

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

--- Comment #2 from Barry Revzin  ---
C++17 does change this rule. expr.call/8:

The postfix-expression is sequenced before each expression in the
expression-list and any default argument. The initialization of a parameter,
including every associated value computation and side effect, is
indeterminately sequenced with respect to that of any other parameter.

[Bug fortran/91963] Logical function does not simplify

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Wed, Oct 02, 2019 at 06:10:48PM +, tkoenig at gcc dot gnu.org wrote:
> 
> You're right, Steve, the problem lies in the simplification
> of the implied DO loop (the error message is a catch-all
> which is somewhat misleading here).
> 

I've looked at this a long time ago.  Never came up with a fix.

In the original code or the conforming example I posted, gfortran
ends up in check.c(kind_check).  If we look at lines 630 and following
we have

  if (!gfc_check_init_expr (k))
{
  gfc_error ("%qs argument of %qs intrinsic at %L must be a constant",
  gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
  &k->where);
  return false;
}

gfc_check_init_exp() returns ok, so gfortran knows it has an
intialization expression.  It simply hasn't reduced it to a
constant.  The next section of code fails, because extraction
of the kind value fails.

  if (gfc_extract_int (k, &kind)
  || gfc_validate_kind (type, kind, true) < 0)
{
  gfc_error ("Invalid kind for %s at %L", gfc_basic_typename (type),
   &k->where);
  return false;
}

This is were I'm stuck.  I think we need to rummage through
gfc_reduce_init_expr().

[Bug tree-optimization/90839] Detect lsb ones counting loop (final value replacement?)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
(In reply to Dmitrij Pochepko from comment #2)
> aarch64 won't be necessarily faster with such fix.
> 531.deepsjeng_r on ThunderX2 shows about 0.5% slower numbers with 31-clz(a).

This sounds like we only pass 0 or 1 to this function in deepsjeng_r?
Have you figured out the values that deepsjeng_r uses for these loops?

Because 31-clz would be:
clz w0, w0
mov w1, 31
sub w0, w1, w0
--- CUT ---
While the loop version would be:
asr w1, w0, 1
mov w0, 0
cbz w1, .L3
.p2align 2
.L5:
add w0, w0, 1
asr w1, w1, 1
cbnzw1, .L5
.L3:

If the first branch was predicted as being taken (and it was actually taken;
that is skip the loop), it would be a few cycles faster than the non-loop based
one.  This would also mean the value of w0 is either 0 or 1.

Did you anlaysis why it was worse for TX2?

[Bug tree-optimization/91965] missing simplification for (C - a) << N

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
(In reply to Marc Glisse from comment #2)
> What exact transformation do you want? Canonicalize the constant C to
> something like C % (1 << (bitsize - N))?

I'm thinking (C << N) >>> N where '>>>' is sign-extending right shift. In other
words, duplicate the bit at position (bitsize - 1 - N) to the left. In the
opening example, I want to go from

  (0xf - a) << 44

to

  (-1 - a) << 44

> For unsigned only... didn't we use to canonicalize in the reverse direction,
> i.e. from x*4 to x<<2?

For unsigned - because we promise not to use undefined overflow for signed left
shifts? Can we canonicalize to a wrapping multiplication?

[Bug tree-optimization/91975] New: worse code for small array copy using pointer arithmetic than array indexing

[msebor at gcc dot gnu.org]

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

Bug ID: 91975
   Summary: worse code for small array copy using pointer
arithmetic than array indexing
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When the contents of one small array is copied into another, GCC with -O2
generates more or less optimal code depending on whether the source array is
statically initialized, and also depending on whether the copying takes place
using pointer arithmetic and dereferencing or using array indexing.  Some
copies are transformed into series of assignments while others remain as loops,
while others still into a single MEM_REF statement.

The emitted assembly is also more or less efficient.

-O3 is required to get the same optimally efficient code.

Clang emits optimally efficient code for all forms at -O2.

It seems that since GCC can make some of the functions below optimally
efficient it should be able to do it for all of them.

$ cat b.c && gcc -DT=int -O2 -S -fdump-tree-optimized=/dev/stdout b.c
const T a[] = { 0, 1, 2, 3, 4, 5, 6, 7 };
T b[sizeof a / sizeof *a];

void f0 (void)   // near optimal
{
  const T *s = a;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
d[i] = s[i];
}

void g0 (void)   // suboptimal
{
  const T *s = a;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
*d++ = *s++;
}

extern const T c[sizeof a / sizeof *a];

void f1 (void)   // optimal
{
  const T *s = c;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
d[i] = s[i];
}

void g1 (void)   // optimal
{
  const T *s = c;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
*d++ = *s++;
}


;; Function f0 (f0, funcdef_no=0, decl_uid=1926, cgraph_uid=1, symbol_order=2)

f0 ()
{
   [local count: 119292717]:
  MEM  [(int *)&b] = 4294967296;
  MEM  [(int *)&b + 8B] = 12884901890;
  MEM  [(int *)&b + 16B] = 21474836484;
  MEM  [(int *)&b + 24B] = 30064771078;
  return;

}



;; Function g0 (g0, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=3)

g0 ()
{
  sizetype ivtmp.25;
  int prephitmp_4;
  int pretmp_5;

   [local count: 119292716]:

   [local count: 954449108]:
  # prephitmp_4 = PHI <0(2), pretmp_5(4)>
  # ivtmp.25_2 = PHI <0(2), ivtmp.25_15(4)>
  MEM[symbol: b, index: ivtmp.25_2, offset: 0B] = prephitmp_4;
  ivtmp.25_15 = ivtmp.25_2 + 4;
  if (ivtmp.25_15 != 32)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 835156388]:
  pretmp_5 = MEM[symbol: a, index: ivtmp.25_15, offset: 0B];
  goto ; [100.00%]

   [local count: 119292717]:
  return;

}



;; Function f1 (f1, funcdef_no=2, decl_uid=1945, cgraph_uid=3, symbol_order=4)

f1 ()
{
   [local count: 119292717]:
  MEM  [(char * {ref-all})&b] = MEM 
[(char * {ref-all})&c];
  return;

}



;; Function g1 (g1, funcdef_no=3, decl_uid=1954, cgraph_uid=4, symbol_order=5)

g1 ()
{
   [local count: 119292717]:
  MEM  [(char * {ref-all})&b] = MEM 
[(char * {ref-all})&c];
  return;

}

[Bug rtl-optimization/91976] New: [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

Bug ID: 91976
   Summary: [10 regression] RTL check: expected code 'const_int',
have 'reg' in emit_block_move_hints, at expr.c:1627
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

gcc bootstrap
r276439 PASS
r276476 FAIL

Fedora 30 x86_64

/home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native

make
...
/home/dimhen/build/gcc_current/./gcc/xgcc
-B/home/dimhen/build/gcc_current/./gcc/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/sys-include   -fno-checking -g -O2
-O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection
-mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I/home/dimhen/src/gcc_current/libgcc -I/home/dimhen/src/gcc_current/libgcc/.
-I/home/dimhen/src/gcc_current/libgcc/../gcc
-I/home/dimhen/src/gcc_current/libgcc/../include
-I/home/dimhen/src/gcc_current/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov
-c /home/dimhen/src/gcc_current/libgcc/libgcov-driver.c
during RTL pass: expand
In file included from /home/dimhen/src/gcc_current/libgcc/libgcov-driver.c:214:
/home/dimhen/src/gcc_current/libgcc/libgcov-driver-system.c: In function
'gcov_do_dump':
/home/dimhen/src/gcc_current/libgcc/libgcov-driver-system.c:252:26: internal
compiler error: RTL check: expected code 'const_int', have 'reg' in
emit_block_move_hints, at expr.c:1627
  252 |   char *p = (char *) memcpy (gf->prefix, gcov_prefix,
prefix_length);
  | 
^~~
0x1218bf6 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/home/dimhen/src/gcc_current/gcc/rtl.c:879
0xc8346e emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long, unsigned long, unsigned long, unsigned long, bool, bool*,
bool)
/home/dimhen/src/gcc_current/gcc/expr.c:1627
0xa441ae expand_builtin_memory_copy_args
/home/dimhen/src/gcc_current/gcc/builtins.c:3936
0xa439da expand_builtin_memcpy
/home/dimhen/src/gcc_current/gcc/builtins.c:3793
0xa50c08 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/dimhen/src/gcc_current/gcc/builtins.c:7644
0xcb582d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:11108
0xca7170 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:8327
0xc9ab8d store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:5723
0xc98ed0 expand_assignment(tree_node*, tree_node*, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:5485
0xa9ecd9 expand_call_stmt
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:2729
0xaa2d2d expand_gimple_stmt_1
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:3710
0xaa3471 expand_gimple_stmt
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:3875
0xaace9b expand_gimple_basic_block
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:5914
0xaae9eb execute
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:6554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[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 #1 from Dmitry G. Dyachenko  ---
FAIL: configure --enable-checking=yes,rtl --enable-languages=c,c++,lto
--disable-multilib

PASS: configure --enable-checking=yes --enable-languages=c,c++,lto
--disable-multilib

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

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Just to make sure, you are using -std=c++17 or -std=gnu++17 (or
-fstrong-eval-order)?  Because it is not obvious from this report.

[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|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-02
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Most likely caused by r276461.

[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 #18 from joseph at codesourcery dot com  ---
No, --with-build-time-tools definitely should not override newly built 
tools.

For example, in some bootstrap configurations you have to build GCC more 
than once.  If you're also installing into a DESTDIR rather than directly 
into the configured prefix, you need to use --with-build-time-tools so 
that binutils for the target can be found.  But when building the second 
GCC, the newly built GCC *must* be used to compile its own shared 
libraries, not the first-stage GCC that might be installed alongside 
binutils in the directory pointed to with --with-build-time-tools.  (For 
example, the second GCC might be configured --enable-shared, with that 
being needed to build shared libgcc and libstdc++, where the first GCC was 
configured --disable-shared.)

[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

--- Comment #3 from Jakub Jelinek  ---
I think
--- gcc/expr.c.jj   2019-10-02 16:35:20.977451346 +0200
+++ gcc/expr.c  2019-10-02 21:47:54.900724874 +0200
@@ -1624,16 +1624,18 @@ emit_block_move_hints (rtx x, rtx y, rtx
   set_mem_size (y, const_size);
 }

-  bool pieces_ok = can_move_by_pieces (INTVAL (size), align);
+  bool pieces_ok = false;
+  if (CONST_INT_P (size))
+pieces_ok = can_move_by_pieces (INTVAL (size), align);
   bool pattern_ok = false;

-  if (!CONST_INT_P (size) || !pieces_ok || might_overlap)
+  if (!pieces_ok || might_overlap)
 {
-  pattern_ok = 
-   emit_block_move_via_pattern (x, y, size, align,
-expected_align, expected_size,
-min_size, max_size, probable_max_size,
-might_overlap);
+  pattern_ok
+   = emit_block_move_via_pattern (x, y, size, align,
+  expected_align, expected_size,
+  min_size, max_size, probable_max_size,
+  might_overlap);
   if (!pattern_ok && might_overlap)
{
  /* Do not try any of the other methods below as they are not safe
@@ -1645,7 +1647,7 @@ emit_block_move_hints (rtx x, rtx y, rtx

   if (pattern_ok)
 ;
-  else if (CONST_INT_P (size) && pieces_ok)
+  else if (pieces_ok)
 move_by_pieces (x, y, INTVAL (size), align, RETURN_BEGIN);
   else if (may_use_call && !might_overlap
   && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
should fix this.

[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 #4 from joseph at codesourcery dot com  ---
The libgcc2.c functions for conversions that get used by default on most 
architectures should respect the rounding mode if the underlying 
single-word-to-floating-point instruction does so.  (They have more 
complicated logic to handle the __floatdisf case and other such cases 
where a single word is wider than the precision of the floating-point 
type.)

The libgcc2.c __fix* functions may raise spurious "inexact" exceptions, 
but that's a different matter.

[Bug c/91973] gcc failed for Multiple level macro expansion

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Joseph S. Myers  ---
This is not a bug in GCC, it's how the preprocessor is defined to work.

[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 #19 from Stas Sergeev  ---
OK, but the setup when you want to override
the newly-built gcc, is also needed. Like, when
you want to build the "destdir" gcc with the one
installed directly into prefix (and therefore
working fine on host).
Would you suggest a new option for that?
I've seen the variables CC_FOR_TARGET and alike,
but they do not work that way too. So I think
currently there is no way of doing that, and
so some patch should be created. How should it
look like?

[Bug c/91973] gcc failed for Multiple level macro expansion

[qinzhao at gcc dot gnu.org]

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Joseph S. Myers from comment #1)
> This is not a bug in GCC, it's how the preprocessor is defined to work.
So, this is an user error? is there any C language rules on this?
why icc works on this?

[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 #20 from joseph at codesourcery dot com  ---
The only case where the newly built GCC should be overridden is the 
Canadian cross case, and while that does use a pre-installed tool from the 
PATH, it's best to use "make all-host" in that case to avoid rebuilding 
target libraries and instead copy them from the build system.  (The 
identically-configured build-x-target tools still need to be in the PATH 
in that case because the GCC build wants to run the target compiler with 
-dumpspecs.)

Your problem as originally described was with finding non-sysroot headers.  
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.  Maybe you don't want --with-headers because of the side-effect 
of copying into a sys-include directory, but something quite similar to 
that but without that side-effect might work.

[Bug c/91973] gcc failed for Multiple level macro expansion

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Macro replacement for function-like macros is defined in C17 6.10.3.  
Note in paragraph 10 the words "the function-like macro name followed by a 
( as the next preprocessing token".  In your example foo ends up followed 
by ) not ( as the next preprocessing token.

[Bug gcov-profile/91087] g++.dg/gcov/pr16855.C fails everywhere on Darwin.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Iain Sandoe  ---
fixed on open branches

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

[iains at gcc dot gnu.org]

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

--- Comment #18 from Iain Sandoe  ---
I'm testing regularly on macOS 10.14 (darwin18) - which I assume is the version
you meant?

Also on 8.3 and 9.2 .. (the results are posted to @testresults).

There was a PCH fixed (but that only manifested with -save-temps, so I don't
expect it to be directly relevant).

Right now, I can find no indication (or repeat) of this report - are you still
seeing it anywhere?

[Bug target/90834] Header and startup objects not found on macOS 10.15

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
other than the desire to locate /usr/local/include in some automatic way, is
this still a current issue?

I've built (with the workaround for missing __has_x()) on 10.14 using the
10.15 XC11.0 command line tools, without any issues [other than the missing
__has_x()].

[Bug target/82920] cet test failures on darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #24 from Iain Sandoe  ---
fixed on open branches

[Bug testsuite/27221] g++.dg/ext/alignof2.C fails on powerpc-darwin (and powerpc-aix)

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Iain Sandoe  ---
fixed on open branches