[Bug other/90431] support __builtin_cpu_supports() in Linux kernel code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
__builtin_cpu_supports support is in libgcc really.

For x86:
All it is create an access to the variable  __cpu_model.

Which is defined in libgcc/config/i386/cpuinfo.h .

The code to initialize the variable __cpu_model is found in
libgcc/config/i386/cpuinfo.c

So there is nothing special about it really except the ABI is fixed though can
be still extended (the last field is an array of bits).

To add support for the kernel, the kernel needs to implement the same exact ABI
for the variable __cpu_model.  That is it.  Nothing special.
It is up to the Linux kernel to implement that.

PowerPC implements it slightly different and there needs some support added to
the compiler to support it.

What target do you want to use __builtin_cpu_supports inside the kernel for?

[Bug tree-optimization/42970] Missed unused function return value elimination

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Jambor from comment #5)
> I have posted a WIP patch as:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01765.html
> 
> I am in the process of cleaning it up for final submission once stage 1
> opens again.

Stage 1 has opened again.

[Bug c/66970] Add __has_builtin() macro

[egallager at gcc dot gnu.org]

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

--- Comment #14 from Eric Gallager  ---
(In reply to Martin Sebor from comment #13)
> Let me look into this request for GCC 10.

It's GCC 10 now.

[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Sebor from comment #4)
> POSIX says this about bcopy:
> 
>   For maximum portability, it is recommended to replace the function call to
> bcopy() as follows:
> 
>   #define bcopy(b1,b2,len) (memmove((b2), (b1), (len)), (void) 0)
> 
> GCC lowers bcopy calls to memmove (and similarly for other bxxx calls),
> which I think makes it even more important that the non-null attribute be
> applied to their declarations, to detect bugs due to legacy code making the
> assumption that   bcopy et al are null-safe (e.g., on a target where they
> really are).
> 
> $ cat t.c && gcc -O0 -S -Wall -fdump-tree-lower=/dev/stdout t.c
> void f (void *d, const void *s, __SIZE_TYPE__ n)
> {
>   __builtin_bcopy (s, 0, n);
> }
> 
> ;; Function f (f, funcdef_no=0, decl_uid=1908, cgraph_uid=1, symbol_order=0)
> 
> f (void * d, const void * s, long unsigned int n)
> {
>   __builtin_memmove (0B, s, n);
>   return;
> }

ok, be sure to update the comment, then, once you add the attribute

[Bug other/49194] Trivially stupid inlining decisions

[egallager at gcc dot gnu.org]

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

--- Comment #12 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #11)
> Well, I am working on gradual improvements in the inlining decisions,
> but since the PR is not very specific, we never will be perfect :)

So should we leave it open then, or close it?

[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions

[egallager at gcc dot gnu.org]

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

--- Comment #10 from Eric Gallager  ---
(In reply to Arseny Solokha from comment #9)
> Yes, but AFAIK none of the PRs specific to powerpcspe have been closed so
> far. And, personally, I'd like them to stay open for another release cycle
> in the hope Andrew would actually revive the target this year. But it's up
> to gcc maintainers to decide, of course.

OK, leaving this open then...

[Bug middle-end/78917] missing -Wnonnull passing null to a nonnull function

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> Another test case:
> 
> $ cat f.c && gcc -O2 -S -Wall -Wextra f.c
> int f (int i)
> {
>   const char * p = __builtin_strchr (i ? "123" : "456", '2');
>   return __builtin_strlen (p);
> }
> 
> The strlen argument is a phi with a null operand so that should make it easy
> to detect:
> 
>   # prephitmp_11 = PHI <_10(3), 0B(2)>
>   _1 = __builtin_strlen (prephitmp_11);

OK, this second testcase is different enough, so I guess this bug can stay
separate

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com,
   ||pinskia at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #13 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #10)
> On Thu, 25 Jun 2015, P at draigBrady dot com wrote:
> 
> > I'm not understanding completely TBH. Are flexible array members not 
> > special?
> > Should the optimizations be restricted on access through the flexible array,
> > because I presume most/all existing allocation code is not considering this
> > alignment/padding issue. I certainly didn't notice any examples when looking
> > into a workaround which I came up with independently. For my reference there
> > are some notes RE GCC's divergence from C99 re padding and flexi arrays at:
> > https://sites.google.com/site/embeddedmonologue/home/c-programming/data-alig
> 
> That page doesn't exist - I assume you mean: 
> https://sites.google.com/site/embeddedmonologue/home/c-programming/data-
> alignment-structure-padding-and-flexible-array-member
> 
> That page is over ten years out of date - it's quoting the wording in C99 
> as it was before it was corrected by TC2 (published 2004-11-15).  You 
> should look at the post-TC2 wording rather than the old wording with 
> various defects in it.

Could you quote the post-TC2 wording here for us so we don't have to go
looking?

[Bug other/90411] Colored diagnostics can omit characters

[m101010a at gmail dot com]

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

--- Comment #2 from m101010a at gmail dot com ---
When I said to put spaces ELs at the end of lines, I meant the end of logical
lines (e.g. \n), not the end of screen lines.  Sorry for the confusion.

You can't see this issue in gnome-terminal because they special-cased this
behavior as an intentional deviation from xterm.  See
https://gitlab.gnome.org/GNOME/vte/commit/916964e .  If you follow the links
from there you'll get to the grep bug https://savannah.gnu.org/bugs/?36831
which seems to be the justification for that change.  In fact, it looks like
this behavior was taken from grep, since the justification block comment is
almost identical.

[Bug fortran/90430] [9 Regression] internal procedure target rejected in initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-11
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Caused by revision r269980 (pr85537).

[Bug translation/80195] Message build from untranslated string concatenation in fortran/resolve.c:14529

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-11
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  This could be fairly easily detected by an enhancement to the
-Wformat-diag checker I'm working on by checking literal arguments of unquoted
%s directives.  I'm not sure it's a good idea but it might be worth looking
into after I'm done with the first iteration of it.

[Bug target/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Component|translation |target

--- Comment #4 from Martin Sebor  ---
I'm assuming setting Component to translation was a mistake and this is really
a target issue.

[Bug translation/90157] aarch64: unnecessary abbreviation in diagnostic: arg instead of argument

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
My checker found a few of these in an x86_64 build too:

gcc/c-family/c-format.c:394:50: warning: ‘args’ is not a word; use ‘arguments’
instead [-Wformat-diag]
gcc/c-family/c-format.c:5148:11: warning: ‘args’ is not a word; use ‘arguments’
instead [-Wformat-diag]
gcc/builtins.c:10227:56: warning: ‘args’ is not a word; use ‘arguments’ instead
[-Wformat-diag]
gcc/regcprop.c:1246:44: warning: ‘reg’ is not a word; use ‘register’ instead
[-Wformat-diag]
gcc/reg-stack.c:572:36: warning: ‘regs’ is not a word; use ‘registers’ instead
[-Wformat-diag]
gcc/reg-stack.c:612:27: warning: ‘regs’ is not a word; use ‘registers’ instead
[-Wformat-diag]
gcc/reg-stack.c:629:25: warning: ‘regs’ is not a word; use ‘registers’ instead
[-Wformat-diag]
gcc/gcc.c:6141:44: warning: ‘args’ is not a word; use ‘arguments’ instead
[-Wformat-diag]

[Bug c++/90432] New: Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero

[david at doublewise dot net]

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

Bug ID: 90432
   Summary: Internal compiler error with no_unique_address empty
type with constructor call followed by value
initialized to non-zero
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at doublewise dot net
  Target Milestone: ---

The following code causes an internal compiler error:


struct empty {};

struct has_empty {
[[no_unique_address]] empty brace_or_equal_initialized{};
};

struct has_value {
int non_zero = 1;
};


struct pair : has_empty, has_value {};

pair a;
//pair b = pair();





:14:7: internal compiler error: in output_constructor_regular_field, at
varasm.c:5207

   14 | pair a;

  |   ^




See it live: https://godbolt.org/z/tvdsmg


The error occurs if you comment out a and uncomment b, as well.
`brace_or_equal_initialized` can also be initialized by a regular constructor
call, the important part is just that the constructor is explicitly called.

[Bug other/90431] New: support __builtin_cpu_supports() in Linux kernel code

[slandden at gmail dot com]

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

Bug ID: 90431
   Summary: support __builtin_cpu_supports() in Linux kernel code
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slandden at gmail dot com
  Target Milestone: ---

Given that the glibc features is based on AT_HWCAPS which comes from Linux this
should be quite straight forward.

#ifdef __KERNEL__

[Bug fortran/90430] New: [9 Regression] internal procedure target rejected in initialization

[damian at sourceryinstitute dot org]

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

Bug ID: 90430
   Summary: [9 Regression] internal procedure target rejected in
initialization
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

gfortran 9.1.0 gives an error message when compiling the following code, which
I believe is valid and which gfortran 8.3.0 compiles without error:

$cat internal-procedure-target.f90 
  implicit none
  interface
function f() result(i)
  integer i
end function
  end interface
  procedure(f), pointer :: g=>h
contains
  function h() result(j)
integer j
j=1
  end function
end
$gfortran internal-procedure-target.f90 
internal-procedure-target.f90:7:31:

7 |   procedure(f), pointer :: g=>h
  |   1
Error: Internal procedure ‘h’ is invalid in procedure pointer initialization at
(1)
$gfortran --version
GNU Fortran (GCC) 9.1.0

[Bug libstdc++/90239] [C++20] scoped_allocator_adaptor should support nested pair

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 9.2

[Bug libstdc++/90397] Incompatibility with clang-tidy on std::variant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
fixed on trunk and gcc-9-branch

[Bug libstdc++/90397] Incompatibility with clang-tidy on std::variant

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri May 10 22:23:10 2019
New Revision: 271083

URL: https://gcc.gnu.org/viewcvs?rev=271083=gcc=rev
Log:
PR libstdc++/90397 fix std::variant friend declaration

Clang diagnoses insert inconsistent noexcept-specifier on the friend
declaration of __get. Add .

PR libstdc++/90397
* include/std/variant (variant): Add noexcept to friend declaration.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/std/variant

[Bug libstdc++/90239] [C++20] scoped_allocator_adaptor should support nested pair

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Fri May 10 22:23:01 2019
New Revision: 271081

URL: https://gcc.gnu.org/viewcvs?rev=271081=gcc=rev
Log:
PR libstdc++/90239 use uses_allocator_construction_args in 

Backport from mainline
2019-04-25  Jonathan Wakely  

PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Amend P0591R4 status.
* include/std/scoped_allocator [__cplusplus > 201703L]
(scoped_allocator_adaptor::construct): Define in terms of
uses_allocator_construction_args, as per P0591R4.
* testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc: New test.
* testsuite/util/testsuite_allocator.h: Remove name of unused
parameter.
* doc/html/*: Regenerate.

Added:
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/doc/html/manual/status.html
branches/gcc-9-branch/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
branches/gcc-9-branch/libstdc++-v3/include/std/scoped_allocator
branches/gcc-9-branch/libstdc++-v3/testsuite/util/testsuite_allocator.h

[Bug c++/90426] [P0732] Error constructing non-type template parameter from a prvalue

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I think this is invalid.  [temp.arg]p2:
"In a template-argument, an ambiguity between a type-id and an expression is
resolved to a type-id, regardless of the form of the corresponding
template-parameter."

template
struct S { };

struct R { };

void
g (void)
{
  S s; // template argument treated as function type
  S s2;
  S s3; // template argument treated as function type
  S s4;
}

[Bug libstdc++/90388] Disabled hash specialization should not be invocable

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk. The noexcept part might be worth backporting.

[Bug libstdc++/90397] Incompatibility with clang-tidy on std::variant

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri May 10 21:41:19 2019
New Revision: 271079

URL: https://gcc.gnu.org/viewcvs?rev=271079=gcc=rev
Log:
PR libstdc++/90397 fix std::variant friend declarations

Clang diagnoses the inconsistent noexcept-specifier on the friend
declaration of __get. Add it, and also on __get_storage.

PR libstdc++/90397
* include/std/variant (_Variant_storage::_M_storage())
(_Variant_storage::_M_reset()))
(_Variant_storage::_M_storage())): Add noexcept.
(__get_storage): Likewise.
(variant): Add noexcept to friend declarations for __get and
__get_storage.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri May 10 21:41:23 2019
New Revision: 271080

URL: https://gcc.gnu.org/viewcvs?rev=271080=gcc=rev
Log:
PR libstdc++/81266 fix std::thread::native_handle_type test

The test uses remove_pointer because in most cases native_handle_type is
a pointer to the actual type that the C++ class contains. However, for
std::thread, native_handle_type is the same type as the type contained
in std::thread, and so remove_pointer is not needed. On targets where
pthread_t is a pointer type remove_pointer is not a
no-op, instead it transforms pthread_t and causes the test to fail.

The fix is to not apply remove_pointer when testing std::thread.

PR libstdc++/81266
* testsuite/util/thread/all.h: Do not use remove_pointer for
std::thread::native_handle_type.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/util/thread/all.h

[Bug libstdc++/90388] Disabled hash specialization should not be invocable

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri May 10 21:41:16 2019
New Revision: 271078

URL: https://gcc.gnu.org/viewcvs?rev=271078=gcc=rev
Log:
PR libstdc++/90388 fix std::hash> bugs

A disabled specialization should not be callable, so move the function
call operator into a new base class which correctly implements the
disabled hash semantics. For the versioned namespace configuration do
not derive from __poison_hash in the enabled case, as the empty base
class serves no purpose but potentially increases the object size. For
the default configuration that base class must be kept, to preserve
layout.

An enabled specialization should not be unconditionally noexcept,
because the underlying hash object might throw.

PR libstdc++/90388
* include/bits/unique_ptr.h (default_delete, default_delete):
Use _Require for constraints.
(operator>(nullptr_t, const unique_ptr&)): Implement exactly as
per the standard.
(__uniq_ptr_hash): New base class with conditionally-disabled call
operator.
(hash>): Derive from __uniq_ptr_hash.
* testsuite/20_util/default_delete/48631_neg.cc: Adjust dg-error line.
* testsuite/20_util/unique_ptr/hash/90388.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/unique_ptr/hash/90388.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/unique_ptr.h
trunk/libstdc++-v3/testsuite/20_util/default_delete/48631_neg.cc

[Bug c++/90426] [P0732] Error constructing non-type template parameter from a prvalue

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This compiles if I use {} instead of ():

struct gram : unit {};

[Bug rtl-optimization/57193] [7 Regression] suboptimal register allocation for SSE registers

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #20 from Romain Geissler  ---
Hi,

It looks like the GCC 9/10 re-occurence is being tracked in this bug 87716.

Cheers,
Romain

[Bug rtl-optimization/87716] [9/10 Regression] FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #6 from Romain Geissler  ---
Hi,

If this test is failing for quite some time and if the fix seems to be complex
to write, shall this test be marked as xfailing for now ?

Cheers,
Romain

[Bug translation/90152] untranslated strings in print_z_candidate

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
(In reply to Martin Sebor from comment #2)
> Just so I'm clear: what exactly needs to be enclosed in _(...) in
> print_z_candidate?

The code:
print_z_candidate (loc, "candidate:", candidates);

should be:
print_z_candidate (loc, N_("candidate:"), candidates);

The code:
ACONCAT ((msgstr, " ", NULL)))

should be:
ACONCAT ((_(msgstr), " ", NULL)));

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
I'm replacing all the tree codes with %qs and get_tree_code_name (TREE_CODE
(expr)), like so:

@@ -3072,13 +3073,15 @@ verify_types_in_gimple_reference (tree expr, bool
requir
e_lvalue)
size))
{
  error ("mode size of non-integral result does not "
-"match field size of BIT_FIELD_REF");
+"match field size of %qs",
+get_tree_code_name (TREE_CODE (expr)));
  return true;
}
  if (INTEGRAL_TYPE_P (TREE_TYPE (op))
  && !type_has_mode_precision_p (TREE_TYPE (op)))
{
- error ("BIT_FIELD_REF of non-mode-precision operand");
+ error ("%qs of non-mode-precision operand",
+get_tree_code_name (TREE_CODE (expr)));
  return true;
}
  if (!AGGREGATE_TYPE_P (TREE_TYPE (op))

[Bug translation/90152] untranslated strings in print_z_candidate

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-10
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I see the missing N_().  Let me handle it as part of the bigger quoting patch.

Just so I'm clear: what exactly needs to be enclosed in _(...) in
print_z_candidate?

[Bug translation/90157] aarch64: unnecessary abbreviation in diagnostic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-10
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The following is the correct spelling (in the same file):

 case AARCH64_PARSE_MISSING_ARG:
   error ("missing argument to % pragma
or"
  " attribute");

My checker diagnoses this so I'll fix it as part of the patch before I commit
it.

[Bug c++/90353] No warning on unused exception parameter with -Wall -Wextra

[david.bolvansky at gmail dot com]

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

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #3 from Dávid Bolvanský  ---
Clang has switch -Wunused-exception-parameter so maybe GCC should support it
too.

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Fri May 10 20:14:22 2019
New Revision: 271076

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

PR fortran/61968
* interface.c (compare_actual_formal): Do not create a vtab if
the actual argument is assumed type.

2019-05-10  Thomas Koenig  

PR fortran/61968
* gfortran.dg/assumed_type_10.f90: New test case.
* gfortran.dg/assumed_type_11.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_type_10.f90
trunk/gcc/testsuite/gfortran.dg/assumed_type_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug other/87695] Arduino: ICE with avr and LTO

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sandreas at satx dot rr.com

--- Comment #11 from Andrew Pinski  ---
*** Bug 90429 has been marked as a duplicate of this bug. ***

[Bug lto/90429] lto-wrapper.exe: fatal error: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc returned 1 exit status

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 87695.

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

[Bug lto/90429] New: lto-wrapper.exe: fatal error: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc returned 1 exit status

[sandreas at satx dot rr.com]

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

Bug ID: 90429
   Summary: lto-wrapper.exe: fatal error: C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__
mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc returned
1 exit status
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandreas at satx dot rr.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I installed version 1.8.9 (Windows Store 1.8.21.0)

Without making any changes to my Marlin configuration (it compiled cleanly
earlier today) I did a compile.

I received this error:

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper.exe: fatal error: C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc
returned 1 exit status

compilation terminated.

c:/program
files/windowsapps/arduinollc.arduinoide_1.8.21.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe:
error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

exit status 1
Error compiling for board Arduino/Genuino Mega or Mega 2560.

[Bug c++/90428] New: -Wredundant-move could warn for more cases

[redi at gcc dot gnu.org]

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

Bug ID: 90428
   Summary: -Wredundant-move could warn for more cases
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

G++ gives no warnings for this:

#include 

struct T { };

T f(const T& t)
{
  return std::move(t);
}

T g()
{
  return std::move(f());
}

The std::move in f does nothing, because the argument is const (and T does not
have a T(const T&&) constructor, so the conversion to an rvalue is useless).

The std::move in g also does nothing, because the argument is already an rvalue
(this might actually be a candidate for -Wpessimizing-move instead, since it
prevents elision).

[Bug target/90419] RISCV --with-multilib-list support is somewhat incomplete

[wilson at gcc dot gnu.org]

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

--- Comment #4 from Jim Wilson  ---
GCC worked out of the box before we started upstreaming the toolchain.  And it
will work out of the box again when we are done with the upstreaming.  But
meanwhile, we are still in the middle of upstreaming and some things only work
if you have the right collection of patches or the right collection of source
trees.  If I change the FSF gcc tree to try to fix this, then I break the
github riscv/riscv-gnu-toolchain tree, which is using the same gcc sources, and
has working multilib support.  I don't want to have to maintain two different
gcc source trees, so I'm leaving the FSF gcc broken temporarily because I don't
want to break the riscv/riscv-gnu-toolchain tree.  This problem will go away
when glibc is finished upstreaming.  This is a problem I keep raising inside
SiFive and the RISC-V Foundation because a number of things are blocked on this
glibc upstreaming problem.  It isn't clear when it will get fixed though.  I
might have to volunteer to do it myself at some point, but I'm still hoping
someone else does it.

[Bug middle-end/89845] Consider improving division and modulo by constant if highpart multiply is cheap

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||drepper at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I admit I haven't done any measurements yet, but just at eyeballing the
generated code with both trunk gcc and clang say on -O2 -mtune=generic
with their
https://raw.githubusercontent.com/lemire/fastmod/master/include/fastmod.h
doesn't seem that compelling; the fastmod code is pretty much in all cases
larger (part of it is that we aren't good at optimizing that __uint128_t or
__int128_t arithmetics in there just to highpart 64x64 multiplication and
nothing else, plus all these fastmod sequences have the large and more costly
movabsqs compared to what we emit currently.

For the int128_t arithmetics, perhaps it would help let tree-ssa-math-opts.c
pattern recognize MULT_HIGHPART_EXPR code (or do that in match.pd) even in
non-vectorized code if can_mult_highpart_p returns 1.

#include "fastmod.h"

uint32_t ud3 (uint32_t x) { return fastmod::fastdiv<3> (x); }
uint32_t ud3_ (uint32_t x) { return x / 3; }
uint32_t um3 (uint32_t x) { return fastmod::fastmod<3> (x); }
uint32_t um3_ (uint32_t x) { return x % 3; }
int32_t sd3 (int32_t x) { return fastmod::fastdiv<3> (x); }
int32_t sd3_ (int32_t x) { return x / 3; }
int32_t sm3 (int32_t x) { return fastmod::fastmod<3> (x); }
int32_t sm3_ (int32_t x) { return x % 3; }
uint32_t ud61 (uint32_t x) { return fastmod::fastdiv<61> (x); }
uint32_t ud61_ (uint32_t x) { return x / 61; }
uint32_t um61 (uint32_t x) { return fastmod::fastmod<61> (x); }
uint32_t um61_ (uint32_t x) { return x % 61; }
int32_t sd61 (int32_t x) { return fastmod::fastdiv<61> (x); }
int32_t sd61_ (int32_t x) { return x / 61; }
int32_t sm61 (int32_t x) { return fastmod::fastmod<61> (x); }
int32_t sm61_ (int32_t x) { return x % 61; }
uint32_t ud279 (uint32_t x) { return fastmod::fastdiv<279> (x); }
uint32_t ud279_ (uint32_t x) { return x / 279; }
uint32_t um279 (uint32_t x) { return fastmod::fastmod<279> (x); }
uint32_t um279_ (uint32_t x) { return x % 279; }
int32_t sd279 (int32_t x) { return fastmod::fastdiv<279> (x); }
int32_t sd279_ (int32_t x) { return x / 279; }
int32_t sm279 (int32_t x) { return fastmod::fastmod<279> (x); }
int32_t sm279_ (int32_t x) { return x % 279; }

E.g. in ud3 there is
movl%edi, %eax
movabsq $6148914691236517206, %rdi
mulq%rdi
movq%rdx, %rax
and in ud3_
movl%edi, %eax
movl$2863311531, %edi
imulq   %rdi, %rax
shrq$33, %rax
In um3 there is:
movabsq $6148914691236517206, %rcx
movl%edi, %edi
xorl%edx, %edx
imulq   %rcx, %rdi
movq%rdi, %rax
movq%rdi, %rsi
movq%rdx, %rdi
addq%rax, %rsi
shldq   $1, %rax, %rdi
addq%rsi, %rax
adcq%rdi, %rdx
movq%rdx, %rax
which is terrible, in um3_
movl%edi, %eax
movl$2863311531, %edx
imulq   %rdx, %rax
shrq$33, %rax
leal(%rax,%rax,2), %eax
subl%eax, %edi
movl%edi, %eax
In *.optimized um3 is:
  _3 = (long unsigned int) x_2(D);
  lowbits_4 = _3 * 6148914691236517206;
  _6 = lowbits_4 w* 3;
  _7 = _6 >> 64;
  _8 = (unsigned int) _7;
where _4 is 64-bit and _6, _7 is 128-bit.  This is another case where just
using
  _3 = (long unsigned int) x_2(D);
  lowbits_4 = _3 * 6148914691236517206;
  _9 = lowbits_4 h* 3;
  _8 = (unsigned int) _9;
might result in better code, though not sure if we have a good expander for
highpart multiply by constant.

[Bug tree-optimization/56457] Bogus warning: loop-invariant.c:786:20: error: unused variable ‘regno’ when building vax-*-*

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
defs = DF_REF_CHAIN (use);  
if (!defs)  
{   
unsigned int regno = DF_REF_REGNO (use);

/* If this is the use of an uninitialized argument register that is 
likely to be spilled, do not move it lest this might extend its 
lifetime and cause reload to die.  This can occur for a call to 
a function taking complex number arguments and moving the insns 
preparing the arguments without moving the call itself wouldn't 
gain much in practice.  */  
if ((DF_REF_FLAGS (use) & DF_HARD_REG_LIVE) 
&& FUNCTION_ARG_REGNO_P (regno) 
&& targetm.class_likely_spilled_p (REGNO_REG_CLASS (regno)))
return false;   

return true;
}

This is the actual code and it seems to be used not in the if block below it
Eric. I haven't run a build for it on the current gcc sources but it seems to
be used currently. As for memory I don't recall it happening during my latest
gcc builds on the upstream sources.

[Bug c/71924] missing -Wreturn-local-addr returning alloca result

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I'm testing a patch.

[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
Created attachment 46341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46341=edit
updated patch

I'm testing this - the posted one didn't build on Darwin.

[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #3 from Alexandre Oliva  ---
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00493.html has a patch

[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method

[barry.revzin at gmail dot com]

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

--- Comment #13 from Barry Revzin  ---
Thanks Marek!

[Bug tree-optimization/90427] missing "sign flipping" optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Most likely, but that would be -frounding-math only, no?
That said, at the GIMPLE level we really don't know if the target will have
immediate - register or register - immediate or both instructions etc., so
maybe it might be better to do it on RTL.  Although, after RTL expansion, we
usually have constants in memory (constant pool) rather than in registers, so
the optimization would need to also do some analysis on what kind of constants
the function uses and if the sign flipping wouldn't increase number of those
constants (it can of course also decrease that).

[Bug tree-optimization/90427] missing "sign flipping" optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I would suspect there are rounding mode issues with it.

[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros

[remi at machet dot us]

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

--- Comment #2 from Remi  ---
I found 69543 which looks similar but is different (and fixed): the cause of
the bug is different and it applies to the first level of a macro, while this
bug requires 2 levels of macro to show up.

[Bug tree-optimization/90427] New: missing "sign flipping" optimization

[tromey at gcc dot gnu.org]

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

Bug ID: 90427
   Summary: missing "sign flipping" optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

This test case comes from this blog post:
https://nfrechette.github.io/2019/05/08/sign_flip_optimization/
(which also says that clang 8 performs this optimization).

Consider

float foo_ref(float value) {
  value = value * 0.5f;   // mulss value, 0.5f
  // movss tmp, 1.0f
  return 1.0f - value;// subss tmp, value
}

float foo_ref2(float value) {
  value = value * -0.5f;  // mulss value, -0.5f
  return value + 1.0f; // addss value, 1.0f
}


According to the post, these are equivalent.  However, gcc
generates different code for them, with the latter being better.

The comments for the first function seem to omit an
instruction that gcc emits, making that version even worse:

movss   .LC0(%rip), %xmm1
mulss   %xmm0, %xmm1
movss   .LC1(%rip), %xmm0
subss   %xmm1, %xmm0

However the comments in the second one are correct:

mulss   .LC2(%rip), %xmm0
addss   .LC1(%rip), %xmm0


Tested with git master from today, using gcc -O2, on x86-64 Fedora 29.

I just made a guess at which component to use.

[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Fixed for 9.2 and 10.

[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 10 14:57:22 2019
New Revision: 271066

URL: https://gcc.gnu.org/viewcvs?rev=271066=gcc=rev
Log:
PR c++/78010 - bogus -Wsuggest-override warning on final function.
* class.c (check_for_override): Don't warn for final functions.

* g++.dg/warn/Wsuggest-override-2.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/warn/Wsuggest-override-2.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/class.c

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

--- Comment #29 from Than McIntosh  ---

Tested patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=46337 and that
brings compile time now down to about 700 seconds. -ftime-report shows that
tree-PRE is still the major culprit.

Also tested second patch at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=46339 and that looks even
better, reduces compile time to 137 seconds, which is well under the timeout
enforced by our build system.

Thanks--

[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 10 14:53:30 2019
New Revision: 271065

URL: https://gcc.gnu.org/viewcvs?rev=271065=gcc=rev
Log:
PR c++/78010 - bogus -Wsuggest-override warning on final function.
* class.c (check_for_override): Don't warn for final functions.

* g++.dg/warn/Wsuggest-override-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wsuggest-override-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/90426] New: [P0732] Error constructing non-type template parameter from a prvalue

[mateusz.pusz at gmail dot com]

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

Bug ID: 90426
   Summary: [P0732] Error constructing non-type template parameter
from a prvalue
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mateusz.pusz at gmail dot com
  Target Milestone: ---

Hi,

Compiling the code provided below with the following options produces an error:
"-std=c++2a -Wall -Wextra"

```
#include 

struct ratio {
std::intmax_t num;
std::intmax_t den;

template
constexpr ratio(std::ratio): num(Num), den(Den) {}
};

template
struct unit {};
struct gram : unit {};
```

Error:
:13:39: error: type/value mismatch at argument 1 in template parameter
list for 'template struct unit'

   13 | struct gram : unit {};

  |   ^

:13:39: note:   expected a constant of type 'auto', got
'ratio(std::milli (*)())' {aka 'ratio(std::ratio<1, 1000> (*)())'}

Compiler returned: 1

See also here: https://godbolt.org/z/PHD8Ly

Best

Mat

[Bug middle-end/89765] [9/10 Regression] Multiple problems with vec-insert implementation on PowerPC

[kelvin at gcc dot gnu.org]

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

--- Comment #13 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri May 10 14:00:17 2019
New Revision: 271064

URL: https://gcc.gnu.org/viewcvs?rev=271064=gcc=rev
Log:
gcc/ChangeLog:

2019-05-10  Kelvin Nilsen  

Backport from mainline.
2019-05-07  Kelvin Nilsen  

PR target/89765
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic
to compute vector element selector for both constant and variable
operands.

gcc/testsuite/ChangeLog:

2019-05-10  Kelvin Nilsen  

Backport from mainline.
2019-05-07  Kelvin Nilsen  

PR target/89765
* gcc.target/powerpc/pr89765-mc.c: New test.
* gcc.target/powerpc/vsx-builtin-10c.c: New test.
* gcc.target/powerpc/vsx-builtin-10d.c: New test.
* gcc.target/powerpc/vsx-builtin-11c.c: New test.
* gcc.target/powerpc/vsx-builtin-11d.c: New test.
* gcc.target/powerpc/vsx-builtin-12c.c: New test.
* gcc.target/powerpc/vsx-builtin-12d.c: New test.
* gcc.target/powerpc/vsx-builtin-13c.c: New test.
* gcc.target/powerpc/vsx-builtin-13d.c: New test.
* gcc.target/powerpc/vsx-builtin-14c.c: New test.
* gcc.target/powerpc/vsx-builtin-14d.c: New test.
* gcc.target/powerpc/vsx-builtin-15c.c: New test.
* gcc.target/powerpc/vsx-builtin-15d.c: New test.
* gcc.target/powerpc/vsx-builtin-16c.c: New test.
* gcc.target/powerpc/vsx-builtin-16d.c: New test.
* gcc.target/powerpc/vsx-builtin-17c.c: New test.
* gcc.target/powerpc/vsx-builtin-17d.c: New test.
* gcc.target/powerpc/vsx-builtin-18c.c: New test.
* gcc.target/powerpc/vsx-builtin-18d.c: New test.
* gcc.target/powerpc/vsx-builtin-19c.c: New test.
* gcc.target/powerpc/vsx-builtin-19d.c: New test.
* gcc.target/powerpc/vsx-builtin-20c.c: New test.
* gcc.target/powerpc/vsx-builtin-20d.c: New test.
* gcc.target/powerpc/vsx-builtin-9c.c: New test.
* gcc.target/powerpc/vsx-builtin-9d.c: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/pr89765-mc.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20d.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9c.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9d.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug other/90411] Colored diagnostics can omit characters

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
gcc doesn't use ncurses or similar toolkits so it doesn't really know what is
and what isn't actually an end of line.
I can't reproduce the problem you're talking about in gnome-terminal.

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
Created attachment 46340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46340=edit
Patch under test

This is a combination of Jakub's patch
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html

+ a fragment to note that WORLD_SAVE_P is set in -mdebug=stack

+ change to rs6000_function_ok_for_sibcall to return false for eh_return cases.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Biener  ---
Created attachment 46339
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46339=edit
untested patch

This is another patch.  It changes the iteration scheme to RPO order instead of
DOM order to not require iteration unless AVAIL_OUT changes on a backedge
(which usually should not happen for regular PRE insertions...).

Your reduced testcases were all acyclic so this should fix the slowness there.

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Putting an exit into a module_mp_wsm5.F90 shows that the function is really
executed:

diff --git a/benchspec/CPU/521.wrf_r/src/module_mp_wsm5.F90
b/benchspec/CPU/521.wrf_r/src/module_mp_wsm5.F90
index 4d5487a7..acb4f890 100644
--- a/benchspec/CPU/521.wrf_r/src/module_mp_wsm5.F90
+++ b/benchspec/CPU/521.wrf_r/src/module_mp_wsm5.F90
@@ -1403,6 +1403,7 @@ CONTAINS
   real  qn(km), qr(km),tmp(km),tmp1(km),tmp2(km),tmp3(km)
   real  dza(km+1), qa(km+1), qmi(km+1), qpi(km+1)
 !
+  CALL EXIT(100)
   precip(:) = 0.0
 !
   i_loop : do i=1,im

$ ...
  Error (RE) with training run!

So it's definitely a profile manipulation issue..

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|powerpc-apple-darwin9   |powerpc-apple-darwin9
   ||powerpc-ibm-aix*
 CC||dje at gcc dot gnu.org
   Host|powerpc-apple-darwin9   |
  Build|powerpc-apple-darwin9   |

--- Comment #6 from David Edelsohn  ---
The patch also introduced a large number of EH testsuite failures for AIX.

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

[rguenther at suse dot de]

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

--- Comment #39 from rguenther at suse dot de  ---
On Fri, 10 May 2019, ian at airs dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
> 
> --- Comment #38 from Ian Lance Taylor  ---
> Ah, sorry, misunderstood.
> 
> Yes, that work was all for the goal of implementing -Wjump-misses-init, which
> is a small aspect of -Wc++-compat.  That was part of the work of getting GCC 
> to
> use the common subset of C and C++ before we switched to C++.
> 
> (It's also used for the error of jumping into the scope of a variably modified
> type.)

Yes, and it looks like this code is somehow quadratic (or worse) in the
number of jumps/locals.

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

[ian at airs dot com]

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

--- Comment #38 from Ian Lance Taylor  ---
Ah, sorry, misunderstood.

Yes, that work was all for the goal of implementing -Wjump-misses-init, which
is a small aspect of -Wc++-compat.  That was part of the work of getting GCC to
use the common subset of C and C++ before we switched to C++.

(It's also used for the error of jumping into the scope of a variably modified
type.)

[Bug gcov-profile/90425] [GCOV] wrong coverage for complicated function call in if expression when the abort() statement is in the body of if statement

[yangyibiao at nju dot edu.cn]

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

--- Comment #2 from Yibiao Yang  ---
(In reply to Martin Liška from comment #1)
> Confirmed, we already have a duplicate for it. It's about trailing '||'
> operator.
> Following is fine:
> 
> -:4:int
> 1:5:main ()
> -:6:{
> 1:7:  long a = 0x89ABCDEF;
> -:8:
> 1:9:  if (f1(a)!=0x8900L
> 1:   10:  || f6(a)!=0x89ABL)
> #:   11:__builtin_abort();
> 1:   12:  __builtin_exit(0);
> -:   13:}

Got it. Thanks a lot.

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > (In reply to Iain Sandoe from comment #2)
> > > (In reply to Jakub Jelinek from comment #1)
> 
> > Though, I don't understand why that
> > if (DEFAULT_ABI == ABI_DARWIN && crtl->calls_eh_return) return false;
> > wouldn't work in rs6000_function_ok_for_sibcall, because that conditional
> > should make sure we don't have any tail calls in such functions and thus the
> > above shouldn't trigger.
> 
> Agreed, and that's exactly the code I have present, and I just did a clean
> build.  However, as you suspect the sibcall is still present. Perhaps
> crtl->calls_eh_return is not somehow set or somehow a sib call is generated
> without checking it's OK.  Will look more later.

Hm. So it seems that the problem is in expand - the call to
rs6000_function_ok_for_sibcall() occurs when the tail call is encountered, but
that is before the call to expand_eh_return() - which sets
crtl->calls_eh_return.

If I jam sibcalls off completely, of course, it works.

Trying the posted patch for gcc/tree-tailcall.c

[Bug gcov-profile/90425] [GCOV] wrong coverage for complicated function call in if expression when the abort() statement is in the body of if statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-10
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, we already have a duplicate for it. It's about trailing '||'
operator.
Following is fine:

-:4:int
1:5:main ()
-:6:{
1:7:  long a = 0x89ABCDEF;
-:8:
1:9:  if (f1(a)!=0x8900L
1:   10:  || f6(a)!=0x89ABL)
#:   11:__builtin_abort();
1:   12:  __builtin_exit(0);
-:   13:}

[Bug tree-optimization/90416] [10 Regression] ICE in dump_generic_node at tree-pretty-print.c:1383 since r271006

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 46338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46338=edit
Debugging patch

So the issue started before the revision, output of the debugging patch is
following:

$ ./xgcc -B. /tmp/ice.f90 -c -O3 -ffast-math -fdump-tree-vect-details
-march=haswell
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77ac8b28 precision:32 min  max
>
V8SI
size  constant 256>
unit-size  constant 32>
align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77ac8bd0 nunits:8>
calling dump_printf_loc with mask_vectype=0x77ac8bd0,
vectype=0x7796ae70
case T=0x22d0090
during GIMPLE pass: vect
dump file: ice.f90.158t.vect
dump_generic_node node=0x77ac1150
/tmp/ice.f90:9:0:

9 | subroutine refl10cm_hm (dBZ , kte)
  | 
internal compiler error: in decode_format, at dumpfile.c:976
0xbc6618 dump_pretty_printer::decode_format(text_info*, char const*, char
const**)
../../gcc/dumpfile.c:976
0xbc63fc dump_pretty_printer::format_decoder_cb(pretty_printer*, text_info*,
char const*, int, bool, bool, bool, bool*, char const**)
../../gcc/dumpfile.c:906
0x20d387a pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1390
0xbc66e0 dump_context::dump_printf_va(dump_metadata_t const&, char const*,
__va_list_tag (*) [1])
../../gcc/dumpfile.c:1003
0xbc6790 dump_context::dump_printf_loc_va(dump_metadata_t const&,
dump_user_location_t const&, char const*, __va_list_tag (*) [1])
../../gcc/dumpfile.c:1024
0xbc7248 dump_printf_loc(dump_metadata_t const&, dump_user_location_t const&,
char const*, ...)
../../gcc/dumpfile.c:1350
0x1541755 vect_check_load_store_mask
../../gcc/tree-vect-stmts.c:2575
0x155446b vectorizable_load
../../gcc/tree-vect-stmts.c:7620
0x155b46d vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*, _slp_instance*,
vec*)
../../gcc/tree-vect-stmts.c:9695
0x156b927 vect_analyze_loop_operations
../../gcc/tree-vect-loop.c:1575
0x156cd0e vect_analyze_loop_2
../../gcc/tree-vect-loop.c:1969
0x156e1ac vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
../../gcc/tree-vect-loop.c:2268
0x15aad71 try_vectorize_loop_1
../../gcc/tree-vectorizer.c:883
0x15ab506 try_vectorize_loop
../../gcc/tree-vectorizer.c:1029
0x15ab6d6 vectorize_loops()
../../gcc/tree-vectorizer.c:
0x141b9cd execute
../../gcc/tree-ssa-loop.c:414

So as seen, we call dump_printf_loc with 2 arguments, but the var_arg arguments
are smashed somehow.

I'm going to bisect that now.

[Bug tree-optimization/90416] [10 Regression] ICE in dump_generic_node at tree-pretty-print.c:1383

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Assignee|marxin at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|10.0|9.2
Summary|[10 Regression] ICE in  |[10 Regression] ICE in
   |dump_generic_node at|dump_generic_node at
   |tree-pretty-print.c:1383|tree-pretty-print.c:1383
   |since r271006   |
  Known to fail||10.0, 9.1.0

--- Comment #4 from Martin Liška  ---
Started with David's r264424 with the debugging patch.

[Bug gcov-profile/90425] New: [GCOV] wrong coverage for complicated function call in if expression when the abort() statement is in the body of if statement

[yangyibiao at nju dot edu.cn]

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

Bug ID: 90425
   Summary: [GCOV] wrong coverage for complicated function call in
if expression when the abort() statement is in the
body of if statement
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --enable-languages=c,c++
--disable-multilib --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 9.0.1 20190414 (experimental) (GCC)

$ cat small.c
long f1(long a){return a&0xff00L;}
long f6(long a){return a&~0xL;}

main ()
{
  long a = 0x89ABCDEF;

  if (f1(a)!=0x8900L||
  f6(a)!=0x89ABL)
; // abort();
  exit(0);
}

$ gcc -w -O0 -g --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:87.50% of 8
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:long f1(long a){return a&0xff00L;}
1:2:long f6(long a){return a&~0xL;}
-:3:
1:4:main ()
-:5:{
1:6:  long a = 0x89ABCDEF;
-:7:
2:8:  if (f1(a)!=0x8900L||
1:9:  f6(a)!=0x89ABL)
#:   10:abort();
1:   11:  exit(0);
-:   12:}

It seems that line #8 might be "wrongly" marked as executed twice. 

When Line #10 is removed, the coverage of line #8 seems to be correct as
follows:

$ gcc -w -O0 -g --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:long f1(long a){return a&0xff00L;}
1:2:long f6(long a){return a&~0xL;}
-:3:
1:4:main ()
-:5:{
1:6:  long a = 0x89ABCDEF;
-:7:
1:8:  if (f1(a)!=0x8900L||
1:9:  f6(a)!=0x89ABL)
-:   10:; // abort();
1:   11:  exit(0);
-:   12:}

[Bug target/90424] New: memcpy into vector builtin not optimized

[kretz at kde dot org]

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

Bug ID: 90424
   Summary: memcpy into vector builtin not optimized
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Testcase (cf. https://godbolt.org/z/LsKcii):

template 
using V [[gnu::vector_size(16)]] = T;

template )>
V load(const void *p) {
  using W = V;
  W r;
  __builtin_memcpy(, p, M);
  return r;
}

// movq or movsd
template V load(const void *); // bad
template V load(const void *);   // bad
template V load(const void *);   // bad
template V load(const void *); // good
template V load(const void *);   // bad
template V load(const void *); // good (movsd?)

// movd or movss
template V load(const void *);   // bad
template V load(const void *); // bad
template V load(const void *); // good
template V load(const void *); // good

All of these partial loads should be translated to a single mov[qd] or movs[sd]
instruction. But most of them are not.

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Richard Biener from comment #6)
>   6.22%  80774   wrf_r_peak.pgo  
> __module_mp_wsm5_MOD_nislfv_rain_plm
>   5.50%  71494   wrf_r_peak.pgo   __module_mp_wsm5_MOD_wsm52d
> 
> vs.
> 
>   4.04%  49253   wrf_r_peak.std__module_mp_wsm5_MOD_wsm52d
>   3.93%  47888   wrf_r_peak.std   
> __module_mp_wsm5_MOD_nislfv_rain_plm
> 

So it's quite clear what's happening, the profile is empty with:
PASS1_OPTIMIZE= -fprofile-generate
PASS2_OPTIMIZE= -fprofile-use

$ gcov-dump -l module_mp_wsm5.fppized.gcda
module_mp_wsm5.fppized.gcda:data:magic `gcda':version `B00e'
module_mp_wsm5.fppized.gcda:stamp 2705505138
module_mp_wsm5.fppized.gcda:  a100:   2:OBJECT_SUMMARY runs=1,
sum_max=4450478
module_mp_wsm5.fppized.gcda:  0100:   3:FUNCTION ident=1833382280,
lineno_checksum=0xc50142f7, cfg_checksum=0xa4c61a93
module_mp_wsm5.fppized.gcda:01a1:  28:COUNTERS arcs 14 counts
module_mp_wsm5.fppized.gcda:   0: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:   8: 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:01af:   2:COUNTERS time_profiler 1 counts
module_mp_wsm5.fppized.gcda:   0: 0 
module_mp_wsm5.fppized.gcda:  0100:   3:FUNCTION ident=1714856802,
lineno_checksum=0x2828ada2, cfg_checksum=0xdf8e1de8
module_mp_wsm5.fppized.gcda:01a1: 244:COUNTERS arcs 122 counts
module_mp_wsm5.fppized.gcda:   0: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:   8: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  16: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  24: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  32: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  40: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  48: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  56: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  64: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  72: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  80: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  88: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  96: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  104: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  112: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  120: 0 0 
module_mp_wsm5.fppized.gcda:01af:   2:COUNTERS time_profiler 1 counts
module_mp_wsm5.fppized.gcda:   0: 0 
module_mp_wsm5.fppized.gcda:  0100:   3:FUNCTION ident=1918459980,
lineno_checksum=0xbfa13ab3, cfg_checksum=0xc8579be8
module_mp_wsm5.fppized.gcda:01a1:   6:COUNTERS arcs 3 counts
module_mp_wsm5.fppized.gcda:   0: 0 0 0 
module_mp_wsm5.fppized.gcda:01af:   2:COUNTERS time_profiler 1 counts
module_mp_wsm5.fppized.gcda:   0: 0 
module_mp_wsm5.fppized.gcda:  0100:   3:FUNCTION ident=496119459,
lineno_checksum=0x6ee163ab, cfg_checksum=0xa35960e7
module_mp_wsm5.fppized.gcda:01a1:  14:COUNTERS arcs 7 counts
module_mp_wsm5.fppized.gcda:   0: 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:01af:   2:COUNTERS time_profiler 1 counts
module_mp_wsm5.fppized.gcda:   0: 0 
module_mp_wsm5.fppized.gcda:  0100:   3:FUNCTION ident=296982037,
lineno_checksum=0x6d77a6f1, cfg_checksum=0x136773da
module_mp_wsm5.fppized.gcda:01a1:  10:COUNTERS arcs 5 counts
module_mp_wsm5.fppized.gcda:   0: 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:01af:   2:COUNTERS time_profiler 1 counts
module_mp_wsm5.fppized.gcda:   0: 0 
module_mp_wsm5.fppized.gcda:  0100:   3:FUNCTION ident=1896179062,
lineno_checksum=0x7ca7aef8, cfg_checksum=0xb913c38e
module_mp_wsm5.fppized.gcda:01a1:  10:COUNTERS arcs 5 counts
module_mp_wsm5.fppized.gcda:   0: 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:01af:   2:COUNTERS time_profiler 1 counts
module_mp_wsm5.fppized.gcda:   0: 0 
module_mp_wsm5.fppized.gcda:  0100:   3:FUNCTION ident=882722517,
lineno_checksum=0x36b2a0c5, cfg_checksum=0xfd6c3dcf
module_mp_wsm5.fppized.gcda:01a1: 102:COUNTERS arcs 51 counts
module_mp_wsm5.fppized.gcda:   0: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:   8: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  16: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  24: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  32: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  40: 0 0 0 0 0 0 0 0 
module_mp_wsm5.fppized.gcda:  48: 0 0 0 
module_mp_wsm5.fppized.gcda:01af:   2:COUNTERS time_profiler 1 counts
module_mp_wsm5.fppized.gcda:   0: 0 

[Bug tree-optimization/90416] [10 Regression] ICE in dump_generic_node at tree-pretty-print.c:1383 since r271006

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
I'm going to investigate that, it's quite strange issue..

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener  ---
Created attachment 46337
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46337=edit
untested patch

So this is another patch adjusting PRE insertion to only iterate when necessary
(well, I think it should be never necessary to iterate...).  That said, it
strips iteration down to a minimum (still supporting the notion that iteration
is necessary at all).  I wonder if iteration in the end is really only
because of the sorting order issue, thus if the patch doesn't help, can you
try changing the hunk

@@ -3326,6 +3331,10 @@ do_pre_regular_insertion (basic_block bl
}
}
 }
+  /* ???  Imperfect sorting of expressions means we have to iterate here.
+ For example gcc.dg/tree-ssa/pr23455.c shows a dependent memory
+ load cannot be inserted as part of a computation.  */
+  } while (old_trans_fails != trans_fails);

   exprs.release ();
   return new_stuff;

to never loop and try again?  (this particular looping is a hack
implementation-wise and probably can be improved or even avoided)

[Bug c++/90423] Breakage with C++ and "-mlong-double-128"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
-mlong-double-128 changes the ABI of long double.  You need to compile all
libraries wit it too including glibc.

[Bug libstdc++/90370] Does 0 correspond to a POSIX errno value for std::system_category?

[fw at gcc dot gnu.org]

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

--- Comment #5 from Florian Weimer  ---
(In reply to Florian Weimer from comment #4)
> (In reply to Jonathan Wakely from comment #3)
> > The issue is basically that the C++ Standard Library defines two categories
> > for error numbers known to the implementation: "generic" and "system", where
> > the former is for the POSIX errno values, and the latter is for other error
> > numbers used by the OS for other kinds of errors that aren't covered by a
> > POSIX errno macro (which might be other non-standard EBLAH macros that the
> > OS adds to the POSIX ones, or some totally different error numbers used by
> > the OS, e.g. Windows has its own error numbers unrelated to errno). The
> > question is which category zero belongs to.
> 
> This is really confusing for native POSIX systems because the generic/system
> terminology appears to be swapped for them.  This is also reflected in the
> standard:
> 
> 
> 
> And in the documentation:
> 
> 
> 
> With this observation in mind, I reach this conclusion:
> 
> For a native POSIX system, no translation of errno values is needed.  That
> suggests to me that all int values (the ev argument) correspond to a POSIX
> errno value, and therefore all error conditions crated by
> default_­error_­condition should be of the system_category category.

Sorry, I meant  generic_category on the last line (which really should be
called posix_category or perhaps errno_category, based on the required behavior
of default_error_condition).

Why do I consider generic/system terminology swapped?  A system error for
GNU/Linux is a POSIX error because the that's the kind of error numbers the
operating system uses.  If the application uses non-POSIX errors that are
unlikely (or impossible, in the case of Linux on most architectures) to occur
as operating system errors for different error conditions, I would call that a
“generic error” as in “not a system error”.

However, I do not think that there is an debate that an ERANGE error needs to
be of generic_category according to the specification, even though it is
clearly a system error from the GNU/Linux point of view.

If we say that all int error values are of generic_category, without further
translation, I think this mostly resolves this confusion.

[Bug c++/90423] New: Breakage with C++ and "-mlong-double-128"

[mar...@mpa-garching.mpg.de]

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

Bug ID: 90423
   Summary: Breakage with C++  and "-mlong-double-128"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Compiling the code snippet below with "g++ -mlong-double-128" and running the
executable prints "2" to the console on my machine, which is obviously wrong.
Without the "-mlong-double-128" flag the output is correct.

#include 
#include 

using namespace std;

int main()
  {
  long double v=2.;
  cout << double(sqrt(v)) << endl;
  }

I understand that C++ support for this kind of long doubles may not be
complete, but would it be possible to fail in a more obvious manner?

Reproduced with g++ 8 and trunk on x86_64-pc-linux-gnu.

[Bug libstdc++/90370] Does 0 correspond to a POSIX errno value for std::system_category?

[fw at gcc dot gnu.org]

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

--- Comment #4 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #3)
> The issue is basically that the C++ Standard Library defines two categories
> for error numbers known to the implementation: "generic" and "system", where
> the former is for the POSIX errno values, and the latter is for other error
> numbers used by the OS for other kinds of errors that aren't covered by a
> POSIX errno macro (which might be other non-standard EBLAH macros that the
> OS adds to the POSIX ones, or some totally different error numbers used by
> the OS, e.g. Windows has its own error numbers unrelated to errno). The
> question is which category zero belongs to.

This is really confusing for native POSIX systems because the generic/system
terminology appears to be swapped for them.  This is also reflected in the
standard:



And in the documentation:



With this observation in mind, I reach this conclusion:

For a native POSIX system, no translation of errno values is needed.  That
suggests to me that all int values (the ev argument) correspond to a POSIX
errno value, and therefore all error conditions crated by
default_­error_­condition should be of the system_category category.

> So although zero isn't a POSIX errno value, POSIX does "reserve" the value
> zero and give it special meaning (it's the value that won't get set to
> report an error). No posix-ish OS is going to give it a different meaning
> that clashes with that.

I'm not sure if this matters.  A non-POSIX systems can use 0 for a real error
code that needs to be mapped to an actual C/POSIX E* value (such ERANGE).

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška  ---
(In reply to Melven.Roehrig-Zoellner from comment #27)
> (In reply to Martin Liška from comment #25)
> > (In reply to Melven.Roehrig-Zoellner from comment #24)
> > > Created attachment 46335 [details]
> > > Testcase: Fortran coverage .gcda and .gcno files
> > > 
> > > Hi Martin
> > > 
> > > here is coverage test data for one of the Fortran files where gcov does 
> > > not
> > > seem to terminate.
> > > 
> > > Steps to reproduce:
> > > Just run
> > > > gcov vast_mbs_model.gcda
> > > ... wait ...
> > > 
> > > I'm not sure if it would finish sometime; I aborted it after an hour.
> > > 
> > > Thanks for looking into that!
> > > Melven
> > 
> > Thanks a lot. Apparently, I did a stupid mistake in the 0002 patch. Please
> > test me the updated patch.
> 
> Hi Martin
> 
> With both patches it works fine.
> The output seams reasonable and matches well with the results obtained by
> GCC 7.2.0 for the file I provided (not identical results but the different
> compiler versions most probably produce slightly different code/branches)
> 
> Thanks a lot
> Melven

Hi Melven!

Thank you very much for testing. Yes, there can be slight differences among
compiler versions.

A nice cooperation, I'm going to install the patch early next week.

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Iain Sandoe from comment #2)
> > (In reply to Jakub Jelinek from comment #1)

> Though, I don't understand why that
> if (DEFAULT_ABI == ABI_DARWIN && crtl->calls_eh_return) return false;
> wouldn't work in rs6000_function_ok_for_sibcall, because that conditional
> should make sure we don't have any tail calls in such functions and thus the
> above shouldn't trigger.

Agreed, and that's exactly the code I have present, and I just did a clean
build.  However, as you suspect the sibcall is still present. Perhaps
crtl->calls_eh_return is not somehow set or somehow a sib call is generated
without checking it's OK.  Will look more later.

(call_insn/j 16 14 17 3 (parallel [
(set (reg:SI 3 r3)
(call (mem:SI (symbol_ref:SI ("_Unwind_RaiseException") [flags
0x403]  ) [0
_Unwind_RaiseException S4 A8])
(const_int 32 [0x20])))
(use (const_int 0 [0]))
(simple_return)
]) "/src-local/gcc-git/libgcc/unwind.inc":264:12 682
{*sibcall_value_local32}
 (expr_list:REG_CALL_DECL (symbol_ref:SI ("_Unwind_RaiseException") [flags
0x403]  )
(nil))
(expr_list:SI (use (reg:SI 3 r3))
(nil)))

[Bug sanitizer/90414] [Feature] Implementing HWASAN (and eventually MTE)

[matmal01 at gcc dot gnu.org]

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

--- Comment #2 from Matthew Malcomson  ---
(In reply to Richard Biener from comment #1)
> (In reply to Matthew Malcomson from comment #0)
> > Hello,
> > 
> > I'm looking into how we can implement MTE in the compiler.
> 
> What is MTE?

It's an architecture extension, otherwise known as memory tagging or memtag.
There's a high-level explanation in the link below, 
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-a-profile-architecture-2018-developments-armv85a

the instructions are introduced in Armv8.5-a.
https://developer.arm.com/docs/ddi0596/latest/base-instructions-alphabetic-order

I can't find a document describing *just* the MTE extension right now, but the
gist is that memory regions can have associated tags, and accesses to those
memory regions must be done with a pointer that has the corresponding tag in
bits 56-59 inclusive.

This is why the MTE extension will need to modify how the access is performed
instead of just adding in a check before the access is done -- it needs to
ensure that the pointer has the correct tag associated with the base object
that it's trying to access.
It's for the MTE extension that we would need the transformation below (so that
the *_CHECK ifn can ensure the pointer has the relevant tag before access).


> 
> ...
> > 3) Would there be any obvious difficulties with a transformation of the 
> > form:
> >   _4 = big_arrayD.3771[num_3(D)]
> >   
> >   TO
> >   
> >   _6 = _arrayD.3771[num_3(D)];
> >   _7 = HWASAN_CHECK(6, _6, 4, 4);
> >   _4 = *_7;
> > 
> >Instead of
> >   _4 = big_arrayD.3771[num_3(D)]
> >   
> >   TO
> >   
> >   _6 = _arrayD.3771[num_3(D)];
> >   ASAN_CHECK(6, _6, 4, 4);
> >   _4 = big_arrayD.3771[num_3(D)]
> > 
> >which is what ASAN currently does.
> >This new form would enable using MTE by allowing the check to modify the
> >pointer that the access will be made with (so it can have have its tag).
> 
> The "obvious" difficulties is that HWASAN_CHECK expansion needs to handle
> expanding the actual memory reference.  But that's only a slight
> complication.
> 
> Other complication is of course that it may pessimize optimization more
> than the old approach.

[Bug tree-optimization/88709] Improve store-merging

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #13 from Ramana Radhakrishnan  ---
(In reply to Richard Earnshaw from comment #9)
> (In reply to Jakub Jelinek from comment #7)
> > (In reply to Christophe Lyon from comment #6)
> > > I've noticed that the new test store_merging_29.c fails on
> > > arm-none-eabi --with-cpu cortex-a9
> > > FAIL: gcc.dg/store_merging_29.c scan-tree-dump store-merging "New sequence
> > > of 3 stores to replace old one of 6 stores"
> > 
> > That is because target-supports.exp lies on arm, even for -mcpu=cortex-a9
> > STRICT_ALIGNMENT is 1 on arm (it is 1 unconditionally), but
> > check_effective_target_non_strict_align returns true on arm anyway.
> > I've already added hacks for it in r256783 in another testcase though, guess
> > I'll do something similar now, but I must say I'm not very excited about
> > that.
> 
> Support for misaligned accesses is a three(.5!)-valued problem:
> 
> 1) There's no support in the architecture at all
> 2) There's some support with a limited set of instructions
> 3) There's full support: any memory access can handle any alignment.
> 3.5) There's full support: but some accesses may be very slow
> 
> I would think that these days most CPU architectures actually fall into
> either 1 or 2.  Many architectures have limitations, for example on atomic
> accesses that are unaligned.
> 
> STRICT_ALIGNMENT only covers, in reality case 3.  I'm not even sure if it
> would be defined on a machine with case 3.5.
> 
> I think the real problem here is that it's not clear what question this
> target-supports macro is really asking - does the CPU have the capability to
> do (some) unaligned acceses?  or can it arbitrarily support casts from
> unaligned pointers to standard types?

I agree - it sounds like this should be put in a comment next to the
target-supports query.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[Melven.Roehrig-Zoellner at DLR dot de]

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

--- Comment #27 from Melven.Roehrig-Zoellner at DLR dot de ---
(In reply to Martin Liška from comment #25)
> (In reply to Melven.Roehrig-Zoellner from comment #24)
> > Created attachment 46335 [details]
> > Testcase: Fortran coverage .gcda and .gcno files
> > 
> > Hi Martin
> > 
> > here is coverage test data for one of the Fortran files where gcov does not
> > seem to terminate.
> > 
> > Steps to reproduce:
> > Just run
> > > gcov vast_mbs_model.gcda
> > ... wait ...
> > 
> > I'm not sure if it would finish sometime; I aborted it after an hour.
> > 
> > Thanks for looking into that!
> > Melven
> 
> Thanks a lot. Apparently, I did a stupid mistake in the 0002 patch. Please
> test me the updated patch.

Hi Martin

With both patches it works fine.
The output seams reasonable and matches well with the results obtained by GCC
7.2.0 for the file I provided (not identical results but the different compiler
versions most probably produce slightly different code/branches)

Thanks a lot
Melven

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener  ---
(In reply to Richard Biener from comment #25)
> OK, so the hashtable looks good.  But
> 
> 135 pre "insert iterations == 1084" 1
> 
> is indeed excessive.  Expecially combined with
> 
> 135 pre "Insertions" 3

Ah, but

135 pre "New PHIs" 1085

so we're inserting a PHI per iteration appearantly... :/

> I wonder if you can share the full -fdump-tree-pre-details dump (it's
> going to be large though).

So the insertion possibly excessively iterates.

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Iain Sandoe from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > Most likely similar problem to the one analyzed in PR59813, after all, it is
> > the same function.  Previously, in that function there were no tail calls
> > and most likely no tailcalls in any function with __builtin_eh_return call,
> > now it is possible, so various targets need to either catch up and handle
> > that case properly, or declare they don't want to support tailcalls if
> > cfun->calls_eh_return in *_ok_for_sibcall target hook.
> 
> thanks for the suggestion, I tried disabling sib calls when
> crtl->calls_eh_return (it is probably something that should be done anyway,
> given what's below).  That's not sufficient to resolve the bug.

I guess the problem is then:
  /* This will not work in conjunction with sibcalls.  Make sure there
 are none.  (This check is expensive, but seldom executed.) */
  if (WORLD_SAVE_P (info))
{
  rtx_insn *insn;
  for (insn = get_last_insn_anywhere (); insn; insn = PREV_INSN (insn))
if (CALL_P (insn) && SIBLING_CALL_P (insn))
  {
info->world_save_p = 0;
break;
  }
}
if powerpc-darwin relies on world save in order to implement
__builtin_eh_return.  Though, I don't understand why that
if (DEFAULT_ABI == ABI_DARWIN && crtl->calls_eh_return) return false;
wouldn't work in rs6000_function_ok_for_sibcall, because that conditional
should make sure we don't have any tail calls in such functions and thus the
above shouldn't trigger.

> We actually generate correct code for -O1, but fail at -O2,3,s.

tail calls are optimized only at -O2.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška  ---
Created attachment 46336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46336=edit
Patch 2/2

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
(In reply to Melven.Roehrig-Zoellner from comment #24)
> Created attachment 46335 [details]
> Testcase: Fortran coverage .gcda and .gcno files
> 
> Hi Martin
> 
> here is coverage test data for one of the Fortran files where gcov does not
> seem to terminate.
> 
> Steps to reproduce:
> Just run
> > gcov vast_mbs_model.gcda
> ... wait ...
> 
> I'm not sure if it would finish sometime; I aborted it after an hour.
> 
> Thanks for looking into that!
> Melven

Thanks a lot. Apparently, I did a stupid mistake in the 0002 patch. Please test
me the updated patch.

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #1)
> Most likely similar problem to the one analyzed in PR59813, after all, it is
> the same function.  Previously, in that function there were no tail calls
> and most likely no tailcalls in any function with __builtin_eh_return call,
> now it is possible, so various targets need to either catch up and handle
> that case properly, or declare they don't want to support tailcalls if
> cfun->calls_eh_return in *_ok_for_sibcall target hook.

thanks for the suggestion, I tried disabling sib calls when
crtl->calls_eh_return (it is probably something that should be done anyway,
given what's below).  That's not sufficient to resolve the bug.

We actually generate correct code for -O1, but fail at -O2,3,s.

There seem to be two problems.

powerpc-darwin has a facility for the unwinder that allows the same binary to
run on a machine with or without altivec.  The unwind save/restore is delegated
to a function "save_world" that tests an OS bit to determine if the altivec
regs should be saved/restored.

1) We are correctly calling this for <= O1
 - We are not (for some TBD reason) calling it at greater optimisations.

2) however, it's not clear why the current generated code isn't lowerable (even
if it would not work at runtime on a machine without altivec).

longer-term there's an intention to remove the "save_world" machinery, but we
have to replace the relevant routines in libgcc to do that.  It seems that
right now if we just switched it off, the codegen would fail anyway.

[Bug c++/90383] [9/10 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 10 08:19:44 2019
New Revision: 271058

URL: https://gcc.gnu.org/viewcvs?rev=271058=gcc=rev
Log:
PR c++/90383
* tree-inline.h (struct copy_body_data): Add do_not_fold member.
* tree-inline.c (remap_gimple_op_r): Avoid folding expressions if
id->do_not_fold.
(copy_tree_body_r): Likewise.
(copy_fn): Set id.do_not_fold to true.

* g++.dg/cpp1y/constexpr-90383-1.C: New test.
* g++.dg/cpp1y/constexpr-90383-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-90383-1.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-90383-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener  ---
OK, so the hashtable looks good.  But

135 pre "insert iterations == 1084" 1

is indeed excessive.  Expecially combined with

135 pre "Insertions" 3

I wonder if you can share the full -fdump-tree-pre-details dump (it's
going to be large though).

[Bug tree-optimization/90385] [9/10 Regression] ICE: tree check: expected ssa_name, have real_cst in transform_to_exit_first_loop_alt, at tree-parloops.c:1772

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 10 08:20:38 2019
New Revision: 271059

URL: https://gcc.gnu.org/viewcvs?rev=271059=gcc=rev
Log:
PR tree-optimization/90385
* tree-parloops.c (try_create_reduction_list): Punt on non-SSA_NAME
arguments of the exit phis.

* gfortran.dg/pr90385.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr90385.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug fortran/90093] Extended C interop: optional argument incorrectly identified as PRESENT

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Fri May 10 07:59:42 2019
New Revision: 271057

URL: https://gcc.gnu.org/viewcvs?rev=271057=gcc=rev
Log:
2019-05-10  Paul Thomas  

PR fortran/90093
* trans-decl.c (convert_CFI_desc): Test that the dummy is
present before doing any of the conversions.

PR fortran/90352
* decl.c (gfc_verify_c_interop_param): Restore the error for
charlen > 1 actual arguments passed to bind(C) procs.
Clean up trailing white space.

PR fortran/90355
* trans-array.c (gfc_trans_create_temp_array): Set the 'span'
field to the element length for all types.
(gfc_conv_expr_descriptor): The force_no_tmp flag is used to
prevent temporary creation, especially for substrings.
* trans-decl.c (gfc_trans_deferred_vars): Rather than assert
that the backend decl for the string length is non-null, use it
as a condition before calling gfc_trans_vla_type_sizes.
* trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): 'force_no_tmp'
is set before calling gfc_conv_expr_descriptor.
* trans.c (get_array_span): Move the code for extracting 'span'
from gfc_build_array_ref to this function. This is specific to
descriptors that are component and indirect references.
* trans.h : Add the force_no_tmp flag bitfield to gfc_se.

2019-05-10  Paul Thomas  

PR fortran/90093
* gfortran.dg/ISO_Fortran_binding_12.f90: New test.
* gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code.

PR fortran/90352
* gfortran.dg/iso_c_binding_char_1.f90: New test.

PR fortran/90355
* gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test
the direct passing of substrings as descriptors to bind(C).
* gfortran.dg/assign_10.f90: Increase the tree_dump count of
'atmp' to account for the setting of the 'span' field.
* gfortran.dg/transpose_optimization_2.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.c
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.f90
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_4.f90
trunk/gcc/testsuite/gfortran.dg/assign_10.f90
trunk/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug gcov-profile/90420] [GCOV] wrong coverage with "-O3" or "-O2" optimizations for function call

[yangyibiao at nju dot edu.cn]

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

--- Comment #8 from Yibiao Yang  ---
(In reply to Martin Liška from comment #7)
> > Line #5 is marked as not executed. I understand that this function might be
> > optimized as an inline function. However, since Line #7 and Line #8 is
> > marked as executed and Line #5 is marked as not executed. This might mislead
> > others when debugging or testing based on code coverage.
> 
> That's the nature of any optimizing compiler. If you want to have the best
> results, then don't use -O2, or any other optimization level.

Got it. Thanks a lot.

[Bug fortran/90355] Uninitialized read in gfortran.dg/ISO_Fortran_binding_4.f90 test

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Fri May 10 07:59:42 2019
New Revision: 271057

URL: https://gcc.gnu.org/viewcvs?rev=271057=gcc=rev
Log:
2019-05-10  Paul Thomas  

PR fortran/90093
* trans-decl.c (convert_CFI_desc): Test that the dummy is
present before doing any of the conversions.

PR fortran/90352
* decl.c (gfc_verify_c_interop_param): Restore the error for
charlen > 1 actual arguments passed to bind(C) procs.
Clean up trailing white space.

PR fortran/90355
* trans-array.c (gfc_trans_create_temp_array): Set the 'span'
field to the element length for all types.
(gfc_conv_expr_descriptor): The force_no_tmp flag is used to
prevent temporary creation, especially for substrings.
* trans-decl.c (gfc_trans_deferred_vars): Rather than assert
that the backend decl for the string length is non-null, use it
as a condition before calling gfc_trans_vla_type_sizes.
* trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): 'force_no_tmp'
is set before calling gfc_conv_expr_descriptor.
* trans.c (get_array_span): Move the code for extracting 'span'
from gfc_build_array_ref to this function. This is specific to
descriptors that are component and indirect references.
* trans.h : Add the force_no_tmp flag bitfield to gfc_se.

2019-05-10  Paul Thomas  

PR fortran/90093
* gfortran.dg/ISO_Fortran_binding_12.f90: New test.
* gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code.

PR fortran/90352
* gfortran.dg/iso_c_binding_char_1.f90: New test.

PR fortran/90355
* gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test
the direct passing of substrings as descriptors to bind(C).
* gfortran.dg/assign_10.f90: Increase the tree_dump count of
'atmp' to account for the setting of the 'span' field.
* gfortran.dg/transpose_optimization_2.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.c
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.f90
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_4.f90
trunk/gcc/testsuite/gfortran.dg/assign_10.f90
trunk/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90

[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Fri May 10 07:59:42 2019
New Revision: 271057

URL: https://gcc.gnu.org/viewcvs?rev=271057=gcc=rev
Log:
2019-05-10  Paul Thomas  

PR fortran/90093
* trans-decl.c (convert_CFI_desc): Test that the dummy is
present before doing any of the conversions.

PR fortran/90352
* decl.c (gfc_verify_c_interop_param): Restore the error for
charlen > 1 actual arguments passed to bind(C) procs.
Clean up trailing white space.

PR fortran/90355
* trans-array.c (gfc_trans_create_temp_array): Set the 'span'
field to the element length for all types.
(gfc_conv_expr_descriptor): The force_no_tmp flag is used to
prevent temporary creation, especially for substrings.
* trans-decl.c (gfc_trans_deferred_vars): Rather than assert
that the backend decl for the string length is non-null, use it
as a condition before calling gfc_trans_vla_type_sizes.
* trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): 'force_no_tmp'
is set before calling gfc_conv_expr_descriptor.
* trans.c (get_array_span): Move the code for extracting 'span'
from gfc_build_array_ref to this function. This is specific to
descriptors that are component and indirect references.
* trans.h : Add the force_no_tmp flag bitfield to gfc_se.

2019-05-10  Paul Thomas  

PR fortran/90093
* gfortran.dg/ISO_Fortran_binding_12.f90: New test.
* gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code.

PR fortran/90352
* gfortran.dg/iso_c_binding_char_1.f90: New test.

PR fortran/90355
* gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test
the direct passing of substrings as descriptors to bind(C).
* gfortran.dg/assign_10.f90: Increase the tree_dump count of
'atmp' to account for the setting of the 'span' field.
* gfortran.dg/transpose_optimization_2.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.c
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.f90
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_4.f90
trunk/gcc/testsuite/gfortran.dg/assign_10.f90
trunk/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90

[Bug tree-optimization/90416] [10 Regression] ICE in dump_generic_node at tree-pretty-print.c:1383 since r271006

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P1

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 10 07:53:23 2019
New Revision: 271056

URL: https://gcc.gnu.org/viewcvs?rev=271056=gcc=rev
Log:
PR tree-optimization/88709
PR tree-optimization/90271
* gcc.dg/store_merging_29.c: Allow 4 stores to replace 6 stores on
arm*-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/store_merging_29.c

[Bug tree-optimization/88709] Improve store-merging

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 10 07:53:23 2019
New Revision: 271056

URL: https://gcc.gnu.org/viewcvs?rev=271056=gcc=rev
Log:
PR tree-optimization/88709
PR tree-optimization/90271
* gcc.dg/store_merging_29.c: Allow 4 stores to replace 6 stores on
arm*-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/store_merging_29.c

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

[rguenth at gcc dot gnu.org]

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

--- Comment #37 from Richard Biener  ---
(In reply to Ian Lance Taylor from comment #36)
> Different Ian, but I'm not sure which one -- ILT

I'm sure it was you - r148512.  Of course the intent of that rev. was to
speed things up.  I didn't check whether this change regressed the
testcase in this PR though.

[Bug sanitizer/90414] [Feature] Implementing HWASAN (and eventually MTE)

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
(In reply to Matthew Malcomson from comment #0)
> Hello,
> 
> I'm looking into how we can implement MTE in the compiler.

What is MTE?

...
> 3) Would there be any obvious difficulties with a transformation of the form:
>   _4 = big_arrayD.3771[num_3(D)]
>   
>   TO
>   
>   _6 = _arrayD.3771[num_3(D)];
>   _7 = HWASAN_CHECK(6, _6, 4, 4);
>   _4 = *_7;
> 
>Instead of
>   _4 = big_arrayD.3771[num_3(D)]
>   
>   TO
>   
>   _6 = _arrayD.3771[num_3(D)];
>   ASAN_CHECK(6, _6, 4, 4);
>   _4 = big_arrayD.3771[num_3(D)]
> 
>which is what ASAN currently does.
>This new form would enable using MTE by allowing the check to modify the
>pointer that the access will be made with (so it can have have its tag).

The "obvious" difficulties is that HWASAN_CHECK expansion needs to handle
expanding the actual memory reference.  But that's only a slight complication.

Other complication is of course that it may pessimize optimization more
than the old approach.

[Bug tree-optimization/90387] [9 Regression] __builtin_constant_p and -Warray-bounds warnings

[JunMa at linux dot alibaba.com]

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

--- Comment #4 from JunMa  ---
LGTM