[Bug c++/109459] static_assert with operator""s causes internal compiler error

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jakub Jelinek  ---
Indeed.

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

[Bug c++/105300] [10/11/12 Regression] segfault from static_assert with user-defined string suffix argument

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||stevenxia990430 at gmail dot 
com

--- Comment #7 from Jakub Jelinek  ---
*** Bug 109459 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

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

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

--- Comment #29 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #28)
> Created attachment 54821 [details]
> New set of patches including some other improvements

Note this series does not bootstrap, the last patch found that I had a latent
bug in the patch that started to handle diamond shaped PHIs.

For:
  if (_16 == 34)
goto ; [INV]
  else
goto ; [INV]

   :
  ...
  _27 = csets__identifier_char[_26];
  if (_27 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
  // predicted unlikely by early return (on trees) predictor.

   :
  # _28 = PHI <1(7), 0(12), 1(4), 1(11)>

I would transform it to use _27 even from bb 12 which is wrong.

I had missed that minmax_replacement did:

  if (!single_pred_p (middle_bb)
  || !single_pred_p (alt_middle_bb)
  || !single_succ_p (middle_bb)
  || !single_succ_p (alt_middle_bb))
return false;

I will add that check tomorrow.

[Bug target/109458] invalid use 'z' operand modifier in some cases mention the 'Z' operand modifier

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 54822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54822&action=edit
gcc13-pr109458.patch

Untested fix.

[Bug tree-optimization/109462] New: [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

Bug ID: 109462
   Summary: [13 Regression] Possible miscompilation of clang
LocalizationChecker since r13-1938
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54823&action=edit
LocalizationChecker.ii.xz

As mentioned in (but not reported to us) in
https://github.com/llvm/llvm-project/issues/59227
// clang -cc1 test.m -analyze -setup-static-analyzer
-analyzer-checker=optin.osx.cocoa.localizability.EmptyLocalizationContextChecker
#define nil ((id)0)
#define NSLocalizedString(key, comment) [[NSBundle mainBundle]
localizedStringForKey:(key) value:@"" table:nil]
struct CGPoint { double x; double y; };
typedef struct CGPoint CGPoint;
@interface NSObject
+ (id)alloc;
- (id)init;
@end
@class NSDictionary;
@interface NSString : NSObject
- (void)drawAtPoint:(CGPoint)point withAttributes:(NSDictionary *)attrs;
+ (instancetype)localizedStringWithFormat:(NSString *)format, ...;
@end
@interface NSBundle : NSObject
+ (NSBundle *)mainBundle;
- (NSString *)localizedStringForKey:(NSString *)key
  value:(NSString *)value
  table:(NSString *)tableName;
@end
@interface LocalizationTestSuite : NSObject
@end
@implementation LocalizationTestSuite
- (void)testNilLocalizationContext {
  NSString *string = NSLocalizedString(@"LocalizedString", nil);
}
@end
reports an (expected) warning when
clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp is compiled with
r13-1937 and earlier, while
when compiled with r13-1938 and later the warning is not emitted.
The r13-1938 changes cause differences in
_ZNK5clang13SourceManager16getDecomposedLocENS_14SourceLocationE
and
_ZN12_GLOBAL__N_131EmptyLocalizationContextChecker13MethodCrawler20VisitObjCMessageExprEPKN5clang15ObjCMessageExprE
functions and it is the latter that matters for whether the warning is reported
or not (proved by hand-combining assembly
from the 2 revisions, everything from r13-1937 but the
_ZN12_GLOBAL__N_131EmptyLocalizationContextChecker13MethodCrawler20VisitObjCMessageExprEPKN5clang15ObjCMessageExprE
function from r13-1938 doesn't report the warning, everything from r13-1938 but
that function from r13-1937 does.
First difference in both functions appears in the dom2 dumps.

Flags used to compile were -fPIC -fno-semantic-interposition
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections -fno-common
-fno-strict-aliasing -O3 -fno-exceptions -funwind-tables -fno-rtti -std=c++17
LocalizationChecker.ii

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Severity|normal  |critical

[Bug c/109463] New: suboptimal sequence for converting 64-bit unsigned int to float

[elronnd at elronnd dot net via Gcc-bugs]

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

Bug ID: 109463
   Summary: suboptimal sequence for converting 64-bit unsigned int
to float
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elronnd at elronnd dot net
  Target Milestone: ---

double f(uint64_t x) { return x; } gives:

test   rdi,rdi
js 10 
pxor   xmm0,xmm0
cvtsi2sd xmm0,rdi
ret
nop
10:
movrax,rdi
andedi,0x1
pxor   xmm0,xmm0
shrrax,1
or rax,rdi
cvtsi2sd xmm0,rax
addsd  xmm0,xmm0
ret

In particular, the sequence:

movrax,rdi
andedi,0x1
shrrax,1
or rax,rdi
cvtsi2sd xmm0,rax

Can be replaced with:

movzx  eax,dil
shrrdi,1
or rdi,rax
cvtsi2sd xmm0,rdi

Since all 9 low bits of rdi are below the sticky bit, oring them together in
any order suffices to round correctly.

Alternatively, in order to avoid clobbering rdi, use the following sequence:

movrax,rdi
shrrax,1
or al,dil
cvtsi2sd xmm0,rax

(The penalty for partial register access appears to be very cheap or
nonexistent on recent uarchs.)

[Bug target/109463] suboptimal sequence for converting 64-bit unsigned int to float

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
clang/LLVM produces:

movq%rdi, %xmm1
punpckldq   .LCPI1_0(%rip), %xmm1   # xmm1 =
xmm1[0],mem[0],xmm1[1],mem[1]
subpd   .LCPI1_1(%rip), %xmm1
movapd  %xmm1, %xmm0
unpckhpd%xmm1, %xmm0# xmm0 =
xmm0[1],xmm1[1]
addsd   %xmm1, %xmm0
retq

LCPI1_0 being:
.LCPI1_1:
.quad   0x4330  # double 4503599627370496
.quad   0x4530  # double 1.9342813113834067E+25


note clang even produces that even if you say the top bit is not set via:
double f(unsigned long x) { if (x >>63) __builtin_unreachable(); return x; }

[Bug target/109463] suboptimal sequence for converting 64-bit unsigned int to float

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

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

--- Comment #2 from Andrew Pinski  ---
It might be the case that having the top bit set for an 64bit unsigned integer
is not often enough to optimize for ...

[Bug target/109463] suboptimal sequence for converting 64-bit unsigned int to float

[elronnd at elronnd dot net via Gcc-bugs]

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

--- Comment #3 from elronnd at elronnd dot net ---
Yes, I think the gcc approach of branching is definitely better.  But it's
still a good idea to optimise for size in the cold path.

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

--- Comment #1 from Jakub Jelinek  ---
When stepping through the function in the debugger, the difference appears in
the
  Token I;
  Token Result;
  int p_count = 0;
  while (!TheLexer.LexFromRawLexer(I)) {
if (I.getKind() == tok::l_paren)
  ++p_count;
if (I.getKind() == tok::r_paren) {
  if (p_count == 1)
break;
  --p_count;
}
Result = I;
  }

loop followed by:
  if (isAnyIdentifier(Result.getKind())) {
I see 7 iterations of the loop where the 2nd increments p_count to 1
and then in the expected behavior we reach the isAnyIdentifier expression in
the if statement after the loop.
In the non-expected behavior also 7 iterations, but in the last one I see:
1157if (I.getKind() == tok::l_paren)
(gdb) 
1159if (I.getKind() == tok::r_paren) {
(gdb) 
1160  if (p_count == 1)
(gdb) n
1184}
(gdb) n
(anonymous
namespace)::EmptyLocalizationContextChecker::MethodCrawler::VisitChildren
(this=0x7fffb830, S=) at
/usr/src/llvm-project/clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp:1060
1060  for (const Stmt *Child : S->children()) {
so basically it didn't break but did return or so.
The expected behavior under debugger was:
1157if (I.getKind() == tok::l_paren)
(gdb) 
1159if (I.getKind() == tok::r_paren) {
(gdb) 
1160  if (p_count == 1)
(gdb) 
1167  if (isAnyIdentifier(Result.getKind())) {
so, I think the 2nd iteration has I.getKind() == tok::l_paren and the 7th ==
tok::r_paren and no other iteration has those kinds.

[Bug target/109456] `-ffixed` is ignored for `a` registers on RISC-V.

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #5 from Xi Ruoyao  ---
Is this a bug?

-ffixed-reg
Treat the register named reg as a fixed register; generated code should never
refer to it (except perhaps as a stack pointer, frame pointer or in some other
fixed role).

To me "the ABI mandates to pass an argument in this register" means "some other
fixed role".

[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
Fixed in 9.3 and later.

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

[Bug target/85667] ms_abi rules aren't followed when returning and passing short structs with float and double values

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||jistone at redhat dot com

--- Comment #16 from Eric Botcazou  ---
*** Bug 82028 has been marked as a duplicate of this bug. ***

[Bug c++/109464] New: gcc does not instantiate constructor for explicitly instantiated template

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 109464
   Summary: gcc does not instantiate constructor for explicitly
instantiated template
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Created attachment 54824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54824&action=edit
unreduced testcase

Attached is a preprocessed file. I don't know how to reduce it for absence of a
function.


```
template
class basic_shallow_string
  {
static_assert(!is_array::value, "invalid character type");
static_assert(is_trivial::value, "characters must be trivial");
template friend class basic_cow_string;

  private:
const charT* m_ptr;
size_t m_len;

  public:
explicit constexpr
basic_shallow_string(const charT* ptr) noexcept
  : m_ptr(ptr), m_len(noadl::xstrlen(ptr))
  { }

  public:
constexpr
const charT*
c_str() const noexcept
  { return this->m_ptr;  }

constexpr
size_t
length() const noexcept
  { return this->m_len;  }

(... more member functions follow ...)
  };

extern template class basic_shallow_string;
```

And in 'cow_string.cpp' I have 

```
#include "cow_string.hpp"
namespace rocket {

template class basic_shallow_string;

(... more explicit instantiations follow ...)
}  // namespace rocket
```

This explicit instantiation instantiates all inline member functions above, but
not the constructor. I have examined assembly output, and there is no
constructor. Unless optimization is enabled, this causes undefined references:

```
/usr/bin/ld: asteria/repl/bin_asteria-commands.o: in function
`rocket::basic_shallow_string rocket::sref(char const*)':
/home/lh_mouse/GitHub/asteria/asteria/repl/../../rocket/cow_string.hpp:97:
undefined reference to
`rocket::basic_shallow_string::basic_shallow_string(char const*)'
collect2: error: ld returned 1 exit status
```

This happens only with the constructor.

[Bug target/109465] New: LoongArch: The expansion of memcpy is slow and bloated for some sizes

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

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

Bug ID: 109465
   Summary: LoongArch: The expansion of memcpy is slow and bloated
for some sizes
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

extern char *a, *b;

void test() { __builtin_memcpy(a, b, 15); }

With -mno-strict-align, this is compiled to 15 ld.bu/st.b pairs instead of the
optimal (4 pairs).

All size values >= 19 (except 24) seem affected.

[Bug target/109465] LoongArch: The expansion of memcpy is slow and bloated for some sizes

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-10
 CC||chenglulu at loongson dot cn
 Target||loongarch64-linux-gnu
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Xi Ruoyao  ---
Not a regression nor "serious" issue, the fix can be deferred into GCC 14 stage
1.

[Bug c++/109459] static_assert with operator""s causes internal compiler error

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Steven Xia  ---
(In reply to Jakub Jelinek from comment #2)
> Indeed.
> 
> *** This bug has been marked as a duplicate of bug 105300 ***

Thanks for the pointers and sorry for the confusion, will check against trunk
next time for any bug reports.

[Bug testsuite/109466] New: [13 regression] gfortran.dg/gomp/affinity-clause-1.f90 fails after r13-7120-g46fe32cb4d887d

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

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

Bug ID: 109466
   Summary: [13 regression] gfortran.dg/gomp/affinity-clause-1.f90
fails after r13-7120-g46fe32cb4d887d
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:46fe32cb4d887d44a62f9c4ff2a72532d4eb5a19, r13-7120-g46fe32cb4d887d 

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,m64}'
gomp.exp=gfortran.dg/gomp/affinity-clause-1.f90"
FAIL: gfortran.dg/gomp/affinity-clause-1.f90   -O   scan-tree-dump-times
original "#pragma omp task affinity\\(iterator\\(integer\\(kind=4\\)
i=D\\.[0-9]+:5:1\\):b\\[\\(.* ? \\+ -1\\]\\)
affinity\\(iterator\\(integer\\(kind=4\\)
i=D\\.[0-9]+:5:1\\):d\\[\\(\\(integer\\(kind=8\\)\\) i \\+ -1\\) \\* 6\\]\\)" 1
# of expected passes7
# of unexpected failures1

Previously it just had 7 passes.

Note this only happens on powerpc64 BE systems.  On LE systems the test is
skipped altogether.


commit 46fe32cb4d887d44a62f9c4ff2a72532d4eb5a19
Author: Paul Thomas 
Date:   Sat Apr 8 07:49:13 2023 +0100

Fortran: Fix dg directives and remove trailing whitespaces in testsuite

[Bug fortran/109467] New: inconsistent formatting/case of keywords in error messages in Fortran front end

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

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

Bug ID: 109467
   Summary: inconsistent formatting/case of keywords in error
messages in Fortran front end
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

I've noted that calls to gfc_error in the Fortran front end use a mix of
conventions for language keywords.  Some messages use "%", others
"KEYWORD", and then there are things like "% REDUCTION clause" in the
same message.  :-(

The GCC internals manual is clear that %< markup should be used on all
keywords, but is upper or lower case preferred?  Almost all places that
currently use %< markup use lower case.  The Fortran standard uses upper case
for keywords and intrinsics, as does the GNU Fortran manual, while the OpenMP
spec seems to use lower case for its own keywords and upper case for regular
Fortran keywords.

There are also a couple messages in trans-openmp.cc that use literal quotes
around lower-case keywords.

Anyway, rather than trying to patch these things piecemeal, it's probably best
just to make a pass through the sources to implement whatever convention we
decide on, and similarly patch up all testcases that scan for these error
messages.

[Bug c/3343] gcc compiled code gives segmentation fault

[trodgers at redhat dot com via Gcc-bugs]

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

--- Comment #3 from trodgers at redhat dot com ---
I had this in my TODO list to review, I've done that now. Any sense of when
LWG will approve it?

On Thu, Feb 23, 2023 at 9:17 AM redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449
>
> Jonathan Wakely  changed:
>
>What|Removed |Added
>
> 
>  CC||rodgertq at gcc dot
> gnu.org
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
>

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Costas Argyris  ---
Can you give some more info on how exactly you are cross-building gcc for
windows host?

Did you add the -fno-PIE flag manually or was it part of the build process you
are following?

Seems like you are trying to compile an executable out of sym-mingw32.cc, but
this shouldn't be happening because this file gets compiled into a simple
object file only.That's why it would help to know more about the build
process you are following.

[Bug analyzer/109190] GCC Static Analyzer cannot handle the initialization of an array with a for loop

[StevenSun2021 at hotmail dot com via Gcc-bugs]

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

Steven Sun  changed:

   What|Removed |Added

 CC||StevenSun2021 at hotmail dot 
com

--- Comment #4 from Steven Sun  ---
The analyzer is implemented as a ipa pass, which eats codes partially optimized
by the middle end, or the optimizer.

Your code presented to the analyzer looks like this in -O1

https://godbolt.org/z/KdaKW5Yae
```
int main ()
{
  int j;
  goto ; [100.00%]
   [local count: 536870913]:
  j_4 = j_1 + 1;
   [local count: 1073741824]:
  if (j_1 <= 0)
goto ; [50.00%]
  else
goto ; [50.00%]
   [local count: 536870913]:
  return 0;
}
```

And it looks like this in -O2
https://godbolt.org/z/rrjdaM4WP

```
int main ()
{
  MEM[(int *)0B] = 1;
  return 0;
}
```

The analyzer outputs should be definitely different.

I am not here to what causes this, but in case you're interested, you can use
godbolt to check all optimize passes.

[Bug analyzer/108767] O2 optimization has side effects on static analysis.

[StevenSun2021 at hotmail dot com via Gcc-bugs]

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

Steven Sun  changed:

   What|Removed |Added

 CC||StevenSun2021 at hotmail dot 
com

--- Comment #2 from Steven Sun  ---
Like I just mentioned in #109190, you can check what is eaten by the analyzer.

https://godbolt.org/z/Yqd11hGM6

the `for (d = 0; d <= 1; ++d)` was optimized as  `for (d = 0; d != 2; ++d)`

It looks like it will increase the range of `d` to `d != 2`.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-10
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
> Did you add the -fno-PIE flag manually or was it part of the build process
> you are following?

-fno-PIE is automatically set when the compiler is built.

> Seems like you are trying to compile an executable out of sym-mingw32.cc,
> but this shouldn't be happening because this file gets compiled into a
> simple object file only.That's why it would help to know more about the
> build process you are following.

The missing -o looks genuine, does not it?

sym-mingw32.o : $(srcdir)/config/i386/sym-mingw32.cc
$(COMPILER) -c $< $@

Note that:

tf8-mingw32.o : utf8rc-mingw32.o sym-mingw32.o
$(COMPILER) -r utf8rc-mingw32.o sym-mingw32.o -o $@

can be rewritten using $^ instead of repeating the prerequisites.

[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 54825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54825&action=edit
failed attempt at reducing

This was my trial on reducing the testcase but it failed. In that the symbol is
defined correctly still.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Costas Argyris  ---
"The missing -o looks genuine, does not it?"

Not to me because this has been built successfully before.If this was the
problem then it would never build, right?

What happened in this case was that sym-mingw32.o was treated as an input to
the compiler (see "No such file or directory" error) rather than as an output
which it really is.

I suspect this had to do with -fno-PIE triggering building an executable, which
I still don't know where it is coming from and whether it should be used for
compiling this file, as this has nothing to do with an executable - we are only
compiling the .cc file to a .o file.

Still I think it is important to have details of the overall build process
followed to get some context.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Eric Botcazou  ---
> Not to me because this has been built successfully before.If this was
> the problem then it would never build, right?

This looks like a bug in any case and thus needs to be fixed.

> What happened in this case was that sym-mingw32.o was treated as an input to
> the compiler (see "No such file or directory" error) rather than as an
> output which it really is.

Yes, because -o is missing.

> I suspect this had to do with -fno-PIE triggering building an executable,
> which I still don't know where it is coming from and whether it should be
> used for compiling this file, as this has nothing to do with an executable -
> we are only compiling the .cc file to a .o file.

-fno-PIE is just a standard -f compilation option, nothing more.

> Still I think it is important to have details of the overall build process
> followed to get some context.

No disagreement.

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

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

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

--- Comment #9 from Andrew Pinski  ---
I have a patch which fixes the phiopt issue I saw.
The problem is when do_hoist_loads is true (which is !early and
-fhoist-adjacent-loads ), we would not do the diamond case for phiopt in later
passes.
In the above case, pre needs to hoist the load first and then we could get to
it with phiopt4.

You can see the same effect with:
-O2 -fno-hoist-adjacent-loads -fno-tree-vectorize

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Costas Argyris  ---
>> Yes, because -o is missing.

I don't understand why -o missing is a problem some times but not others
(because this has been succesfully built before with -o missing).

Adding a "-o" flag seems OK to me if it solves this issue, but Huaqi still
reported problems even after adding it:

utf8-mingw32.o: In function `WinMainCRTStartup':
...

this object file should never have such a function, so something went very
wrong in this build process.Looks like something was attempted to get built
as an executable, when it shouldn't.All three object files:

utf8rc-mingw32.o
sym-mingw32.o
utf8-mingw32.o

should be without any such main function.What caused this main function to
appear in this object file in this particular build process?

[Bug c++/109468] New: assign to default with three way comparison

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

Bug ID: 109468
   Summary: assign to default with three way comparison
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevenxia990430 at gmail dot com
  Target Milestone: ---

The following program reports an internal compiler error: Segmentation fault

To quickly reproduce: https://gcc.godbolt.org/z/M5oPs7eor
```
#include 
enum class Color { Red, Green, Blue };
auto operator<=>(Color lhs, Color rhs) = default;
int main() {
return 0;
}
```

It seems that assigning to default causes the issue as changing the assignment
to 0 removes the internal compiler error.

[Bug target/108812] gcc.target/powerpc/p9-sign_extend-runnable.c fails on power 9 BE

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

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

commit r13-7134-ga213e2c965382c24fe391ee5798effeba8da0fdf
Author: Haochen Gui 
Date:   Tue Apr 11 08:55:56 2023 +0800

rs6000: correct vector sign extend builtins on Big Endian

gcc/
PR target/108812
* config/rs6000/vsx.md (vsx_sign_extend_qi_): Rename to...
(vsx_sign_extend_v16qi_): ... this.
(vsx_sign_extend_hi_): Rename to...
(vsx_sign_extend_v8hi_): ... this.
(vsx_sign_extend_si_v2di): Rename to...
(vsx_sign_extend_v4si_v2di): ... this.
(vsignextend_qi_): Remove.
(vsignextend_hi_): Remove.
(vsignextend_si_v2di): Remove.
(vsignextend_v2di_v1ti): Remove.
(*xxspltib__split): Replace gen_vsx_sign_extend_qi_v2di with
gen_vsx_sign_extend_v16qi_v2di and gen_vsx_sign_extend_qi_v4si
with gen_vsx_sign_extend_v16qi_v4si.
* config/rs6000/rs6000.md (split for DI constant generation):
Replace gen_vsx_sign_extend_qi_si with
gen_vsx_sign_extend_v16qi_si.
(split for HSDI constant generation): Replace
gen_vsx_sign_extend_qi_di
with gen_vsx_sign_extend_v16qi_di and gen_vsx_sign_extend_qi_si
with gen_vsx_sign_extend_v16qi_si.
* config/rs6000/rs6000-builtins.def
(__builtin_altivec_vsignextsb2d):
Set bif-pattern to vsx_sign_extend_v16qi_v2di.
(__builtin_altivec_vsignextsb2w): Set bif-pattern to
vsx_sign_extend_v16qi_v4si.
(__builtin_altivec_visgnextsh2d): Set bif-pattern to
vsx_sign_extend_v8hi_v2di.
(__builtin_altivec_vsignextsh2w): Set bif-pattern to
vsx_sign_extend_v8hi_v4si.
(__builtin_altivec_vsignextsw2d): Set bif-pattern to
vsx_sign_extend_si_v2di.
(__builtin_altivec_vsignext): Set bif-pattern to
vsx_sign_extend_v2di_v1ti.
* config/rs6000/rs6000-builtin.cc (lxvrse_expand_builtin): Replace
gen_vsx_sign_extend_qi_v2di with gen_vsx_sign_extend_v16qi_v2di,
gen_vsx_sign_extend_hi_v2di with gen_vsx_sign_extend_v8hi_v2di and
gen_vsx_sign_extend_si_v2di with gen_vsx_sign_extend_v4si_v2di.

gcc/testsuite/
PR target/108812
* gcc.target/powerpc/p9-sign_extend-runnable.c: Set corresponding
expected vectors for Big Endian.
* gcc.target/powerpc/int_128bit-runnable.c: Likewise.

[Bug c++/109468] assign to default with three way comparison causes internal compiler error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
duplicate of bug 96689

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

[Bug c++/96689] Segmentation fault when defaulting operator<=> on enum er enum class

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||stevenxia990430 at gmail dot 
com

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

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #6 from Huaqi  ---
I think it might be introduced by this commit
https://github.com/gcc-mirror/gcc/commit/304c7d44a2212e6fd618587331cea2c266dc10bf,
since I tested this commit
https://github.com/gcc-mirror/gcc/commit/4872e46e080c6695dfe1f9dc9db26b4703bc348c
it works for win32 build. After this commit, it failed.

[Bug tree-optimization/101404] cond_removal_in_popcount_clz_ctz_pattern and factor_out_conditional_conversion do a similar transformation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Andrew Pinski  ---
First note it is called cond_removal_in_builtin_zero_pattern now.

And cond_removal_in_builtin_zero_pattern can be done almost in match so closing
this as won't fix. I have a set of patches that do that except for an extra
feeding statement which I will add support for next week.

[Bug tree-optimization/104339] Missing phiopt due to cast

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

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

--- Comment #2 from Andrew Pinski  ---
Note after r13-6834-g41ade3399bd1ec, the testcase in comment #0 works as the
cast in the first bb is unused otherwise,
Here is a better testcase:
```
int f(unsigned short y)
{
unsigned short t =y;
   int tt = y;
   y = -y;
   int yy = y;
   if (t) tt = yy;
   return tt;
}
```

[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:908d9c7e6ed4be95d39b7b01056dda365f379947

commit r12-9394-g908d9c7e6ed4be95d39b7b01056dda365f379947
Author: Michael Meissner 
Date:   Mon Apr 10 22:46:34 2023 -0400

Backport from master

2023-04-10  Michael Meissner  

gcc/

PR target/109067
* config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
(init_float128_ieee): Delete code to switch complex multiply and
divide
for long double.  Backport from master, 3/20/2023.
(complex_multiply_builtin_code): New helper function.
(complex_divide_builtin_code): Likewise.
(rs6000_mangle_decl_assembler_name): Add support for mangling the
name
of complex 128-bit multiply and divide built-in functions.

gcc/testsuite/

PR target/109067
* gcc.target/powerpc/divic3-1.c: New test.  Backport from master,
3/20/2023.
* gcc.target/powerpc/divic3-2.c: Likewise.
* gcc.target/powerpc/mulic3-1.c: Likewise.
* gcc.target/powerpc/mulic3-2.c: Likewise.

[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #2 from LIU Hao  ---
shouldn't this be classified as wrong code?

[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to LIU Hao from comment #2)
> shouldn't this be classified as wrong code?

It is at least a link-failure. Wrong code might be a strech here.

[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

  Known to fail||10.4.0, 9.5.0

--- Comment #4 from LIU Hao  ---
Manually reduced testcase:
(godbolt: https://gcc.godbolt.org/z/YsaoM78vM)

```
template
struct shallow
 {
   int len;
   constexpr shallow() : len(0) { }
  };

template
struct use_shallow
  {
   static constexpr shallow s_zstr = { };
   static_assert(s_zstr.len == 0);
  };

extern template struct shallow;
extern template struct use_shallow;

template struct shallow;
template struct use_shallow;
```

Constructor of `shallow` is lost. All GCC versions are affected.

[Bug target/54816] [avr] shift is better than widening mul

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

Wilhelm M  changed:

   What|Removed |Added

 CC||klaus.doldinger64@googlemai
   ||l.com

--- Comment #1 from Wilhelm M  ---
The following code has the same problem:

#include 
#include 

uint16_t b;
uint8_t a;

template
B Mul(const A a, const B b) {
static constexpr uint8_t shift = (sizeof(B) - sizeof(A)) * 8;
return static_cast(b >> shift) * a ;
}

int main() {
return Mul(a, b);
}

with 4.6.4. it produces:

main:
lds r24,a
lds r25,b+1
mul r25,r24
movw r24,r0
clr r1
ret

with actual 12.2 it produces missing optimization:

main:
lds r24,b+1
ldi r25,0
lds r18,a
movw r20,r24
mul r18,r20
movw r24,r0
mul r18,r21
add r25,r0
clr __zero_reg__
ret

Interistingly the follwing code produces optimal code also with 12.2:

template
B MulX(const A a, const B b) {
static const uint8_t shift = (sizeof(B) - sizeof(A)) * 8;
return static_cast((b >> shift) + 1) * a ;
}

[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #5 from LIU Hao  ---
Additional information:

I tried splitting the two class templates into two separate .cpp files, so the
explicit instantiation of `basic_shallow_string` should not be subject to
the instantiation of `basic_cow_string`. This made GCC emit the
constructor correctly (checked by examining assembly), but still failed to the
very same undefined reference.

At the moment, a temporary workaround is to mark the constructor of
`basic_shallow_string` as `always_inline`. This works for GCC 10, 11 and 12.
Haven't checked GCC 9 as it's no longer available from APT sources of my
current machine.

[Bug tree-optimization/109469] New: [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Bug ID: 109469
   Summary: [13 regression] ICE: internal compiler error:
verify_flow_info failed (error: returns_twice call is
not first in basic block 2)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Hit this when building xdvik-22.87.06 with 13.0.1 20230409 w/ checking.

```
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.  -I./gui -DPS_GS 
-I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include   -Wimplicit -Wreturn-type -O2
-pipe -march=native -fdiagnostics-color=always -frecord-gcc-switches
-Wreturn-type  -ggdb3 -Werror=implicit-function-declaration
-Werror=implicit-int -Wformat -Waddress -Warray-bounds -Wfree-nonheap-object
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Wint-conversion -Wint-to-pointer-cast -Wmain -Wnonnull -Wodr -Wparentheses
-Wreturn-type -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstring-compare
-Wuninitialized -Wunused-value -Wvarargs -c -o util.o util.c
util.c: In function ‘fork_process’:
util.c:988:1: error: returns_twice call is not first in basic block 25
  988 | fork_process(const char *proc_name, Boolean redirect_stdout,
  | ^~~~
pid_96 = vfork ();
during GIMPLE pass: slp
util.c:988:1: internal compiler error: verify_flow_info failed
0x7aa668 verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/cfghooks.cc:285
0x151e50d execute_function_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:2110
0x1485fd1 do_per_function
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:1694
0x1485fd1 execute_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:2152
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #1 from Sam James  ---
Created attachment 54826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54826&action=edit
util.i.orig (unreduced)

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #2 from Sam James  ---
Created attachment 54827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54827&action=edit
util.i (reduced)

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #3 from Sam James  ---
Created attachment 54828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54828&action=edit
util2.i (reduced further, but check)

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #4 from Sam James  ---
This might be a dupe of PR108783 or PR109410 but I had to try reduce it to be
relatively sure, so may as well file it here for completeness.

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #5 from Sam James  ---
(In reply to Sam James from comment #4)
> This might be a dupe of PR108783 or PR109410 but I had to try reduce it to
> be relatively sure, so may as well file it here for completeness.

I thought it was interesting in this case that it happens even without a
definition of foo which was the main motivation for bothering here.