[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 51488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51488=edit
trimmed preprocessed source a lot

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE with|[12 Regression] ICE with
   |-march=armv8.2-a+sve -O3|-march=armv8.2-a+sve -O3
   Target Milestone|--- |12.0

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #3 from Andrew Pinski  ---
Reducing, Can reproduce it with r12-3568.

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Gilles Gouaillardet  
---
I am happy to confirm this issue is fixed in the latest 12-20210919 snapshot
:-)

FWIW, I was not yet able to build GROMACS because of an other issue that was
introduced last week. I reported it at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Gilles Gouaillardet  
---
Created attachment 51487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51487=edit
a trimmed reproducer (FWIW - include files are missing)

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Gilles Gouaillardet  
---
Created attachment 51486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51486=edit
a (compressed) pre-processed reproducer

[Bug target/102421] New: ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 102421
   Summary: ICE with -march=armv8.2-a+sve -O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

This is a new issue that happens with -march=armv8.2-a+sve -O3 with the latest
snapshot (12-20210919). FWIW, no crash with
 - 12-20210912 (last week snapshot)
 - -march=armv8.2-a+sve -O2
 - -march=armv8.2-a -O3


I tried to trim the file that caused an issue (it is from GROMACS 2021.3) but
was not quite able to do so. The attached reproducer is my best effort at
trimming it.


g++ (GCC) 12.0.0 20210919 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Singularity> g++ -march=armv8.2-a+sve -O3 -c test.i
during GIMPLE pass: vect
test.cpp: In function 'void foo(gmx::PaddedVector >,
gmx::PaddedVector >, int, short unsigned int*, const
int (*)[3])':
test.cpp:12:6: internal compiler error: in dr_misalignment, at
tree-vect-data-refs.c:900
   12 | void foo (
  |  ^~~
0x1d279c7 dr_misalignment(dr_vec_info*)
../.././gcc/tree-vect-data-refs.c:900
0x1d27a07 vect_duplicate_ssa_name_ptr_info
../.././gcc/tree-vect-data-refs.c:4639
0x1d2aa0f vect_create_addr_base_for_vector_ref(vec_info*, _stmt_vec_info*,
gimple**, tree_node*, tree_node*)
../.././gcc/tree-vect-data-refs.c:4750
0x1d2ac9f vect_create_data_ref_ptr(vec_info*, _stmt_vec_info*, tree_node*,
loop*, tree_node*, tree_node**, gimple_stmt_iterator*, gimple**, bool,
tree_node*, tree_node*)
../.././gcc/tree-vect-data-refs.c:4951
0x130b5b7 vectorizable_load
../.././gcc/tree-vect-stmts.c:9370
0x131854b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../.././gcc/tree-vect-stmts.c:11044
0x131a7a3 vect_transform_loop_stmt
../.././gcc/tree-vect-loop.c:9343
0x1335717 vect_transform_loop(_loop_vec_info*, gimple*)
../.././gcc/tree-vect-loop.c:9779
0x1365f2b try_vectorize_loop_1
../.././gcc/tree-vectorizer.c:1108
0x13669af vectorize_loops()
../.././gcc/tree-vectorizer.c:1247
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jonathan Wakely  ---
I.e. please don't mark it as resolved, I'll do that when it's resolved.

[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jonathan Wakely  ---
I've set the Target Milestone field to indicate is going to be fixed for 10.4

[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #36 from Eric Gallager  ---
This bug is part of a large discussion on the llvm mailing lists, about whether
they should do similarly to GCC:
https://lists.llvm.org/pipermail/llvm-dev/2021-September/152530.html

[Bug c/54192] -fno-trapping-math by default?

[gabravier at gmail dot com via Gcc-bugs]

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

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #5 from Gabriel Ravier  ---
Also of note should be the fact that Clang's current default is
`-fno-trapping-math`.

I'm myself kind of curious about how exactly `-ftrapping-math` is interpreted.
It certainly doesn't seem to remove every single kind of non-trapping
math-based optimization: GCC will remove such statements as `(void)1/x;` even
with `-ftrapping-math`, even though that could fault with `x == 0`, and will
optimize things like `float x = 3412897421;` to not do a conversion even though
that conversion could raise an exception (as 3412897421 cannot be exactly
represented as a float), whereas Clang won't do that kind of optimization and
will keep those operations as-is.

[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?

[gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I think this bug should be changed to a request to improve the diagnostics.

The diagnostic says:

```
:13:15: note: constraints not satisfied
:8:9:   required by the constraints of 'template concept foo'
:8:15:   in requirements with 't v' [with t = int]
:10:6: note: 'v' does not satisfy return-type-requirement
   10 | {v} -> same_as;
  |  ^
```

If you don't know that `{v}` should be read as `{(v)}`, it is confusing that
the diagnostic says that `'t v' [with t = int]` does not satisfy that the type
of the expression `{ v }` is `t`.

I think the diagnostic for the return-type-requirement should add the reason /
diagnostic why it isn't fulfilled, so basically the same reason that
`static_assert(std::same_as);` would give.

> note: the expression 'is_same_v<_Tp, _Up> [with _Tp = int&; _Up = int]' 
> evaluated to 'false'
>   57 |   concept __same_as = std::is_same_v<_Tp, _Up>;
>  |   ~^~~

[Bug c/102415] [12 Regression] ICE in bb_seq_addr, at gimple.h:1786

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/102414] [12 Regression] ICE in unify_array_domain, at cp/pt.c:23442

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/99811] ICE: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst_pack_expansion, at cp/pt.c:13002

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work|11.1.0  |

--- Comment #2 from Andrew Pinski  ---
The first testcase is fixed in GCC 11+ while the second testcase still ICEs on
the trunk.

[Bug c++/102420] null pointer dereference during constant evaluation not rejected

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-20
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, here is a testcase which does not require C++20 (though it does use
a GNU extension):

struct X {
  constexpr int f() { return 0; }
};
constexpr int g() {
return (X*){nullptr}->f();
}

int t = g();
 CUT 
here is one which is invalid C++14 (and does not use the GNU extension):
struct X {
  constexpr int f() { return 0; }
};
constexpr int g() {
X *x = nullptr;
return x->f();
}

int t = g();
 CUT --
I only noticed that clang rejects it while ICC and MSVC accept it also.

[Bug c/79516] [9/10/11/12 Regression] ICE: unspellable token PRAGMA_EOL

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|ICE: unspellable token  |[9/10/11/12 Regression]
   |PRAGMA_EOL  |ICE: unspellable token
   ||PRAGMA_EOL
   Target Milestone|--- |9.5

--- Comment #2 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1)
> Confirmed, started in between 4.5.2 and 4.5.3.

No 4.4.7 ICEs too. But 4.1.2 does not.

[Bug c/97991] [9/10/11/12 Regression] ICE in c_parser_consume_token, at c/c-parser.c:850

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=47254
Summary|ICE in  |[9/10/11/12 Regression] ICE
   |c_parser_consume_token, at  |in c_parser_consume_token,
   |c/c-parser.c:850|at c/c-parser.c:850
  Known to fail||10.1.0, 4.4.7
   Target Milestone|--- |9.5
  Known to work||4.1.2

--- Comment #3 from Andrew Pinski  ---
(In reply to G. Steinmetz from comment #1)
> A special case, loosely related :
> 
> 
> $ cat z2.c
> #define foo _Pragma (" ")
> #pragma redefine_extname foo

That is PR 47254.

[Bug c++/102420] null pointer dereference during constant evaluation not rejected

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

Summary|null pointer dereference|null pointer dereference
   |constant|during constant evaluation
   ||not rejected
 Blocks||55004

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
See https://godbolt.org/z/r5zxPTcK6.
```C++
struct X {
  constexpr void f() { }
};
int main() {
  []() consteval {
X* x{nullptr};
x->f();
  }();
}
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/102420] New: null pointer dereference constant

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 102420
   Summary: null pointer dereference constant
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

[Bug c++/96638] [9/10/11/12 Regression] ICE in chainon, at tree.c:3169

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #1)
> Even GCC 6 ICEs.

I suspect GCC 5 did not ICE, see PR 96637 .

[Bug c++/58109] alignas() fails to compile with constant expression

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/59012] alignas does not support parameter pack expansions

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

[Bug c++/96637] [9/10/11/12 Regression] ICE in tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1423

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
Summary|ICE in tree check: expected |[9/10/11/12 Regression] ICE
   |tree_list, have error_mark  |in tree check: expected
   |in  |tree_list, have error_mark
   |cp_check_const_attributes,  |in
   |at cp/decl2.c:1423  |cp_check_const_attributes,
   ||at cp/decl2.c:1423
  Known to work||5.5.0
   Severity|normal  |minor
  Known to fail||6.1.0

--- Comment #2 from Andrew Pinski  ---
In GCC 5.5.0 and before we only got the following error message and no confused
by earlier errors message:
:1:16: error: expected ',' or '...' before 'alignas'
 void foo(int[] alignas[1] alignas(1)){}
^

GCC 6+ changed the error message to:
:1:23: error: expected '(' before '[' token
 void foo(int[] alignas[1] alignas(1)){}
   ^

[Bug c++/54367] [meta-bug] lambda expressions

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 89138, which changed state.

Bug 89138 Summary: typeof VLA in lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89138

   What|Removed |Added

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

[Bug c++/16994] [meta-bug] VLA and C++

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
Bug 16994 depends on bug 89138, which changed state.

Bug 89138 Summary: typeof VLA in lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89138

   What|Removed |Added

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

[Bug c++/60855] ICE provoked by a lambda using the sizeof a captured VLA

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

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

[Bug c++/89138] typeof VLA in lambdas

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Yes this is a dup of bug 60855.  It has been fixed for GCC 10+.

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

[Bug c++/92331] ICE on incorrect code with VLA type inside a local struct type

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE on incorrect code with  |ICE on incorrect code with
   |VLA |VLA type inside a local
   ||struct type
   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #2 from Andrew Pinski  ---
It did not crash in GCC 4.5.3 but there was multiple calls to foo.

Note I used this code instead (removing C++11ism from it):
int foo();

int main() {
  typedef int X[foo()];
  struct S { S() { X x; } } s;
}

[Bug preprocessor/82469] ICE in _cpp_process_line_notes, at libcpp/lex.c:1066

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
I cannot even reproduce this on the FSF released GCC 6.3.0 code ...

[Bug preprocessor/69869] [6 Regression] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|6.5 |7.4

[Bug c++/102419] New: [concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 102419
   Summary: [concepts] [regression] return-type-requirement of
"Y" does not check that T::type
actually exists
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/GWjYYnrnM
template concept Y = true;
template concept X = requires {
{ 1 } -> Y;
};
static_assert(!X);


:8:15: error: static assertion failed
8 | static_assert(!X);
  |   ^~~

Clang and MSVC both appear to have the correct behavior -- or what I believe to
be the consistent/useful/majority behavior, anyway -- which is that since
T::type doesn't exist, the concept shouldn't be satisfied.

This seems to be a regression; according to Godbolt, GCC 10.3 had the correct
behavior but GCC 11.1 lost it. 

I wonder if #92268 could be related somehow, since it seems to be something
like the inverse issue (nonexistent nested type causing a hard error in 10.x),
and it was marked fixed presumably somewhere in the 11.x timeframe.

[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

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

--- Comment #2 from Arthur O'Dwyer  ---
Yes, this is/was a Clang bug; a return-type-requirement should be applied to
decltype((expr)), but Clang was incorrectly applying the requirement to
decltype(expr).

I think this can now be closed as "not a bug" (the bug was in Clang, not GCC).

[Bug c++/81157] If constexpr does not support Short-circuit evaluation

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

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

--- Comment #1 from Arthur O'Dwyer  ---
I'd say neither a bug nor a defect. In `if constexpr (X && Y)`, `X && Y` is an
expression and it must be well-formed, even if it's false -- just like if you
did `static_assert((X && Y) == false)`. GCC is behaving according to the C++
Standard in this case.

Recommend closing as INVALID.

[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint

[joeloser93 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Joe Loser  ---
Johnathan, your fix LGTM. Safe to mark this as resolved, or do you need to do
something to backport it for the 10.4 release branch?

[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped

[sandra at gcc dot gnu.org via Gcc-bugs]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
Still present on trunk.

[Bug other/102408] [OpenACC] omp-oacc-neuter-broadcast.cc: random() not available on all platforms

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-09-20
 CC||jules at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Keywords||openacc
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #1 from Thomas Schwinge  ---
Sorry for the temporary breakage, I'll get this sorted out tomorrow; see
.

[Bug c++/102418] New: [concepts] prefer iterator to range concept failures in ranges (QoI)

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 102418
   Summary: [concepts] prefer iterator to range concept failures
in ranges (QoI)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

When interacting with the ranges library I am occasionally presented with
hundreds of lines of circuitous concept failures driven by failing a range
concept. The vast majority of programmers won't find these helpful.

On the other hand, it was pointed out that when the failure is due to one of
the range's dependent iterator concepts, asserting the corresponding iterator
concept produces beautiful and too-the-point failure traces.

>From a QoI perspective, some mechanism to prioritize the iterator concept
failure when it is responsible for a range concept failure would go a long way
to making ranges more usable.

The example I was playing with is at https://godbolt.org/z/fGWcTdEjo, an is the
difference in output when -DITERATOR is defined in the following example.

```
struct Broken {
struct iterator {
int i;
auto operator*() const -> decltype(auto) {
return std::tie(i);
}
auto operator++() -> decltype(auto) {
++i;
return *this;
}
friend bool operator==(iterator const&, iterator const&) = default;
friend auto operator<=>(iterator const&, iterator const&) = default;
};

auto begin() const -> iterator { return {}; }
auto end() const -> iterator { return {}; }
};

#ifdef ITERATOR
static_assert(std::input_iterator);
#else

#include 

int foo() {
Broken r;
std::ranges::for_each(r, [](auto t) { 
auto [i] = t;
printf("%d\n", i);
});
}
#endif
```

[Bug c/102416] [12 Regression] ICE in gimplify_expr, at gimplify.c:15570

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/102413] [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug fortran/102417] Wrong error message about character length with -std=f2018

[gscfq--- via Gcc-bugs]

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

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

And obviously, works with a single AC :


$ cat z0.f90
program p
   character :: x = 'a'
   character(4) :: y(3)
   y = [character(4) :: x, 'b', 'c']
   print *, y
end

$ gfortran-12-20210919 z0.f90 -std=f2018 -Wall && ./a.out
 a   b   c

[Bug fortran/102417] New: Wrong error message about character length with -std=f2018

[gscfq--- via Gcc-bugs]

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

Bug ID: 102417
   Summary: Wrong error message about character length with
-std=f2018
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

An embedded AC together with option -std=f2018 (or f2008 etc.)
produces a misleading error message. Typespec is explicitly given.
Affects versions down to at least r5.

That unique error message comes from line 1888 in decl.c.
Issue is eventually related to pr102315.


$ cat z1.f90
program p
   character :: x = 'a'
   character(4) :: y(3)
   y = [[character(4) :: x, 'b', 'c']]
   print *, y
end


$ gfortran-12-20210919 -c z1.f90 -std=f2018 -Wall
z1.f90:4:27:

4 |y = [[character(4) :: x, 'b', 'c']]
  |   1
Warning: CHARACTER expression at (1) is being truncated (4/1)
[-Wcharacter-truncation]
z1.f90:4:27: Error: The CHARACTER elements of the array constructor at (1) must
have the same length (4/1)
z1.f90:4:32:

4 |y = [[character(4) :: x, 'b', 'c']]
  |1
Warning: CHARACTER expression at (1) is being truncated (4/1)
[-Wcharacter-truncation]
z1.f90:4:32: Error: The CHARACTER elements of the array constructor at (1) must
have the same length (4/1)

[Bug fortran/102315] ICE tree check: expected integer_cst, have save_expr in gfc_trans_array_constructor_value, at fortran/trans-array.c:2056

[gscfq--- via Gcc-bugs]

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

--- Comment #3 from G. Steinmetz  ---

A reduced variant with the same ICE :

$ cat z2.f90
program p
   character :: x = 'a'
   character :: y(5)
   y = [[trim(x), 'b', 'c', 'd', 'e']]
   print *, y
end



But z1 gives additional hints when reduced to four or less
array elements. It compiles and runs correctly, like :

$ cat za1.f90
program p
   character(4) :: x = '123'
   character(8) :: y(4)
   y = [[character(8) :: 'a'//trim(x), 'b', 'c', 'd']]
   print *, y
end

$ gfortran-12-20210919 za1.f90 && ./a.out
 a123b   c   d


And it fails with a wrong runtime error when adding checks via
-fcheck=bounds or -fcheck=all :

$ gfortran-12-20210919 za1.f90 -g -fcheck=all && ./a.out
At line 4 of file za1.f90
Fortran runtime error: Different CHARACTER lengths (4/8) in array constructor

Error termination. Backtrace:
#0  0x4026b7 in p
at .../za1.f90:4
#1  0x4029c9 in main
at .../za1.f90:6


That unique error message comes from line 1787 in trans-array.c

[Bug c/102415] [12 Regression] ICE in bb_seq_addr, at gimple.h:1786

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2021-09-20
 Ever confirmed|0   |1

[Bug c/102416] New: [12 Regression] ICE in gimplify_expr, at gimplify.c:15570

[gscfq--- via Gcc-bugs]

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

Bug ID: 102416
   Summary: [12 Regression] ICE in gimplify_expr, at
gimplify.c:15570
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210523 and 20210530 :


$ cat z1.c
void *f ()
{
  #pragma omp task affinity(f()[2])
  ;
}


$ cat z2.c
void f ()
{
  struct S *x;
  #pragma omp task affinity(*x)
  ;
}


$ gcc-12-20210919 -c z1.c -fopenmp
z1.c: In function 'f':
z1.c:3:32: warning: dereferencing 'void *' pointer
3 |   #pragma omp task affinity(f()[2])
  |^
z1.c:3:28: warning: dereferencing 'void *' pointer
3 |   #pragma omp task affinity(f()[2])
  |^
z1.c:3:28: internal compiler error: in gimplify_expr, at gimplify.c:15570
0x960cc4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15570
0x9581e4 gimplify_omp_affinity
../../gcc/gimplify.c:8105
0x9581e4 gimplify_scan_omp_clauses
../../gcc/gimplify.c:9924
0x95dbeb gimplify_omp_task
../../gcc/gimplify.c:11814
0x95dbeb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15062
0x960cf8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7006
0x961251 gimplify_bind_expr
../../gcc/gimplify.c:1426
0x95ecca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14769
0x960cf8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7006
0x961d6b gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15814
0x9621bf gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15968
0x7eaf97 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x7ed8e7 analyze_functions
../../gcc/cgraphunit.c:1234
0x7ee2ad symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2508

[Bug c/102415] New: [12 Regression] ICE in bb_seq_addr, at gimple.h:1786

[gscfq--- via Gcc-bugs]

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

Bug ID: 102415
   Summary: [12 Regression] ICE in bb_seq_addr, at gimple.h:1786
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210808 and 20210822 :


$ cat z1.c
void abort ();
void f ()
{
  #pragma omp scope nowait
  abort ();
}


$ gcc-12-20210919 -c z1.c -fopenmp
during GIMPLE pass: ompexp
z1.c: In function 'f':
z1.c:4:11: internal compiler error: Segmentation fault
4 |   #pragma omp scope nowait
  |   ^~~
0xbdd88f crash_signal
../../gcc/toplev.c:328
0x176a67a bb_seq_addr
../../gcc/gimple.h:1786
0x176a67a gsi_last_bb
../../gcc/gimple-iterator.h:164
0x176a67a gsi_last_nondebug_bb
../../gcc/gimple-iterator.h:306
0x176a67a expand_omp_single
../../gcc/omp-expand.c:8441
0x176a67a expand_omp
../../gcc/omp-expand.c:10246
0x176c63d execute_expand_omp
../../gcc/omp-expand.c:10467

[Bug c++/102413] [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-09-20

[Bug c++/102414] New: [12 Regression] ICE in unify_array_domain, at cp/pt.c:23442

[gscfq--- via Gcc-bugs]

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

Bug ID: 102414
   Summary: [12 Regression] ICE in unify_array_domain, at
cp/pt.c:23442
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210627 and 20210704 :


$ cat z1.cc
void f ()
{
  int a[3];
  auto (*b)[0/0] = 
}


$ g++-12-20210919 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:4:14: warning: division by zero [-Wdiv-by-zero]
4 |   auto (*b)[0/0] = 
  | ~^~
z1.cc:4:21: internal compiler error: in unify_array_domain, at cp/pt.c:23442
4 |   auto (*b)[0/0] = 
  | ^
0x671a18 unify_array_domain
../../gcc/cp/pt.c:23442
0x8160a5 unify
../../gcc/cp/pt.c:24013
0x815da3 unify
../../gcc/cp/pt.c:24319
0x814b99 unify_one_argument
../../gcc/cp/pt.c:22271
0x8225b6 type_unification_real
../../gcc/cp/pt.c:22390
0x80aea5 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29807
0x732d36 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7948
0x7f3caf cp_parser_init_declarator
../../gcc/cp/parser.c:22665
0x7d1b52 cp_parser_simple_declaration
../../gcc/cp/parser.c:15133
0x7d37c9 cp_parser_declaration_statement
../../gcc/cp/parser.c:14214
0x7d3e4c cp_parser_statement
../../gcc/cp/parser.c:12306
0x7d4cb4 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12713
0x7d4d6f cp_parser_compound_statement
../../gcc/cp/parser.c:12662
0x7f2e78 cp_parser_function_body
../../gcc/cp/parser.c:24893
0x7f2e78 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24944
0x7f3326 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:31066
0x7f4247 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:30982
0x7f4247 cp_parser_init_declarator
../../gcc/cp/parser.c:22427
0x7d1b52 cp_parser_simple_declaration
../../gcc/cp/parser.c:15133
0x7f9a1f cp_parser_declaration
../../gcc/cp/parser.c:14819

[Bug c++/102413] New: [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172

[gscfq--- via Gcc-bugs]

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

Bug ID: 102413
   Summary: [12 Regression] ICE in cp_lexer_consume_token, at
cp/parser.c:1172
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210627 and 20210704 :


$ cat z1.cc
[[omp::directive(error]];


$ g++-12-20210919 -c z1.cc -fopenmp
z1.cc:1:25: internal compiler error: in cp_lexer_consume_token, at
cp/parser.c:1172
1 | [[omp::directive(error]];
  | ^
0x7b6c27 cp_lexer_consume_token
../../gcc/cp/parser.c:1172
0x7b8966 cp_parser_omp_directive_args
../../gcc/cp/parser.c:28632
0x7e0005 cp_parser_std_attribute
../../gcc/cp/parser.c:28871
0x7e0005 cp_parser_std_attribute_list
../../gcc/cp/parser.c:28961
0x7e0005 cp_parser_std_attribute_spec
../../gcc/cp/parser.c:29049
0x7e0005 cp_parser_std_attribute_spec_seq
../../gcc/cp/parser.c:29142
0x7d1267 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:15516
0x7d19f1 cp_parser_simple_declaration
../../gcc/cp/parser.c:15006
0x7f9a1f cp_parser_declaration
../../gcc/cp/parser.c:14819
0x7fa4ab cp_parser_translation_unit
../../gcc/cp/parser.c:4978
0x7fa4ab c_parse_file()
../../gcc/cp/parser.c:47694
0x8cb652 c_common_parse_file()
../../gcc/c-family/c-opts.c:1236

[Bug c++/102412] Template argument deduction fails when using concept as defaulted non-type template parameter

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |11.3
   Last reconfirmed||2021-09-20
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug target/102411] arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Earnshaw  ---
The AAPCS tests are executable tests, so rely on a number of features of the
support libraries (ie libraries compatible with the options used for the
compilation).  I don't think they should be adding any options to try and force
the test to compile.  So I think the dg-add-options is just wrong.

[Bug ipa/102388] [12 Regression] ICE in duplicate, at ipa-prop.c:4436 since r12-2523-g13586172d0b70c9d

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Jambor  ---
Mine, looks like a lot of fun.

[Bug c++/101940] Implement -Wno-attributes=vendor::attr

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579858.html

[Bug c++/102412] New: Template argument deduction fails when using concept as defaulted non-type template parameter

[joeloser93 at gmail dot com via Gcc-bugs]

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

Bug ID: 102412
   Summary: Template argument deduction fails when using concept
as defaulted non-type template parameter
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joeloser93 at gmail dot com
  Target Milestone: ---

When using a defaulted non-type template parameter whose value is from a
concept, GCC is unable to deduce the template correctly when calling the
function template. Clang accepts this code and it should be valid. 

```
#include 

template
concept different_from = not std::is_same_v;

template>
void f() {}

template>
void g() {}

int main() {
f(); // fails to compile
g(); // compiles
}

```

See it live at https://godbolt.org/z/n1zrzGPoq

[Bug target/102411] New: arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4

[clyon at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102411
   Summary: arm/vfp18.c fails with -march=armv7e-m+fp for
cortex-m4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

When running the testsuite with -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp and
simulating for cortex-m4, I noticed that gcc.target/arm/vfp18.c fails at
execution.

The testcase contains:
void myfunc(__fp16, float, double, float, __fp16, int) ;

int main()
{
  myfunc(1.0f, 2.0f, 4.0, 2.0f, 1.0f, 3);

}

The testcase is compiled with:
-mthumb -mfloat-abi=hard -march=armv7e-m+fp -mfpu=vfpv4 -mfp16-format=ieee

For main we generate:
push{r7, lr}@ 27[c=8 l=2]  *push_multi
add r7, sp, #0  @ 28[c=4 l=4]  *arm_addsi3/4
movsr0, #3  @ 5 [c=4 l=2]  *thumb2_movsi_shortim
movwr3, #15360  @ 23[c=4 l=8]  *movhf_vfp/6
vmovs5, r3  @ 6 [c=4 l=4]  *movhf_vfp/4
vmov.f32s4, #2.0e+0 @ 7 [c=4 l=4]  *thumb2_movsf_vfp/2
vmov.f64d1, #4.0e+0 @ 8 [c=4 l=4]  *thumb2_movdf_vfp/2
vmov.f32s1, #2.0e+0 @ 9 [c=4 l=4]  *thumb2_movsf_vfp/2
vmovs0, r3  @ 10[c=4 l=4]  *movhf_vfp/4
bl  myfunc  @ 11[c=8 l=4]  *call_symbol
movsr3, #0  @ 12[c=4 l=2]  *thumb2_movsi_shortim
mov r0, r3  @ 19[c=4 l=2]  *thumb2_movsi_vfp/0
pop {r7, pc}@ 31[c=8 l=2] 
*pop_multiple_with_writeback_and_return

The problem is the vmov.f64 instruction which is not supported by cortex-m4
since it has a single-precision-only FPU.

Running under QEMU with -cpu cortex-m7 passes, as expected.

The problem comes from -mfpu=vfpv4, which is added by arm_fp16_hw (indirectly
from check_effective_target_arm_fp16_ok_nocache)

Indeed arm-cpus.in says:
begin fpu vfpv4
  isa VFPv4 FP_D32
end fpu vfpv4

so it enables double-precision support.


Looks like a testism, since we effectively override -march=armv7e-m+fp with
-mfpu=vfpv4, but maybe a warning would be helpful?
And something to disable the test or make it pass.

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Sebor  ---
In general a program can add an attribute to a system function by redeclaring
it with it.  This of course needs to be done conditionally on the GCC version
that supports the attribute.  This in turn can be tested at compile time by the
__has_attribute operator or based on GCC version macros.

[Bug c++/102410] New: parameter pack expansion twice when there is default parameter during template specialization

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102410
   Summary: parameter pack expansion twice when there is default
parameter during template specialization
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

The following code should NOT be accepted because parameter pack should be just
"int*" without "double" which is considered as "Extra". 

template
void foo(First, Extra, Ts...){}
template<>
void foo(char,double,int*,double){}


As a contrast, the following code is rejected which is wrong.

template
void foo(First, Extra, Ts...){}
template<>
void foo(char,double,int*){}

[Bug target/102404] Loop vectorized with 32 byte vectors actually uses 16 byte vectors

[freddie at witherden dot org via Gcc-bugs]

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

--- Comment #4 from Freddie Witherden  ---
Created attachment 51485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51485=edit
Clang assembly.

[Bug target/102404] Loop vectorized with 32 byte vectors actually uses 16 byte vectors

[freddie at witherden dot org via Gcc-bugs]

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

--- Comment #3 from Freddie Witherden  ---
(In reply to Richard Biener from comment #2)
> 32 bytes are 256 bits (ymm), 64 bytes are 512 bits (zmm).  GCC does not
> consider zmm vectorization because
> 
> t.c:25:37: missed:  loop does not have enough iterations to support
> vectorization.
> 
> because
> 
> t.c:25:37: note:  vectorization_factor = 16, niters = 8
> 
> the memory accesses cannot be related so we fail to SLP this.
> 
> Does clang use vpgathers/scatters on %zmm here?

Apologises for the typo.  However, I would still expect the loop to be
vectorized with %zmm as it is operating (fundamentally) on double precision
numbers (8 bytes) with a trip count of 8.

Clang assembly is attached, showing the expected structure.  Gathers and
scatters are used on %zmm here.

Could GCC be thrown off by the fact that the table indices are 4 byte integers?

[Bug c++/102409] New: _pragma ("omp ...") expansion issue - placed in the wrong scope

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102409
   Summary: _pragma ("omp ...") expansion issue - placed in the
wrong scope
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51484=edit
Testcase. Compile with "g++ -fopenmp" or with "g++ -E" vs. "clang++ -E" and
inspect "omp ordered" placement

I have to admit that I do not know the fine print of _Pragma and nested macro
expansion. However, the result I get with clang matches what I naively would
expect – while I find the result for GCC odd. I also do not know whether this
use is an extension or matches the C (C++?) standard.

I think it is similar to PR 91669, PR 90400, PR91285, PR 82335

... except that here only the _Pragma that ends up at the wrong spot is the one
which is used in the macro call – while those which are in a #define are
handled properly.
If I read the other PRs correctly, there the issue is the _Pragma in the macro
#define. Nonetheless, they may still fail due to the very same reason.

 * * *

In any case, the result which clang gives matches the expectation of the
testcase author
of the test at
https://github.com/clang-ykt/omptests/blob/master/t-for/test.c#L296

Due to GCC's macro/_Pragma expansion, that one (as well as the attached
stripped-down version) fails with:
  error: ‘ordered’ region may not be closely nested inside of ‘critical’,
‘ordered’, explicit ‘task’ or ‘taskloop’ region

 * * *

The code uses:

#define PARALLEL(X) TEST({ \
...
_Pragma("omp for ordered") \
  X  \
_Pragma("omp for schedule(auto) ordered") \
  X  \
})
...

PARALLEL(
for (int i = 0; i < N; i++) { \
  _Pragma("omp ordered") \



EXPECTED: same result as with clang++-11 -E -fopenmp:

...
#pragma omp for ordered
 for (int i = 0; i < (1024*3); i++) {
#pragma omp ordered
 S[0] += C[i] + D[i]; }
#pragma omp for schedule(auto) ordered
 for (int i = 0; i < (1024*3); i++) {
#pragma omp ordered
 S[0] += C[i] + D[i]; } } }} } }
  }
...


BUT: g++ -E -fopenmp gives the following, placing the 'omp ordered' before TEST
instead of inside before "S[0] = " together with the rest of X:

#pragma omp ordered
#pragma omp ordered
{ int fail = 0, trial; for (int trial = 0; trial < (1) && fail == 0;
trial++) {
...
#pragma omp for ordered
for (int i = 0; i < (1024*3); i++) { S[0] += C[i] + D[i]; } 
#pragma omp for schedule(auto) ordered
for (int i = 0; i < (1024*3); i++) { S[0] += C[i] + D[i]; } } }} } }
  }

[Bug other/102408] New: [OpenACC] omp-oacc-neuter-broadcast.cc: random() not available on all platforms

[pexu--- via Gcc-bugs]

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

Bug ID: 102408
   Summary: [OpenACC] omp-oacc-neuter-broadcast.cc: random() not
available on all platforms
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-w64-mingw32

Hi.

random() is not available on all platforms (it's XSI), e.g. mingw.

I wonder if the simplest thing would be simply to use rand() or std::rand()
given that the required random value is quite small?

<...>/gcc/omp-oacc-neuter-broadcast.cc: In function 'void
oacc_do_neutering(long long unsigned int, long long unsigned int)':
<...>/gcc/omp-oacc-neuter-broadcast.cc:1786:23: error: 'random' was not
declared in this scope; did you mean 'rand'?
 1786 |base = bounds_lo + random () % 512;

The problematic commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2a3f9f6532bb21d8ab6f16fbe9ee603f6b1405f2

[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Richard Biener  ---
(In reply to Andrew Pinski from comment #5)
> r9-3927 changed the type from int to HOST_WIDE_INT which is always at least
> 64bit ...
> 
> I also wonder if we could use wi::widest_int here.

That's prohibitively expensive (storage-wise).  Note propagating a failure
upwards should in theory be possible (but it's going to "hurt" - welcome C++
exceptions?)

[Bug testsuite/102282] New test cases in r12-3320 fail

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
 Status|UNCONFIRMED |NEW
  Build|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
   Host|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
   Last reconfirmed||2021-09-20
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
This fails everywhere.

[Bug tree-optimization/82426] Missed tree-slp-vectorization on -O2 and -O3

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
I have a patch that produces

  vect__1.5_42 = MEM  [(float *)a_34(D)];
  vect__1.7_47 = VEC_PERM_EXPR ;
  vect__2.10_49 = MEM  [(float *)b_35(D)];
  vect__2.12_53 = VEC_PERM_EXPR ;
  vect__3.13_54 = vect__1.7_47 * vect__2.12_53;
  vect__2.30_73 = MEM  [(float *)b_35(D)];
  vect__1.18_61 = VEC_PERM_EXPR ;
  vect__2.23_68 = VEC_PERM_EXPR ;
  vect__6.24_69 = vect__1.18_61 * vect__2.23_68;
  vect__7.25_70 = vect__3.13_54 + vect__6.24_69;
  vect__5.40_85 = MEM  [(float *)b_35(D) + 8B];
  MEM  [(float *)&] = vect__7.25_70;
  vect__21.35_81 = MEM  [(float *)a_34(D) + 16B];
  vect__1.36_82 = VEC_PERM_EXPR ;
  vect__22.37_83 = vect__2.30_73 * vect__1.36_82;
  vect__1.46_94 = VEC_PERM_EXPR ;
  vect__24.47_95 = vect__5.40_85 * vect__1.46_94;
  vect__25.48_96 = vect__22.37_83 + vect__24.47_95;
  vect__26.51_98 = MEM  [(float *)b_35(D) + 16B];
  vect__27.52_100 = vect__25.48_96 + vect__26.51_98;
  MEM  [(float *)& + 16B] = vect__27.52_100;

that means it ends up with some odd vector loads, but with SSE 4.2 it becomes

movups  (%rsi), %xmm5
movups  (%rdx), %xmm1
movq%rdi, %rax
movq(%rdx), %xmm4
movq8(%rdx), %xmm3
movsldup%xmm5, %xmm0
movaps  %xmm1, %xmm2
movlhps %xmm1, %xmm2
shufps  $238, %xmm1, %xmm1
mulps   %xmm0, %xmm2
movshdup%xmm5, %xmm0
mulps   %xmm1, %xmm0
movq16(%rsi), %xmm1
addps   %xmm2, %xmm0
movups  %xmm0, (%rdi)
movsldup%xmm1, %xmm0
movshdup%xmm1, %xmm1
mulps   %xmm4, %xmm0
mulps   %xmm3, %xmm1
addps   %xmm1, %xmm0
movq16(%rdx), %xmm1
addps   %xmm1, %xmm0
movlps  %xmm0, 16(%rdi)

alternatively -mavx can do some of the required perms with the loads and
with -mfma we can use an FMA as well:

vpermilps   $238, (%rdx), %xmm1
vpermilps   $245, (%rsi), %xmm0
movq%rdi, %rax
vpermilps   $160, (%rsi), %xmm3
vpermilps   $68, (%rdx), %xmm4
vmulps  %xmm1, %xmm0, %xmm0
vmovq   (%rdx), %xmm2
vfmadd231ps %xmm4, %xmm3, %xmm0
vmovq   8(%rdx), %xmm3
vmovups %xmm0, (%rdi)
vmovq   16(%rsi), %xmm0
vmovsldup   %xmm0, %xmm1
vmovshdup   %xmm0, %xmm0
vmulps  %xmm3, %xmm0, %xmm0
vfmadd132ps %xmm1, %xmm0, %xmm2
vmovq   16(%rdx), %xmm0
vaddps  %xmm2, %xmm0, %xmm0
vmovlps %xmm0, 16(%rdi)

I'm not sure whether the vmovups + vmovs{l,h}dup are any better than doing
two scalar loads + dups though - it might avoid some STLF conflict with
earlier smaller stores at least.

[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
r9-3927 changed the type from int to HOST_WIDE_INT which is always at least
64bit ...

I also wonder if we could use wi::widest_int here.

[Bug rtl-optimization/84345] [9/10/11/12 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Andrew Pinski  ---
Note this was not fixed by r8-6634.

[Bug rtl-optimization/83631] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 7 with -fno-sched-rank-heuristic --param=max-sched-extend-regions-iters=4

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |8.0
 Resolution|--- |FIXED

--- Comment #3 from Andrew Pinski  ---
This was fixed by r8-6634.

[Bug middle-end/81724] ICE in expand_stack_vars

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
I think it comes from round_push.

  char three[8192] __attribute__ ((aligned (4096)));   \
  char four[8192] __attribute__ ((aligned (4096)));\


config/nvptx/nvptx.h:#define STACK_BOUNDARY 128
config/nvptx/nvptx.h:#define MAX_STACK_ALIGNMENT (1024 * 8)


#define MAX_SUPPORTED_STACK_ALIGNMENT MAX_STACK_ALIGNMENT


#define SUPPORTS_STACK_ALIGNMENT (MAX_STACK_ALIGNMENT > STACK_BOUNDARY)


  if (size_align % MAX_SUPPORTED_STACK_ALIGNMENT != 0)


I think the code in round_push is wrong.

[Bug middle-end/63289] ICE from --param max-vartrack-expr-depth

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
I think this was a stack limit issue.  It seemed to be fixed in GCC 6+.  The
compile time is also cut in half too.

[Bug c++/102401] std::bit_cast falls over, seemingly due to some invisible alignment requirements

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||78620

--- Comment #6 from Jonathan Wakely  ---
std::bit_cast says the padding bits have unspecified values, so we don't
necessarily need to copy them. We just can't reject them for being
uninitialized.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78620
[Bug 78620] C++11, Padding bytes not zero-intialized when POD is initialized
with compiler generated default constructor

[Bug rtl-optimization/71634] Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

[Bug rtl-optimization/48188] ICE: SIGSEGV in remove_unnecessary_regions (ira-build.c:1855) with --param ira-max-loops-num=0 on basic code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Zdenek Sojka from comment #4)
> Doesn't seem to crash since at least gcc-7

Because it is a dup of bug 71634.

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

[Bug c++/102401] std::bit_cast falls over, seemingly due to some invisible alignment requirements

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|INVALID |---
   Last reconfirmed||2021-09-20
 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED

--- Comment #5 from Jakub Jelinek  ---
We need to fix PR78620 first.
I think one thing is adding some CONSTRUCTOR_ZERO_PADDING flag on CONSTRUCTORs
(meaning that padding is zero initialized), propagate it through the FE and
handle in constexpr there and handle that during gimplification, either by
__builtin_clear_padding or pre-zeroing the whole memory (TREE_STATIC vars don't
need that of course).
And then there is a question if we don't need further middle-end changes,
because a mere struct assignment in the GIMPLE IL doesn't guarantee copying of
the padding bits.

[Bug target/52877] ARC cross-compiler cc1 fails on "x=-1;"

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.0

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> It was added back ...

by r0-125504
So I am just going to assume this was fixed with the updated backend ...

[Bug target/102404] Loop vectorized with 32 byte vectors actually uses 16 byte vectors

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Target|x86_64  |x86_64-*-*
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-20

--- Comment #2 from Richard Biener  ---
32 bytes are 256 bits (ymm), 64 bytes are 512 bits (zmm).  GCC does not
consider zmm vectorization because

t.c:25:37: missed:  loop does not have enough iterations to support
vectorization.

because

t.c:25:37: note:  vectorization_factor = 16, niters = 8

the memory accesses cannot be related so we fail to SLP this.

Does clang use vpgathers/scatters on %zmm here?

[Bug target/52877] ARC cross-compiler cc1 fails on "x=-1;"

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|4.7.0   |---
 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |---

--- Comment #3 from Andrew Pinski  ---
It was added back ...

[Bug target/52877] ARC cross-compiler cc1 fails on "x=-1;"

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Andrew Pinski  ---
Closing as won't fix as arc was removed.

[Bug tree-optimization/60914] ICE: SIGSEGV (use after free) in bitmap_obstack_alloc_stat() with -flto -fvtable-verify=preinit

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail|4.10.0  |

--- Comment #4 from Andrew Pinski  ---
The support for -flto and -fvtable-verify together was disable at r10-2966.  I
am not saying we should close this, just we produce a sorry starting in GCC 10.

[Bug c++/102407] New: Ambiguity is not reported in case of separate inheritance of `<` and `<=>` operators

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 102407
   Summary: Ambiguity is not reported in case of separate
inheritance of `<` and `<=>` operators
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following code is ill-formed:
```
#include 

struct A { 
bool operator <(const A&) const { return true; }
};
struct B { 
auto operator <=>(const B&) const = default; 
};
struct C : A, B {};
int main() { 
C c;
c.operator<(c);
return c < c;
}

```
and it shall be rejected due to ambiguity, but it not in GCC (neither in other
compilers). Demo: https://gcc.godbolt.org/z/d6G7e9319

The detailed explanation why is here:
https://stackoverflow.com/questions/69240507/ambiguity-in-case-of-multiple-inheritance-and-spaceship-operator-in-c20/69245639#69245639

[Bug tree-optimization/102400] Field might miss initialization in vn_reference_insert_pieces()

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-09-20
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed, it should be safe to zero initialize it (the field was added late).

[Bug tree-optimization/102393] Failure to optimize 2 8-bit stores into a single 16-bit store

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
SLSR might come to the rescue eventually but same as the other PR,
store-merging doesn't perform any advanced DR analysis.

[Bug tree-optimization/102392] Failure to optimize a sign extension to a zero extension

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
Note w/o explicit ZEXT_EXPR / SEXT_EXPR the GIMPLE for non-"natural" extensions
is more costly (more stmts) than the "natural" extension based on the sign
of the object because it requires an intermediate sign changing conversion.

[Bug tree-optimization/102391] Failure to optimize adjacent 8-bit loads into a single bigger load

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
the bswap pass is in principle able to handle these but it sees

  _1 = (sizetype) offset_12(D);
  _2 = RomHeader_13(D) + _1;
  _3 = *_2;
  _4 = (signed short) _3;
  _5 = _1 + 1;
  _6 = RomHeader_13(D) + _5;
  _7 = *_6;

so the constant offset is not forwarded to the MEM_REFs (int vs. size_t issue)
and the bswap pass doesn't perform any fancy dataref analysis to spot
constant offsetted same bases (it could simply use split_constant_offset
on the found base I guess or invoke DR analysis in BB mode).

[Bug tree-optimization/102387] [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Richard Biener  ---
Likely a duplicate of PR102385?

[Bug rtl-optimization/100533] [10/11/12 Regression] aarch64: -fcompare-debug failure with -O -fmodulo-sched

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
 (code_label # 0 0 3 (nil) [1 uses])
 (note # 0 0 [bb 5] NOTE_INSN_BASIC_BLOCK)
+(note # 0 0 NOTE_INSN_DELETED)
 (insn # 0 0 (set (mem:HI (plus:DI (reg/f:DI 2 x2 [102])
 (const_int 30 [0x1e])) [ MEM[(short int *)_747 + 30B + _13
* 2]+0 S2 A16])
 (reg:HI 4 x4 [104])) "t.c":6:25# {*movhi_aarch64}
  (expr_list:REG_DEAD (reg/f:DI 2 x2 [102])
 (nil)))
-(note # 0 0 NOTE_INSN_DELETED)
 (insn # 0 0 (set (reg/f:DI 2 x2 [102])
 (plus:DI (ashift:DI (reg/v:DI 0 x0 [orig:93 i_1 ] [93])
 (const_int 1 [0x1]))

sms definitely moved the deleted instruction before the mem.

[Bug ipa/101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #9 from DAC324  ---
Bug not assigned - looks like it is considered not important to be able to
compile the Linux kernel.

Am I correct in the assumption that everybody who wants to build their own
kernels, should keep using GCC 11, until further notice?

[Bug debug/94340] [9/10/11/12 Regression] -fcompare-debug -O failure on cpp1z/nodiscard3.C

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
apinski@xeond:~/src/upstream-gcc$ diff -up nodiscard3.C.gkd nodiscard3.gk.C.gkd
--- nodiscard3.C.gkd2021-09-20 07:45:03.448528331 +
+++ nodiscard3.gk.C.gkd 2021-09-20 07:45:04.373528230 +
@@ -2190,10 +2190,10 @@ Declarations used by test, sorted by DEC
 (note # 0 0 NOTE_INSN_DELETED)
 (insn # 0 0 166 (set (reg:DI 5 di [406])
 (plus:DI (reg/f:DI 7 sp)
-(const_int 7280 [0x1c70])))
"gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C":198:7# {*leadi}
+(const_int 7280 [0x1c70])))
"gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C":198:18# {*leadi}
  (nil))
 (call_insn # 0 0 166 (call (mem:QI (symbol_ref:DI ("_Z7check12v") [flags 0x41]
 ) [ check12 S1 A8])
-(const_int 0 [0]))
"gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C":198:7# {*call}
+(const_int 0 [0]))
"gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C":198:18# {*call}
  (expr_list:REG_DEAD (reg:DI 5 di)
 (expr_list:REG_EH_REGION (const_int 2 [0x2])
 (nil)))

Literally just column differences.



>From .gimple:
-  [gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C:198:7] D.2655 = check12
(); [return slot optimization]
+  [gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C:198:3] # DEBUG
BEGIN_STMT
+  [gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C:198:10] # DEBUG
BEGIN_STMT
+  [gcc/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C:198:18] D.2655 =
check12 (); [return slot optimization]


The correct line/column is actually with debugging turned on 
column 7 is the start of the statement expression.

-  if (<>>).i != 0>>)
+  D.2654 >>;>).i != 0>>)


I wonder if this is a gimplification issue where the call gets the
TARGET_EXPR's location info if the TARGET_EXPR can be removed ...  Just happens
with the statement frontiers, that the TARGET_EXPR can no longer exactly be
removed so the location info is not copied.

[Bug preprocessor/19753] different LANG settings and ccache don't work together

[mark at gcc dot gnu.org via Gcc-bugs]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #4 from Mark Wielaard  ---
Since then gcc/c-opts.c has been moved to gcc/c-family/c-opts.c which still
uses _("" and _("").

Note that there is also _("") used in some files.

All probably shouldn't be translated, since they also end up in the DWARF
output.

[Bug rtl-optimization/100533] [10/11/12 Regression] aarch64: -fcompare-debug failure with -O -fmodulo-sched

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|wrong-code  |
   Last reconfirmed||2021-09-20
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug gcov-profile/100520] [11/12 Regression] ‘-fcompare-debug’ failure with -fprofile-generate

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64, x86_64 |
   Severity|normal  |major
  Component|debug   |gcov-profile
 CC||marxin at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> -  __gcov_indirect_call_profiler_v4 (1387117561, f);
> +  __gcov_indirect_call_profiler_v4 (983609665, f);

  tree_uid = build_int_cst
  (gcov_type_node,
   cgraph_node::get (current_function_decl)->profile_id);


profile_id is computed in coverage_compute_profile_id.
Which has:

  chksum = coverage_checksum_string
(chksum, aux_base_name);


The problem is with -fcompare-debug the aux_base_name is different.
Hmm, this code for coverage_compute_profile_id has not changed.  Maybe the use
of the profile id has changed though.

[Bug debug/100520] [11/12 Regression] ‘-fcompare-debug’ failure with -fprofile-generate

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
-  __gcov_indirect_call_profiler_v4 (1387117561, f);
+  __gcov_indirect_call_profiler_v4 (983609665, f);

[Bug debug/100520] [11/12 Regression] ‘-fcompare-debug’ failure with -fprofile-generate

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-20

--- Comment #2 from Andrew Pinski  ---
I can even reproduce it on x86_64 also.

[Bug debug/100303] [11 Regression] -fcompare-debug failure (length) with -O -fno-dce -ftracer

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100304

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

[Bug debug/100304] [11/12 Regression] -fcompare-debug failure (length) with custom flags

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100303

--- Comment #6 from Andrew Pinski  ---
Since it was fixed by the patch for PR 100303, I am just goign to declare this
as a dup of bug 100303.

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

[Bug tree-optimization/85057] GCC fails to vectorize code unless dummy loop is added

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85057
Bug 85057 depends on bug 65206, which changed state.

Bug 65206 Summary: vectorized version of loop is removed, dependence analysis 
fails for *[i] vs a[j]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65206

   What|Removed |Added

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 65206, which changed state.

Bug 65206 Summary: vectorized version of loop is removed, dependence analysis 
fails for *[i] vs a[j]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65206

   What|Removed |Added

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

[Bug tree-optimization/65206] vectorized version of loop is removed, dependence analysis fails for *[i] vs a[j]

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail||11.2.1
   Target Milestone|--- |12.0

--- Comment #13 from Richard Biener  ---
Fixed for GCC 12.

[Bug tree-optimization/65206] vectorized version of loop is removed, dependence analysis fails for *[i] vs a[j]

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r12-3677-gf92901a508305f291fcf2acae0825379477724de
Author: Richard Biener 
Date:   Wed Sep 8 14:42:31 2021 +0200

tree-optimization/65206 - dependence analysis on mixed pointer/array

This adds the capability to analyze the dependence of mixed
pointer/array accesses.  The example is from where using a masked
load/store creates the pointer-based access when an otherwise
unconditional access is array based.  Other examples would include
accesses to an array mixed with accesses from inlined helpers
that work on pointers.

The idea is quite simple and old - analyze the data-ref indices
as if the reference was pointer-based.  The following change does
this by changing dr_analyze_indices to work on the indices
sub-structure and storing an alternate indices substructure in
each data reference.  That alternate set of indices is analyzed
lazily by initialize_data_dependence_relation when it fails to
match-up the main set of indices of two data references.
initialize_data_dependence_relation is refactored into a head
and a tail worker and changed to work on one of the indices
structures and thus away from using DR_* access macros which
continue to reference the main indices substructure.

There are quite some vectorization and loop distribution opportunities
unleashed in SPEC CPU 2017, notably 520.omnetpp_r, 548.exchange2_r,
510.parest_r, 511.povray_r, 521.wrf_r, 526.blender_r, 527.cam4_r and
544.nab_r see amendments in what they report with -fopt-info-loop while
the rest of the specrate set sees no changes there.  Measuring runtime
for the set where changes were reported reveals nothing off-noise
besides 511.povray_r which seems to regress slightly for me
(on a Zen2 machine with -Ofast -march=native).

2021-09-08  Richard Biener  

PR tree-optimization/65206
* tree-data-ref.h (struct data_reference): Add alt_indices,
order it last.
* tree-data-ref.c (free_data_ref): Release alt_indices.
(dr_analyze_indices): Work on struct indices and get DR_REF as
tree.
(create_data_ref): Adjust.
(initialize_data_dependence_relation): Split into head
and tail.  When the base objects fail to match up try
again with pointer-based analysis of indices.
* tree-vectorizer.c (vec_info_shared::check_datarefs): Do
not compare the lazily computed alternate set of indices.

* gcc.dg/torture/20210916.c: New testcase.
* gcc.dg/vect/pr65206.c: Likewise.

[Bug debug/96261] -fcompare-debug failure (length) with -Os -fno-gcse-lm -fnon-call-exceptions

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
I suspect r11-7750-g9f59cb7c (+ r10-7393-g5a1706f63) fixed this.  It is very
similar to PR 99230 in the patch which caused the regression (using FOR_STMT in
the C front-end rather than just the C++ front-end).

[Bug c++/46580] -fcompare-debug failure with -gstabs -g due to different symbol mangling

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #5 from Andrew Pinski  ---
The first testcase was most likely fixed by r5-9033 (r6-555 + r6-5094) which
changed where the alias managing happened.

The second testcase was most likely fixed by r10-707 which changed how the
TYPE_NAME is done for these kind of types.