[Bug c++/104177] coroutine frame is not being allocated with the correct alignment

[davidledger at live dot com.au via Gcc-bugs]

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

--- Comment #16 from David Ledger  ---
The above example produces the xmm instruction on a clearly misaligned value.

I was searching the assembly using:
```SH
#!/bin/bash

g++-11 main.cpp -std=c++2a -O3 -march=native -S
grep -E "vmovdqu\s%xmm0,\s3\+_ZL6buffer" main.s
exit $?
```

[Bug c++/104177] coroutine frame is not being allocated with the correct alignment

[davidledger at live dot com.au via Gcc-bugs]

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

David Ledger  changed:

   What|Removed |Added

 CC||davidledger at live dot com.au

--- Comment #15 from David Ledger  ---
This is a complete minimum reproduction, just to aid Iain Sandoe:

```CPP
#include 
using namespace std;
#include 
static char buffer[4];
template  struct b {
  struct promise_type {
void *operator new(size_t) { return [3]; }
void get_return_object();
void unhandled_exception();
suspend_always initial_suspend();
suspend_always final_suspend() noexcept;
suspend_always yield_value(a);
  };
};
b c() {
  max_align_t buffer[1];
  for (auto d : buffer)
co_yield 
}
```

[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to pefoley2 from comment #8)
> Note that this appears to be affecting the gcc source tree.
> 
> Attempting a build with --with-build-config=bootstrap-lto --enable-werror
> errors out with:
 Yes but lto bootstrap disables werror on purpose so you adding --enable-werror
is not supported.

[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto

[pefoley2 at pefoley dot com via Gcc-bugs]

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

pefoley2 at pefoley dot com changed:

   What|Removed |Added

 CC||pefoley2 at pefoley dot com

--- Comment #8 from pefoley2 at pefoley dot com ---
Note that this appears to be affecting the gcc source tree.

Attempting a build with --with-build-config=bootstrap-lto --enable-werror
errors out with:
In function ‘release’,
inlined from ‘release’ at ../../gcc/vec.h:1915:0,
inlined from ‘__dt_base ’ at ../../gcc/vec.h:1574:0,
inlined from ‘visit_reference_op_call.isra’ at
../../gcc/tree-ssa-sccvn.cc:5562:0:
../../gcc/vec.h:316: error: ‘free’ called on unallocated object ‘accesses’
[-Werror=free-nonheap-object]
  316 |   ::free (v);
  |
../../gcc/tree-ssa-sccvn.cc: In function ‘visit_reference_op_call.isra’:
../../gcc/tree-ssa-sccvn.cc:5457: note: declared here
 5457 |   auto_vec accesses;
  |
lto1: all warnings being treated as errors

Due to this pragma being ignored:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.h;h=a536b68732ddcb9ed7b223803308b3e079a53969;hb=HEAD#l300

[Bug c++/108488] segfault with -fmodules-ts and class-scope friend declaration first in uninstantiated template

[wendellcraigbaker at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Wendell Baker  ---
Created attachment 54324
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54324=edit
shell script and C++ to demonstrate with  and  in
combination

This happens in real life with the confluence of  and  as
the accompanying exhibition highlights.

Re: About ' * ' not recognized

[naoki ueda via Gcc-bugs]

Ok, I see.

2023年1月21日(土) 10:12 Andrew Pinski :

> On Fri, Jan 20, 2023 at 5:05 PM naoki ueda via Gcc-bugs
>  wrote:
> >
> > When I tried to execute the attached file mycalc.c with a command line
> > argument, it could not be executed normally only in the case of '*'.
> > '+', '-' and '/' can be executed normally, but the compiler cannot
> > execute '*' normally. Isn't this a gcc bug?
>
> First off this email list is really for automated messages from gcc's
> bugzilla rather than from users reporting issues.
>
> >
> >
> > ~/Clearning$ ./mycalc 20 * 30
>
> Oh * here is being handled by the shell you are using and being
> expanded as all the files in the current working directory. This has
> nothing to do with GCC really.
> You can use quotes around the * to force the shell not expanding it
> such as this:
> ./mycalc 20 '*' 30
>
> or you use \ to force the shell not to expand what comes after the * like
> this:
> ./mycalc 20 \* 30
>
> Thanks,
> Andrew Pinski
>
> > 用法:mycalc 数値1 演算子 数値2
>

Re: About ' * ' not recognized

[Andrew Pinski via Gcc-bugs]

On Fri, Jan 20, 2023 at 5:05 PM naoki ueda via Gcc-bugs
 wrote:
>
> When I tried to execute the attached file mycalc.c with a command line
> argument, it could not be executed normally only in the case of '*'.
> '+', '-' and '/' can be executed normally, but the compiler cannot
> execute '*' normally. Isn't this a gcc bug?

First off this email list is really for automated messages from gcc's
bugzilla rather than from users reporting issues.

>
>
> ~/Clearning$ ./mycalc 20 * 30

Oh * here is being handled by the shell you are using and being
expanded as all the files in the current working directory. This has
nothing to do with GCC really.
You can use quotes around the * to force the shell not expanding it
such as this:
./mycalc 20 '*' 30

or you use \ to force the shell not to expand what comes after the * like this:
./mycalc 20 \* 30

Thanks,
Andrew Pinski

> 用法:mycalc 数値1 演算子 数値2

About ' * ' not recognized

[naoki ueda via Gcc-bugs]

When I tried to execute the attached file mycalc.c with a command line
argument, it could not be executed normally only in the case of '*'.
'+', '-' and '/' can be executed normally, but the compiler cannot
execute '*' normally. Isn't this a gcc bug?


~/Clearning$ ./mycalc 20 * 30
用法:mycalc 数値1 演算子 数値2
#include 
#include  // for exit()
#include  // for strcpy() strlen()
int main(int argc, char *argv[])
{
 double d1, d2,ans;
 char ope[80];
 
 if (argc != 4) {
  printf("用法:mycalc 数値1 演算子 数値2\n");
  exit(1);
 }
 d1 = atof(argv[1]);
 d2 = atof(argv[3]);
 strcpy(ope,argv[2]);
 if (strlen(ope) != 1) {
  printf("演算子が1文字でない\n");
  exit(1);
 }
 switch (ope[0]) {
 case '+':
  ans = d1 + d2;
  break;
 case '-':
  ans = d1 - d2;
  break;
 case '*':
  ans = d1 * d2;
  break;
 case '/':
  if (d2 == 0.0) ans = 0.0;// 0除算対応
  else ans = d1 / d2;
  break;
 default:
  printf("演算子が違っている\n");
  exit(1);
 }
 printf("%f\n",ans);
}

[Bug modula2/108136] Modula2 meets cppcheck

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #3 from Gaius Mulley  ---
Created attachment 54323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54323=edit
Fix for the style bugs mentioned in the PR

Here is a patch committed, pushed and bootstrap tested for the style category
bugs (para 2).

[Bug c++/108488] segfault with -fmodules-ts and class-scope friend declaration first in uninstantiated template

[wendellcraigbaker at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Wendell Baker  ---
Created attachment 54322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54322=edit
exhibited output of run.sh showing the segfault with and without -fmodules-ts

[Bug c++/108488] segfault with -fmodules-ts and class-scope friend declaration first in uninstantiated template

[wendellcraigbaker at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Wendell Baker  ---
Created attachment 54321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54321=edit
run cc1plus to echigit the problem

[Bug c++/108488] New: segfault with -fmodules-ts and class-scope friend declaration first in uninstantiated template

[wendellcraigbaker at gmail dot com via Gcc-bugs]

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

Bug ID: 108488
   Summary: segfault with -fmodules-ts and class-scope friend
declaration first in uninstantiated template
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wendellcraigbaker at gmail dot com
  Target Milestone: ---

Created attachment 54320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54320=edit
Complete C++ to exhibit the segfault

The sequence of declarations causes a segfault in gcc 12.2.1 under -fmodules-ts


template  class k;
...more...
struct d {
  ...
  void ck(k const &);
  void ck(int);
};
...more...
template  class k {
  template  friend class ca;
};
...more...
  auto e::operator+=(e &) -> e & {
for (auto bt : cl)
  ck(bt);
return *this;
  }
...more...
template  class ca {};
ca d;



It is specific to -fmodules-ts
It is specific to the declaration of friend class ca introduced at class scope.

The exhibition and script show details.


The compiler instance here stock-delivered Fedora 37 GCC 12.2.1 but the problem
exists in older versions and also on trunk.

https://godbolt.org/z/GGP4dxnjY

https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:1,endLineNumber:34,positionColumn:1,positionLineNumber:34,selectionStartColumn:1,selectionStartLineNumber:34,startColumn:1,startLineNumber:34),source:'class+e%3B%0A%0Atemplate+%3Ctypename%3E+class+k%3B%0A%0Astruct+l+%7B%0A++int+operator*()%3B%0A++void+operator%2B%2B()%3B%0A++friend+bool+operator%3D%3D(l,+l)%3B%0A%7D%3B%0Astruct+d+%7B%0A++l+begin()%3B%0A++l+end()%3B%0A++void+ck(k%3Cint%3E+const+%26)%3B%0A++void+ck(int)%3B%0A%7D%3B%0A%0A%0Aclass+e+:+d+%7B%0A++auto+operator%2B%3D(e+%26%26)+-%3E+e+%26%3B%0A%7D%3B%0Atemplate+%3Ctypename%3E+class+k+%7B%0A++template+%3Ctypename%3E+friend+class+ca%3B%0A%7D%3B%0A%0A++auto+e::operator%2B%3D(e+%26%26cl)+-%3E+e+%26+%7B%0Afor+(auto+bt+:+cl)%0A++ck(bt)%3B%0Areturn+*this%3B%0A++%7D%0A%0A%0Atemplate+%3Ctypename%3E+class+ca+%7B%7D%3B%0A%0Aca%3Cint%3E+d%3B%0A'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:27.194244604316548,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'x86-64+clang+3.5',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+gcc+(trunk)+(Compiler+%231)',t:'0')),header:(),k:47.805755395683455,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:gsnapshot,deviceViewOpen:'1',filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'-std%3Dc%2B%2B23+-fmodules-ts',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x86-64+gcc+(trunk)+(Editor+%231)',t:'0')),k:25,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4


On goldbolt.org, against trunk, the error messaging is:

'
tree check: expected class 'type', have 'declaration' (type_decl) in
get_originating_module_decl, at cp/module.cc:18634
   32 | template  class ca {};
  |   ^~
0x23aef7e internal_error(char const*, ...)
???:0
0x939ce7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xbc4c9b get_originating_module(tree_node*, bool)
???:0
0x23ce58c pp_format(pretty_printer*, text_info*)
???:0
0x23cf79d pp_format_verbatim(pretty_printer*, text_info*)
???:0
0x23cf885 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x23ad925 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x23aef7e internal_error(char const*, ...)
???:0
0x939ce7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xbc4c9b get_originating_module(tree_node*, bool)
???:0
0xb6f28c decl_as_string(tree_node*, int)
???:0
0xb6f2c3 decl_as_dwarf_string(tree_node*, int)
???:0
0x1220e3c rest_of_type_compilation(tree_node*, int)
???:0
0xabf59e finish_struct_1(tree_node*)
???:0
0xca51c0 instantiate_class_template(tree_node*)
???:0
0xb258f3 start_decl_1(tree_node*, bool)
???:0
0xb48077 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0xc4e137 c_parse_file()
???:0
0xd89ad9 c_common_parse_file()
???:0
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.
Compiler returned: 1

[Bug rtl-optimization/108487] New: ~20-30x slowdown in populating std::vector from std::ranges::iota_view

[Mark_B53 at yahoo dot com via Gcc-bugs]

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

Bug ID: 108487
   Summary: ~20-30x slowdown in populating std::vector from
std::ranges::iota_view
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Mark_B53 at yahoo dot com
  Target Milestone: ---

Using -std=c++20 -O3, comparing gcc 12.2 vs. gcc 10.3:
 * fn2 is 20-30x slower on gcc 12.2 (i.e. 2000-3000% more) 
 * fn1 is ~20% slower on gcc 12.2 

This test was run on an 52 core Intel Xeon Gold 6278C CPU.  Tests on
www.godbolt.org directionally align with these findings.  It seems the slowdown
was introduced in 10.4 & 11.1.  The trunk has identical performance to 12.2.

#include 
#include 
#include 
#include 

__attribute__((noinline)) std::vector fn1(int n)
{
auto v = std::vector(n);
for(int i = 0; i != n; ++i)
v[i] = i;
return v;
}

__attribute__((noinline)) std::vector fn2(int n)
{
auto rng = std::ranges::iota_view{0, n};
return std::vector{rng.begin(), rng.end()};
}

int main() {
int n = 100'000;
int times = 100'000;

auto t0 = std::clock();
for (int i = 0; i < times; ++i)
fn1(n);
auto t1 = std::clock();
for (int i = 0; i < times; ++i)
fn2(n);
auto t2 = std::clock();
std::cout << t1 - t0 << '\n';
std::cout << t2 - t1 << '\n';
return 0;
}

P.S. 20% slowdown for a common vector population is still significant IMO.  I
am not sure that qualifies as a bug.  I did not file one on account of the
'fn1' slowdown.

[Bug c++/57919] [C++11] Alias templates cause partial specialization to erroneously fail

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

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

--- Comment #1 from Andrew Pinski  ---
MSVC also rejects this code for the same reason as GCC:
(32): error C2752: 'foo<1,1,sequence<>>': more than one partial
specialization matches the template argument list
(19): note: could be 'foo...>>'
(25): note: or   'foo...>>'
(32): error C2027: use of undefined type 'foo<1,1,sequence<>>'
(32): note: see declaration of 'foo<1,1,sequence<>>'
(32): error C2061: syntax error: identifier 'type'

[Bug c++/108486] New: explicit specialization of alias templates error message should be improved

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

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

Bug ID: 108486
   Summary: explicit specialization of alias templates error
message should be improved
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
template
struct myinternal_int;
template using myinttype = myinternal_int;
template<> using myinttype<32> = unsigned int;
```
GCC gives:
```
:4:12: error: expected unqualified-id before 'using'
4 | template<> using myinttype<32> = unsigned int;
  |^
```
Which is correct though not very useful for an user.
clang gives a much better error message:
```
:4:1: error: explicit specialization of alias templates is not
permitted
template<> using myinttype<32> = unsigned int;
^~
```

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
If you don't want to see the warning at all when using the macro, workaround is
easy, just use (0+sizeof(x)/sizeof(*(x)) and be done with it.
If you want a warning if you use it say on int * type and no warning but 0
result if you use it on cv void * (note, the original
one only works with void * and not with const void * etc.), you could use e.g.
following (verified both with gcc and clang),
of course if you don't care about const void * etc., you can simplify it a
little bit.

//#define ARRAY_SIZE_MAYBENULL(x)  ( __builtin_types_compatible_p(typeof(x),
void*) ? 0 : (sizeof(x)/sizeof(*(x))) )
//#define ARRAY_SIZE_MAYBENULL(x) _Generic((x), void*: 0, const void*: 0,
volatile void*: 0, const volatile void*: 0, default:
(0+sizeof(x))/sizeof(*(x)))
//#define ARRAY_SIZE_MAYBENULL(x) _Generic((x), void*: 0, const void*: 0,
volatile void*: 0, const volatile void*: 0, default: sizeof(x)/sizeof(*(x)))
#define ARRAY_SIZE_MAYBENULL(x) _Generic((x), void*: 0, const void*: 0,
volatile void*: 0, const volatile void*: 0, default: \
  sizeof(x)/sizeof(_Generic((x), void*: (x), const void*: (x), volatile void*:
(x), const volatile void*: (x), default:*(x

void
foo (int *p)
{
  int a[10];
  p[0] = ARRAY_SIZE_MAYBENULL (a);
  p[1] = ARRAY_SIZE_MAYBENULL ((void *) 0);
  p[2] = ARRAY_SIZE_MAYBENULL ((const void *) 0);
  p[3] = ARRAY_SIZE_MAYBENULL ((volatile void *) 0);
  p[4] = ARRAY_SIZE_MAYBENULL ((void *restrict) 0);
  p[5] = ARRAY_SIZE_MAYBENULL ((const volatile void *) 0);
  p[6] = ARRAY_SIZE_MAYBENULL (p);
}

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #4 from Andrew Pinski  ---
In GCC 12, IFN_LOOP_DIST_ALIAS is removed during vectorization but on the trunk
it is still there.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

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

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

--- Comment #3 from Andrew Pinski  ---
What is interesting is if we look at the IR:

  _41 = .LOOP_DIST_ALIAS (3, _40);
  if (_41 != 0)
goto ; [90.00%]
  else
goto ; [10.00%]

   [local count: 430033601]:
  _29 = *_4;
  _30 = (char) _29;
  _31 = _7 & _30;
  goto ; [100.00%]

   [local count: 47781512]:
  _47 = *_4;
  _48 = (char) _47;
  _49 = _7 & _48;

   [local count: 118111600]:
  # _46 = PHI <_49(4), _31(3)>

That code is the same on both edges even though not noticed being the same.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-20
   Target Milestone|--- |13.0
Summary|ice in  |[13 Regression] ice in
   |expand_LOOP_DIST_ALIAS, at  |expand_LOOP_DIST_ALIAS with
   |internal-fn.cc:2737 |-O3
   ||-ftrivial-auto-var-init=zer
   ||o
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed. A regression from GCC 12.

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

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

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #1)
> I doubt this will be changed anytime soon, see PR 4210 for the history on
> why.

That PR is about an UB case though.  In this case the code is perfectly well
defined (just IB).

The warning code here sees a sizeof divided by a sizeof and wants to warn for
it as being maybe wrong, although it would be pretty easy to see it isn't.

[Bug modula2/108485] New: CppArg is broken for whitespaces

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

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

Bug ID: 108485
   Summary: CppArg is broken for whitespaces
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Just quickly looking into CppArg and I noticed the arguments are not quoted or
otherwise fixed up when doing ConCatChar.
This means if you had a whitespace in one of the options, the options become
two because it gets reinterrupted.

The answer is to always just pass around an array of arguments and never do
concatting like this but this is a huge change ...

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

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

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

--- Comment #3 from Michael Karcher  ---
Thanks for the pointer to #4210. Note that 4210 is slightly different, though.
In that report, the condition and the warnable expression are in different
statements, and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210#c13
explicitly mentioned using a ternary expression to enable gcc to see the
deadness of the code, using a flag called "skip_evaluation".

This PR concerns a case that uses ?:, so I wonder whether skip_evaluation still
exists, and could be used to gate the sizeof-pointer-div warning.

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

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

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

--- Comment #2 from Segher Boessenkool  ---
The testcase needs a NULL defined as  (void *)0  .

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2023-01-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
I doubt this will be changed anytime soon, see PR 4210 for the history on why.

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

--- Comment #22 from Joseph S. Myers  ---
The fix introduced a regression building glibc for ia64-linux-gnu, see bug
108484.

[Bug target/108484] New: [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148

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

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

Bug ID: 108484
   Summary: [13 Regression] ICE building glibc for ia64 in
cselib_subst_to_values, at cselib.cc:2148
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
Target: ia64*-*-*

Created attachment 54319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54319=edit
preprocessed source

Compile the attached file (from glibc) with -g -O2 for ia64-linux-gnu. This
produces the following ICE:

during RTL pass: mach
In file included from ../sysdeps/ia64/unwind-resume.c:18:
../sysdeps/generic/unwind-resume.c: In function '_Unwind_Resume':
../sysdeps/generic/unwind-resume.c:38:1: internal compiler error: in
cselib_subst_to_values, at cselib.cc:2148
0x5fd409 cselib_subst_to_values(rtx_def*, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2148
0x98c873 cselib_subst_to_values(rtx_def*, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2193
0x98f761 cselib_subst_to_values_from_insn(rtx_def*, machine_mode, rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2264
0x18172aa add_insn_mem_dependence
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:1741
0x181b230 sched_analyze_2
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2688
0x181b267 sched_analyze_2
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2806
0x181b9eb sched_analyze_insn
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2960
0x181ddb0 deps_analyze_insn(deps_desc*, rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:3683
0x181e40e sched_analyze(deps_desc*, rtx_insn*, rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:3836
0x1821870 schedule_ebb(rtx_insn*, rtx_insn*, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-ebb.cc:505
0x1821da2 schedule_ebbs()
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-ebb.cc:655
0x11b3346 ia64_reorg
/scratch/jmyers/glibc/many13/src/gcc/gcc/config/ia64/ia64.cc:9862
0xdb527d execute
/scratch/jmyers/glibc/many13/src/gcc/gcc/reorg.cc:3927
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.

Introduced by g:3c99493bf39a7fef9213e6f5af94b78bb15fcfdc

commit 3c99493bf39a7fef9213e6f5af94b78bb15fcfdc
Author: Alexandre Oliva 
Date:   Thu Jan 19 01:09:15 2023 -0300

[PR106746] drop cselib addr lookup in debug insn mem

The testcase used to get scheduled differently depending on the
presence of debug insns with MEMs.  It's not clear to me why those
MEMs affected scheduling, but the cselib pre-canonicalization of the
MEM address is not used at all when analyzing debug insns, so the
memory allocation and lookup are pure waste.  Somehow, avoiding that
waste fixes the problem, or makes it go latent.


for  gcc/ChangeLog

PR debug/106746
* sched-deps.cc (sched_analyze_2): Skip cselib address lookup
within debug insns.

for  gcc/testsuite/ChangeLog

PR debug/106746
* gcc.target/i386/pr106746.c: New.

[Bug rtl-optimization/108388] LRA generates RTL that violates constraints

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

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

--- Comment #1 from Vladimir Makarov  ---
Thank you for reporting this.  I've been working on this PR.  I believe the PR
reveals the problem not only for PDP11.  I guess the same can happen for some
other targets.

I hope the patch will be ready the next week as it requires a good testing for
several major targets.  Unfortunately, practically any change in LRA might have
unexpected effect on other targets.

[Bug c/108483] New: gcc warns about suspicious constructs for unevaluted ?: operand

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

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

Bug ID: 108483
   Summary: gcc warns about suspicious constructs for unevaluted
?: operand
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
  Target Milestone: ---

Created attachment 54318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54318=edit
minimal example

A well-known construct to determine array sizes at compile time is

#define ARRAY_SIZE(x) (sizeof(x)/sizeof(*(x)))

gcc helpfully warns for dangerous mis-use of this macro, as it only works with
real arrays, not with pointer, for example. Assuming NULL is defined as
((void*)0), ARRAY_SIZE(NULL) yields a valid C expression, as long as we use the
gcc extension that sizeof(void) equals one:

ARRAY_SIZE(NULL) is expanded to essentially sizeof(void*)/sizeof(void)

which yields 8 on usual 64-bit systems and 4 on usual 32-bit system. While this
expression is valid, the result of this expression is likely not what the
programmer intended, so the gcc warning "division ‘sizeof (void *) / sizeof
(void)’ does not compute the number of array elements" is warranted.

The Linux kernel contains a macro essentially being

#define ARRAY_SIZE_MAYBENULL(x)  ( __builtin_types_compatible_p(typeof(x),
void*) ? 0 : (sizeof(x)/sizeof(*x)) )

which is intended to be invocable using actual array operands (returning the
array size) or the compile-time constant NULL (returning zero).

gcc correctly evaluates ARRAY_SIZE_MAYBENULL(NULL) to zero, but emits about the
suspicious pattern in the third operand of the ternary operator. This is not
helpful for the programmer, and breaks builds using -Wall -Werror.

This is a feature request to omit warnings about dubious constructs like this
if it can be statically determined that they are not evaluated.

The example in the attachment compiles correctly and initializes x to 1, but
emits the spurious warning about the unevaluated sizeof pattern.

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

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

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

--- Comment #2 from Tobias Burnus  ---
Interestingly, it is resolved twice. First for:

(gdb) p gfc_debug_expr(e)
maxloc[((p:a) (mask = p:l))]

via
resolve_all_program_units → gfc_resolve → gfc_resolve → resolve_codes →
gfc_resolve_code → gfc_resolve_blocks → gfc_resolve_code → gfc_resolve_expr

And then via:
 ... → resolve_omp_atomic → gfc_resolve_expr

The problem is that in the latter case, the 'e' is now:

  maxloc[((p:a(FULL)) (mask = p:l) (.false.))]

and the unprefixed .false. seems to cause the problems.

The intrinsic uses:
   RESULT = MAXLOC(ARRAY, DIM [, MASK] [,KIND] [,BACK])
   RESULT = MAXLOC(ARRAY [, MASK] [,KIND] [,BACK])

During the first call to check_specific,

  maxloc[((p:a(FULL)) (mask = p:l))]

is turned into

  maxloc[((p:a(FULL)) ((arg not-present)) (mask = p:l) ((arg not-present))
((arg not-present)))]

via

4774  if (!sort_actual (specific->name, ap, specific->formal,
>where))

The null-args are later removed via 'remove_nullargs (ap);'

 * * *

Thus, it looks as if resolving the RHS expression twice is wrong.

[Bug modula2/108135] Modula2 meets clang

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
Closing as bugfix has been git pushed.  Thanks for reporting the clang warnings
and bug.

[Bug modula2/108135] Modula2 meets clang

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Verified these bugs and have git committed/pushed a patch.

[Bug middle-end/108435] [13 Regression] ICE in as_a, at is-a.h:242 since r13-142-g705bcedf6eae2d7c

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

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

Tobias Burnus  changed:

   What|Removed |Added

  Component|fortran |middle-end
 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #2)
> Possibly dup of PR107424 or at least related to that.

I don't think so.  In any case, it shows also up for C
if one uses the nested-functions extension:


int
main ()
{
  int i, j;
  void bar()
  {
#pragma omp for simd collapse(2)
 for (i = 1; i <= 16; i++)
   for (j = 1; j <= 16; j++)  /* Note: *no* non-rectangular loop nest.  */
 ;
  }
  bar ();
  return 0;
}


(I get an ICE since GCC 8 and none with GCC 7; thus, I might be a regression,
but I have not checked in depth.)

[Bug fortran/108382] [12/13 Regression] Incorrect parsing when acc and omp coexist and -fopenmp -fopenacc is used.

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
   Last reconfirmed||2023-01-20
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.4
Summary|Incorrect parsing when acc  |[12/13 Regression]
   |and omp coexist and |Incorrect parsing when acc
   |-fopenmp -fopenacc is used. |and omp coexist and
   ||-fopenmp -fopenacc is used.
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
It seems as if for

  !$acc enter &
  !$acc   data
  !$omp flush &
  !$omp   RELEASE

a flag is wrong after parsing the second line; I think either the
'openacc_flag' needs to be (re)set to 0 or continue_flag needs to be set to 0.

(likewise for swapping omp and acc lines) 

Possibly be caused by the following commit as it works with GCC 11 but fails
with GCC 12:
  r12-1216-g4facf2bf5b7b32f444da864306b5c11e14c15bcf

[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures

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

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

--- Comment #24 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #23)
> (In reply to Jakub Jelinek from comment #21)
> > (In reply to Andrew Macleod from comment #19)
> > > Created attachment 54313 [details]
> > > better patch
> > > 
> > > A more consistent approach.. rather than directly call 
> > > relation_intersect()
> > > from multiple places, add the floating point fix to
> > > value_relation::intersect and always go through that.
> > > 
> > > This will cause the normal oracle and the path oracle to both make the
> > > previous adjustment to intersect for floating point operations.   
> > > untested,
> > > running tests now.
> > 
> > I thought (unless somebody proves otherwise) that relation_intersect is
> > actually just fine, the only thing that is incorrect (IMHO) for floating
> > point with NaNs are the
> 
> 
> I thought intersection was wrong for x <= y intersect x >= y because it
> produces x == y?

A floating point comparison when NANs is possible has 4 possible outcomes:
(1) x < y
(2) x == y
(3) x > y
(4) isnan (x) || isnan (y)
(unlike say integral which has only the 3 options).
Now, each of the C or tree comparisons can be expressed in a table for which of
those 4 outcomes it returns true.
Say:
x < y (1)
x <= y(1) || (2)
x > y (3)
x >= y(2) || (3)
x == y(2)
x != y(1) || (3) || (4)
VARYING   (1) || (2) || (3) || (4)
UNDEFINED
etc.
x <= y && x >= y from the above table is ((1) || (2)) && ((2) || (3)) aka (2)
aka x == y.
While x <= y || x >= y is (1) || (2) || (3) which is something we don't have a
VREL_*
name for (it is ORDERED_EXPR in trees).
Similarly x < y || x > y is (1) || (3) which we don't have either but is
LTGT_EXPR on trees.
For the integral cases when only (1), (2) and (3) are possible, all we need is
8
relations, LT, LE, GT, GE, EQ, NE, TRUE (VARYING) and FALSE (UNDEFINED) are
needed,
but for complete coverage of the 4 possibilities we need 16 (32 if it is also
about whether qNaN operand(s) raise exceptions or not).

E.g. AVX VCMP instruction has those 32 possibilities:

Predicate  imm8  Description A > B A < B A = B Unordered Signal on
qNAN
EQ_OQ (EQ)   0H  Equal (ordered, non-signaling)   F F T
F N
LT_OS (LT)   1H  Less-than (ordered, signaling)   F T F
F Y
LE_OS (LE)   2H  Less-than-or-equal (ordered, signaling)  F T T
F Y
UNORD_Q (UNORD)  3H  Unordered (non-signaling)F F F
T N
NEQ_UQ (NEQ) 4H  Not-equal (unordered, non-signaling) T T F
T N
NLT_US (NLT) 5H  Not-less-than (unordered, signaling) T F T
T Y
NLE_US (NLE) 6H  Not-less-than-or-equal (unordered, signaling)T F F
T Y
ORD_Q (ORD)  7H  Ordered (non-signaling)  T T T
F N
EQ_UQ8H  Equal (unordered, non-signaling) F F T
T N
NGE_US (NGE) 9H  Not-greater-than-or-equal (unordered, signaling) F T F
T Y
NGT_US (NGT) AH  Not-greater-than (unordered, signaling)  F T T
T Y
FALSE_OQ (FALSE) BH  False (ordered, non-signaling)   F F F
F N
NEQ_OQ   CH  Not-equal (ordered, non-signaling)   T T F
F N
GE_OS (GE)   DH  Greater-than-or-equal (ordered, signaling)   T F T
F Y
GT_OS (GT)   EH  Greater-than (ordered, signaling)T F F
F Y
TRUE_UQ(TRUE)FH  True (unordered, non-signaling)  T T T
T N
EQ_OS   10H  Equal (ordered, signaling)   F F T
F Y
LT_OQ   11H  Less-than (ordered, non-signaling)   F T F
F N
LE_OQ   12H  Less-than-or-equal (ordered, non-signaling)  F T T
F N
UNORD_S 13H  Unordered (signaling)F F F
T Y
NEQ_US  14H  Not-equal (unordered, signaling) T T F
T Y
NLT_UQ  15H  Not-less-than (unordered, non-signaling) T F T
T N
NLE_UQ  16H  Not-less-than-or-equal (unordered, non-signaling)T F F
T N
ORD_S   17H  Ordered (signaling)  T T T
F Y
EQ_US   18H  Equal (unordered, signaling) F F T
T Y
NGE_UQ  19H  Not-greater-than-or-equal (unordered, non-signaling) F T F
T N
NGT_UQ  1AH  Not-greater-than (unordered, non-signaling)  F T T
T N
FALSE_OS1BH  False (ordered, signaling)   F F F
F Y
NEQ_OS  1CH  Not-equal (ordered, signaling)   T T F
F Y
GE_OQ   1DH  Greater-than-or-equal (ordered, non-signaling)   T F T
F N
GT_OQ   1EH  Greater-than (ordered, non-signaling)T F F
F N
TRUE_US 1FH  True (unordered, signaling)  T T T
T Y

I think for VREL_*, we could use just the 16, but for the time being need just
some
VREL_* value to 

[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
from the standard:

A structure or union shall not contain a member with incomplete or function
type (hence, a structure shall not contain an instance of itself, but may
contain a pointer to an instance of itself), except that the last member of a
structure with more than one named member may have incomplete array type; such
a structure (and any union containing, possibly recursively, a member that is
such a structure) shall not be a member of a structure or an element of an
array.

as a result, if you add -Wpedantic to the compilation line:

[opc@qinzhao-ol8u3-x86 101832]$ sh t
/home/opc/Install/latest-d/bin/gcc -O1 -Wpedantic t.c
t.c:30:18: warning: invalid use of structure with flexible array member
[-Wpedantic]
   30 | struct nlmsg msg;
  |  ^~~


However, looks like that GCC extension allow such usage, but I am not sure
whether there is any documentation on such extension?

[Bug c/108482] ice in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2737

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced code seems to be:

int g_30, g_261, g_263, func_1___trans_tmp_17;
int **g_120;
int *g_530;
void func_1() {
  int *l_29 = _30;
  *l_29 = 1;
  g_263 = 0;
  for (; g_263 <= 1; g_263 += 1) {
g_530 = 0;
if (*l_29) {
  char *l_1694 = _261;
  *l_1694 &= **g_120;
} else
  *l_29 ^= func_1___trans_tmp_17;
  }
}

This case came from about 20,000 executions of csmith.

[Bug c/108482] New: ice in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2737

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108482
   Summary: ice in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2737
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54317=edit
C source code

For the attached C code, compiled as follows:

$ /home/dcb36/gcc/results/bin/gcc  -c -O3 -w -ftrivial-auto-var-init=zero 
bug874.c
during RTL pass: expand
testFile.21840.c: In function ‘func_1.isra’:
testFile.21840.c:112:16: internal compiler error: in expand_LOOP_DIST_ALIAS, at
internal-fn.cc:2737
0xb17ff4 expand_LOOP_DIST_ALIAS(internal_fn, gcall*)
../../trunk.d1/gcc/internal-fn.cc:2737
0x86d30e expand_call_stmt(gcall*)
../../trunk.d1/gcc/cfgexpand.cc:2737
0x86d30e expand_gimple_stmt_1(gimple*)
../../trunk.d1/gcc/cfgexpand.cc:3880
0x86d30e expand_gimple_stmt(gimple*)
../../trunk.d1/gcc/cfgexpand.cc:4044

The bug seems to exist since sometime before g:02c031088ac0bbf7,
dated 20221220.

I have a reduction running.

[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #23 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #21)
> (In reply to Andrew Macleod from comment #19)
> > Created attachment 54313 [details]
> > better patch
> > 
> > A more consistent approach.. rather than directly call relation_intersect()
> > from multiple places, add the floating point fix to
> > value_relation::intersect and always go through that.
> > 
> > This will cause the normal oracle and the path oracle to both make the
> > previous adjustment to intersect for floating point operations.   untested,
> > running tests now.
> 
> I thought (unless somebody proves otherwise) that relation_intersect is
> actually just fine, the only thing that is incorrect (IMHO) for floating
> point with NaNs are the


I thought intersection was wrong for x <= y intersect x >= y because it
produces x == y?

[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #22 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #21)
> (In reply to Andrew Macleod from comment #19)
> > Created attachment 54313 [details]
> > better patch
> > 
> > A more consistent approach.. rather than directly call relation_intersect()
> > from multiple places, add the floating point fix to
> > value_relation::intersect and always go through that.
> > 
> > This will cause the normal oracle and the path oracle to both make the
> > previous adjustment to intersect for floating point operations.   untested,
> > running tests now.
> 
> I thought (unless somebody proves otherwise) that relation_intersect is
> actually just fine, the only thing that is incorrect (IMHO) for floating
> point with NaNs are the
> relation_union (VREL_L[TE], VREL_G[TE]) and relation_union (VREL_G[TE],
> VREL_L[TE])
> cases, because those return VREL_NE or VREL_VARYING even when those are
> actually
> LTGT_EXPR (aka ordered and not equal) or ORDERED_EXPR.
> So, if the callers of relation_union know whether it is a relation for
> floating point with NAN or integral/pointer/floating point fast math can't
> they just tweak those cases?

I have since evolved to something close to this.  I am moving all the
relation_intersect and relation_union calling locations to instead go through
the existing value_relation class.  This stores a relation and 2 operands, and
isolates all the smarts for swapping operands and reversing relations as
needed.  (this is how the oracle internally handles it).   That class then
knows whether this is a floating point relation or not an can make adjustments
based on that, keeping it isolated to one place.

We wont have the actual floating point status of NAN and such, but we can at
least not get it wrong for this release in those cases.  THen decide how to add
the required knowledge properly for the next release... maybe just adding a
couple of extra relations will be enough. 

Patch forthcoming soon.

[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures

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

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

--- Comment #21 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #19)
> Created attachment 54313 [details]
> better patch
> 
> A more consistent approach.. rather than directly call relation_intersect()
> from multiple places, add the floating point fix to
> value_relation::intersect and always go through that.
> 
> This will cause the normal oracle and the path oracle to both make the
> previous adjustment to intersect for floating point operations.   untested,
> running tests now.

I thought (unless somebody proves otherwise) that relation_intersect is
actually just fine, the only thing that is incorrect (IMHO) for floating point
with NaNs are the
relation_union (VREL_L[TE], VREL_G[TE]) and relation_union (VREL_G[TE],
VREL_L[TE])
cases, because those return VREL_NE or VREL_VARYING even when those are
actually
LTGT_EXPR (aka ordered and not equal) or ORDERED_EXPR.
So, if the callers of relation_union know whether it is a relation for floating
point with NAN or integral/pointer/floating point fast math can't they just
tweak those cases?

[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'

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

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

--- Comment #11 from David Malcolm  ---
(In reply to Richard Biener from comment #10)
> I suppose a fix would be to provide a dummy implementation for
> range_label_for_type_mismatch::get_text in lto/, but I wonder how
> for example the fortran frontend avoids this issue?
> 
> f951 has rich_location uses but no range_label_for_type_mismatch, it looks
> like range_label_for_* is used only from the C family frontends, so maybe
> another fix would be to move that class and implementation somewhere to
> c-family/?

AIUI class range_label_for_type_mismatch is only used:
  * by the C and C++ frontends (directly, and by
range_label_for_format_type_mismatch), and
  * by maybe_range_label_for_tree_type_mismatch::get_text in
gcc/gcc-rich-location.cc, which is used by class binary_op_rich_location in
gcc/gcc-rich-location.{h,cc}; the latter is only used by the C/C++ frontends.

So moving range_label_for_type_mismatch *and* binary_op_rich_location to
c/cp/c-family might be a fix for this; I'm not sure.

[Bug modula2/108480] gm2 fails to find SYSTEM module after relocation

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-January
   ||/610099.html
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-20

--- Comment #1 from Iain Sandoe  ---
this https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610099.html
fixes relocation of the compiler.

[Bug c/53232] No warning for main() without a return statement with -std=c99

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #18 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #17)
> Yeah, but warnings with high false positivity rates at least shouldn't be in
> -Wall.

Well, there already is -Wunused, which is included in -Wall (such warnings may
typically be emitted due to #if and also in temporary code when debugging), and
-Wsign-compare in C++.

Anyway, there is a first issue: the warning is inexistent, even with -Wextra.
There is a second issue: the warning is not emitted with -Wreturn-type when
there is a call to main(). Solving these two issues alone would not yield a
high false positivity rate with -Wall. (That said, I think that developers
should be encouraged to have an explicit "return" for main(); in particular,
this is really easy to do and improves the code readability, specially knowing
the difference of behavior with other languages, such as shell scripts and
Perl.)

[Bug modula2/108462] duplicate install of static libraries

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

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

--- Comment #3 from Gaius Mulley  ---
ah, oops, of course the testsuite checks in tree :-)

So after an install:

$ cd gcc/testsuite/gm2/isocoroutines/run/pass
$ gm2 -fiso coroutine.mod && ./a.out

would be a simple test.

[Bug c/53232] No warning for main() without a return statement with -std=c99

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

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

--- Comment #17 from Jakub Jelinek  ---
Yeah, but warnings with high false positivity rates at least shouldn't be in
-Wall.

[Bug c/53232] No warning for main() without a return statement with -std=c99

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #16 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #15)
> But much more often it is intentional than unintentional.

That's the same thing for many kinds of warnings.

[Bug sanitizer/108481] New: UBsan missed a signed integer overflow

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108481
   Summary: UBsan missed a signed integer overflow
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, UBsan at -O1 and above missed the signed integer
overflow, while -O0 found it. I checked the assembly and the buggy code was not
optimized away.

Clang detected it at all optimization levels.

Compiler explorer: https://godbolt.org/z/rK6sad1WG

%cat a.c
int a, d;
short b;
short *c = 
int *const e = 
static char f(int *g, short h, long i) {
  d = 2;
  for (;; d--) {
int j = *e;
*g = (0 || h) / h;
*c = 3;
if ((i * (unsigned long)7 <= 1) << j)
  ;
else {
  i = i - 6822162149299574294;
  if (j) {
if (*g)
  break;
continue;
  }
  return 8;
}
  }
  return h;
}
int main() {
  int *k = 
  f(k, 4, 8289379813243698614);
}
%
%gcc-tk -fsanitize=undefined -O1 && ./a.out
%
%gcc-tk -fsanitize=undefined -O0 && ./a.out
/a.c:14:9: runtime error: signed integer overflow: -5354944485355449974 -
6822162149299574294 cannot be represented in type 'long int'
%

[Bug c/53232] No warning for main() without a return statement with -std=c99

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

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

--- Comment #15 from Jakub Jelinek  ---
But much more often it is intentional than unintentional.

[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align

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

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

--- Comment #14 from Richard Earnshaw  ---
(In reply to Richard Biener from comment #13)
> (In reply to Andrew Pinski from comment #10)
> > Updated patch submitted:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589254.html
> 
> I think you need to ping your patches more aggressively ...

Richard Sandiford reviewed it here:|
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589581.html
So the problem is that the review wasn't followed up by the submitter.

[Bug c/53232] No warning for main() without a return statement with -std=c99

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #14 from Vincent Lefèvre  ---
Anyway, as I said initially, the warning would be interesting even in C99+
mode, because the lack of a return statement may be unintentional. For
instance, the developer may have forgotten a "return err;".

[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64

[i.nixman at autistici dot org via Gcc-bugs]

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

niXman  changed:

   What|Removed |Added

 CC||i.nixman at autistici dot org

--- Comment #2 from niXman  ---
fixed by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756

[Bug c/53232] No warning for main() without a return statement with -std=c99

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
And intersection of all the standards is quite hard to define.
So, adding -std=intersection_of_all_c_standards is just not a good idea, any
time same construct changes meaning between different standard you need to
decide what to do.
This is something that should be solved with warnings or external tools and on
the warning side we already have various warnings.

[Bug c/53232] No warning for main() without a return statement with -std=c99

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

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

--- Comment #12 from Jonathan Wakely  ---
Because GCC is primarily a compiler, not a linter for portability problems.

[Bug modula2/108480] New: gm2 fails to find SYSTEM module after relocation

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

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

Bug ID: 108480
   Summary: gm2 fails to find SYSTEM module after relocation
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When you relocate the installed GCC tree (or install with DESTDIR=/some/path)
then gm2 will not find the SYSTEM module since all -I and -L arguments are
not relative to the install location:

> /space/rguenther/install/trunk-r13-5267/usr/local/bin/gm2 -o a.out -fiso 
> coroutine.mod -v
Driving: /space/rguenther/install/trunk-r13-5267/usr/local/bin/gm2 -o a.out
-fiso coroutine.mod -v -fgen-module-list=- -I
/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2iso -I
/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2pim -fplugin=m2rte -L
/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2iso -l m2iso -L
/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2pim -l m2pim -l stdc++ -l
m -l pthread -shared-libgcc
new argc = 17, added_libraries = 3
Using built-in specs.
COLLECT_GCC=/space/rguenther/install/trunk-r13-5267/usr/local/bin/gm2
COLLECT_LTO_WRAPPER=/home/space/rguenther/install/trunk-r13-5267/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /space/rguenther/src/gcc/configure
--enable-languages=c,c++,fortran,m2 --disable-libstdcxx-pch --disable-bootstrap
--enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230120 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'a.out' '-fiso' '-v' '-fgen-module-list=-' '-I'
'/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2iso' '-I'
'/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2pim' '-fplugin=m2rte'
'-L/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2iso'
'-L/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2pim' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'

/home/space/rguenther/install/trunk-r13-5267/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/cc1gm2
-iplugindir=/home/space/rguenther/install/trunk-r13-5267/usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.0.1/plugin
-quiet -dumpdir a- -dumpbase coroutine.mod -dumpbase-ext .mod -mtune=generic
-march=x86-64 -version -fiso -fgen-module-list=- -fplugin=m2rte -fiso
-fgen-module-list=- -fplugin=m2rte -I
/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2iso -I
/usr/local/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2pim -v coroutine.mod -o
/tmp/ccR3avKM.s
GNU Modula-2 (GCC) version 13.0.1 20230120 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version
4.0.2-p6, MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Versions of loaded plugins:
 m2rte: Unknown version.
GNU Modula-2 (GCC) version 13.0.1 20230120 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version
4.0.2-p6, MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Versions of loaded plugins:
 m2rte: Unknown version.
: error: the file containing the definition module ‘SYSTEM’ cannot be
found

that's different from GCC:

> /space/rguenther/install/trunk-r13-5267/usr/local/bin/gcc t.c -v
Using built-in specs.
COLLECT_GCC=/space/rguenther/install/trunk-r13-5267/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/home/space/rguenther/install/trunk-r13-5267/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /space/rguenther/src/gcc/configure
--enable-languages=c,c++,fortran,m2 --disable-libstdcxx-pch --disable-bootstrap
--enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230120 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'

/home/space/rguenther/install/trunk-r13-5267/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/cc1
-quiet -v -iprefix
/home/space/rguenther/install/trunk-r13-5267/usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.0.1/
t.c -quiet -dumpdir a- -dumpbase t.c -dumpbase-ext .c -mtune=generic
-march=x86-64 -version -o /tmp/ccRkTB0l.s
...

[Bug c/53232] No warning for main() without a return statement with -std=c99

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #11 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #8)
> (In reply to comment #6)
> > Er, if you want to find portability problems for people not using C99 then
> > don't use -std=c99. Then -Wreturn-type warns about main.
> 
> There are several reasons one may want to use -std=c99, e.g. to be able to
> use C99 features when available (via autoconf and/or preprocessor tests).

In any case, there does not seem to be a -std value to say that the program
must be valid for all C90, C99, C11 and C17 standards (and the future C23
standard). That's what portability is about.

[Bug c++/108479] New: Internal compiler error: in type_memfn_rqual, at cp/typeck.cc:10994

[etienne.doms at gmail dot com via Gcc-bugs]

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

Bug ID: 108479
   Summary: Internal compiler error: in type_memfn_rqual, at
cp/typeck.cc:10994
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne.doms at gmail dot com
  Target Milestone: ---

Created attachment 54316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54316=edit
Preprocessed source

Hello,

I was just playing on my lunch time and something blew up:

> [smod@syslt041-arch playground]$ g++ bug.cpp -std=c++20 -freport-bug
> bug.cpp: In instantiation of ‘class Foo >’:
> bug.cpp:34:30:   required from here
> bug.cpp:5:7: internal compiler error: in type_memfn_rqual, at 
> cp/typeck.cc:10994
> 5 | class Foo
>   |   ^~~
> 0x19e2ee8 internal_error(char const*, ...)
>   ???:0
> 0x65443c fancy_abort(char const*, int, char const*)
>   ???:0
> 0x69df2f finish_struct_1(tree_node*)
>   ???:0
> 0x7ed3c7 instantiate_class_template(tree_node*)
>   ???:0
> 0x83d035 complete_type(tree_node*)
>   ???:0
> 0x6fcc40 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, 
> tree_node*, tree_node*, tree_node**)
>   ???:0
> 0x7c7d9c c_parse_file()
>   ???:0
> 0x8dd47d c_common_parse_file()
>   ???:0
> Please submit a full bug report, with preprocessed source.
Got this on a up-to-date g++ 12.2.1 on ArchLinux:

> [smod@syslt041-arch playground]$ g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: /build/gcc/src/gcc/configure 
> --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap 
> --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --> 
> mandir=/usr/share/man --infodir=/usr/share/info 
> --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto 
> --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-libstdcxx-backtrace 
> --enable-link-serialization=1 --enable-linker-build-id --enable-lto 
> --enable-multilib --enable-plugin --enable-shared --enable-threads=posix 
> --disable-libssp --disable-libstdcxx-pch --disable-werror
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 12.2.1 20230111 (GCC) 
See attachment generated by "-freport-bug", as requested.

Probably related to #96745, but does not look identical to me.

Note that I was not trying to do something specific, I was reading about this
new shiny concept of "prospective destructor" and tried to instantiate my
template class with "T = decltype(std::cout)", I was expecting something like
"nope, no suitable dtor" but got this instead.

Cheers,
Etienne

[Bug sanitizer/108478] New: Inconsistencies with --enable-version-specific-runtime-libs install

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

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

Bug ID: 108478
   Summary: Inconsistencies with
--enable-version-specific-runtime-libs install
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Besides the m2 issue in PR108144 and the libgcc issue in PR32415 we have

> ls install/lib/gcc/x86_64-pc-linux-gnu/13.0.1/32/*.so
install/lib/gcc/x86_64-pc-linux-gnu/13.0.1/32/libasan.so
install/lib/gcc/x86_64-pc-linux-gnu/13.0.1/32/libssp.so
install/lib/gcc/x86_64-pc-linux-gnu/13.0.1/32/libubsan.so
> ls install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/*.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libatomic.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libgomp.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libitm.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libm2cor.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libm2iso.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libm2log.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libm2min.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libm2pim.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libquadmath.so
install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/libstdc++.so

so most multilibs are installed in the install/lib64/ subdir but some,
notably sanitizer libs and libssp are installed in the system multilib
directory.

I'm fixing PR108144 to match the layout for libstdc++.

Without --enable-version-specific-runtime-libs you get the .o files in

install2/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/

and

install2/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/

and install2/lib/gcc/x86_64-pc-linux-gnu/13.0.1/ is solely used for an
include/ directory containing sanitizer and ssp specific files.

[Bug tree-optimization/108477] New: fwprop over-optimizes conversion from + to |

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 108477
   Summary: fwprop over-optimizes conversion from + to |
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

In the unsigned int case (baz) fwprop over-optimizes the addition to a logical
or:

--cut here--
int lock;

int bar (int old)
{
  int val = (old >> 1) & 0x1;
  int new = (old & ~0x3) + 0x2 + val;

  lock = new;
  return val ? 0 : -1;
}

int ulock;

int baz (unsigned int old)
{
  unsigned int val = (old >> 1) & 0x1;
  unsigned int new = (old & ~0x3) + 0x2 + val;

  ulock = new;
  return val ? 0 : -1;
}
--cut here--

resulting in:

bar:
movl%edi, %eax
andl$-4, %edi
sarl%eax
andl$1, %eax
leal2(%rax,%rdi), %edx< here
subl$1, %eax
movl%edx, lock(%rip)
ret

baz:
movl%edi, %eax
andl$-4, %edi
shrl%eax
andl$1, %eax
orl %eax, %edi<--- here ...
subl$1, %eax
addl$2, %edi  <--- ... and here
movl%edi, ulock(%rip)
ret

Please note the three-operand addition, implemented with LEAL instruction in
the signed case, which is not emitted in the unsigned case. The reason is
fwprop pass that substitutes addition with the equivalent or operation.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #14 from Richard Biener  ---
OK, it looks libgm2 lacks the magic invocation of config-ml.in.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

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

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

--- Comment #13 from Richard Biener  ---
I think all uses of $(inst_libdir)/$(MULTIDIR) should be replaced with
$(toolexeclibdir) and the redundant multi settings removed.

A first round of "cleanups" leads to

$ find /tmp/gcc -name libm2cor.so
/tmp/gcc/lib/gcc/x86_64-pc-linux-gnu/13/libm2cor.so
/tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.so

an improvement(?!) but still not where we want to be ...

[Bug c/108476] Please turn -Wreturn-type on by default for C

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The reason it is enabled by default for C++ is that the 2 languages differ
significantly in this regard.  Falling through the end of a non-void function
in C++ is undefined behavior, in C it is not, in C it is only UB if the caller
actually uses the uninitialized return value (which is much harder to warn
about).
And in C it is enabled in -Wall, which you should use anyway if you care about
warnings.

[Bug c++/108474] static structured binding undefined reference

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 54315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54315=edit
gcc13-pr108474.patch

Untested fix.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #12 from Richard Biener  ---
Hmm, so with --enable-version-specific-runtime-libs we install the 32bit
multilib to the same location as the 64bit one.  Somehow MULTISUBDIR
ends up being empty even though it should be passed down into the subdirs.

The -recursive rules are quite hard to follow and I'm neither a make nor
automake expert here :/

Looking at libsanitizer I wonder why the libgm2 automake files are so complex
:/

There definitely seems to be a lot of "dead" things but then somehow
magically the non-version-specific path is working.

Somehow for libsanitizer the ubsan Makefile has a tail

# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
MULTISUBDIR = /32

but the libgm2/m2cor Makefile for example has not.

m2 doesn't do AM_PROG_LIBTOOL but instead LT_INIT, it looks like libgm2 mostly
cut from libgcc?

I'm trying some cleanups but that's just random edits without really knowing
what I'm doing ...

[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used

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

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

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

https://gcc.gnu.org/g:16bd9e14f226e07bf0ffb9d68084c9ad69bf7b45

commit r13-5268-g16bd9e14f226e07bf0ffb9d68084c9ad69bf7b45
Author: Jakub Jelinek 
Date:   Fri Jan 20 10:23:49 2023 +0100

niter: Fix up unused var warning [PR108457]

tree-ssa-loop-niter.cc (build_cltz_expr) gets unused variable mode
warning on some architectures where C[LT]Z_DEFINED_VALUE_AT_ZERO
macro(s) don't use the first argument (which includes the
defaults.h definitions of:
 #define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE)  0
 #define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE)  0
Other uses of this macro avoid this problem by avoiding temporaries
which are only used as argument to those macros, the following patch
does it the same way for consistency.  Plus some formatting fixes
while at it.

2023-01-20  Jakub Jelinek  

PR tree-optimization/108457
* tree-ssa-loop-niter.cc (build_cltz_expr): Use
SCALAR_INT_TYPE_MODE (utype) directly as
C[LT]Z_DEFINED_VALUE_AT_ZERO
argument instead of a temporary.  Formatting fixes.

[Bug libgomp/85463] [nvptx] "exit" in offloaded region doesn't terminate process

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

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

--- Comment #4 from Tobias Burnus  ---
Crossref: Thomas posted the following newlib patch:

  [PATCH] nvptx: In offloading execution, map '_exit' to 'abort' [GCC PR85463]
  https://sourceware.org/pipermail/newlib/2023/020140.html

[Bug c/108423] [12/13 Regression] ICE in make_ssa_name_fn with VLA types in arguments and inlining since r12-5338-g4e6bf0b9dd5585df

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #4 from Martin Uecker  ---

The specific problem is triggered by the change to pointer_int_sum in
gcc/c-family/c-common.cc, but the underlying problem is older. The following
example fails since gcc 7:

void f(int n, int (*a(void))[n])
{
sizeof (*a());
}

int (*a(void))[1];

void g(void)
{
f(1, a);
}


https://godbolt.org/z/645ahfrzx

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 19 Jan 2023, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144
> 
> --- Comment #10 from Jonathan Wakely  ---
> Isn't --enable-version-specific-runtime-libs completely broken anyway? See PR
> 32415

Depends on what you call "completely broken" - the libgcc install is
"broken", yes.  But it could be fixed easily if somebody cared.

[Bug c/108476] Please turn -Wreturn-type on by default for C

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug ipa/108470] Missing documentation for alternate uses of __attribute__((noinline))

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-20

--- Comment #1 from Richard Biener  ---
Confirmed.  'noinline' has historically disabled quite some IPA transforms (now
we have the more complete 'noipa').

[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher

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

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

--- Comment #2 from Richard Biener  ---
There's some special code dealing with checking on a conditional set value
but that's confused by the two-value guard here.