[Bug tree-optimization/95845] Failure to optimize vector load made in separate operations to single load

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

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

--- Comment #3 from Richard Biener  ---
It's now vectorized at -O3 or with -ftree-slp-vectorize.  In particular
vect_slp_check_for_constructors now matches

  else if (code == BIT_INSERT_EXPR
   && VECTOR_TYPE_P (TREE_TYPE (rhs))
   && TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)).is_constant ()
   && TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)).to_constant () > 1
   && integer_zerop (gimple_assign_rhs3 (assign))
   && useless_type_conversion_p
(TREE_TYPE (TREE_TYPE (rhs)),
 TREE_TYPE (gimple_assign_rhs2 (assign)))
   && bb_vinfo->lookup_def (gimple_assign_rhs2 (assign)))
{
  /* We start to match on insert to lane zero but since the
 inserts need not be ordered we'd have to search both
 the def and the use chains.  */

this matching could be factored out and used by forwprop to build a
vector CTOR.  So I don't think it's fully fixed yet and there's an
opportunity to improve things earlier.

Partial defs of otherwise uninitialized vectors might also be an interesting
target.  When not keying on lane zero to start the match the possibility
is to start matching on the insert that does not have a single immediate
use of the result in another BIT_INSERT_EXPR.

[Bug c++/102116] structured binding is returned from a function as rvalue in C++20 mode

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Fedor Chelnokov  ---
Thanks a lot, it is clear now.

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Richard Biener  ---
The implementation issue is that

extern int var __attribute__((aligned(1)));

has DECL_ALIGN of 8 but the type still has alignment of 32, so when you
take the address and dereference it you'll get a ref with 32 bit alignment.

For aligned attributes that increase alignment that's not a correctness issue
but for aligned attributes decreasing alignment it becomes a problem.

If we want to make the above work reliably we have to arrange for the
type of 'var' to be adjusted by the aligned attribute on the decl.  But
IMHO diagnosing alignment decreasing attributes on decls would be
appropriate.  The docs clearly say (emphasis mine):

@cindex @code{aligned} variable attribute
@item aligned
@itemx aligned (@var{alignment})
The @code{aligned} attribute specifies a MINIMUM alignment for the variable
or structure field, measured in bytes.  When specified, @var{alignment} must
be an integer constant power of 2.  Specifying no @var{alignment} argument
implies the maximum alignment for the target, which is often, but by no
means always, 8 or 16 bytes.

so giving a larger alignment is valid.

Likewise for

extern int i __attribute__((aligned(1)));

the alignment of 'i' is known to be at least 1 from the attribute but
we also know that 'int' is aligned to 4 and thus can use that larger alignment.

Thus IMHO this bug is invalid.  You have to reduce the alignment of the type
which is another alignment constraint seen by the compiler.

[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above

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

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

Bug 88085 Summary: User alignments on var decls not respected if smaller than 
type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug c++/102116] structured binding is returned from a function as rvalue in C++20 mode

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
If you follow the Keywords: hyperlink, you'll get description of all the
keywords...

[Bug target/95969] Use of __builtin_aarch64_im_lane_boundsi in AArch64 arm_neon.h interferes with gimple optimisation

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 51396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51396&action=edit
Patch

Simple patch which adds both generic and gimple level folding for
__builtin_aarch64_im_lane_boundsi.
In this case (and most likely others), __builtin_aarch64_im_lane_boundsi is
removed during early inlining so it will fix the majority of the issue.

[Bug tree-optimization/102131] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu

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

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

--- Comment #6 from Jiu Fu Guo  ---
Drafted a patch as below.  With this patch, those cases can pass.

diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 7af92d1c893..a400c42919b 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -1866,6 +1866,24 @@ number_of_iterations_cond (class loop *loop,
  || !iv0->no_overflow || !iv1->no_overflow))
return false;

+  /* GT/GE has been transformed to LT/LE already.
+   cmp_code could be LT, LE or NE
+
+   For LE/LT transform
+   {iv0.base, iv0.step} LT/LE {iv1.base, iv1.step}
+   to
+   {iv0.base, iv0.step - iv1.step} LT/LE {iv1.base, 0}
+   Negative iv0.step - iv1.step means decreasing until wrap,
+   then the transform is not accurate.
+
+   For example:
+   {1, +, 1} <= {4, +, 3}
+   is not same with
+   {1, +, -2} <= {4, +, 0}
+   */
+  if ((code == LE_EXPR || code == LT_EXPR) && tree_int_cst_sign_bit
(step))
+   return false;
+
   iv0->step = step;
   if (!POINTER_TYPE_P (type))
iv0->no_overflow = false;

[Bug middle-end/25186] (short)(((int)short_var) <<1) should be folded so that the shift is done in the short type

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||easyhack
   Last reconfirmed|2021-08-21 00:00:00 |2021-9-2

--- Comment #9 from Richard Biener  ---
The optimization is still not done, the shift could be unconditionally made a
logical shift but on the smaller type.

[Bug target/30813] Numerical error--#define value differs from declared variable value

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
ok, this is really PR 323.
With -std=c90 or -std=c99, it provides the correct thing for x86 (but note it
is not 0 really).

Also you could use -mfpmath=sse these days.

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

[Bug middle-end/323] optimized code gives strange floating point results

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kevin.glass at pnl dot gov

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

[Bug tree-optimization/102155] LIM fill_always_executed_in handles contains_call incorrectly

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Richard Biener  ---
It seems I was mistaken, get_loop_body_in_dom_order seems to exactly care for
this specific case.

[Bug target/102171] New: vget_low_*/vget_high_* intrinsics should become BIT_FIELD_REF during gimple

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

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

Bug ID: 102171
   Summary: vget_low_*/vget_high_* intrinsics should become
BIT_FIELD_REF during gimple
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 95958
  Target Milestone: ---
Target: aarch64*-linux-gnu

#include 
float16x4_t f0(float16x8_t b)
{
  return vget_low_f16 (b);
}
float16x4_t f(float16x8_t b)
{
  return vget_high_f16 (b);
}
float16x4_t f1(float16x8_t b)
{
  return ((float16x4_t*)&b)[0];
}
float16x4_t f2(float16x8_t b)
{
  return ((float16x4_t*)&b)[1];
}
 CUT 
For little-endian f0 and f1 are the same, and f and f2 are the same.
For big-endian f0 and f2 are the same, and f0 and f1 are the same.

The reason why we should simplify them at the gimple level is to allow the
gimple optimizers do the work for us.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
[Bug 95958] [meta-bug] Inefficient arm_neon.h code for AArch64

[Bug target/44987] *mmintrin.h files incompatible with partial __attribute__((target("sse...")))

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed since r0-124016 for GCC 4.9.0

[Bug target/44073] x86 constants could be unduplicated for -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|x86 constants could be  |x86 constants could be
   |unduplicated|unduplicated for -Os
   Last reconfirmed|2010-05-11 08:42:34 |2021-9-2
   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c/102172] New: ice in determine_exit_conditions, at tree-ssa-loop-manip.c:1049

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102172
   Summary: ice in determine_exit_conditions, at
tree-ssa-loop-manip.c:1049
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

char **Gif_ClipImage_gfi_0;
int Gif_ClipImage_y, Gif_ClipImage_shift;
void Gif_ClipImage() {
  for (; Gif_ClipImage_y >= Gif_ClipImage_shift; Gif_ClipImage_y++)
Gif_ClipImage_gfi_0[Gif_ClipImage_shift] =
Gif_ClipImage_gfi_0[Gif_ClipImage_y];
}

compiled by recent gcc trunk and compiler flag -O3 -march=bdver2,
does this:

$ /home/dcb/gcc/results/bin/gcc -c -O3 -march=bdver2 bug753.c
during GIMPLE pass: aprefetch
bug753.c: In function ‘Gif_ClipImage’:
bug753.c:3:6: internal compiler error: in determine_exit_conditions, at
tree-ssa-loop-manip.c:1049
3 | void Gif_ClipImage() {
  |  ^
0xf070ff determine_exit_conditions(loop*, tree_niter_desc*, unsigned int,
tree_node**, tree_node**, tree_node**, tree_code*, tree_node**)
../../trunk.git/gcc/tree-ssa-loop-manip.c:1049
0xf070ff tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)

The bug first starts sometime between git hash f8977166135de09f,
dated 20210824 and git hash 3ac6b5cff1eca4e1, dated 20210825.

[Bug target/59625] asm goto and TARGET_FOUR_JUMP_LIMIT

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed so closing.

[Bug c/102172] ice in determine_exit_conditions, at tree-ssa-loop-manip.c:1049

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
That's only 35 revisions, I'll have a go at a git bisect.

[Bug c/102172] ice in determine_exit_conditions, at tree-ssa-loop-manip.c:1049

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r12-3136-g3673dcf6d6baeb67.

[Bug c/102172] [12 Regression] ICE in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|ice in  |[12 Regression] ICE in
   |determine_exit_conditions,  |determine_exit_conditions,
   |at  |at
   |tree-ssa-loop-manip.c:1049  |tree-ssa-loop-manip.c:1049
   ||since
   ||r12-3136-g3673dcf6d6baeb67
 Status|UNCONFIRMED |NEW
 CC||guojiufu at gcc dot gnu.org
   Last reconfirmed||2021-09-02

[Bug tree-optimization/102172] [12 Regression] ICE in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||ice-on-valid-code
  Component|c   |tree-optimization

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

--- Comment #1 from HaoChen Gui  ---
For pr81348.c, it was already fixed by r11-8941. Segher backported it. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952#c12

PASS: gcc.target/powerpc/pr81348.c (test for excess errors)
PASS: gcc.target/powerpc/pr81348.c scan-assembler \\mlha\\M
PASS: gcc.target/powerpc/pr81348.c scan-assembler \\mmtvsrwa\\M

[Bug target/95969] Use of __builtin_aarch64_im_lane_boundsi in AArch64 arm_neon.h interferes with gimple optimisation

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
> Created attachment 51396 [details]
> Patch
> 
> Simple patch which adds both generic and gimple level folding for
> __builtin_aarch64_im_lane_boundsi.
> In this case (and most likely others), __builtin_aarch64_im_lane_boundsi is
> removed during early inlining so it will fix the majority of the issue.

looks like the wrong patch was attached?

[Bug target/67129] x86: erratic parsing of "#pragma GCC target ("...")"

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #6 from Andrew Pinski  ---
So starting with GCC 7 we get a warning with the no-warning case:
:3:13: warning: SSE instruction set disabled, using 387 arithmetics
 void t1(void) { }
 ^
:3:13: warning: SSE instruction set disabled, using 387 arithmetics

Starting with GCC 11 we get a warning on the pragma itself:
:2:29: warning: SSE instruction set disabled, using 387 arithmetics
2 | #pragma GCC target ("no-sse")
  | ^
:3:13: warning: SSE instruction set disabled, using 387 arithmetics
3 | void t1(void) { }
  | ^
:3:13: warning: SSE instruction set disabled, using 387 arithmetics

[Bug target/67129] x86: erratic parsing of "#pragma GCC target ("...")"

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Fixed by r11-3183 in GCC 11.
I have not checked what caused the change in GCC 7 though.

[Bug target/67129] x86: erratic parsing of "#pragma GCC target ("...")"

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Dominik Vogt from comment #4)
> Unlike
> global_options, the structure global_options_set is never saved or restored,
> so any target pragma or attribute may change the structure for the rest of
> the compilation unit.  This may or may not cause weird things to happen.

This is what r11-3183 solves exactly.

[Bug target/95969] Use of __builtin_aarch64_im_lane_boundsi in AArch64 arm_neon.h interferes with gimple optimisation

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #51396|0   |1
is obsolete||

--- Comment #5 from Andrew Pinski  ---
Created attachment 51397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51397&action=edit
Correct patch

[Bug other/81242] Clear-to-EOL in diagnostics colorization corrupts output

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug other/90411] Colored diagnostics can omit characters

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

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

[Bug other/90411] Colored diagnostics can omit characters

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

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

--- Comment #6 from Andrew Pinski  ---
Another reference of the problem.
  http://invisible-island.net/xterm/xterm.faq.html#grep_colors

[Bug rtl-optimization/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2020-12-31 00:00:00 |2021-9-2

--- Comment #8 from Andrew Pinski  ---
Part of this is register allocation but the __int128_t one seems to be more and
it comes down to how we don't handle double register integer arthematic that
well.  On the gimple level we leave it as normal and only split it up during
expansion to RTL.

[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above

[arnd at linaro dot org via Gcc-bugs]

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

--- Comment #27 from Arnd Bergmann  ---
The linux kernel instance from arch/parisc/ looks like a bug we fixed in
arch/arm a few years ago, by adding the required alignment directive to the
linker script.

If changing the linker script is not possible because of boot loader
requirements, then this should do as well:

diff --git a/arch/parisc/boot/compressed/misc.c
b/arch/parisc/boot/compressed/misc.c
index 2d395998f524..b91d6cf80c06 100644
--- a/arch/parisc/boot/compressed/misc.c
+++ b/arch/parisc/boot/compressed/misc.c
@@ -26,7 +26,7 @@
 extern char input_data[];
 extern int input_len;
 /* output_len is inserted by the linker possibly at an unaligned address */
-extern __le32 output_len __aligned(1);
+extern struct { __u8 bytes; } output_len;
 extern char _text, _end;
 extern char _bss, _ebss;
 extern char _startcode_end;

[Bug testsuite/50670] GCC testsuite try to execute sse2 code on non-sse2 machines

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed on the trunk at the time by r0-108118. Even though the testcase was
backported for GCC 4.6.1, the fix for the testcase was not.

So fixed for GCC 4.7.0.

[Bug testsuite/50704] FAIL: gcc.target/i386/warn-vect-op-1.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |testsuite
   Target Milestone|--- |4.7.0

--- Comment #10 from Andrew Pinski  ---
Fixed by r0-112415.

[Bug testsuite/50704] FAIL: gcc.target/i386/warn-vect-op-1.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug testsuite/52249] FAIL: gfortran.dg/vect/pr32380.f

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug fortran/60236] gfortran.dg/vect/pr32380.f fails on ARM

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Greta.Yorsh at arm dot com

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

[Bug tree-optimization/102172] [12 Regression] ICE in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67

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

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

--- Comment #3 from Richard Biener  ---
there are duplicates of this bug already

[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Fixed by r0-114550.

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[petro.karashchenko at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Petro Karashchenko  
---
Sorry but based on

@cindex @code{aligned} variable attribute
@item aligned
@itemx aligned (@var{alignment})
The @code{aligned} attribute specifies a MINIMUM alignment for the variable
or structure field, measured in bytes.  When specified, @var{alignment} must
be an integer constant power of 2.  Specifying no @var{alignment} argument
implies the maximum alignment for the target, which is often, but by no
means always, 8 or 16 bytes.

I do not see any statement saying that giving a lower alignment is invalid.
I see "attribute specifies a MINIMUM alignment" so "int i
__attribute__((aligned(1)));" specifies that between 1 and 4 the 1 should be
chosen as a "MINIMUM".

The statement "must be an integer constant power of 2" is also valid because 1
is a 0 power of 2. So no questions here.

"Thus IMHO this bug is invalid." -- I do not see any strong argument on this.
All prerequisites from a description are met, so this is a pure bug.

[Bug tree-optimization/102172] [12 Regression] ICE in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #3)
> there are duplicates of this bug already

Yes dup of bug 102087.

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

[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67

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

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

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

[Bug testsuite/70316] FAIL: gcc.dg/tree-ssa/pr68714.c scan-tree-dump-times optimized " <= " 1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |6.0
 Resolution|--- |FIXED
  Component|tree-optimization   |testsuite

--- Comment #3 from Andrew Pinski  ---
Fixed by r6-7443.

[Bug tree-optimization/99591] Improving __builtin_add_overflow performance on x86-64

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

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

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

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

commit r12-3312-g2af6dd77ea742d4ee911f466878624972929508a
Author: Jakub Jelinek 
Date:   Thu Sep 2 11:25:07 2021 +0200

match.pd: Demote IFN_{ADD,SUB,MUL}_OVERFLOW operands [PR99591]

The overflow builtins work on infinite precision integers and then convert
to the result type's precision, so any argument promotions are useless.
The expand_arith_overflow expansion is able to demote the arguments itself
through get_range_pos_neg and get_min_precision calls and if needed promote
to whatever mode it decides to perform the operations in, but if there are
any promotions it demoted, those are already expanded.  Normally combine
would remove the useless sign or zero extensions when it sees the result
of those is only used in a lowpart subreg, but typically those lowpart
subregs appear multiple times in the pattern so that they describe properly
the overflow behavior and combine gives up, so we end up with e.g.
movswl  %si, %esi
movswl  %di, %edi
imulw   %si, %di
seto%al
where both movswl insns are useless.

The following patch fixes it by demoting operands of the ifns (only gets
rid of integral to integral conversions that increase precision).
While IFN_{ADD,MUL}_OVERFLOW are commutative and just one simplify would be
enough, IFN_SUB_OVERFLOW is not, therefore two simplifications.

2021-09-02  Jakub Jelinek  

PR tree-optimization/99591
* match.pd: Demote operands of IFN_{ADD,SUB,MUL}_OVERFLOW if they
were promoted.

* gcc.target/i386/pr99591.c: New test.
* gcc.target/i386/pr97950.c: Match or reject setb or jn?b
instructions
together with seta or jn?a.

[Bug tree-optimization/99591] Improving __builtin_add_overflow performance on x86-64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for GCC 12.

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Petro Karashchenko from comment #11)
> Sorry but based on
> 
> @cindex @code{aligned} variable attribute
> @item aligned
> @itemx aligned (@var{alignment})
> The @code{aligned} attribute specifies a MINIMUM alignment for the variable
> or structure field, measured in bytes.  When specified, @var{alignment} must
> be an integer constant power of 2.  Specifying no @var{alignment} argument
> implies the maximum alignment for the target, which is often, but by no
> means always, 8 or 16 bytes.
> 
> I do not see any statement saying that giving a lower alignment is invalid.
> I see "attribute specifies a MINIMUM alignment" so "int i
> __attribute__((aligned(1)));" specifies that between 1 and 4 the 1 should be
> chosen as a "MINIMUM".
> 
> The statement "must be an integer constant power of 2" is also valid because
> 1 is a 0 power of 2. So no questions here.
> 
> "Thus IMHO this bug is invalid." -- I do not see any strong argument on
> this. All prerequisites from a description are met, so this is a pure bug.

The testcase of the description is

typedef int __attribute__((vector_size(16))) v4si; 

v4si a4 __attribute__((aligned(4)));

that creates a variable with minimum alignment 4 (as seen in the assembly
output).  But you give the variable a type of 'v4si' which has larger
alignment and thus is in conflict with the alignment for the storage you
specified.  That automatically runs into the standard mandated rule that
any access has to be aligned according to its type.

The expectation that accesses should be unaligned is wrong unless you
also use an unaligned type.

That GCC creates an object with the desired alignment isn't wrong - you told it
so.

As I said the conflict should probably be diagnosed as it results in unexpected
behavior.

[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above

[deller at gmx dot de via Gcc-bugs]

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

--- Comment #28 from deller at gmx dot de ---
Arnd,
there are various calls to the get_unaligned_X() functions in all kernel
bootloaders, specifically in the kernel decompression routines: 
[deller@ls3530 linux-2.6]$ grep get_unaligned lib/decompress*
lib/decompress_unlz4.c: size_t out_len = get_unaligned_le32(input + in_len);
lib/decompress_unlz4.c: chunksize = get_unaligned_le32(inp);
lib/decompress_unlz4.c: chunksize = get_unaligned_le32(inp);
lib/decompress_unlzo.c: version = get_unaligned_be16(parse);
lib/decompress_unlzo.c: if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
lib/decompress_unlzo.c: dst_len = get_unaligned_be32(in_buf);
lib/decompress_unlzo.c: src_len = get_unaligned_be32(in_buf);

So sadly it's not possible to work around that cases with linker scripts,
because they work on externally generated compressed files (kernel code) for
which the specs of the compressed files can't be changed.
Same for the output_len variable - externally linked in directly behind the
code and not (easily?) changeable.
Helge

[Bug c++/61061] FAIL: g++.dg/inherit/covariant7.C

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
  Component|testsuite   |c++
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-02

--- Comment #3 from Andrew Pinski  ---
48#'fdesc_expr' not supported by dump_expr#

Confirmed, still a bug, FDESC_EXPR is not handled by dump_expr still.

[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above

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

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

--- Comment #29 from Andrew Pinski  ---
(In reply to deller from comment #28)
> Arnd,
> there are various calls to the get_unaligned_X() functions in all kernel
> bootloaders, specifically in the kernel decompression routines: 

get_unaligned_ function is fine and working correctly.  It is only the
declarations of output_len (and like declarations) which problematic.

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[petro.karashchenko at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Petro Karashchenko  
---
Sorry that I brought some confusion. I was reading some latest comments and
didn't fully payed attention to a ticket description. The reason for my comment
is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94662 that was closed as a
duplicate of this issue.

For the variable alignment vs type alignment when it is specified your
statement seems to be correct, however I agree that it still has a lot of open
points. For example what should be the code if we put variable into a structure

typedef int __attribute__((vector_size(16))) v4si; 

struct {
  v4si a __attribute__((aligned(4)));
} b;

Should it still get aligned on 16 bytes or 4 bytes?

In my case I was seeking for a way to generate alignment tolerant code without
using
struct {
  int a;
} __attribute__((packed));

Obviously "int a __attribute__((packed));" does not work, so I tried to solve
it via "__attribute__((aligned(1)))" attribute.

[Bug target/68275] bb-slp-38 FAILs on armeb

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2015-11-11 00:00:00 |2021-9-2

--- Comment #5 from Andrew Pinski  ---
arm_evpc_neon_vtbl (struct expand_vec_perm_d *d)
{
  rtx rperm[MAX_VECT_LEN], sel;
  machine_mode vmode = d->vmode;
  unsigned int i, nelt = d->perm.length ();

  /* TODO: ARM's VTBL indexing is little-endian.  In order to handle GCC's
 numbering of elements for big-endian, we must reverse the order.  */
  if (BYTES_BIG_ENDIAN)
return false;

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[petro.karashchenko at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Petro Karashchenko  
---
Probably I need to fill a ticket to allow "packed" to be applied for variables
and not only to a types of structure fields.

[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=58253,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52402
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #14 from Andrew Pinski  ---
Fxied so closing.

[Bug tree-optimization/97352] gcc.dg/vect/bb-slp-pr78205.c fails to vectorize all opportunities with AVX

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97351
   Last reconfirmed||2021-09-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug target/98792] Fail to use SHRN instructions for narrowing shift on aarch64

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

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

--- Comment #3 from Andrew Pinski  ---
We do produce shrn2 but not shrn now:

.L2:
ldp q0, q1, [x0]
add x0, x0, 32
ushrv0.4s, v0.4s, 3
xtn v0.4h, v0.4s
shrn2   v0.8h, v1.4s, 3
str q0, [x1], 16
cmp x0, x2
bne .L2

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #15 from rguenther at suse dot de  ---
On Thu, 2 Sep 2021, petro.karashchenko at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085
> 
> --- Comment #13 from Petro Karashchenko  
> ---
> Sorry that I brought some confusion. I was reading some latest comments and
> didn't fully payed attention to a ticket description. The reason for my 
> comment
> is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94662 that was closed as a
> duplicate of this issue.
> 
> For the variable alignment vs type alignment when it is specified your
> statement seems to be correct, however I agree that it still has a lot of open
> points. For example what should be the code if we put variable into a 
> structure
> 
> typedef int __attribute__((vector_size(16))) v4si; 
> 
> struct {
>   v4si a __attribute__((aligned(4)));
> } b;
> 
> Should it still get aligned on 16 bytes or 4 bytes?
> 
> In my case I was seeking for a way to generate alignment tolerant code without
> using
> struct {
>   int a;
> } __attribute__((packed));
> 
> Obviously "int a __attribute__((packed));" does not work, so I tried to solve
> it via "__attribute__((aligned(1)))" attribute.

I don't think it makes much sense to generate alignment "tolerant" code
for declarations, so when it is about indirect accesses via pointers
then simply use a pointer to a type with appropriate alignment.  Then
the access will be "tolerant" but when the compiler sees the object
accessed is actually of bigger alignment it isn't forced to honor
your "tolerant" minimum alignment.

When you're facing the situation that you have to access data at
some symbol and that symbol can end up with alignment less than
what its type specifies then you cannot just do

extern int possibly_misaligned_data __attribute__((aligned(1)));

which seems to be the case kernel folks run into with hppa.  Instead
you have to put the "tolerance" on the type again:

typedef int tolerant_int __attribute__((aligned(1)));
extern tolerant_int possibly_misaligned_data;

[Bug target/95969] Use of __builtin_aarch64_im_lane_boundsi in AArch64 arm_neon.h interferes with gimple optimisation

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

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

--- Comment #6 from Andrew Pinski  ---
There are two bugs with this change.
First is in the change itself; I forgot to check to make sure totalsize and
elementsize are non-zero. I have that fixed.
The second issue is some gimple level passes are not ready to change the
function to a GIMPLE_NOP yet.  I will fix those tomorrow.

Right now I see evpr and cunroll so far.

[Bug target/102173] New: [12 Regression] ICEs gcc.target/aarch64/sve/acle/general-c/type_redef_1.c after recent error recovery patch

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

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

Bug ID: 102173
   Summary: [12 Regression] ICEs
gcc.target/aarch64/sve/acle/general-c/type_redef_1.c
after recent error recovery patch
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/type_redef_1.c:5:9:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in register_vector_type, at
config/aarch64/aarch64-sve-builtins.cc:3419
0x6a8c0b tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/tree.c:8738
0x11ed7bf tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/tree.h:3523
0x11ed7bf register_vector_type
   
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:3419
0x11ed7bf aarch64_sve::handle_arm_sve_h()
   
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:3535
0x802ab7 aarch64_pragma_aarch64
   
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-c.c:298
0x7309a3 c_parser_pragma
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c/c-parser.c:12573
0x75e56b c_parser_external_declaration
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c/c-parser.c:1761
0x75ecef c_parser_translation_unit
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c/c-parser.c:1653
0x75ecef c_parse_file()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c/c-parser.c:22581
0x7c8097 c_common_parse_file()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-opts.c:1236

[Bug target/102173] [12 Regression] ICEs gcc.target/aarch64/sve/acle/general-c/type_redef_1.c after recent error recovery patch

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-09-02
   Target Milestone|--- |12.0

--- Comment #1 from Andrew Pinski  ---
I will fix this tomorrow.

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[petro.karashchenko at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Petro Karashchenko  
---
Again based on your description even if we go with putting "tolerance" on the
type should not work because in "typedef int tolerant_int
__attribute__((aligned(1)));" the "int" default alignment is 4 and we apply
"1", so according to "The @code{aligned} attribute specifies a MINIMUM
alignment for the variable or structure field, measured in bytes." the compiler
should use the MAX of all alignments of the type MAX(4,1) is 4 and not 1.

So
typedef int int_1 __attribute__((aligned(1)));
typedef int_1 int_2 __attribute__((aligned(2)));
typedef int_2 int_4 __attribute__((aligned(4)));
typedef int_4 int_8 __attribute__((aligned(8)));
typedef int_8 int_16 __attribute__((aligned(16)));

int_16 a;

Then a should get aligned on 16 and not on 1.

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #17 from rguenther at suse dot de  ---
On Thu, 2 Sep 2021, petro.karashchenko at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085
> 
> --- Comment #16 from Petro Karashchenko  
> ---
> Again based on your description even if we go with putting "tolerance" on the
> type should not work because in "typedef int tolerant_int
> __attribute__((aligned(1)));" the "int" default alignment is 4 and we apply
> "1", so according to "The @code{aligned} attribute specifies a MINIMUM
> alignment for the variable or structure field, measured in bytes." the 
> compiler
> should use the MAX of all alignments of the type MAX(4,1) is 4 and not 1.
> 
> So
> typedef int int_1 __attribute__((aligned(1)));
> typedef int_1 int_2 __attribute__((aligned(2)));
> typedef int_2 int_4 __attribute__((aligned(4)));
> typedef int_4 int_8 __attribute__((aligned(8)));
> typedef int_8 int_16 __attribute__((aligned(16)));
> 
> int_16 a;
> 
> Then a should get aligned on 16 and not on 1.

It is (aligned to 16).

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[petro.karashchenko at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Petro Karashchenko  
---
Yes. So I just checked GCC man and see that

The aligned attribute can only increase the alignment; but you can decrease it
by specifying packed as well. See below.

Note that the effectiveness of aligned attributes may be limited by inherent
limitations in your linker. On many systems, the linker is only able to arrange
for variables to be aligned up to a certain maximum alignment. (For some
linkers, the maximum supported alignment may be very very small.) If your
linker is only able to align variables up to a maximum of 8 byte alignment,
then specifying aligned(16) in an __attribute__ will still only provide you
with 8 byte alignment. See your linker documentation for further information.

So

typedef int tolerant_int __attribute__((aligned(1)));
extern tolerant_int possibly_misaligned_data;

"possibly_misaligned_data" will still be 4 bytes aligned.

The real problem is that "packed" can be applied only to struct or union type
definition, I can't just do

typedef int tolerant_int __attribute__((packed));
extern tolerant_int possibly_misaligned_data;

So it will simply not work and I need to wrap a variable into a struct or
union.

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[petro.karashchenko at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Petro Karashchenko  
---
Sorry my bad again. Just checked with GCC 11 man page

When used on a struct, or struct member, the aligned attribute can only
increase the alignment; in order to decrease it, the packed attribute must be
specified as well. When used as part of a typedef, the aligned attribute can
both increase and decrease alignment, and specifying the packed attribute
generates a warning.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #21 from Rimvydas (RJ)  ---
After long poking with gdb the tree t1 and t2 structures in
lto-symtab.c:warn_type_compatibility_p() just before "lev |5" is returned, it
looks like trees are are almost identical except for t1->decl_common.off_align
== 1 vs 2.  This looks suspicious since these are in call to already type/rank
specific runtime library function _gfortran_reshape_r8().  Sadly the
lto-dump(1) tool is unable to dump type information about called functions
arguments.

Looking at gcc/fortran/intrinsic.c it is seen that -fdefault-real-*
-fdefault-integer-* options have same effect as -freal-M-real-N or
-finteger-M-integer-N options.  This does not look intentional as this breaks
use of certain (more archaic forms) intrinsics with variables and numeric
constants that have explicit kinds.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #22 from Rimvydas (RJ)  ---
Created attachment 51398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51398&action=edit
proposed patch

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[petro.karashchenko at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Petro Karashchenko  
---
I just checked next case

typedef int tolerant_int __attribute__((aligned(1)));
tolerant_int var;

int foo(void)
{
  return var;
}
--
arm-none-eabi-gcc -save-temps -Wall -Wextra -c -mcpu=arm7tdmi -mthumb test.c
-O0
--
.cpu arm7tdmi
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 6
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "test.c"
.text
.comm   var,4,1
.align  1
.global foo
.arch armv4t
.syntax unified
.code   16
.thumb_func
.fpu softvfp
.type   foo, %function
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
push{r7, lr}
add r7, sp, #0
ldr r3, .L3
ldr r3, [r3]
movsr0, r3
mov sp, r7
@ sp needed
pop {r7}
pop {r1}
bx  r1
.L4:
.align  2
.L3:
.word   var
.size   foo, .-foo
.ident  "GCC: (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]"
-

So seems the alignment decrease does not work on types.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #23 from Rimvydas (RJ)  ---
Created attachment 51399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51399&action=edit
additional patch, for previous behavior

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #24 from Rimvydas (RJ)  ---
Created attachment 51400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51400&action=edit
alog() intrinsic testcases

[Bug c++/102174] New: Unused result of undefined behavior arithmetic is accepted during constant evaluation

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 102174
   Summary: Unused result of undefined behavior arithmetic is
accepted during constant evaluation
   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: ---

See https://godbolt.org/z/d38ozc91x.
```C++
#include 
constexpr bool f() {
  1 / 0;
  1.0 / 0;
  1 % 0;
  INT32_MIN / INT32_C(-1);
  INT32_MIN * INT32_C(-1);
  INT32_MAX + INT32_C(1);
  INT16_C(INT32_MAX + INT32_C(1));
  return true;
}
constexpr bool b{f()};
```
```
: In function 'constexpr bool f()':
:3:5: warning: division by zero [-Wdiv-by-zero]
3 |   1 / 0;
  |   ~~^~~
:3:5: warning: statement has no effect [-Wunused-value]
:4:7: warning: division by zero [-Wdiv-by-zero]
4 |   1.0 / 0;
  |   ^~~
:4:7: warning: statement has no effect [-Wunused-value]
:5:5: warning: division by zero [-Wdiv-by-zero]
5 |   1 % 0;
  |   ~~^~~
:5:5: warning: statement has no effect [-Wunused-value]
:6:13: warning: integer overflow in expression of type 'int' results in
'-2147483648' [-Woverflow]
6 |   INT32_MIN / INT32_C(-1);
  | ^
:6:13: warning: statement has no effect [-Wunused-value]
:7:13: warning: integer overflow in expression of type 'int' results in
'-2147483648' [-Woverflow]
7 |   INT32_MIN * INT32_C(-1);
  | ^
:7:13: warning: statement has no effect [-Wunused-value]
:8:13: warning: integer overflow in expression of type 'int' results in
'-2147483648' [-Woverflow]
8 |   INT32_MAX + INT32_C(1);
  | ^
:8:13: warning: statement has no effect [-Wunused-value]
In file included from
/opt/compiler-explorer/gcc-11.2.0/lib/gcc/x86_64-linux-gnu/11.2.0/include/stdint.h:9,
 from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/cstdint:41,
 from :1:
:9:21: warning: integer overflow in expression of type 'int' results in
'-2147483648' [-Woverflow]
9 |   INT16_C(INT32_MAX + INT32_C(1));
  | ^
:9:21: warning: statement has no effect [-Wunused-value]
Compiler returned: 0
```

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #25 from Rimvydas (RJ)  ---
Created attachment 51401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51401&action=edit
testcase with ice deep in rtl code for sign extend

[Bug c++/102175] New: Error comparing the pointers on static class fields in static_assert

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 102175
   Summary: Error comparing the pointers on static class fields in
static_assert
   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: ---

This code:
```
template struct C { 
static int x; 
};

template int C::x = 0;

int main() { 
static_assert(&C<0>::x != &C<1>::x); 
}
```
produces an error in GCC: "non-constant condition for static assertion", but
accepted in other compilers. Demo: https://gcc.godbolt.org/z/o6dE3GaMK

A similar code without templates is accepted by GCC:
```
struct C { static int x; };
int C::x = 0;
struct D { static int x; };
int D::x = 0;
int main() { static_assert( &D::x != &C::x ); }
```

[Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #21 from rguenther at suse dot de  ---
On Thu, 2 Sep 2021, petro.karashchenko at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085
> 
> --- Comment #20 from Petro Karashchenko  
> ---
> I just checked next case
> 
> typedef int tolerant_int __attribute__((aligned(1)));
> tolerant_int var;
> 
> int foo(void)
> {
>   return var;
> }
> --
> arm-none-eabi-gcc -save-temps -Wall -Wextra -c -mcpu=arm7tdmi -mthumb test.c
> -O0
> --
> .cpu arm7tdmi
> .eabi_attribute 20, 1
> .eabi_attribute 21, 1
> .eabi_attribute 23, 3
> .eabi_attribute 24, 1
> .eabi_attribute 25, 1
> .eabi_attribute 26, 1
> .eabi_attribute 30, 6
> .eabi_attribute 34, 0
> .eabi_attribute 18, 4
> .file   "test.c"
> .text
> .comm   var,4,1
> .align  1
> .global foo
> .arch armv4t
> .syntax unified
> .code   16
> .thumb_func
> .fpu softvfp
> .type   foo, %function
> foo:
> @ Function supports interworking.
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 1, uses_anonymous_args = 0
> push{r7, lr}
> add r7, sp, #0
> ldr r3, .L3
> ldr r3, [r3]
> movsr0, r3
> mov sp, r7
> @ sp needed
> pop {r7}
> pop {r1}
> bx  r1
> .L4:
> .align  2
> .L3:
> .word   var
> .size   foo, .-foo
> .ident  "GCC: (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
> 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]"
> -
> 
> So seems the alignment decrease does not work on types.

It works on trunk.  There were bugs fixed for arm "recently"
(your 9.2.1 is nearly two years old).

[Bug tree-optimization/102176] New: BB SLP scalar costing is off with extern promoted nodes

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

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

Bug ID: 102176
   Summary: BB SLP scalar costing is off with extern promoted
nodes
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

On aarch64 we can see

int foo(long *restrict res, long *restrict foo, long a, long b)
{
  res[0] = ((foo[0] * a) >> 1) + foo[0];
  res[1] = ((foo[1] * b) >> 1) + foo[1];
}

being vectorized as

t.c:3:10: note: Costing subgraph:
t.c:3:10: note: node 0x35f03b0 (max_nunits=2, refcnt=1)
t.c:3:10: note: op template: *res_12(D) = _4;
t.c:3:10: note: stmt 0 *res_12(D) = _4;
t.c:3:10: note: stmt 1 MEM[(long int *)res_12(D) + 8B] = _8;
t.c:3:10: note: children 0x35f0440
t.c:3:10: note: node 0x35f0440 (max_nunits=2, refcnt=1)
t.c:3:10: note: op template: _4 = _1 + _3;
t.c:3:10: note: stmt 0 _4 = _1 + _3;
t.c:3:10: note: stmt 1 _8 = _5 + _7;
t.c:3:10: note: children 0x35f04d0 0x35f0560
t.c:3:10: note: node 0x35f04d0 (max_nunits=2, refcnt=2)
t.c:3:10: note: op template: _1 = *foo_10(D);
t.c:3:10: note: stmt 0 _1 = *foo_10(D);
t.c:3:10: note: stmt 1 _5 = MEM[(long int *)foo_10(D) + 8B];
t.c:3:10: note: node 0x35f0560 (max_nunits=2, refcnt=1)
t.c:3:10: note: op template: _3 = _2 >> 1;
t.c:3:10: note: stmt 0 _3 = _2 >> 1;
t.c:3:10: note: stmt 1 _7 = _6 >> 1;
t.c:3:10: note: children 0x35f05f0 0x35f0710
t.c:3:10: note: node (external) 0x35f05f0 (max_nunits=2, refcnt=1)
t.c:3:10: note: stmt 0 _2 = _1 * a_11(D);
t.c:3:10: note: stmt 1 _6 = _5 * b_14(D);
t.c:3:10: note: children 0x35f04d0 0x35f0680
t.c:3:10: note: node (external) 0x35f0680 (max_nunits=1, refcnt=1)
t.c:3:10: note: { a_11(D), b_14(D) }
t.c:3:10: note: node (constant) 0x35f0710 (max_nunits=1, refcnt=1)
t.c:3:10: note: { 1, 1 }

so the promoted external node 0x35f05f0 should keep the load live.
vect_bb_slp_scalar_cost relies on PURE_SLP_STMT but
that's unreliable here since the per-stmt setting cannot capture the
different uses.  The code shares intend (and some bugs) with
vect_bb_slp_mark_live_stmts and the problem in general is a bit
difficult given the lack of back-mapping from stmt to SLP nodes
referencing it.

[Bug tree-optimization/102176] BB SLP scalar costing is off with extern promoted nodes

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-02
 Status|UNCONFIRMED |ASSIGNED
   Keywords||missed-optimization

[Bug tree-optimization/102176] BB SLP scalar costing is off with extern promoted nodes

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

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

--- Comment #1 from Richard Biener  ---
So in this case we have _2 = _1 * a_11(D) still pure_slp even though it does
not participate in any vectorized SLP node.

Unfortunately marking of PURE_SLP_STMTs happens before analyzing operations
(the vectorizable_* functions called rely on the SLP type here for no good
reason).  But that analysis can promote nodes extern and the SLP type is
not adjusted afterwards.

[Bug c++/96286] Unhelpful errors after a failed static_assert

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

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

--- Comment #6 from Jason Merrill  ---
Created attachment 51402
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51402&action=edit
patch to silence constexpr issues with erroneous functions

Here are a couple of other commits I tried to reduce error cascades, but they
also didn't help with the vector testcase.

[Bug c++/96286] Unhelpful errors after a failed static_assert

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

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

--- Comment #7 from Jason Merrill  ---
Created attachment 51403
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51403&action=edit
patch to stop compiling a function after static_assert

[Bug target/102173] [12 Regression] ICEs gcc.target/aarch64/sve/acle/general-c/type_redef_1.c after recent error recovery patch

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
Appeared after r12-3278 g:823685221de986afb729910a6f2237f07a377f17

[Bug tree-optimization/102176] BB SLP scalar costing is off with extern promoted nodes

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

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

--- Comment #2 from Richard Biener  ---
Created attachment 51404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51404&action=edit
patch

This brute-force approach of re-computing something like PURE_SLP_STMT minus
the set of defs used in extern def SLP nodes does the trick.

[Bug c++/96286] Unhelpful errors after a failed static_assert

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #5)
> I get better results if I add the static_assert to __uninitialized_copy_a,
> so we hit it before queuing any further instantiations.

I actually need to check the same assertion in that function anyway, for the
constexpr std::vector case.

I'll see how the diagnostics look on that branch after rebasing on trunk, to
get your recent G++ changes. Thanks.

[Bug pch/71934] pch cannot be disabled so gcc cannot be position independent

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #6 from Iain Sandoe  ---

> Actually you could exactly what is done for darwin targets to get it working 
> on PIE.

Darwin does the same as Linux - disables PIE for the $host build (although PIE
is the default for Darwin for a long time).

 - Making PCH position independent is probably a larger job than extending the
modules tree streamer to replace it (neither is a trivial activity).

> Now having PCH around might not be useful anyways.  Someone would have to 
> check to see if anyone uses PCH still.

- a) I don't see that anything has changed to make the value go down - quite
the opposite, headers have become larger and more complex and parsing has only
increased in load.

- b) There are build recipes in the wild that use it, ripping it out would need
to be done in a way that didn't break such recipes.

> There should really be a build-time option to make gcc completely ignore the 
> existence of .gch files and fallback to the normal headers as if they didn't 
> exist.

This would be useful; I have a Darwin platform version that is forbidden to be
no-PIE so that PCH is disabled by local patches, I might look into a configure
option***, but see (b) above about simple removal - we'd have to figure out
what to do with command lines that depend on it.

> so, GCC has module support now...

GCC has experimental modules support with some bugs.
modules suppport is not a direct replacement for PCH (e.g. it only works with
>= C++20 and not with the other c-family FEs at all).

As noted above, though, it would seem likely that the modules tree streamer
could be generalised to support some kind of FE hook that allowed each of the
FEs to stream their own specific trees ...  but none of this is a trivial
undertaking.

*** I'll put this on my TODO for aarch64-darwin.

[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above

[deller at gmx dot de via Gcc-bugs]

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

--- Comment #30 from deller at gmx dot de ---
Created attachment 51405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51405&action=edit
Linux kernel patch to add compiler optimization barrier

Linux kernel boots sucessfully with this patch on hppa.

[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above

[deller at gmx dot de via Gcc-bugs]

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

--- Comment #31 from deller at gmx dot de ---
Richard suggested that adding a compiler optimization barrier (__asm__ ("" :
"+r" (__pptr))) might fix the problem.
I tested the attached patch and it works nicely.

[Bug c++/102177] New: Implement C++17 P0418R2

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

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

Bug ID: 102177
   Summary: Implement C++17 P0418R2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I think we aren't implementing https://wg21.link/p0418r2
which dropped the requirement that failure mode can't be stronger than success
mode.
For
long
bar (long *x, long y, long z)
{
  __atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
__ATOMIC_SEQ_CST);
  return y;
}
we warn:
warning: failure memory model cannot be stronger than success memory model for
‘__atomic_compare_exchange’ [-Winvalid-memory-model]
and document it in doc/extend.texi:
Otherwise, @code{false} is returned and memory is affected according
to @var{failure_memorder}. This memory order cannot be
@code{__ATOMIC_RELEASE} nor @code{__ATOMIC_ACQ_REL}.  It also cannot be a
stronger order than that specified by @var{success_memorder}.
and libstdc++ has:
__glibcxx_assert(__b2 <= __b1);
in various spots in bits/atomic_base.h.

Do we emit right code on aarch64 and other weak ordering targets for this case
despite the warning?

[Bug c++/102177] Implement C++17 P0418R2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-02
 Ever confirmed|0   |1
 CC||amacleod at redhat dot com,
   ||redi at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug target/61359] GCC Bootstrap comparison failures on hppa2.0w-hp-hpux11.23

[me at larbob dot org via Gcc-bugs]

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

--- Comment #7 from Larkin Nickle  ---
For anyone finding this in the future, I'm guessing 32-bit builds of GCC on
HP-UX+PA-RISC were just broken for a while. Building 5.5.0 with libquadmath
enabled worked fine.

[Bug c++/102177] Implement C++17 P0418R2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
E.g. aarch64 has comment like:
  /* Normally the succ memory model must be stronger than fail, but in the
 unlikely event of fail being ACQUIRE and succ being RELEASE we need to
 promote succ to ACQ_REL so that we don't lose the acquire semantics.  */
which makes me think that maybe it needs some work when the stronger
requirement isn't honored.

What about powerpc?

[Bug c++/102177] Implement C++17 P0418R2

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

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

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

Untested patch to remove the warning and just use maximum for success if weaker
than failure instead of always seq_cst.

On the other side, even current C2X draft has that:
The failure argument shall be no stronger than the success argument.
requirement.  So should we keep the restriction for __atomic_* APIs and just
pass maximum from libstdc++ headers?

[Bug testsuite/37182] [4.4 Regression] Revision 139286 caused gcc.dg/pr17506.c and gcc.dg/uninit-15.c

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:9695e1c23be5b5c55d572ced152897313ddb96ae

commit r12-3315-g9695e1c23be5b5c55d572ced152897313ddb96ae
Author: Martin Sebor 
Date:   Thu Sep 2 09:20:09 2021 -0600

Improve -Wuninitialized note location.

Related:
PR tree-optimization/17506 - warning about uninitialized variable points to
wrong location
PR testsuite/37182 - Revision 139286 caused gcc.dg/pr17506.c and
gcc.dg/uninit-15.c

gcc/ChangeLog:

PR tree-optimization/17506
PR testsuite/37182
* tree-ssa-uninit.c (warn_uninit): Remove conditional guarding
note.

gcc/testsuite/ChangeLog:

PR tree-optimization/17506
PR testsuite/37182
* gcc.dg/diagnostic-tree-expr-ranges-2.c: Add expected output.
* gcc.dg/uninit-15-O0.c: Remove xfail.
* gcc.dg/uninit-15.c: Same.

[Bug tree-optimization/17506] [4.0/4.1 Regression] warning about uninitialized variable points to wrong location

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

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

--- Comment #37 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:9695e1c23be5b5c55d572ced152897313ddb96ae

commit r12-3315-g9695e1c23be5b5c55d572ced152897313ddb96ae
Author: Martin Sebor 
Date:   Thu Sep 2 09:20:09 2021 -0600

Improve -Wuninitialized note location.

Related:
PR tree-optimization/17506 - warning about uninitialized variable points to
wrong location
PR testsuite/37182 - Revision 139286 caused gcc.dg/pr17506.c and
gcc.dg/uninit-15.c

gcc/ChangeLog:

PR tree-optimization/17506
PR testsuite/37182
* tree-ssa-uninit.c (warn_uninit): Remove conditional guarding
note.

gcc/testsuite/ChangeLog:

PR tree-optimization/17506
PR testsuite/37182
* gcc.dg/diagnostic-tree-expr-ranges-2.c: Add expected output.
* gcc.dg/uninit-15-O0.c: Remove xfail.
* gcc.dg/uninit-15.c: Same.

[Bug tree-optimization/95187] Failure to optimize bool check into consecutive literals

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gabriel Ravier  ---
Seems to be fixed since GCC 11

[Bug tree-optimization/102178] New: SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

Bug ID: 102178
   Summary: SPECFP 2006 470.lbm regressions on AMD Zen CPUs after
r12-897-gde56f95afaaa22
   Product: gcc
   Version: 11.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-linix
Target: x86_64-linux

LNT has detected an 18% regression of SPECFP 2006 benchmark 470.lbm
when it is compiled with -Ofast -march=native on a Zen2 machine:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=421.240.0&plot.1=301.240.0&;

...and similarly a 6% regression when it is run on the same machine
with -Ofast:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=450.240.0&plot.1=24.240.0&;

I have bisected both on another zen2 machine to commit
r12-897-gde56f95afaaa22 (Run pass_sink_code once more before
store_merging).

Zen1 machine has also seen a similar -march=native regression in the
same time frame:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=450.240.0&plot.1=24.240.0&;

Zen1 -march=generic seems to be unaffected, which is also the case for
the Intel machines we track.

Although lbm has been known to have weird regressions caused entirely
by code layout where the compiler was not really at fault, the fact
that both generic code-gen and Zen1 are affected seems to indicate this
is not the case.


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 tree-optimization/96615] Failure to optimize out loop that eventually ends but has no side effects involving decrease of loop counter using an unsigned operation and the loop being done through r

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gabriel Ravier  ---
It seems to be optimized into nothing as of right now

[Bug target/96127] ICE in extract_insn, at recog.c:2294

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

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

--- Comment #3 from Jonathan Wakely  ---
Andreas, do you need to backport this, or should it be closed as fixed for
11.0?

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

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

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

--- Comment #13 from Jonathan Wakely  ---
Is this also the cause of several libstdc++ FAILs on ppc64le?

/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:2936:
error: unrecognizable insn:
(insn 11 10 12 2 (set (reg:SF 118 [  ])
(subreg:SF (reg:DI 122) 0))
"/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h":2936:16
-1
 (nil))
during RTL pass: vregs
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:2936:
internal compiler error: in extract_insn, at recog.c:2769
0x10221bb7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/jwakely/src/gcc/gcc/rtl-error.c:108
0x10221c0f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/jwakely/src/gcc/gcc/rtl-error.c:116
0x10de48af extract_insn(rtx_insn*)
/home/jwakely/src/gcc/gcc/recog.c:2769
0x10a3c82f instantiate_virtual_regs_in_insn
/home/jwakely/src/gcc/gcc/function.c:1611
0x10a3c82f instantiate_virtual_regs
/home/jwakely/src/gcc/gcc/function.c:1985
0x10a3c82f execute
/home/jwakely/src/gcc/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

[Bug target/87198] ICE in extract_insn, at recog.c:2304

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug pch/71934] pch cannot be disabled so gcc cannot be position independent

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
So, what is exactly the reason why we disallow PCH for PIEs?
Is it that we support in GC managed memory pointers into .rodata/.data/.text
sections of the compiler (function pointers, data pointers, vtable pointers)?
If yes, are those at least marked as pointers in the GTY stuff?
Perhaps the compiler when writing PCH could just record the extents of those
sections (or say PT_LOAD segments, on Linux e.g. using dl_iterate_phdr) if it
detects the binary is position independent, and when loading the PCH also
detect those extents and for GC pointers that fall into those extents adjust
them for the new locations?

[Bug c++/102177] Implement C++17 P0418R2

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-3317-gdba1ab212292839572fda60df00965e094a11252
Author: Jonathan Wakely 
Date:   Thu Sep 2 15:29:22 2021 +0100

libstdc++: Remove "no stronger" assertion in compare exchange [PR102177]

P0418R2 removed some preconditions from std::atomic::compare_exchange_*
but we still enforce them via __glibcxx_assert. This removes those
assertions.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR c++/102177
* include/bits/atomic_base.h (__is_valid_cmpexch_failure_order):
New function to check if a memory order is valid for the failure
case of compare exchange operations.
(__atomic_base::compare_exchange_weak): Simplify assertions
by using __is_valid_cmpexch_failure_order.
(__atomic_base::compare_exchange_strong): Likewise.
(__atomic_base::compare_exchange_weak): Likewise.
(__atomic_base::compare_exchange_strong): Likewise.
(__atomic_impl::compare_exchange_weak): Add assertion.
(__atomic_impl::compare_exchange_strong): Likewise.
* include/std/atomic (atomic::compare_exchange_weak): Likewise.
(atomic::compare_exchange_strong): Likewise.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

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

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

--- Comment #14 from Segher Boessenkool  ---
(In reply to Jonathan Wakely from comment #13)
> Is this also the cause of several libstdc++ FAILs on ppc64le?


Yes.

I have asked for reversion of g:d2874d905647:

[Bug fortran/93834] [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Patch withdrawn after review.

[Bug target/101849] MMA built-in dies with a verify_gimple failed error

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:585667735e9fb7a38357a84d4d25206a8ccec576

commit r11-8951-g585667735e9fb7a38357a84d4d25206a8ccec576
Author: Peter Bergner 
Date:   Thu Aug 19 17:33:29 2021 -0500

rs6000: Fix ICE expanding lxvp and stxvp gimple built-ins [PR101849]

PR101849 shows we ICE on a test case when we pass a non __vector_pair *
pointer to the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins
that is cast to __vector_pair *.  The problem is that when we expand
the built-in, the cast has already been removed from gimple and we are
only given the base pointer.  The solution used here (which fixes the ICE)
is to catch this case and convert the pointer to a __vector_pair * pointer
when expanding the built-in.

2021-08-19  Peter Bergner  

gcc/
PR target/101849
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin):
Cast
pointer to __vector_pair *.

gcc/testsuite/
PR target/101849
* gcc.target/powerpc/pr101849.c: New test.

(cherry picked from commit b0963c4379becafaebd8e52b0b42698ff151c293)