[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed

[judge.packham at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Chris Packham  ---
In terms of my proposed change which fixes the problem for GCC 11.3.0 it
actually triggers the same assert on GCC 12.1.0.


[ALL  ]In file included from
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:21:
[ERROR]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:75:38:
error: static assertion failed
[ALL  ]   75 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct
stat));
[ALL  ]  |~~^~
[ALL  ]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:348:44:
note: in definition of macro 'COMPILER_CHECK'
[ALL  ]  348 | #define COMPILER_CHECK(pred) static_assert(pred, "")
[ALL  ]  |^~~~
[ALL  ]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:75:38:
note: the comparison reduces to '(104 == 216)'
[ALL  ]   75 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct
stat));
[ALL  ]  |~~^~
[ALL  ]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:348:44:
note: in definition of macro 'COMPILER_CHECK'
[ALL  ]  348 | #define COMPILER_CHECK(pred) static_assert(pred, "")
[ALL  ]  |^~~~
[ERROR]make[5]: *** [Makefile:616: sanitizer_platform_limits_linux.lo]
Error 1

It appears that with GCC 12 we now end up with different values for _MIPS_SIM.

Removing my "fix" resolves the issue for GCC 12 but I suspect something like
the suggestion from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614#c7
might resolve the issue properly.

[Bug tree-optimization/105665] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
> Started with r12-398-g5fbe6a8e73b52c6ebc28b9 because r12-397 didn't compile,
> but yes, it is r12-397.

And it is very similar to PR 100810 in the sense there is an not-executed use
of an uninitialized variable too.

[Bug ipa/105685] [10/11/12 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic, needs-bisection
Summary|Still Bogus |[10/11/12 Regression] Bogus
   |`-Wsuggest-attribute=cold`  |`-Wsuggest-attribute=cold`
   |on function already marked  |on function already marked
   |as `__attribute__((cold))`  |as `__attribute__((cold))`
   Last reconfirmed||2022-05-21
  Known to fail||10.1.0, 10.3.0, 11.3.0,
   ||8.3.0, 9.2.0
  Known to work||8.4.0, 8.5.0, 9.3.0, 9.4.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.4

--- Comment #1 from Andrew Pinski  ---
Confirmed. This one is interesting because it was fixed on the 8 and 9 release
branches but is broken in GCC 10.

[Bug ipa/105682] 12/13 Regression] Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||needs-bisection
   Target Milestone|--- |12.2
  Known to fail||12.1.0
   Last reconfirmed||2022-05-21
  Known to work||11.3.0
 Status|UNCONFIRMED |NEW
Summary|Both|12/13 Regression] Both
   |`-Wsuggest-attribute=pure`  |`-Wsuggest-attribute=pure`
   |and |and
   |`-Wsuggest-attribute=const` |`-Wsuggest-attribute=const`
   |on same function|on same function

--- Comment #1 from Andrew Pinski  ---
Confirmed. A regression from GCC 11.3.0.

[Bug c++/105683] [12/13 Regression] Infinite loop (at runtime) with construction of vector of variant

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

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

--- Comment #1 from Andrew Pinski  ---
It is calling the copy constructor (which you missed in your comment):
  value(const value& other) noexcept : v{other.v}
  {
  }


Which is called via:

inline value_variant_type::value_variant_type(const
std::vector& v) : m_type{Type8}
{
  new (&m_impl.m_value8) std::vector(v);
}

inline ossia::value init_value(ossia::val_type type)
{
...
  return std::vector{};
}


I am thinking there is a constructor that is not being elided here.

[Bug c++/105683] [12/13 Regression] Infinite loop (at runtime) with construction of vector of variant

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12 Regression] Infinite|[12/13 Regression] Infinite
   |loop with construction of   |loop (at runtime) with
   |vector of variant   |construction of vector of
   ||variant
   Keywords||wrong-code
   Target Milestone|--- |12.2

[Bug tree-optimization/105684] Bogus `-Warray-bounds` in partially allocated struct

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I don't think it is defined behavior if it is partially allocated. Unions it
would be questionable but not structs.

[Bug fortran/105674] Wrong bounds for assumed rank pointer

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Reduced testcase, rank 1, no pointer or target needed:

program test
  implicit none
  integer, dimension(4) :: dim_1 = 42
  print*, 'lbound', lbound(dim_1), 'ubound', ubound(dim_1)
  print*, ''
  print *, "call assumed_rank( dim_1 )"
  call assumed_rank( dim_1 )
  print *, "call assumed_rank((dim_1))"
  call assumed_rank((dim_1))
contains
  subroutine assumed_rank(dataset)
integer, intent(in), dimension(..) :: dataset
print*,   'outside select rank'
print*,   'lbound', lbound(dataset), 'ubound', ubound(dataset)
select rank (dataset)
rank (1)
  print*, 'inside  select rank'
  print*, 'lbound', lbound(dataset), 'ubound', ubound(dataset)
end select
print*, ''
  end subroutine assumed_rank
end program test

This prints:

 lbound   1 ubound   4

 call assumed_rank( dim_1 )
 outside select rank
 lbound   1 ubound   4
 inside  select rank
 lbound   1 ubound   4

 call assumed_rank((dim_1))
 outside select rank
 lbound   1 ubound   4
 inside  select rank
 lbound   0 ubound   3

[Bug ipa/91088] IPA-cp cost evaluation is too conservative for "if (f(param) cmp const_val)" condition

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Dimitar Dimitrov :

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

commit r13-699-gaddacdc87b044e63d72054036907c91a18be6734
Author: Dimitar Dimitrov 
Date:   Sun May 15 17:21:59 2022 +0300

testsuite: Adjust pr91088.c for default_packed targets

PR ipa/91088

gcc/testsuite/ChangeLog:

* gcc.dg/ipa/pr91088.c: Adjust member offset checks to
accommodate targets which pack structures by default.

Signed-off-by: Dimitar Dimitrov 

[Bug middle-end/53535] non-aligned memset on non-strict-alignment targets not optimized where aligned memset is

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Dimitar Dimitrov :

https://gcc.gnu.org/g:0380b6575f61e5bd9f428887790716a57dd66488

commit r13-698-g0380b6575f61e5bd9f428887790716a57dd66488
Author: Dimitar Dimitrov 
Date:   Sun May 15 17:11:39 2022 +0300

testsuite: Skip gcc.dg/pr46647.c for PRU

Like AVR and Cris, PRU has no alignment requirements.  Thus it is
also affected by PR53535.

PR middle-end/53535

gcc/testsuite/ChangeLog:

* gcc.dg/pr46647.c: Skip for pru target.

Signed-off-by: Dimitar Dimitrov 

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||build

--- Comment #1 from Jonathan Wakely  ---
Odd, that isn't new code and last time I built for msp430 I thought it worked
ok. I'll look into it.

[Bug rtl-optimization/105686] New: [10/11/12/13 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 8 with -fnon-call-exceptions

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105686
   Summary: [10/11/12/13 Regression] ICE: verify_flow_info failed:
missing REG_EH_REGION note at the end of bb 8 with
-fnon-call-exceptions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O -fno-delete-dead-exceptions
-fnon-call-exceptions -fexceptions -fno-tree-dce -fno-tree-forwprop testcase.c
testcase.c: In function 'foo':
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 8
   11 | }
  | ^
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 7
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 6
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 5
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 4
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 3
during RTL pass: cprop_hardreg
testcase.c:11:1: internal compiler error: verify_flow_info failed
0xc42133 verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:284
0x1055eba execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2097
0x105643b execute_todo
/repo/gcc-trunk/gcc/passes.cc:2139
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.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-694-20220520170416-gd5cf2a1f15e-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-694-20220520170416-gd5cf2a1f15e-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220520 (experimental) (GCC)

[Bug ipa/105685] New: Still Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`

[sagebar at web dot de via Gcc-bugs]

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

Bug ID: 105685
   Summary: Still Bogus `-Wsuggest-attribute=cold` on function
already marked as `__attribute__((cold))`
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I would re-open https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087, but I don't
think I can so a new bug report it is... - Anyways: while my test-case from
back then remains fixed, the same problem still happens for the following code:

Run (`gcc -c -O2 -Wsuggest-attribute=cold infile.c`)
```
extern void external_fun(char *, char const *, int);

__attribute__((cold)) char *my_cold_fun(int x) {
static char b[42];
external_fun(b, "Without me, the warning disappears?", x);
return b;
}

__attribute__((cold)) char *my_other_cold_fun(int x) {
return my_cold_fun(x);
}
```

 Output 
>infile.c: In function 'my_other_cold_fun':
>infile.c:9:29: warning: function might be candidate for attribute 'cold' 
>[-Wsuggest-attribute=cold]
>9 | __attribute__((cold)) char *my_other_cold_fun(int x) {
>  | ^


 Output (Expected) 
>

[Bug c/105684] New: Bogus `-Warray-bounds` in partially allocated struct

[sagebar at web dot de via Gcc-bugs]

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

Bug ID: 105684
   Summary: Bogus `-Warray-bounds` in partially allocated struct
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

Accessing the fields of a partially allocated struct results in
`-Warray-bounds`, even when all accessed fields lie within the allocated
portion of the struct (a fact that can be proven to be known to gcc by asking
it for `__builtin_object_size()`)

Example (compile with `gcc -c infile.c -O2 -Warray-bounds -S -o -`):

```
struct obj {
unsigned long long kind;
union {
struct {
unsigned long long a;
} data0;
struct {
unsigned long long a;
unsigned long long b;
} data1;
};
};

extern __attribute__((alloc_size(1))) void *my_malloc(unsigned long);
#define offsetafter(s, m) (__builtin_offsetof(s, m) + sizeof(((s *)0)->m))

struct obj *create_object_kind_0(void) {
struct obj *result;
result = (struct obj *)my_malloc(offsetafter(struct obj, data0));
__asm__ __volatile__("# Object size is: %p0" : : "X"
(__builtin_object_size(result, 0)));
result->kind= 0;
result->data0.a = 1;
return result;
}
```

Real-world use-case & rationale: the idea is that access to `data1` vs. `data0`
is governed by the value of `kind` (`obj` is a "typed variant"), and by
allocating only the relevant portion of the object, we can save memory, and
create an environment where buggy code that wrongfully accesses (e.g.) certain
fields of `data1` of a `kind=0` object might cause the program to crash (rather
than remain unnoticed as would be the case when simply using `sizeof(struct
obj)` as allocation size).

Expected behavior: no warnings should be generated

== Actual behavior (Truncated) ===
>[stderr]infile.c: In function 'create_object_kind_0':
>[stderr]infile.c:22:15: warning: array subscript 'struct obj[0]' is partly 
>outside array bounds of 'unsigned char[16]' [-Warray-bounds]
>[stderr]   21 | result->kind= 0;
>[stderr]  |   ^~
>[stderr]infile.c:20:32: note: object of size 16 allocated by 'my_malloc'
>[stderr]   19 | result = (struct obj *)my_malloc(offsetafter(struct 
>obj, data0));
>[stderr]  |
>^
>[stderr]infile.c:23:15: warning: array subscript 'struct obj[0]' is partly 
>outside array bounds of 'unsigned char[16]' [-Warray-bounds]
>[stderr]   22 | result->data0.a = 1;
>[stderr]  |   ^~
>[stderr]infile.c:20:32: note: object of size 16 allocated by 'my_malloc'
>[stderr]   19 | result = (struct obj *)my_malloc(offsetafter(struct 
>obj, data0));
>[stderr]  |
>^
>[stdout][...]
>[stdout]/  22 "infile.c" 1
>[stdout]# Object size is: 16
>[stdout]/  0 "" 2
>[stdout]/NO_APP
>[stdout]movl$0, (%eax)
>[stdout]movl$0, 4(%eax)
>[stdout]movl$1, 8(%eax)
>[stdout]movl$0, 12(%eax)
>[stdout]leave
>[stdout]ret
>[stdout][...]

As can be seen by `# Object size is: 16` (and repeated in warning messages),
gcc knows that the allocated size of the object is 16 bytes, and as can be seen
by the offsets used by the `movl` instructions, this limit is never exceeded.

Judging by what the warnings state (and confirmed by replacing
`offsetafter(struct obj, data0)` with `sizeof(struct obj)`), the
`-Warray-bounds` warning will always be generated for any accessed field
(irregardless of that field's offset) so-long as `__builtin_object_size(result,
0) < sizeof(struct obj)`.

I am uncertain about the intended semantics of `-Warray-bounds`, and
technically speaking, the warning is stating the truth: "'struct obj[0]' is
partly outside array bounds" (emphasis on the "partly"). However, as it stands
right now, warning about this situation is less than useful (a warning might
arguably be useful when passing `result` -- or a pointer to one of its members
-- to some other function, but even in that situation a warning would probably
be a false positive). So in my opinion, at `-Warray-bounds[=1]`, a warning
should only be generated exactly in those cases where an out-of-bounds access
*actually* happens (*possible* out-of-bounds warnings may appear at
`-Warray-bounds=2`, but definitely shouldn't at `-Warray-bounds=1`).

==


Additionally, after making the following changes to the above code (causing
`sizeof(struct obj) == offsetafter(struct obj, data0)`):

```
@@ -6,7 +6,7 @@
} data0;

[Bug c++/105683] New: [12 Regression] Infinite loop with construction of vector of variant

[jeanmichael.celerier at gmail dot com via Gcc-bugs]

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

Bug ID: 105683
   Summary: [12 Regression] Infinite loop with construction of
vector of variant
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

Created attachment 53012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53012&action=edit
Full repro

Hello,

Full repro attached (g++ -std=gnu++20 repro.cpp && ./a.out is enough to trigger
the issue).
Same code works fine for every GCC version < 12 in c++17, c++20, as well as
with every released clang version in c++17, c++20, with both libc++ and
libstdc++.

My code more-or-less looks like this (trying to keep only the relevant parts):



// line 58584
struct value_variant_type {
  union Impl { std::vector m_value8; } m_impl;

  value_variant_type(const std::vector& v); 
  value_variant_type(std::vector&& v);
};


// line 58681
class value {
  value_variant_type v;
  value(const std::vector& val) noexcept : v{val}
  {
  }
  explicit value(std::vector&& val) noexcept :
v{std::move(val)}
  {
  }
};



// line 75925
inline value_variant_type::value_variant_type(const
std::vector& v) : m_type{Type8}
{
  new (&m_impl.m_value8) std::vector(v);
}

inline value_variant_type::value_variant_type(std::vector&&
v) : m_type{Type8}
{
  new (&m_impl.m_value8) std::vector(std::move(v));
}




// line 58916
inline ossia::value init_value(ossia::val_type type)
{
  return std::vector{};
}



// line 76232
void create_value_inline(ossia::value& v, ossia::val_type t) {
  v = ossia::init_value(t);
}

int main()
{
ossia::value v;
create_value_inline(v, ossia::val_type::LIST);
}


What it looks that is happening is a loop between the construction of the value
and of the vector: 


#1822 0x87b7 in ossia::value::value (other=...,
this=0x55abff10)
at
/home/jcelerier/ossia/score/3rdparty/libossia/src/ossia/network/value/value.hpp:302
#1823 std::_Construct
(__p=0x55abff10) at /usr/include/c++/12.1.0/bits/stl_construct.h:119
#1824 std::__do_uninit_copy
(__result=, __last=, __first=0x7f802a50)
at /usr/include/c++/12.1.0/bits/stl_uninitialized.h:120
#1825 std::__uninitialized_copy::__uninit_copy (__result=, __last=, 
__first=) at
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:137
#1826 std::uninitialized_copy
(__result=, __last=, __first=)
at /usr/include/c++/12.1.0/bits/stl_uninitialized.h:185
#1827 std::__uninitialized_copy_a (__result=0x55abff10, __last=0x7f802a78,
__first=0x7f802a50)
at /usr/include/c++/12.1.0/bits/stl_uninitialized.h:372
#1828 std::vector
>::_M_range_initialize (__last=0x7f802a78,
__first=0x7f802a50, 
this=0x55abfee0) at /usr/include/c++/12.1.0/bits/stl_vector.h:1690
#1829 std::vector >::vector
(__a=..., Python Exception : value has been optimized out
__l=, this=0x55abfee0) at /usr/include/c++/12.1.0/bits/stl_vector.h:677
#1830 ossia::value_variant_type::value_variant_type (other=...,
this=0x55abfee0)
at
/home/jcelerier/ossia/score/3rdparty/libossia/src/ossia/network/value/value_variant_impl.hpp:17017
#1831 ossia::value::value (other=..., this=0x55abfee0) at
/home/jcelerier/ossia/score/3rdparty/libossia/src/ossia/network/value/value.hpp:302

[Bug c/105682] New: Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function

[sagebar at web dot de via Gcc-bugs]

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

Bug ID: 105682
   Summary: Both `-Wsuggest-attribute=pure` and
`-Wsuggest-attribute=const` on same function
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

The following example causes both a `-Wsuggest-attribute=pure` and
`-Wsuggest-attribute=const` warning for the same function. Additionally, in
this example, only `-Wsuggest-attribute=pure` would be correct (the
`-Wsuggest-attribute=const` is completely bogus):

Compile with `gcc -c -O2 -Wsuggest-attribute=const -Wsuggest-attribute=pure
input.c`:

```
__attribute__((pure))
int callee(int x) {
unsigned int a;
__asm__ __volatile__("");
__asm__ __volatile__("" : "=X" (a));
x &= 1;
if (a & 2)
__asm__ __volatile__("" : "=m" (x));
return x & 4;
}

int caller(int x) {
return callee(x);
}
```

Output (gcc-12.1.0):
>input.c: In function 'caller':
>input.c:12:5: warning: function might be candidate for attribute 'pure' 
>[-Wsuggest-attribute=pure]
>   12 | int caller(int x) {
>  | ^~
>input.c:12:5: warning: function might be candidate for attribute 'const' 
>[-Wsuggest-attribute=const]

Output (gcc-11.2.0; expected behavior):
>input.c: In function 'caller':
>input.c:12:5: warning: function might be candidate for attribute 'pure' 
>[-Wsuggest-attribute=pure]
>   12 | int caller(int x) {
>  | ^~


=== After adding `__attribute__((pure))` to `caller` ===

```
__attribute__((pure))
int caller(int x) {
return callee(x);
}
```

gcc-12.1.0 (bogus warning: `caller()` has no right to be const; it calls a pure
function, and that function even contains inline assembly):
>infile.c: In function 'caller':
>infile.c:13:5: warning: function might be candidate for attribute 'const' 
>[-Wsuggest-attribute=const]
>   13 | int caller(int x) {
>  | ^~

gcc-11.2.0 (expected behavior):
> (No warnings)

===

NOTES:
- Not only does gcc suggest to add both pure & const to the same function, the
later wouldn't even make any sense in this scenario (though suggesting `pure`
is correct).
- The strange-looking body of `callee()` is required to reproduce the bug. -
Trying to further simplify it tends to make the warning go away, suggesting a
problem with some kind of heuristic.
- I know I also just reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105676, but that one is about a
bogus `-Wsuggest-attribute=pure` warning, while this one is about a bogus
`-Wsuggest-attribute=const` warning. The two bugs may be related, but simply
suppressing `-Wsuggest-attribute=pure` on const-functions wouldn't be enough to
fix the bug addressed in this report.

[Bug libstdc++/105681] New: libstdc++-v3 fails to build on msp430

[beagleboard at davidjohnsummers dot uk via Gcc-bugs]

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

Bug ID: 105681
   Summary: libstdc++-v3 fails to build on msp430
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beagleboard at davidjohnsummers dot uk
  Target Milestone: ---

Hi, I'm trying to build gcc for an msp430 cpu, using gcc12.1.0 binuitils-2.38
and newlib-4.2.0.20211231. Now I can build c fine, but when I try to build c++
libstdc++-v3 fails, I think becuase the msp430 is only a 16bit processor.

The specific configure command used is:

../../gcc-git/configure --with-sysroot=/home/summers/msp430
--prefix=/home/summers/msp430  --target=msp430-elf --disable-nls
--disable-werror
--with-native-system-header-dir=/home/summers/msp430/msp430-elf/include
--with-newlib --enable-languages=c,c++ --disable-nls --enable-initfini-array
--enable-target-optspace --with-gmp --with-mpfr --with-mpc --with-isl
-enable-newlib-nano-malloc

This has binutils and newlib copied into the gcc source directory. The native
system header is pointed at newlib header files.

The build fails with errors like:

In file included from
/home/summers/msp430/gcc-git/libstdc++-v3/include/precompiled/extc++.h:61:
/home/summers/msp430/src/gcc-binutils-newlib/msp430-elf/libstdc++-v3/include/ext/random:355:69:
error: narrowing conversion of '86243' from 'long int' to 'unsigned int'
[-Wnarrowing]
  355 | 0xU, 0xe9528d85U>
  | ^

I also tried the build with the git version of gcc, last weekend (14/5/22) and
had exactly the same error.

So is this a bug, or have I configured something wrong. Does libstdc++-v3 just
need to be made 16bit aware?