[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[xry111 at mengyan1223 dot wang]

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

--- Comment #42 from Xi Ruoyao  ---
I just sent a patch making symver attribute "really" useful for LTO.

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01162.html

[Bug c++/92968] New: C style struct initialization fail to compile in g++ when initializing array fields

[mytbk920423 at gmail dot com]

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

Bug ID: 92968
   Summary: C style struct initialization fail to compile in g++
when initializing array fields
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mytbk920423 at gmail dot com
  Target Milestone: ---

The following program cannot be compiled with g++ but can be compiled with
clang++ or any C compiler including gcc.

typedef struct AStruct
{
int a[2];
} AStruct;

int main()
{
AStruct t0 = { .a[0] = 5 };
}

[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
I cannot reproduce it anymore as of r279405.

[Bug fortran/92967] New: ICE in matching_typebound_op, at fortran/interface.c:4214

[asolokha at gmx dot com]

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

Bug ID: 92967
   Summary: ICE in matching_typebound_op, at
fortran/interface.c:4214
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-10.0.0-alpha20191215 snapshot (r279405) ICEs when compiling the
following testcase reduced from test/semantics/modfile35.f90 from the f18 test
suite:

module uu
  type :: kn
   contains
 generic :: operator(+) => sk
  end type kn
contains
  subroutine pk(hg, zu, c5)
class(kn) :: hg
integer :: zu
integer :: c5(hg + zu)
  end subroutine pk
end module uu

% powerpc-e300c3-linux-gnu-gfortran-10.0.0-alpha20191215 -c yi0ak79e.f90
f951: internal compiler error: in matching_typebound_op, at
fortran/interface.c:4214
0x5729ae matching_typebound_op
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/interface.c:4214
0x838a04 gfc_extend_expr(gfc_expr*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/interface.c:4330
0x89eb8b resolve_operator
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:4382
0x89c347 gfc_resolve_expr(gfc_expr*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:6992
0x89c347 gfc_resolve_expr(gfc_expr*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:6961
0x7f0e62 resolve_array_bound
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/array.c:377
0x7f1bd0 gfc_resolve_array_spec(gfc_array_spec*, int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/array.c:421
0x8a47d7 resolve_formal_arglist
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:341
0x8c10b2 do_traverse_symtree
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/symbol.c:4165
0x8a501c resolve_formal_arglists
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:563
0x8a501c resolve_contained_functions
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:1129
0x8a501c resolve_types
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:17093
0x89690e gfc_resolve(gfc_namespace*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:17219
0x89690e gfc_resolve(gfc_namespace*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/resolve.c:17200
0x8880cb gfc_parse_file()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/parse.c:6443
0x8d6d9e gfc_be_parse_file
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/fortran/f95-lang.c:210

(While my target here is powerpc, the ICE is not target-specific.)

[Bug c++/92966] New: Segfault on defaulted operator== with wrong return type

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 92966
   Summary: Segfault on defaulted operator== with wrong return
type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

cat >test.cc  for instructions.

[Bug c++/92965] New: "note: 'x' is not public" emitted even when no error is emitted

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 92965
   Summary: "note: 'x' is not public" emitted even when no error
is emitted
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

cat >test.cc <
class TS {
int x;
public:
constexpr TS(int) {}
};
TS(int) -> TS<1>;

template void foo() {}  // #1
template void foo() {}  // #2

void test() { foo<2>(); }
EOF
g++ -std=c++2a test.cc

test.cc: In function 'void test()':
test.cc:4:9: note: 'TS<1>::x' is not public
4 | int x;
  | ^

What's happening here is that the compiler is attempting to substitute into foo
#1, failing because TS<1> is not a structural type, emitting the note
explaining why TS<1> is not structural, and then proceeding to try foo #2,
which works fine and therefore the original error about foo #1 is suppressed
and never emitted. So the note is just hanging out there on its own, in an
otherwise successful compile.

I assume GCC has some mechanism to push/defer diagnostics in a SFINAE context,
and the mechanism simply wasn't applied to this new note.

[Bug c++/92495] spaceship operator requires public member

[arthur.j.odwyer at gmail dot com]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #2 from Arthur O'Dwyer  ---
FWIW, my understanding is that the current failure-to-compile is correct: GCC
is implementing P1907 which requires all data members to be public (and does
*not* any longer require operator<=> to be defined) in order for you to use a
user-defined type as a NTTP.
Wilhelm's code was valid circa N4835, but is not supposed to be valid
post-P1907.

[Bug c++/61339] add mismatch between struct and class [-Wmismatched-tags] to non-bugs

[msebor at gcc dot gnu.org]

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

--- Comment #15 from Martin Sebor  ---
(In reply to Eric Gallager from comment #14)

The patch that implements -Wmismatched-tags is still in review.  Here's the
latest: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01154.html

[Bug target/92651] [10 Regression] Unnecessary stv transform in some x86 backend

[wwwhhhyyy333 at gmail dot com]

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

Hongyu Wang  changed:

   What|Removed |Added

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

--- Comment #10 from Hongyu Wang  ---
Fixed on GCC 10.

[Bug target/92651] [10 Regression] Unnecessary stv transform in some x86 backend

[liuhongt at gcc dot gnu.org]

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

--- Comment #9 from liuhongt at gcc dot gnu.org ---
Author: liuhongt
Date: Tue Dec 17 01:50:35 2019
New Revision: 279452

URL: https://gcc.gnu.org/viewcvs?rev=279452=gcc=rev
Log:
Add abs pattern to handle {si,di} mode abs to avoid pmax/cmove conversion.

2019-12-17  Hongyu Wang  

gcc/
PR target/92651
* config/i386/i386.h (TARGET_EXPAND_ABS): New macro.
* config/i386/x86-tune.def (X86_TUNE_EXPAND_ABS): New.
* config/i386/i386.md (abs2): New define_expand.

gcc/testsuite
* gcc.target/i386/pr92651.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr92651.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/x86-tune.def
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/88739] [7 Regression] Big-endian union bug

[pinskia at gcc dot gnu.org]

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

--- Comment #63 from Andrew Pinski  ---
Note match.pd has a similar bug.  Here is the patch which fixes it:
diff --git a/gcc/match.pd b/gcc/match.pd
index 92b93b0..8607abe 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5676,16 +5676,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   isize = tree_to_uhwi (TYPE_SIZE (TREE_TYPE (@1)));
   }
   (switch
-   (if (wi::leu_p (wi::to_wide (@ipos), wi::to_wide (@rpos))
+   (if ((!INTEGRAL_TYPE_P (TREE_TYPE (@1)) || type_has_mode_precision_p
(TREE_TYPE (@1)))
+&& wi::leu_p (wi::to_wide (@ipos), wi::to_wide (@rpos))
&& wi::leu_p (wi::to_wide (@rpos) + wi::to_wide (@rsize),
  wi::to_wide (@ipos) + isize))
 (BIT_FIELD_REF @1 @rsize { wide_int_to_tree (bitsizetype,
  wi::to_wide (@rpos)
 - wi::to_wide (@ipos)); }))
-   (if (wi::geu_p (wi::to_wide (@ipos),
-  wi::to_wide (@rpos) + wi::to_wide (@rsize))
-   || wi::geu_p (wi::to_wide (@rpos),
- wi::to_wide (@ipos) + isize))
+   (if ((!INTEGRAL_TYPE_P (TREE_TYPE (@0)) || type_has_mode_precision_p
(TREE_TYPE (@0)))
+ && (wi::geu_p (wi::to_wide (@ipos),
+   wi::to_wide (@rpos) + wi::to_wide (@rsize))
+|| wi::geu_p (wi::to_wide (@rpos),
+  wi::to_wide (@ipos) + isize)))
 (BIT_FIELD_REF @0 @rsize @rpos)

 (if (canonicalize_math_after_vectorization_p ())

- CUT 
The second part should not be needed as the first operand to BIT_INSERT_EXPR
should always be type_has_mode_precision_p; though I have not looked to make
sure that is the case.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[liuhongt at gcc dot gnu.org]

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

--- Comment #6 from liuhongt at gcc dot gnu.org ---
Author: liuhongt
Date: Tue Dec 17 01:29:09 2019
New Revision: 279451

URL: https://gcc.gnu.org/viewcvs?rev=279451=gcc=rev
Log:
Use add for a = a + b and a = b + a when possible.
Since except for Bonnell,

01 fb   add%edi,%ebx

is faster and shorter than

8d 1c 1flea(%rdi,%rbx,1),%ebx

we should use add for a = a + b and a = b + a when possible if not
optimizing for Bonnell.

Tested on x86-64.

2019-12-17  H.J. Lu  

gcc/

PR target/92807
* config/i386/i386.c (ix86_lea_outperforms): Check !TARGET_BONNELL.
(ix86_avoid_lea_for_addr): When not optimizing for Bonnell, use add
for a = a + b and a = b + a.

gcc/testsuite/

PR target/92807
* gcc.target/i386/pr92807-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr92807-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/91165] [10 Regression] error: location references block not in block tree

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Mon Dec 16 23:25:08 2019
New Revision: 279447

URL: https://gcc.gnu.org/viewcvs?rev=279447=gcc=rev
Log:
PR c++/91165 - verify_gimple ICE with cached constexpr.

It seems we need to unshare even non-CONSTRUCTOR expressions that we are
going to stick in the constexpr_call_table, so we don't end up sharing the
same e.g. ADDR_EXPR between two different functions.  I now think I
understand why unsharing CONSTRUCTOR arguments was improving memory
performance: separating the arguments from the caller function allows the
caller function to be GC'd better.  But it occurs to me that we don't need
to unshare until we decide that we're evaluating and caching this call, so
we can avoid the CONSTRUCTOR unshare/free pair for tentative arguments.
Freeing the tentative TREE_VEC still seems worth doing, so free_bindings
isn't going away entirely.

* constexpr.c (cxx_bind_parameters_in_call): Don't unshare.
(cxx_eval_call_expression): Unshare all args if we're caching.

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

[Bug c++/92859] compiler treats enum type as an integer during overload resolution when a bit-field of this enum is considered

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Dec 16 23:23:43 2019
New Revision: 279446

URL: https://gcc.gnu.org/viewcvs?rev=279446=gcc=rev
Log:
PR c++/92859 - ADL and bit-field.

We also need unlowered_expr_type when considering associated types for ADL.

* name-lookup.c: Use unlowered_expr_type.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/overload/bit-field1.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/name-lookup.c

[Bug middle-end/92210] no warning for invariable used in loop condition

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end

--- Comment #2 from Martin Sebor  ---
Clang also diagnoses more interesting cases where the control variable is used
so if GCC implements a similar warning (which I agree would be useful) it
should handle those as well.  Such an implementation would most likely need to
be done later than in the front-end, so setting Component to middle-end.

void f (int);

int main()
{
  for (int i = 0; i < 2; )
  {
f (i);
  }
}

[Bug middle-end/92952] [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
*** Bug 92956 has been marked as a duplicate of this bug. ***

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Thanks!  Yes, the code made the incorrect assumption that array indices were
zero-based.  I just committed r279445 with a fix so I'm going to assume it
takes care of these warnings as well as will resolve this as a duplicate.

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

[Bug middle-end/92952] [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
This should be fixed now.

[Bug middle-end/92952] [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Mon Dec 16 22:24:15 2019
New Revision: 279445

URL: https://gcc.gnu.org/viewcvs?rev=279445=gcc=rev
Log:
PR middle-end/92952 - gfortran.dg/lto/pr87689 FAILs at -O2

gcc/ChangeLog:
* builtins.c (compute_objsize): Adjust offset by the array low bound.

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

[Bug tree-optimization/92963] Optimization with `restrict`: is `p == q ? p : q` "based" on `p`?

[ch3root at openwall dot com]

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

--- Comment #2 from Alexander Cherepanov  ---
> p cannot be q as they cannot be based on each other based on my reading of
> 6.7.3.1p3.

Perhaps something like that was intended at some point but I don't see it in
the text. Until you start analyzing actual accesses you cannot draw any
conclusions about values of p and q. Example 3 in the formal definition of
restrict (C11, 6.7.3.1p10) specifically illustrates the case of two equal
restricted pointers.

[Bug c++/92964] New: order of base class members generates vastly different code

[john at drouhard dot dev]

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

Bug ID: 92964
   Summary: order of base class members generates vastly different
code
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john at drouhard dot dev
  Target Milestone: ---

Created attachment 47510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47510=edit
reproducible c++ source

I'm new at submitting bug reports, sorry if this one is invalid.D

I have attached a repro file that actually exhibits what I believe to be two
issues, but I'm unsure of the second. If I need to open a second report for it
(or if it's really not a problem) just let me know. I've reproduced this
behavior on gcc 8.3, gcc 9.2, and gcc trunk.

Godbolt link if interested: https://godbolt.org/z/F756Pe

Anyway, looking at the generated assembly when compiling the program with
-std=c++17 -O2 (and -O3) seems to indicate a missed optimization of some kind.

bar1() and bar3() are equivalent, other than the order of the union and the
bool in the base storage class. I believe gcc should be able to generate
basically the same assembly as well (other than swapping %rax/%rdx), but bar3
utilizes the stack, even using SIMD instructions for the false branch. bar1
doesn't do this. clang generates equivalent code for bar1/bar3.

I'm assuming it has something to do with alignment, but what's strange is that
if the intermediary Payload class is bypassed by using a PayloadBase directly
in Foo<>, bar1 and bar3 are generated (almost) equivalently as expected (no
SIMD instructions or stack usage).



The other issue (please let me know if I should just open another report or if
this is expected), is the difference between bar1/bar2 and bar3/bar4. They only
differ in how they return the Foo<> object. bar1/bar3 return a default
constructed Foo<>, but bar2/bar4 return a sentinel and rely on converting to
Foo<> using the user-defined constructor. Generated assembly for these pairs of
functions are very different (at least at -O2 optimization).

With the -O2 level optimization, bar2 does not set %rdx in the false branch
(bar1 does). clang sets it in both. I realize it's not strictly necessary to
ensure that a value is returned in %rdx since the empty union member is the one
being initialized, but bar1 takes care to make sure it's set to 0 (as does
clang for both). Bumping the optimization level up to -O3 actually causes bar2
to ensure both are set to 0 explicitly.

bar3 and bar4, however, both intentionally populate %rax with uninitialized
junk from the stack in the false branch (both -O2 and -O3), though it's clearer
in bar4 since it doesn't use SIMD instructions there (related to the first
point?) If initializing %rax isn't necessary, why does it move memory from the
uninitialized stack into the return register at all?

I apologize if this is not well-thought-out or if there's something obvious I'm
missing. Let me know if you need me to provide any more information.

[Bug tree-optimization/92963] Optimization with `restrict`: is `p == q ? p : q` "based" on `p`?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Take:

if (p == q)
r = p;
else
r = q;

p cannot be q as they cannot be based on each other based on my reading of
6.7.3.1p3.

Therefore r is only ever based on q.

[Bug fortran/91651] [F03] Implement KIND argument for INDEX

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug tree-optimization/92963] New: Optimization with `restrict`: is `p == q ? p : q` "based" on `p`?

[ch3root at openwall dot com]

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

Bug ID: 92963
   Summary: Optimization with `restrict`: is `p == q ? p : q`
"based" on `p`?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

The question: is `p == q ? p : q` "based" on `p` (as in C11, 6.7.3.1p3)?

First, suppose that the answer is "yes". Then the following program should be
strictly conforming and should always print "2":

--
#include 

__attribute__((__noinline__)) // imagine it in a separate TU
static int f(int *restrict p, int *restrict q)
{
*p = 1;

int *r;
if (p == q)
r = p;
else
r = q;

// is r "based" on p?

*r = 2;

return *p;
}

int main()
{
int x;
printf("%d\n", f(, ));
}
--
$ gcc -std=c11 test.c && ./a.out
2
$ gcc -std=c11 -O3 test.c && ./a.out
1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191216 (experimental)
--

Ok, fair enough, `p == q ? p : q` is always equal to `q`, doesn't change when
`p` changes and, thus, is not "based" on `p`.
Then the following program (3 differences are marked) should be fine according
to the standard and should always print "2":

--
#include 

__attribute__((__noinline__)) // imagine it in a separate TU
static int f(int *restrict p, int *restrict q)
{
*q = 1; // 1) changed p -> q

int *r;
if (p == q)
r = p;
else
r = q;

// is r "based" on p?

if (p == q) // 2) added if
*r = 2;

return *q; // 3) changed p -> q
}

int main()
{
int x;
printf("%d\n", f(, ));
}
--
$ gcc -std=c11 test.c && ./a.out
2
$ gcc -std=c11 -O3 test.c && ./a.out
1
--

Either way, there is a problem...

[Bug target/92962] Documentation: x86 Options - znver2 missing RDPID and WBNOINVD

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to kim.walisch from comment #0)
> GCC should definitely not warn when using constants from . GCC
> should also provide an option to disable these warnings (e.g.
> -Wno-non-standard-suffix). People are currently using disgusting hacks to
> avoid these warnings so please add an option for that.

Also, adding a new warning option is relatively easy:

1. Add the option to gcc/c-family/c.opt
2. Edit the point of the warning to use the new option
3. Add documentation for the option in gcc/doc/invoke.texi
4. Add/update existing tests to test for the option

See also:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Manuel López-Ibáñez  ---
The fact that GCC points to column 5 suggest that the location info is wrong.
If the location info was correct, then __extension__, #pragma diagnostic
ignore, and #pragma system_headers will work.

The first step to fix this is to figure out why the column location is wrong
(it should point to FLT128_MIN):

https://dmalcolm.fedorapeople.org/gcc/newbies-guide/how-to-improve-the-location-of-a-diagnostic.html

[Bug c/92479] missing warnings for unreachable codes with -Wunreachable-code

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2019-12-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Manuel López-Ibáñez  ---
This should be suspended until someone comes up with a proposal for reviving
-Wunreachable that is supported by GCC developers. Having bugs lying around in
UNCONFIRMED or NEW may give the impression that a quick-and-dirty solution may
be acceptable, which is not the case. Any proposed solution must solve the
problems that led to the removal of the previous -Wunreachable-code.

[Bug c/92392] -Wignored-qualifiers points to wrong location and doesn't mention which qualifiers

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
 CC||manu at gcc dot gnu.org
Summary|-Wignored-qualifiers points |-Wignored-qualifiers points
   |to diff location|to wrong location and
   ||doesn't mention which
   ||qualifiers

--- Comment #2 from Manuel López-Ibáñez  ---
Confirmed. This is probably just a matter of keeping track of the qualifiers. I
believe we already do that for duplicated "const". Mentioning the qualifiers
that are ignored should be a matter of passing this info to the warning point.

Easyhack: https://gcc.gnu.org/wiki/EasyHacks

Bonus points for adding a fix-it hint to remove the qualifier.

[Bug other/92962] New: Documentation: x86 Options - znver2 missing RDPID and WBNOINVD

[aklhfex at gmail dot com]

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

Bug ID: 92962
   Summary: Documentation: x86 Options - znver2 missing RDPID and
WBNOINVD
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aklhfex at gmail dot com
  Target Milestone: ---

RDPID and WBNOINVD were added as part of znver2 in:

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/common/config/i386/i386-common.c;h=ff13ea5f69f364c1210badc9452cf4ec44235175;hp=f12806ef3a91ce9881d8d37fcda0ee1d28559566;hb=703d2f69fad4772dc4aedb5327b5e3d88e8e1843;hpb=0acb32e2c782816e9552e0b8855181d9fe7b196f

but not included when znver2 was added to the x86 options documentation:

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/doc/invoke.texi;h=1743c64582e90896dc3841833ed3e0c873f8fd0c;hp=e290128f535f3e6b515bff5a81fae0aa0d1c8baf;hb=703d2f69fad4772dc4aedb5327b5e3d88e8e1843;hpb=0acb32e2c782816e9552e0b8855181d9fe7b196f

They are listed for various Intel types on that page.

N.B. an extra comma was added in front of CLWB for zenver2 in the same commit.

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Created attachment 47508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47508=edit
-fdump-tree-strlen dump of gcc/testsuite/gfortran.dg/lto/pr87689_*.f

As requested, the output of:
$ gfortran-trunk -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
gfortran.dg/lto/pr87689_* -fdump-tree-strlen
$ head -n 20 pr87689_0.f.180t.strlen1 pr87689_1.f.180t.strlen1 >
strlen.txt


I think the following causes the confusion:
  character(kind=1)[1:1] & restrict c,
  …  
  _7 = (*c_15(D))[1]{lb: 1 sz: 1};

'c' is a string of length 1 but the lower bound is also 1, hence "c[1]"
accesses the first element of the string.

I wonder whether you case assumes that the lower bound is always 0? – On the
other hand, this issue only appears with inlining (and the specified LTO
options), w/o there is no warning.

[Bug c/92209] Imprecise column number for -Wstrict-prototypes

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
The key here is to add the fix-hit hint more appropriate for the function
declaration. Clang is not smart enough here, when you try with:

static int func_1();
int func_1(int a) { return a; }

Perhaps change the text to say: "a function prototype must specify the argument
types" ?

Either way, it should be easy to fix for a new contributor.

[Bug fortran/92961] [8/9/10 Regression] ICE in gfc_zero_size_array, at fortran/arith.c:1680

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

And when involving such an array, e.g.


$ cat z2.f90
subroutine s
   integer :: a(0/(0))
   integer :: b = ubound(a,1)
end


$ gfortran-10-20191215 -c z2.f90
f951: internal compiler error: Segmentation fault
0xb8147f crash_signal
../../gcc/toplev.c:328
0x62e560 gfc_numeric_ts(gfc_typespec*)
../../gcc/fortran/expr.c:891
0x6a24f0 resolve_operator
../../gcc/fortran/resolve.c:4022
0x69f967 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6992
0x5fa584 resolve_array_bound
../../gcc/fortran/array.c:377
0x5fb1b6 gfc_resolve_array_spec(gfc_array_spec*, int)
../../gcc/fortran/array.c:421
0x6b0856 simplify_bound_dim
../../gcc/fortran/simplify.c:4014
0x6b0c57 simplify_bound
../../gcc/fortran/simplify.c:4232
0x640357 do_simplify
../../gcc/fortran/intrinsic.c:4583
0x64aa78 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4848
0x630097 gfc_check_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2873
0x6305b7 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3053
0x633790 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3099
0x61f6e3 variable_decl
../../gcc/fortran/decl.c:2832
0x61f6e3 gfc_match_data_decl()
../../gcc/fortran/decl.c:6098
0x6815a3 match_word
../../gcc/fortran/parse.c:65
0x6815a3 decode_statement
../../gcc/fortran/parse.c:376
0x682fea next_free
../../gcc/fortran/parse.c:1279
0x682fea next_statement
../../gcc/fortran/parse.c:1511
0x68463b parse_spec
../../gcc/fortran/parse.c:3922

[Bug fortran/92961] New: [8/9/10 Regression] ICE in gfc_zero_size_array, at fortran/arith.c:1680

[gs...@t-online.de]

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

Bug ID: 92961
   Summary: [8/9/10 Regression] ICE in gfc_zero_size_array, at
fortran/arith.c:1680
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With an expression (0) :


$ cat z1.f90
program p
   integer :: a((0)/0)
   integer :: b(0/(0))
   integer :: c((0)/(0))
end


$ gfortran-5 -c z1.f90
z1.f90:2:17:

integer :: a((0)/0)
 1
Error: Division by zero at (1)
z1.f90:2:22:

integer :: a((0)/0)
  1
Error: The module or main program array 'a' at (1) must have constant shape
z1.f90:3:17:

integer :: b(0/(0))
 1
Error: Division by zero at (1)
z1.f90:3:22:

integer :: b(0/(0))
  1
Error: The module or main program array 'b' at (1) must have constant shape
z1.f90:4:17:

integer :: c((0)/(0))
 1
Error: Division by zero at (1)
z1.f90:4:24:

integer :: c((0)/(0))
1
Error: The module or main program array 'c' at (1) must have constant shape


$ gfortran-10-20191215 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb8147f crash_signal
../../gcc/toplev.c:328
0x5f6d9b gfc_zero_size_array
../../gcc/fortran/arith.c:1680
0x5f6d9b reduce_binary0
../../gcc/fortran/arith.c:1694
0x5f6d9b eval_intrinsic_f3
../../gcc/fortran/arith.c:1743
0x63139a simplify_intrinsic_op
../../gcc/fortran/expr.c:1196
0x63139a gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2201
0x61e611 variable_decl
../../gcc/fortran/decl.c:2565
0x61e611 gfc_match_data_decl()
../../gcc/fortran/decl.c:6098
0x6815a3 match_word
../../gcc/fortran/parse.c:65
0x6815a3 decode_statement
../../gcc/fortran/parse.c:376
0x682fea next_free
../../gcc/fortran/parse.c:1279
0x682fea next_statement
../../gcc/fortran/parse.c:1511
0x685394 parse_spec
../../gcc/fortran/parse.c:3738
0x68740c parse_progunit
../../gcc/fortran/parse.c:5848
0x688ae9 gfc_parse_file()
../../gcc/fortran/parse.c:6388
0x6d365f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/92885] [8/9/10 Regression] ICE (segfault) with allocatable coarrays

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #2 from G. Steinmetz  ---

Issue is similar to pr85002.
A complete backtrace is valuable and helpful.
Please allow me to adapt the names, they are just sound and smoke anyway :


$ cat z1.f90
program p
   type t
  character(:), allocatable :: s
   end type
   type t2
  type(t), allocatable :: sp(:)
   end type
   type(t2), allocatable :: t2s(:)[:]
   allocate (t2s(2)[*])
end


$ gfortran-10-20191215 -c z1.f90 -fcoarray=single
z1.f90:9:0:

9 |allocate (t2s(2)[*])
  |
internal compiler error: Segmentation fault
0xb8147f crash_signal
../../gcc/toplev.c:328
0x8c43d3 fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:11908
0x8c5fb3 fold_build3_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:12943
0x6ea9ed structure_alloc_comps
../../gcc/fortran/trans-array.c:9257
0x6eafbe structure_alloc_comps
../../gcc/fortran/trans-array.c:8692
0x6ec87f structure_alloc_comps
../../gcc/fortran/trans-array.c:9361
0x6eef63 gfc_copy_alloc_comp(gfc_symbol*, tree_node*, tree_node*, int, int)
../../gcc/fortran/trans-array.c:9812
0x705d1b gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:9685
0x7170cd gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11051
0x74c5b1 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:7033
0x6d6da7 trans_code
../../gcc/fortran/trans.c:2036
0x700124 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6891b6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6891b6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d365f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c/92210] no warning for invariable used in loop condition

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
This one would be useful to have and probably easy to implement based on
-Wunused-but-set-variable.

Easyhack: https://gcc.gnu.org/wiki/EasyHacks

[Bug c++/43361] missing uninitialized warning without optimization (-O0) (PHI in always_executed basic block)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||tangyixuan at mail dot 
dlut.edu.cn

--- Comment #12 from Manuel López-Ibáñez  ---
*** Bug 92118 has been marked as a duplicate of this bug. ***

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
(In reply to Martin Sebor from comment #2)
> -Wstringop-overflow is a C-family only option that shouldn't be enabled for
> Fortran.  It took some effort to make it work that way […] I wouldn't be
> surprised if the problem was still unresolved in LTO builds

Well, this uses LTO – but only behind the scenes. When doing offloading (via
OpenACC or OpenMP ["omp target"]), the blocks which are to be run on the device
will be processes by a lto1 compiler for the device target (amdgcn, nvptx), see
https://gcc.gnu.org/wiki/Offloading

> I don't see this test in my builds or on gcc-testresults and compiling it
> by hand gives the error below. […]
> Fatal Error: Cannot open module file ‘omp_lib.mod’ for reading at (1): No
> such file or directory

I think in order to reproduce Thomas' problem, I fear you need to configure the
compiler for actual offloading. (But see below.)

Still, I do not understand the error message. This file is part of libgomp and
installed along the compiler; in my case, it is in
$INSTALL/lib64/gcc/x86_64-pc-linux-gnu/10.0.0/finclude/ and should be found
automatically when calling 'gfortran'.

 * * *

Regarding a test case, I actually stumbled over a test case this afternoon
which fails without offloading. (There are 22 PASS and this one FAIL.) — I
don't know whether it is your commit, but the message looks very similar. In
any case:

FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin

Which fails with:

In function 'MAIN__',
inlined from 'main' at gcc/testsuite/gfortran.dg/lto/pr87689_0.f:13:0:
gcc/testsuite/gfortran.dg/lto/pr87689_0.f:10: warning: writing 1 byte into a
region of size 0 [-Wstringop-overflow=]
gcc/testsuite/gfortran.dg/lto/pr87689_0.f: In function 'main':
gcc/testsuite/gfortran.dg/lto/pr87689_0.f:7:22: note: at offset 1 to object 'c'
with size 1 declared here

The message is also bogus as one writes a single character to to a len=1
string.

[Bug fortran/92960] New: ICE tree check: expected tree that contains 'decl minimal' structure, have 'component_ref' in add_decl_as_local, at fortran/trans-decl.c:261

[gs...@t-online.de]

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

Bug ID: 92960
   Summary: ICE tree check: expected tree that contains 'decl
minimal' structure, have 'component_ref' in
add_decl_as_local, at fortran/trans-decl.c:261
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gfortran-8 :


$ cat z1.f90
program p
   type t(n)
  integer, len :: n
  character(n) :: c
   end type
   type(t(:)), allocatable :: z
   allocate (t(7) :: z)
   associate (y => z%c)
  ! print *, y
   end associate
end


$ gfortran-10-20191215 -c z1.f90
z1.f90:8:0:

8 |associate (y => z%c)
  |
internal compiler error: tree check: expected tree that contains 'decl minimal'
structure, have 'component_ref' in add_decl_as_local, at
fortran/trans-decl.c:261
0x5ef00f tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.c:9859
0x73e77d contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3387
0x73e77d add_decl_as_local
../../gcc/fortran/trans-decl.c:261
0x73e77d gfc_finish_var_decl
../../gcc/fortran/trans-decl.c:646
0x73d3de gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1829
0x740cbf generate_local_decl
../../gcc/fortran/trans-decl.c:5872
0x6f1dc2 do_traverse_symtree
../../gcc/fortran/symbol.c:4165
0x7358bf generate_local_vars
../../gcc/fortran/trans-decl.c:6078
0x7358bf gfc_process_block_locals(gfc_namespace*)
../../gcc/fortran/trans-decl.c:7089
0x7a7469 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2267
0x70b137 trans_code
../../gcc/fortran/trans.c:1960
0x7424cd gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6bc426 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6bc426 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x70742f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug middle-end/92118] warning with [-Wmaybe-uninitialized] in -O1

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez  ---
When reporting a Wuninitialized bug please check PR24639. 99% of the cases are
duplicated of an existing report.

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

[Bug fortran/85002] [8/9/10 Regression][Coarray] ICE in fold_ternary_loc, at fold-const.c:11360

[gs...@t-online.de]

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

--- Comment #5 from G. Steinmetz  ---

Please note that switching to a test-version (configured with
--enable-checking=yes) allows further reduction to another branch :


$ cat z7.f90
program p
   type t2
  integer, allocatable :: b(:)
   end type
   type(t2) :: y[*]
   y = t2([123])
end


$ gfortran-10-20191215 -c z7.f90 -fcoarray=single
z7.f90:1:0:

1 | program p
  |
Error: non-trivial conversion in 'var_decl'
struct array02_integer(kind=4)
struct array01_integer(kind=4)
t2.0.b = parm.2;
z7.f90:1:0: internal compiler error: 'verify_gimple' failed
0xd4efad verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5097
0xa1a055 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:14670
0xa1a344 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:14760
0x855fa7 cgraph_node::analyze()
../../gcc/cgraphunit.c:669
0x859335 analyze_functions
../../gcc/cgraphunit.c:1212
0x85a692 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2958

[Bug fortran/85002] [8/9/10 Regression][Coarray] ICE in fold_ternary_loc, at fold-const.c:11360

[gs...@t-online.de]

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

--- Comment #4 from G. Steinmetz  ---

Update, ICEs also with a scalar component "a" :


$ cat z2.f90
program p
   type t
  integer, allocatable :: a
   end type
   type t2
  type(t), allocatable :: b(:)
   end type
   type(t) :: x
   type(t2) :: y(2)[*]
   allocate (x%a)
   x%a = 123
   y = t2([x])
end


$ gfortran-10-20191215 -c z2.f90 -fcoarray=single
z2.f90:12:0:

   12 |y = t2([x])
  |
internal compiler error: Segmentation fault
0xb8147f crash_signal
../../gcc/toplev.c:328
0x8c43d3 fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:11908
0x8c5fb3 fold_build3_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:12943
0x6ea9ed structure_alloc_comps
../../gcc/fortran/trans-array.c:9257
0x6eafbe structure_alloc_comps
../../gcc/fortran/trans-array.c:8692
0x6ec87f structure_alloc_comps
../../gcc/fortran/trans-array.c:9361
0x6eef63 gfc_copy_alloc_comp(gfc_symbol*, tree_node*, tree_node*, int, int)
../../gcc/fortran/trans-array.c:9812
0x705d1b gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:9685
0x7170cd gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11051
0x6d6b97 trans_code
../../gcc/fortran/trans.c:1864
0x700124 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6891b6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6891b6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d365f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c/91839] missing error diagnosis for undeclared identifier

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to tangyixuan from comment #3)
> Error handler should not stop at the first error and report the errors as
> many as possible.

This is not possible in general as the error may cause a cascade of errors that
are only "errors" because of the first one. In that case, it is better to stop
so that the user knows which error is the actual important one to fix.

> Maybe it could be improved at some extent.

You are welcome to try:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

GCC will always need more contributors and you are very welcome to contribute
in this area if it is interesting for you.

However, existing GCC developers should better spend their time on other more
important bugs or features.

[Bug fortran/92959] ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

Whereas, directly :

$ cat z3.f90
program p
   character(:), pointer :: x, y
   print *, associated(x, y)
end

$ gfortran-10-20191215 z3.f90 && ./a.out
 F

[Bug c/91820] missing error diagnosis of '&' in initialization

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #6 from Manuel López-Ibáñez  ---
Not a bug per comment #5

[Bug fortran/92959] New: ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

[gs...@t-online.de]

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

Bug ID: 92959
   Summary: ICE in gfc_conv_associated, at
fortran/trans-intrinsic.c:8634
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gfortran-5 :


$ cat z1.f90
program p
   character(:), pointer :: x, y
   call s
contains
   subroutine s
  print *, associated(x, y)
   end
end


$ cat z2.f90
program p
   character, pointer :: x, y
   call s
contains
   subroutine s
  print *, associated(x, y)
   end
end


$ gfortran-10-20191215 -c z1.f90
z1.f90:6:0:

6 |   print *, associated(x, y)
  |
internal compiler error: Segmentation fault
0xb8147f crash_signal
../../gcc/toplev.c:328
0x71961b gfc_conv_associated
../../gcc/fortran/trans-intrinsic.c:8634
0x72ff85 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9844
0x70719a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8657
0x70e0f5 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:8802
0x736377 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2582
0x6d6e57 trans_code
../../gcc/fortran/trans.c:2084
0x733e5e build_dt
../../gcc/fortran/trans-io.c:2026
0x6d6e37 trans_code
../../gcc/fortran/trans.c:2056
0x700124 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6fff24 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5796
0x6fff24 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6733
0x6891b6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6891b6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d365f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
So, what I see that happens is that when processing that insn 97, insert_regs
calls make_regs_eqv (135, 131) and as pseudo 131 is live at the end of the bb
while pseudo 135 is not, 131 is selected as the canonical register for the
equivalence.
5968elt = insert (dest, sets[i].src_elt,
5969  sets[i].dest_hash, GET_MODE (dest));
afterwards stores the table entry, but under the pseudo 135, such as
lookup_for_remove (reg_135, HASH (reg_135), E_VOIDmode) is non-NULL and
contains
in ->exp reg_135 and in ->first_same_value->exp reg_131, while
lookup_for_remove (reg_131, HASH (reg_131), E_VOIDmode) is NULL.
Later on we process the 131 = 135 assignment, canonicalize_insn canonicalizes
that into 131 = 131 assignment (i.e. noop).
Later we invalidate_reg (reg_131) as the destination, which undoes the reg
equivalency, but as lookup_for_remove (reg_131, HASH (reg_131), E_VOIDmode)
used to be NULL, nothing is removed from the table.  And then insert_regs is
called again, and ICEs, because
1128  gcc_assert (REGNO_QTY_VALID_P (c_regno));
I'd think that invalidate_reg really should remove the traces of that pseudo
from the tables, wonder e.g. if the remove_pseudo_from_table call in
invalidate_reg couldn't be done before delete_reg_equiv and lookup_for_remove
use exp_equiv_p.  It does use it already for the !REG_P case, but I believe it
is never called with non-REG.

[Bug middle-end/92952] [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug middle-end/92952] [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-16
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
-Wstringop-overflow is enabled only for the C family of languages (and for LTO)
so it shouldn't be issued for Fortran code (see also pr80545).  I think the
problem might be making the distinction between languages during LTO builds.

I can reproduce the warning but have no idea how to actually step into the LTO
code.  My best guess is that the size computation doesn't account for the
non-zero low bound in Fortran arrays.  The following avoids the warning so let
me go with it.

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 279443)
+++ gcc/builtins.c  (working copy)
@@ -3999,6 +3999,16 @@ compute_objsize (tree dest, int ostype, tree *pdec
 above.  */
  if (TREE_CODE (dest) == ARRAY_REF)
{
+ tree lowbnd = array_ref_low_bound (dest);
+ if (!integer_zerop (lowbnd) && tree_fits_uhwi_p (lowbnd))
+   {
+ /* Adjust the offset by the low bound of the array
+domain (normally zero but 1 in Fortran).  */
+ unsigned HOST_WIDE_INT lb = tree_to_uhwi (lowbnd);
+ offrng[0] -= lb;
+ offrng[1] -= lb;
+   }
+
  /* Convert the array index into a byte offset.  */
  tree eltype = TREE_TYPE (dest);
  tree tpsize = TYPE_SIZE_UNIT (eltype);

[Bug other/92958] New: [10 regression] gfortran.dg/lto/pr87689_0.f fails starting with r279392

[seurer at gcc dot gnu.org]

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

Bug ID: 92958
   Summary: [10 regression] gfortran.dg/lto/pr87689_0.f fails
starting with r279392
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  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/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
f_lto_pr87689_0.o f_lto_pr87689_1.o-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never  -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
  
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-o gfortran-dg-lto-pr87689-31.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
f_lto_pr87689_0.o f_lto_pr87689_1.o -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-o gfortran-dg-lto-pr87689-31.exe
In function 'MAIN__',
inlined from 'main' at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/lto/pr87689_0.f:13:0:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/lto/pr87689_0.f:10:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/lto/pr87689_0.f: In
function 'main':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/lto/pr87689_0.f:7:22:
note: at offset 1 to object 'c' with size 1 declared here
FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin

[Bug middle-end/92957] gcc produces a duplicated load, clang doesn't

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

Version|9.2.1   |10.0

--- Comment #1 from Rafael Avila de Espindola  ---
gcc trunk (r279443) still produces the same code.

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
-Wstringop-overflow is a C-family only option that shouldn't be enabled for
Fortran.  It took some effort to make it work that way (see pr80545 for the
background) and there's no test for it so either the logic put in there still
isn't correct or something has regressed.

I wouldn't be surprised if the problem was still unresolved in LTO builds
(e.g., pr92952) but this doesn't look like like an LTO test.  I don't see this
test in my builds or on gcc-testresults and compiling it by hand gives the
error below.  What do I need to do to build it?

/ssd/src/gcc/svn/libgomp/testsuite/libgomp.fortran/examples-4/async_target-2.f90:25:7:

   25 |   use omp_lib, only: omp_is_initial_device
  |   1
Fatal Error: Cannot open module file ‘omp_lib.mod’ for reading at (1): No such
file or directory
compilation terminated.

Can you include the strlen dump for the test (-fdump-tree-strlen)?

[Bug testsuite/92955] [10 regression] gcc.dg/vect/pr60505.c fails starting with r279392

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-16
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I cannot reproduce the warnings with my powerpc64le cross compiler, either at
-O2 or -O3 when the loop is fully unrolled, or with any other options I tried
(e.g., -mcpu=power8 and -mcpu=power9), but I did manage to reproduce it with a
powerpc64-linux cross.  The -maltivec option makes a difference.

Below are parts of the dump of the function the warning sees and that cause the
some of the warnings.  The warning is working correctly -- the out-of-bounds
accesses are in the IL.  It looks like they are introduced by jump threading.

Suppressing the new warning by -Wno-stringop-truncation doesn't seem
appropriate because the test was added to verify no warning (originally
-Warray-bounds) is issued for such accesses.  I don't know why they only show
up with the powerpc64 back end and not others.

foo (char * in, char * out, int num)
{
  ...
  char ovec[16];
  ...
   [local count: 118111600]:
  ovec = "\x00";
  if (num_13(D) > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119324]:
  _10 = (unsigned int) num_13(D);
  _9 = _10 + 4294967295;
  addr2int0_27 = (signed long) out_14(D);
  andmask_21 = addr2int0_27 & 15;
  _26 = _9 > 14;
  _22 = andmask_21 == 0;
  _30 = in_17(D) + 1;
  _31 = out_14(D) - _30;
  _32 = (sizetype) _31;
  _33 = _32 > 14;
  _76 = _33 & _22;
  _34 = _76 & _26;
  if (_34 != 0)
goto ; [80.00%]
  else
goto ; [20.00%]

   [local count: 84095460]:
  bnd.6_56 = _10 >> 4;
  in_60 = in_17(D) & -16B;
  vect__3.9_61 = MEM  [(char *)in_60];
  vect__3.12_62 = __builtin_altivec_mask_for_load (in_17(D));
  vectp_in.15_64 = in_17(D) + 15;
  vectp_in.14_67 = vectp_in.15_64 & -16B;
  vect__3.16_68 = MEM  [(char *)vectp_in.14_67];
  vect__3.17_69 = REALIGN_LOAD ;
  MEM  [(char *)] = vect__3.17_69;
  MEM  [(char *)out_14(D)] = vect__3.17_69;
  vectp_in.14_66 = vectp_in.15_64 + 16;
  vectp_out.20_74 = out_14(D) + 16;
  niters_vector_mult_vf.7_57 = bnd.6_56 << 4;
  tmp.8_58 = (int) niters_vector_mult_vf.7_57;
  if (_10 == niters_vector_mult_vf.7_57)
goto ; [6.25%]
  else
goto ; [93.75%]

   [local count: 78839493]:
  _205 = (sizetype) tmp.8_58;
  _206 = in_17(D) + 16;
  _207 = *_206;
  ovec[tmp.8_58] = _207;
  _209 = vectp_out.20_74;
  MEM[(char *)vectp_out.20_74] = _207;
  i_211 = tmp.8_58 + 1;
  if (num_13(D) > 17)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 70167152]:
  _214 = 17;
  _215 = in_17(D) + 17;
  _216 = *_215;
  ovec[17] = _216;   <<< index value 17 is out of the bounds of char[16]
  _218 = out_14(D) + 17;
  *_218 = _216;
  i_220 = 18;
  if (num_13(D) > 18)
goto ; [89.00%]
  else
goto ; [11.00%]
  ...
   [local count: 15424248]:
  _48 = 30;
  _49 = in_17(D) + 30;
  _50 = *_49;
  ovec[30] = _50;   <<< index value 30 is out of the bounds of char[16]
  _52 = out_14(D) + 30;
  *_52 = _50;
  i_54 = 31;
  goto ; [100.00%]
  ...

[Bug middle-end/92957] New: gcc produces a duplicated load, clang doesn't

[rafael at espindo dot la]

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

Bug ID: 92957
   Summary: gcc produces a duplicated load, clang doesn't
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

Created attachment 47507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47507=edit
testcase

In the attached testcase gcc produces

_Z3fooPN7seastar12future_stateIJiEEES2_:
movq(%rsi), %rax
movq%rax, (%rdi)
movq$0, (%rsi)
movq(%rdi), %rax
subq$2, %rax
cmpq$1, %rax
ja  .L1
movl8(%rsi), %eax
movl%eax, 8(%rdi)
.L1:
ret

The "movq   (%rdi), %rax" load is redundant and clang avoids it.

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
(In reply to myself from comment #0)
> regression in (all?) OpenMP 'target' offloading compilation testing, for
> example with 64-bit nvptx:

;-) This "all" here means (presumably?) all different offload target
configurations, not "all test cases".  (I'm seeing this just for
'libgomp.fortran/examples-4/async_target-2.f90'.)

> Similarly for 32-bit Intel MIC (emulated) offloading.

[Bug fortran/92956] New: 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92956
   Summary: 'libgomp.fortran/examples-4/async_target-2.f90'
offloading compilation regression
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
msebor at gcc dot gnu.org
  Target Milestone: ---

The recent PR91582 "missing heap overflow detection for strcpy", PR92868 "ICE:
tree check: expected integer_cst, have ssa_name" commit r279392 causes a
regression in (all?) OpenMP 'target' offloading compilation testing, for
example with 64-bit nvptx:

@@ -2537,9 +2537,9 @@ PASS: libgomp.fortran/examples-4/async_target-2.f90  
-O1  (test for excess erro
PASS: libgomp.fortran/examples-4/async_target-2.f90   -O1  execution test
PASS: libgomp.fortran/examples-4/async_target-2.f90   -O2  (test for excess
errors)
PASS: libgomp.fortran/examples-4/async_target-2.f90   -O2  execution test
[-PASS:-]{+FAIL:+} libgomp.fortran/examples-4/async_target-2.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
PASS: libgomp.fortran/examples-4/async_target-2.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
[-PASS:-]{+FAIL:+} libgomp.fortran/examples-4/async_target-2.f90   -O3 -g 
(test for excess errors)
PASS: libgomp.fortran/examples-4/async_target-2.f90   -O3 -g  execution
test
PASS: libgomp.fortran/examples-4/async_target-2.f90   -Os  (test for excess
errors)
PASS: libgomp.fortran/examples-4/async_target-2.f90   -Os  execution test

Note: '-O3' only, and execution testing not affected.

[...]/libgomp.fortran/examples-4/async_target-2.f90: In function
'vec_mult_._omp_fn.2':
[...]/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1
[8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=^G-Wstringop-overflow=8;;^G]
lto1: note: at offset 0 to object 'rank' with size 1 declared here
[...]/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1
[8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=^G-Wstringop-overflow=8;;^G]
lto1: note: at offset 0 to object 'rank' with size 1 declared here
[...]/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1
[8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=^G-Wstringop-overflow=8;;^G]
lto1: note: at offset 0 to object 'rank' with size 1 declared here
[...]/libgomp.fortran/examples-4/async_target-2.f90: In function
'vec_mult_._omp_fn.2':
[...]/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1
[8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=^G-Wstringop-overflow=8;;^G]
lto1: note: at offset 0 to object 'rank' with size 1 declared here
[...]/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1
[8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=^G-Wstringop-overflow=8;;^G]
lto1: note: at offset 0 to object 'rank' with size 1 declared here
[...]/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1
[8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=^G-Wstringop-overflow=8;;^G]
lto1: note: at offset 0 to object 'rank' with size 1 declared here

Similarly for 32-bit Intel MIC (emulated) offloading.

As this cites gfortran internals ("object 'rank'"), tentatively setting
"Component: fortran", and CCing Tobias.

[Bug ipa/92676] [10 Regression] lto1: error: comdat-local function called by construct.constprop outside its comdat since r278669

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
I proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01129.html

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Not working on this further.

[Bug c++/92745] [8/9/10 Regression] Initializing array with vec4 results in compile error

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Potential fix:

--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -6408,11 +6408,11 @@ reshape_init_r (tree type, reshape_iter *d, bool
first_initializer_p,
  /* For a nested compound literal, there is no need to reshape since
 we called reshape_init in finish_compound_literal, before calling
 digest_init.  */
- else if (COMPOUND_LITERAL_P (stripped_init)
-  /* Similarly, a CONSTRUCTOR of the target's type is a
- previously digested initializer.  */
-  || same_type_ignoring_top_level_qualifiers_p (type,
-init_type))
+ else if (COMPOUND_LITERAL_P (stripped_init))
+   gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ /* Similarly, a CONSTRUCTOR of the target's type is a previously
+digested initializer.  */
+ else if (same_type_ignoring_top_level_qualifiers_p (type, init_type))
{
  ++d->cur;
  gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));

[Bug testsuite/92955] New: [10 regression] gcc.dg/vect/pr60505.c fails starting with r279392

[seurer at gcc dot gnu.org]

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

Bug ID: 92955
   Summary: [10 regression] gcc.dg/vect/pr60505.c fails starting
with r279392
   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/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -maltivec -mpower8-vector
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -Wall -Werror -S -o pr60505.s   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -maltivec -mpower8-vector
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -Wall -Werror -S -o pr60505.s
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c: In function
'foo':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset [16, 2147483632] to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 17 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 18 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 19 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 20 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 21 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 22 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 23 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 24 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 25 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 26 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 27 to object 'ovec' with size 16 declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:10:23: error:
writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr60505.c:7:8: note: at
offset 28 

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Also note the update_vtable_entry_for_fn changes (except the formatting one)
were done just in desperate attempt to avoid various ICEs, I'm afraid I have no
idea what would need to be done to diagnose consteval method covariant returns
are valid, but without ICEing because we can't find those in structures that
don't have those already, or e.g. that we don't try to create thunks.  And,
guess the cxx_eval_constant_call or somewhere similar it needs to be able to
deal with what thunks would normally deal with.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Testcase for pmf (incomplete, guess the non-pmf calls should be converted too):
struct S {
  constexpr S () : s (0) {}
  virtual int foo () const { return 42; }
  consteval virtual int bar () const { return 43; }
  consteval virtual int baz () const { return 44; }
  int s;
};
struct T : public S {
  constexpr T () : t (0) {}
  consteval int bar () const { return 45; }
  consteval virtual int baz () const { return 46; }
  int t;
};

consteval int
foo ()
{
  S s;
  T t;
  S *u = (S *) 
  T *v = 
  auto pmf1 = ::bar;
  auto pmf2 = ::baz;
  if ((s.*pmf1) () != 43) throw 1;
  if ((s.*pmf2) () != 44) throw 2;
  if ((t.*pmf1) () != 45) throw 3;
  if ((t.*pmf2) () != 46) throw 4;
  if ((u->*pmf1) () != 45) throw 5;
  if ((u->*pmf2) () != 46) throw 6;
  return 0;
}

constexpr S s;
constexpr T t;

constexpr const S *
bar (bool x)
{
  return x ?  : (const S *) 
}

int a = foo ();
int b = bar (false)->bar ();
int c = bar (true)->baz ();
static_assert (bar (false)->bar () == 45);
static_assert (bar (true)->baz () == 44);

Not sure what to do there, expand_ptrmemfunc_cst uses DECL_VINDEX which for
immediate virtual functions is negative.  It could transform those into
positive say by adding list_length (BINFO_VIRTUALS ()) to it, but during the
constexpr evaluation it isn't evaluated as some kind of OBJ_TYPE_REF, but
rather dereference of the vtable.  And, for vtable decls we don't want the
consteval methods in there, so maybe cxx_eval_constant_call would need to
figure out it is a PMF call to a consteval method and look it up in
BINFO_VIRTUALS chain rather than actually in the vtable.

Testcase for covariants, this one compiles, but fails the assertion.  It is
covariant2.C where I had to s/virtual/public/ on the D prototype, so that D's
ctor could be constexpr, so maybe it is ok it works this way.
// { dg-do compile { target c++2a } }

struct B1;
struct B2;
struct D;

struct B1
{
  virtual consteval const B1 *foo1 () const {return this;}
  consteval virtual const B2 *foo2 (const D *) const;
};
struct B2
{
  consteval virtual const B2 *baz1 () const {return this;}
  consteval virtual const B1 *baz2 (const D *) const;
};

struct D : public B1, B2
{
  virtual consteval const D *foo1 () const {return this;}
  virtual consteval const D *foo2 (const D *d) const {return d;}
  consteval virtual const D *baz1 () const {return this;}
  virtual consteval const D *baz2 (const D *d) const {return d;}
};

consteval const B2 *B1::foo2 (const D *d) const {return d;}
consteval const B1 *B2::baz2 (const D *d) const {return d;}

consteval int
test (const B1 *b1, const B2 *b2, const D *d)
{
  if (b1->foo1 () != b1)
return 1;
  if (b2->baz1 () != b2)
return 2;
  if (b1->foo2 (d) != b2)
return 3;
  if (b2->baz2 (d) != b1)
return 4;
  return 0;
}

consteval int
test (const D *d)
{
  if (d->foo2 (d) != d)
return 11;
  if (d->baz2 (d) != d)
return 12;
  if (d->foo1 () != d)
return 13;
  if (d->baz1 () != d)
return 14;
  return 0;
}

constexpr D d;
constexpr auto e = test (, , );
constexpr auto f = test ();
//static_assert (e == 0);
static_assert (f == 0);
int g = e;

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Created attachment 47506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47506=edit
gcc10-wip-consteval-virtual.patch

I've tried to make further progress on this, and while simple testcases like
those included in the patch work, consteval pmf for consteval virtual methods
doesn't work and covariants don't work either and I'm stuck.

[Bug c++/92948] internal compiler error: in tsubst_copy, at cp/pt.c:15788

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-16
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
This tsubst_copy ICE started with r267108 but before that we had another ICE:

92948.C:13:21: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:4594
   13 | using Bbb = Bbb_;
  | ^
0x8982d3 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4594
0x88b4a5 cxx_eval_call_expression
../../gcc/cp/constexpr.c:1508
0x8970c9 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4288
0x899db8 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5023
0x89a62d cxx_constant_value(tree_node*, tree_node*)
../../gcc/cp/constexpr.c:5144
0xa5be7a get_template_parm_object
../../gcc/cp/pt.c:6726
0xa5dab7 convert_nontype_argument
../../gcc/cp/pt.c:7187
0xa60ec2 convert_template_argument
../../gcc/cp/pt.c:8094
0xa62aa2 coerce_template_parms
../../gcc/cp/pt.c:8574
0xa631ac coerce_innermost_template_parms
../../gcc/cp/pt.c:8695
0xa65769 lookup_template_class_1
../../gcc/cp/pt.c:9392
0xa67db7 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:9751
0xae8a49 finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:3257
0x9fabe3 cp_parser_template_id
../../gcc/cp/parser.c:16103
0xa0773f cp_parser_class_name
../../gcc/cp/parser.c:22660
0x9e74f8 cp_parser_qualifying_entity
../../gcc/cp/parser.c:6638
0x9e6598 cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:6324
0x9fd271 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:17442
0x9fc7bb cp_parser_type_specifier
../../gcc/cp/parser.c:17115
0xa05143 cp_parser_type_specifier_seq
../../gcc/cp/parser.c:21404

the second ICE started with Implement P0732R2, class types in non-type template
parameters. / r265789, before that the test was rejected.

So confirmed, though it may be a dup too.

[Bug target/92953] Undesired if-conversion with overflow builtins

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
At least then GCC should try to use cmovno instead of seto-test-cmove for
if-conversion:

foo:
movl%edi, %eax
subl%esi, %eax
notl%eax
orl $1, %eax
subl%esi, %edi
cmovno  %edi, %eax
ret

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||amonakov at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Alexander Monakov  ---
Looks like the documentation was added in r230651, overflow patterns for arm in
r239739, and for arm64 in r262890.

[Bug c++/83441] Null this captured in lambda in class variable initializer for templated classes

[boldizsar.palo...@continental-corporation.com]

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

Boldizsar Palotas  changed:

   What|Removed |Added

 CC||boldizsar.palotas@continent
   ||al-corporation.com

--- Comment #1 from Boldizsar Palotas 
 ---
A more minimal reproduction that relies on the core language only:

  // https://godbolt.org/z/fW6Bkx
  #include 

  template 
  struct S {
S* x = [this] { return this; }();
  };

  int main()
  {
S s;
assert(s.x != nullptr);
  }

The assert fails only on GCC 7, including GCC 7.4 and 7.5. Other compilers and
newer GCC major versions seem fine. More combinations can be tested on the
Compiler Explorer link.

[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  ---
For the time being, -fno-ipa-icf-variables might do as a work-around.

[Bug ipa/92932] Optimizers generate wrong code due to aggressive data optimization.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa

--- Comment #3 from Georg-Johann Lay  ---
For the time being, -fno-ipa-icf-variables might be used as a work-around.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |INVALID

[Bug target/92953] Undesired if-conversion with overflow builtins

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #2)
> Well, the aarch64 backend does not implement subv4 pattern in the
> first place, which would be required for efficient branchy code:
> 
> foo:
> subsw0, w0, w1
> b.vc.LBB0_2
> mvn w0, w0
> orr w0, w0, #0x1
> .LBB0_2:
> ret
> 
> This is preferable when the branch is predictable, thanks to shorter
> dependency chain.

Not much shorter and even if the branch is predictable it is worse. Also more
likely you a lot going on during the time, so a microbenchmark is not going to
prove to me it is worse.  

Also yes overflow might be considered the "exceptional" case but I have my
doubts that is always true.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

Filippo Portera  changed:

   What|Removed |Added

 Resolution|INVALID |WORKSFORME

[Bug target/92953] Undesired if-conversion with overflow builtins

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
Well, the aarch64 backend does not implement subv4 pattern in the first
place, which would be required for efficient branchy code:

foo:
subsw0, w0, w1
b.vc.LBB0_2
mvn w0, w0
orr w0, w0, #0x1
.LBB0_2:
ret

This is preferable when the branch is predictable, thanks to shorter dependency
chain.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> NOTE yes there is a missing -Wshadow warning, I will file it in a second.

PR92954

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #11 from Andrew Pinski  ---
.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

--- Comment #9 from Filippo Portera  ---
Fixed!
Thanks a lot!

Il giorno lun 16 dic 2019 alle ore 12:28 pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> ha scritto:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92951
>
> --- Comment #8 from Andrew Pinski  ---
> NOTE yes there is a missing -Wshadow warning, I will file it in a second.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

Filippo Portera  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

[Bug c++/92954] New: -Wshadow does not report when a struct member shadows a global

[pinskia at gcc dot gnu.org]

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

Bug ID: 92954
   Summary: -Wshadow does not report when a struct member shadows
a global
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
int t;
struct g{
int t;
void h(void)
{
t++;
}
};
 CUT ---
I would have thought there would be a warning with -Wshadow but there is not.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
NOTE yes there is a missing -Wshadow warning, I will file it in a second.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
class MeanSquaredError
{
private:
  arma::mat traindata;


:)

That is the traindata inside MeanSquaredError::Backward is referencing
this->traindata and not the global one.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

--- Comment #6 from Filippo Portera  ---
Created attachment 47505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47505=edit
implementation file

where I would like to use the training variable

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

--- Comment #5 from Filippo Portera  ---
Created attachment 47504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47504=edit
include file

where training is declared as extern

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

--- Comment #4 from Filippo Portera  ---
Created attachment 47503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47503=edit
main file

where training is defined

[Bug target/92953] Undesired if-conversion with overflow builtins

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-linux-gnu
  Component|rtl-optimization|target
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
But for aarch64 we get:
subsw0, w0, w1 //w0 = w0 - w1; setting overflow bit of flags
mvn w1, w0  // w1 = ~w0
orr w1, w1, 1 // w1 = w1 | 1
cselw0, w1, w0, vs // w0 = over ? w1 : w0
ret

Which is the best and better than with branches.

So this is a fully a target issue.

[Bug rtl-optimization/92953] New: Undesired if-conversion with overflow builtins

[amonakov at gcc dot gnu.org]

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

Bug ID: 92953
   Summary: Undesired if-conversion with overflow builtins
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

Consider:

/* Return 0 if a==b, any positive value if a>b, any negative value otherwise.
*/
int foo(int a, int b)
{
int c;
if (__builtin_sub_overflow(a, b, ))
c = 1 | ~c;
return c;
}

(suggestions for implementations that would be more efficient on x86 welcome)

on x86 with -Os gives the expected

foo:
subl%esi, %edi
movl%edi, %eax
jno .L1
notl%eax
orl $1, %eax
.L1:
ret

but with -O2 there's if-conversion despite internal-fn.c marking the branch as
"very_unlikely":

foo:
xorl%edx, %edx
subl%esi, %edi
movl%edi, %eax
seto%dl
notl%eax
orl $1, %eax
testl   %edx, %edx
cmove   %edi, %eax
ret

Adding __builtin_expect to the source doesn't help. Adding
__builtin_expect_with_probability helps when specified probability is very low
(<3%), but I feel that shouldn't be required here.

Looking at expand dump, on RTL we start with two branches, first from expanding
the internal fn to calculate a 0/1 predicate value, the second corresponding to
the "if" in the source, branching on testing that predicate against 0. At -Os,
we rely on first if-conversion pass to eliminate the first branch, and then on
combine to optimize the second branch.

Is it possible to expand straight to one branch by noticing that the predicate
is only used in the gimple conditional that follows immediately?

[Bug ipa/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
One possibility would be to make sure that for lto_stream_offload_p
get_partitioning_class never returns SYMBOL_DUPLICATE, because for
lto_stream_offload_p only ->offloadable nodes are selected for streaming.
Honza, thoughts on that?  Not really sure about the special cases like
DECL_IN_CONTSTANT_POOL etc.
Yet another option would be not stream only ->offloadable nodes, but also nodes
for which node->get_partitioning_class () returns SYMBOL_DUPLICATE, that would
be a solution closer to the OpenMP 5.0 way of automatic declare target to
discovery, not fully, but partially.

Honza, thoughts on that?

[Bug middle-end/92952] [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/92952] New: [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[ro at gcc dot gnu.org]

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

Bug ID: 92952
   Summary: [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Between 20191213 (r279370) and 20191215 (r279402), gfortran.dg/lto/pr87689
started to FAIL:

+FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2
-flto
+FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2
-flto -flto-partition=1to1 
+FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2
-flto -flto-partition=none 

I'm seeing it on 32 and 64-bit Solaris/SPARC and x86, but according to
gcc-testresults
it happens everywhere.  The link succeeds actually, but there's a warning:

In function ‘MAIN__’,
inlined from ‘main’ at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/lto/pr87689_0.f:13:0:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/lto/pr87689_0.f:10:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/lto/pr87689_0.f: In
function ‘main’:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/lto/pr87689_0.f:7:22:
note: at offset 1 to object ‘c’ with size 1 declared here

during the link step.  It seems plausible that this is due to

2019-12-13  Martin Sebor  

PR middle-end/91582
PR middle-end/92868

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
This is not a usable bug report, please read the page you were asked to read
before submitting bugs: https://gcc.gnu.org/bugs/

[Bug c++/92893] [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array

[sbergman at redhat dot com]

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

--- Comment #4 from Stephan Bergmann  ---
(FWIW, the amount of cases where this issue hits the build of LibreOffice seems
to have increased further with more recent GCC trunk builds after I filed the
issue.)

[Bug target/92946] [9 Regression] [SH] Native GCC crashes when invoking with -m4 -m4-nofpu -pipe

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
I can confirm that the issue is introduced by the Debian patch
gcc-search-prefixed-as-ld.diff. Changing the patch as suggested in the Debian
bug report fixes the problem for me.

So it's not an upstream bug.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

--- Comment #2 from Filippo Portera  ---
I printf the variable dimensions both in the main() that in:

void MeanSquaredError::Backward(
  int begin, int batch_size,
  const InputType&& input,
  const TargetType&& target,
  OutputType&& output)
{
  double gamma = 1;
  printf("n_rows = %d, n_cols = %d\n", traindata.n_rows, traindata.n_cols);


that I'm sure it is called inside the main function and before the first
main's printf.





Il giorno lun 16 dic 2019 alle ore 09:39 pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> ha scritto:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92951
>
> --- Comment #1 from Andrew Pinski  ---
> Is the printf before or after main?
>
> If before, then the problem is the order of variables initialized from
> different translational units is unspecified and therefore undefined.
>
> If after, then maybe something is changing them.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/92951] extern variable declaration doesn't behave properly for me

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Is the printf before or after main?

If before, then the problem is the order of variables initialized from
different translational units is unspecified and therefore undefined.

If after, then maybe something is changing them.

[Bug c++/92951] New: extern variable declaration doesn't behave properly for me

[fportera2 at gmail dot com]

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

Bug ID: 92951
   Summary: extern variable declaration doesn't behave properly
for me
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fportera2 at gmail dot com
  Target Milestone: ---

I have a global variable 'traindata' declared in cnn.cpp:

arma::mat traindata;

, I'm importing this varible in mean_squared_error.hpp:

#include 

extern arma::mat traindata;

and I'm trying to exploit this variable in mean_squared_error_impl.hpp (that
includes 'mean_squared_error.hpp'), for example:

printf("n_rows = %d, n_cols = %d\n", traindata.n_rows, traindata.n_cols);

but it gives me that the dimensions are 0's (while in the cnn.cpp' main() they
are positive).

thanks

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Dec 16 08:03:28 2019
New Revision: 279410

URL: https://gcc.gnu.org/viewcvs?rev=279410=gcc=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi

The backend emits 16 bit memory loads for single element character
vector.  As a result the character will not be right justified in the
GPR.

gcc/ChangeLog:

2019-12-16  Andreas Krebbel  

PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
and lhrl with llc.

gcc/testsuite/ChangeLog:

2019-12-16  Andreas Krebbel  

PR target/92950
* gcc.target/s390/vector/pr92950.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/vector/pr92950.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/vector.md
trunk/gcc/testsuite/ChangeLog