[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ebiggers3 at gmail dot com

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

[Bug target/104439] arm crc feature not enabled in assembly for function with crc target attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
PR 101723 is an exact dup then, so closing as a dup of bug 101723.

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

[Bug target/104439] arm crc feature not enabled in assembly for function with crc target attribute

[ebiggers3 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Eric Biggers  ---
I ran a bisection and found that the following commit fixed this bug:

  commit c1cdabe3aab817d95a8db00a8b5e9f6bcdea936f
  Author: Richard Earnshaw 
  Date:   Thu Jul 29 11:00:31 2021 +0100

  arm: reorder assembler architecture directives [PR101723]

This commit is on the branches origin/release/gcc-9, origin/releases/gcc-10,
and origin/releases/gcc-11.  That means it will be in gcc 9.5, 10.4, and 11.3,
right?  It looks like gcc-8 is no longer maintained.

So, it looks like there's nothing else to do here and this can be closed.

[Bug middle-end/95126] [9/10/11/12 Regression] Missed opportunity to turn static variables into immediates

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #5 from Alan Modra  ---
The gcc-5.1.0 code is incorrect.  It loads past the end of s, which is only
2-byte aligned.

[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:0103c2e4082c5a342a6834d31ea52bc7e5498016

commit r12-7089-g0103c2e4082c5a342a6834d31ea52bc7e5498016
Author: liuhongt 
Date:   Mon Jan 24 18:17:47 2022 +0800

Don't propagate for a more expensive reg-reg move.

For i386, it enables optimization like:

vmovd   %xmm0, %edx
-   vmovd   %xmm0, %eax
+   movl%edx, %eax

gcc/ChangeLog:

PR rtl-optimization/104059
* regcprop.cc (copyprop_hardreg_forward_1): Don't propagate
for a more expensive reg-reg move.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr104059.c: New test.

[Bug target/104439] arm crc feature not enabled in assembly for function with crc target attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
There definitely has been fixes for option attributes/pragma that went into the
trunk so this being fixed is not unexpected.

[Bug target/104439] arm crc feature not enabled in assembly for function with crc target attribute

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

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

--- Comment #1 from Andrew Pinski  ---
Looks like it was fixed on the trunk.

[Bug c/104439] New: arm crc feature not enabled in assembly for function with crc target attribute

[ebiggers3 at gmail dot com via Gcc-bugs]

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

Bug ID: 104439
   Summary: arm crc feature not enabled in assembly for function
with crc target attribute
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebiggers3 at gmail dot com
  Target Milestone: ---

Minimized reproducer:

void some_other_function(void) { }

unsigned int __attribute__((target("arch=armv8-a+crc")))
crc32_arm(unsigned int crc, const unsigned char *data, unsigned long size)
{
for (unsigned long i = 0; i < size; i++)
crc = __builtin_arm_crc32b(crc, data[i]);
return crc;
}

#pragma GCC push_options
#pragma GCC pop_options

$ arm-linux-gnueabihf-gcc -c test.c
/tmp/ccCUwib8.s: Assembler messages:
/tmp/ccCUwib8.s:58: Error: selected processor does not support `crc32b
r3,r3,r2' in ARM mode
$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (GCC) 11.2.0

The crc32_arm() function is compiled with crc instructions enabled, and gcc is
emitting assembly code using them.  However, gcc isn't emitting the directives
that tell the assembler to allow these instructions.

The problem goes away if either some_other_function() is deleted, or if the
"GCC push_options" and "GCC pop_options" pair is deleted.  I don't see any
logical reason why either change would make a difference.

(The original, non-minimized code this problem was seen on can be found at
https://github.com/ebiggers/libdeflate/blob/v1.9/lib/arm/crc32_impl.h#L75.)

[Bug target/104438] New: Combine optimization exposed after pro_and_epilogue

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 104438
   Summary: Combine optimization exposed after pro_and_epilogue
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*

#include
#include

static __m256i __attribute__((always_inline)) load8bit_4x4_avx2(const uint8_t
*const src,
const uint32_t stride)
{
__m128i src01, src23;
src01 = _mm_cvtsi32_si128(*(int32_t*)(src + 0 * stride));
src01 = _mm_insert_epi32(src01, *(int32_t *)(src + 1 * stride), 1);
src23 = _mm_cvtsi32_si128(*(int32_t*)(src + 2 * stride));
src23 = _mm_insert_epi32(src23, *(int32_t *)(src + 3 * stride), 1);
return _mm256_setr_m128i(src01, src23);
}

uint32_t  compute4x_m_sad_avx2_intrin(
uint8_t  *src, // input parameter, source samples Ptr
uint32_t  src_stride,  // input parameter, source stride
uint8_t  *ref, // input parameter, reference samples Ptr
uint32_t  ref_stride,  // input parameter, reference stride
uint32_t  height,  // input parameter, block height (M)
uint32_t  width)   // input parameter, block width (N)
{
__m128i xmm0;
__m256i ymm = _mm256_setzero_si256();
uint32_t y;
(void)width;

for (y = 0; y < height; y += 4) {
const __m256i src0123 = load8bit_4x4_avx2(src, src_stride);
const __m256i ref0123 = load8bit_4x4_avx2(ref, ref_stride);
ymm = _mm256_add_epi32(ymm, _mm256_sad_epu8(src0123, ref0123));
src += src_stride << 2;
ref += ref_stride << 2;
}

xmm0 = _mm_add_epi32(_mm256_castsi256_si128(ymm),
_mm256_extracti128_si256(ymm, 1));

return (uint32_t)_mm_cvtsi128_si32(xmm0);
}  




gcc -O2 -mavx2 -S



suboptimal asm

.L4:
vpxor   xmm3, xmm3, xmm3  # 12[c=4 l=4]  movv4di_internal/0
vpxor   xmm0, xmm0, xmm0  # 11[c=4 l=4]  movv8si_internal/0
vextracti128xmm3, ymm3, 0x1 # 409 [c=4 l=6] 
vec_extract_hi_v4di
vpaddd  xmm0, xmm0, xmm3# 429   [c=4 l=4]  *addv4si3/1
vmovd   eax, xmm0 # 430 [c=4 l=4]  *movsi_internal/12
ret   # 437   [c=0 l=1]  simple_return_internal

It can be optimized to just

xor eax, eax

Before pro_and_epilogue, cfg is like

.L2
...asm...
jmp .L4

.L3:
vpxor   xmm3, xmm3, xmm3  # 12[c=4 l=4]  movv4di_internal/0
vpxor   xmm0, xmm0, xmm0  # 11[c=4 l=4]  movv8si_internal/0

.L4:

vextracti128xmm3, ymm3, 0x1 # 409 [c=4 l=6] 
vec_extract_hi_v4di
vpaddd  xmm0, xmm0, xmm3# 429   [c=4 l=4]  *addv4si3/1
vmovd   eax, xmm0 # 430 [c=4 l=4]  *movsi_internal/12
ret   # 437   [c=0 l=1]  simple_return_internal


And Since there're 2 predecessor bbs for .L4, it can't be optimized off, but
after pro_and_epilogue, GCC copy .L4 to .L2 and merge .L4 with .L3, and exposed
the opportunity.

[Bug c++/104418] [C++17+] Error inheriting base class constructors by using-declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[C++14+] Error inheriting   |[C++17+] Error inheriting
   |base class constructors by  |base class constructors by
   |using-declaration   |using-declaration

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> So the code is invalid C++11 but valid C++14 it seems. clang gets it wrong
> for C++11 but gets it correct for C++14+.
> 
> GCC gets it wrong for C++14+.

Or that is part of C++17. Someone else will have to decide there. But clang is
definitely wrong for C++11 and GCC is definitely wrong for C++17 and C++20.

[Bug c++/104418] [C++14+] Error inheriting base class constructors by using-declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|Error inheriting base class |[C++14+] Error inheriting
   |constructors by |base class constructors by
   |using-declaration   |using-declaration
   Last reconfirmed||2022-02-08
   Keywords||rejects-valid

--- Comment #5 from Andrew Pinski  ---
(In reply to Fedor Chelnokov from comment #4)
> I think `using B::B;` is not the same as redefining each constructor with
> the explicit call of base class constructor `C(int a) : B{(int)a}{}`.

Sorry I meant it should be done by static_cast(a) which is the move
syntax rather than by a copy.


There looks like there are some differences between versions of the C++
standard too.
C++11 (before defect reports) In class.inhctor/8 had:
Each expression in the expression-list is of the form static_cast(p),
where p is the name
of the corresponding constructor parameter and T is the declared type of p.

But that was removed it looks like with
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html 

So the code is invalid C++11 but valid C++14 it seems. clang gets it wrong for
C++11 but gets it correct for C++14+.

GCC gets it wrong for C++14+.

[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
I think it's related to r12-2666 which caused load-to-store-forwarding stall
issue, and we're working on pr103734, try to improve ipa-inline.

w -param=inline-min-speedup=3, we observe both performance improvement and
codesize decrease.

Plan to land on GCC13.

[Bug target/88798] AVX512BW code does not use bit-operations that work on mask registers

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
(In reply to Wojciech Mula from comment #8)
> Thank you for the answer. Thus my question is: is it possible to delay
> conversion from kmasks into ints? I'm not a language lawyer, but I guess a
> `x binop y` has to be treated as `(int)x binop (int)y`. If it's true, we
> will have to prove that `(int)(x avx512-binop y)` is equivalent to the
> latter expr.

It's quite tricky to teach RA to choose the best alternative(which is discussed
in  pr101185).

alternatively, you can use intrinsic _kor_mask64 directly to avoid extra
movment from GPR to MASK.

uint64_t any_whitespace(__m512i string) {
return _kor_mask64 (_kor_mask64 (_mm512_cmpeq_epu8_mask(string,
_mm512_set1_epi8(' '))
 ,_mm512_cmpeq_epu8_mask(string, _mm512_set1_epi8('\n')))
 ,_mm512_cmpeq_epu8_mask(string, _mm512_set1_epi8('\r')));
}

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #3 from palmer at gcc dot gnu.org ---
I'm not sure what the right way to go about fixing this is.

Assuming the inline atomics
 work out we'll end up
with libstdc++ using atomics when compiled with newer GCCs and using locks when
compiled with older GCCs.  Those two implementations aren't compatible with
each other, as the direct atomics won't respect the lock.  That certainly means
these two implementations can't coexist, but I'm not actually sure if this is
an ABI break because I don't know what the ABI surface is supposed to be here.

As far as I can tell simple uses cases are safe here, as __exchange_and_add
isn't inlined outside of the shared library (though I'm not seeing anything
guaranteeing that, so I may be wrong here).  Doing something like trying to
mmap a shared_ptr and access from both flavors of the library (maybe one's
statically linked, for example) would also break, and I could imagine that
existing in real code.

It looks like LLVM already has inline atomics, so presumably the same issues
would arise when mixing libstdc++ libraries compiled with LLVM and GCC.

[Bug c++/104437] Constructor of templated class with full instantiation name rejected in -std=c++2a

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #1 from Jan Engelhardt  ---
Due to http://eel.is/c++draft/diff.cpp17.class#2 , it's probably going to be
(b).
However, adding inline, i.e.

  inline S() {}

makes it compile again, so that case.. might be improperly rejected.

[Bug target/104338] RISC-V: Subword atomics result in library calls

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #3 from Patrick O'Neill  ---
Created attachment 52368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52368=edit
Initial patch

Patch submitted to mailing list.
Subject: [PATCH v1] RISC-V: Add support for inlining subword atomic operations.

[Bug c++/104437] New: Constructor of templated class with full instantiation name rejected in -std=c++2a

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 104437
   Summary: Constructor of templated class with full instantiation
name rejected in -std=c++2a
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input
=

struct K {};
template struct S : Base {
S() {}
};
int main() { S s; }

Output
==
$ g++ -c -std=c++2a x.cpp (-v)
gcc version 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
(SUSE Linux) 
x.cpp:3:17: error: expected unqualified-id before ‘)’ token
3 | S() {}

Expected output
===

One of two options.

(a) succeed, as it does with g++ -std=c++17 (clang13 also accepts it under both
-std=).
(b) improve the error message to hint that the current instantiation of a class
template is no longer accepted in the new standard.

[Bug middle-end/104436] spurious -Wdangling-pointer assigning local address to a class passed by value

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
It seems that DECL_BY_REFERENCE(fndecl) might be able to tell us if the
argument is a "fake reference" that the by-value argument is substituted for. 
Let me see if that works.

[Bug middle-end/104436] spurious -Wdangling-pointer assigning local address to a class passed by value

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-07
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=2051740
   Keywords||diagnostic
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Blocks||104077


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
[Bug 104077] bogus/missing -Wdangling-pointer

[Bug middle-end/104436] New: spurious -Wdangling-pointer assigning local address to a class passed by value

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

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

Bug ID: 104436
   Summary: spurious -Wdangling-pointer assigning local address to
a class passed by value
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The test case below, reduced from
https://bugzilla.redhat.com/show_bug.cgi?id=2051740, shows that
-Wdangling-pointer can be made to trigger by assigning an object of a C++ class
with a user-defined copy ctor that stores a pointer to a local in a function
that takes an argument of the class by value.  GCC transforms the by-value
argument of the function to a by-reference, which is one of the use cases the
warning is designed to detect.

$ cat rhbz2051740.C && gcc -O1 -S -Wall -fdump-tree-optimized=/dev/stdout
rhbz2051740.C
struct S
{
  S () = default;
  S (const S ): p (s.p) { }

  void *p;
};

void foo (S s)
{
  int a[3];
  S t; t.p = a;
  s = t;
}
rhbz2051740.C: In function ‘void foo(S)’:
rhbz2051740.C:13:5: warning: storing the address of local variable ‘a’ in
‘*s.S::p’ [-Wdangling-pointer=]
   13 |   s = t;
  |   ~~^~~
rhbz2051740.C:11:7: note: ‘a’ declared here
   11 |   int a[3];
  |   ^
rhbz2051740.C:11:7: note: ‘s’ declared here

;; Function foo (_Z3foo1S, funcdef_no=3, decl_uid=2396, cgraph_uid=4,
symbol_order=3)

void foo (struct S & s)
{
  int a[3];

   [local count: 1073741824]:
  s_2(D)->p = 
  a ={v} {CLOBBER};
  return;

}

[Bug analyzer/103872] testcase fail in gcc.dg/analyzer/pr103526.c on riscv64-unknown-elf-gcc

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above commit; marking this one as resolved.  Please
reopen it if the problem is still occurring.

[Bug analyzer/104417] [12 Regression] ICE in check_dynamic_size_for_taint, at analyzer/sm-taint.cc:1058

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Thanks for filing this.  Should be fixed by the above commit.

[Bug analyzer/104417] [12 Regression] ICE in check_dynamic_size_for_taint, at analyzer/sm-taint.cc:1058

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:0c04ac0e15830b94a9f1e0715d92a4a2558dda03

commit r12-7087-g0c04ac0e15830b94a9f1e0715d92a4a2558dda03
Author: David Malcolm 
Date:   Mon Feb 7 14:00:55 2022 -0500

analyzer: fix ICE on realloc of non-heap [PR104417]

gcc/analyzer/ChangeLog:
PR analyzer/104417
* sm-taint.cc (tainted_allocation_size::tainted_allocation_size):
Remove overzealous assertion.
(tainted_allocation_size::emit): Likewise.
(region_model::check_dynamic_size_for_taint): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/104417
* gcc.dg/analyzer/pr104417.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/103872] testcase fail in gcc.dg/analyzer/pr103526.c on riscv64-unknown-elf-gcc

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-7086-g9d2c0fad59745bf67aa6471e8c9e96c351f0de59
Author: David Malcolm 
Date:   Thu Feb 3 16:21:27 2022 -0500

analyzer: fixes to memcpy [PR103872]

PR analyzer/103872 reports a failure of gcc.dg/analyzer/pr103526.c on
riscv64-unknown-elf-gcc.  The issue is that I wrote the test on x86_64
where a memcpy in the test is optimized to a write to a read/write pair,
whereas due to alignment differences the analyzer can see it as a
memcpy call, revealing problems with the analyzer's implementation
of memcpy.

This patch reimplements region_model::impl_call_memcpy in terms of a
get_store_value followed by a set_value, fixing the issue.

gcc/analyzer/ChangeLog:
PR analyzer/103872
* region-model-impl-calls.cc (region_model::impl_call_memcpy):
Reimplement in terms of a get_store_value followed by a set_value.

gcc/testsuite/ChangeLog:
PR analyzer/103872
* gcc.dg/analyzer/memcpy-1.c: Add alternate versions of test cases
in which the calls to memcpy are hidden from the optimizer.  Add
further test cases.
* gcc.dg/analyzer/taint-size-1.c: Add test coverage for memcpy
with tainted size.

Signed-off-by: David Malcolm 

[Bug target/102952] New code-gen options for retpolines and straight line speculation

[andrew.cooper3 at citrix dot com via Gcc-bugs]

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

--- Comment #40 from Andrew Cooper  ---
I've given the GCC-11 branch a test and everything appears to be in order.

[Bug demangler/104435] New: Infinite recursion in rust_demangle(mangled="_RYAvB2_l", options=259)

[teemperor at gmail dot com via Gcc-bugs]

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

Bug ID: 104435
   Summary: Infinite recursion in
rust_demangle(mangled="_RYAvB2_l", options=259)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: teemperor at gmail dot com
  Target Milestone: ---

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

Calling rust_demangle with (mangled="_RYAvB2_l", options=259) results in
infinite recursion with the following backtrace (I truncated the repeating
frames):

```
frame #130956: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130957: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130958: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130959: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130960: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130961: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130962: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130963: 0x5573a139
objdump`demangle_const(rdm=0x7fffd708) at rust-demangle.c:1158:11
frame #130964: 0x557397c1
objdump`demangle_type(rdm=0x7fffd708) at rust-demangle.c:938:11
frame #130965: 0x55738e20
objdump`demangle_path(rdm=0x7fffd708, in_value=1) at
rust-demangle.c:759:7
frame #130966: 0x55737fba
objdump`rust_demangle_callback(mangled="_RYAvB2_l", options=259,
callback=(objdump`str_buf_demangle_callback at rust-demangle.c:1534),
opaque=0x7fffd788) at rust-demangle.c:1438:7
frame #130967: 0x5573900f
objdump`rust_demangle(mangled="_RYAvB2_l", options=259) at
rust-demangle.c:1549:13
frame #130968: 0x55722fd2
objdump`cplus_demangle(mangled="_RYAvB2_l", options=259) at cplus-dem.c:166:13
frame #130969: 0x5565291f
objdump`bfd_demangle(abfd=0x55807bf0, name="_RYAvB2_l", options=3) at
bfd.c:2428:9
```

This is with objdump build from binutils-gdb at commit
2b1026f391d55070ae1e724c0770302d1c429611 . Side note: this is after commit
f10bec5ffa487ad3033ed5f38cfd0fc7d696deab that fixed the other rust demangler
infinite recursion (PR demangler/98886, PR demangler/99935). Searching bugzilla
hasn't turned up a similar backtrace, so I hope this isn't a dupe.

Can be reproduced via `objdump -C -D crashes_47.o`

[Bug analyzer/104434] Analyzer doesn't know about "pure" and "const" functions

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

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

--- Comment #1 from David Malcolm  ---
Seen on
https://github.com/xianyi/OpenBLAS/blob/c5f280a7f0e875d83833d895b2b8b0e341efabf4/lapack-netlib/LAPACKE/src/lapacke_cgbbrd_work.c
where the code has:

   if( LAPACKE_lsame( vect, 'b' ) || LAPACKE_lsame( vect, 'p' ) ) {
pt_t = (lapack_complex_float*)
LAPACKE_malloc( sizeof(lapack_complex_float) *
ldpt_t * MAX(1,n) );
  ...snip...
   }

   [...snip lots of code...]

   if( LAPACKE_lsame( vect, 'b' ) || LAPACKE_lsame( vect, 'p' ) ) {
LAPACKE_free( pt_t );
   }

where the analyzer considers the execution path where the conditions
guarding the malloc and the free are first true, and then false.

LAPACKE_lsame is a case-insensitive comparison, implemented in its own
source file.  I think if it were marked as "pure", the analyzer could
fix this without needing LTO.

[Bug analyzer/104434] New: Analyzer doesn't know about "pure" and "const" functions

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

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

Bug ID: 104434
   Summary: Analyzer doesn't know about "pure" and "const"
functions
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Consider:

extern int pure_p (int) __attribute__ ((pure));
extern void do_stuff (void);

void test (int a)
{
  void *p;
  if (pure_p (a))
{
  p = __builtin_malloc (1024);
  if (!p)
return;
}
  do_stuff ();
  if (pure_p (a))
__builtin_free (p);
}

Currently trunk -fanalyzer emits these warnings:

/tmp/foo.c: In function ‘test’:
/tmp/foo.c:14:6: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
   14 |   if (pure_p (a))
  |  ^
  ‘test’: events 1-7
|
|7 |   if (pure_p (a))
|  |  ^
|  |  |
|  |  (1) following ‘true’ branch...
|8 | {
|9 |   p = __builtin_malloc (1024);
|  |   ~~~
|  |   |
|  |   (2) ...to here
|  |   (3) allocated here
|   10 |   if (!p)
|  |  ~
|  |  |
|  |  (4) assuming ‘p’ is non-NULL
|  |  (5) following ‘false’ branch (when ‘p’ is non-NULL)...
|..
|   13 |   do_stuff ();
|  |   ~~~
|  |   |
|  |   (6) ...to here
|   14 |   if (pure_p (a))
|  |  ~
|  |  |
|  |  (7) following ‘false’ branch...
|
  ‘test’: event 8
|
|cc1:
| (8): ...to here
|
  ‘test’: event 9
|
|   14 |   if (pure_p (a))
|  |  ^
|  |  |
|  |  (9) ‘p’ leaks here; was allocated at (3)
|
/tmp/foo.c:15:5: warning: use of uninitialized value ‘p’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   15 | __builtin_free (p);
  | ^~
  ‘test’: events 1-6
|
|6 |   void *p;
|  | ^
|  | |
|  | (1) region created on stack here
|7 |   if (pure_p (a))
|  |  ~   
|  |  |
|  |  (2) following ‘false’ branch...
|..
|   13 |   do_stuff ();
|  |   ~~~
|  |   |
|  |   (3) ...to here
|   14 |   if (pure_p (a))
|  |  ~   
|  |  |
|  |  (4) following ‘true’ branch...
|   15 | __builtin_free (p);
|  | ~~
|  | |
|  | (5) ...to here
|  | (6) use of uninitialized value ‘p’ here
|

by considering the execution paths where
  pure_p (a)
is true then false (the false leak diagnostic), and false then true (the false
uninit diagnostic)

Presumably the analyzer should consider that the result of a pure/const
function doesn't change, and thus only considers the true/true and false/false
paths.

[Bug c++/104425] SFINAE hard error on failed resolution of << for defined class in namespace

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||rejects-valid

--- Comment #1 from Andrew Pinski  ---
Seems to be fixed on the trunk.

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Peter Dimov  ---
FWIW, I agree with everything Martin Sebor says in PR71962.
-fallow-address-zero is an entirely separate feature, and shouldn't be implied
by -fsanitize=undefined.

[Bug c++/104418] Error inheriting base class constructors by using-declaration

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Fedor Chelnokov  ---
I think `using B::B;` is not the same as redefining each constructor with the
explicit call of base class constructor `C(int a) : B{(int)a}{}`.

Please consider this example proving it:
```
struct A {
A() {}
A(const A&) = delete;
};

struct B {
B(A) {}
};

// ok everywhere
struct C : B {
using B::B;
};

//error everywhere
struct D : B {
D(A a) : B(a) {}
};
```

Here struct C definition is fine, but struct D is ill-formed because it
requires A to be copyable. Demo: https://gcc.godbolt.org/z/T7bhv9jeP

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That's a consequence of -fsanitize=undefined turning on
-fno-delete-null-pointer-checks (it has to, otherwise -fsanitize=null wouldn't
work properly).
And -fno-delete-null-pointer-checks says that variables or functions can be
placed at NULL address.

[Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1

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

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
the following patch fixed this bug:
[opc@qinzhao-aarch64-ol8 latest_gcc]$ git diff
diff --git a/gcc/cp/cxx-pretty-print.cc b/gcc/cp/cxx-pretty-print.cc
index 4f9a090e520d..744ed0add5ba 100644
--- a/gcc/cp/cxx-pretty-print.cc
+++ b/gcc/cp/cxx-pretty-print.cc
@@ -171,7 +171,10 @@ pp_cxx_unqualified_id (cxx_pretty_printer *pp, tree t)
 case ENUMERAL_TYPE:
 case TYPENAME_TYPE:
 case UNBOUND_CLASS_TEMPLATE:
-  pp_cxx_unqualified_id (pp, TYPE_NAME (t));
+  if (TYPE_NAME (t))
+   pp_cxx_unqualified_id (pp, TYPE_NAME (t));
+  else
+   pp_string (pp, "");
   if (tree ti = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (t))
if (PRIMARY_TEMPLATE_P (TI_TEMPLATE (ti)))
  {

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

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

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

--- Comment #2 from Jonathan Wakely  ---
And PR 67762

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

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

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

--- Comment #1 from Jonathan Wakely  ---
Maybe a dup of my PR 71962

[Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1

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

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is:

1. there is no NAME for the pointer to member function type as the following:
(in cp/decl.cc)

tree
build_ptrmemfunc_type (tree type)
{

10655   finish_builtin_struct (t, "__ptrmemfunc_type", fields, ptr_type_node);
10656 
10657   /* Zap out the name so that the back end will give us the debugging
10658  information for this anonymous RECORD_TYPE.  */
10659   TYPE_NAME (t) = NULL_TREE;
...
}

2. therefore, when printing this ptrmemfun type (which is a RECORD_TYPE), we
should consider that it might not have a TYPE_NAME, however, in the current
handling "pp_cxx_unqualified_id", the TYPE_NAME is assumed to be non-NULL, this
is not correct. 

 126 static void
 127 pp_cxx_unqualified_id (cxx_pretty_printer *pp, tree t)
 128 {
 129   enum tree_code code = TREE_CODE (t);
 130   switch (code)
... 
 169 case RECORD_TYPE:
 170 case UNION_TYPE:
 171 case ENUMERAL_TYPE:
 172 case TYPENAME_TYPE:
 173 case UNBOUND_CLASS_TEMPLATE:
 174   pp_cxx_unqualified_id (pp, TYPE_NAME (t)); ===> the ICE happens here
due to TYPE_NAME is NULL.

[Bug c/104424] -fvolatile, not documented in gcc-4.3.3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|VERIFIED|RESOLVED

--- Comment #6 from Jonathan Wakely  ---
The flag does not exist (and cannot be used) in the official GCC releases.
Maybe you are using a modified GCC provided by a third party, so that the
switch is silently ignored and doesn't give an error. In that case, you should
ask whoever provided you with that build.

The documentation on gcc.gnu.org applies to official releases, and -fvolatile
gives an error for those:

$ /home/jwakely/gcc/4.1.2/bin/gcc -x c /dev/null -fvolatile
cc1: error: unrecognized command line option "-fvolatile"
$ /home/jwakely/gcc/4.3.6/bin/gcc -x c /dev/null -fvolatile
cc1: error: unrecognized command line option "-fvolatile"

[Bug c++/104418] Error inheriting base class constructors by using-declaration

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

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

--- Comment #3 from Andrew Pinski  ---
But this is invalid code with a similar error message:
struct B {
B(int) {}
B(int&&) {}
};
struct C : B {
C(int a) : B{(int)a}{}
};

So the question is how is default constructor done, is it done with the cast
causing an rvalue or not?

[Bug c++/104418] Error inheriting base class constructors by using-declaration

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Fedor Chelnokov  ---
My personal feeling is that if a compiler accepts `B b(i);` then it must accept
`C c(i);` as well because of [namespace.udecl] p13:

> Constructors that are named by a using-declaration are treated as though they 
> were constructors of the derived class when looking up the constructors of 
> the derived class ([class.qual]) or forming a set of overload candidates 
> ([over.match.ctor], [over.match.copy], [over.match.list]).

But probably I miss something.

[Bug analyzer/104417] [12 Regression] ICE in check_dynamic_size_for_taint, at analyzer/sm-taint.cc:1058

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0

[Bug tree-optimization/104415] uninit diagnostic improvement at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-07
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug c++/104433] New: [modules] Importing and using std::make_shared causes linker errors

[lhlaurini at hotmail dot com via Gcc-bugs]

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

Bug ID: 104433
   Summary: [modules] Importing  and using
std::make_shared causes linker errors
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhlaurini at hotmail dot com
  Target Milestone: ---

Greetings.

I found that by importing  and trying to use std::make_shared, some
symbols seem to not be defined. Example:

$ cat main.cpp 
import ;

int main()
{
std::make_shared();
}

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (GCC) 

$ g++ -fmodules-ts -x c++-system-header memory

$ g++ -fmodules-ts main.cpp 
/usr/bin/ld: /tmp/ccezjsm1.o: in function `std::_Sp_make_shared_tag::_S_ti()':
main.cpp:(.text._ZNSt19_Sp_make_shared_tag5_S_tiEv[_ZNSt19_Sp_make_shared_tag5_S_tiEv]+0x7):
undefined reference to `std::_Sp_make_shared_tag::_S_ti()::__tag'
collect2: error: ld returned 1 exit status

$ g++-12 -v
Using built-in specs.
COLLECT_GCC=g++-12
COLLECT_LTO_WRAPPER=/home/username/.local/stow/gcc/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/username/.local
--enable-languages=c,c++ --disable-bootstrap --disable-multilib
--with-system-zlib --program-suffix=-12
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220207 (experimental) (GCC)

$ g++-12 -fmodules-ts -x c++-system-header memory

$ g++-12 -fmodules-ts main.cpp 
/usr/bin/ld: /tmp/cca9Gc2j.o: in function `std::_Sp_make_shared_tag::_S_ti()':
main.cpp:(.text._ZNSt19_Sp_make_shared_tag5_S_tiEv[_ZNSt19_Sp_make_shared_tag5_S_tiEv]+0x5):
undefined reference to `std::_Sp_make_shared_tag::_S_ti()::__tag'
/usr/bin/ld: /tmp/cca9Gc2j.o: in function
`std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count()':
main.cpp:(.text._ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EED2Ev[_ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EED5Ev]+0x23):
undefined reference to
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()'
collect2: error: ld returned 1 exit status

As you can see the code fails on both gcc 11.1 (as packaged by Arch Linux) and
the latest gcc. There are more errors with the newer version, but these are
caused by a change in libstdc++.

>From some quick investigation, I found that the errors seem to be occur when
importing a header which either:
1. has a function that returns a static constexpr variable;
2. defines a member function of a class specialization outside the class
template declaration (using inline or not).

Additionally, I also found that defining a member function outside the
(non-template) class declaration also causes the error, unless it's marked
inline, but this problem doesn't seem to be directly triggered by .

This is my attempt to create some simpler test cases for showing the bug(s):

$ cat header.hpp
struct A
{
static const int& f()
{
static constexpr int x = 0;
return x;
}
};

struct B
{
static void f1();
static void f2();
};

void B::f1()
{
}

// This is ok
inline void B::f2()
{
}

template 
struct C
{
static void f1();
static void f2();
};

template <>
void C::f1()
{
}

template <>
inline void C::f2()
{
}

$ cat main.cpp
import "header.hpp";

int main()
{
A::f();
B::f1();
B::f2();
C::f1();
C::f2();
}

$ g++ -fmodules-ts -x c++-header header.hpp 
$ g++ -fmodules-ts main.cpp
/usr/bin/ld: /tmp/ccMu0ee3.o: in function `main':
main.cpp:(.text+0xa): undefined reference to `B::f1()'
/usr/bin/ld: main.cpp:(.text+0x14): undefined reference to `C::f1()'
/usr/bin/ld: main.cpp:(.text+0x19): undefined reference to `C::f2()'
/usr/bin/ld: /tmp/ccMu0ee3.o: in function `A::f()':
main.cpp:(.text._ZN1A1fEv[_ZN1A1fEv]+0x7): undefined reference to `A::f()::x'
c

[Bug c++/104432] [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/104432] [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-02-07

[Bug c++/104432] New: [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080

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

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

Bug ID: 104432
   Summary: [12 Regression] ICE in operator() from
filter_memfn_lookup since r12-6080
   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: ---

Since r12-6080-gab85331c58223e483c55ff0316a92265d7910e9b the following testcase
ICEs:
rh2051651.C: In instantiation of ‘void E<  >::bar()
[with  = int]’:
rh2051651.C:22:8:   required from here
rh2051651.C:22:38: internal compiler error: in operator(), at cp/pt.c:16271
   22 |   void bar () { for (auto i : b) foo (i); }
  |  ^~~
0xddb7b4 operator()
../../gcc/cp/pt.c:16271
0xddbac4 filter_memfn_lookup
../../gcc/cp/pt.c:16276
0xddc1cf tsubst_baselink
../../gcc/cp/pt.c:16363
0xdf6444 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20864
0xdf42e3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20494
0xdeed6a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:19313
0xde6c18 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18326
0xde8c90 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18557
0xde9a37 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18655
0xe0d76a instantiate_body
../../gcc/cp/pt.c:26236
0xe0f136 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26529
0xe0f4d2 instantiate_pending_templates(int)
../../gcc/cp/pt.c:26608
0xc10624 c_parse_final_cleanups()
../../gcc/cp/decl2.c:5097
0xf5edcd c_common_parse_file()
../../gcc/c-family/c-opts.c:1260
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

struct A {
  int operator* ();
  void operator++ ();
  bool operator!= (A);
};
struct B {
  A begin ();
  A end ();
};
struct C {
  template 
  void foo ();
};
struct D : public C {
  void foo (int);
  virtual void bar ();
};
template  struct E : D {
  using D::foo;
  using C::foo;
  B b;
  void bar () { for (auto i : b) foo (i); }
};
struct F {
  using G = E<>;
  F() {}
  G g;
};

[Bug c++/104418] Error inheriting base class constructors by using-declaration

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

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

--- Comment #1 from Andrew Pinski  ---
MSVC and ICC reject this for the same reason as GCC. Are you sure this is not a
bug in clang?

[Bug other/104431] Provide better error message when GCC "multilib" is missing

[eyalroz1 at gmx dot com via Gcc-bugs]

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

--- Comment #2 from Eyal Rozenberg  ---
(In reply to Andrew Pinski from comment #1)
> How did configure GCC?

I used:

./configure --disable-gnat --disable-fortran

(although I'm not sure --disable-fortran does anything).

[Bug target/104422] nvptx: for-3.exe fail with driver 390.x

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #1 from Roger Sayle  ---
Is the problem reproduceable (with the legacy driver) when the omp #pragma are
removed, and the program compiled with -mainkernel and executed with
nvptx-none-run-single?  This eliminates the GOMP (interaction) as source of the
problem.

[Bug other/104431] Provide better error message when GCC "multilib" is missing

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-02-07

--- Comment #1 from Andrew Pinski  ---
>I was recently trying to build GCC 8.5.0

How did configure GCC?

GCC has a nice error message about not having a 32bit mutlilib installed since
r0-127201 (which is pre GCC 5.0).

So I have no idea why you are getting the error message you are getting without
exact instructions on how to reproduce this.

[Bug other/104431] New: Provide better error message when GCC "multilib" is missing

[eyalroz1 at gmx dot com via Gcc-bugs]

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

Bug ID: 104431
   Summary: Provide better error message when GCC "multilib" is
missing
   Product: gcc
   Version: 8.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz1 at gmx dot com
  Target Milestone: ---

I was recently trying to build GCC 8.5.0 on my Devuan Chimaera machine, which
has GCC 9 and 10 installed. When configuring, I was told:

/usr/bin/ld: cannot find Scrt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/10/libgcc.a
when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/10/libgcc.a
when searching for -lgcc
/usr/bin/ld: cannot find -lgcc

it is _quite_ difficult for the lay person to understand what the actual
problem here. I have GCC 10, I have ligcc for GCC 10 - what's wrong with it?
And what are Scrt1 and crti ? And why is configure checking for `.o` files
anyway?

Now, as explained in this StackOverflow answer: 

https://stackoverflow.com/a/16016792/1593077

this is easily resolved by installing the "gcc-multilib" Debian package, which
meant in practice installing:

gcc-10-multilib lib32asan6 lib32atomic1 lib32gcc-10-dev lib32gomp1 lib32itm1
lib32quadmath0 lib32ubsan1 libc6-dev-i386 libc6-dev-x32 libc6-x32 libx32asan6
libx32atomic1 libx32gcc-10-dev libx32gcc-s1 libx32gomp1 libx32itm1
libx32quadmath0 libx32stdc++6 libx32ubsan1

I don't need to be told about all of these, but some kind of message saying
"cross-platform build libraries missing" or "GCC multilib 32-bit libraries
missing" or whatever. It doesn't have to be distribution-specific, but it
_should_ tell me what I need to go look for.

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-02-07

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE with|ICE with
   |__builtin_assoc_barrier and |__builtin_assoc_barrier and
   |float16 types   |float types which introduce
   ||excess precision
 Target||aarch64*-* x86_64-*-*

--- Comment #2 from Andrew Pinski  ---
It is an interaction between excess_precision_expr and the barrier.

Here is another testcase which shows the same issue but on i?86 (-m32 -mno-sse
-std=c99):
float x, y;
int foo()
{
  return __builtin_assoc_barrier(x + y) - y;
}

[Bug fortran/104430] New: [9/10/11/12 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742

[gscfq--- via Gcc-bugs]

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

Bug ID: 104430
   Summary: [9/10/11/12 Regression] ICE in gfc_conv_component_ref,
at fortran/trans-expr.cc:2742
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Starts with r8, basically r9 changed between 20181014 and 20181021 :


$ cat z1.f90
module m
   type t
  integer :: a
   end type
contains
   function f(x) result(z)
  class(t) :: x(:)
  type(t) :: z(size(x%a))
   end
end
program p
   use m
   class(t), allocatable :: y(:), z(:)
   z = f(y)
end


$ gfortran-7 -c z1.f90
$
$ gfortran-12-20220206 -c z1.f90
z1.f90:14:11:

   14 |z = f(y)
  |   1
internal compiler error: Segmentation fault
0xe6fc6f crash_signal
../../gcc/toplev.cc:322
0x8265df tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/tree.h:3483
0x8265df gfc_conv_component_ref(gfc_se*, gfc_ref*)
../../gcc/fortran/trans-expr.cc:2742
0x837897 gfc_conv_variable
../../gcc/fortran/trans-expr.cc:3118
0x83264a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9406
0x835760 gfc_conv_expr_lhs(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9436
0x7f0858 gfc_conv_ss_descriptor
../../gcc/fortran/trans-array.cc:3219
0x7fd2e5 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.cc:7494
0x8462cf gfc_conv_intrinsic_size
../../gcc/fortran/trans-intrinsic.cc:7975
0x86295b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.cc:10644
0x83262a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9398
0x834b5a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
../../gcc/fortran/trans-expr.cc:4865
0x7ee747 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*)
../../gcc/fortran/trans-array.cc:1080
0x83066f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:7472
0x8426ac gfc_trans_arrayfunc_assign
../../gcc/fortran/trans-expr.cc:10873
0x8428d4 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool)
../../gcc/fortran/trans-expr.cc:12038
0x7e9887 trans_code
../../gcc/fortran/trans.cc:1916
0x8207a9 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7654
0x7931fe translate_all_program_units
../../gcc/fortran/parse.cc:6651
0x7931fe gfc_parse_file()
../../gcc/fortran/parse.cc:6938

[Bug c/104427] ICE with __builtin_assoc_barrier and float16 types

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

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

--- Comment #1 from Andrew Pinski  ---
>Started between 2024 and 20211121 :

Started when __builtin_assoc_barrier support was added
(r12-5368-gefb7c51024ccad9df2) so this is not a regression.

[Bug fortran/104429] New: [9/10/11/12 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056

[gscfq--- via Gcc-bugs]

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

Bug ID: 104429
   Summary: [9/10/11/12 Regression] ICE in gfc_conv_variable, at
fortran/trans-expr.cc:3056
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20180826 and 20180902 :


$ cat z1.f90
module m
   type t
   contains
  procedure :: op
  procedure :: assign
  generic :: operator(*) => op
  generic :: assignment(=) => assign
   end type
contains
   function op (x, y)
  class(t), allocatable :: op
  class(t), intent(in) :: x
  real, intent(in) :: y
   end
   subroutine assign (z, x)
  type(t), intent(in) :: x
  class(t), intent(out) :: z
   end
end
program p
   use m
   class(t), allocatable :: x
   x = x * y
end


$ gfortran-8 -c z1.f90
$
$ gfortran-12-20220206 -c z1.f90
z1.f90:23:12:

   23 |x = x * y
  |1
interner Compiler-Fehler: in gfc_conv_variable, at fortran/trans-expr.cc:3056
0x7dc07f gfc_conv_variable
../../gcc/fortran/trans-expr.cc:3056
0x7d7fba gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9406
0x7e5102 get_proc_ptr_comp
../../gcc/fortran/trans-expr.cc:4176
0x7e5102 conv_function_val
../../gcc/fortran/trans-expr.cc:4215
0x7e5102 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:7650
0x81f040 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.cc:422
0x7a7043 trans_code
../../gcc/fortran/trans.cc:1995
0x7d037e gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7654
0x7530ae translate_all_program_units
../../gcc/fortran/parse.cc:6651
0x7530ae gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x7a00af gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

[Bug fortran/104428] New: [12 Regression] ICE in gfc_trans_omp_declare_variant, at fortran/trans-openmp.cc:7648

[gscfq--- via Gcc-bugs]

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

Bug ID: 104428
   Summary: [12 Regression] ICE in gfc_trans_omp_declare_variant,
at fortran/trans-openmp.cc:7648
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211010 and 20211017 :


$ cat z1.f90
program p
contains
   subroutine s
  !$omp declare variant(x) match(construct={do})
   end
end


$ cat z2.f90   # accepted
subroutine s
   !$omp declare variant(x) match(construct={do})
end


$ gfortran-12-20220206 -c z2.f90 -fopenmp
$
$ gfortran-12-20220206 -c z1.f90 -fopenmp
z1.f90:3:15:

3 |subroutine s
  |   1
interner Compiler-Fehler: Speicherzugriffsfehler
0xcc806f crash_signal
../../gcc/toplev.cc:322
0x816506 gfc_trans_omp_declare_variant(gfc_namespace*)
../../gcc/fortran/trans-openmp.cc:7648
0x7cb007 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.cc:3118
0x7d016e gfc_generate_contained_functions
../../gcc/fortran/trans-decl.cc:5768
0x7d016e gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7586
0x7530ae translate_all_program_units
../../gcc/fortran/parse.cc:6651
0x7530ae gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x7a00af gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

[Bug c/104427] New: [12 Regression] ICE in gimplify_expr, at gimplify.cc:15759

[gscfq--- via Gcc-bugs]

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

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

Started between 2024 and 20211121 :


$ cat z1.c
_Float16 x, y;
int foo()
{
  return __builtin_assoc_barrier(x + y) - y;
}


$ gcc-12-20220206 -c z1.c
z1.c:4:36: internal compiler error: in gimplify_expr, at gimplify.cc:15759
4 |   return __builtin_assoc_barrier(x + y) - y;
  |  ~~^~~
0xac934a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15759
0xac70cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15720
0xac43ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15066
0xac3f9d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15729
0xac9c78 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xac57ee gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.cc:495
0xac57ee gimplify_return_expr
../../gcc/gimplify.cc:1677
0xac57ee gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15225
0xac9c78 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xaca603 gimplify_bind_expr
../../gcc/gimplify.cc:1427
0xac5f8a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15164
0xac9c78 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xacb85e gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:16209
0xacbe47 gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:16363
0x8dd527 cgraph_node::analyze()
../../gcc/cgraphunit.cc:675
0x8e07d6 analyze_functions
../../gcc/cgraphunit.cc:1240
0x8e19ad symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2500

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 52366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52366=edit
gcc12-pr104385.patch

So far lightly tested fix.

[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

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

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

--- Comment #2 from Martin Jambor  ---
(In reply to Hongtao.liu from comment #1)
> I think this patch has already been reverted by
> r12-3011-g1db70e61a92978377a648bbd90e383859fc0126b.

Unfortunately that revision does not help.

[Bug c++/104419] [[no_unique_address]] interaction with is_standard_layout

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Pr 104386 is very much related.

[Bug c++/104426] New: -fsanitize=undefined causes constexpr failures

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 104426
   Summary: -fsanitize=undefined causes constexpr failures
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

The following program

```
struct category
{
constexpr bool failed() const noexcept
{
return true;
}
};

inline constexpr category s_cat;

struct condition
{
category const* cat_;

constexpr bool failed() const noexcept
{
if( cat_ )
{
return cat_->failed();
}
else
{
return false;
}
}
};

int main()
{
constexpr condition cond{ _cat };
static_assert( cond.failed() );
}
```

compiles without -fsanitize=undefined (https://godbolt.org/z/Pn9M5ocfz), but
fails with it (https://godbolt.org/z/KKc8Tb9qe) with

```
: In function 'int main()':
:31:31: error: non-constant condition for static assertion
   31 | static_assert( cond.failed() );
  |~~~^~
:31:31:   in 'constexpr' expansion of 'cond.condition::failed()'
:17:13: error: '((& s_cat) != 0)' is not a constant expression
   17 | if( cat_ )
  | ^~~~
```

This happens under all GCC versions starting from 7.

(The above is an extract from the test suite for
boost::system::error_condition.)

[Bug c/104424] -fvolatile, not documented in gcc-4.3.3

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |INVALID

[Bug target/88798] AVX512BW code does not use bit-operations that work on mask registers

[wojciech_mula at poczta dot onet.pl via Gcc-bugs]

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

--- Comment #8 from Wojciech Mula  ---
Thank you for the answer. Thus my question is: is it possible to delay
conversion from kmasks into ints? I'm not a language lawyer, but I guess a `x
binop y` has to be treated as `(int)x binop (int)y`. If it's true, we will have
to prove that `(int)(x avx512-binop y)` is equivalent to the latter expr.

[Bug c++/104425] New: SFINAE hard error on failed resolution of << for defined class in namespace

[saalvage at gmail dot com via Gcc-bugs]

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

Bug ID: 104425
   Summary: SFINAE hard error on failed resolution of << for
defined class in namespace
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saalvage at gmail dot com
  Target Milestone: ---

namespace A { class foo {}; }
namespace B { class bar {}; }

A::foo& operator<<(A::foo& f, const B::bar&) { return f; }

namespace C {
template 
T val();

class asd {};
A::foo& operator<<(A::foo& f, const asd& in) { return f; }

template 
struct has_insertion_operator {
static constexpr bool value = false;
};

template 
struct has_insertion_operator() << val(),
void())> {
static constexpr bool value = true;
};
}

int main() { C::has_insertion_operator::value; }

Produces:
: In instantiation of 'struct C::has_insertion_operator':
:24:47:   required from here
:19:62: error: no match for 'operator<<' (operand types are 'A::foo'
and 'B::bar')
   19 | struct has_insertion_operator() <<
val(), void())> {
  |  
~~~^~~
:11:13: note: candidate: 'A::foo& C::operator<<(A::foo&, const
C::asd&)'
   11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
  | ^~~~
:11:46: note:   no known conversion for argument 2 from 'B::bar' to
'const C::asd&'
   11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
  |   ~~~^~
:19:62: error: no match for 'operator<<' (operand types are 'A::foo'
and 'B::bar')
   19 | struct has_insertion_operator() <<
val(), void())> {
  |  
~~~^~~
:11:13: note: candidate: 'A::foo& C::operator<<(A::foo&, const
C::asd&)'
   11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
  | ^~~~
:11:46: note:   no known conversion for argument 2 from 'B::bar' to
'const C::asd&'
   11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
  |   ~~~^~
:19:62: error: no match for 'operator<<' (operand types are 'A::foo'
and 'B::bar')
   19 | struct has_insertion_operator() <<
val(), void())> {
  |  
~~~^~~
:11:13: note: candidate: 'A::foo& C::operator<<(A::foo&, const
C::asd&)'
   11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
  | ^~~~
:11:46: note:   no known conversion for argument 2 from 'B::bar' to
'const C::asd&'
   11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
  |   ~~~^~
:20: confused by earlier errors, bailing out

Notably, the same candidate appears to be reinspected thrice?

Bizzarely enough, both of the following fix the issue:
- Calling operator<< explicitely
- Only declaring, not defining B::bar

[Bug c/104424] -fvolatile, not documented in gcc-4.3.3

[swaroop.tekale at se dot com via Gcc-bugs]

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

Swaroop Tekale  changed:

   What|Removed |Added

 Resolution|INVALID |WORKSFORME
 Status|RESOLVED|VERIFIED

--- Comment #5 from Swaroop Tekale  ---
As mentioned in the description: We are able to use the -fvolatile flag. We are
not getting any errors. 
And hence need to understand if this is a a document miss or really an invalid
flag for gcc 4.3.3 ?

[Bug c/104424] -fvolatile, not documented in gcc-4.3.3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
.

[Bug c/104424] -fvolatile, not documented in gcc-4.3.3

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

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

--- Comment #3 from Jonathan Wakely  ---
It's not there because it was removed in GCC 3.4:
https://gcc.gnu.org/gcc-3.4/changes.html

You will get an error if you try to use it with 4.3.3

There is no bug report here, so I think it would have been more appropriate on
the gcc-help mailing list, https://gcc.gnu.org/lists.html

[Bug c/104424] -fvolatile, not documented in gcc-4.3.3

[swaroop.tekale at se dot com via Gcc-bugs]

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

--- Comment #2 from Swaroop Tekale  ---
It seems to be there on or before gcc-3.3.6:

https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Option-Summary.html#Option-Summary

Code Generation Options
See Options for Code Generation Conventions.
  -fcall-saved-reg  -fcall-used-reg 
  -ffixed-reg  -fexceptions 
  -fnon-call-exceptions  -funwind-tables 
  -fasynchronous-unwind-tables 
  -finhibit-size-directive  -finstrument-functions 
  -fno-common  -fno-ident  -fno-gnu-linker 
  -fpcc-struct-return  -fpic  -fPIC 
  -freg-struct-return  -fshared-data  -fshort-enums 
  -fshort-double  -fshort-wchar  -fvolatile 
  -fvolatile-global  -fvolatile-static 
  -fverbose-asm  -fpack-struct  -fstack-check 
  -fstack-limit-register=reg  -fstack-limit-symbol=sym 
  -fargument-alias  -fargument-noalias 
  -fargument-noalias-global  -fleading-underscore 
  -ftls-model=model 
  -ftrapv  -fbounds-check

[Bug c/104424] -fvolatile, not documented in gcc-4.3.3

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
Such a flag never existed, there is only -Wvolatile.

[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code

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

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

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

https://gcc.gnu.org/g:5d2a330dee37ed10daa424d33ab1bcd5727c187b

commit r12-7084-g5d2a330dee37ed10daa424d33ab1bcd5727c187b
Author: Jakub Jelinek 
Date:   Mon Feb 7 17:39:11 2022 +0100

testsuite: Fix up testsuite/gcc.c-torture/execute/builtins/lib/chk.c for
powerpc [PR104380]

> > The following testcase FAILs when configured with
> > --with-long-double-format=ieee .  Only happens in the -std=c* modes,
not the
> > GNU modes; while the glibc headers have __asm redirects of
> > vsnprintf and __vsnprinf_chk to __vsnprintfieee128 and
> > __vsnprintf_chkieee128, the vsnprintf fortification extern inline
gnu_inline
> > always_inline wrapper calls __builtin_vsnprintf_chk and we actually
emit
> > a call to __vsnprinf_chk (i.e. with IBM extended long double) instead
of
> > __vsnprintf_chkieee128.
> >
> > rs6000_mangle_decl_assembler_name already had cases for *printf and
*scanf,
> > so this just adds another case for *printf_chk.  *scanf_chk doesn't
exist.
> > __ prefixing isn't done because *printf_chk already starts with __.

Unfortunately, while I've tested the testcase also with
-mabi=ieeelongdouble
by hand, the full bootstrap/regtest was on GCCFarm where glibc is too old
to test with --with-long-double-format=ieee.
I've done full bootstrap/regtest with that option during the weekend and
the patch regressed:
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -Os

The problem is that the execute/builtins/ testsuite wants to override some
of the library functions and with the change we (correctly) call
__*printf_chkieee128 and so lib/chk.c is no longer called but the glibc
APIs are.

2022-02-07  Jakub Jelinek  

PR target/104380
* gcc.c-torture/execute/builtins/lib/chk.c (__sprintf_chkieee128,
__vsprintf_chkieee128, 

[Bug c/104424] New: -fvolatile, not documented in gcc-4.3.3

[swaroop.tekale at se dot com via Gcc-bugs]

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

Bug ID: 104424
   Summary: -fvolatile, not documented in gcc-4.3.3
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: swaroop.tekale at se dot com
  Target Milestone: ---

"-fvolatile" flag is not listed in the below gcc-4.3.6:
https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Option-Summary.html#Option-Summary

Can you please confirm if this is explicitly removed, as it should not be
configured ?

Or if it is a gcc document miss in above link?

We are still able to use the -fvolatile flag as part of compiler options, So
need confirmation if this is still a valid flag ?

This will help us to understand if we still have to keep "-fvolatile" flag in
our environment or consider removing it.

Compiler version: gnu 4.3.3

[Bug tree-optimization/24021] VRP does not work with floating points

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #5 from Aldy Hernandez  ---
(In reply to Andrew Macleod from comment #4)
> FWIW, we hope to enable floating point range support in ranger for GCC 13. 
> 
> One of the post stage 1 tasks is to generalize ranger to use a vrange class,
> from which we can derive integral (irange), pointer (prange), and float
> (frange) types. possibly complex integral (cirange) and/or string (srange)
> have been thrown around if appropriate.
> 
> Before we go to develop the frange class, we'll have a working session of
> some sort to flesh out what it can track, then implement some range-ops for
> some float tree-codes.

FWIW, I'm on this.  I've begun work on vrange, and simultaneously have started
work on a proof-of-concept for floating points that I hope some more savvy
floating experts can extend.

[Bug fortran/104382] Finalization of parent components not compliant with standard

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

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

--- Comment #3 from Paul Thomas  ---
(In reply to anlauf from comment #2)
> crayftn 11 & 12 output:
> 
>  destructor4(complicated) 2*2.
>  destructor5 (simple2) 5
>  destructor5 (simple2) 6
>  destructor2(simple) 2*1
>  destructor4(complicated) 4.,  5.
>  destructor5 (simple2) -1
>  destructor5 (simple2) -2
>  destructor2(simple) 3,  4
>  final_count after assignment =  8
>  destructor4(complicated) 4.,  5.
>  destructor5 (simple2) -1
>  destructor5 (simple2) -2
>  destructor2(simple) 3,  4
>  final_count after deallocation =  12

That seems to make a majority vote for the present gfortran behaviour then.

Thanks

Paul

[Bug fortran/104382] Finalization of parent components not compliant with standard

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
crayftn 11 & 12 output:

 destructor4(complicated) 2*2.
 destructor5 (simple2) 5
 destructor5 (simple2) 6
 destructor2(simple) 2*1
 destructor4(complicated) 4.,  5.
 destructor5 (simple2) -1
 destructor5 (simple2) -2
 destructor2(simple) 3,  4
 final_count after assignment =  8
 destructor4(complicated) 4.,  5.
 destructor5 (simple2) -1
 destructor5 (simple2) -2
 destructor2(simple) 3,  4
 final_count after deallocation =  12

[Bug testsuite/104423] New: [libgomp, testsuite] Add means to do accelerator-only testing in libgomp

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

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

Bug ID: 104423
   Summary: [libgomp, testsuite] Add means to do accelerator-only
testing in libgomp
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

For nvptx offload testing, I switched to an eGPU setup, and cycle through 4
boards (kepler, maxwell, pascal, turing) to do pre-commit testing.  Sometime in
the future that'll be 5, once I get an ampere board as well.

I run a script test-board.sh that iterates over various dimensions, which takes
about 5 hours per board.  In practice, this means testing a patch get spread
over 2 days.

Furthermore, I'm looking to extend the dimensions on which I test, possibly
doubling the test-board time.

I noticed that a lot of time is spent running libgomp tests that do not use the
accelerator, and which are not needed for my purposes.

It would be nice if libgomp provided a mode to run only tests that use the
accelerator, to drive down the test-board.sh execution time.

[Bug target/104422] New: nvptx: for-3.exe fail with driver 390.x

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

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

Bug ID: 104422
   Summary: nvptx: for-3.exe fail with driver 390.x
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

While testing libgomp using legacy driver 390.x on a maxwell card, Quadro K620
I ran into a for-3.exe execution failure.

I've minimized it to this:
...
$ cat for-3.c  
/* { dg-additional-options "-std=gnu99" { target c } } */

extern void abort ();

#pragma omp declare target

int a[1500];

void
test_ds_normal (void)
{
#pragma omp target update to(a)
  ;

#pragma omp target teams
#pragma distribute simd
  for (int i = 0; i < 1500; i++)
a[i] += 2;

#pragma omp target update from(a)
;
}

#pragma omp end declare target

int
main (void)
{
  int err = 0;

  for (int i = 0; i < 1500; i++)
a[i] = i - 25;

  test_ds_normal ();

  for (int i = 0; i < 1500; i++)
if (a[i] != i - 23)
  err = 1;

 if (err)
abort ();

  return 0;
}
...

This might be a driver problem, we know of problems that we reported to nvidia
that they're not going to fix in this driver.

Then again, it might not be a driver problem...

[Bug middle-end/103641] [11 regression] Severe compile time regression in SLP vectorize step

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[11/12 regression] Severe   |[11 regression] Severe
   |compile time regression in  |compile time regression in
   |SLP vectorize step  |SLP vectorize step
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #31 from Richard Biener  ---
Marking fixed for GCC 12 then (still 35% with SLP vectorization is on the high
end).  I'm not sure about backporting this particular change, I'll definitely
wait more for that.

I suppose the slowness is still entirely within synth_mult?

[Bug fortran/102596] [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 since r11-4883-ge929ef532ad52cde

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords||ice-on-valid-code

--- Comment #2 from Tobias Burnus  ---
The problem is that gfc_omp_clause_default_ctor requires outer != NULL_TREE
(gcc_assert). 

(C++ does ignore the last argument and C uses the hook_tree_tree_tree_tree_null
fallback.)

That is used in Fortran for:
  /* Allocatable arrays and scalars in PRIVATE clauses need to be set to
 "not currently allocated" allocation status if outer
 array is "not currently allocated", otherwise should be allocated.  */

But omp-low.cc has:
  x = lang_hooks.decls.omp_clause_default_ctor
(c, unshare_expr (new_var),
 cond ? NULL_TREE
 : build_outer_var_ref (var, ctx));
Note the NULL_TREE.


My impression is that NULL_TREE is fine for reduction - and there is also code
like:


  /* Reduction clause requires allocated ALLOCATABLE.  */
  if (OMP_CLAUSE_CODE (clause) != OMP_CLAUSE_REDUCTION
  && OMP_CLAUSE_CODE (clause) != OMP_CLAUSE_IN_REDUCTION
  && OMP_CLAUSE_CODE (clause) != OMP_CLAUSE_TASK_REDUCTION)
{
  gfc_init_block (_block);
...
  tree tem = fold_convert (pvoid_type_node,
   GFC_DESCRIPTOR_TYPE_P (type)
   ? gfc_conv_descriptor_data_get (outer) :
outer);/*...*/
  cond = fold_build2_loc (input_location, NE_EXPR, logical_type_node,
  tem, null_pointer_node);


However - there is other code which uses 'outer' like:
  tree tem = gfc_walk_alloc_comps (outer, decl,
or 
  gfc_add_modify (_block, decl, outer);
and those make use of 'outer'.

I don't quickly see whether outer is always required or it can be deduced in
this case. 
(Does using OMP_CLAUSE_REDUCTION_PLACEHOLDER() make sense here?) — Or whether
some is-always-used case (→ 'cond' case) is needed as additional flag or
encoded in outer.


PS: I don't think it is a real regression as 'reduction(task:' wasn't supported
before.

[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes

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

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

--- Comment #4 from Jeffrey A. Law  ---
Given we've run this code on a pretty wide variety of targets, I'm not too
concerned.  The arc issue was the last one I'm aware of related to your ifcvt
changes.

[Bug c++/104410] [11/12 Regression] Internal error using default-initialized constexpr bool in requires clause

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||ppalka at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #3 from Patrick Palka  ---
Started with r11-6321.  I suppose the underlying problem is that the assert in
satisfaction_value should is too strict, it should be relaxed to accept
cv-qualified bool.

[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Created attachment 52365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52365=edit
gcc12-pr104379.patch

Untested fix (just for -Wshadow).

[Bug ada/104421] New: The Ada.Directories.Modification_Time procedure does not work for non-ASCII filenames in the Windows environment.

[yeongtaek.ham at gmail dot com via Gcc-bugs]

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

Bug ID: 104421
   Summary: The Ada.Directories.Modification_Time procedure does
not work for non-ASCII filenames in the Windows
environment.
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yeongtaek.ham at gmail dot com
  Target Milestone: ---

The Ada.Directories.Modification_Time procedure does not work for non-ASCII
filenames in the Windows environment.

Example code (file is UTF-8 encoded):

with Ada.Calendar;
with Ada.Directories;
with Ada.Text_IO;
with GNAT.Calendar.Time_IO;

procedure Main is
   package TEXT_IO renames Ada.Text_IO;
   package TIME_IO renames GNAT.Calendar.Time_IO;

   Mod_Time : Ada.Calendar.Time;
begin
   TEXT_IO.Put_Line ("한글 출력");

   -- Good
   Mod_Time := Ada.Directories.Modification_Time("modtime.gpr");
   TIME_IO.Put_Time (Mod_Time, TIME_IO.ISO_Time);
   TEXT_IO.NEW_LINE;

   -- Error
   Mod_Time := Ada.Directories.Modification_Time("한글.txt");
   TIME_IO.Put_Time (Mod_Time, TIME_IO.ISO_Time);
   TEXT_IO.NEW_LINE;
end Main;



Execution result:

PS C:\Users\Regentag\desktop\AdaDev\FileModTime> chcp 65001
Active code page: 65001
PS C:\Users\Regentag\desktop\AdaDev\FileModTime> dir


디렉터리: C:\Users\Regentag\desktop\AdaDev\FileModTime


Mode LastWriteTime Length Name
 - -- 
d-  22-02-07 22:46obj
d-  22-02-07 21:02src
-a  22-02-07 19:30126 modtime.gpr
-a  22-02-07 19:30126 한글.txt


PS C:\Users\Regentag\desktop\AdaDev\FileModTime> C:\GNAT\2021\bin\gprbuild.exe
.\modtime.gpr
Compile
   [Ada]  main.adb
Bind
   [gprbind]  main.bexch
   [Ada]  main.ali
Link
   [link] main.adb
PS C:\Users\Regentag\desktop\AdaDev\FileModTime> .\obj\main.exe
한글 출력
2022-02-07T19:30:02+09

raised ADA.IO_EXCEPTIONS.USE_ERROR : Unable to get modification time of the
file "한글.txt"
PS C:\Users\Regentag\desktop\AdaDev\FileModTime>



My GCC version info:

PS C:\GNAT\2021\bin> ./gcc -v
Using built-in specs.
COLLECT_GCC=C:\GNAT\2021\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/gnat/2021/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../src/configure --enable-languages=ada,c,c++
--enable-checking=release --enable-threads=win32 --enable-libstdcxx-threads
--enable-lto --enable-large-address-aware
--with-bugurl=URL:mailto:rep...@adacore.com --disable-nls
--without-libiconv-prefix --disable-libstdcxx-pch --disable-libada
--disable-multilib --enable-libstdcxx
--with-mpfr=/it/sbx/a2c2/x86_64-windows64/mpfr-3.1.5/install
--with-gmp=/it/sbx/a2c2/x86_64-windows64/gmp-6.1.2/install
--with-mpc=/it/sbx/a2c2/x86_64-windows64/mpc-1.0.3/install
--with-build-time-tools=/it/sbx/a2c2/x86_64-windows64/gcc-c/build/buildtools/bin
--prefix=/it/sbx/a2c2/x86_64-windows64/gcc-c/pkg --build=x86_64-w64-mingw32
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210520 (for GNAT Community 2021 20210519) (GCC)
PS C:\GNAT\2021\bin>



In my opinion, the cause is the use of the GetFileAttributesExA() function
without proper handling of the file name in the __gnat_file_time() function
implemented in adaint.c.
 *
https://github.com/gcc-mirror/gcc/blob/db95441cf5399aabc46ca83df19f7290c3e23cb1/gcc/ada/adaint.c#L1515

[Bug target/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test

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

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

--- Comment #4 from Tom de Vries  ---
This fixes it:
...
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
b/gcc/testsuite/gcc.dg/tree-ss
a/builtin-sprintf.c
index f90558e9b7ee..9368a2e0e50a 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
@@ -3,7 +3,8 @@
constant folding.  With optimization enabled the test will fail to
link if any of the assertions fails.  Without optimization the test
aborts at runtime if any of the assertions fails.  */
-/* { dg-do run } */
+/* { dg-do run { target c99_runtime } } */
+/* { dg-do link { target { ! c99_runtime } } } */
 /* { dg-skip-if "not IEEE float layout" { "pdp11-*-*" } } */
 /* { dg-additional-options "-O2 -Wall -Wno-pedantic -fprintf-return-value" }
*/
...

[Bug tree-optimization/104420] New: [12 Regression] Inconsistent checks for X * 0.0 optimization

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

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

Bug ID: 104420
   Summary: [12 Regression] Inconsistent checks for X * 0.0
optimization
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

(from a comment in PR 104389)

/* Maybe fold x * 0 to 0.  The expressions aren't the same
   when x is NaN, since x * 0 is also NaN.  Nor are they the
   same in modes with signed zeros, since multiplying a
   negative value by 0 gives -0, not +0.  Nor when x is +-Inf,
   since x * 0 is NaN.  */
(simplify
 (mult @0 real_zerop@1)
 (if (!tree_expr_maybe_nan_p (@0)
  && (!HONOR_NANS (type) || !tree_expr_maybe_infinite_p (@0))
  && !tree_expr_maybe_real_minus_zero_p (@0)
  && !tree_expr_maybe_real_minus_zero_p (@1))
  @1))

Notice how the comment talks about @0 being a "negative value" while the code
says "!tree_expr_maybe_real_minus_zero_p (@0)", which is not at all the same
thing.

Because tree_expr_maybe_real_minus_zero_p is rather weak, it does not trigger
so often, but still:

double f(int a){
  return a*0.;
}

is optimized to "return 0.;" whereas f(-42) should return -0.

[Bug c++/104419] New: [[no_unique_address]] interaction with is_standard_layout

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

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

Bug ID: 104419
   Summary: [[no_unique_address]] interaction with
is_standard_layout
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

GCC disagrees with Clang and MSVC in this example (reduced from our std::tuple,
and affecting std::unique_ptr):


template struct node;

#ifdef USE_EBO
template struct node : T
{ };
#else
template struct node
{
[[no_unique_address]] T t;
};
#endif

template struct node
{
T t;
};

template struct tuple;

template
struct tuple : node { };

template
struct tuple : tuple, node
{ };

struct empty {};

static_assert( sizeof(tuple) == sizeof(int), "" );

static_assert( __is_standard_layout(tuple), "");
static_assert( __is_standard_layout(tuple), "");
static_assert( __is_standard_layout(tuple), ""); // Clang fails


template struct tuple2;

template
struct tuple2 : node, node
{ };

static_assert( sizeof(tuple2) == sizeof(int), "" );

// GCC and Clang agree for this type (with no recursive inheritance)
static_assert( ! __is_standard_layout(tuple2), "");


If USE_EBO is defined, everybody agrees tuple is standard layout.
But when replacing EBO with [[no_unique_address]] other compilers say it's no
longer standard layout. If they're right, that's a problem for our std::tuple
(as it means the change to use [[no_unique_address]] in std::tuple affected its
ABI).

It seems to me that we should be able to replace EBO with [[no_unique_address]]
(that was the whole point of it), which would support GCC's interpretation. But
if that's the case, I'm not sure why tuple2 isn't standard layout,
even for GCC.

[Bug target/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test

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

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> I'll try to rebuild with
> --enable-newlib-io-c99-formats.

And we run into:
...
In file included from
/home/vries/nvptx/trunk/source-gcc/newlib/libc/include/stdlib.h:22,
 from
/home/vries/nvptx/trunk/source-gcc/newlib/libc/stdio/vfscanf.c:83:
/home/vries/nvptx/trunk/source-gcc/newlib/libc/stdio/vfscanf.c: In function
‘__ssvfiscanf_r’:
/home/vries/nvptx/trunk/source-gcc/newlib/libc/stdio/vfscanf.c:451:39: sorry,
unimplemented: \
target cannot support alloca
...

[Bug target/104413] _mm_set1_epi8 isn't optimized for SSE2

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
pshufb is SSSE3.

[Bug target/104396] [11/12 Regression] Invalid SIMD intriniscs accepted at -O1 and above after r11-6794-g04b472ad0e1dc93aba

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
So shouldn't diagnostics of the builtins errors that now can be and previously
couldn't be DCEd done in the gimple fold target hook?

[Bug c++/104300] [12 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2977 since r12-6326-ge948436eab818c52

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test

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

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

--- Comment #2 from Tom de Vries  ---
With -fno-builtin, mimimized further to:
...
char buffer[100];

int
main (void)
{
  unsigned int i = 0xdeadbeef;

  __builtin_sprintf (buffer, "%hhx", i);
  __builtin_printf ("%s\n", buffer);

  __builtin_printf ("%hhx\n", i);

  return 0;
}
...

On x86_64 with glibc:
...
$ gcc gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
$ ./a.out
ef
ef
...

On nvptx with newlib:
...
spawn nvptx-none-run ./builtin-sprintf.exe^M
beef^M
%hhx^M
...

This could be related to newlib support for hh, I'll try to rebuild with
--enable-newlib-io-c99-formats.

[Bug middle-end/103641] [11/12 regression] Severe compile time regression in SLP vectorize step

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

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

--- Comment #30 from Tamar Christina  ---
No problem during nightlies. No real changes in other workloads in compile time
nor runtime.

can confirm no perf change for xxhash and compile time decreased from 8 to 1
sec.

tree vectorization :   0.28 (  3%)   0.00 (  0%)   0.28 (  3%) 
 135k (  0%)
tree slp vectorization :   7.43 ( 89%)   0.00 (  0%)   7.41 ( 87%) 
3450k (  8%)

into

tree vectorization :   0.02 (  2%)   0.00 (  0%)   0.02 (  2%) 
 135k (  0%)
tree slp vectorization :   0.37 ( 35%)   0.00 (  0%)   0.39 ( 31%) 
3400k (  8%)

[Bug c++/104418] New: Error inheriting base class constructors by using-declaration

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 104418
   Summary: Error inheriting base class constructors by
using-declaration
   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
```
struct B {
B(int) {}
B(int&&) {}
};

int i = 1;
B b(i); //ok everywhere

struct C : B {
using B::B;
};

C c(i); //ok in Clang only
```
is accepted in Clang, but GCC complains:
```
:13:6: error: use of deleted function 'C::C(int) [inherited from B]'
   13 | C c(i);
  |  ^
:10:14: note: 'C::C(int) [inherited from B]' is implicitly deleted
because the default definition would be ill-formed:
   10 | using B::B;
  |  ^
:10:14: error: call of overloaded 'B(int)' is ambiguous
```
Demo: https://gcc.godbolt.org/z/79EoYM94d

Related question: https://stackoverflow.com/q/71005539/7325599

[Bug fortran/104382] Finalization of parent components not compliant with standard

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

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

--- Comment #1 from Paul Thomas  ---
(In reply to Paul Thomas from comment #0)
> Created attachment 52349 [details]
> Testcase for the problems
> 
> With all branches that feature finalization, the attached testcase outputs:
>  final_count after assignment =0
>  destructor4(complicated)   4.   5.
>  destructor5 (simple2)  -1
>  destructor5 (simple2)  -2
>  destructor2(simple)   3   4
>  final_count after deallocation =4
> 
> Ifort, on the other hand, outputs:
>  destructor4(complicated)   2.00   2.00
>  destructor5 (simple2)   5
>  destructor5 (simple2)   6
>  destructor1(simple)   1
>  destructor1(simple)   1
>  final_count after assignment =5
>  destructor4(complicated)   4.00   5.00
>  destructor5 (simple2)  -1
>  destructor5 (simple2)  -2
>  destructor1(simple)   3
>  destructor1(simple)   4
>  final_count after deallocation =   10
> 
> There are two problems:
> (i) The finalization of 'var' prior to reallocation is not ocurring. This is
> fixed by the patch that I posted to the list yesterday.
> 
> (ii) The parent component is not being treated as a component, as mandated
> by F2018 7.5.6.2/1(3). Ifort is behaving correctly.
> 
> Paul
 I now discover that NAG 7.1 behaves the same way as gfortran.

Paul

[Bug target/97005] [nvptx] FAIL: c-c++-common/torture/builtin-arith-overflow-15.c -O0 execution test

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

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

--- Comment #8 from Tom de Vries  ---
I've tried the workaround (posting here only the patch for trunchiqi2, the
pattern that was actually triggered):
...
@@ -424,9 +436,21 @@
   [(set (match_operand:QI 0 "nvptx_nonimmediate_operand" "=R,m")
(truncate:QI (match_operand:HI 1 "nvptx_register_operand" "R,R")))]
   ""
-  "@
-   %.\\tcvt%t0.u16\\t%0, %1;
-   %.\\tst%A0.u8\\t%0, %1;"
+  {
+if (which_alternative == 1)
+  return "%.\\tst%A0.u8\\t%0, %1;";
+
+const char *cvt = "%.\\tcvt%t0.u16\\t%0, %1;";
+if (1)
+  {
+/* Workaround https://developer.nvidia.com/nvidia_bug/3527713.  */
+output_asm_insn ("%.\\tcvt.s32.s16\\t%0, %1;", operands);
+output_asm_insn ("%.\\tand.b32\\t%0, %0,0x;", operands);
+return "";
+  }
+
+return cvt;
+  }
   [(set_attr "subregs_ok" "true")])

 (define_insn "truncsi2"
...
but it didn't work for the test-case from comment 0.

Something that does seem to work for both cases, and the unreduced
builtin-arith-overflow-15.c:
...
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 6c399dea1908..c33903688a5d 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -507,7 +507,13 @@
(minus:HSDIM (match_operand:HSDIM 1 "nvptx_register_operand" "R")
 (match_operand:HSDIM 2 "nvptx_register_operand" "R")))]
   ""
-  "%.\\tsub%t0\\t%0, %1, %2;")
+  {
+if (GET_MODE (operands[0]) == HImode)
+  /* Workaround https://developer.nvidia.com/nvidia_bug/3527713.  */
+  return "%.\\tsub.s16\\t%0, %1, %2;";
+
+return "%.\\tsub%t0\\t%0, %1, %2;";
+  })

 (define_insn "mul3"
   [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
...

[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #52362|0   |1
is obsolete||

--- Comment #16 from Jakub Jelinek  ---
Created attachment 52364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52364=edit
gcc12-pr104407.patch

Updated patch.  Hope it doesn't do more harm for -fcompare-debug, I'm not
really sure if e.g. mangling something doesn't force some instantiations that
wouldn't otherwise happen.  And this patch can mangle even things that weren't
mangled before with the PR96690 change, though I guess reference_to_unused
calls during early_dwarf are just random lottery.

[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #15 from rguenther at suse dot de  ---
On Mon, 7 Feb 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407
> 
> --- Comment #14 from Jakub Jelinek  ---
> Ah, you're right, I thought the rtl is used in the native_encode_initializer
> case but it is not.
> So, if the point of r11-2834 was to mangle the referenced symbols, then we
> shouldn't call rtl_for_decl_init but instead do STRIP_NOPS + if
> (initializer_constant_valid_p) walk_tree with a callback that will
> DECL_ASSEMBLER_NAME on the decls.

Yeah, I guess so, using assign_assembler_name_if_needed ()

[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1

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

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

--- Comment #14 from Jakub Jelinek  ---
Ah, you're right, I thought the rtl is used in the native_encode_initializer
case but it is not.
So, if the point of r11-2834 was to mangle the referenced symbols, then we
shouldn't call rtl_for_decl_init but instead do STRIP_NOPS + if
(initializer_constant_valid_p) walk_tree with a callback that will
DECL_ASSEMBLER_NAME on the decls.

[Bug tree-optimization/104408] SLP discovery fails due to -Ofast rewriting

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Tamar Christina from comment #4)
> (In reply to Richard Biener from comment #3)
> > match.pd just does canonicalization here.  SLP discovery could handle this
> > in the existing swap operands or reassoc support but I guess the desire here
> > is to pull out a Complex SLP pattern.
> 
> Yes, though also to optimize the case where you don't have the optab,
> currently the generated code is much worse at -Ofast.
> 
> > 
> > So - no perfect idea yet how to reliably match a Complex pattern here but
> > trying to attack this from the match.pd side sounds wrong.
> 
> Well the problem is that the scalar code is suboptimal too. even without
> matching a complex pattern, so the epilogue here does an extra sub on each
> unrolled step.

Well, the issue is then why the scalar code is not optimized (yes, it's
not so easy).

> So I initially figured we'd want to not perform the canonization if it's
> coming at the expense of sharing. However that looks harder than I though at
> first as there are multiple points in const-fold.c that will try and force
> this form.

Yep.  The canonicalization likely happens early before we do CSE.

> I can probably fix the epilogue post vectorization but that seemed like a
> worse solution.

Well, the CSE opportunity needs to be realized despite the canonialization.

[Bug analyzer/104417] New: [12 Regression] ICE in check_dynamic_size_for_taint, at analyzer/sm-taint.cc:1058

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 104417
   Summary: [12 Regression] ICE in check_dynamic_size_for_taint,
at analyzer/sm-taint.cc:1058
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 12.0.1 20220206 snapshot (g:8eb329e963593342855b6072e5692659107337b7) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/Wfree-nonheap-object-2.c, w/ -fanalyzer:

char eparr[1];

void *
warn_realloc_extern_ptrarr_offset (int i, int n)
{
  return __builtin_realloc (eparr + i, n);
}

% gcc-12.0.1 -fanalyzer -c e9xvubm5.c
during IPA pass: analyzer
e9xvubm5.c: In function 'warn_realloc_extern_ptrarr_offset':
e9xvubm5.c:6:10: internal compiler error: in check_dynamic_size_for_taint, at
analyzer/sm-taint.cc:1058
6 |   return __builtin_realloc (eparr + i, n);
  |  ^~~~
0x7b4ac7 ana::region_model::check_dynamic_size_for_taint(ana::memory_space,
ana::svalue const*, ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/sm-taint.cc:1058
0x1299852 ana::region_model::set_dynamic_extents(ana::region const*,
ana::svalue const*, ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/region-model.cc:3895
0x12a3510 update_model
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/region-model-impl-calls.cc:667
0x1270a0b ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:3808
0x127157a ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:3137
0x1273c00 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:5716
0x1274afe ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:5787
0x1263808 execute
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/analyzer-pass.cc:87