[Bug target/92132] new test case gcc.dg/vect/vect-cond-reduc-4.c fails with its introduction in r277067

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin  ---
Powerpc already support vcond where A and B are in the same mode or the
same size mode. As Richard pointed out, this case requires some packs, it
requires powerpc supports vec_cmpv2dfv2di and vcond_mask_v4siv4si, the
comparison generates the mask then convert to V4SI to use in condition
selection.

[Bug ipa/92074] [10 regression] 26% performance regression on Spec2017 548.exchange2_r

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu  ---
Same regression on skylake.

[Bug c++/83534] C++17: typeinfo for noexcept function lacks noexcept information

[kamleshbhalui at gmail dot com]

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

--- Comment #5 from Kamlesh Kumar  ---
Fixed on trunk

[Bug tree-optimization/92173] New: [10 Regression] ICE in optab_for_tree_code, at optabs-tree.c:81

[asolokha at gmx dot com]

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

Bug ID: 92173
   Summary: [10 Regression] ICE in optab_for_tree_code, at
optabs-tree.c:81
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-10.0.0-alpha20191020 snapshot (r277217) ICEs when compiling the following
testcase w/ -O1 -ftree-loop-vectorize:

unsigned int
yo (unsigned int o0, signed char s1)
{
  for (s1 = 0; s1 < 1; s1 -= 2)
o0 += o0;

  return o0 + s1;
}

% x86_64-pc-linux-gnu-gcc-10.0.0-alpha20191020 -O1 -ftree-loop-vectorize -c
bcnm9vyh.c
during GIMPLE pass: vect
bcnm9vyh.c: In function 'yo':
bcnm9vyh.c:2:1: internal compiler error: in optab_for_tree_code, at
optabs-tree.c:81
2 | yo (unsigned int o0, signed char s1)
  | ^~
0x653a1a optab_for_tree_code(tree_code, tree_node const*, optab_subtype)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/optabs-tree.c:81
0xe8b9ba vectorizable_reduction(_stmt_vec_info*, _slp_tree*, _slp_instance*,
vec*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-vect-loop.c:6247
0xe91fc1 vect_analyze_loop_operations
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-vect-loop.c:1560
0xe91fc1 vect_analyze_loop_2
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-vect-loop.c:2079
0xe91fc1 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-vect-loop.c:2356
0xeaaa04 try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-vectorizer.c:886
0xeab82d vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-vectorizer.c:1114

[Bug fortran/87711] ICE in gfc_trans_transfer, at fortran/trans-io.c:2676

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
corallary:

program p
   character(3) :: c(2) = ['abc', 'xyz']
   integer n(2)
   n = len_trim(c,4)
   print *, n
end

% gfcx -o z a.f90
a.f90:4:0:

4 |n = len_trim(c,4)
  | 
internal compiler error: in gfc_trans_assignment_1, at
fortran/trans-expr.c:11065
0x5c80b6 gfc_trans_assignment_1
../../gccx/gcc/fortran/trans-expr.c:11065
0x83b122 trans_code
../../gccx/gcc/fortran/trans.c:1852
0x86a8d9 gfc_generate_function_code(gfc_namespace*)
../../gccx/gcc/fortran/trans-decl.c:6798
0x7e53e6 translate_all_program_units
../../gccx/gcc/fortran/parse.c:6276
0x7e53e6 gfc_parse_file()
../../gccx/gcc/fortran/parse.c:6515
0x838008 gfc_be_parse_file
../../gccx/gcc/fortran/f95-lang.c:208
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Without kind type parameter 

program p
   character(3) :: c(2) = ['abc', 'xyz']
   integer n(2)
   n = len_trim(c)
   print *, n
end

% gfcx -o z a.f90 && ./z
   3   3

[Bug c/92172] ARM Thumb2 frame pointers inconsistent with clang

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #1 from Wilco  ---
Firstly it's important to be clear this is about adding support for a frame
chain for unwinding.

A frame pointer is something different since it is used for addressing local
variables. Historically Arm compilers only supported a frame pointer, not a
frame chain for unwinding. So different Arm backends use different frame
pointer registers and there is no defined layout since it is not designed for
unwinding.

Why does this matter? Well as your examples show, if you want to emit a frame
chain using standard push/pop, it typically ends up pointing to the top of the
frame. That is the worst possible position for a frame pointer on Thumb - while
Arm supports negative immediate offsets up to 4KB, Thumb-1 doesn't support
negative offsets at all, and Thumb-2 supports offsets up to -255 but only with
32-bit instructions. So the result of conflating the frame chain and frame
pointer implies a terrible codesize hit for Thumb.

There is also an issue with using r7 as the frame chain in that you're now
reserving a precious low register callee-save and just use it once in a typical
function. So using r7 is a very bad idea for Thumb.

Your examples suggest LLVM suffers from both of these issues, and IIRC it still
uses r11 on Arm but r7 on Thumb. That is way too inefficient/incorrect to
consider a defacto standard.

[Bug tree-optimization/92128] fold more non-constant strlen relational expressions

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Yes.  I constrained strlenopt-80.c to only a subset of the targets where the
optimization has been implemented but forgot to do the same for strlenopt-81.c.
 I'm traveling this week but I'll try to remember to adjust the text after I
get back.

[Bug c/92172] New: ARM Thumb2 frame pointers inconsistent with clang and ARM-THUMB Procedure Call Standard

[sethml at ofb dot net]

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

Bug ID: 92172
   Summary: ARM Thumb2 frame pointers inconsistent with clang and
ARM-THUMB Procedure Call Standard
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sethml at ofb dot net
  Target Milestone: ---

This is a bit of a feature request, which has been rejected before, but I think
there are compelling reasons to reconsider.

The issue is described pretty well in this gcc-patches thread:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg195725.html

And in this clang bug:
https://bugs.llvm.org/show_bug.cgi?id=18505

The request is to provide an option to make gcc's frame pointer behavior
consistent with clang, either with a special flag, or by default.

The behavior of frame pointers on ARM is a mess, with AAPCS not defining it,
the obsolete ARM-Thumb Procedure Call Standard (ATPCS) recommdending a frame
layout different than GCC and clang, and ARM's obsolete armcc compiler
implementing different semantics.

However, as of 2014, ARM's standard toolchain is "ARM Compiler 6", which
packages clang:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.comp6/index.html

The Keil embedded toolchain, which is pretty industry-standard for ARM embedded
development, uses armclang:
http://www.keil.com/support/man/docs/armclang_ref/armclang_ref_vvi1466179578564.htm

Addressing some of the objections to modifying the frame layout from the
gcc-patches thread:

Wilco Dijkstra
:
> However changing the frame pointer like in the proposed patch
> will have a much larger cost - both in performance and codesize. You'd be 
> lucky if it is less than 10%. This is due to placing the frame pointer at the
> top rather than the bottom of the frame, and that is very inefficient in 
> Thumb-2.

I don't understand this objection. For a simple function the additional
overhead is literally nothing - for example , GCC
generates:
push{r3, r4, r7, lr}
add r7, sp, #0
while clang adds a small constant to make r7 point to the previous r7 on the
stack, with lr immediately above - zero overhead:
push{r4, r6, r7, lr}
add r7, sp, #8
For a more complex function where the compiler has to spill r8-r11 one extra
instruction is required to generate the right frame layout - gcc generates:
push{r3, r4, r5, r6, r7, r8, r9, lr}
add r7, sp, #0
While clang generates:
push{r4, r5, r6, r7, lr}
add r7, sp, #12
push.w  {r8, r9, r11}
Push (stmia) instructions take, at least on Cortex-M3, 1+N cycles, where N is
the number of registers saved. So clang's frame pointer approach takes one
extra cycle and 4 extra bytes.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/BABBCJII.html

> Doing real unwinding is also far more accurate than frame pointer based
> unwinding (the latter doesn't handle leaf functions correctly, entry/exit in
> non-leaf functions and shrinkwrapped functions - and this breaks callgraph
> profiling).

This is true, but doing real unwinding is prohibitively expensive in an
embedded systems context, in which one has only hundreds of KiB of code storage
and RAM.

Richard Earnshaw
:
> I object to another hack going in for another ill-specified frame
> pointer variant until such time as the ABI is updated to sort this out
> properly.
>
> So until the ABI sanctions a proper inter-function frame chain record,
> GCC will only support local use of the frame pointer and no chaining.

Since this is not defined by the ABI, the ABI is unlikely to specify it any
time soon. However, ARM seems to have blessed clang as the official ARM
compiler, so it's a defacto standard at this point.

Richard Earnshaw
:
> On entry to a function the code has to save the existing frame register.
> It doesn't know (can't trivially know) whether the caller is code
> compiled in Arm state or Thumb state.  So how can it save the caller's
> frame register if they are not the same?
>
> Furthermore, the 'other' frame register (ie r7 in Arm state, r11 in
> Thumb) is available as a call-saved register, so can contain any random
> value.  If you try to use that random value during a frame chain walk
> your program will most like take an access violation.  It will certainly
> give you a garbage frame chain.

This is true - you cannot safely walk the stack frames if thumb and arm
functions are intermixed. However, for the situations in which this feature is
most useful this is not a problem. For deeply embedded codebases, the entire
codebase 

[Bug c++/92171] New: accept incorrect access of static constexpr member when read from a reference

[jonathan.poelen at gmail dot com]

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

Bug ID: 92171
   Summary: accept incorrect access of static constexpr member
when read from a reference
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan.poelen at gmail dot com
  Target Milestone: ---

#include 

struct A
{
  static constexpr std::true_type value {};
};

int main()
{
  A a;
  A& ref = a;
  constexpr bool r1 = a.value; //ok
  constexpr bool r2 = ref.value; // this should not work
}

See https://bugs.llvm.org/show_bug.cgi?id=43732#c1

[Bug tree-optimization/92163] [10 Regression] ICE: Segmentation fault (in bitmap_set_bit)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 47079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47079=edit
Untested fix

Does this patch look OK ?

Thanks,
Prathamesh

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)

[shek.spam+gcc at gmail dot com]

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

--- Comment #26 from Kevin Shekleton  ---
Thanks for educating me on the numbering scheme, Segher. That's helpful info!

Florian - I see you requested the CVE. Will you be working to get the NVD entry
updated with the appropriate affected releases/fix versions?

[Bug driver/92170] Incorrect function names output when using -fstack-usage on C++

[austinpmorton at gmail dot com]

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

--- Comment #1 from Austin Morton  ---
Created attachment 47076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47076=edit
current su output

[Bug driver/92170] Incorrect function names output when using -fstack-usage on C++

[austinpmorton at gmail dot com]

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

--- Comment #2 from Austin Morton  ---
Created attachment 47077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47077=edit
expected su output

[Bug driver/92170] Incorrect function names output when using -fstack-usage on C++

[austinpmorton at gmail dot com]

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

--- Comment #3 from Austin Morton  ---
Created attachment 47078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47078=edit
workaround patch

[Bug driver/92170] New: Incorrect function names output when using -fstack-usage on C++

[austinpmorton at gmail dot com]

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

Bug ID: 92170
   Summary: Incorrect function names output when using
-fstack-usage on C++
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: austinpmorton at gmail dot com
  Target Milestone: ---

Created attachment 47075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47075=edit
example source

When test.cc is compiled as follows:

g++ -c -fstack-usage test.cc

test.su contents appears as follows:
test.cc:12:34:   16  static
test.cc:12:34:static void::_FUN(void*)   24  static
test.cc:12:34:::operator void (*)(void*)() const 16  static
test.cc:8:11:)>::fptr_t) [with RetT = void; ArgTs = {}] 16  static
test.cc:20:12:void __static_initialization_and_destruction_0(int, int)  48 
static
test.cc:20:12:cc)   16  static

expected test.su contents as follows:
test.cc:12:26:   16  static
test.cc:12:26:static void::_FUN(void*)   24  static
test.cc:12:26:::operator void (*)(void*)() const 16  static
test.cc:8:11:function_ref::function_ref(function_ref::fptr_t) [with RetT = void;
ArgTs = {}]  16  static
test.cc:20:12:void __static_initialization_and_destruction_0(int, int)  48 
static
test.cc:20:12:(static initializers for test.cc) 16  static


This appears to be caused by code in output_stack_usage in toplev.c searching
for "." in the function name and only outputting after that point.
It is unclear to me what the intent was originally, but it dates back to the
original stack usage support commit (990495a75cd7).

I achieved the expected output shown above by applying the below patch to
disable the checks:

diff --git a/gcc/toplev.c b/gcc/toplev.c
index 1c7002f5c37..a0b6cefd2d1 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -981,6 +981,7 @@ output_stack_usage (void)
= strchr (IDENTIFIER_POINTER (DECL_NAME (current_function_decl)), '.');
   const char *name
= lang_hooks.decl_printable_name (current_function_decl, 2);
+#if 0
   if (suffix)
{
  const char *dot = strchr (name, '.');
@@ -996,6 +997,7 @@ output_stack_usage (void)
  if (dot)
name = dot + 1;
}
+#endif

   fprintf (stack_usage_file,
   "%s:%d:%d:%s\t" HOST_WIDE_INT_PRINT_DEC"\t%s\n",

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)

[segher at gcc dot gnu.org]

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

--- Comment #25 from Segher Boessenkool  ---
There is no 9.2.1 release, and there will not be one either.

See https://gcc.gnu.org/develop.html for how our numbering scheme works.
Very briefly, if the second number is 0, or the third number is *not* zero,
it isn't a release but some development version.

I have nothing to do with the NVD, and not with https://cve.mitre.org/ either.
I didn't request a CVE for this.  I am merely the maintainer of this code, I
am not involved with the vulnerability circus.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)

[shek.spam+gcc at gmail dot com]

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

--- Comment #24 from Kevin Shekleton  ---
Thanks, Segher. You mentioned 9.3 -- does that mean there won't be a 9.2.1
release? If so, will the 'Known to work' field here be updated?

Also, will someone from the GCC team request an update to the NVD database to
correct the affected release versions?

[Bug target/92168] Poor code generation for addcarry / subborrow

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
[hjl@gnu-cfl-1 gcc]$  cat c.c
#include 

unsigned char
foo (unsigned long long HxL0, unsigned long long LxH0,
 unsigned long long HxL1, unsigned long long LxH1)
{
  unsigned char carry;
  carry = _addcarry_u64(0, HxL0, LxH0, );
  carry = _addcarry_u64(carry, HxL1, LxH1, );
  return carry;
}
[hjl@gnu-cfl-1 gcc]$ gcc -S -O2 c.c
[hjl@gnu-cfl-1 gcc]$ cat c.s
.file   "c.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB5519:
.cfi_startproc
addq%rsi, %rdi
setc%al
addb$-1, %al
adcq%rdx, %rcx
setc%al
ret
.cfi_endproc
.LFE5519:
.size   foo, .-foo
.ident  "GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 gcc]$ clang -S -O2 c.c
[hjl@gnu-cfl-1 gcc]$ cat c.s
.text
.file   "c.c"
.globl  foo # -- Begin function foo
.p2align4, 0x90
.type   foo,@function
foo:# @foo
.cfi_startproc
# %bb.0:
addq%rsi, %rdi
adcq%rcx, %rdx
setb%al
retq
.Lfunc_end0:
.size   foo, .Lfunc_end0-foo
.cfi_endproc
# -- End function

.ident  "clang version 8.0.0 (Fedora 8.0.0-1.fc30)"
.section".note.GNU-stack","",@progbits
.addrsig
[hjl@gnu-cfl-1 gcc]$

[Bug gcov-profile/83434] [GCOV] A label after a non-executed if statement is wrongly marked as not executed in gcov

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Oct 21 20:19:28 2019
New Revision: 277270

URL: https://gcc.gnu.org/viewcvs?rev=277270=gcc=rev
Log:
PR c++/83434 - typeinfo for noexcept function lacks noexcept information

2019-10-21  Kamlesh Kumar  

* rtti.c (get_tinfo_decl_dynamic): Do not call
TYPE_MAIN_VARIANT for function.
(get_typeid): Likewise.

* g++.dg/rtti/pr83534.C: New Test.

Reviewed-by: Jason Merrill 

Added:
trunk/gcc/testsuite/g++.dg/rtti/pr83534.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c

[Bug c++/92169] New: crash on referring to a local class member by unqualified name from outside the enclosing function

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 92169
   Summary: crash on referring to a local class member by
unqualified name from outside the enclosing function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

[Probably no-one will ever write code like this outside a compiler test case,
but filing just in case this affects non-contrived situations.]

This code crashes every version of g++ that supports deduced return types:


auto f() {
static int n;
struct Y {
static int () { return n; }
struct X {
int ();
};
};
return Y::X();
};
using X = decltype(f());
int ::get() { return g(); }

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #22)
> See https://gcc.gnu.org/develop.html/timeline

Sorry, that should be https://gcc.gnu.org/develop.html#timeline

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
(In reply to Segher Boessenkool from comment #21)
> No future releases for GCC have been announced.  Judging from historical
> trends the next (and last) GCC 7 release (7.5) will be in November, GCC 8
> (8.4) in December, GCC 9 (9.3) in Februari, and GCC 10 (10.1) will be
> there in May.  This is just *my* estimate, your mileage may vary, etc.

See https://gcc.gnu.org/develop.html/timeline for dates of point releases from
the release branches, which can be used to judge the historical trends for
yourself.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)

[segher at gcc dot gnu.org]

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

--- Comment #21 from Segher Boessenkool  ---
It will be fixed in the next releases of all still supported branches
(that's GCC 7, 8, and 9), and also in the upcoming GCC 10 release of
course.

If you are in a hurry, you can build your own compilers right now, the
problem has been fixed in all open release branches.

If, alternatively, you get your GCC from some distribution, ask them
about *their* release plans.  We don't know.

No future releases for GCC have been announced.  Judging from historical
trends the next (and last) GCC 7 release (7.5) will be in November, GCC 8
(8.4) in December, GCC 9 (9.3) in Februari, and GCC 10 (10.1) will be
there in May.  This is just *my* estimate, your mileage may vary, etc.

[Bug c++/92015] [9/10 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/92168] Poor code generation for addcarry / subborrow

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-21
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
Confirmed.

[Bug target/92168] Poor code generation for addcarry / subborrow

[dje at gcc dot gnu.org]

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

--- Comment #1 from David Edelsohn  ---
Created attachment 47074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47074=edit
Source code example from Compiler Explorer

[Bug target/92168] New: Poor code generation for addcarry / subborrow

[dje at gcc dot gnu.org]

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

Bug ID: 92168
   Summary: Poor code generation for addcarry / subborrow
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Real World Technology reader reports poor GCC code generation relative to Clang
and MSVC for source code involving carry / borrow.

https://www.realworldtech.com/forum/?threadid=188061=188061

with example at Compiler Explorer

https://godbolt.org/z/YYq6ou

[Bug c++/92015] [9/10 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 18:51:43 2019
New Revision: 277267

URL: https://gcc.gnu.org/viewcvs?rev=277267=gcc=rev
Log:
PR c++/92015
* constexpr.c (cxx_eval_component_reference, cxx_eval_bit_field_ref):
Use STRIP_ANY_LOCATION_WRAPPER on CONSTRUCTOR elts.

* g++.dg/cpp0x/constexpr-92015.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-92015.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/92062] [9 Regression] ODR-use by static_assert ignored for static member of class template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ODR-use   |[9 Regression] ODR-use by
   |by static_assert ignored|static_assert ignored for
   |for static member of class  |static member of class
   |template|template

--- Comment #6 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/92062] [9/10 Regression] ODR-use by static_assert ignored for static member of class template

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Mon Oct 21 18:45:45 2019
New Revision: 277266

URL: https://gcc.gnu.org/viewcvs?rev=277266=gcc=rev
Log:
PR c++/92062 - ODR-use ignored for static member of class template.

has_value_dependent_address wasn't stripping location wrappers so it
gave the wrong answer for "" in the static_assert.  That led us to
thinking that the expression isn't instantiation-dependent, and we
skipped static initialization of A<0>::x.

This patch adds stripping so that has_value_dependent_address gives the
same answer as it used to before the location wrappers addition.

* pt.c (has_value_dependent_address): Strip location wrappers.

* g++.dg/cpp0x/constexpr-odr1.C: New test.
* g++.dg/cpp0x/constexpr-odr2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-odr1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-odr2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

[longb at cray dot com]

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

--- Comment #5 from Bill Long  ---
Any progress on this?

[Bug c++/92106] [8/9 Regression] ICE with structured bindings and -Wreturn-local-addr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE |[8/9 Regression] ICE with
   |with structured bindings|structured bindings and
   |and -Wreturn-local-addr |-Wreturn-local-addr

--- Comment #7 from Marek Polacek  ---
Fixed on trunk so far.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)

[kevin.shekleton at gmail dot com]

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

Kevin Shekleton  changed:

   What|Removed |Added

 CC||kevin.shekleton at gmail dot 
com

--- Comment #20 from Kevin Shekleton  ---
Hi all. The NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2019-15847)
specifies that gcc 10.0 will fix this issue. Of course, 10.0 is not yet
released and the 'Known to work' field on this Bugzilla entry states "10.0,
6.5.0, 7.4.1, 8.3.1, 9.2.1". Some questions:

1. Any ETA on when a fix versions will be released?

2. From the commits here it looks like this fix is being backported to match
the 'Known to work' field here (thanks!). Is the NVD entry going to be updated
to reflect accurate  affected versions of gcc?

[Bug c++/92106] [8/9/10 Regression] ICE with structured bindings and -Wreturn-local-addr

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Mon Oct 21 18:22:41 2019
New Revision: 277264

URL: https://gcc.gnu.org/viewcvs?rev=277264=gcc=rev
Log:
PR c++/92106 - ICE with structured bindings and -Wreturn-local-addr.

* typeck.c (maybe_warn_about_returning_address_of_local): Avoid
recursing on null initializer and return false instead.

* g++.dg/cpp1z/decomp50.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/92027] [10 regression] gfortran.dg/ISO_Fortran_binding_10.f90 FAILs – conditional jump based on uninitialized memory in runtime/ISO_Fortran_binding.c

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
Fixed under PR91926.

Thanks for the report

Paul

[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Sorry about that.  I've been working on new C++20 features in the dwindling
stage 1 time, and kept kicking this can down the stage3 road.  But hopefully
I'll get to this after posting my aggregate paren init patch, which should be
Real Soon.

Unfortunately, there's no way to turn off the const checking.

[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array

[h2+bugs at fsfe dot org]

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

Hannes Hauswedell  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #2 from Hannes Hauswedell  ---
Any news on this issue? We are using this pattern in some rather central files
in our library and the bug literally breaks 90% of our unit tests so we can't
keep track of other gcc10 issues or try the new concepts support...

Thank you for your help!

[Bug c/92167] New: Poor source location choice for diagnostic in macro expansion

[achurch+gcc at achurch dot org]

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

Bug ID: 92167
   Summary: Poor source location choice for diagnostic in macro
expansion
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: achurch+gcc at achurch dot org
  Target Milestone: ---

Given a macro which expands to a function call and passes a macro argument as
an argument in that call, if the macro argument is parenthesized, a diagnostic
triggered by an improper argument in an invocation will be associated with the
macro definition rather than the invocation.  For example:

-
$ cat test.c
extern int a(void *);
#define b(x) a((x))
int c(int x) {return b(x);}
$ gcc-9.2.0 -c test.c
test.c: In function 'c':
test.c:2:16: warning: passing argument 1 of 'a' makes pointer from integer
without a cast [-Wint-conversion]
2 | #define b(x) a((x))
  |^~~
  ||
  |int
test.c:3:22: note: in expansion of macro 'b'
3 | int c(int x) {return b(x);}
  |  ^
test.c:1:14: note: expected 'void *' but argument is of type 'int'
1 | extern int a(void *);
  |  ^~
-

The invocation is also shown as a note, but one must read through the list of
notes in order to find it rather than simply checking the line given with the
diagnostic itself.  It would arguably be more useful to associate the
diagnostic with the macro invocation on line 3 and include the macro expansion
as a note, as Clang does:

-
$ clang-9 -c test.c
test.c:3:22: warning: incompatible integer to pointer conversion passing 'int'
to parameter of type 'void *' [-Wint-conversion]
int c(int x) {return b(x);}
 ^~~~
test.c:2:16: note: expanded from macro 'b'
#define b(x) a((x))
   ^~~
test.c:1:20: note: passing argument to parameter here
extern int a(void *);
   ^
1 warning generated.
-


If the macro parameter is used as is (not parenthesized), GCC does identify the
macro invocation as the diagnostic location:

-
$ cat test2.c
extern int a(void *);
#define b(x) a(x)
int c(int x) {return b(x);}
$ gcc-9.2.0 -c test2.c
test.c: In function 'c':
test.c:3:24: warning: passing argument 1 of 'a' makes pointer from integer
without a cast [-Wint-conversion]
3 | int c(int x) {return b(x);}
  |^
  ||
  |int
test.c:2:16: note: in definition of macro 'b'
2 | #define b(x) a(x)
  |^
test.c:1:14: note: expected 'void *' but argument is of type 'int'
1 | extern int a(void *);
  |  ^~
-

But this is not particularly helpful because most macro arguments must be
parenthesized to be used safely.

[Bug testsuite/92165] [10 regression] g++.dg/cpp2a/nodiscard-once.C fails starting with r277205

[phdofthehouse at gmail dot com]

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

--- Comment #3 from JeanHeyd Meneide  ---
Thanks for pinging me about this. I'm at a WG14 Meeting so I won't be able to
get to it immediately, but when I get back I'll get right on fixing!

[Bug testsuite/92165] [10 regression] g++.dg/cpp2a/nodiscard-once.C fails starting with r277205

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||phdofthehouse at gmail dot com

--- Comment #2 from Jakub Jelinek  ---
As I said on gcc-patches, my changes only unbroke testing altogether, before
there were tcl syntax errors, the actual tests were inroduced in r277200.

[Bug testsuite/92165] [10 regression] g++.dg/cpp2a/nodiscard-once.C fails starting with r277205

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Also these:

FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
16)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
17)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
176)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
178)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
183)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
185)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
190)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line
192)
FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a (test for excess errors)

[Bug tree-optimization/92166] New: [10 regression] ICE compiling gcc.dg/vshift-5.c starting with r277241

[seurer at gcc dot gnu.org]

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

Bug ID: 92166
   Summary: [10 regression] ICE compiling gcc.dg/vshift-5.c
starting with r277241
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -O3  -lm  -o
./vshift-5.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -lm -o ./vshift-5.exe
during GIMPLE pass: slp
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c: In function 'f2':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c:26:1: internal
compiler error: in operator[], at vec.h:859
0x10df142f vec::operator[](unsigned int)
/home/seurer/gcc/gcc-test2/gcc/vec.h:859
0x10df142f vec::operator[](unsigned int)
/home/seurer/gcc/gcc-test2/gcc/vec.h:1425
0x10df142f vectorizable_shift
/home/seurer/gcc/gcc-test2/gcc/tree-vect-stmts.c:5842
0x10e0ac4b vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
/home/seurer/gcc/gcc-test2/gcc/tree-vect-stmts.c:10812
0x10e3b69f vect_schedule_slp_instance
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3950
0x10e3b3ab vect_schedule_slp_instance
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3844
0x10e3dd2b vect_schedule_slp(vec_info*)
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:4024
0x10e421d7 vect_slp_bb_region
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3076
0x10e421d7 vect_slp_bb(basic_block_def*)
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3170
0x10e4595b execute
/home/seurer/gcc/gcc-test2/gcc/tree-vectorizer.c:1309

[Bug testsuite/92165] New: [10 regression] g++.dg/cpp2a/nodiscard-once.C fails starting with r277205

[seurer at gcc dot gnu.org]

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

Bug ID: 92165
   Summary: [10 regression] g++.dg/cpp2a/nodiscard-once.C fails
starting with r277205
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++2a -O -ftrack-macro-expansion=0  -S -o nodiscard-once.s(timeout =
300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++2a -O -ftrack-macro-expansion=0 -S -o nodiscard-once.s
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C:5:14:
error: attribute 'nodiscard' can appear at most once in an attribute-list
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C: In
function 'void test()':
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C:10:10:
warning: ignoring return value of 'int check1()', declared with attribute
'nodiscard' [-Wunused-result]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C:5:30:
note: declared here
compiler exited with status 1
PASS: g++.dg/cpp2a/nodiscard-once.C  -std=gnu++2a  (test for errors, line 5)
FAIL: g++.dg/cpp2a/nodiscard-once.C  -std=gnu++2a (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C:10:10:
warning: ignoring return value of 'int check1()', declared with attribute
'nodiscard' [-Wunused-result]

testcase /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/dg.exp completed in 0
seconds

=== g++ Summary ===

# of expected passes1
# of unexpected failures1
# of unsupported tests  3

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||meta-bug
 Blocks||90709
 Depends on||66970

--- Comment #16 from Iain Sandoe  ---
I think to make this into a meta-bug, with dependencies on:

__has_builtin () -  PR 66970
__has_feature ()
__has_extension ()
__attribute__((__availability__()))
  which depends on __attribute__((__unavailable__(...)))

Martin Sebor has posted a patch for PR 66970 and i have patches in progress for
__has_fature/extension and __attribute__((__unavailable__()))

(I will create PRs for the other deps. in due course)

At the moment, I'm a bit reluctant to jam __has_ => 0 in Darwin startup
code, since that might well produce wrong effects on headers that are already
adjusted (i.e. the compiler would report that __has_xxx was defined, but that
all the facilities were non-existent - which is a different state from
reporting hat __has_xxx is not present).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
[Bug 66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709
[Bug 90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on
Darwin platforms.

[Bug tree-optimization/92162] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92162] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 21 13:43:19 2019
New Revision: 277261

URL: https://gcc.gnu.org/viewcvs?rev=277261=gcc=rev
Log:
2019-10-21  Richard Biener  

PR tree-optimization/92162
* tree-vect-loop.c (vect_create_epilog_for_reduction): Lookup
STMT_VINFO_REDUC_IDX in reduc_info.
* tree-vect-stmts.c (vectorizable_condition): Likewise.

* gcc.dg/pr92162.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr92162.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c

[Bug c/92164] Wrong result using builtin rint/rintf optimization in x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
See PR34678 for issues of -frounding-math.

[Bug c/92164] Wrong result using builtin rint/rintf optimization in x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Note that if GCC would be standards-conforming here your program would still
need

#pragma STDC FENV_ACCESS ON

since you are accessing and modifying the floating-point state (where the
pragma has no effect for GCC)

[Bug c/92164] Wrong result using builtin rint/rintf optimization in x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Steffen Schmidt from comment #3)
> Thanks for the quick reply.
> 
> Just tested using -frounding-math and it seems to fix the issue. 
> Sorry, I was not aware of this option, according to GCCs manual it is
> experimental.
> 
> Please correct me if I'm wrong, but my expectation would be, assuming a
> correct program, switching from -O0 to -O1 should not influence the runtime
> result.

GCC assumes you do not mess with the floating-point state but round-to-nearest
is in effect.  You have to use -frounding-math to remove this assumption but
then still correct operation isn't guaranteed (thus the "experimental" tag
for this option).

[Bug tree-optimization/92162] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Seems to hit 416.gamess as well.  Patch in testing.

[Bug tree-optimization/91665] [8 Regression] ICE in build_vector_from_val, at tree.c:1904

[dcb314 at hotmail dot com]

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

--- Comment #12 from David Binderman  ---
Scratch my comment. Wrong bug report. Sorry.

[Bug tree-optimization/92162] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Another test case seems to be:

double *a;
b() {
  int c, d = 1;
  for (; c < b; c++)
for (; c < b; c++)
  if (a[c])
d = 0;
  if (d)
e();
}

-O3 required for this case. Bug seems to start sometime between
revision 277050 and 277010.

[Bug tree-optimization/92162] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/91665] [8 Regression] ICE in build_vector_from_val, at tree.c:1904

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #11 from David Binderman  ---
I see something similar here. Flag -O3 required.

Bug seems to start sometime between revision 277050 and 277100.

[Bug tree-optimization/92163] [10 Regression] ICE: Segmentation fault (in bitmap_set_bit)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
tree-ssa-dse.c assumes need_eh_cleanup bitmap (which is static) is initialized
at the start of the pass and handled at the end.
So, do we need to add functions (init and fini) which ifcvt can call, or just
not consider in the ifcvt local dce stores that can throw, something else?

[Bug ipa/92160] The control variable of TLS variable alias be removed when use emutls(--enable-tls=no)

[unclepom at sina dot com]

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

--- Comment #2 from Pom  ---
Created attachment 47073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47073=edit
test code and makefile

[Bug tree-optimization/92163] [10 Regression] ICE: Segmentation fault (in bitmap_set_bit)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r276681.

[Bug ipa/92160] The control variable of TLS variable alias be removed when use emutls(--enable-tls=no)

[unclepom at sina dot com]

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

--- Comment #1 from Pom  ---
full source code:

#define TLS __thread
TLS int oldname = 7;
extern TLS int newname __attribute__((alias("oldname")));

[Bug inline-asm/92151] Spurious register copying

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
>> (or write actual assembly rather than using inline-asm).
> In this case, yes -- I now declare the function "naked" and avoid the issue.

I think this solution (hand-writing asm for the entire function) is generally
undesirable because you become responsible for ABI/calling convention, the
compiler won't help you with things like properly restoring callee-saved
registers, and violations may stay unnoticed as long as callers don't try to
use a particular callee-saved reg.

Here's a manually reduced variant that exhibits a similar issue at -O1:

void foo(int num, int c) {
asm("# %0" : "+r"(num));
while (--c)
asm goto("# %0" :: "r"(num) :: l2);
l2:
asm("# %0" :: "r"(num));
}

The main issue seems to be our 'asmcons' pass transforming RTL in such a way
that REG_DEAD notes are "behind" the actual death, so if the RA takes them
literally it operates on wrong (too conservative) lifetime information; e.g.,
for the first asm, just before IRA we have:

(insn 29 4 8 2 (set (reg:SI 84 [ num ])
(reg:SI 85)) "./example.c":3:5 -1
 (nil))
(insn 8 29 7 2 (parallel [
(set (reg:SI 84 [ num ])
(asm_operands:SI ("# %0") ("=r") 0 [
(reg:SI 84 [ num ])
]
 [
(asm_input:SI ("0") ./example.c:3)
]
 [] ./example.c:3))
(clobber (reg:CC 17 flags))
]) "./example.c":3:5 -1
 (expr_list:REG_DEAD (reg:SI 85)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

but register 85 actually dies in insn 29, not in insn 8.

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

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
The originally reported issue fixed for 9.3+ too.  Not really sure if it is a
good idea to backport the shift and array ref changes, those are quite
invasive.

[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Fixed for 9.3+.

[Bug c++/88203] assert does not compile with OpenMP's pragma omp parallel for default(none)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Version|unknown |8.2.1

--- Comment #10 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug c/92164] Wrong result using builtin rint/rintf optimization in x86_64

[steffen-schmidt at siemens dot com]

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

--- Comment #3 from Steffen Schmidt  ---
Thanks for the quick reply.

Just tested using -frounding-math and it seems to fix the issue. 
Sorry, I was not aware of this option, according to GCCs manual it is
experimental.

Please correct me if I'm wrong, but my expectation would be, assuming a correct
program, switching from -O0 to -O1 should not influence the runtime result.

[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.3

--- Comment #16 from Jakub Jelinek  ---
Fixed for 9.3+ too. 8.x and earlier shouldn't have the problem, as readonly
variables are predetermined shared there.

[Bug tree-optimization/91723] [9 Regression] builtin fma is not optimized or vectorized as *+

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug middle-end/91623] [7/8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] -msse4.1 |[7/8 Regression] -msse4.1
   |-O3 segfault in |-O3 segfault in
   |/usr/lib/gcc/x86_64-pc-linu |/usr/lib/gcc/x86_64-pc-linu
   |x-gnu/8.3.0/include/smmintr |x-gnu/8.3.0/include/smmintr
   |in.h:270:10 |in.h:270:10

--- Comment #9 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug lto/91572] [9 Regression] lto1: error: type variant has different ‘TREE_TYPE’ since r269862

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug tree-optimization/91665] [8 Regression] ICE in build_vector_from_val, at tree.c:1904

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||9.2.1
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |build_vector_from_val, at   |build_vector_from_val, at
   |tree.c:1904 |tree.c:1904

--- Comment #10 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug tree-optimization/91351] [9 Regression] -fstrict-enums generates incorrect code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:49:18 2019
New Revision: 277259

URL: https://gcc.gnu.org/viewcvs?rev=277259=gcc=rev
Log:
Backported from mainline
2019-10-17  Jakub Jelinek  

PR tree-optimization/92056
* tree-object-size.c (cond_expr_object_size): Return early if then_
processing resulted in unknown size.

* gcc.c-torture/compile/pr92056.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/pr92056.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-object-size.c

[Bug fortran/87752] ICE in omp_add_variable, at gimplify.c:6776

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:48:34 2019
New Revision: 277258

URL: https://gcc.gnu.org/viewcvs?rev=277258=gcc=rev
Log:
Backported from mainline
2019-10-17  Jakub Jelinek  

PR fortran/87752
* gfortran.dg/gomp/pr87752.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/gomp/pr87752.f90
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:48:00 2019
New Revision: 277257

URL: https://gcc.gnu.org/viewcvs?rev=277257=gcc=rev
Log:
Backported from mainline
2019-10-05  Jakub Jelinek  

PR tree-optimization/91734
* generic-match-head.c: Include fold-const-call.h.
* match.pd (sqrt(x) cmp c): Check the boundary value and
in case inexact computation of c*c affects comparison of the boundary,
turn LT_EXPR into LE_EXPR, GE_EXPR into GT_EXPR, LE_EXPR into LT_EXPR
or GT_EXPR into GE_EXPR.  Punt for sqrt comparisons against NaN and
for -frounding-math.  For c2, try the next smaller or larger floating
point constant depending on comparison code and if it has the same
sqrt as c2, use it instead of c2.

* gcc.dg/pr91734.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr91734.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/generic-match-head.c
branches/gcc-9-branch/gcc/match.pd
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:46:21 2019
New Revision: 277255

URL: https://gcc.gnu.org/viewcvs?rev=277255=gcc=rev
Log:
Backported from mainline
2019-10-01  Jakub Jelinek  

PR c++/91925
* c-warn.c (check_alignment_of_packed_member): Ignore FIELD_DECLs
with NULL DECL_FIELD_OFFSET.

* g++.dg/conversion/packed2.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/conversion/packed2.C
Modified:
branches/gcc-9-branch/gcc/c-family/ChangeLog
branches/gcc-9-branch/gcc/c-family/c-warn.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:47:09 2019
New Revision: 277256

URL: https://gcc.gnu.org/viewcvs?rev=277256=gcc=rev
Log:
Backported from mainline
2019-10-04  Jakub Jelinek  

PR c++/91974
* cp-gimplify.c (cp_gimplify_expr) : For
-fstrong-eval-order ensure CALL_EXPR_FN side-effects are evaluated
before any arguments.  Additionally, ensure CALL_EXPR_FN that isn't
invariant nor OBJ_TYPE_REF nor SSA_NAME is forced into a temporary.

* g++.dg/cpp1z/eval-order5.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1z/eval-order5.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/cp-gimplify.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:45:27 2019
New Revision: 277254

URL: https://gcc.gnu.org/viewcvs?rev=277254=gcc=rev
Log:
Backported from mainline
2019-09-29  Jakub Jelinek  

PR bootstrap/90543
* optc-save-gen.awk: Fix up printing string option differences.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/optc-save-gen.awk

[Bug c++/88203] assert does not compile with OpenMP's pragma omp parallel for default(none)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:44:53 2019
New Revision: 277253

URL: https://gcc.gnu.org/viewcvs?rev=277253=gcc=rev
Log:
Backported from mainline
2019-09-27  Jakub Jelinek  

PR c++/88203
* c-common.h (c_omp_predefined_variable): Declare.
* c-omp.c (c_omp_predefined_variable): New function.
(c_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_SHARED
for predefined variables.

* c-parser.c (c_parser_predefined_identifier): New function.
(c_parser_postfix_expression): Use it.
(c_parser_omp_variable_list): Parse predefined identifiers.
* c-typeck.c (c_finish_omp_clauses): Allow predefined variables
in shared and firstprivate clauses, even when they are predetermined
shared.

* parser.c (cp_parser_omp_var_list_no_open): Parse predefined
variables.
* semantics.c (finish_omp_clauses): Allow predefined variables in
shared and firstprivate clauses, even when they are predetermined
shared.
* cp-gimplify.c (cxx_omp_predetermined_sharing_1): Return
OMP_CLAUSE_DEFAULT_SHARED for predefined variables.

* c-c++-common/gomp/pr88203-1.c: New test.
* c-c++-common/gomp/pr88203-2.c: New test.
* c-c++-common/gomp/pr88203-3.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/c-c++-common/gomp/pr88203-1.c
branches/gcc-9-branch/gcc/testsuite/c-c++-common/gomp/pr88203-2.c
branches/gcc-9-branch/gcc/testsuite/c-c++-common/gomp/pr88203-3.c
Modified:
branches/gcc-9-branch/gcc/c-family/ChangeLog
branches/gcc-9-branch/gcc/c-family/c-common.h
branches/gcc-9-branch/gcc/c-family/c-omp.c
branches/gcc-9-branch/gcc/c/ChangeLog
branches/gcc-9-branch/gcc/c/c-parser.c
branches/gcc-9-branch/gcc/c/c-typeck.c
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/cp-gimplify.c
branches/gcc-9-branch/gcc/cp/parser.c
branches/gcc-9-branch/gcc/cp/semantics.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:43:16 2019
New Revision: 277252

URL: https://gcc.gnu.org/viewcvs?rev=277252=gcc=rev
Log:
Backported from mainline
2019-09-27  Jakub Jelinek  

PR middle-end/91920
* gimplify.c (omp_default_clause): Predetermine DECL_IN_CONSTANT_POOL
variables as shared.

* c-c++-common/gomp/pr91920.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/c-c++-common/gomp/pr91920.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/gimplify.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89435] [7/8/9 Regression] wrong code with -O1 -march=armv4 -fno-forward-propagate with __builtin_sub_overflow()

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:42:37 2019
New Revision: 277251

URL: https://gcc.gnu.org/viewcvs?rev=277251=gcc=rev
Log:
Backported from mainline
2019-09-11  Jakub Jelinek  

PR rtl-optimization/89435
PR rtl-optimization/89795
PR rtl-optimization/91720
* gcc.dg/pr89435.c: New test.
* gcc.dg/pr89795.c: New test.
* gcc.dg/pr91720.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr89435.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr89795.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr91720.c
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91720] [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:42:37 2019
New Revision: 277251

URL: https://gcc.gnu.org/viewcvs?rev=277251=gcc=rev
Log:
Backported from mainline
2019-09-11  Jakub Jelinek  

PR rtl-optimization/89435
PR rtl-optimization/89795
PR rtl-optimization/91720
* gcc.dg/pr89435.c: New test.
* gcc.dg/pr89795.c: New test.
* gcc.dg/pr91720.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr89435.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr89795.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr91720.c
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/91723] [9 Regression] builtin fma is not optimized or vectorized as *+

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:41:40 2019
New Revision: 277250

URL: https://gcc.gnu.org/viewcvs?rev=277250=gcc=rev
Log:
Backported from mainline
2019-09-11  Jakub Jelinek  

PR tree-optimization/91723
* tree-vect-stmts.c (vectorizable_call): Use types_compatible_p check
instead of pointer equality when checking if argument vectypes are
the same.

* gcc.dg/vect/vect-fma-3.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/vect-fma-3.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-vect-stmts.c

[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:42:37 2019
New Revision: 277251

URL: https://gcc.gnu.org/viewcvs?rev=277251=gcc=rev
Log:
Backported from mainline
2019-09-11  Jakub Jelinek  

PR rtl-optimization/89435
PR rtl-optimization/89795
PR rtl-optimization/91720
* gcc.dg/pr89435.c: New test.
* gcc.dg/pr89795.c: New test.
* gcc.dg/pr91720.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr89435.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr89795.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr91720.c
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/91665] [8/9 Regression] ICE in build_vector_from_val, at tree.c:1904

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:40:48 2019
New Revision: 277249

URL: https://gcc.gnu.org/viewcvs?rev=277249=gcc=rev
Log:
Backported from mainline
2019-09-07  Jakub Jelinek  

PR tree-optimization/91665
* tree-vect-loop.c (vectorizable_reduction): Punt if base has type
incompatible with the type of PHI result.

* gcc.dg/vect/pr91665.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/pr91665.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-vect-loop.c

[Bug target/91106] internal compiler error: output_operand: invalid use of register 'frame'

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:39:53 2019
New Revision: 277248

URL: https://gcc.gnu.org/viewcvs?rev=277248=gcc=rev
Log:
Backported from mainline
2019-09-06  Jakub Jelinek  

* function.c (assign_parm_find_data_types): Use RECORD_OR_UNION_TYPE_P
before testing TYPE_TRANSPARENT_AGGR.
* calls.c (initialize_argument_information, load_register_parameters):
Likewise.

2019-09-05  Jakub Jelinek  

PR middle-end/91001
PR middle-end/91105
PR middle-end/91106
* calls.c (load_register_parameters): For TYPE_TRANSPARENT_AGGR
types, use type of their first field instead of type of
args[i].tree_value.

* gcc.c-torture/compile/pr91001.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/pr91001.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/calls.c
branches/gcc-9-branch/gcc/function.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/91105] internal compiler error: maximum number of generated reload insns per insn achieved (90)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:39:53 2019
New Revision: 277248

URL: https://gcc.gnu.org/viewcvs?rev=277248=gcc=rev
Log:
Backported from mainline
2019-09-06  Jakub Jelinek  

* function.c (assign_parm_find_data_types): Use RECORD_OR_UNION_TYPE_P
before testing TYPE_TRANSPARENT_AGGR.
* calls.c (initialize_argument_information, load_register_parameters):
Likewise.

2019-09-05  Jakub Jelinek  

PR middle-end/91001
PR middle-end/91105
PR middle-end/91106
* calls.c (load_register_parameters): For TYPE_TRANSPARENT_AGGR
types, use type of their first field instead of type of
args[i].tree_value.

* gcc.c-torture/compile/pr91001.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/pr91001.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/calls.c
branches/gcc-9-branch/gcc/function.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:39:53 2019
New Revision: 277248

URL: https://gcc.gnu.org/viewcvs?rev=277248=gcc=rev
Log:
Backported from mainline
2019-09-06  Jakub Jelinek  

* function.c (assign_parm_find_data_types): Use RECORD_OR_UNION_TYPE_P
before testing TYPE_TRANSPARENT_AGGR.
* calls.c (initialize_argument_information, load_register_parameters):
Likewise.

2019-09-05  Jakub Jelinek  

PR middle-end/91001
PR middle-end/91105
PR middle-end/91106
* calls.c (load_register_parameters): For TYPE_TRANSPARENT_AGGR
types, use type of their first field instead of type of
args[i].tree_value.

* gcc.c-torture/compile/pr91001.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/pr91001.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/calls.c
branches/gcc-9-branch/gcc/function.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/91632] [10 Regression] Probably wrong code since r275026

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:39:04 2019
New Revision: 277247

URL: https://gcc.gnu.org/viewcvs?rev=277247=gcc=rev
Log:
Backported from mainline
2019-09-02  Jakub Jelinek  

PR tree-optimization/91632
* gcc.c-torture/execute/pr91632.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91632.c
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/91623] [7/8/9 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:38:37 2019
New Revision: 277246

URL: https://gcc.gnu.org/viewcvs?rev=277246=gcc=rev
Log:
Backported from mainline
2019-09-01  Jakub Jelinek  

PR middle-end/91623
* optabs.c (expand_vec_cond_expr): If op0 is a VECTOR_CST and only
EQ_EXPR/NE_EXPR is supported, verify that op0 only contains
zeros or negative elements and use NE_EXPR instead of LT_EXPR against
zero vector.

* gcc.target/i386/pr91623.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91623.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/optabs.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug lto/91572] [9 Regression] lto1: error: type variant has different ‘TREE_TYPE’ since r269862

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:37:41 2019
New Revision: 277245

URL: https://gcc.gnu.org/viewcvs?rev=277245=gcc=rev
Log:
Backported from mainline
2019-09-01  Jakub Jelinek  

PR lto/91572
* tree.c (find_decls_types_in_node): Also walk TREE_PURPOSE of
GIMPLE_ASM TREE_LIST operands.

* g++.dg/lto/pr91572_0.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/lto/pr91572_0.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree.c

[Bug tree-optimization/91351] [9 Regression] -fstrict-enums generates incorrect code

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:36:36 2019
New Revision: 277244

URL: https://gcc.gnu.org/viewcvs?rev=277244=gcc=rev
Log:
Backported from mainline
2019-09-02  Jakub Jelinek  

PR go/91617
* fold-const.c (range_check_type): For enumeral and boolean
type, pass 1 to type_for_size langhook instead of
TYPE_UNSIGNED (etype).  Return unsigned_type_for result whenever
etype isn't TYPE_UNSIGNED INTEGER_TYPE.
(build_range_check): Don't call unsigned_type_for for pointer types.
* match.pd (X / C1 op C2): Don't call unsigned_type_for on
range_check_type result.

2019-08-29  Jakub Jelinek  

PR tree-optimization/91351
* tree-cfg.c (generate_range_test): Use range_check_type instead of
unsigned_type_for.
* tree-cfgcleanup.c (convert_single_case_switch): Punt if
range_check_type returns NULL.
* tree-switch-conversion.c (switch_conversion::build_one_array):
Use range_check_type instead of unsigned_type_for, don't perform
linear opt if it returns NULL.
(bit_test_cluster::find_bit_tests): Formatting fix.
(bit_test_cluster::emit): Use range_check_type instead of
unsigned_type_for.
(switch_decision_tree::try_switch_expansion): Punt if range_check_type
returns NULL.

* g++.dg/opt/pr91351.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/opt/pr91351.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/fold-const.c
branches/gcc-9-branch/gcc/match.pd
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-cfg.c
branches/gcc-9-branch/gcc/tree-cfgcleanup.c
branches/gcc-9-branch/gcc/tree-switch-conversion.c

[Bug go/91617] [10 regression] Many go test case failures after r275026

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:36:36 2019
New Revision: 277244

URL: https://gcc.gnu.org/viewcvs?rev=277244=gcc=rev
Log:
Backported from mainline
2019-09-02  Jakub Jelinek  

PR go/91617
* fold-const.c (range_check_type): For enumeral and boolean
type, pass 1 to type_for_size langhook instead of
TYPE_UNSIGNED (etype).  Return unsigned_type_for result whenever
etype isn't TYPE_UNSIGNED INTEGER_TYPE.
(build_range_check): Don't call unsigned_type_for for pointer types.
* match.pd (X / C1 op C2): Don't call unsigned_type_for on
range_check_type result.

2019-08-29  Jakub Jelinek  

PR tree-optimization/91351
* tree-cfg.c (generate_range_test): Use range_check_type instead of
unsigned_type_for.
* tree-cfgcleanup.c (convert_single_case_switch): Punt if
range_check_type returns NULL.
* tree-switch-conversion.c (switch_conversion::build_one_array):
Use range_check_type instead of unsigned_type_for, don't perform
linear opt if it returns NULL.
(bit_test_cluster::find_bit_tests): Formatting fix.
(bit_test_cluster::emit): Use range_check_type instead of
unsigned_type_for.
(switch_decision_tree::try_switch_expansion): Punt if range_check_type
returns NULL.

* g++.dg/opt/pr91351.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/opt/pr91351.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/fold-const.c
branches/gcc-9-branch/gcc/match.pd
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-cfg.c
branches/gcc-9-branch/gcc/tree-cfgcleanup.c
branches/gcc-9-branch/gcc/tree-switch-conversion.c

[Bug c/91401] schedule + dist_schedule clauses rejected on distribute parallel for

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 21 11:35:09 2019
New Revision: 277243

URL: https://gcc.gnu.org/viewcvs?rev=277243=gcc=rev
Log:
Backported from mainline
2019-08-09  Jakub Jelinek  

PR c/91401
* c-parser.c (c_parser_omp_clause_dist_schedule): Fix up typos in the
check_no_duplicate_clause call.  Comment it out, instead emit a
warning for duplicate dist_schedule clauses.

* parser.c (cp_parser_omp_clause_dist_schedule): Comment out the
check_no_duplicate_clause call, instead emit a warning for duplicate
dist_schedule clauses.

* c-c++-common/gomp/pr91401-1.c: New test.
* c-c++-common/gomp/pr91401-2.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/c-c++-common/gomp/pr91401-1.c
branches/gcc-9-branch/gcc/testsuite/c-c++-common/gomp/pr91401-2.c
Modified:
branches/gcc-9-branch/gcc/c/ChangeLog
branches/gcc-9-branch/gcc/c/c-parser.c
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/parser.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/92161] [10 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92161] [10 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 21 11:32:25 2019
New Revision: 277240

URL: https://gcc.gnu.org/viewcvs?rev=277240=gcc=rev
Log:
2019-10-21  Richard Biener  

PR tree-optimization/92161
* tree-vect-loop.c (vect_analyze_loop_2): Reset stmts def-type
for reductions.

* gfortran.dg/pr92161.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr92161.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug inline-asm/92151] Spurious register copying

[gcc at gmch dot uk]

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

Chris Hall  changed:

   What|Removed |Added

 CC||gcc at gmch dot uk

--- Comment #2 from Chris Hall  ---
(In reply to Richard Biener from comment #1)
> I wonder if it's better to put all of the assembler into a single asm() ...
> (or write actual assembly rather than using inline-asm).

In this case, yes -- I now declare the function "naked" and avoid the issue.

However, I have some functions which are designed to be always be inlined, and
which have a "hot" part and one or more "cold" parts.  For those (I believe) I
still need to use __asm__ goto() etc.

Further, I wonder if what I see with inline __asm__ is a symptom of some more
general register allocation funkiness.

[Bug tree-optimization/92163] [10 Regression] ICE: Segmentation fault (in bitmap_set_bit)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c/92164] Wrong result using builtin rint/rintf optimization in x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Did you compile with -frounding-math?

[Bug tree-optimization/92162] [10 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
mine I bet

[Bug tree-optimization/92152] [10 Regression] Wrong code (Resurrection of PR53663)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
OK, so this happens in visit_reference_op_store which hits

  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Store matched earlier value, "
 "value numbering store vdefs to matching vuses.\n");

  changed |= set_ssa_val_to (vdef, SSA_VAL (vuse));

where I actually wondered if I could trigger wrong-code with it.  The
counter-measure is

  /* If the TBAA state isn't compatible for downstream reads
 we cannot value-number the VDEFs the same.  */
  alias_set_type set = get_alias_set (lhs);
  if (vnresult->set != set
  && ! alias_set_subset_of (set, vnresult->set))
resultsame = false;

but here we have v.i and v.f both of which get the alias-set of the union.

We later disambiguate u.i against *f via aliasing_component_refs_p which
correctly assesses that if u.i is the active union member then the load
via *f cannot alias it.

On x86_64 we optimize away the v.f store as redundant but then still
don't CSE because somehow aliasing_component_refs_p doesn't get it in
the case both fields are not of the same size.

So I'm not entirely sure it isn't aliasing_component_refs_p that is to blame.
At least it should make the testcase also fail on x86_64...

Honza?

[Bug c/92164] Wrong result using builtin rint/rintf optimization in x86_64

[steffen-schmidt at siemens dot com]

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

--- Comment #1 from Steffen Schmidt  ---
Created attachment 47072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47072=edit
Test result output text.