[Bug web/87933] Bad headers and titles for:

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Thu Jun  6 07:20:16 2019
New Revision: 271988

URL: https://gcc.gnu.org/viewcvs?rev=271988&root=gcc&view=rev
Log:
Fix HTML headers and titles for 'Installing GCC' pages (PR web/87933).

2019-06-06  Martin Liska  

PR web/87933
* doc/install.texi: Fix HTML headers and
titles for 'Installing GCC' pages.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi

[Bug web/87933] Bad headers and titles for:

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Fixed now.

[Bug libfortran/77278] Use LTO for libgfortran

[rguenther at suse dot de]

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

--- Comment #26 from rguenther at suse dot de  ---
On Thu, 6 Jun 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
> 
> --- Comment #25 from Thomas Koenig  ---
> (In reply to Jan Hubicka from comment #24)
> > Hi,
> > actually it won't help since C has only one bool type and not bools in
> > different sizes (why would one need that?).
> 
> "Because it's in the Fortran language standard" is probably a good
> answer as any.  For example, the standard specifies that default
> logical and default integer have to have the same size, and
> it specifies all the other logical kinds.
> 
> > I guess it would be easiest to turn Fortran frontend to use integers here.
> 
> Easiest for this case, yes.
> 
> However, this is far from the only case where integer vs. logical
> is a problem in libgfortran - to reduce code size, we've been treating
> them interchangeably for quite some time.
> 
> Really, it would be easiest if there was a way to tell the middle
> end that logical(kind=4) and integer(kind=4) could alias.

I think that's reasonably easy to do for LTO.  We'd want to keep
the default boolean_type_node size BOOLEAN_TYPEs separate but
can glob larger ones with integer types in the canonical type
merging.  We can probably do the same in non-LTO but that might
not be required.

Honza?

> There is another, possibly even worse, case.  To reduce combinatorical
> explosion of some functions, we have been using this idiom
> 
>   mask_kind = GFC_DESCRIPTOR_SIZE (mask);
> 
>   if (mask_kind == 1 || mask_kind == 2 || mask_kind == 4 || mask_kind == 8
> #ifdef HAVE_GFC_LOGICAL_16
>   || mask_kind == 16
> #endif
>   )
> {
>   /*  Do not convert a NULL pointer as we use test for NULL below.  */
>   if (mptr)
> mptr = GFOR_POINTER_TO_L1 (mptr, mask_kind);
> }
>   else
> runtime_error ("Funny sized logical array");
> 
> where GFOR_POINTER_TO_L1 computes an offset between little- and big-endian
> systems, and we then access the value bytewise.
> 
> If we made this more cleanly, we would add 1505 more functions to the
> libgfortran library (rough count).

If the "bytewise" access uses character types (or uint8_t) then
TBAA wise that should be fine.  If the pointers are restrict
you don't lose optimization either.

[Bug middle-end/90673] A problem with 'copy destination size is too small' error in copy_from_user

[yaro330 at gmail dot com]

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

Yaro Slav  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Yaro Slav  ---
This was just bad coding, resolved.

[Bug tree-optimization/87954] VRP can transform a * b where a,b are [0,1] to a & b

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Jun  6 07:55:51 2019
New Revision: 271991

URL: https://gcc.gnu.org/viewcvs?rev=271991&root=gcc&view=rev
Log:
Simplify mult where both arguments are 0 or 1 (PR tree-optimization/87954).

2019-06-06  Martin Liska  

PR tree-optimization/87954
* match.pd: Simplify mult where both arguments are 0 or 1.
2019-06-06  Martin Liska  

PR tree-optimization/87954
* gcc.dg/pr87954.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr87954.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/90746] __sanitizer_cov_trace_pc should not be tail called

[dvyukov at google dot com]

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

--- Comment #3 from Dmitry Vyukov  ---
> It would probably useful to have __attribute__((notailcall)) which the 
> sanitizers then could stick on the function types.

It should be on _declaration_, right? Sanitizers only provide a definition. The
declaration is provided by gcc itself:

sanitizer.def-DEF_SANITIZER_BUILTIN(BUILT_IN_SANITIZER_COV_TRACE_PC,
sanitizer.def:"__sanitizer_cov_trace_pc",
sanitizer.def-BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)

But I guess we could still plum that attribute there.

This also makes me wonder: find_tail_calls has fndecl_built_in_p check, the
callback is declared with DEF_SANITIZER_BUILTIN, yet it's not a builtin
somehow?


> We could also make noinline imply no tailcalls, noinline is already mentioned 
> in the docs for __builtin_return_address.  That wouldn't work for indirect 
> calls though.

I would expect that C programmers want more control over this. C programmers
really like to keep things in control :)
That aside, this will introduce performance regressions for existing code,
right?


> Of course, for a builtin we can check that manually in tree-tailcall.c

This looks like the simplest solution for the problem at hand. What would it
be? I guess something more fancy that this: :)

diff --git a/gcc/tree-tailcall.c b/gcc/tree-tailcall.c
index afe8931b5f0..b83b8ba446e 100644
--- a/gcc/tree-tailcall.c
+++ b/gcc/tree-tailcall.c
@@ -477,6 +477,7 @@ find_tail_calls (basic_block bb, struct tailcall **ret)
   func = gimple_call_fndecl (call);
   if (func
   && !fndecl_built_in_p (func)
+  && func != builtin_decl_implicit (BUILT_IN_SANITIZER_COV_TRACE_PC)
   && recursive_call_p (current_function_decl, func))
 {
   tree arg;

[Bug tree-optimization/87954] VRP can transform a * b where a,b are [0,1] to a & b

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Implemented.

[Bug libstdc++/68303] performance: unordered_map&co. up to 7x speedup

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00903.html
> Reviewed at https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02120.html

As pointed out in https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00104.html this
was partially addressed in r270868.

[Bug libgcc/88267] A new flag in GCC causes a divergence in crtbegin.o file

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
(In reply to Martin Liška from comment #2)
> (In reply to Richard Biener from comment #1)
> > But it's hidden, so I'm not sure we care. 
> 
> I noticed that using objdump -d where the tools assigns names to locations
> of which it knows name.
> 
> > OTOH not sure why options.h is being pulled in.
> 
> This should be investigated ;)

It's being pulled due to:
$ /bin/sh /home/marxin/Programming/gcc/gcc/mkconfig.sh tm.h
where tm.h includes
# include "options.h"

It's probably low priority issue..

[Bug libstdc++/68303] performance: unordered_map&co. up to 7x speedup

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
But it doesn't make a huge difference and iteration is still much faster for <=
17 elements:

| GCC 9 |   | GCC 10 |  | 10 wrapped |
0=0.696880  0=0.700247  0=0.110166
1=0.705601  1=0.676875  1=0.177209
2=1.006746  2=0.728425  2=0.228726
3=0.920503  3=0.778136  3=0.379848
4=1.044559  4=0.830860  4=0.378648
5=1.205183  5=0.882847  5=0.330908
6=0.950419  6=0.930731  6=0.363111
7=1.004634  7=1.001264  7=0.359892
8=1.070675  8=1.030736  8=0.368559
9=1.117331  9=1.100524  9=0.408855
10=1.192385 10=1.138487 10=0.424364
11=1.409491 11=1.181265 11=0.481035
12=0.958946 12=1.231175 12=0.517279
13=0.987015 13=1.328534 13=0.579356
14=1.024184 14=0.970562 14=0.629750
15=1.049774 15=0.991556 15=0.703401
16=1.082365 16=1.017649 16=0.754023
17=1.098181 17=1.037775 17=0.878584
18=1.127022 18=1.060267 18=1.137607
19=1.233192 19=1.085448 19=1.193701
20=1.215447 20=1.104254 20=1.001146
21=1.257106 21=1.128671 21=1.169435
22=1.278363 22=1.149634 22=1.185851
23=1.320331 23=1.171409 23=1.206449
24=0.988053 24=1.194045 24=1.229551
25=1.002762 25=1.218135 25=1.253025
26=1.006531 26=1.239955 26=1.276393
27=1.013021 27=1.263612 27=1.296041
28=1.027757 28=1.286184 28=1.360461
29=1.035280 29=1.308196 29=1.355412
30=1.055340 30=0.996437 30=1.040220

[Bug libfortran/77278] Use LTO for libgfortran

[hubicka at ucw dot cz]

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

--- Comment #27 from Jan Hubicka  ---
> 
> I think that's reasonably easy to do for LTO.  We'd want to keep
> the default boolean_type_node size BOOLEAN_TYPEs separate but
> can glob larger ones with integer types in the canonical type
> merging.  We can probably do the same in non-LTO but that might
> not be required.

Yes, we can glob other sizes of bool into integers and that should
not affect non-fortran languages where truth comes in only one size.
It would be bit inconsistent in a way that logical sized same way
as C bool will bind to C _Bool type and others will bind to integer
types of corresponding sizes.

The Fortran 2003 language draft has section on interoperability of
C and Fortran language:
https://j3-fortran.org/doc/year/10/10-007.pdf
Which says that fortran language C_BOOL should interoperate with _Bool.
Why libgfortran API functions which dispatch into C code are not
declared with C_BOOL rather than the integer sized logical?

I wrote some testcases for LTO C and fortran types interoperatibility
(gfortran.dg/lto/bind_c*)
Since my Fortran-fu is limited, they may not be complete. It would be
very useful to look into them and see if everything important is
tested and also that we have testcase for all cases we want to support
in addition to stadnard (like this one it seems) with some rationale
in them for future reference.

Honza

[Bug ipa/89330] IPA inliner touches released cgraph_edges

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Martin Liška  ---
Apparently, this is not an issue any longer.

[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #20 from Martin Liška  ---
I'm closing this now.

[Bug rtl-optimization/87375] Conditional jump or move depends on uninitialised value(s) in calculate_allocation_cost (ira.c:2453)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can't reproduce any longer, closing..

[Bug fortran/86657] ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/87165] Did you mean hints candidates equality

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |10.0

--- Comment #2 from Martin Liška  ---
Let me fix it.

[Bug c++/90757] inlining skips function parameter initialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
  float testValue = 3.25;
  char* warningAvoider = reinterpret_cast(&testValue);
  int32_t rawValue = *(reinterpret_cast(warningAvoider));

this is just invalid code.  Use -fno-strict-aliasing if you need to play
this kind of tricks or use memcpy to access the "raw value".

reinterpret_cast is not a way to circumvent type-based alias rules.

[Bug tree-optimization/90758] [7 Regression] spurious -Warray-bounds with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug c/90760] [8/9/10 Regression] ICE on attributes section and alias in set_section, at symtab.c:1573

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |8.4

--- Comment #2 from Richard Biener  ---
IIRC I've seen a duplicate.

[Bug tree-optimization/90768] better range analysis for converting bit tests into less-than greater-than

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
We miss a s < 16 && s & 8 simplification pattern in the code ifcombine uses
to do this (which should be removed / moved to match.pd and use its
machinery which I stated elsewhere).

[Bug libstdc++/90770] New: Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory

[tadeus.prastowo at unitn dot it]

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

Bug ID: 90770
   Summary: Building with --enable-libstdcxx-debug and make
profiledbootstrap fails with mv: cannot stat
'Makefile': No such file or directory
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tadeus.prastowo at unitn dot it
  Target Milestone: ---

Created attachment 46456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46456&action=edit
Complete terminal output during the non-parallel build

This issue is initially reported in gcc-help (see
https://gcc.gnu.org/ml/gcc-help/2019-05/msg00137.html) and has been confirmed
by one other person (see
https://gcc.gnu.org/ml/gcc-help/2019-06/msg00014.html).  The issue is
reproducible by unpacking the release tarball of GCC 9.1.0 (see
https://gcc.gnu.org/ml/gcc/2019-05/msg00024.html) and then building it by
configuring using configure switch `--enable-libstdcxx-debug' (e.g.,
../gcc-9/configure --prefix=$HOME/gcc-9 --enable-languages=c,c++
--enable-libstdcxx-debug --disable-multilib) and making using `make
profiledbootstrap'.  The build will fail with the following message (the
complete terminal output during the non-parallel build is attached; feel free
to request additional log files) whose solution is described at the end:

libtool: link: x86_64-linux-gnu-ranlib .libs/libstdc++convenience.a
libtool: link: rm -fr .libs/libstdc++convenience.lax
.libs/libstdc++convenience.lax
libtool: link: ( cd ".libs" && rm -f "libstdc++convenience.la" && ln -s
"../libstdc++convenience.la" "libstdc++convenience.la" )
if test ! -d
/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug; then \
  mkdir -p
/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug; \
  for d in c++98 c++11 c++17 filesystem; do mkdir -p 
/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/$d;
done; \
  (cd /home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug;
\
  sed -e 's/top_builddir = \.\./top_builddir = ..\/../' \
  -e 's/top_build_prefix = \.\./top_build_prefix = ..\/../' \
  -e 's/srcdir = \.\./srcdir = ..\/../' \
  -e 's/VPATH = \.\./VPATH = ..\/../' \
  -e 's/glibcxx_basedir = \.\./glibcxx_basedir = ..\/../' \
  -e 's/MKDIR_P = \.\./MKDIR_P = ..\/../' \
  < ../Makefile > Makefile ; \
  for d in . c++98 c++11 c++17 filesystem; do \
  sed -e 's/top_builddir = \.\./top_builddir = ..\/../' \
  -e 's/top_build_prefix = \.\./top_build_prefix = ..\/../' \
  -e 's/srcdir = \.\./srcdir = ..\/../' \
  -e 's/VPATH = \.\./VPATH = ..\/../' \
  -e 's/glibcxx_basedir = \.\./glibcxx_basedir = ..\/../' \
  -e 's/MKDIR_P = \.\./MKDIR_P = ..\/../' \
  < ../$d/Makefile > $d/Makefile ; \
  done) ; \
fi; \
echo `date` > stamp-debug;
(cd /home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug; \
  mv Makefile Makefile.tmp; \
  sed -e 's,all-local: all-once,all-local:,' \
  -e 's,install-data-local: install-data-once,install-data-local:,' \
  -e '/vpath/!s,src/c,src/debug/c,' \
  < Makefile.tmp > Makefile ; \
  rm -f Makefile.tmp ; \
  make CXXFLAGS='-gdwarf-4 -g3 -O0 -D_GLIBCXX_ASSERTIONS' \
  toolexeclibdir=/home/eus/gcc-9/lib/../lib64/debug all) ;
mv: cannot stat 'Makefile': No such file or directory
/bin/bash: line 2: Makefile.tmp: No such file or directory
make[7]: Entering directory
'/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug'
make[7]: *** No rule to make target 'all'.  Stop.
make[7]: Leaving directory
'/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug'
Makefile:1074: recipe for target 'build-debug' failed
make[6]: *** [build-debug] Error 2
make[6]: Leaving directory
'/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src'
Makefile:730: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
'/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src'
Makefile:562: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
'/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3'
Makefile:487: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory
'/home/eus/buildzone/gcc-9-build/x86_64-linux-gnu/libstdc++-v3'
Makefile:15380: recipe for target 'all-stagefeedback-target-libstdc++-v3'
failed
make[2]: *** [all-stagefeedback-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/home/eus/buildzone/gcc-9-build'
Makefile:22998: recipe for target 'stagefeedback-bubble' failed
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory '/home/eus/buildzone/gcc-9-build'
Makefile:23017: recipe for target 'profiledbootstrap' failed
make: *** [profiledbootstrap] Error 2

[Solut

[Bug c++/90757] inlining skips function parameter initialization

[martin.hierholzer at desy dot de]

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

--- Comment #2 from Martin Hierholzer  ---
Shouldn't all forms of this code then give an error message or at least a
warning (preferably not something misleading like "used uninitialized")? I my
opinion, it shouldn't matter whether the function is inlined or the loop is
omitted.

[Bug libstdc++/90770] Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-06
 Ever confirmed|0   |1

[Bug target/90751] -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[eb at emlix dot com]

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

Rolf Eike Beer  changed:

   What|Removed |Added

 CC||eb at emlix dot com

--- Comment #6 from Rolf Eike Beer  ---
Comment on attachment 46452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46452
Patch

The first hunk in config/pa/pa-linux.h only adds whitespace damage.

[Bug c++/87165] Did you mean hints candidates equality

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
So there are multiple problems:

-  add_misspelling_candidates function adds alternatives for an option, so e.g.
fno-sanitize-address-use-after-scope
-sanitize-address-use-after-scope
- we do not track the information
- in void consider (candidate_t candidate) we can bail out when we have
multiple candidates with equally good distance; but we have to distinguish a
situation when a candidate is an alternative to another candidate

I'm leaving that to David.

[Bug c++/87165] Did you mean hints candidates equality

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
It's probably also responsible for:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/spellcheck-options-4.c
--sanitize-recover=integer-divide-by-0 -c
cc1: error: unrecognized argument to ‘-fsanitize-recover=’ option:
‘integer-divide-by-0’; did you mean ‘integer-divide-by-zero’?

Note that user hasn't provided ‘-fsanitize-recover=’ on command line. That's
probably also related to the alternatives.

[Bug fortran/90742] OpenACC/OpenMP target offloading: Fortran 'allocatable' scalars in 'firstprivate' clauses

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Schwinge  ---
Jakub, is my understanding correct, that when a Fortran 'allocatable' is used
in a 'firstprivate' clause on an OpenMP 'target' construct, then that should do
"the obvious" thing?  (But it currently isn't.)  That is, behave similar as a
Fortran 'allocatable' used in a 'map' clause.  (Which does work as expected.)

I do note that OpenMP 5.0 doesn't seem to contain any words on this
specifically (in contrast to 'allocatable' with a 'map' clause; see 2.19.7.1
"'map' Clause", near the end), but I suppose (!) that's just because a
'firstprivate' clause need not be concerned about the case of "exit from the
region".  (Relate to how 2.19.4.5 "'lastprivate' Clause" in turn *does* talk
about 'allocatable' in context of "exit from [...]".)

(..., and then similarly also for a 'private' clause, as much as applicable,
which I have not yet checked.)

Cesar's patch "[OpenACC] Add support for firstprivate Fortran allocatable
scalars" (see link above) would fix at least some aspects of this (for OpenACC
only).

Also, so far, I only consider scalars.

[Bug debug/90574] [gdb] gdb wrongly stopped at a breakpoint in an unexecuted line of code

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Related testcase:

int main(int argc, char **argv)
{
  switch (argc)
{
case 0:
  {
foo:;
  }
case 1:;
}
  return 0;
}

breaking on the foo: line stops.

Fixing this is a two-edged sword - we do try to build an optimized CFG
(esp. for case label merging), creating more blocks defeats this.
It might be possible to move cleanup_dead_labels after make_edges
so that we can split blocks again when we make edges - but for
switch stmts that would be quite expensive as well.

But to fix these issues building more blocks is a requirement.

The following does this:

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 271990)
+++ gcc/tree-cfg.c  (working copy)
@@ -2722,10 +2722,10 @@ stmt_starts_bb_p (gimple *stmt, gimple *
  || FORCED_LABEL (gimple_label_label (label_stmt)))
return true;

-  if (prev_stmt && gimple_code (prev_stmt) == GIMPLE_LABEL)
+  if (glabel *plabel = safe_dyn_cast  (prev_stmt))
{
- if (DECL_NONLOCAL (gimple_label_label (
-  as_a  (prev_stmt
+ if (DECL_NONLOCAL (gimple_label_label (plabel))
+ || !DECL_ARTIFICIAL (gimple_label_label (plabel)))
return true;

  cfg_stats.num_merged_labels++;

it will ensure new BBs for consecutive user labels and artificial labels
following a user label assuming that is the target of a goto.

It prevents case merging for the above testcase during CFG build
when not optimizing CFG cleanup merges them though and in the correct
fasion, deleting the user label, when optimizing.

The debug experience is that gdb no longer stops at the line with the
label but setting a breakpoint on its line will stop at some other
line (that's a consumer issue I guess?).

[Bug fortran/90742] OpenACC/OpenMP target offloading: Fortran 'allocatable' scalars in 'firstprivate' clauses

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The firstprivate behavior should be covered by 2.19.3 "List Item Privatization"
because firstprivate is a privatization clause.
"For a list item or the subobject of a list item with the ALLOCATABLE
attribute:
• If the allocation status is unallocated, the new list item or the subobject
of the new list item will have an initial allocation status of unallocated;
• If the allocation status is allocated, the new list item or the subobject of
the new list item will have an initial allocation status of allocated; and
• If the new list item or the subobject of the new list item is an array, its
bounds will be the same as those of the original list item or the subobject of
the original list item."
So, for firstprivate(allocatable_var) one can allocate or deallocate or
reallocate as he wishes inside of the region.  I'd hope that at least for
non-target regions we implement it correctly, but it has been a while since
I've worked full time on Fortran OpenMP.
For the implicit mapping or privatization, there is also:
"If a scalar variable has the TARGET, ALLOCATABLE or POINTER attribute then it
is treated as if it has appeared in a map clause with a map-type of tofrom."
so allocatables are mapped by default if defaultmap clause is not present (or
is default).
For the map clause, there are additional restrictions:
"• If the allocation status of a list item or any subobject of the list item
with the ALLOCATABLE attribute is unallocated upon entry to a target region,
the list item or any subobject of the corresponding list item must be
unallocated upon exit from the region.
• If the allocation status of a list item or any subobject of the list item
with the ALLOCATABLE attribute is allocated upon entry to a target region, the
allocation status of the corresponding list item or any subobject of the
corresponding list item must not be changed and must not be reshaped in the
region."
So, while with firstprivate allocatable one can do anything he wishes, for
mapped allocatable if it is not allocated on mapping it should not be allocated
at the end either (so in the end it is like a private allocatable), and if it
is allocated its data can be mapped normally and user should not
allocate/deallocate/reallocate.

[Bug tree-optimization/90450] [9 Regression] Hash function in gather_mem_refs_stmt does not match with mem_ref_hasher::equal

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  6 11:06:45 2019
New Revision: 271995

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

Backport from mainline
2019-05-22  Richard Biener  

PR tree-optimization/90450
* tree-ssa-loop-im.c (struct im_mem_ref): Add ref_decomposed.
(mem_ref_hasher::equal): Check it.
(mem_ref_alloc): Initialize it.
(gather_mem_refs_stmt): Set it.

2019-05-15  Richard Biener  

PR c/90474
* c-common.c (c_common_mark_addressable_vec): Also mark
a COMPOUND_LITERAL_EXPR_DECL addressable similar to
c_mark_addressable.

2019-05-13  Richard Biener  

PR tree-optimization/90402
* tree-if-conv.c (tree_if_conversion): Value number only
the loop body by making the latch an exit of the region
as well.
* tree-ssa-sccvn.c (process_bb): Add flag whether to skip
processing PHIs.
(do_rpo_vn): Deal with multiple edges into the entry block
that are not backedges inside the region by skipping PHIs
of the entry block.

* gcc.dg/torture/pr90402-1.c: New testcase.

2019-05-06  Richard Biener  

PR tree-optimization/90328
* tree-data-ref.h (dr_may_alias_p): Pass in the actual loop nest.
* tree-data-ref.c (dr_may_alias_p): Check whether the clique
is valid in the loop nest before using it.
(initialize_data_dependence_relation): Adjust.
* graphite-scop-detection.c (build_alias_set): Pass the SCOP enclosing
loop as loop-nest to dr_may_alias_p.

* gcc.dg/torture/pr90328.c: New testcase.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr90328.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr90402-1.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/c-family/ChangeLog
branches/gcc-9-branch/gcc/c-family/c-common.c
branches/gcc-9-branch/gcc/graphite-scop-detection.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-data-ref.c
branches/gcc-9-branch/gcc/tree-data-ref.h
branches/gcc-9-branch/gcc/tree-if-conv.c
branches/gcc-9-branch/gcc/tree-ssa-loop-im.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/90402] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  6 11:06:45 2019
New Revision: 271995

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

Backport from mainline
2019-05-22  Richard Biener  

PR tree-optimization/90450
* tree-ssa-loop-im.c (struct im_mem_ref): Add ref_decomposed.
(mem_ref_hasher::equal): Check it.
(mem_ref_alloc): Initialize it.
(gather_mem_refs_stmt): Set it.

2019-05-15  Richard Biener  

PR c/90474
* c-common.c (c_common_mark_addressable_vec): Also mark
a COMPOUND_LITERAL_EXPR_DECL addressable similar to
c_mark_addressable.

2019-05-13  Richard Biener  

PR tree-optimization/90402
* tree-if-conv.c (tree_if_conversion): Value number only
the loop body by making the latch an exit of the region
as well.
* tree-ssa-sccvn.c (process_bb): Add flag whether to skip
processing PHIs.
(do_rpo_vn): Deal with multiple edges into the entry block
that are not backedges inside the region by skipping PHIs
of the entry block.

* gcc.dg/torture/pr90402-1.c: New testcase.

2019-05-06  Richard Biener  

PR tree-optimization/90328
* tree-data-ref.h (dr_may_alias_p): Pass in the actual loop nest.
* tree-data-ref.c (dr_may_alias_p): Check whether the clique
is valid in the loop nest before using it.
(initialize_data_dependence_relation): Adjust.
* graphite-scop-detection.c (build_alias_set): Pass the SCOP enclosing
loop as loop-nest to dr_may_alias_p.

* gcc.dg/torture/pr90328.c: New testcase.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr90328.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr90402-1.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/c-family/ChangeLog
branches/gcc-9-branch/gcc/c-family/c-common.c
branches/gcc-9-branch/gcc/graphite-scop-detection.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-data-ref.c
branches/gcc-9-branch/gcc/tree-data-ref.h
branches/gcc-9-branch/gcc/tree-if-conv.c
branches/gcc-9-branch/gcc/tree-ssa-loop-im.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/90474] [7/8/9 Regression] ICE: verify_gimple failed (error: DECL_GIMPLE_REG_P set on a variable with address taken; error: invalid address operand in MEM_REF)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  6 11:06:45 2019
New Revision: 271995

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

Backport from mainline
2019-05-22  Richard Biener  

PR tree-optimization/90450
* tree-ssa-loop-im.c (struct im_mem_ref): Add ref_decomposed.
(mem_ref_hasher::equal): Check it.
(mem_ref_alloc): Initialize it.
(gather_mem_refs_stmt): Set it.

2019-05-15  Richard Biener  

PR c/90474
* c-common.c (c_common_mark_addressable_vec): Also mark
a COMPOUND_LITERAL_EXPR_DECL addressable similar to
c_mark_addressable.

2019-05-13  Richard Biener  

PR tree-optimization/90402
* tree-if-conv.c (tree_if_conversion): Value number only
the loop body by making the latch an exit of the region
as well.
* tree-ssa-sccvn.c (process_bb): Add flag whether to skip
processing PHIs.
(do_rpo_vn): Deal with multiple edges into the entry block
that are not backedges inside the region by skipping PHIs
of the entry block.

* gcc.dg/torture/pr90402-1.c: New testcase.

2019-05-06  Richard Biener  

PR tree-optimization/90328
* tree-data-ref.h (dr_may_alias_p): Pass in the actual loop nest.
* tree-data-ref.c (dr_may_alias_p): Check whether the clique
is valid in the loop nest before using it.
(initialize_data_dependence_relation): Adjust.
* graphite-scop-detection.c (build_alias_set): Pass the SCOP enclosing
loop as loop-nest to dr_may_alias_p.

* gcc.dg/torture/pr90328.c: New testcase.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr90328.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr90402-1.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/c-family/ChangeLog
branches/gcc-9-branch/gcc/c-family/c-common.c
branches/gcc-9-branch/gcc/graphite-scop-detection.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-data-ref.c
branches/gcc-9-branch/gcc/tree-data-ref.h
branches/gcc-9-branch/gcc/tree-if-conv.c
branches/gcc-9-branch/gcc/tree-ssa-loop-im.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/90450] [9 Regression] Hash function in gather_mem_refs_stmt does not match with mem_ref_hasher::equal

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.1.1
 Resolution|--- |FIXED
  Known to fail||9.1.0

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/90402] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.1.1
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug fortran/86657] ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Reduced test-case:

$ cat dec.f03
  type :: mytype (a,b)
integer, kind :: a  
integer, LEN :: b

  end type
end

[Bug debug/90574] [gdb] gdb wrongly stopped at a breakpoint in an unexecuted line of code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Note these issues also appear as coverage errors:

-:0:Source:t.c
-:0:Graph:t.gcno
-:0:Data:t.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int main(int argc, char **argv)
-:2:{
-:3:  if (argc == 0)
-:4:{
-:5:  int *ptr;
1:6:label:
-:7:{
-:8:}
-:9:}
1:   10:  if (argc == 1)
-:   11:{
1:   12:  __builtin_printf("hello\n");
-:   13:}
1:   14:  return 0;
-:   15:}

[Bug debug/90574] [gdb] gdb wrongly stopped at a breakpoint in an unexecuted line of code

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Richard Biener from comment #4)
> Note these issues also appear as coverage errors:
> 
> -:0:Source:t.c
> -:0:Graph:t.gcno
> -:0:Data:t.gcda
> -:0:Runs:1
> -:0:Programs:1
> 1:1:int main(int argc, char **argv)
> -:2:{
> -:3:  if (argc == 0)
> -:4:{
> -:5:  int *ptr;
> 1:6:label:
> -:7:{
> -:8:}
> -:9:}
> 1:   10:  if (argc == 1)
> -:   11:{
> 1:   12:  __builtin_printf("hello\n");
> -:   13:}
> 1:   14:  return 0;
> -:   15:}

If you take a look at following list:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&email1=yangyibiao%40nju.edu.cn&emailreporter1=1&emailtype1=substring&list_id=239143&query_format=advanced

You'll find bazillion of similar test-cases where we optimize CFG before
gimplification happens.

[Bug rtl-optimization/88751] Performance regression reload vs lra

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Jun  6 11:35:04 2019
New Revision: 271996

URL: https://gcc.gnu.org/viewcvs?rev=271996&root=gcc&view=rev
Log:
Fix PR88751

This patch implements a small improvement for the heuristic in lra
which decides when it has to activate the simpler register allocation
algorithm.

gcc/ChangeLog:

2019-06-06  Andreas Krebbel  

PR rtl-optimization/88751
* ira.c (ira): Use the number of the actually referenced registers
when calculating the threshold.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c

[Bug target/90751] -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[dave.anglin at bell dot net]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2019-06-06 5:56 a.m., eb at emlix dot com wrote:
> The first hunk in config/pa/pa-linux.h only adds whitespace damage.
No, it adds a period to end sentence.

[Bug debug/90574] [gdb] gdb wrongly stopped at a breakpoint in an unexecuted line of code

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
*** Bug 89673 has been marked as a duplicate of this bug. ***

[Bug gcov-profile/89673] [GCOV] A label followed with a blank(empty) statement will be wrongly marked as executed in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Martin Liška  ---
Dup.

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

[Bug target/90751] -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[eb at emlix dot com]

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

--- Comment #8 from Rolf Eike Beer  ---
(In reply to dave.anglin from comment #7)
> On 2019-06-06 5:56 a.m., eb at emlix dot com wrote:
> > The first hunk in config/pa/pa-linux.h only adds whitespace damage.
> No, it adds a period to end sentence.

I stand corrected.

[Bug fortran/86657] ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
So the test-case needs -fdec which is described as:
These features are non-standard and should be avoided at all costs.

So that I leave the issue.

[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #20 from Vincent Lefèvre  ---
Similar to comment 16:

void d (unsigned int a, unsigned int b)
{
  unsigned int diff = a - b;
  if (diff == 0)
feq ();
  else if (diff > a)
flt ();
  else
fgt ();
}

is not optimized.

Under Debian, GCC 10.0.0 20190527 (experimental) [trunk revision 271671] gives
for x86_64 (i386 is similar):

[...]
xorl%eax, %eax
cmpl%esi, %edi
setb%al
je  .L7
testl   %eax, %eax
je  .L5
[...]

I would expect just a cmpl, a je and a jl.

[Bug libstdc++/90700] Wrong constraints for tuple(allocator_arg_t, const A&, const tuple

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Jun  6 12:13:36 2019
New Revision: 271998

URL: https://gcc.gnu.org/viewcvs?rev=271998&root=gcc&view=rev
Log:
Refactor SFINAE constraints on std::tuple constructors

Replace the _TC class template with the better-named _TupleConstraints
one, which provides a different set of member functions. The new members
do not distinguish construction from lvalues and rvalues, but expects
the caller to do that by providing different template arguments. Within
the std::tuple primary template and std::tuple partial
specialization the _TupleConstraints members are used via new alias
templates like _ImplicitCtor and _ExplicitCtor which makes the
constructor constraints less verbose and repetitive. For example, where
we previously had:

 template::template
   _MoveConstructibleTuple<_UElements...>()
 && _TMC<_UElements...>::template
   _ImplicitlyMoveConvertibleTuple<_UElements...>()
 && (sizeof...(_Elements) >= 1),
   bool>::type=true>
   constexpr tuple(_UElements&&... __elements)

We now have:

 template(),
 _ImplicitCtor<_Valid, _UElements...> = true>
  constexpr
  tuple(_UElements&&... __elements)

There are two semantic changes as a result of the refactoring:

- The allocator-extended default constructor is now constrained.
- The rewritten constraints fix PR 90700.

* include/std/tuple (_TC): Replace with _TupleConstraints.
(_TupleConstraints): New helper for SFINAE constraints, with more
expressive member functions to reduce duplication when used.
(tuple::_TC2, tuple::_TMC, tuple::_TNTC): Remove.
(tuple::_TCC): Replace dummy type parameter with bool non-type
parameter that can be used to check the pack size.
(tuple::_ImplicitDefaultCtor, tuple::_ExplicitDefaultCtor)
(tuple::_ImplicitCtor, tuple::_ExplicitCtor): New alias templates for
checking constraints in constructors.
(tuple::__valid_args, tuple::_UseOtherCtor, tuple::__use_other_ctor):
New SFINAE helpers.
(tuple::tuple): Use new helpers to reduce repitition in constraints.
(tuple::tuple(allocator_arg_t, const Alloc&)): Constrain.
(tuple::_TCC, tuple::_ImplicitDefaultCtor)
(tuple::_ExplicitDefaultCtor, tuple::_ImplicitCtor)
(tuple::_ExplicitCtor): New alias templates for checking
constraints in constructors.
(tuple::__is_alloc_arg()): New SFINAE helpers.
(tuple::tuple): Use new helpers to reduce repitition in
constraints.
(tuple::tuple(allocator_arg_t, const Alloc&)): Constrain.
* testsuite/20_util/tuple/cons/90700.cc: New test.
* testsuite/20_util/tuple/cons/allocators.cc: Add default constructor
to meet new constraint on allocator-extended default constructor.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/cons/90700.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
trunk/libstdc++-v3/testsuite/20_util/tuple/cons/allocators.cc

[Bug c++/90757] inlining skips function parameter initialization

[jens.georg at desy dot de]

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

--- Comment #3 from Jens Georg  ---
I mean even if the code in main is invalid, so what. If we replace that by
memcopy, the function argument is still not initialized when inlined.

IMHOt there's something fishy, but well. your decision

[Bug other/76739] Add support dynamically allocated multi-dimensional arrays in OpenACC data clauses

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||tschwinge at gcc dot gnu.org
   Assignee|chunglin.tang at gmail dot com |unassigned at gcc dot 
gnu.org

--- Comment #1 from Thomas Schwinge  ---
Nobody is actively working on that right now.


Initial pieces got into the OpenACC development branch (gomp-4_0-branch at that
time, r244259),
. 
That got forward-ported to later development branches.

As far as I know, that work is not yet ready for trunk inclusion.

[Bug fortran/86657] ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Blocks|86656   |82173

--- Comment #4 from Dominique d'Humieres  ---
> So the test-case needs -fdec which is described as:

The test in comment 2 has nothing to do with -fdec, but is likely another
problem with parametrized derived type triggered by asan and -fdec.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
[Bug 82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
[Bug 86656] [meta-bug] Issues found with -fsanitize=address

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jun  6 13:59:07 2019
New Revision: 272002

URL: https://gcc.gnu.org/viewcvs?rev=272002&root=gcc&view=rev
Log:
[AArch64] PR tree-optimization/90332: Implement vec_init where N is a
vector mode

This patch fixes the failing gcc.dg/vect/slp-reduc-sad-2.c testcase on aarch64
by implementing a vec_init optab that can handle two half-width vectors
producing a full-width one
by concatenating them.

In the gcc.dg/vect/slp-reduc-sad-2.c case it's a V8QI reg concatenated with a
V8QI const_vector of zeroes.
This can be implemented efficiently using the aarch64_combinez pattern that
just loads a D-register to make
use of the implicit zero-extending semantics of that load.
Otherwise it concatenates the two vector using aarch64_simd_combine.

With this patch I'm seeing the effect from richi's original patch that added
gcc.dg/vect/slp-reduc-sad-2.c on aarch64
and 525.x264_r improves by about 1.5%.

PR tree-optimization/90332
* config/aarch64/aarch64.c (aarch64_expand_vector_init):
Handle VALS containing two vectors.
* config/aarch64/aarch64-simd.md (*aarch64_combinez): Rename
to...
(@aarch64_combinez): ... This.
(*aarch64_combinez_be): Rename to...
(@aarch64_combinez_be): ... This.
(vec_init): New define_expand.
* config/aarch64/iterators.md (Vhalf): Handle V8HF.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-simd.md
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/iterators.md

[Bug c++/90757] inlining skips function parameter initialization

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
myScalarToCooked is of course similar broken.  The following works fine for me:

#include 

/** Inefficient convenience function for converting a single value to cooked */
double myScalarToCooked(int32_t raw) {
float cooked;

for (auto it = &raw; it != (&raw) + 1; ++it) {
float genericRepresentation;
__builtin_memcpy (&genericRepresentation, it, 4);
*(&cooked) = genericRepresentation;
}

return cooked;
}

int main()
{
  float testValue = 3.25;
  int32_t rawValue;
  __builtin_memcpy (&rawValue, &testValue, 4);

  std::cout << myScalarToCooked(rawValue) << std::endl;

  return 0;
}

[Bug libstdc++/90700] Wrong constraints for tuple(allocator_arg_t, const A&, const tuple

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|10.0|9.2

--- Comment #3 from Jonathan Wakely  ---
Fixed for 9.2, but probably not important enough to backport as it's a
contrived example.

[Bug libstdc++/90702] FAIL: 26_numerics/complex/proj.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/9663] [arm] gcc-20030127 misses an optimization opportunity

[fredrik.hederstie...@securitas-direct.com]

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

Fredrik Hederstierna  changed:

   What|Removed |Added

 CC||fredrik.hederstierna@securi
   ||tas-direct.com

--- Comment #10 from Fredrik Hederstierna 
 ---
Created attachment 46457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46457&action=edit
Testcase from CSiBE teem sources

Testcase from CSiBE teem sources
Tested with gcc-9.1.0 for ARM 32bit targets.

Without peephole2

 :
   0:   e92d407fpush{r0, r1, r2, r3, r4, r5, r6, lr}
   4:   e2504000subsr4, r0, #0
   8:   0a3fbeq 10c 
   c:   e351cmp r1, #0
  10:   e1a05001mov r5, r1

With peephole2

 :
   0:   e92d407fpush{r0, r1, r2, r3, r4, r5, r6, lr}
   4:   e2504000subsr4, r0, #0
   8:   0a3ebeq 108 
   c:   e2515000subsr5, r1, #0

/Fredrik

[Bug target/9663] [arm] gcc-20030127 misses an optimization opportunity

[rearnsha at gcc dot gnu.org]

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

--- Comment #11 from Richard Earnshaw  ---
(In reply to Fredrik Hederstierna from comment #10)
> Created attachment 46457 [details]
> Testcase from CSiBE teem sources
> 
> Testcase from CSiBE teem sources
> Tested with gcc-9.1.0 for ARM 32bit targets.
> 
> Without peephole2
> 
>  :
>0: e92d407fpush{r0, r1, r2, r3, r4, r5, r6, lr}
>4: e2504000subsr4, r0, #0
>8: 0a3fbeq 10c 
>c: e351cmp r1, #0
>   10: e1a05001mov r5, r1
> 
> With peephole2
> 
>  :
>0: e92d407fpush{r0, r1, r2, r3, r4, r5, r6, lr}
>4: e2504000subsr4, r0, #0
>8: 0a3ebeq 108 
>c: e2515000subsr5, r1, #0
> 
> /Fredrik

Can you run this through your preprocessor to remove the dependencies on
external headers?

[Bug target/9663] [arm] gcc-20030127 misses an optimization opportunity

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #12 from Fredrik Hederstierna 
 ---
Created attachment 46458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46458&action=edit
range ran through preprocessor using -E -P

I'm not sure if this is what you wanted, but here is file stand-alone
compile-able, without headers. Compiled with -E -P.
/Fredrik

[Bug tree-optimization/90766] strlen(a + i) missing range for arrays of unknown bound with strings of known length and variable i

[tavianator at gmail dot com]

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

Tavian Barnes  changed:

   What|Removed |Added

 CC||tavianator at gmail dot com

--- Comment #2 from Tavian Barnes  ---
If char b[] = "123\01234"; then it can't be folded to false for i == 4, right? 
Presumably g() is only folded because you have &s[i] not &a[i].

[Bug tree-optimization/90766] strlen(a + i) missing range for arrays of unknown bound with strings of known length and variable i

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Yes, good catch, thanks!

The call can only be folded if i is known to be less than or equal to the
length of the string, or if the rest of the buffer is all nuls.  The strlen
pass can readily determine the first, i.e., it can do the folding here:

  extern char a[8];

  unsigned f (unsigned i)
  {
__builtin_strcpy (a, "123");
if (i > 3) i = 3;
return __builtin_strlen (&a[i]);   // can be folded to 3 - i
  }

The pass doesn't track the the trailing nuls yet so it can't easily do the
folding in cases like below:

  unsigned g (unsigned i)
  {
__builtin_memset (a, 0, sizeof a);
__builtin_strcpy (a, "123");
return __builtin_strlen (&a[i]);   // can be folded to (i <= 3 ? 3 - i : 0)
  }


like the folder does for constant strings:

  const char a[8] = "123";

  unsigned h (unsigned i)
  {
return __builtin_strlen (&a[i]);   // folded to (i <= 3 ? 3 - i : 0)
  }

[Bug fortran/90744] [7/8/9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Tomáš Trnka from comment #3)

> I'm not sure how to fix this properly, but the following one-liner seems to
> work for me:
> 
> --- a/gcc/fortran/trans-types.c
> +++ b/gcc/fortran/trans-types.c
> @@ -3006,6 +3006,7 @@ get_formal_from_actual_arglist (gfc_symbol *sym,
> gfc_actual_arglist *actual_args
> {
>   s->ts = a->expr->ts;
>   s->attr.flavor = FL_VARIABLE;
> + s->ts.deferred = false;
>   if (a->expr->rank > 0)
> {
>   s->attr.dimension = 1;

Good analysis, and this is indeed the correct fix.

(In this case, it is the actual argument that is deferred, it does
not make sense for the dummy argument to have the same attribute
in the absence of an explicit interface).

Do you have a gcc copyright assignment (and possibly commit privileges),
by any chance?  If not, I'll commit your patch, as it is both
obvious and simple, and is definitely small enough so no
copyright assignment is needed.

Thanks!

[Bug libgomp/90771] New: Omp for with default(none) and const variable fails to compile

[jodebo_beck at gmx dot de]

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

Bug ID: 90771
   Summary: Omp for with default(none) and const variable fails to
compile
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jodebo_beck at gmx dot de
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Compiling the following code works with gcc 8.3 but no longer works with gcc 9:

int getNumRows() {
return 10;
}

int main() {
const int rows = getNumRows();

#pragma omp parallel for default( none )
for( int row = 0; row < rows ; ++row) {
}
}

Compiler with g++ -fopenmp results in the following error message:
: In function 'int main()':
:9:5: error: 'rows' not specified in enclosing 'parallel'
9 | for( int row = 0; row < rows ; ++row) {
  | ^~~
:8:13: error: enclosing 'parallel'
8 | #pragma omp parallel for default( none )
  | ^~~
Compiler returned: 1

(link to compiler explorer: https://godbolt.org/z/YfO7tD)

I am not sure, if the code is not correct or if this is a regression. Clang and
MSVC does compile it.

[Bug libgomp/90771] Omp for with default(none) and const variable fails to compile

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
See https://gcc.gnu.org/gcc-9/porting_to.html#ompdatasharing

[Bug fortran/90744] [7/8/9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

[trnka at scm dot com]

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

--- Comment #5 from Tomáš Trnka  ---
(In reply to Thomas Koenig from comment #4)
> Good analysis, and this is indeed the correct fix.

OK. I thought that perhaps get_formal_from_actual_arglist() should be done
already before processing the arguments for the first call so that all calls go
through the same processing (just in case there were more bugs lurking in the
current approach). Not sure if that makes any sense, though.

> Do you have a gcc copyright assignment (and possibly commit privileges),
> by any chance?

Unfortunately not, but I could certainly sort out the copyright assignment if
necessary. It'd be best if you can just commit it for me. Thanks!

[Bug testsuite/90772] New: [10 regression] g++.dg/cpp1y/feat-cxx14.C and several others fails starting with r272011

[seurer at gcc dot gnu.org]

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

Bug ID: 90772
   Summary: [10 regression] g++.dg/cpp1y/feat-cxx14.C and several
others fails starting with r272011
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Looks like a few more test cases need updating:

New failures (update from 271994 to 272011):
FAIL: g++.dg/cpp1y/feat-cxx14.C   (test for excess errors)
FAIL: g++.dg/cpp1z/feat-cxx1z.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/cpp1z/pr85569.C  -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp2a/feat-cxx2a.C   (test for excess errors)

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++17 -I/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1y
-I/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1y/testinc  -S -o
feat-cxx1z.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++17 -I/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1y
-I/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1y/testinc -S -o
feat-cxx1z.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C:295:26:
error: 'size_t' has not been declared
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C:296:35:
error: '_Num' was not declared in this scope
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C:296:39:
error: template argument 2 is invalid
compiler exited with status 1
FAIL: g++.dg/cpp1z/feat-cxx1z.C  -std=gnu++17 (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C:295:26:
error: 'size_t' has not been declared
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C:296:35:
error: '_Num' was not declared in this scope
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C:296:39:
error: template argument 2 is invalid

[Bug testsuite/90772] [10 regression] g++.dg/cpp1y/feat-cxx14.C and several others fails starting with r272011

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 46459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46459&action=edit
gcc10-pr90772.patch

Fix, tested on x86_64-linux.

[Bug testsuite/90772] [10 regression] g++.dg/cpp1y/feat-cxx14.C and several others fails starting with r272011

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Also (in case these were missed):

FAIL: g++.dg/tree-ssa/pr69336.C   (test for excess errors)
FAIL: g++.dg/tree-ssa/pr80293.C   (test for excess errors)

which I thought were caused by something else but look like the same thing.

Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0  
-O3 -fdump-tree-optimized -std=c++14  -S -o pr69336.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -O3
-fdump-tree-optimized -std=c++14 -S -o pr69336.s
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:8:30: error:
'size_t' has not been declared
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:14:33:
error: 'size_t' was not declared in this scope; did you mean 'std::size_t'?
In file included from
/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/utility:68,
 from
/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/array:38,
 from
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:4:
/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu/bits/c++config.h:253:26:
note: 'std::size_t' declared here
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:14:51:
error: template argument 1 is invalid
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:15:3: error:
'_value_type' does not name a type; did you mean 'value_type'?
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:16:20:
error: '_value_type' does not name a type; did you mean 'value_type'?
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:32:
error: 'size_t' has not been declared
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:42:
error: 'size_t' has not been declared
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:84:
error: 'N' was not declared in this scope
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:85:
error: template argument 3 is invalid
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:138:
error: 'N' was not declared in this scope
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:109:
error: expected primary-expression before 'const'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:162:
error: 'I' was not declared in this scope
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:163:
error: expected parameter pack before '...'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:166:
error: template argument 1 is invalid
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:167:
error: expression list treated as compound expression in initializer
[-fpermissive]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:41:168:
error: expected ';' before '{' token
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:46:30:
error: 'size_t' has not been declared
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:46:69:
error: 'N' was not declared in this scope
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:46:70:
error: template argument 3 is invalid
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:46:118:
error: 'N' was not declared in this scope
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C: In function
'constexpr int make_static_map(...)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C:48:48:
error: 'N' was not declared in

[Bug testsuite/90772] [10 regression] g++.dg/cpp1y/feat-cxx14.C and several others fails starting with r272011

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2019-06/msg00384.htm
   ||l

--- Comment #3 from Jakub Jelinek  ---
Updated patch: http://gcc.gnu.org/ml/gcc-patches/2019-06/msg00384.html

[Bug fortran/90744] [7/8/9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Tomáš Trnka from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Good analysis, and this is indeed the correct fix.
> 
> OK. I thought that perhaps get_formal_from_actual_arglist() should be done
> already before processing the arguments for the first call so that all calls
> go through the same processing (just in case there were more bugs lurking in
> the current approach). Not sure if that makes any sense, though.

During resolution? Might also make sense, but the order of resolving
things is quite fragile, and easy to get wrong... I will check.

[Bug c++/60531] template function not resolved when comparing functions

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

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

--- Comment #6 from Harald van Dijk  ---
Thanks for approving and committing!

[Bug c++/60869] ICE on throw after invalid definition of __cxa_throw

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

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

--- Comment #1 from Harald van Dijk  ---
This is fixed in GCC 9, which gives:

  error: '__cxa_throw' declared incorrectly

[Bug other/90695] [10 regression] g++.dg/cpp0x/noexcept15.C fails starting with r271806

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Jonathan Wakely  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00390.html

[Bug middle-end/90773] New: Improve piecewise operation

[hjl.tools at gmail dot com]

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

Bug ID: 90773
   Summary: Improve piecewise operation
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

For

[hjl@gnu-cfl-1 pieces-6]$ cat copy.i 
extern char *dst, *src;

void
foo (unsigned int x)
{
  __builtin_memcpy (dst, src, 15);
}
[hjl@gnu-cfl-1 pieces-6]$ 

we generate

movqsrc(%rip), %rdx
movqdst(%rip), %rax
movq(%rdx), %rcx
movq%rcx, (%rax)
movl8(%rdx), %ecx
movl%ecx, 8(%rax)
movzwl  12(%rdx), %ecx
movw%cx, 12(%rax)
movzbl  14(%rdx), %edx
movb%dl, 14(%rax)
ret

Instead, we can generate

movqsrc(%rip), %rdx
movqdst(%rip), %rax
movq(%rdx), %rcx
movq%rcx, (%rax)
movq7(%rdx), %rcx
movq%rcx, 7(%rax)
ret

[Bug testsuite/90772] [10 regression] g++.dg/cpp1y/feat-cxx14.C and several others fails starting with r272011

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Sorry about this. I thought I'd actually run the g++ tests this time, but I
didn't use -k and they didn't actually run (and so I saw no FAILs ... which
should have rung alarm bells because guality tests always fail).

[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec

[wilson at gcc dot gnu.org]

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

--- Comment #6 from Jim Wilson  ---
Author: wilson
Date: Thu Jun  6 23:18:48 2019
New Revision: 272021

URL: https://gcc.gnu.org/viewcvs?rev=272021&root=gcc&view=rev
Log:
RISC-V: Move STARTFILE_PREFIX_SPEC into target OS files.

gcc/
PR target/89955
* config/riscv/riscv.h (STARTFILE_PREFIX_SPEC): Deleted.
* config/riscv/freebsd.h (STARTFILE_PREFIX_SPEC): Added.
* config/riscv/linux.h (STARTFILE_PREFIX_SPEC): Added.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/riscv/freebsd.h
trunk/gcc/config/riscv/linux.h
trunk/gcc/config/riscv/riscv.h

[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #7 from Jim Wilson  ---
Fixed on mainline.

[Bug middle-end/90774] New: avoid doing vector splat arithmetic where possible

[slandden at gmail dot com]

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

Bug ID: 90774
   Summary: avoid doing vector splat arithmetic where possible
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slandden at gmail dot com
  Target Milestone: ---

When gcc knows that it is dealing with splats it should just do regular
arithmetic, and only convert to splat at the end.

https://simd.godbolt.org/z/6P3Qcq

[Bug c++/90775] New: A inconsistent compilation result

[zhonghao at pku dot org.cn]

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

Bug ID: 90775
   Summary: A inconsistent compilation result
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

My g++ is 10.0.0, and my code is as follows:

#include 
#include 
struct S {};
int begin(S);
template std::true_type has_cbegin(decltype(std::cbegin(T{})));
template std::false_type has_cbegin(...);
static_assert(!decltype(has_cbegin(0))::value);

When compiling with -c -std=c++14, it accepts the code. However, when compiling
with -c -std=c++11 or -c -std=c++0x

/home/haozhong/project/approach/compilerpara/llvm/tmp/llvm_28927/code0.c.cpp:5:59:error:‘cbegin’
is not a member of ‘std’; did you mean ‘begin’?
5 | template std::true_type
has_cbegin(decltype(std::cbegin(T{})));
  |   ^~
  |   begin
/home/haozhong/project/approach/compilerpara/llvm/tmp/llvm_28927/code0.c.cpp:5:59:
error:‘cbegin’ is not a member of ‘std’; did you mean ‘begin’?
5 | template std::true_type
has_cbegin(decltype(std::cbegin(T{})));
  |   ^~
  |   begin
/home/haozhong/project/approach/compilerpara/llvm/tmp/llvm_28927/code0.c.cpp:7:15:
error: static assertion failed
7 | static_assert(!decltype(has_cbegin(0))::value);
  |   ^~

Something wrong with -std=c++14?

[Bug libstdc++/90775] A inconsistent compilation result

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
std::cbegin was only added in c++14.

[Bug c++/90776] New: g++ -fms-extensions is inconsistent with Microsoft's compiler

[zhonghao at pku dot org.cn]

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

Bug ID: 90776
   Summary: g++ -fms-extensions is inconsistent with Microsoft's
compiler
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is:

typedef struct a {} A;

void f() {
 if (__builtin_alignof(A))
 ;
}

g++ -fms-extensions rejects the code:

 error: ‘__builtin_alignof’ was not declared in this scope; did you mean
‘__builtin_asinhf’?
4 |  if (__builtin_alignof(A))
  |  ^
  |  __builtin_asinhf

clang++ -fms-extensions accepts the code, and Microsoft's compiler also accepts
the code:

https://godbolt.org/z/HIAYtj

Another code sample is:

class __declspec(dllexport) A
{};

g++ rejects the code:

 error: expected initializer before ‘A’
1 | class __declspec(dllexport) A
  |  

Microsoft's compiler accepts it.

[Bug c++/90776] g++ -fms-extensions is inconsistent with Microsoft's compiler

[zhonghao at pku dot org.cn]

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

--- Comment #1 from zhonghao at pku dot org.cn ---
Another code sample:

typedef union __declspec(align(64)) foo_t {
 double a[8];
} foo_t;

foo_t bar;

[Bug other/46489] tree optimizer and frontend files use target macros

[egallager at gcc dot gnu.org]

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

--- Comment #10 from Eric Gallager  ---
(In reply to Eric Gallager from comment #9)
> (In reply to Joseph S. Myers from comment #7)
> > FWIW, the following files include tm.h and appear not to have any direct
> > uses of target macros, or uses of the most common headers (such as rtl.h or
> > cp-tree.h) that depend on tm.h.  They require more careful checks of what
> > headers they are using for any hidden tm.h dependencies, but may be good
> > candidates for the removal of tm.h includes.
> > 
> > gcc/java/except.c
> > gcc/java/jvgenmain.c
> > gcc/java/jvspec.c
> > gcc/java/mangle.c
> > gcc/java/zextract.c
> 
> I don't know about the rest of them, but these at least are gone.

I checked for other removals:

(In reply to Joseph S. Myers from comment #7)
> gcc/c-aux-info.c
> gcc/c-convert.c
> gcc/c-errors.c
> gcc/c-lang.c
> gcc/c-parser.c

These have all been moved to gcc/c/

> gcc/cppspec.c

This has been moved to gcc/c-family/

> gcc/tree-nomudflap.c
> gcc/tree-optimize.c
> gcc/tree-ssa-copyrename.c

These 3 appear to have been removed.

[Bug tree-optimization/78902] Add warn_unused_attribute for builtins with alloc_size

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Fri Jun  7 05:33:11 2019
New Revision: 272028

URL: https://gcc.gnu.org/viewcvs?rev=272028&root=gcc&view=rev
Log:
Add warn_unused_result for malloc-like functions (PR tree-optimization/78902).

2019-06-07  Martin Liska  

PR tree-optimization/78902
* builtin-attrs.def (ATTR_WARN_UNUSED_RESULT): New.
(ATTR_MALLOC_NOTHROW_LEAF_LIST): Remove.
(ATTR_WARN_UNUSED_RESULT_NOTHROW_LEAF_LIST): New.
(ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_LEAF_LIST): New.
(ATTR_ALLOC_SIZE_2_NOTHROW_LIST): Remove.
(ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST): Remove.
(ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_LIST): New.
(ATTR_ALLOC_WARN_UNUSED_RESULT_SIZE_2_NOTHROW_LIST): New.
(ATTR_MALLOC_WARN_UNUSED_RESULT_SIZE_1_NOTHROW_LEAF_LIST): New.
(ATTR_ALLOCA_SIZE_1_NOTHROW_LEAF_LIST): Remove.
(ATTR_ALLOCA_WARN_UNUSED_RESULT_SIZE_1_NOTHROW_LEAF_LIST): New.
(ATTR_MALLOC_SIZE_1_2_NOTHROW_LEAF_LIST):  Remove.
(ATTR_MALLOC_WARN_UNUSED_RESULT_SIZE_1_2_NOTHROW_LEAF_LIST):
New.
(ATTR_ALLOC_SIZE_2_NOTHROW_LEAF_LIST): Remove.
(ATTR_ALLOC_WARN_UNUSED_RESULT_SIZE_2_NOTHROW_LEAF_LIST): New.
(ATTR_MALLOC_NOTHROW_NONNULL): Remove.
(ATTR_WARN_UNUSED_RESULT_NOTHROW_NONNULL): New.
(ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL): New.
(ATTR_MALLOC_NOTHROW_NONNULL_LEAF): Remove.
(ATTR_WARN_UNUSED_RESULT_NOTHROW_NONNULL_LEAF): New.
(ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL_LEAF): New.
* builtins.def (BUILT_IN_ALIGNED_ALLOC): Change to use
warn_unused_result attribute.
(BUILT_IN_STRDUP): Likewise.
(BUILT_IN_STRNDUP): Likewise.
(BUILT_IN_ALLOCA): Likewise.
(BUILT_IN_CALLOC): Likewise.
(BUILT_IN_MALLOC): Likewise.
(BUILT_IN_REALLOC): Likewise.
2019-06-07  Martin Liska  

PR tree-optimization/78902
* c-c++-common/asan/alloca_loop_unpoisoning.c: Use result
of __builtin_alloca.
* c-c++-common/asan/pr88619.c: Likewise.
* g++.dg/overload/using2.C: Likewise for malloc.
* gcc.dg/attr-alloc_size-5.c: Add new dg-warning.
* gcc.dg/nonnull-3.c: Use result of __builtin_strdup.
* gcc.dg/pr43643.c: Likewise.
* gcc.dg/pr59717.c: Likewise for calloc.
* gcc.dg/torture/pr71816.c: Likewise.
* gcc.dg/tree-ssa/pr78886.c: Likewise.
* gcc.dg/tree-ssa/pr79697.c: Likewise.
* gcc.dg/pr78902.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr78902.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtin-attrs.def
trunk/gcc/builtins.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c
trunk/gcc/testsuite/c-c++-common/asan/pr88619.c
trunk/gcc/testsuite/g++.dg/overload/using2.C
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-5.c
trunk/gcc/testsuite/gcc.dg/nonnull-3.c
trunk/gcc/testsuite/gcc.dg/pr43643.c
trunk/gcc/testsuite/gcc.dg/pr59717.c
trunk/gcc/testsuite/gcc.dg/torture/pr71816.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr78886.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79697.c

[Bug middle-end/90774] avoid doing vector splat arithmetic where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
So this kind of reassociation can only be done with either -fwrapv or unsigned
types.  Due to integer overflow being undefined.

+ is left-to-right associative operator.