[Bug tree-optimization/97009] [9 Regression] Inlining with non-standard selected_int_kind leads to errors

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dimitri.gorokhovik at free dot 
fr

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

[Bug ipa/94485] Inter-dependency between { tree-sra, ABI, inlining, loop-unrolling } leads to mis-optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Pinski  ---
Dup.

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

[Bug ipa/94485] Inter-dependency between { tree-sra, ABI, inlining, loop-unrolling } leads to mis-optimization

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

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

--- Comment #11 from Andrew Pinski  ---
SRA in 10.2.0:
```
Created a replacement for D.14474 offset: 0, size: 64: SR.70D.14479
Created a replacement for D.14475 offset: 0, size: 64: SR.71D.14480
Removing load: D.13665 = D.14475;
```

in 10.3.0:
```
Created a replacement for D.14507 offset: 0, size: 64: SR.70D.14512
Created a replacement for D.14508 offset: 0, size: 64: SR.71D.14513
```

Notice how there is not a "removing load" in 10.3.0.

[Bug ipa/94485] Inter-dependency between { tree-sra, ABI, inlining, loop-unrolling } leads to mis-optimization

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

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

--- Comment #10 from Sam James  ---
ok, on godbolt, 8.5 fails. I think we're fine here then?

[Bug ipa/94485] Inter-dependency between { tree-sra, ABI, inlining, loop-unrolling } leads to mis-optimization

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #9 from Sam James  ---
Not sure if I'm doing something wrong or if it just got fixed in the 10 dev
cycle, but https://godbolt.org/z/x48xK9j67 is fine and so were the other
compilers I tried (9+).

[Bug target/100754] Order of multiple inheritance can lead to illegal code jump

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

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

--- Comment #5 from Andrew Pinski  ---
The bug/issue is most likely inside microblaze_asm_output_mi_thunk .

[Bug ipa/80728] IPA-reference suppresses compiler memory barrier

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

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

--- Comment #9 from Andrew Pinski  ---
I am not 100% sure we should not transform this code. The way signals are
defined that only volatile/atomic variables can be done via signals.

This works:
```

static _Atomic int i;
static _Atomic int b;

void sighandler(void)
{
 __atomic_store_n (, 1, __ATOMIC_RELAXED);
  __atomic_store_n (, 1, __ATOMIC_RELAXED);
}

__attribute__((noinline))
static int x(void)
{
  asm volatile("":::"memory");
  return __atomic_load_n(, __ATOMIC_RELAXED);
}

int f(void)
{
  __atomic_store_n (, 0, __ATOMIC_RELAXED);
  return x() ? __atomic_load_n(, __ATOMIC_RELAXED) : 0;
}

```

So does marking b/i as volatile.

Marking the variable i with the attribute used also works. as that says the
variable is used outside of what the compiler knows and in this case x only has
an inline-asm which clobbers memory.

[Bug c/114493] [11/12/13/14 Regression] internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||35980

--- Comment #5 from Andrew Pinski  ---
Ah yes PR 35980 which describes the exact issue ...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35980
[Bug 35980] The canonical type of types with may_alias attribute is incorrect

[Bug c/35980] The canonical type of types with may_alias attribute is incorrect

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> But starting in GCC 7, we no longer do.

that changed in r7-1272-g5545a9071573a5 .

[Bug c/114493] [11/12/13/14 Regression] internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257

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

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

--- Comment #4 from Andrew Pinski  ---
Also related is commit r7-1272-g5545a9071573a5 .

[Bug c/114493] [11/12/13/14 Regression] internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.1.0
  Known to fail||9.1.0
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code, lto
 Ever confirmed|0   |1
Summary|internal compiler error: in |[11/12/13/14 Regression]
   |fld_incomplete_type_of, at  |internal compiler error: in
   |ipa-free-lang-data.cc:257   |fld_incomplete_type_of, at
   ||ipa-free-lang-data.cc:257
  Component|ipa |c
   Target Milestone|--- |11.5
   Last reconfirmed||2024-03-27

--- Comment #3 from Andrew Pinski  ---
Works with the C++ front-end ...

[Bug c++/80320] Constructor executed twice for the same static member when using -fno-implicit-templates

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

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

--- Comment #2 from Andrew Pinski  ---
For not emitting the guard:
#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)  \
|| DECL_ONE_ONLY (decl) \
|| DECL_WEAK (decl)))


Since the decl is extern, so none of those are true.

But I think it should get that far for this variable.
I have not looked fully in the front-end to understand this code further.

[Bug ipa/114493] internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257

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

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

--- Comment #2 from Sam James  ---
Pfff.

```
typedef struct git_midx_writer git_midx_writer;
int git_futils_rmdir_flags;
int __attribute__git_midx_writer_new(git_midx_writer **);
struct __attribute__((__may_alias__)) git_midx_writer {};
```

[Bug ipa/114493] internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I have seen TYPE_CANONICAL issues with may_alias before.

[Bug ipa/114493] New: internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257

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

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

Bug ID: 114493
   Summary: internal compiler error: in fld_incomplete_type_of, at
ipa-free-lang-data.cc:257
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57819=edit
odb_pack.c.i.xz

11/12/13/14 all fail. 10 fails b/c of malloc attribute so needs to be checked.

I hit this after adding may_alias to a struct.

```
$ gcc src/libgit2/CMakeFiles/libgit2.dir/odb_pack.c.i -std=c90 -c -flto
during IPA pass: *free_lang_data
/home/sam/git/libgit2/src/libgit2/odb_pack.c:986:1: internal compiler error: in
fld_incomplete_type_of, at ipa-free-lang-data.cc:257
  986 | }
  | ^
0x55e8b946cd88 fld_incomplete_type_of
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:257
0x55e8baa704cd fld_simplified_type
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:344
0x55e8baa704cd free_lang_data_in_type
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:439
0x55e8bb0d2280 free_lang_data_in_cgraph
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:1072
0x55e8bb0d2280 free_lang_data
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:1109
0x55e8bb0d2280 execute
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/ipa-free-lang-data.cc:1176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
``

[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl or if ifunc support is disabled (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

[raj.khem at gmail dot com via Gcc-bugs]

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

Khem Raj  changed:

   What|Removed |Added

 CC||raj.khem at gmail dot com

--- Comment #5 from Khem Raj  ---
(In reply to Wilco from comment #4)
> Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646408.html

FWIW, v2 of this patch worked fine on Yocto/qemuarm64/musl build. Run tests
have not been completed yet but it looks promising.

[Bug target/114492] Invalid use of gcc_assert (notably in gcc/config/aarch64/aarch64-ldp-fusion.cc)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
PR 29862 listed at least one in the past.

[Bug target/114492] Invalid use of gcc_assert (notably in gcc/config/aarch64/aarch64-ldp-fusion.cc)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>Please be advised that the argument is *not* evaluated with release checking

Actually it is evaluated with release checking as release checking enables
assert checking.
But it is not evaluated for `--without-checking` or `--with-checking=none`.

It has been done that way since release checking was added in
r0-61420-ge1bbfc5cc2dd04 .

Before that yes assert checking was NOT enabled for releases.



The 2 I see which might be an issue is:
  gcc_assert (crtl->ssa->verify_insn_changes (changes));

gcc_assert (rtl_ssa::restrict_movement_ignoring (*changes[i],
is_changing));

[Bug target/69041] Unnecessary push/pop of caller-save register (ecx) on 32bit with vector intrinsics.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|Unnecessary push/pop of |Unnecessary push/pop of
   |caller-save register (ecx)  |caller-save register (ecx)
   |on 32bit with vector|on 32bit with vector
   |intrinsics.  Sometimes  |intrinsics.
   |without the pop, clobbering |
   |ebp (callee-save)   |
   Keywords|wrong-code  |

--- Comment #2 from Andrew Pinski  ---
>clobbers the caller's ebp with the pushed value of ecx, but the esp=ebp part 
>of leave cleans up after the mismatched push/pop

This is wrong. Leave does the pop.
Basically leave is `sp = ebp + 4; ebp = [ebp];`

So no wrong code. Just missed optimizations.

The removal of the stack frame happened in GCC 6 for dummy/dummy2.


The removal of vzeroupper for dummy/dummy2 happened in GCC 9.

Looks like there is still a frame pointer creation happening for add_pixdiff; I
have not looked into why though

[Bug target/114492] New: Invalid use of gcc_assert (notably in gcc/config/aarch64/aarch64-ldp-fusion.cc)

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

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

Bug ID: 114492
   Summary: Invalid use of gcc_assert (notably in
gcc/config/aarch64/aarch64-ldp-fusion.cc)
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: acoplan at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

I've noticed invalid uses of gcc_assert in
gcc/config/aarch64/aarch64-ldp-fusion.cc.  Please be advised that the argument
is *not* evaluated with release checking; I believe most uses can be cured by
breaking out the call; i.e. replacing an invalid call:

gcc_assert (function_that_needs_to_be_called_but_most_certainly_returns_true())

with:

bool x = function_that_needs_to_be_called_but_most_certainly_returns_true ();
gcc_assert (x).

(Probably not the only file, just the one I've been looking at, for reasons,
and I thought better enter a bug report, just not going to fix it myself.)

Incidentally, I think "we" ought to add something to gcc that automatically
checks and warns for such invalid use.  There may be a need to implement a
builtin to check that an expression X does not have side-effects, for use both
within gcc in gcc_assert and user-visible, for implementations of assert; say
__builtin_pure_p (X).  (The name is ripe to bike-shedding, just choosing a mix
of __builtin_constant_p and the "pure" attribute.)

[Bug c++/58525] __cxa_throw_bad_array_new_length is generated with -fno-exceptions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/86347] [C++17] Incorrect call order of allocation function in new expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #5 from Andrew Pinski  ---
Looks to be fixed in GCC 12+.

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bki at hacon dot de

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

[Bug target/85961] scratch register rsi used after function call

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Dup of bug 92860.

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

[Bug target/85961] scratch register rsi used after function call

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||12.1.0

--- Comment #7 from Andrew Pinski  ---
The `#pragma GCC optimize "O2"` issue seems fixed in GCC 12.1.0+.

[Bug c++/12944] [meta-bug] C++ name-lookup problems

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

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

Bug 114491 Summary: incorrect identifier namespacing with variadic templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114491

   What|Removed |Added

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

[Bug c++/114491] incorrect identifier namespacing with variadic templates

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Oh but it is a duplicate.

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

[Bug c++/90189] Spurious "error: parameter packs not expanded" when a dependent name coincides

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||christoph.schied at gmail dot 
com

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

[Bug c++/114491] incorrect identifier namespacing with variadic templates

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

Interesting:
```
template
void works_also()
{
typename A::T var; /* A::T and T seem to clash */
}
```

Works also.

[Bug rtl-optimization/107051] redundant loads when copying a union

[absoler at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #2 from absoler at smail dot nju.edu.cn ---
(In reply to Richard Biener from comment #1)
> With -O2 I see
> 
> func_1:
> .LFB0:
> .cfi_startproc
> movle(%rip), %eax
> testl   %eax, %eax
> je  .L2
> .L3:
> jmp .L3
> .p2align 4,,10
> .p2align 3
> .L2:
> movqg_284+8(%rip), %rax
> movq%rax, g_284(%rip)
> ret
> 
> note that with -O1 we retain
> 
>   c = g_284[1];
>   c$f0_3 = g_284[1].f0;
>   c.f0 = c$f0_3;
>   g_284[0] = c;
> 
> after GIMPLE optimization which possibly explains this compared to
> 
>   c = g_284[1];
>   g_284[0] = c;
> 
> with -O2.

for gcc-13.2.0 -O2, it seems still forget to remove the load for this reduced
case:
```
union U0 {
short f1;
int f2;
};
union U0 g1, g2;

volatile int flag;
void func_1() {
union U0 d[1] = {{.f1 = 1}};
for (; flag;)
;
d[0] = g2;
g1 = d[0];
}
```
```
func_1:
.LFB0:
.cfi_startproc
.p2align 4,,10
.p2align 3
.L2:
movlflag(%rip), %eax
testl   %eax, %eax
jne .L2
movlg2(%rip), %eax
movwg2(%rip), %ax
movl%eax, g1(%rip)
ret
.cfi_endproc
```

[Bug c++/83908] -fvisibility=hidden not setting the visibility of the resolver/ifunc created for attribute target

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
   Last reconfirmed||2024-03-27

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

[Bug c++/114491] New: incorrect identifier namespacing with variadic templates

[christoph.schied at gmail dot com via Gcc-bugs]

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

Bug ID: 114491
   Summary: incorrect identifier namespacing with variadic
templates
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.schied at gmail dot com
  Target Milestone: ---

Created attachment 57818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57818=edit
same source code as posted in the description

The following code fails to compile with g++, however it works with clang. I
tried various versions of gcc in godbolt (https://godbolt.org/z/xqfoc4Yce)
using std=c++17 and std=c++20 and the code fails to compile on all versions. It
appears that the dependent type T gets confused with the template argument of
the function.

template
void works()
{
typename A::T var;
}

template
void broken()
{
typename A::T var; /* A::T and T seem to clash */
}


results in:
: In function 'void broken()':
:10:19: error: parameter packs not expanded with '...':
   10 | typename A::T var; /* A::T and T seem to clash */
  |   ^~~
:10:19: note: 'T'

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

https://gcc.gnu.org/g:41e767c482fc903ca5d54014b034c7526dbf8f1c

commit r14-9681-g41e767c482fc903ca5d54014b034c7526dbf8f1c
Author: Jerry DeLisle 
Date:   Tue Mar 26 16:44:17 2024 -0700

libgfortran: Fix file position after ENDFILE statement.

PR libfortran/107031

libgfortran/ChangeLog:

* io/file_pos.c (st_endfile): Remove call to next_record().

gcc/testsuite/ChangeLog:

* gfortran.dg/endfile_5.f90: New test.

[Bug target/78253] [5/6/7 Regression] [ARM] call weak function instead of strong when called through pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

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

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Andrew Pinski  ---
Dup of bug 78253 in the end. It was fixed in GCC 6.4.0 and GCC 5.5.0.

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

[Bug c++/101140] [modules] no matching function for call to ‘operator new(sizetype, void*)’

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

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

--- Comment #5 from Nathaniel Shead  ---
(In reply to Patrick Palka from comment #4)
> FWIW I was thinking we might want to perform two-phase name lookup for
> new-expressions like we do for other operator expressions, wherein
> unqualified lookup is performed at template definition time, saved inside
> the expression (via DEPENDENT_OPERATOR_TYPE) and then reused at
> instantiation time.

I actually wonder if this is even correct. [basic.argdep.lookup] p4 says:

> If the lookup is for a dependent name ([temp.dep], [temp.dep.candidate]), the
> above lookup is also performed from each point in the instantiation context
> ([module.context]) of the lookup, additionally ignoring any declaration that
> appears in another translation unit, is attached to the global module, and is
> either discarded ([module.global.frag]) or has internal linkage.

And the instantiation context is defined to include ([module.context] p3):

> ...if the template is defined in a module interface unit of a module M and
> the point of instantiation is not in a module interface unit of M, the point
> at the end of the declaration-seq of the primary module interface unit of M
> (prior to the private-module-fragment, if any).

Which implies to me that the following sample should work:

  export module M;

  export template 
  void f(T t) { g(t); }

  namespace ns {
export struct X {};
void g(X);
  }

//

  import M;
  int main() {
f(ns::X{});  // should compile?
  }

but we currently error. Whether this is a sensible thing to support is another
question...

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

[Explorer09 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Kang-Che Sung  ---
(In reply to Andrew Pinski from comment #2)
> 
> Basically if you are shifting by 0, then the CF bit never changes from the
> previous and this can't be done.
> 
> So the comment in the backend is correct and there is no way to remove the
> test (unless you know ch can't be 0).

What if I had the CF cleared to 0 already before the shift?

Even when the flags don't change when the value in the CL register is zero, if
I had the flags in a known state, the optimization can still be done.

And my suggested 'my_isxdigit_2' code worked before I know the caveat of the
shift instructions... ("xorl  %eax, %eax" -> CF = SF = 0)

[Bug target/53192] Incorrect arguments to AVX2's gather intrinsics

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #5)
> BTW, to avoid that warning, you could use in C:
> extern __inline __m128i
> __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> _mm_i32gather_epi64 (
> #ifdef __cplusplus
>  long long int const *base,
> #else
>  union __attribute__((__transparent_union__)) { long
> long int const *__ll; long int const *__l; } base,
> #endif
>  __m128i index, const int scale)
> and for C++ add another overload (of course, for _LP64 only).

The other option is to change how intrinsics work on x86 and use resolve
overloads inside the backend like how aarch64, arm and rs6000 backends all
handle intrinsics these days.

That would be a huge rewrite of the intrinsics but it might resolve some of the
other issues dealing the builtins and such too.

[Bug rtl-optimization/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #18 from Andrew Pinski  ---
Fixed long ago.

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Read `7.3.6.1 Shift Instructions` from the `Intel® 64 and IA-32 Architectures
Software Developer’s Manual` volume 1.

Basically if you are shifting by 0, then the CF bit never changes from the
previous and this can't be done.

"The CF flag is loaded with the last bit shifted out of the
operand."
There was no bit shifted if doing a shift by 0.

So the comment in the backend is correct and there is no way to remove the test
(unless you know ch can't be 0).

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm, the backend has:
;; This pattern can't accept a variable shift count, since shifts by
;; zero don't affect the flags.  We assume that shifts by constant
;; zero are optimized away.

[Bug target/53192] Incorrect arguments to AVX2's gather intrinsics

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|wrong-code  |diagnostic, rejects-valid
 Target|x86-64  |x86-64 (LP64)
 Status|WAITING |NEW

--- Comment #6 from Andrew Pinski  ---
Confirmed.
Here is a testcase which compiles just fine at -O0 but fails at -O1 and above:
```
#include 

__m128i f(long *base, __m128i vindx, int scale)
{
return _mm_i32gather_epi64 (base, vindx, 1);
}
__m128i g(long long *base, __m128i vindx, int scale)
{
return _mm_i32gather_epi64 (base, vindx, 1);
}
```

Note clang's version is to always use a macro here.
ICC directly defines these internally as real intrinsics and accepts the above
without an error.

[Bug target/114490] New: Optimization: x86 "shl" condition codes never reused

[Explorer09 at gmail dot com via Gcc-bugs]

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

Bug ID: 114490
   Summary: Optimization: x86 "shl" condition codes never reused
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Explorer09 at gmail dot com
  Target Milestone: ---

This seems to happen with x86 target only.

For the example code below, I can use the SF (sign flag) after a left shift
(<<) operation, but somehow I cannot make GCC reuse the condition code of a
"shl" instruction. It always generates an unnecessary "testl %edx, %edx" before
the conditional jump.

This is one case where the condition code of a bit shift can be useful. I know
in the ARM target of GCC, the condition code is reused after the shift.

```c
#include 
#include 

bool my_isxdigit(unsigned char ch) {
  uint32_t mask1 = 0x7E00FFC0;
  // Prevent the compiler from transforming the constants.
  // Suppose we have to use them as written.
  __asm__ ("" : "+r" (mask1));

  if (!((mask1 << (ch & 0x1F)) >> 31))
return false;

  uint32_t mask2 = 0x1A << 24;
  __asm__ ("" : "+r" (mask2));

  if (!((mask2 << (ch >> 4)) >> 31))
return false;

  return true;
}
```

x86-64 gcc with "-O3" option
(Actually I tested in Compiler Explorer (godbolt.org))

```x86asm
my_isxdigit:
  movl   %edi, %ecx
  movl   $2113994688, %eax
  sall   %cl, %eax
  movl   %eax, %edx
  xorl   %eax, %eax
  testl  %edx, %edx
  jns.L1
  shrb   $4, %cl
  movl   $436207616, %eax
  sall   %cl, %eax
  shrl   $31, %eax
.L1:
  ret
```

Possible shorter code:

```x86asm
my_isxdigit_2:
  movl   %edi, %ecx
  xorl   %eax, %eax
  movl   $2113994688, %edx
  sall   %cl, %edx
  jns.L2
  shrb   $4, %cl
  movl   $436207616, %eax
  sall   %cl, %eax
  shrl   $31, %eax
.L2:
  ret
```

[Bug lto/110710] LTO linker on Windows creates an invalid Makefile

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #13 from peter0x44 at disroot dot org ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648427.html

Patch submitted. Couldn't figure out how to assign myself in bugzilla.

[Bug ipa/68331] [meta-bug] fipa-pta issues

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

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

Bug 50577 Summary: IPA-PTA context insensitivity confuses pure-const analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50577

   What|Removed |Added

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

[Bug tree-optimization/50577] IPA-PTA context insensitivity confuses pure-const analysis

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
r6-5670-gee7d29b43faf15 looks to have fixed this. It removed the FIXME/early
out.

[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #4)
> Oh btw, the #c3 problem isn't new at all, it happens with 4.8 already for
> example.

Yes it was originally reported as PR 46164 against GCC 4.5.1 even.

[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||siarhei.siamashka at gmail dot 
com

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

[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Turns out this is a dup of bug 87600. See bug 87600 comment #3 which is exactly
the same testcase as in comment #0 here (except for aarch64).

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

[Bug c++/114488] internal compiler error: unexpected expression static_cast ...

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> On the gcc-9 branch the first bad commit is r9-8623-g0296697cf9893d

Which was the backport of r11-122.

And as expected, the ICE began on gcc-10 with the gcc-10 backport of r11-122,
which was r10-8183-gaa613a81831bdc

It was fixed for gcc-10 by r10-9207-gd0684e49ee8d85 which is the backport for
PR 97975, as Andrew said in comment 1.

[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 57817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57817=edit
Draft patch

This adds a fixup of the expression type of the actual argument of the
DT constructor which is often set to BT_PROCEDURE in match_actual_arg.

[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #3 from Mikael Morin  ---
(In reply to anlauf from comment #2)
> (In reply to Jürgen Reuter from comment #1)
> > I suspect this commit here,
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=44c0398e65347def316700911a51ca8b4ec0a411
> > but not totally certain.
> 
> The following patch fixes the apparent regression:
> 
> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
> index 9a042cd7040..68d16a9a378 100644
> --- a/gcc/fortran/expr.cc
> +++ b/gcc/fortran/expr.cc
> @@ -3517,6 +3563,7 @@ check_restricted (gfc_expr *e)
>if (e->error
>   || sym->attr.in_common
>   || sym->attr.use_assoc
> + || sym->attr.used_in_submodule
>   || sym->attr.dummy
>   || sym->attr.implied_index
>   || sym->attr.flavor == FL_PARAMETER
> 
Yes, I was coming to the same fix.
I'm not too sure about it though.

> 
> Looks like the commit actually uncovered a latent issue.
> 
> Mikael, do you want to follow up?

Yes, this is mine in any case.

[Bug c++/114488] internal compiler error: unexpected expression static_cast ...

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

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

--- Comment #4 from Jonathan Wakely  ---
On the gcc-9 branch the first bad commit is r9-8623-g0296697cf9893d

commit 0296697cf9893dc9509cdcd8e3fd4ba9fe422527
Author: Jason Merrill
Date:   Mon May 25 18:38:09 2020 -0400

c++: constexpr and lambda capture [PR90212]

This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression.  As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to
the
captured variable.

PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.

[Bug gcov-profile/113765] [14 Regression] ICE: autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #7 from Eugene Rozenfeld  ---
I'll prepare a patch this week.

[Bug libstdc++/114387] Explicitly declared destructor makes basic_format_context sometimes not movable

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2024-03-26

--- Comment #1 from Jonathan Wakely  ---
https://cplusplus.github.io/LWG/issue4061

[Bug tree-optimization/114485] [13/14 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||12.3.0
   Target Milestone|--- |13.3
   Last reconfirmed||2024-03-26
 Blocks||53947
 Status|UNCONFIRMED |NEW
  Known to fail||13.1.0
Summary|[14] Wrong code with -O3|[13/14 Regression] Wrong
   |-march=rv64gcv on riscv |code with -O3
   ||-march=rv64gcv on riscv or
   ||`-O3 -march=armv9-a` for
   ||aarch64
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed. Yes it does look very similar if not the same.
This one does not even need -fno-vect-cost-model nor -fwrapv for aarch64 even.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug lto/110710] LTO linker on Windows creates an invalid Makefile

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #12 from peter0x44 at disroot dot org ---
diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
index 5186d040ce0..7119157d830 100644
--- a/gcc/lto-wrapper.cc
+++ b/gcc/lto-wrapper.cc
@@ -2024,9 +2024,7 @@ cont:
 truncate them as soon as we have processed it.  This
 reduces temporary disk-space usage.  */
  if (! save_temps)
-   fprintf (mstream, "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null "
-"2>&1 && mv \"%s.tem\" \"%s\"\n",
-input_name, input_name, input_name, input_name);
+   fprintf (mstream, "\t@-copy /y nul \"%s\"" input_name);
}
  else
{

This experimental patch works for me, it doesn't seem to matter if the
timestamp gets updated. I guess what's left to do is write code that runs "sh
-c "true"" to determine if there is an sh.exe present, and then emit the
correct fragment to truncate the file.

[Bug tree-optimization/114485] [14] Wrong code with -O3 -march=rv64gcv on riscv

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv*-*-*  |riscv*-*-* aarch64-*-*

--- Comment #1 from Andrew Pinski  ---
[apinski@xeond2 upstream-cross-aarch64]$ ./install/bin/aarch64-linux-gnu-gcc
-O3 t67.c -static
.[apinski@xeond2 upstream-cross-aarch64]$ ./install-qemu/bin/qemu-aarch64 a.out
8
[apinski@xeond2 upstream-cross-aarch64]$ ./install/bin/aarch64-linux-gnu-gcc
-O3 t67.c -static -march=armv9-a+sve2
[apinski@xeond2 upstream-cross-aarch64]$ ./install-qemu/bin/qemu-aarch64 a.out
4294967288

[Bug tree-optimization/114489] introduced redundant load facing different branches

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
>[local count: 375809640]:
>   _3 = g1;
>   goto ; [100.00%]
> 
>[local count: 697932184]:
>   g2.1_2 = g2;
>   arr[0] = g2.1_2;
>   _8 = g1;
> 
>[local count: 1073741824]:
>   # _6 = PHI <_8(4), _3(3)>
> 
> Which does not optimize unless using -O2.
> 
> This is on purpose.

In that PRE is not enabled at -O1 but it is at -O2.

[Bug tree-optimization/114489] introduced redundant load facing different branches

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
   [local count: 375809640]:
  _3 = g1;
  goto ; [100.00%]

   [local count: 697932184]:
  g2.1_2 = g2;
  arr[0] = g2.1_2;
  _8 = g1;

   [local count: 1073741824]:
  # _6 = PHI <_8(4), _3(3)>

Which does not optimize unless using -O2.

This is on purpose.

[Bug tree-optimization/114489] New: introduced redundant load facing different branches

[absoler at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 114489
   Summary: introduced redundant load facing different branches
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: absoler at smail dot nju.edu.cn
  Target Milestone: ---

similar with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107050, but without
function call.

```
int f = 1;
int g1, g2, arr[10];

int func_1() {
int a = 4;
int *p1 = 
if (f) {
arr[0] = g2;
int *p2 = 
a = 1;
}
*p1 &= (a > 9) - 5;
return a;
}

int main() {
func_1();
}
```
gcc-13.2.0 -O1 generates:
```
func_1():
  401106:   mov0x2f80(%rip),%eax# 40408c   # first load
  40110c:   mov$0x4,%edx
  40:   cmpl   $0x0,0x2f10(%rip)# 404028 
  401118:   je 401131 
  40111a:   mov0x2f68(%rip),%eax# 404088 
  401120:   mov%eax,0x2f3a(%rip)# 404060 
  401126:   mov0x2f60(%rip),%eax# 40408c   # second load
  40112c:   mov$0x1,%edx
  401131:   and$0xfffb,%eax
  401134:   mov%eax,0x2f52(%rip)# 40408c 
  40113a:   mov%edx,%eax
  40113c:   retq   
```

I wonder why compiler won't use another register to hold `g2`, so that the
second load is unnecessary.

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||vincenzo.innocente at cern dot 
ch

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

[Bug target/114484] #include changes ::abs in std::abs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #11 from Jonathan Wakely  ---
(In reply to vincenzo Innocente from comment #9)
> We observe that including xmmintrin.h the behaviour of some code,
> notably abs(x), when x is float or double changes.

Yeah, it *fixes* your code. Without  your abs(f) code calls
abs(int) which is wrong.

e.g. https://godbolt.org/z/sxv69hv5K

The arm code uses abs(int) which is wrong. The problem here is not that
xmmintrin.h includes another header, it's that your code is not including the
headers it requires. The fact that xmmintrin.h includes stdlib.h means you get
away with it on one platform, but not on another. That portability problem
isn't great, but it's not actually a bug in xmmintrin.h.


> And this depends on the platform as  xmmintrin.h is x86_64 specific.

Yes, but different headers having different transitive inclues on different
platforms is not actually a bug.

> Yes, is 20 years that is like that and people always wandered why abs(x) was
> behaving differently in different parts of the code and now asking why it
> behaves differently on x86_64 and ARM.

Righ, so *that's* the bug, not that xmmintrin.h includes another header, and
not that C++ code is "supposed to #include  not ".

There is nothing wrong with xmmintrin.h including other headers.

> The workaround is obvious: use std::abs.
> 
> I personally find very unconfortable that including (even through cascade)
> xmmintrin.h changes the behaviour of "abs(x)" 

When Bug 89855 is fixed, it won't change it.  will put all overloads of
abs in the global namespace.

This is a dup of Bug 89855

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

[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #1)
> I suspect this commit here,
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=44c0398e65347def316700911a51ca8b4ec0a411
> but not totally certain.

The following patch fixes the apparent regression:

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 9a042cd7040..68d16a9a378 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3517,6 +3563,7 @@ check_restricted (gfc_expr *e)
   if (e->error
|| sym->attr.in_common
|| sym->attr.use_assoc
+   || sym->attr.used_in_submodule
|| sym->attr.dummy
|| sym->attr.implied_index
|| sym->attr.flavor == FL_PARAMETER


Looks like the commit actually uncovered a latent issue.

Mikael, do you want to follow up?

[Bug target/114484] #include changes ::abs in std::abs

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
arm_neon.h includes stdint.h .
arm_acle.h includes stdint.h and stddef.h .
arm_sve.h includes stdint.h.
These all will define types and functions in the global namespace.

So basically including intrinsic header will always include in other headers
and will depend on the target since those target specific.


The whole "arm vs x86_64" behavior seems more like the code depending on target
specific headers in the first place so obvious they will be different. Sounds
more like people have the wrong expectations here.

Also note ICX, and clang have the same issue (maybe even worse with libc++ not
wrapping stdlib.h).

[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC|anlauf at gmx dot de   |anlauf at gcc dot 
gnu.org
   Last reconfirmed||2024-03-26

[Bug target/114484] #include changes ::abs in std::abs

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #9 from vincenzo Innocente  ---
We observe that including xmmintrin.h the behaviour of some code,
notably abs(x), when x is float or double changes.
And this depends on the platform as  xmmintrin.h is x86_64 specific.
Yes, is 20 years that is like that and people always wandered why abs(x) was
behaving differently in different parts of the code and now asking why it
behaves differently on x86_64 and ARM.
The workaround is obvious: use std::abs.

I personally find very unconfortable that including (even through cascade)
xmmintrin.h changes the behaviour of "abs(x)" 


If everybody on GCC side is confortable with this situation we will just take
note and try to be more strict with code visual inspection.

[Bug c++/114488] internal compiler error: unexpected expression static_cast ...

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

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

--- Comment #3 from Jonathan Wakely  ---
An ICE seems to have started on trunk with r11-122 and been fixed by r11-557

[Bug c++/114488] internal compiler error: unexpected expression static_cast ...

[ing.russomauro at gmail dot com via Gcc-bugs]

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

--- Comment #2 from mauro russo  ---
If something is removed from sample code (e.g., b made bool instead of a
shared_ptr, or some const is removed), the problem disappears.

[Bug c++/114488] internal compiler error: unexpected expression static_cast ...

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97975
   Keywords||ice-on-valid-code
 Resolution|--- |FIXED

--- Comment #1 from Andrew Pinski  ---
So this was fully fixed for GCC 10.3.0 and GCC 11+. See PR 97975 .

[Bug c++/97975] [8/9 Regression] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.2.0
  Known to work||10.3.0
   Target Milestone|8.5 |10.3

[Bug c++/104284] [9/10 Regression] ICE: unexpected expression '' of kind implicit_conv_expr since r9-6073-ge8b3c1bc3ba22dcf

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.3.0
  Known to fail||11.2.0
   Target Milestone|9.5 |11.3

[Bug c++/91465] [9 Regression] unexpected expression of kind overload (ICE)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|9.4 |10.0

[Bug c++/114488] New: internal compiler error: unexpected expression static_cast ...

[ing.russomauro at gmail dot com via Gcc-bugs]

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

Bug ID: 114488
   Summary: internal compiler error: unexpected expression
static_cast ...
   Product: gcc
   Version: 9.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ing.russomauro at gmail dot com
  Target Milestone: ---

The error is reproduced on godbolt online compiler with gcc 9.5.

It was initially experienced on a local machine.

/* BEGIN CODE */

#include 

int main(){
const auto b = std::make_shared(1);

[b](const auto& v) {
const auto u = static_cast(b ? 1 : 3);
}(2);
}

/* END CODE */

The compiler message reads:

internal compiler error: unexpected expression 'static_cast((b ? 1 :
3))' of kind static_cast_expr

Note that the same happens with the gcc versions 9.4 and 10.2, whereas 9.3,
10.1, 10.3, and 13.2 do not present the error (not applicable to version 9.2
for unsupported features). Not checked on intermediate versions between 10.3
and 13.2.
The error arises even adding options to the compiler on godbolt, as
"-std=c++14" or "-std=gnu++14" or "-std=c++17" or "-std=gnu++17" or
"-std=c++2a" or "-std=gnu++2a" (it seems C++14 is the default; nonetheless,
does not affect the resulting internal error).
The error is confirmed even with options either "-Wall -Wextra" or
"-fno-strict-aliasing -fwrapv".

Among the possible duplicates, 63415 has the most similar title but the kind of
source code appears different, I cannot guess whether the root cause was
overlapped or not, taking also into account that 63415 is for version 4.9.1 and
above I mentioned that version 9.2 is not capable to compile my posted code for
missing features.

[Bug target/114484] #include changes ::abs in std::abs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-03-26
 Status|UNCONFIRMED |WAITING

--- Comment #8 from Andrew Pinski  ---
Can you expand on what is going wrong with the way the include files are done
this way? Because it is not obvious what the issue you are running into.

Is it because you want to include the intrinsic header inside a header and then
it is bringing in some of the declarations to the toplevel namespace and it is
breaking the build depending on the target you are compiling on? Or something
else?

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/114484] #include changes ::abs in std::abs

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> For the specific case of , you know that includes  and
> always adds abs(int) to the global namespace, right?  It's actually a bug
> that  doesn't always add abs(long) and abs(long long) to the global
> namespace too,

*and* abs(float), abs(double), and abs(long double) too.

> see PR 89855.

Maybe that bug is the real issue you're reporting?

[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf

[cupertino.miranda at oracle dot com via Gcc-bugs]

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

Cupertino Miranda  changed:

   What|Removed |Added

 CC||cupertino.miranda at oracle 
dot co
   ||m

--- Comment #6 from Cupertino Miranda  ---
Based on the comparisson of clang and gcc output over the provided preprocessed
files, I believe that the patch pushed resolves the problem.

Have written to the original systemd github issue to mention the fix and
request for further verification.

[Bug target/114484] #include changes ::abs in std::abs

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

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

--- Comment #6 from Jonathan Wakely  ---
But  is not a standard C++ header, there's no guarantee it doesn't
include  (or any other header).

For the specific case of , you know that includes  and
always adds abs(int) to the global namespace, right?  It's actually a bug that
 doesn't always add abs(long) and abs(long long) to the global
namespace too, see PR 89855.

The standard says  might add the names to the global namespace, so you
seem to be asking for something that is not required by the standard, and very
difficult to implement (without replacing all libc headers).

[Bug target/114484] #include changes ::abs in std::abs

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

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

--- Comment #5 from Andrew Pinski  ---
Note this header has been this way for almost 20 years too ...

[Bug target/114484] #include changes ::abs in std::abs

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #4 from vincenzo Innocente  ---
in C++ one is supposed to #include
 not 

I do not think that there is an explicit version of C++ headers for the
intrinsics that avoids the conflicts between C and C++.

[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Cupertino Miranda :

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

commit r14-9677-gfa60ac549649655a3f55e69f83d2e97423d3eb5c
Author: Cupertino Miranda 
Date:   Tue Mar 26 11:59:47 2024 +

btf: Emit labels in DATASEC bts_offset entries.

GCC was defining bts_offset entry to always contain 0.
When comparing with clang, the same entry is instead a label to the
respective variable or function. The assembler emits relocations for
those labels.

gcc/ChangeLog:
PR target/114431
* btfout.cc (get_name_for_datasec_entry): Add function.
(btf_asm_datasec_entry): Print label when possible.

gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Correct for new
implementation.
* gcc.dg/debug/btf/btf-datasec-2.c: Likewise
* gcc.dg/debug/btf/btf-pr106773.c: Likewise

[Bug target/114487] New: [14 regression] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

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

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

Bug ID: 114487
   Summary: [14 regression] ICE when building libsdl2 on
-mfpmath=sse x86 with LTO
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

I'm not sure if this is really a target bug, or an LTO option merging bug. I
suspect the issue comes down to mismatch of -mfpmath=sse and -msse -msse2 - but
I may be wrong.

Here's a reduction but it might be a bad one, as there's conflicting return
types here.

```
$ cat SDL_test_fuzzer.i
void SDLTest_RandomUnitFloat() { }
```

```
$ cat testautomation-testautomation_pixels.i
void SDLTest_RunSuites();

void SDLTest_AssertPass();
float SDLTest_RandomUnitFloat();
typedef struct {
  int testCase;
} SDLTest_TestCaseReference;
typedef struct {
  char *name;
  void *testSetUp;
  SDLTest_TestCaseReference *testCases;
  void *testTearDown;
} SDLTest_TestSuiteReference;
void pixels_calcGammaRamp() {
  float gamma = SDLTest_RandomUnitFloat();
  SDLTest_AssertPass(gamma);
}
SDLTest_TestCaseReference pixelsTests[] = {(int)pixels_calcGammaRamp};
SDLTest_TestSuiteReference pixelsTestSuite = {0, pixelsTests};

int main() {
  SDLTest_TestSuiteReference *testSuites = 
  SDLTest_RunSuites(testSuites);
}
```

```
$ gcc -O3 -pipe -march=i686 -mfpmath=sse -flto -mmmx -msse -msse2
-fno-strict-aliasing SDL_test_fuzzer.i -fPIC -o SDL_test_fuzzer.o -c
$ gcc -O3 -march=i686 -flto -o a testautomation-testautomation_pixels.i
SDL_test_fuzzer.o
testautomation-testautomation_pixels.i: In function ‘pixels_calcGammaRamp’:
testautomation-testautomation_pixels.i:17:1: error: unrecognizable insn:
   17 | }
  | ^
(insn 6 5 7 2 (set (reg/v:SF 100 [ gamma ])
(reg:SF 20 xmm0)) "testautomation-testautomation_pixels.i":15:17 -1
 (nil))
during RTL pass: vregs
testautomation-testautomation_pixels.i:17:1: internal compiler error: in
extract_insn, at recog.cc:2812
0x5722510f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/rtl-error.cc:108
0x57225146 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/rtl-error.cc:116
0x56d46375 extract_insn(rtx_insn*)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/recog.cc:2812
0x56d46375 instantiate_virtual_regs_in_insn
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/function.cc:1611
0x56d46375 instantiate_virtual_regs
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/function.cc:1994
0x56d46375 execute
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/function.cc:2041
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/i686-pc-linux-gnu/14/../../../../i686-pc-linux-gnu/bin/ld: error:
lto-wrapper failed
collect2: error: ld returned 1 exit status
```

[Bug c++/103825] ICE on switch on enum class in bitfield

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Started with r5-3726-g083e891e69429f, so mine.

commit 083e891e69429f93b958f6c18e2d52f515bae572
Author: Marek Polacek 
Date:   Wed Sep 24 17:23:56 2014 +

re PR c/61405 (Not emitting "enumeration value not handled in switch"
warning for bit-field enums)

[Bug testsuite/114486] new test gcc.c-torture/execute/pr111151.c in r14-9668-gc4f2c84e8fa369 fails

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Should be fixed now.

[Bug testsuite/114486] new test gcc.c-torture/execute/pr111151.c in r14-9668-gc4f2c84e8fa369 fails

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-9676-gf536ea9cc3226793dc156952340f21e55b60c04e
Author: Jakub Jelinek 
Date:   Tue Mar 26 16:40:53 2024 +0100

testsuite: Fix up pr51.c testcase [PR114486]

Apparently I've somehow screwed up the adjustments of the originally tested
testcase, tweaked it so that in the second/third cases it actually see
a MAX_EXPR rather than COND_EXPR the MAX_EXPR has been optimized into,
and didn't update the expected value.

2024-03-26  Jakub Jelinek  

PR middle-end/51
PR testsuite/114486
* gcc.c-torture/execute/pr51.c (main): Fix up expected value
for
f.

[Bug middle-end/111151] [12/13 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-9676-gf536ea9cc3226793dc156952340f21e55b60c04e
Author: Jakub Jelinek 
Date:   Tue Mar 26 16:40:53 2024 +0100

testsuite: Fix up pr51.c testcase [PR114486]

Apparently I've somehow screwed up the adjustments of the originally tested
testcase, tweaked it so that in the second/third cases it actually see
a MAX_EXPR rather than COND_EXPR the MAX_EXPR has been optimized into,
and didn't update the expected value.

2024-03-26  Jakub Jelinek  

PR middle-end/51
PR testsuite/114486
* gcc.c-torture/execute/pr51.c (main): Fix up expected value
for
f.

[Bug modula2/114478] isnormal builtin unavailable from m2

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #3 from Gaius Mulley  ---
Closing now the patch has been applied.

[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab

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

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

--- Comment #11 from Richard Biener  ---
Created attachment 57816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57816=edit
manually reduced preprocessed source

This is the TU reduced to idihs where I put flatten on, with just -Ofast
-march=znver2 one can reproduce the vectorization difference when reverting
the offending revision ontop of trunk.

I'll have a closer look tomorrow.

[Bug modula2/114478] isnormal builtin unavailable from m2

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r14-9675-gb1af867d22e3108402c62f97d8fcd1df303c9dab
Author: Gaius Mulley 
Date:   Tue Mar 26 15:33:52 2024 +

PR modula2/114478 isnormal builtin unavailable from m2

This patch adds isnormal (and isgreater, isless, isgreaterequal,
islessequal, islessgreater, isunordered) c99 macro similar prototyped
builtins to m2.

gcc/m2/ChangeLog:

PR modula2/114478
* gm2-gcc/m2builtins.cc (struct builtin_macro_definition): New
struct.
(lookup_builtin_macro): New function.
(m2builtins_BuildBuiltinTree): Rewrite to lookup builtin function
and builtin macro.
(lookup_builtin_function): New function.
(define_builtin): Rename parameter type to prototype push macro
definition to builtin_macros vector.
(define_builtin_ext): New function.
(define_builtin_math): New function.
(m2builtins_init): Add isgreater, isless, isgreaterequal,
islessequal, islessgreater, isunordered, isnormal to macro
definitions.
* gm2-libs/Builtins.def (isgreater): New procedure function.
(isgreaterf): Ditto.
(isgreaterl): Ditto.
(isgreaterequal): Ditto.
(isgreaterequalf): Ditto.
(isgreaterequall): Ditto.
(isless): Ditto.
(islessf): Ditto.
(islessl): Ditto.
(islessequal): Ditto.
(islessequalf): Ditto.
(islessequall): Ditto.
(islessgreater): Ditto.
(islessgreaterf): Ditto.
(islessgreaterl): Ditto.
(isunordered): Ditto.
(isunorderedf): Ditto.
(isunorderedl): Ditto.
(iseqsig): Ditto.
(iseqsigf): Ditto.
(iseqsigl): Ditto.
(isnormal): Ditto.
(isnormalf): Ditto.
(isnormall): Ditto.
(isinf_sign): Ditto.
(isinf_signf): Ditto.
(isinf_signl): Ditto.
* gm2-libs/Builtins.mod (isgreater): New procedure function.
(isgreaterf): Ditto.
(isgreaterl): Ditto.
(isgreaterequal): Ditto.
(isgreaterequalf): Ditto.
(isgreaterequall): Ditto.
(isless): Ditto.
(islessf): Ditto.
(islessl): Ditto.
(islessequal): Ditto.
(islessequalf): Ditto.
(islessequall): Ditto.
(islessgreater): Ditto.
(islessgreaterf): Ditto.
(islessgreaterl): Ditto.
(isunordered): Ditto.
(isunorderedf): Ditto.
(isunorderedl): Ditto.
(iseqsig): Ditto.
(iseqsigf): Ditto.
(iseqsigl): Ditto.
(isnormal): Ditto.
(isnormalf): Ditto.
(isnormall): Ditto.
(isinf_sign): Ditto.
(isinf_signf): Ditto.
(isinf_signl): Ditto.

gcc/testsuite/ChangeLog:

PR modula2/114478
* gm2/builtins/run/pass/builtins-run-pass.exp: New test.
* gm2/builtins/run/pass/testcomparisons.mod: New test.
* gm2/builtins/run/pass/testisnormal.mod: New test.
* gm2/pimlib/run/pass/testchar.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug tree-optimization/114057] [14 Regression] 435.gromacs fails verification with -Ofast -march={znver2,znver4} and PGO after r14-7272-g57f611604e8bab

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

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

--- Comment #10 from Richard Biener  ---
So the ref output is

-3.22397e+05
3.07684e+02
1.06621e+10

and before the change we get

-3.22205e+05
3.05161e+02
1.06660e+10

while after it is

-3.22401e+05
3.11606e+02
1.06579e+10

vectorization differences show in innerf.o, bondfree.o, clincs.o, coupling.o,
disre.o and update.o while all but innerf.o show only less vectorization.
Only using the "bad" version of innerf.o gets us

-3.23378e+05
3.08348e+02
1.06697e+10

which should still PASS.  Replacing all above TUs with the bad objects
reproduces the bad output.

Replacing update.o, disre.o, coupling.o or clincs.o with the GOOD version
doesn't change the output, so it's only innerf.o and bondfree.o making
a difference.  Using only BAD bondfree.o gives

-3.22265e+05
3.07882e+02
1.06644e+10

That would have been OK as well.

The bondfree.o change is small:

@@ -2720,9 +2588,6 @@
 vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors
 vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors
 vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors
-vec.h:378:9: optimized: basic block part vectorized using 16 byte vectors
-vec.h:379:9: optimized: basic block part vectorized using 16 byte vectors
-vec.h:380:9: optimized: basic block part vectorized using 16 byte vectors
 bondfree.c:806:16: optimized: basic block part vectorized using 8 byte vectors
 vec.h:239:8: optimized: basic block part vectorized using 8 byte vectors
 vec.h:265:8: optimized: basic block part vectorized using 8 byte vectors

while the innerf.o changes are many (but possibly similar).

I will see to understand the bondfree change first.  That's the following
change in the function idihs:

 vec.h:380:9: note: Cost model analysis for part in loop 1:
-  Vector cost: 624
-  Scalar cost: 700
-vec.h:380:9: note: Basic block will be vectorized using SLP
-vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors
-vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors
-vec.h:252:8: optimized: basic block part vectorized using 8 byte vectors
-vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors
-vec.h:419:8: optimized: basic block part vectorized using 8 byte vectors
-vec.h:378:9: optimized: basic block part vectorized using 16 byte vectors
-vec.h:379:9: optimized: basic block part vectorized using 16 byte vectors
-vec.h:380:9: optimized: basic block part vectorized using 16 byte vectors
-vec.h:380:9: note: Vectorizing SLP tree:
-vec.h:380:9: note: node 0x345f188 (max_nunits=2, refcnt=1) vector(2) float
+  Vector cost: 640
+  Scalar cost: 532
+vec.h:380:9: missed: not vectorized: vectorization is not profitable.

where it basically changes what nodes we think are live.  Note this is
a larger graph with multiple instances so we might suffer from
what I noted in PR114413.

The IL has all but the call to do_dih_fup inlined into idihs.

[Bug target/114484] #include changes ::abs in std::abs

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

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

--- Comment #3 from Andrew Pinski  ---
Why do you think this is a bug?
Including an intrinsic header will almost always pull in other headers.

[Bug testsuite/114486] New: new test gcc.c-torture/execute/pr111151.c in r14-9668-gc4f2c84e8fa369 fails

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

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

Bug ID: 114486
   Summary: new test gcc.c-torture/execute/pr51.c  in
r14-9668-gc4f2c84e8fa369 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:c4f2c84e8fa369856aee76679590eb613724bfb0, r14-9668-gc4f2c84e8fa369
make  -k check-gcc RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/pr51.c"
FAIL: gcc.c-torture/execute/pr51.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr51.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr51.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr51.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr51.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr51.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/pr51.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
# of expected passes7
# of unexpected failures7

(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/pr51.exe 

Program received signal SIGABRT, Aborted.
0x77c296f8 in raise () from /lib64/glibc-hwcaps/power9/libc-2.28.so
Missing separate debuginfos, use: yum debuginfo-install
glibc-2.28-236.el8_9.12.ppc64le
(gdb) where
#0  0x77c296f8 in raise () from /lib64/glibc-hwcaps/power9/libc-2.28.so
#1  0x77c03ff4 in abort () from /lib64/glibc-hwcaps/power9/libc-2.28.so
#2  0x1558 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/execute/pr51.c:15


  if (f != 120)
__builtin_abort ();  // line 15



commit c4f2c84e8fa369856aee76679590eb613724bfb0 (HEAD)
Author: Jakub Jelinek 
Date:   Tue Mar 26 11:21:38 2024 +0100

fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case
[PR51]

* gcc.c-torture/execute/pr51.c: New test.

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[avraham.adler at gmail dot com via Gcc-bugs]

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

--- Comment #41 from Avraham Adler  ---
It has been a few years since the last comment. I recently got hit by this bug
for the first time in about a decade and a half of compiling R for Windows 64
using GCC 13.2.0 as packaged in Rtools44 [1].

Does it remain true that the only option to get around this bug without killing
all AVX2 is to pass "-Wa,-muse-unaligned-vector-move" when compiling using GCC
on Windows 64? Thank you.

[1] https://stat.ethz.ch/pipermail/r-sig-windows/2024q1/000113.html

[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE

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

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

--- Comment #13 from avieira at gcc dot gnu.org ---
They have both been backported, @Eric the tests should be passing again now.

[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Andre Simoes Dias Vieira
:

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

commit r12-10294-gd0eed43ff39a0bad4a02f8af7a4795e06aea6f80
Author: Richard Biener 
Date:   Fri Aug 4 11:24:49 2023 +0200

tree-optimization/110838 - less aggressively fold out-of-bound shifts

The following adjusts the shift simplification patterns to avoid
touching out-of-bound shift value arithmetic right shifts of
possibly negative values.  While simplifying those to zero isn't
wrong it's violating the principle of least surprise.

PR tree-optimization/110838
* match.pd (([rl]shift @0 out-of-bounds) -> zero): Restrict
the arithmetic right-shift case to non-negative operands.

(cherry picked from commit 04aa0edcace22a7815cfc57575f1f7b1f166ac10)

[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift

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

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

--- Comment #22 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:1ddd9f9e53bd649d3d236f7941106d8cc46e7358

commit r12-10293-g1ddd9f9e53bd649d3d236f7941106d8cc46e7358
Author: Richard Biener 
Date:   Thu Jul 27 13:08:32 2023 +0200

tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C

The following fixes the lack of simplification of a vector shift
by an out-of-bounds shift value.  For scalars this is done both
by CCP and VRP but vectors are not handled there.  This results
in PR91838 differences in outcome dependent on whether a vector
shift ISA is available and thus vector lowering does or does not
expose scalar shifts here.

The following adds a match.pd pattern to catch uniform out-of-bound
shifts, simplifying them to zero when not sanitizing shift amounts.

PR tree-optimization/91838
* gimple-match-head.cc: Include attribs.h and asan.h.
* generic-match-head.cc: Likewise.
* match.pd (([rl]shift @0 out-of-bounds) -> zero): New pattern.

(cherry picked from commit d1c072a1c3411a6fe29900750b38210af8451eeb)

[Bug c++/114484] #include changes ::abs in std::abs

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #2 from vincenzo Innocente  ---
*** Bug 114483 has been marked as a duplicate of this bug. ***

[Bug c++/114483] #include changes ::abs in std::abs

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

vincenzo Innocente  changed:

   What|Removed |Added

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

--- Comment #1 from vincenzo Innocente  ---
please close this

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