[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jbeulich at suse dot com]

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

--- Comment #11 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #7)
> Though, there are other issues.  There is only vpternlog{d,q}, so for
> V*[QH]Imode we shouldn't pretend we have masking support.

Why would this be? The element mode doesn't matter at all for bitwise
operations. Just like there's no VPANDB / VPANDW, but VPANDD/VPANDQ are quite
fine to use on vectors of QI or HI. Afaict the existence of VPAND{D,Q} in
AVX512 (as opposed to {,V}PAND in MMX/SSE2/AVX) is merely an oddity resulting
from EVEX.W handling (besides of course the element width's effect on embedded
broadcasting).

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jbeulich at suse dot com]

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

--- Comment #12 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 48128 [details]
> gcc10-pr94343.patch
> 
> Updated patch.  A variant to that would be 4 separate patterns I guess, not
> sure if that would be shorter.

May I suggest that the testcases also check for the 0x55 immediate? The
potential of VPTERNLOG allows for much wider use (with different immediates) in
principle, so the correct choice of immediate would imo better be validated
here as well.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jbeulich at suse dot com]

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

--- Comment #13 from jbeulich at suse dot com ---
As to using 512-bit operations even on more narrow input types - is this
correct when e.g. subsequently source code upcasts the vector? I.e. would such
an upcast be carried out by emitting an insn to zero the upper portion, rather
than simply considering this a re-interpretation of the same register (with no
insn emitted at all)? In which case the fix would apparently boil down to using
a mode iterator different from VI (VI48_AVX512VL if you really mean to exclude
vectors of QI/HI, or a combination of this and VI12_AVX512VL otherwise).

[Bug rtl-optimization/94344] [9/10 Regression] Rotate pattern not recognized anymore

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-27
 Target||x86_64-*-* i?86-*-*
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
Confirmed.

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Yes, they are orthogonal.  But I expected that when I use
__attribute__((section"foo")) twice then both instances will be in the
same section which is not the case here.  Here just the names of the sections
are equal.

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
OK, so during early creation of the DIE for the type we end up in

static void
gen_struct_or_union_type_die (tree type, dw_die_ref context_die,
enum debug_info_usage usage)
{
...
  int complete = (TYPE_SIZE (type)
  && (! TYPE_STUB_DECL (type)
  || ! TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type;

where complete is false because of TYPE_DECL_SUPPRESS_DEBUG.  When record
the type to be re-processed later and between now and then the C++ FE does
note_debug_info_needed via maybe_emit_vtables and clears
TYPE_DECL_SUPPRESS_DEBUG, causing the type to be completed during 
retry_incomplete_types processing.

I think PR93951 may be related in the end because the conditions on when
exactly we emit what parts of debug info is quite intricate in dwarf2out.

Now, for this bug I guess we should choose to piggy-back on that,
making should_emit_struct_debug return false for DINFO_LEVEL_TERSE
or initializing debug_struct_{generic,ordinary} accordingly.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b1fa6f5ff7c..378a27394e8 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -399,6 +399,9 @@ get_full_len (const wide_int &op)
 static bool
 should_emit_struct_debug (tree type, enum debug_info_usage usage)
 {
+  if (debug_info_level <= DINFO_LEVEL_TERSE)
+return false;
+
   enum debug_struct_file criterion;
   tree type_decl;
   bool generic = lang_hooks.types.generic_p (type);

thoughts?

The DWARF we generate for the testcase at -g1 is then

 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x0): GNU C++14 10.0.1
2
0200325 (experimental) -mtune=generic -march=x86-64 -g1
<10>   DW_AT_language: 4(C++)
<11>   DW_AT_name: (indirect string, offset: 0x4a): t.ii
<15>   DW_AT_comp_dir: (indirect string, offset: 0x4f):
/home/rguenther/
obj/gcc
<19>   DW_AT_ranges  : 0x0
<1d>   DW_AT_low_pc  : 0x0
<25>   DW_AT_stmt_list   : 0x0
 <1><29>: Abbrev Number: 2 (DW_TAG_variable)
<2a>   DW_AT_name: b
<2c>   DW_AT_decl_file   : 1
<2d>   DW_AT_decl_line   : 3
<2e>   DW_AT_decl_column : 12
<2f>   DW_AT_external: 1
<2f>   DW_AT_declaration : 1
 <1><2f>: Abbrev Number: 3 (DW_TAG_variable)
<30>   DW_AT_specification: <0x29>
<34>   DW_AT_decl_line   : 4
<35>   DW_AT_decl_column : 5
<36>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <1><40>: Abbrev Number: 4 (DW_TAG_subprogram)
<41>   DW_AT_external: 1
<41>   DW_AT_name: c
<43>   DW_AT_decl_file   : 1
<44>   DW_AT_decl_line   : 2
<45>   DW_AT_decl_column : 16
<46>   DW_AT_linkage_name: (indirect string, offset: 0x67): _ZN1a1cEv
<4a>   DW_AT_virtuality  : 1(virtual)
<4b>   DW_AT_vtable_elem_location: 2 byte block: 10 0   (DW_OP_constu:
0)
<4e>   DW_AT_accessibility: 3   (private)
<4f>   DW_AT_low_pc  : 0x0
<57>   DW_AT_high_pc : 0xb
<5f>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
<61>   DW_AT_GNU_all_call_sites: 1
 <1><61>: Abbrev Number: 0

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to jbeulich from comment #13)
> As to using 512-bit operations even on more narrow input types - is this
> correct when e.g. subsequently source code upcasts the vector? I.e. would
> such an upcast be carried out by emitting an insn to zero the upper portion,
> rather than simply considering this a re-interpretation of the same register
> (with no insn emitted at all)? In which case the fix would apparently boil
> down to using a mode iterator different from VI (VI48_AVX512VL if you really
> mean to exclude vectors of QI/HI, or a combination of this and VI12_AVX512VL
> otherwise).

Yes, in RTL a store to a register in some machine mode when the hw register has
wider mode leaves the upper bits undefined, not zero initialized (like e.g.
most of the 32-bit instructions do on 64-bit general purpose registers or many
AVX etc. instructions do on vector registers), we do have a REE pass to handle
some most common cases.
If we added some machine specific pass that would do something like that for
most instructions, we'd need some attribute to mark instructions that don't
have that property, sure, but we don't ATM.

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
I'm testing this patch now.

[Bug web/94351] New: bugzilla search is not as useful as before

[pinskia at gcc dot gnu.org]

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

Bug ID: 94351
   Summary: bugzilla search is not as useful as before
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: overseers at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: LpSolit at gmail dot com
  Target Milestone: ---

Before the recent machine update (and OS), the advanced search had a few fields
instead of having to use the custom search part.
I was able to search by comments, keywords, and target/host/build (maybe a few
others, I can't remember the full list).
Now I have to use the custom search section which is harder and slower than
what I used to do before hand.

[Bug web/94349] Bugzilla user preferences are blank

[LpSolit at gmail dot com]

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

--- Comment #3 from Frédéric Buclin  ---
Hum, what happened recently, server side? The source code didn't change for
months (or if it changed, someone else did).

[Bug web/94349] Bugzilla user preferences are blank

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The entire server was replaced, with new hardware, new OS, and new versions of
most software.

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed since r10-7344-gca6c722561ce9b9d

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:72809d6fe8e085440403ce125c51d01d6e7512b0

commit r10-7410-g72809d6fe8e085440403ce125c51d01d6e7512b0
Author: Jakub Jelinek 
Date:   Fri Mar 27 10:00:47 2020 +0100

c++: Handle COMPOUND_EXPRs in ocp_convert [PR94339]

My recent change to get_narrower/warnings_for_convert_and_check broke
the following testcase, warnings_for_convert_and_check is upset that
expr is a COMPOUND_EXPR with INTEGER_CST at the rightmost operand, while
result is a COMPOUND_EXPR with a NOP_EXPR of INTEGER_CST at the rightmost
operand, it expects such conversions to be simplified.

The easiest fix seems to be to handle COMPOUND_EXPRs in ocp_convert too,
by converting the rightmost operand and recreating COMPOUND_EXPR(s) if that
changed.

The attr-copy-2.C change is a workaround for PR94346, where we now ICE on
the testcase, while previously we'd ICE only if it contained a comma
expression at the outer level rather than cast of a COMPOUND_EXPR to
something.  I'll defer that to Martin.

2020-03-27  Jakub Jelinek  

PR c++/94339
* cvt.c (ocp_convert): Handle COMPOUND_EXPR by recursion on the
second
operand and creating a new COMPOUND_EXPR if anything changed.

* g++.dg/other/pr94339.C: New test.
* g++.dg/ext/attr-copy-2.C: Comment out failing tests due to
PR94346.

[Bug tree-optimization/94352] New: Suspicious code in tree-ssa-propagate.c

[fxue at os dot amperecomputing.com]

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

Bug ID: 94352
   Summary: Suspicious code in tree-ssa-propagate.c
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

In function ssa_propagation_engine::ssa_propagate(), a call chain below might
lead to a reference to uninitialized data.

 ssa_propagate() -> ssa_prop_init() -> add_control_edge() -> "curr_order"

 But ssa_prop_init() is called before "curr_order" is initialized to 0.

[Bug web/94349] Bugzilla user preferences are blank

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
The "Detailed Bug Information" part of the Advanced Search page is also not
properly populated now. It used to have fields for searching comments, keywords
and more.

[Bug web/94351] bugzilla search is not as useful as before

[LpSolit at gmail dot com]

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

--- Comment #1 from Frédéric Buclin  ---
You don't have to use the custom search part. The other fields are still there,
as before.

[Bug c++/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:2eea00c518d5a72d0bdbc810ae675e7ad5fee414

commit r10-7411-g2eea00c518d5a72d0bdbc810ae675e7ad5fee414
Author: Jakub Jelinek 
Date:   Fri Mar 27 10:04:31 2020 +0100

c++: Avoid calls in non-evaluated contexts affect whether function can or
can't throw [PR94326]

The following testcase FAILs -fcompare-debug, because if we emit a
-Wreturn-local-addr warning, we tsubst decltype in order to print the
warning and as that function could throw, set_flags_from_callee during that
sets cp_function_chain->can_throw and later on we don't set TREE_NOTHROW
on foo.  While with -w or -Wno-return-local-addr, tsubst isn't called
during
the warning_at, cp_function_chain->can_throw is kept clear and TREE_NOTHROW
is set on foo.
It isn't just a matter of the warning though, in
int foo ();
int bar () { return sizeof (foo ()); }
int baz () { return sizeof (int); }
I don't really see why we should mark only baz as TREE_NOTHROW and not bar
too, when neither can really throw.

2020-03-27  Jakub Jelinek  

PR c++/94326
* call.c (set_flags_from_callee): Don't update
cp_function_chain->can_throw or current_function_returns_abnormally
if cp_unevaluated_operand.

* g++.dg/other/pr94326.C: New test.

[Bug libstdc++/94353] New: std::copy* breaks when one type is volatile

[alex at grundis dot de]

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

Bug ID: 94353
   Summary: std::copy* breaks when one type is volatile
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex at grundis dot de
  Target Milestone: ---

The following code breaks:

#include 

void foo(const char* b, volatile char* d){
std::copy_n(b, 10, d);
}

This is a regression from earlier versions where it worked fine. The reason is
that at some point `struct __copy_move<_IsMove, true,
random_access_iterator_tag>::__copy_m(const _Tp* __first, const _Tp* __last,
_Tp* __result)` is called where it fails to deduce `__Tp` because it is `char`
and `volatile char`

Full stack: 

In file included from /usr/local/include/c++/10.0.1/bits/char_traits.h:39,
 from /usr/local/include/c++/10.0.1/string:40,
 from /usr/local/include/c++/10.0.1/stdexcept:39,
 from /usr/local/include/c++/10.0.1/system_error:41,
 from
/home/jakecooke/Code/CPP/Glade/src/simulator/abseil-cpp/absl/strings/charconv.h:18,
 from
/home/jakecooke/Code/CPP/Glade/src/simulator/abseil-cpp/absl/strings/charconv.cc:15:
/usr/local/include/c++/10.0.1/bits/stl_algobase.h: In instantiation of
'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false;
_II = const char*; _OI = volatile char*]':
/usr/local/include/c++/10.0.1/bits/stl_algobase.h:533:42:   required from
'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false;
_II = const char*; _OI = volatile char*]'
/usr/local/include/c++/10.0.1/bits/stl_algobase.h:541:31:   required from
'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false;
_II = const char*; _OI = volatile char*]'
/usr/local/include/c++/10.0.1/bits/stl_algobase.h:596:7:   required from
'constexpr _OI std::copy(_II, _II, _OI) [with _II = const char*; _OI = volatile
char*]'
/usr/local/include/c++/10.0.1/bits/stl_algo.h:820:23:   required from
'constexpr _OutputIterator std::__copy_n(_RandomAccessIterator, _Size,
_OutputIterator, std::random_access_iterator_tag) [with _RandomAccessIterator =
const char*; _Size = long int; _OutputIterator = volatile char*]'
/usr/local/include/c++/10.0.1/bits/stl_algo.h:847:27:   required from
'constexpr _OIter std::copy_n(_IIter, _Size, _OIter) [with _IIter = const
char*; _Size = long int; _OIter = volatile char*]'
/home/jakecooke/Code/CPP/Glade/src/simulator/abseil-cpp/absl/strings/charconv.cc:301:7:
  required from 'bool absl::{anonymous}::HandleEdgeCase(const
absl::strings_internal::ParsedFloat&, bool, FloatType*) [with FloatType =
double]'
/home/jakecooke/Code/CPP/Glade/src/simulator/abseil-cpp/absl/strings/charconv.cc:636:23:
  required from 'absl::from_chars_result absl::{anonymous}::FromCharsImpl(const
char*, const char*, FloatType&, absl::chars_format) [with FloatType = double]'
/home/jakecooke/Code/CPP/Glade/src/simulator/abseil-cpp/absl/strings/charconv.cc:681:47:
  required from here
/usr/local/include/c++/10.0.1/bits/stl_algobase.h:499:30: error: no matching
function for call to 'std::__copy_move::__copy_m(const char*&, const char*&, volatile
char*&)'
  498 |   return std::__copy_move<_IsMove, __simple,
  |  ~~~
  499 |  _Category>::__copy_m(__first, __last, __result);
  |  ^~~
/usr/local/include/c++/10.0.1/bits/stl_algobase.h:441:2: note: candidate:
'template static constexpr _Tp* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with
_Tp = _Tp; bool _IsMove = false]'
  441 |  __copy_m(const _Tp* __first, const _Tp* __last, _Tp* __result)
  |  ^~~~
/usr/local/include/c++/10.0.1/bits/stl_algobase.h:441:2: note:   template
argument deduction/substitution failed:
/usr/local/include/c++/10.0.1/bits/stl_algobase.h:499:30: note:   deduced
conflicting types for parameter '_Tp' ('char' and 'volatile char')
  498 |   return std::__copy_move<_IsMove, __simple,
  |  ~~~
  499 |  _Category>::__copy_m(__first, __last, __result);
  |  ^~~


It seems that this should be fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=462f6c2041fad058abcdd5122e99a024f69a39d5
because `__memcpyable` should return false. But
there doesn't seem to be a test case for mixed volatile pointers. I'd suggest
to add them

[Bug web/94349] Bugzilla user preferences are blank

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #5)
> The "Detailed Bug Information" part of the Advanced Search page is also not
> properly populated now. It used to have fields for searching comments,
> keywords and more.

I filed that as PR 94351 as I was finally annoyed enough to file it.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to jbeulich from comment #11)
> (In reply to Jakub Jelinek from comment #7)
> > Though, there are other issues.  There is only vpternlog{d,q}, so for
> > V*[QH]Imode we shouldn't pretend we have masking support.
> 
> Why would this be? The element mode doesn't matter at all for bitwise
> operations. Just like there's no VPANDB / VPANDW, but VPANDD/VPANDQ are
> quite fine to use on vectors of QI or HI. Afaict the existence of VPAND{D,Q}
> in AVX512 (as opposed to {,V}PAND in MMX/SSE2/AVX) is merely an oddity
> resulting from EVEX.W handling (besides of course the element width's effect
> on embedded broadcasting).

For masked instructions, the element mode is significant, it determines which
bits of the mask register apply to which bits in the destination register.
So, if the masked variant is ever matched (e.g. by combine), then it will
expect to do something different from what the insn will actually do.
(define_insn ("one_cmplv64qi2_mask")
 [
(set (match_operand:V64QI 0 ("register_operand") ("=v"))
(vec_merge:V64QI (xor:V64QI (match_operand:V64QI 1
("nonimmediate_operand") ("vm"))
(match_operand:V64QI 2 ("vector_all_ones_operand") ("BC")))
(match_operand:V64QI 3 ("nonimm_or_0_operand") ("0C"))
(match_operand:DI 4 ("register_operand") ("Yk"
] ("(TARGET_AVX512F) && ((TARGET_AVX512F) && (TARGET_AVX512BW))")
("vpternlogd\t{$0x55, %1, %0, %0%{%4%}%N3|%0%{%4%}%N3, %0, %1, 0x55}")
 [
(set_attr ("type") ("sselog"))
(set_attr ("prefix") ("evex"))
(set_attr ("mode") ("XI"))
(set_attr ("mask") ("no"))
])
The above says in RTL that for say the last operand of 0xULL,
first 8 bits in the vector will be the result of the ternlog operation, next 8
bits will be cleared or unmodified (depending on operand 3), etc.
The instruction used for that will do something different, will ignore the
upper 48 bits of the mask register and the low 32 bits of the destination will
be the result of the ternlog operation, next 32 bits will be cleared or
unmodified, etc.

[Bug web/94351] bugzilla search is not as useful as before

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-27
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Where?

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jbeulich at suse dot com]

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

--- Comment #16 from jbeulich at suse dot com ---
Oh, right - I didn't pay attention to the insn permitting masking to be used.
Then still non-masked uses ought to be permitted, perhaps by having a
VI48_AVX512VL one permitting masking and a VI12_AVX512VL one which doesn't?

[Bug libstdc++/94353] std::copy* breaks when one type is volatile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
It is fixed by that commit, and there are several tests for mixed volatile
pointers e.g.

+  volatile int i[2] = { 1, 2 };
+  volatile int j[2] = { 0, 0 };
+  int k[2] = { 0, 0 };
+
+  std::copy(i, i+2, j);
+  VERIFY( j[0] == 1 && j[1] == 2 );
+  std::copy(i, i+2, k);
   ^

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

[Bug libstdc++/94013] [10 Regression] library algos need to work around cwg 2094

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||alex at grundis dot de

--- Comment #7 from Jonathan Wakely  ---
*** Bug 94353 has been marked as a duplicate of this bug. ***

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
The patch I've posted -
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542774.html - solves it by
disabling the problematic masked cases in the condition.  Or we could just
disable the masking on the insn altogether, the expander will not need those.

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[huaixin....@alibaba-inc.com]

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

--- Comment #5 from huaixin chang  ---
(In reply to Richard Biener from comment #2)
> I think the testcase is ill-formed and should be diagnosed in some form.
> IIRC there's some documented behavior (that's not implemented) that
> __aligned__
> only increases alignment unless __packed__ is used.  With __packed__ the
> testcase behaves as expected I think.
> 
> Note __attribute__((__aligned__(4))) applies to 'A', not its type.
Yes, I missed this and quoted wrong document for this case.

> 
> Not sure if behavior changes if you use a typedef that is aligned to 4.

If a use a typedef that is aligned to 4 like this:

typedef struct {
long a __attribute__((__aligned__(128)));
long b __attribute__((__aligned__(128)));
} foo __attribute__((__aligned(4)));

foo A;

Or align variable A to 4 only like this:

typedef struct {
long a __attribute__((__aligned__(128)));
long b __attribute__((__aligned__(128)));
} foo;
foo A __attribute__((__aligned(4)));

I will get warned while compiling and alignment is as expected.

[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #3 from markeggleston at gcc dot gnu.org ---
A patch from Steve Kargl was sent to the fortran mailing list, (see
https://gcc.gnu.org/pipermail/fortran/2020-March/054130.html) without reference
to any PR.

It appeared to be related to this PR. I have verified the patch and also
checked it with the test case in the original report.

The result is:

5 |   equivalence (i, arr(1))
  | 1
Error: Array 'arr' at (1) with non-constant bounds cannot be an EQUIVALENCE
object

The above is much better than an ICE. Thanks Steve.

I will add test cases to the patch and will send it upstream for approval for
master and backports to gcc-8 and gcc-9.

[Bug fortran/93363] [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:a76ff304f905db9fd9b049c2ca4ec84f0420da53

commit r10-7412-ga76ff304f905db9fd9b049c2ca4ec84f0420da53
Author: Tobias Burnus 
Date:   Fri Mar 27 10:56:25 2020 +0100

Fortran] Reject invalid association target (PR93363)

PR fortran/93363
* resolve.c (resolve_assoc_var): Reject association to DT and
function name.

PR fortran/93363
* gfortran.dg/associate_51.f90: Fix test case.
* gfortran.dg/associate_53.f90: New.

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[huaixin....@alibaba-inc.com]

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

--- Comment #6 from huaixin chang  ---
(In reply to jos...@codesourcery.com from comment #3)
> It's a mistake to be referring to the C standard for the interpretation of 
> alignment attributes.  The C standard way of specifying alignment is 
> _Alignas, not __attribute__, and if you write equivalent code using 
> _Alignas you get an error "error: '_Alignas' specifiers cannot reduce 
> alignment of 'A'", which corresponds to the constraint "The combined 
> effect of all alignment specifiers in a declaration shall not specify an 
> alignment that is less strict than the alignment that would otherwise be 
> required for the type of the object or member being declared.".

Yes, I tested with _Alignas and got that error.

[Bug libstdc++/94354] New: std::reverse_iterator comparison operators defined incorrectly

[redi at gcc dot gnu.org]

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

Bug ID: 94354
   Summary: std::reverse_iterator comparison operators defined
incorrectly
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We define the comparison operators for reverse_iterator slightly differently to
how the standard specifies them, which means we incorrectly reject this:

#include 

struct Iter
{
  using iterator_category = std::random_access_iterator_tag;
  using value_type = int;
  using pointer = int*;
  using reference = int&;
  using difference_type = std::ptrdiff_t;

  Iter();

  Iter& operator++();
  Iter operator++(int);
  Iter& operator--();
  Iter operator--(int);
  int& operator*() const;
  int* operator->() const;

  int& operator[](difference_type) const;

  Iter& operator+=(difference_type);
  Iter& operator-=(difference_type);

  friend Iter operator+(Iter, difference_type);
  friend Iter operator+(difference_type, Iter);
  friend Iter operator-(Iter, difference_type);
  friend difference_type operator-(Iter, Iter);

  friend bool operator==(Iter, Iter);
  friend bool operator!=(Iter, Iter);
  friend bool operator<(Iter, Iter);
  friend bool operator>(Iter, Iter);
  friend bool operator<=(Iter, Iter);
  friend bool operator>=(Iter, Iter);
};

bool operator!=(Iter, long*);

std::reverse_iterator l{Iter()};
std::reverse_iterator r{nullptr};

#if __cplusplus > 201703L
static_assert( std::random_access_iterator );
static_assert( std::random_access_iterator );
#endif

bool b1 = l.base() != r.base();  // OK

bool b2 = l != r;


reviter.cc:50:13:   in 'constexpr' expansion of 'std::operator!=(l, r)'
/home/jwakely/gcc/10/include/c++/10.0.1/bits/stl_iterator.h:375:25: error: no
match for 'operator==' (operand types are
'std::reverse_iterator::iterator_type' {aka 'Iter'} and
'std::reverse_iterator::iterator_type' {aka 'long int*'})
  375 | { return __x.base() == __y.base(); }
  |  ~~~^


The reverse_iterator's preconditions are met (both Iter and long* are random
access iterators) and so is the constraint for operator!=

Constraints: x.base() != y.base() is well-formed and convertible to bool.

But it fails because we define operator!= as !(l == r) which uses == on the
base iterator types, and they only support !=

I think the testcase should be valid for C++11 and later, as per
https://cplusplus.github.io/LWG/lwg-defects.html#280
(and also C++98 if we treat that as a DR).

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[bikineev at google dot com]

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

--- Comment #8 from Anton  ---
Yeah, the generated sections are different yet have the same name. The user
would rely on the static linker to merge the sections into a single one.

[Bug fortran/93363] [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
FIXED for GCC 10. Thanks for the testcase!

[Bug web/94351] bugzilla search is not as useful as before

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

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

--- Comment #3 from Andreas Schwab  ---
When edititing a saved search that has used these fields they are lost.

[Bug tree-optimization/94352] Suspicious code in tree-ssa-propagate.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-27
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed but in essence harmless.

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[huaixin....@alibaba-inc.com]

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

--- Comment #7 from huaixin chang  ---
(In reply to Martin Sebor from comment #4)
> Sounds like there's agreement that the code should at least get a warning
> then, so confirmed. 
> 
> The attribute aligned section of the manual describing the variable
> attribute says:
> 
>   When used on a struct, or struct member, the aligned attribute can only
> increase the alignment...
> 
> It's not clear whether struct here refers to a type or a variable (I'm
> guessing it's former but it's in the Common Variable Attribute section so it
> could easily be read as the latter).  Either way, reducing the alignment of
> an object whose members explicitly ask for stricter alignment seems like a
> dangerous thing to do without a warning.
> 
> I'll see if I can do this for GCC 11.

It seems that the compiler thinks A.a is already aligned to 128-byte. Because
as I print alignof(A.a) and alignof(A.b) with the same definition, they are
128.

$./align
address of A 0x42003c
alignof A 4
address of A.a 0x42003c
alignof A.a 128
address of A.b 0x4200bc
alignof A.b 128

Is it in your consideration to actually align A.a to 128-byte boundary?

[Bug libstdc++/94354] std::reverse_iterator comparison operators defined incorrectly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-27
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jonathan Wakely  ---
We also retain the pre-LWG280 homogeneous overloads:

  template
inline _GLIBCXX17_CONSTEXPR bool
operator==(const reverse_iterator<_Iterator>& __x,
   const reverse_iterator<_Iterator>& __y)
{ return __x.base() == __y.base(); }

I don't have a demo, but this might be non-conforming for cases where we
compare reverse_iterator and something convertible to that type.

[Bug target/94220] libgcc FTB for ARM Thumb when optimizing for size

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

https://gcc.gnu.org/g:a9cd2d786ad4c45b9349e7fe22131782828d4cbd

commit r10-7413-ga9cd2d786ad4c45b9349e7fe22131782828d4cbd
Author: Richard Earnshaw 
Date:   Fri Mar 27 10:23:38 2020 +

fixup: move ChangeLog entry for last Arm fix to correct file.

PR target/94220

[Bug target/94220] libgcc FTB for ARM Thumb when optimizing for size

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

https://gcc.gnu.org/g:66e0e23c12d143c8caf787d95ff356f009b1fca9

commit r10-7414-g66e0e23c12d143c8caf787d95ff356f009b1fca9
Author: Richard Earnshaw 
Date:   Fri Mar 27 10:25:51 2020 +

fixup: move ChangeLog entry for last Arm fix to correct file.

PR target/94220

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to huaixin chang from comment #7)
> (In reply to Martin Sebor from comment #4)
> > Sounds like there's agreement that the code should at least get a warning
> > then, so confirmed. 
> > 
> > The attribute aligned section of the manual describing the variable
> > attribute says:
> > 
> >   When used on a struct, or struct member, the aligned attribute can only
> > increase the alignment...
> > 
> > It's not clear whether struct here refers to a type or a variable (I'm
> > guessing it's former but it's in the Common Variable Attribute section so it
> > could easily be read as the latter).  Either way, reducing the alignment of
> > an object whose members explicitly ask for stricter alignment seems like a
> > dangerous thing to do without a warning.
> > 
> > I'll see if I can do this for GCC 11.
> 
> It seems that the compiler thinks A.a is already aligned to 128-byte.
> Because as I print alignof(A.a) and alignof(A.b) with the same definition,
> they are 128.
> 
> $./align
> address of A 0x42003c
> alignof A 4
> address of A.a 0x42003c
> alignof A.a 128
> address of A.b 0x4200bc
> alignof A.b 128
> 
> Is it in your consideration to actually align A.a to 128-byte boundary?

I think there are only two reasonable actions.

 a) warn but otherwise change nothing
 b) reject the case similar to _Alignof

ignoring the user specification as appearantly is done for the typedef
and decl annotation isn't something we can do because it may have ABI impacts.
That is, we need to make sure to not change layout & alignment of structures
with such embedded objects.

I'd lean towards b) here because as you show the actual behavior is
broken.

When you for example exchange 'long' with v4si typedefed as
typedef int v4si __attribute__((vector_size(16))), do you then
get aligned movaps when the actual structure is unaligned?

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Btw,

struct X {
long a __attribute__((__aligned__(128)));
long b __attribute__((__aligned__(128)));
};
struct X A __attribute__((__aligned__(4)));

is not diagnosed (this is what your testcase is, decomposed).

I can't reproduce the diagnostics you describe in comment#5

[Bug fortran/94324] [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||jvdelisle at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
(In reply to Rainer Orth from comment #0)
> I just remembered that between 20191031 (r277679) and 20191101 (r277705) a
> couple of Fortran tests regressed on 32-bit Solaris/x86:

Hmm, that's odd. If I look at this range, there was no libgfortran change and
under gcc/ only an OpenMP change and gcc/config/aarch64.

> However, given that I know nothing about fortran, it would be very helpful
> to have some guidance on where to look.

I hope the following notes help.

 * * *

> +FAIL: gfortran.dg/default_format_1.f90   -O0  execution test
This test is rather old (Feb 2018) — however, there were changes recently,
especially to the "g0" output.

> Note: The following floating-point exceptions are signalling:
> IEEE_UNDERFLOW_FLAG
> STOP 6

  if (test (1.0_8, 0) /= 0) STOP 6

Here, 1.0 (double-prevision) is run as:

  do i = 0, count
write (s,*) x
read (s,*) y
if (y /= x) res = res + 1
x = nearest(x,huge(x))
  end do

Namely: the variable is written out (with default output precision) into the
string "s" and read-in again.  – The test passes if the written-read variable
and the original variable compare equal.

For count=200 steps, the same is repeated for the next higher variable
[nearest() = POSIX's nextafter()]. – Seemingly, one of those fails.

Suggestion: Add (after the "read"):
  print *, i, s, x == y
  print *, x
  print *, y
and - to stop directly after the first fail -
  if (y /= x) stop
and have a look at the output.


 * * *

> +FAIL: gfortran.dg/fmt_g0_1.f08   -O0  execution test
> STOP 3
> 
> #2  0x0805143d in MAIN__ ()
> at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/fmt_g0_1.f08:11
> 11if (buffer.ne.":0.1:") STOP 3
> (gdb) p buffer
> $1 = ':0.', '3' , '2:', ' ' 

This is also an older test (Feb 2018).


write(buffer, string) ':',1.0_8/3.0_8,':'
if (buffer.ne.":0.1:") STOP 3

This test case writes a ':' + 1./3. in double-precision + ':' to buffer.
For each input, "g0" is used.

The expected output is ':' followed by the printed number + ':' (plus padding
by spaces on the right). The assumption is 
":0.1:" - this output
":0.2:" - you get

which also sounds fine. — I don't know whether it has to be '1' or whether '2'
is acceptable as well, one would have to look at the bit representation.

I personally would be fine to accept  ...2 as well.

@ Jerry + Thomas: What do you think?


 * * *

> +FAIL: gfortran.dg/round_4.f90   -Os  execution test
> STOP 15

ref10u = 0.100014_xp

  round = 'nearest'
  call t()
  if (rnd10 .and. (r10p /= ref10u .or. r10m /= -ref10u)) STOP 15

which does:
str = "0.1 0.1 0.1 0.1"
read (str, *,round=round) r4p, r8p, r10p, r16p
str = "-0.1 -0.1 -0.1 -0.1"
read (str, *,round=round) r4m, r8m, r10m, r16m

Namely, the string '0.1' and '-0.1' is read in as 80-bit floating type ("long
double", x87 floating-type number.)

[Or actually: it a this if both 80 bit and 128 bit floating-point numbers are
available; otherweise it is either a 32bit (non available) or 64bit (either
available) number. But as the previous test passes, I assume that it is a 80bit
number in you case.]


0.1 is not representable in binary floating-point numbers and round="nearest"
means:

"the value resulting from conversion shall be the closer of the two nearest
representable values if one is closer than the other. If the two nearest
representable values are equidistant from the original value, it is9processor
dependent which one of them is chosen."


The code assume that
  '0.1' becomes  0.100014
 '-0.1' becomes -0.100014
while you get:   0.15551
-0.15551
this number is suspiciously close to the
expected value for a 64bit floating-point number:
 0.10001

Thus, either 80bit FP numbers are not properly supported or
the output of 80bit FP numbers does not work. However, the
reference value could properly be stored, hmm.

> #2  0x08051f41 in MAIN__ ()
> at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/round_4.f90:100
> 100 if (rnd10 .and. (r10p /= ref10u .or. r10m /= -ref10u)) STOP 15
> 
> (gdb) p rnd10
> $1 = .TRUE.
> (gdb) p r10p
> $2 = 0.15551
> (gdb) p ref10u
> $3 = 0.10001
> (gdb) p r10m
> $4 = -0.15551
> (gdb) p ref10u
> $5 = 0.10001

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
COMDAT is implemented in different ways.  If it is through the ELF comdat
groups, then in theory this can be handled, by putting the COMDAT variable
(from template instantiation, or inline variable, static var in inline function
etc.) into the section with the given name and use the comdat group we would
normally use.
If ELF comdat groups aren't supported, then we use .gnu.linkonce.* sections and
in that case it can't be really supported.  Nor in the non-ELF cases...

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:8d689cf43b501a2f5c077389adbb6d2bfa530ca9

commit r10-7415-g8d689cf43b501a2f5c077389adbb6d2bfa530ca9
Author: Kewen Lin 
Date:   Fri Mar 27 04:51:12 2020 -0500

Fix PR90332 by extending half size vector mode

As PR90332 shows, the current scalar epilogue peeling for gaps
elimination requires expected vec_init optab with two half size
vector mode.  On Power, we don't support vector mode like V8QI,
so can't support optab like vec_initv16qiv8qi.  But we want to
leverage existing scalar mode like DI to init the desirable
vector mode.  This patch is to extend the existing support for
Power, as evaluated on Power9 we can see expected 1.9% speed up
on SPEC2017 525.x264_r.

As Richi suggested, add one function vector_vector_composition_type
to refactor existing related codes and also make use of it further.

Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8 and P9,
as well as x86_64-redhat-linux.

gcc/ChangeLog

2020-03-27  Kewen Lin  

PR tree-optimization/90332
* tree-vect-stmts.c (vector_vector_composition_type): New function.
(get_group_load_store_type): Adjust to call
vector_vector_composition_type,
extend it to construct with scalar types.
(vectorizable_load): Likewise.

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

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #9 from Kewen Lin  ---
Should be fixed by latest trunk on ppc64le P9.

[Bug fortran/93957] [10 Regression] ICE (regression) passing assumed rank arrays with bind(c)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:62ede14d30f5d083f1ab23bcab6e0e3c9c649006

commit r10-7416-g62ede14d30f5d083f1ab23bcab6e0e3c9c649006
Author: Tobias Burnus 
Date:   Fri Mar 27 12:12:36 2020 +0100

[Fortran] Fix ICE with deferred-rank arrays (PR93957)

PR fortran/93957
* trans-array.c (gfc_alloc_allocatable_for_assignment): Accept
nonallocatable, nonpointer deferred-rank arrays.

PR fortran/93957
* gfortran.dg/assumed_rank_19.f90: New.

[Bug fortran/93957] [10 Regression] ICE (regression) passing assumed rank arrays with bind(c)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Tobias Burnus  ---
FIXED on the trunk / GCC 10.

Thanks for the report!

[Bug web/94351] bugzilla search is not as useful as before

[LpSolit at gmail dot com]

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

--- Comment #4 from Frédéric Buclin  ---
(In reply to Jonathan Wakely from comment #2)
> Where?

You are right. These fields are missing.

[Bug analyzer/94355] New: support for C++ new expression

[vanyacpp at gmail dot com]

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

Bug ID: 94355
   Summary: support for C++ new expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

At the moment static analyzer warns about leaked malloc. It would be great if
C++ new expression were also supported.

Example:

void f()
{
char* p = new char;
}

Expected diagnostic:

warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]

3 | char* p = new char;

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[bikineev at google dot com]

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

--- Comment #10 from Anton  ---
I think there are two ways to handle the problem for targets that don't support
COMDAT:
1) issue a diagnostic that the section attribute will be ignored (because it'll
go to .gnu.linkone.*);
2) fallback to weak symbols (which IIUC would be not space efficient).

[Bug analyzer/94355] support for C++ new expression

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is already being actively discussed, and will probably be a GSoC project.

[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Why is LOCAL_DECL_ALIGNMENT not applied during layout_decl?  (I realize for
offloading this might be suboptimal)

[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
For offloading it is very harmful.  Which is why I'd strongly prefer to do it
after IPA, on the other side doing it at expansion time is too late.

[Bug tree-optimization/94352] Suspicious code in tree-ssa-propagate.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:917e21e8bcddf5047ee0ced063fca412ad81ce7f

commit r10-7417-g917e21e8bcddf5047ee0ced063fca412ad81ce7f
Author: Richard Biener 
Date:   Fri Mar 27 13:52:31 2020 +0100

tree-optimization/94352 - fix uninitialized use of curr_order

This fixes a (harmless) use of a not re-initialized curr_order.

2020-03-27  Richard Biener  

PR tree-optimization/94352
* tree-ssa-propagate.c (ssa_prop_init): Move seeding of the
worklist ...
(ssa_propagation_engine::ssa_propagate): ... here after
initializing curr_order.

[Bug tree-optimization/94352] Suspicious code in tree-ssa-propagate.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:45cfaf9903d3f5aa916d330f2013eb7d820a7137

commit r10-7418-g45cfaf9903d3f5aa916d330f2013eb7d820a7137
Author: Richard Biener 
Date:   Fri Mar 27 13:57:42 2020 +0100

debug/94273 - avoid creating type DIEs for DINFO_LEVEL_TERSE

This avoids completing types for DINFO_LEVEL_TERSE by using
the should_emit_struct_debug machinery.

2020-03-27  Richard Biener  

PR debug/94273
* dwarf2out.c (should_emit_struct_debug): Return false for
DINFO_LEVEL_TERSE.

* g++.dg/debug/pr94273.C: New testcase.

[Bug tree-optimization/94356] New: Missed optimisation: useless multiplication generated for pointer comparison

[pascal_cuoq at hotmail dot com]

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

Bug ID: 94356
   Summary: Missed optimisation: useless multiplication generated
for pointer comparison
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

The closest existing ticket I found for this one is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48316 but this seems different
enough, although it might be linked.

Consider the function:

typedef int t[10];

int f(t *p, long long o) {
return p < p+o;
}

GCC 9.3 with -O2, targeting x86-64, correctly simplifies by p, but still
generates a 64x64->64 multiplication in the computation of the offset:

f:
imulq   $40, %rsi, %rsi
xorl%eax, %eax
testq   %rsi, %rsi
setg%al
ret

(Compiler Explorer link: https://gcc.godbolt.org/z/_pT8E- )

Clang 10 avoids generating the multiplication on this example:

f:  # @f
xorl%eax, %eax
testq   %rsi, %rsi
setg%al
retq

A variant of this example is this other function g with two offsets:

int g(t *p, long long o1, long long o2) {
return p+o1 < p+o2;
}

Clang generates the same code as for “o1https://gcc.godbolt.org/z/sDJyHP

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[huaixin....@alibaba-inc.com]

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

--- Comment #10 from huaixin chang  ---
(In reply to Richard Biener from comment #9)
> Btw,
> 
> struct X {
> long a __attribute__((__aligned__(128)));
> long b __attribute__((__aligned__(128)));
> };
> struct X A __attribute__((__aligned__(4)));
> 
> is not diagnosed (this is what your testcase is, decomposed).
> 
> I can't reproduce the diagnostics you describe in comment#5

I am sorry that I made a mistake in testing typedef described in comment#5.

I spelled __aligned__ into __aligned, got warned "warning: '__aligned'
attribute directive ignored [-Wattributes]", and thought I got diagnosed
because of reduction in alignment. As a result, neither type foo nor object A
is reduced in alignment with the code describe in comment#5.

I have tested typedef again, and found that it behaves the same with using
struct under gcc 9.2.1. That is to say, no matter I define A using struct like:

---
struct X {
long a __attribute__((__aligned__(128)));
long b __attribute__((__aligned__(128)));
};
struct X A __attribute__((__aligned__(4)));

or use typedef and reduce the alignment of type foo like:
---
typedef struct {
long a __attribute__((__aligned__(128)));
long b __attribute__((__aligned__(128)));
} foo __attribute__((__aligned(4)));

foo A;

or use typedef and reduce the alignment of A like:
---
typedef struct {
long a __attribute__((__aligned__(128)));
long b __attribute__((__aligned__(128)));
} foo;

foo A __attribute__((__aligned__(4)));

I got no warn on compiling and it behaves like this.
---
address of A 0x42003c
alignof A 4
address of A.a 0x42003c
alignof A.a 128
address of A.b 0x4200bc
alignof A.b 128
address of B 0x420038

[Bug tree-optimization/94357] New: Inline assembly with memory operand is considered nothrow with `-fnon-call-exceptions`

[sagebar at web dot de]

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

Bug ID: 94357
   Summary: Inline assembly with memory operand is considered
nothrow with `-fnon-call-exceptions`
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

Created attachment 48130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48130&action=edit
Issue demonstration

The documentation of `-fnon-call-exceptions`
(https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fnon-call-exceptions)
states that any instruction with a "memory references" is allowed to throw a
c++ exception (or in other words: do what essentially boils down to performing
a CFI unwind, and calling `__gxx_personality_v0()` without that function
calling `std::terminate()` because the faulting PC isn't allowed to trap)

However, from what I can tell by looking at the GCC sources
(gcc/tree-eh.c:tree_could_trap_p(); case ASM_EXPR), GCC only considers an
`asm()` statement as being able to cause a non-call-exception (i.e. trap) when
written as `asm volatile()`.

Given the fact that "memory references" is listed as one of the possible
reasons for an instruction to be trapable, it stands reason that any inline
assembly statement that uses memory operands (i.e. `asm("..." : "=m" (...))` or
`asm("..." : : "m" (...))`), as well as any assembly statement that specifies
"memory" as part of its clobber list (i.e. `asm("..." : : : "memory")`) should
also be considered as potentially containing instructions that may trap.

Note also that during my investigation I've noticed that the catch(...) block
is fully optimized away in the following case ... (`gcc -S` does contain `/*
Hello */`, but doesn't contain `/* World! */`):
```c
void foo() {
try {
__asm__ __volatile__("/* Hello */");
} catch (...) {
__asm__("/* World! */");
}
}
```

... but isn't optimized away when the first `__asm__ __volatile__` is placed in
an inline function (`gcc -S` does contains both `/* Hello */` and `/* World!
*/`):
```c
inline void bar() {
__asm__ __volatile__("/* Hello */");
}
void foo() {
try {
bar();
} catch (...) {
__asm__("/* World! */");
}
}
```


The attached file shows the different cases where `__asm__` appears in `try ...
catch`, and should be compiled as follows (note that -O* flags don't have any
affect on which catch-statements get deleted; -O0 has the same output as -O3):
$ g++ -S -x c++ -fnon-call-exceptions attaced-file.cc -o - | grep "reference"

The current output is:```
callmust_reference_1
```

A consistent output (with the current rules concerning __volatile__) would look
like:```
callmust_reference_1
callmust_reference_2
callmust_reference_3
```

And an output consistent with published documentation would look like:```
callmust_reference_1
callmust_reference_2
callmust_reference_3
callmust_reference_4
callmust_reference_5
callmust_reference_6
```

[Bug fortran/94358] New: [OMP] Privatize internal array variables introduced by the Fortran FE

[tschwinge at gcc dot gnu.org]

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

Bug ID: 94358
   Summary: [OMP] Privatize internal array variables introduced by
the Fortran FE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, 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
  Target Milestone: ---

This is discussed in context of OpenACC, but I suppose also applies to OpenMP?


Just "a while ago", Cesar submitted for gomp-4_0-branch in
 "[gomp4]
privatize internal array variables introduced by the fortran FE", and
committed:

gomp-4_0-branch, openacc-gcc-7-branch commit
fb7036c540273b8da507dac254f5fcf2033a8fb1
Author: cesar 
AuthorDate: Tue Oct 13 20:17:47 2015 +
Commit: cesar 
CommitDate: Tue Oct 13 20:17:47 2015 +

gcc/fortran/
* trans-array.c (gfc_trans_array_bounds): Add an INIT_VLA
argument
to control whether VLAs should be initialized.  Don't mark this
function as static.
(gfc_trans_auto_array_allocation): Update call to
gfc_trans_array_bounds.
(gfc_trans_g77_array): Likewise.
* trans-array.h: Declare gfc_trans_array_bounds.
* trans-openmp.c (gfc_scan_nodesc_arrays): New function.
(gfc_privatize_nodesc_arrays_1): New function.
(gfc_privatize_nodesc_arrays): New function.
(gfc_init_nodesc_arrays): New function.
(gfc_trans_oacc_construct): Initialize any internal variables
for
arrays without array descriptors inside the offloaded parallel
and
kernels region.
(gfc_trans_oacc_combined_directive): Likewise.

gcc/testsuite/
* gfortran.dg/goacc/default_none.f95: New test.

git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@228782
138bc75d-0d04-0410-961f-82ee72b054a4

 gcc/fortran/ChangeLog.gomp   |  18 ++
 gcc/fortran/trans-array.c|  12 +++-
 gcc/fortran/trans-array.h|   2 ++
 gcc/fortran/trans-openmp.c   | 179
---
 gcc/testsuite/ChangeLog.gomp |   4 
 gcc/testsuite/gfortran.dg/goacc/default_none.f95 |  59
+++
 6 files changed, 266 insertions(+), 8 deletions(-)

Later, a bug fix got submitted for gomp-4_0-branch in
 "[gomp4] arrays
inside modules" (but wrong patch file attached), and committed:

gomp-4_0-branch, openacc-gcc-7-branch commit
b9a99e0c7b39ab4b82f5dd148923f03c0dba7aa4
commit b9a99e0c7b39ab4b82f5dd148923f03c0dba7aa4
Author: cesar 
AuthorDate: Wed Jan 13 01:43:16 2016 +
Commit: cesar 
CommitDate: Wed Jan 13 01:43:16 2016 +

gcc/fortran/
* trans-openmp.c (gfc_privatize_nodesc_arrays): Use
gfc_get_symbol_decl instead of accessing backend_decl directly.

gcc/testsuite/
* gfortran.dg/goacc/mod-array.f90: New test.

git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@232307
138bc75d-0d04-0410-961f-82ee72b054a4

 gcc/fortran/ChangeLog.gomp|  5 +
 gcc/fortran/trans-openmp.c|  2 +-
 gcc/testsuite/ChangeLog.gomp  |  4 
 gcc/testsuite/gfortran.dg/goacc/mod-array.f90 | 23 +++
 4 files changed, 33 insertions(+), 1 deletion(-)

These two got merged in og8:

openacc-gcc-8-branch commit be4fecc76b4166e4af6bd1d9646393830ba28df4
commit be4fecc76b4166e4af6bd1d9646393830ba28df4
Author: Cesar Philippidis 
AuthorDate: Tue Oct 13 20:17:47 2015 +
Commit: Thomas Schwinge 
CommitDate: Wed May 23 08:36:03 2018 +0200

Privatize internal array variables introduced by the fortran FE

gcc/fortran/
* trans-array.c (gfc_trans_array_bounds): Add an INIT_VLA
argument
to control whether VLAs should be initialized.  Don't mark this
function as static.
(gfc_trans_auto_array_allocation): Update call to
gfc_trans_array_bounds.
(gfc_trans_g77_array): Likewise.
* trans-array.h: Declare gfc_trans_a

[Bug fortran/94358] [OMP] Privatize internal array variables introduced by the Fortran FE

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
To help with OpenACC 'kernels' support, Gergő later submitted for og8 an
additional change in

"Rework OpenACC Fortran DO loop initialization", and committed:

openacc-gcc-8-branch commit 7c2f3f5c50e029bec704605b065d63273c2425dd
Author: Gergö Barany 
AuthorDate: Mon Jan 21 03:08:57 2019 -0800
Commit: Gergö Barany 
CommitDate: Tue Jan 29 05:21:14 2019 -0800

Rework OpenACC Fortran DO loop initialization

Fortran DO loops on arrays with non-constant bounds (like a(lo:hi))
need
special setup code to compute the bounds and offsets for the iteration.
In
an OpenACC region containing multiple loops, this used to be done in a
block
of code at the start of the region for all of the loops. But the
upcoming
kernels conversion expects this kind of setup code to immediately
precede
the corresponding loop, and variables are not mapped correctly
otherwise.
This patch separates out the initialization part for each loop and
places it
immediately before the loop.

gcc/fortran/
* trans-openmp.c (gfc_privatize_nodesc_array_clauses): Renamed from
gfc_privatize_nodesc_arrays, initialization part factored out to...
(gfc_reinitialize_privatized_arrays): ... this new function,
called...
(gfc_trans_omp_do): ... from here for OpenACC loops.

libgomp/
* testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: New
test.

Reviewed-by: Thomas Schwinge 

 gcc/fortran/ChangeLog.openacc   |  7
+++
 gcc/fortran/trans-openmp.c  | 86
++
 libgomp/ChangeLog.openacc   |  4

 libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90 | 36

 4 files changed, 97 insertions(+), 36 deletions(-)

(I did approve that for the og8 development branch, but had not actually
reviewed.)

This patch did not make it into og9 either (obviously, as it depends on the
other one).

Comparing the previous dumps to this "Rework OpenACC Fortran DO loop
initialization" variant (no og8 commits reverted):

In the 'original' dump, we now again see the 'private' clauses disappear (so,
same as in the "baseline" variant) -- yet the re-computation of 'offset.5' as
well as 'D.3818' remaining inside the region, "unprivatized".

In the 'gimple' dump, we then see 'firstprivate(size.6) firstprivate(offset.5)
firstprivate(stride.4) firstprivate(ubound.3) firstprivate(lbound.2)
firstprivate(ubound.1) firstprivate(lbound.0)' appear (supposedly due to
implicit 'firstprivate' inside OpenACC 'parallel'?) -- huh, that doesn't seem
right, given that the point was to avoid all these 'firstprivate' (data
transfers)!  (..., and for OpenACC 'kernels', these would all be implicit
'copy', thus global device data, slow, and prone to race-conditions -- so, much
worse?)

That doesn't seem to make sense, and will need further investigation.  But
let's first concentrate on the "Privatize internal array variables introduced
by the fortran FE" changes alone.

[Bug fortran/94358] [OMP] Privatize internal array variables introduced by the Fortran FE

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org
   Last reconfirmed||2020-03-27
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug tree-optimization/94356] Missed optimisation: useless multiplication generated for pointer comparison

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
That's because internally we use an unsigned type for offsets (including for
the multiplication). There have been tries to change that...

[Bug tree-optimization/94329] [8/9/10 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|debug   |tree-optimization

[Bug tree-optimization/94329] [8/9/10 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Untested fix.

[Bug c++/94257] ICE in inline nested namespace

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:9dba60130dc3ebf7cce8716a36672281688693f7

commit r10-7423-g9dba60130dc3ebf7cce8716a36672281688693f7
Author: Nathan Sidwell 
Date:   Fri Mar 27 07:54:33 2020 -0700

c++: Fix ICE after ambiguous inline namespace reopen [PR94257]

Following DR2061, 'namespace F', looks for 'F's inside inline namespaces.
That can result in ambiguous lookups that we failed to diagnose early
enough,
leading us to push a new namespace and ICE later.  Diagnose the ambiguity
earlier, and then pick one.

PR c++/94257
* name-lookup.c (push_namespace): Triage ambiguous lookups that
contain namespaces.

[Bug c++/94257] ICE in inline nested namespace

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed 9dba60130dc3ebf7cce8716a36672281688693f7

[Bug tree-optimization/94356] Missed optimisation: useless multiplication generated for pointer comparison

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Given
struct S { char a[37]; };
int f1 (struct S *s, int a) { struct S *sa = s + a; return s < sa; }
int f2 (struct S *s, int a, int b) { struct S *sa = s + a; return sa < s + b; }
int f3 (struct S *s, int a) { struct S *sa = s + a; return s == sa; }
int f4 (struct S *s, int a, int b) { struct S *sa = s + a; return sa == s + b;
}
f3 is optimized in:
/* X + Y < Y is the same as X < 0 when there is no overflow.  */
...
/* For equality, this is also true with wrapping overflow.  */
...
 (simplify
  (op:c (nop_convert?@3 (pointer_plus@2 (convert1? @0) @1)) (convert2? @0))
  (if (tree_nop_conversion_p (TREE_TYPE (@2), TREE_TYPE (@0))
   && tree_nop_conversion_p (TREE_TYPE (@3), TREE_TYPE (@0))
   && (CONSTANT_CLASS_P (@1) || (single_use (@2) && single_use (@3
   (op @1 { build_zero_cst (TREE_TYPE (@1)); }
f4 is optimized too, but not exactly sure where, partly e.g. in
/* For integral types with wrapping overflow and C odd fold
   x * C EQ/NE y * C into x EQ/NE y.  */
(for cmp (eq ne)
 (simplify
  (cmp (mult @0 INTEGER_CST@1) (mult @2 @1))
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
   && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
   && (TREE_INT_CST_LOW (@1) & 1) != 0)
   (cmp @0 @2
For f1/f2 we likely only optimize the ptr + x < ptr + y into x < y at RTL time,
and in any case, the multiplications are done right now in sizetype which is
unsigned type.

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

--- Comment #5 from Stephen Hemminger  ---
Created attachment 48132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48132&action=edit
Preprocessed version of source code

[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to markeggleston from comment #3)
> A patch from Steve Kargl was sent to the fortran mailing list, (see
> https://gcc.gnu.org/pipermail/fortran/2020-March/054130.html) without
> reference to any PR.
> 
> It appeared to be related to this PR. I have verified the patch and also
> checked it with the test case in the original report.

Techinically, it is related to 

https://stackoverflow.com/questions/60846187/fortran-equivalence-statement-with-array-length-from-subroutine-input

In the stackoverflow thread, someone mentioned this is a regression going back
to at least 6.5.

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

--- Comment #6 from Stephen Hemminger  ---
$ gcc --version
gcc (GCC) 10.0.1 20200311 (Red Hat 10.0.1-0.9)

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

--- Comment #7 from Stephen Hemminger  ---
Verbose make output shows compiler flags

gcc -Wp,-MD,./.eal_memalloc.o.d.tmp  -m64 -pthread
-I/home/shemminger/DPDK/upstream/lib/librte_eal/linux/eal/include 
-march=native -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2
-DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3
-DRTE_MACHINE_CPUFLAG_SSE4_1 -DRTE_MACHINE_CPUFLAG_SSE4_2
-DRTE_MACHINE_CPUFLAG_AES -DRTE_MACHINE_CPUFLAG_PCLMULQDQ
-DRTE_MACHINE_CPUFLAG_AVX -DRTE_MACHINE_CPUFLAG_RDRAND
-DRTE_MACHINE_CPUFLAG_RDSEED -DRTE_MACHINE_CPUFLAG_FSGSBASE
-DRTE_MACHINE_CPUFLAG_F16C -DRTE_MACHINE_CPUFLAG_AVX2 
-I/home/shemminger/DPDK/upstream/build/include -DRTE_USE_FUNCTION_VERSIONING
-include /home/shemminger/DPDK/upstream/build/include/rte_config.h
-D_GNU_SOURCE -DALLOW_EXPERIMENTAL_API
-I/home/shemminger/DPDK/upstream/lib/librte_eal/linux/eal/include
-I/home/shemminger/DPDK/upstream/lib/librte_eal/common
-I/home/shemminger/DPDK/upstream/lib/librte_eal/common/include -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs
-Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings
-Wdeprecated -Werror -Wno-missing-field-initializers -Wimplicit-fallthrough=2
-Wno-format-truncation -Wno-address-of-packed-member -O3   -fanalyzer -o
eal_memalloc.o -c
/home/shemminger/DPDK/upstream/lib/librte_eal/linux/eal/eal_memalloc.c 
during IPA pass: analyzer
cc1: internal compiler error: in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4874
Please submit a full bug report,
with preprocessed source if appropriate.

Support More Than 10452 Families All Over Lebanon

[Banin Charity Association]

 Email not displaying correctly? View it in your browser | Share it
 You are seeing this Email in Plain Text Version; Switch to HTML or Click this 
link http://dits.ws/a/44654 to View it properly.

http://www.spx-em.com/url/u8nGvLduh5R6hJJpe5rKzMl6pqrCvMO1tKW7vcfOgLu2sHmFm7e6aXuawsO-tbKumMLDs8CtuMJ5yLq7uLK4kImGgnl9
 

 Subscription Information:
 This email was sent to gcc-bugs@gcc.gnu.org because you are Subscribed to 
Kuwait List
 Click Here to permanently Unsubscribe from this List.

 Sent to you by:
 DIGITAL ITS | Tel: +961 5 464 323

 
 

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed with r10-7168-g5c048755ec98645f.

[gnu.org #1509189] [wwwdocs] https://www.gnu.org/software/gcc/git.html gives internal server error

[Therese Godefroy via RT]

Hello GCC maintainers,

The same sort of error was reported by Jake Vossen on January 17
(gnu.org #1465799): 

"On the home page of gcc (https://www.gnu.org/software/gcc/) if you
click on 'Git' on the right hand side it takes you to
https://www.gnu.org/software/gcc/git.html, which is giving me an
internal server error."

Thanks in advance for looking into this.

Best regards,
Thérèse

Le Ven 27 Mar 2020 10:26:02, ten...@iseries-guru.com a écrit :
> Hello,
> 
> Around 2020-03-27 1409 GMT, on page "GCC 4.1 Release Series"
> , I clicked link "our 
> version control system" .
> The site presented error page "Internal Server Error", which asks
> me to contact you.
> 
> I you this is helpful.
> 
> Terry.
> 
> 
> 

[Bug c++/93810] missing -Wmismatched-tags and -Wredundant-tags on a typedef of an implicit class template specialization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:04dd734b52de121853e1ea6b3c197a598b294e23

commit r10-7424-g04dd734b52de121853e1ea6b3c197a598b294e23
Author: Martin Sebor 
Date:   Fri Mar 27 12:07:45 2020 -0400

c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also improves the detection
of both issues in template declarations.

gcc/cp/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* cp-tree.h (most_specialized_partial_spec): Declare.
* parser.c (cp_parser_elaborated_type_specifier): Distinguish alias
from declarations.
(specialization_of): New function.
(cp_parser_check_class_key): Move code...
(class_decl_loc_t::add): ...to here.  Add parameters.  Avoid
issuing
-Wredundant-tags on first-time declarations in other declarators.
Correct handling of template specializations.
(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
when -Wredundant-tags is enabled.  Use primary template or partial
specialization as the guide for uses of implicit instantiations.
* pt.c (most_specialized_partial_spec): Declare extern.

gcc/testsuite/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* g++.dg/warn/Wmismatched-tags-3.C: New test.
* g++.dg/warn/Wmismatched-tags-4.C: New test.
* g++.dg/warn/Wmismatched-tags-5.C: New test.
* g++.dg/warn/Wmismatched-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
* g++.dg/warn/Wredundant-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-7.C: New test.

[Bug c++/94078] bogus and missing -Wmismatched-tags on an instance of a template

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:04dd734b52de121853e1ea6b3c197a598b294e23

commit r10-7424-g04dd734b52de121853e1ea6b3c197a598b294e23
Author: Martin Sebor 
Date:   Fri Mar 27 12:07:45 2020 -0400

c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also improves the detection
of both issues in template declarations.

gcc/cp/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* cp-tree.h (most_specialized_partial_spec): Declare.
* parser.c (cp_parser_elaborated_type_specifier): Distinguish alias
from declarations.
(specialization_of): New function.
(cp_parser_check_class_key): Move code...
(class_decl_loc_t::add): ...to here.  Add parameters.  Avoid
issuing
-Wredundant-tags on first-time declarations in other declarators.
Correct handling of template specializations.
(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
when -Wredundant-tags is enabled.  Use primary template or partial
specialization as the guide for uses of implicit instantiations.
* pt.c (most_specialized_partial_spec): Declare extern.

gcc/testsuite/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* g++.dg/warn/Wmismatched-tags-3.C: New test.
* g++.dg/warn/Wmismatched-tags-4.C: New test.
* g++.dg/warn/Wmismatched-tags-5.C: New test.
* g++.dg/warn/Wmismatched-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
* g++.dg/warn/Wredundant-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-7.C: New test.

[Bug c++/93824] bogus -Wredundant-tags on a first declaration in use

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:04dd734b52de121853e1ea6b3c197a598b294e23

commit r10-7424-g04dd734b52de121853e1ea6b3c197a598b294e23
Author: Martin Sebor 
Date:   Fri Mar 27 12:07:45 2020 -0400

c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also improves the detection
of both issues in template declarations.

gcc/cp/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* cp-tree.h (most_specialized_partial_spec): Declare.
* parser.c (cp_parser_elaborated_type_specifier): Distinguish alias
from declarations.
(specialization_of): New function.
(cp_parser_check_class_key): Move code...
(class_decl_loc_t::add): ...to here.  Add parameters.  Avoid
issuing
-Wredundant-tags on first-time declarations in other declarators.
Correct handling of template specializations.
(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
when -Wredundant-tags is enabled.  Use primary template or partial
specialization as the guide for uses of implicit instantiations.
* pt.c (most_specialized_partial_spec): Declare extern.

gcc/testsuite/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* g++.dg/warn/Wmismatched-tags-3.C: New test.
* g++.dg/warn/Wmismatched-tags-4.C: New test.
* g++.dg/warn/Wmismatched-tags-5.C: New test.
* g++.dg/warn/Wmismatched-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
* g++.dg/warn/Wredundant-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-7.C: New test.

[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug middle-end/86715] ICE passing too large argument on stack

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Segher Boessenkool  ---
"struct Matrix" is over 2GB big.  The whole stack is just a few megabytes
typically.  Passing "struct Matrix" on the stack is entirely unreasonable.

The comment right before this sorry() is
  /* We don't allow passing huge (> 2^30 B) arguments
 by value.  It would cause an overflow later on.  */
and this is in generic code.

Closing as WONTFIX.  Sorry.

[Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 94359
   Summary: new test case
g++.dg/coroutines/torture/symmetric-transfer-00-basic.
C fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O0  (test for
excess errors)
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O1  (test for
excess errors)
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2  execution
test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O3 -g 
execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -Os  execution
test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C (test for excess
errors)

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-pedantic-errors -Wno-long-long -std=c++17 -fcoroutines
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./symmetric-transfer-00-basic.exe
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
In function 'void _Z8pingpongPKc.actor(pingpong(const
char*)::_Z8pingpongPKc.frame*)':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:75:1:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
compiler exited with status 1

[Bug ipa/94360] New: 6% run-time regression of 502.gcc_r against GCC 9 when compiled with -O2 and both PGO and LTO

[jamborm at gcc dot gnu.org]

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

Bug ID: 94360
   Summary: 6% run-time regression of 502.gcc_r against GCC 9 when
compiled with -O2 and both PGO and LTO
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When built at -O2, generic march/mtune and with both PGO and LTO and
current trunk/master, SPEC 2017 INTrate 502.gcc_r is 6% slower when
run on and AMD Zen2-based CPU - and about 4.8% slower on Intel Cascade
Lake.

Looking at how the run-time of the benchmark evolved over the course
of GCC 10 development cycle, the first and biggest regression (9%)
comes with:

  commit 2925cad2151842daa387950e62d989090e47c91d
  Author: Jan Hubicka 
  Date:   Thu Oct 3 17:08:21 2019 +0200

params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT, [...]): New.

* params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT,
PARAM_INLINE_HEURISTICS_HINT_PERCENT_O2): New.
* doc/invoke.texi (inline-heuristics-hint-percent,
inline-heuristics-hint-percent-O2): Document.
* tree-inline.c (inline_insns_single, inline_insns_auto): Add new
hint attribute.
(can_inline_edge_by_limits_p): Use it.

   From-SVN: r276516

Then between Wed Nov 6 (72d6aeecd95) and Mon Nov 18 (58c036c8354) it
improved to about 103% of GCC 9 run-time (I did not exactly found what
caused it because in much of this range the compiler was segfaulting
in the LTO phase).  Eventually, the benchmark regresses to current
106% of GCC 9 run-time with Honza's:

  - 9340d34599e Convert inliner to function specific param infrastructure, or
  - 1e83bd7003e Convert inliner to new param infrastructure.

The former cannot be built without the latter.

Symbol profiles are:

trunk (26b3e568a60):
  OverheadSamples  Shared Object Symbol 
    .   


 4.04%  42371  cpugcc_r_peak.pgolto  bitmap_ior_into
 2.91%  30281  cpugcc_r_peak.pgolto  df_worklist_dataflow
 2.24%  23342  cpugcc_r_peak.pgolto  df_note_compute
 1.92%  20120  cpugcc_r_peak.pgolto  bitmap_set_bit
 1.75%  18148  cpugcc_r_peak.pgolto  rest_of_handle_fast_dce.lto_priv.0
 1.58%  16580  libc-2.31.so  __memset_avx2_unaligned_erms
 1.40%  14514  cpugcc_r_peak.pgolto  extract_new_fences_from.lto_priv.0
 1.39%  14732  libc-2.31.so  _int_malloc
 1.33%  13824  cpugcc_r_peak.pgolto  bitmap_copy
 1.24%  12962  cpugcc_r_peak.pgolto  bitmap_bit_p
 1.19%  12346  cpugcc_r_peak.pgolto  bitmap_and
 1.18%  12242  cpugcc_r_peak.pgolto  df_lr_local_compute.lto_priv.0
 1.02%  10618  cpugcc_r_peak.pgolto  cleanup_cfg.isra.0


vs gcc 9 (releases/gcc-9.3.0):


  OverheadSamples  Shared Object Symbol 
    .   
.

 6.81%  66967  cpugcc_r_peak.pgolto  df_worklist_dataflow
 2.83%  28063  cpugcc_r_peak.pgolto  bitmap_ior_into
 2.80%  27489  cpugcc_r_peak.pgolto  df_note_compute.lto_priv.0
 2.17%  21334  cpugcc_r_peak.pgolto  rest_of_handle_fast_dce.lto_priv.0
 1.69%  16671  libc-2.31.so  __memset_avx2_unaligned_erms
 1.51%  14876  cpugcc_r_peak.pgolto  try_optimize_cfg.lto_priv.0
 1.50%  14990  libc-2.31.so  _int_malloc
 1.50%  14715  cpugcc_r_peak.pgolto  extract_new_fences_from.lto_priv.0
 1.36%  13406  cpugcc_r_peak.pgolto  df_lr_local_compute.lto_priv.0
 1.20%  11926  cpugcc_r_peak.pgolto  remove_unused_locals
 1.06%  10433  cpugcc_r_peak.pgolto  sched_analyze_insn
 1.04%  10210  cpugcc_r_peak.pgolto  init_alias_analysis
 1.04%  10188  cpugcc_r_peak.pgolto  prescan_insns_for_dce.lto_priv.0
 1.00%   9876  cpugcc_r_peak.pgolto  compute_transp


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
void bar ();

void
foo (char a)
{
  union C { int d[100.0]; char *e; };
  bar ((union C) &a);
}

[Bug fortran/94361] New: Memory leak in nested types with final

[antony at cosmologist dot info]

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

Bug ID: 94361
   Summary: Memory leak in nested types with final
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antony at cosmologist dot info
  Target Milestone: ---

The code below leaks memory (mem grows with each loop interation), but does not
if the "FINAL" is commented. The issue is also present in trunk (10.0.1
20200218), and may be a reduced test case for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 (in which case the problem
was introduced around 8.3.1, but I have not tested versions extensively).


module debug
private

Type TypeWithFinal
contains
FINAL :: finalizer  !No leak if this line is commented
end type

Type Tester
real, dimension(:), allocatable :: Dat
Type(TypeWithFinal) :: X
end Type

Type :: TestType2
Type(Tester) :: T
end type TestType2
public Leaker
contains

subroutine Leaker
type(TestType2) :: Test

allocate(Test%T%Dat(1))
end subroutine

subroutine finalizer(this)
Type(TypeWithFinal) :: this
end subroutine finalizer

end module


program run
use debug
implicit none
integer i

do i=1, 1
call Leaker()
call sleep(1)
end do

end program

[Bug analyzer/94362] New: False analyzer report due to i >= 0 and i < 0 on openssl

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 94362
   Summary: False analyzer report due to i >= 0 and i < 0 on
openssl
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48134&action=edit
Reduced test case

https://github.com/openssl/openssl/issues/11420 reports what looks like a false
positive:
  crypto/asn1/ameth_lib.c:131:18: error: dereference of NULL 'ameth' [CWE-690]
[-Werror=analyzer-null-dereference]

where on the path to the diagnostic i >= 0 and i < 0, which ought to be
rejected by constraint-checking.

I'm attaching a somewhat simplified reproducer.

[Bug ipa/94360] 6% run-time regression of 502.gcc_r against GCC 9 when compiled with -O2 and both PGO and LTO

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Unfortunately, the mentioned configuration is not tested on LNT periodic
benchmarks.

[Bug tree-optimization/94356] Missed optimisation: useless multiplication generated for pointer comparison

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
I tried https://gcc.gnu.org/pipermail/gcc-patches/2017-May/475037.html some
time ago. Having a different type for the multiplication and the offsetting
introduced a lot of NOPs and caused a few regressions (from my notes,
pta-ptrarith-3.c and ssa-pre-8.c were just testsuite issues, but there were
others). I filed a bug or 2 about those (PR 88926 at least). Then I tried to
also make the offsets signed, to be consistent, but that's a much bigger piece
and I ran out of time and motivation.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Iain Sandoe  ---
There are two cases here.

1) When the optimisation level is < 2 (where GCC does not normally tail-call).

 - in that case, the specific call [ which is in the tail position, and AFAIU
should be tail-callable ] is marked as TAIL_CALL, MUST_TAIL_CALL (hence the
complaint error: cannot tail-call: target is not able to optimize the call into
a sibling call, I suppose).

2) for O >= 2 where GCC would normally tail call anyway
 - for this, the coroutine code does not mark the cll specially, so for these
cases it indicates that the tail-call is not being made in "normal"
circumstance.

the function signature is

 void actor (void *)

and the codgen should be emitting an indirect call, followed by a void return 

(the indirect call is expanding __builtin_coro_resume() [expansion happens very
early in the ME].

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
it is not mandatory (for C++20 compliance) that the implementation provides
symmetric transfer - so it could be switched off - or XFAILed. 

However, users state that an impl. that can't do the symmetric transfers is not
useful in a number of important applications.

[Bug c/94363] New: possible typo: attribute attribute

[roland.illig at gmx dot de]

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

Bug ID: 94363
   Summary: possible typo: attribute attribute
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

>From cgraphunit.c:
> warning_at (DECL_SOURCE_LOCATION (node->decl), OPT_Wattributes,
> "%"
> " attribute attribute is ignored on aliases");

Either the "attribute attribute" is a typo, or it is a bad word play that I
don't understand. Whatever it is, it should be corrected.

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[felix.von.s at posteo dot de]

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

felix  changed:

   What|Removed |Added

 CC||felix.von.s at posteo dot de

--- Comment #1 from felix  ---
> Unfortunately the macro trick is arcane and has one potential issue: the 
> compiler may actually generate code to check `cond` at run-time if it cannot 
> deduce that it's a pure function.

Oh, don't worry; the Other Compiler’s solution isn’t perfect either :)

__builtin_assume(({ for (;;) {}; 1; }));

This emits code for the infinite loop. For a less silly example:

__attribute__((__const__,__always_inline__))
inline static int is_pow2(unsigned j) {
__auto_type i = j;

for (int c = 0; c < CHAR_BIT * sizeof(i); ++c) {
i = (i >> 1) | ((i & 1) << (CHAR_BIT * sizeof(i) - 1));
if (i == 1)
break;
}

return i == 1;
}

int foo(void) {
extern unsigned bar(void);
__auto_type x = bar();

__builtin_assume(is_pow2(x));

return __builtin_popcount(x);
}

This will also emit code for the loop, even though the result is not used at
runtime. The code is not very idiomatic, but I don’t believe it’s wrong either:
the __attribute__((const)) on is_pow2 I consider correct, because the side
effects do not escape the function.

If anyone takes this up, it would be nice if GCC at least did not outright
pessimise such code.

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P4  |P2

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

[jakub at gcc dot gnu.org]

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

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

For the error-recovery ICE, we can just make sure that after errors the type
isn't assumed to be VLA.

Unfortunately:
void bar ();

void
foo (char a, int b)
{
  union C { int d[b]; char *e; };
  bar ((union C) &a);
}

still ICEs.

[Bug tree-optimization/94364] New: 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128

[jamborm at gcc dot gnu.org]

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

Bug ID: 94364
   Summary: 505.mcf_r is 8% faster when compiled with
-mprefer-vector-width=128
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

SPEC 2017 INTrate benchmark 505.mcf_r, when compiled with options
-Ofast -march=native -mtune=native, is 8% slower than when we also use
option -mprefer-vector-width=128.  I have observed it on both AMD Zen2
and Intel Cascade Lake Server CPUs (using master revision 26b3e568a60).

Better vector width selection would therefore bring about noticeable
speed-up.


Symbol profiles (collected on AMD Rome):

-Ofast -march=native -mtune=native:

  Overhead   Samples  Shared ObjectSymbol  
      ...  

28.64%462302  mcf_r_peak.mine  spec_qsort
21.58%348703  mcf_r_peak.mine  cost_compare
15.81%255029  mcf_r_peak.mine  primal_bea_mpp
15.58%251176  mcf_r_peak.mine  replace_weaker_arc
 7.37%118646  mcf_r_peak.mine  arc_compare
 6.53%105337  mcf_r_peak.mine  price_out_impl
 1.38% 22276  mcf_r_peak.mine  update_tree

-Ofast -march=native -mtune=native -mprefer-vector-width=128:

  Overhead   Samples  Shared ObjectSymbol  
      ...  

23.57%354536  mcf_r_peak.mine  spec_qsort
23.51%353767  mcf_r_peak.mine  cost_compare
16.98%255104  mcf_r_peak.mine  primal_bea_mpp
16.65%249891  mcf_r_peak.mine  replace_weaker_arc
 7.29%109267  mcf_r_peak.mine  arc_compare
 7.09%106380  mcf_r_peak.mine  price_out_impl
 1.53% 22968  mcf_r_peak.mine  update_tree


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c/93572] [8/9/10 Regression] internal compiler error: q from h referenced in main

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Somewhat reduced:

void
bar ()
{
  void foo (a) char a;
  int b[&a != (char *) 0x4000];
}

[Bug analyzer/94365] New: false positive leak when using container_of-like constructs

[npfhrotynz-ptnqh.myvf at noclue dot notk.org]

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

Bug ID: 94365
   Summary: false positive leak when using container_of-like
constructs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: npfhrotynz-ptnqh.myvf at noclue dot notk.org
  Target Milestone: ---

Created attachment 48136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48136&action=edit
test program.c

First, thanks for this awesome feature! I'm not sure how "ready" it is, but
there are other open bugs and I did not see this one, so here goes...


I'm often using patterns where I return a pointer to an inner field of a struct
and then use it with container_of later on.

The attached example program gives two warnings; only the first one is
interesting to me but figured I could cite both since I stumbled on the second
when writing the reproducer...

-
In function ‘foo’:
t.c:22:9: warning: leak of ‘a’ [CWE-401] [-Wanalyzer-malloc-leak]
   22 |  return &a->b;
  | ^
  ‘foo’: events 1-5
|
|   14 |  struct container *a = malloc(sizeof(*a));
|  |^~
|  ||
|  |(1) allocated here
|..
|   19 |  if (!a)
|  | ~   
|  | |
|  | (2) assuming ‘a’ is non-NULL
|  | (3) following ‘false’ branch (when ‘a’ is non-NULL)...
|..
|   22 |  return &a->b;
|  | ~   
|  | |
|  | (4) ...to here
|  | (5) ‘a’ leaks here; was allocated at (1)
|

-
In function ‘main’:
t.c:41:2: warning: ‘free’ of ‘’ which points to memory not on the heap
[CWE-590] [-Wanalyzer-free-of-non-heap]
   41 |  free(container_of(b, struct container, b));
  |  ^~
  ‘main’: events 1-2
|
|   29 | int main() {
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|   30 |  struct a_struct *b = foo();
|  |   ~
|  |   |
|  |   (2) calling ‘foo’ from ‘main’
|
+--> ‘foo’: events 3-5
   |
   |   13 | struct a_struct *foo() {
   |  |  ^~~
   |  |  |
   |  |  (3) entry to ‘foo’
   |..
   |   19 |  if (!a)
   |  | ~ 
   |  | |
   |  | (4) following ‘false’ branch (when ‘a’ is non-NULL)...
   |..
   |   22 |  return &a->b;
   |  | ~ 
   |  | |
   |  | (5) ...to here
   |
<--+
|
  ‘main’: events 6-10
|
|   30 |  struct a_struct *b = foo();
|  |   ^
|  |   |
|  |   (6) returning to ‘main’ from ‘foo’
|..
|   33 |  if (!b)
|  | ~  
|  | |
|  | (7) following ‘false’ branch (when ‘b’ is non-NULL)...
|..
|   41 |  free(container_of(b, struct container, b));
|  |  ~~
|  |  |
|  |  (8) ...to here
|  |  (9) pointer is from here
|  |  (10) call to ‘free’ here
|
-

I would think that as long as it is programmatically possible to go back to the
allocated pointer (e.g. the return value is a constant offset from malloc
value) then there should be no leak.

Thanks,
-- 
Dominique Martinet

[Bug c/94366] New: OpenMP Parallel Reduction with "&&" operator does not compute correct result

[satzeni at nvidia dot com]

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

Bug ID: 94366
   Summary: OpenMP Parallel Reduction with "&&" operator does not
compute correct result
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: satzeni at nvidia dot com
  Target Milestone: ---

Created attachment 48137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48137&action=edit
reproducer

Consider this program:

#include 
#include 
#include 

static int expect = 1;
static int result;

int main() {
int a = 2;  /* or any another even number */

#pragma omp parallel reduction(&& : a)
{
a = a && 1;
}
result = a ? 1 : 0;
assert(result == 1);
}

Compiler and run with:

$ gcc -fopenmp test.c
$ OMP_NUM_THREADS=2 ./a.out

GCC is not correctly computing the logical-and reduction on variable "a".

Inside the parallel region "a" value is 1, but right after the parallel region
is 0 failing the assertion. The correct result should be 1 as the initial value
is 2 and the logical-and between 2 && 1 should be non zero.

Looking at the assembly code, GCC is using a bitwise “and” instruction to
perform the “&&” operation:

mov(%rbx),%edx
jmp0x400782 
xchg   %ax,%ax
mov%eax,%edx
mov%edx,%ecx
mov%edx,%eax
and$0x1,%ecx
lock cmpxchg %ecx,(%rbx)

However the the value of “a” is not reduced to “1” before it is passed to the
parallel region.

  movl   $0x2,(%rsp)
  callq  0x4005c0 

[Bug preprocessor/94367] New: pragma GCC diagnostics messes up with one line "if" blocks without curly braces

[romain.geissler at amadeus dot com]

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

Bug ID: 94367
   Summary: pragma GCC diagnostics messes up with one line "if"
blocks without curly braces
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

It looks like "if" blocks without curly braces cannot be surrounded by pragma
diagnostics. It looks like this is a very old issue, gcc 4.6 already seem to
have this problem on Compiler Explorer. Clang raises no such error.

void f()
{
if (true)
#pragma GCC diagnostic push
;
#pragma GCC diagnostic pop
else
;
}


: In function 'void f()':
:7:5: error: 'else' without a previous 'if'
7 | else
  | ^~~~
Compiler returned: 1
Compiler Explorer uses cookies and other related techs to serve you

[Bug preprocessor/94367] pragma GCC diagnostics messes up with one line "if" blocks without curly braces

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
pragma GCC diagnostics
is a full statement.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

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

[Bug preprocessor/94367] pragma GCC diagnostics messes up with one line "if" blocks without curly braces

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 63326.

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