[Bug c++/101595] New: ICE: in tsubst_pack_expansion, at cp/pt.c:13124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101595
Bug ID: 101595
Summary: ICE: in tsubst_pack_expansion, at cp/pt.c:13124
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
template
concept C = true;
auto apply(auto f, auto... args) {
f(args...);
}
auto f(auto) {
apply(
[](auto... x) {
([] { if constexpr (C); }(), ...);
}, 0);
}
int main() {
f(0);
}
https://godbolt.org/z/eGjzePdf4
: In instantiation of 'f(int):: [with auto:4 =
{int}]':
:5:4: required from 'auto apply(auto:1, auto:2 ...) [with auto:1 =
f(int)::; auto:2 = {int}]'
:9:8: required from 'auto f(auto:3) [with auto:3 = int]'
:16:4: required from here
:10:12: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:13124
10 | [](auto... x) {
|^
0x1d75749 internal_error(char const*, ...)
???:0
0x72daa7 fancy_abort(char const*, int, char const*)
???:0
0x9a9f67 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0x9a9cb7 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0x995c67 instantiate_decl(tree_node*, bool, bool)
???:0
0x83defe maybe_instantiate_decl(tree_node*)
???:0
0x83f660 mark_used(tree_node*, int)
???:0
0x759055 build_op_call(tree_node*, vec**, int)
???:0
0x9fc005 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x995c67 instantiate_decl(tree_node*, bool, bool)
???:0
0x83defe maybe_instantiate_decl(tree_node*)
???:0
0x83f660 mark_used(tree_node*, int)
???:0
0x754867 build_new_function_call(tree_node*, vec**, int)
???:0
0x9fc18c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x995c67 instantiate_decl(tree_node*, bool, bool)
???:0
0x83defe maybe_instantiate_decl(tree_node*)
???:0
0x83f660 mark_used(tree_node*, int)
???:0
0x754867 build_new_function_call(tree_node*, vec**, int)
???:0
0x9fc18c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x95b245 c_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug middle-end/101596] New: vect_recog_mulhs_pattern could use incorrect precision to check shift count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596
Bug ID: 101596
Summary: vect_recog_mulhs_pattern could use incorrect precision
to check shift count
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
I happened to spot this when I was working to add one new pattern for Power10
divide extended. Now vect_recog_mulhs_pattern uses target_precision to check
the scale_term is expected or not, it's wrong when the precision of the actual
used new_type larger than target_precision, since we use the new_type for the
internal function call.
Test case:
```
#define N 32
typedef signed long long sLL;
signed int si_a[N], si_b[N];
signed short sh_c[N];
#define SH_CNT 48
//#define SH_CNT 32
__attribute__ ((noipa)) void
test_ui ()
{
for (int i = 0; i < N; i++)
sh_c[i] = ((sLL) si_a[i] * (sLL) si_b[i]) >> SH_CNT;
}
__attribute__ ((optimize ("O0"))) int
main ()
{
for (int i = 0; i < N; i++)
{
si_a[i] = 0x12345678;
si_b[i] = 0x76543210;
}
test_ui ();
for (int i = 0; i < N; i++)
{
signed short exp = ((sLL) si_a[i] * (sLL) si_b[i]) >> SH_CNT;
if (exp != sh_c[i])
__builtin_abort ();
}
return 0;
}
```
gcc test.c -mcpu=power10 -O2 -ftree-vectorize
$ ./a.out
Aborted (core dumped)
test.c:13:21: note: vect_recog_mulhs_pattern: detected: _6 = _5 >> 48;
[Bug c++/101595] ICE: in tsubst_pack_expansion, at cp/pt.c:13124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101595 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2021-07-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r9-6542-gf869f40780836d17, it was rejected before the revision.
[Bug middle-end/101596] vect_recog_mulhs_pattern could use incorrect precision to check shift count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596 Kewen Lin changed: What|Removed |Added Last reconfirmed||2021-07-23 Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Kewen Lin --- I have a untested patch.
[Bug ipa/101502] Inconsistent behavior in maybe_record_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101502 --- Comment #2 from Feng Xue --- (In reply to Martin Liška from comment #1) > @Honza: Can you please take a look? > @Feng: Do you have a test-case for it, please? No. I just got this from code logic, but not 100% sure.
[Bug middle-end/101596] vect_recog_mulhs_pattern could use incorrect precision to check shift count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596 --- Comment #2 from Kewen Lin --- Created attachment 51200 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51200&action=edit Untested patch Still need test cases to be added.
[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-23
[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587
--- Comment #1 from Jonathan Wakely ---
Maybe we should add this somewhere and just stop using std::min for integers:
struct __min_fn
{
template
typename common_type<_Tp, _Up>::type
operator()(_Tp __t, _Up __u) const noexcept
{ return std::min::type>(__t, __u); }
};
_GLIBCXX17_INLINE constexpr __min_fn __min{};
[Bug target/95286] -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Jonathan Wakely --- Not a bug, as explained above.
[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
struct A { char a; };
struct B : virtual A {};
struct C : B {};
void
foo ()
{
C c;
__builtin_clear_padding (&c);
}
[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587
--- Comment #2 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #1)
> Maybe we should add this somewhere and just stop using std::min for integers:
>
> struct __min_fn
> {
> template
> typename common_type<_Tp, _Up>::type
> operator()(_Tp __t, _Up __u) const noexcept
> { return std::min::type>(__t, __u); }
> };
> _GLIBCXX17_INLINE constexpr __min_fn __min{};
It may cause problems when comparing integers with different signedness.
[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587 --- Comment #3 from Jonathan Wakely --- In theory yes, but it's unlikely to be a problem in practice because the library doesn't need to compare unsigned types with negative values. If it does need to do that, it is either already doing so carefully and correctly, or this helper wouldn't make things worse. I'm not suggesting designing a general purpose replacement for std::min that handles all the possible corner cases, I'm just suggesting a convenience function for our own internal needs. All the uses in are with iterator difference types, which had better be signed, and distance(first, last) had better be non-negative too. include/bits/hashtable_policy.h does: const auto __max_width = std::min(sizeof(size_t), 8); This is mixing unsigned and signed, but both positive. include/bits/locale_conv.h: auto __nn = std::min(this->epptr() - this->pptr(), __n - __done); This compares ptrdiff_t with streamsize, which are both signed (and both values here are guaranteed to be non-negative by construction).
[Bug tree-optimization/101597] New: r12-2132-ga110855667782dac[12 Regression] ICE in evrp since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101597
Bug ID: 101597
Summary: r12-2132-ga110855667782dac[12 Regression] ICE in evrp
since
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat unified.ii
extern "C" void *memcpy(void *, const void *, unsigned long);
template
struct integral_constant {
static constexpr int value = __v;
};
using false_type = integral_constant;
struct PluginViewBase;
template
using conditional_t = _Iffalse;
template
constexpr bool is_const_v = false_type ::value;
namespace WTF {
template
ToType bitwise_cast(FromType from) {
ToType to;
memcpy(&to, &from, sizeof(to));
return to;
}
} // namespace WTF
using WTF::bitwise_cast;
bool isOfType___trans_tmp_2;
namespace WTF {
template
struct TypeCastTraits;
template
bool is(ArgType &source) {
return TypeCastTraits::isOfType(source);
}
template
using match_constness_t = conditional_t, T, T>;
template
match_constness_t &downcast(Source &source) {
return static_cast &>(source);
}
} // namespace WTF
using WTF::downcast;
using WTF::is;
class PreciseAllocation;
struct HeapCell {
PreciseAllocation &preciseAllocation() const;
int &vm() const;
};
struct WeakSet {
void vm();
};
struct PreciseAllocation {
static PreciseAllocation *fromCell(void *cell) {
char *__trans_tmp_1 = bitwise_cast(cell);
return bitwise_cast(__trans_tmp_1 - halfAlignment);
}
void vm() { m_weakSet.vm(); }
static constexpr unsigned halfAlignment = 2;
WeakSet m_weakSet;
};
PreciseAllocation &HeapCell::preciseAllocation() const {
return *PreciseAllocation::fromCell(const_cast(this));
}
int &HeapCell::vm() const { preciseAllocation().vm(); }
struct Node {
virtual bool isPluginElement() { return false; }
};
struct Widget {};
namespace WTF {
template
struct TypeCastTraits {
static bool isOfType(ArgType &source) {
isOfType___trans_tmp_2 = source.isPluginElement();
return isOfType___trans_tmp_2;
}
};
} // namespace WTF
struct JSHTMLElement {
Node &wrapped();
};
struct PluginViewBase : Widget {
virtual HeapCell *scriptObject(HeapCell *);
};
HeapCell pluginScriptObjectFromPluginViewBase_globalObject;
JSHTMLElement pluginScriptObjectFromPluginViewBase_jsHTMLElement;
HeapCell *pluginScriptObjectFromPluginViewBase___trans_tmp_3;
Node &pluginScriptObjectFromPluginViewBase_element =
pluginScriptObjectFromPluginViewBase_jsHTMLElement.wrapped();
Widget *pluginScriptObjectFromPluginViewBase_pluginWidget;
HeapCell *pluginScriptObjectFromPluginViewBase() {
if (!is(pluginScriptObjectFromPluginViewBase_element)) return nullptr;
pluginScriptObjectFromPluginViewBase___trans_tmp_3 =
downcast(
*pluginScriptObjectFromPluginViewBase_pluginWidget)
.scriptObject(&pluginScriptObjectFromPluginViewBase_globalObject);
return pluginScriptObjectFromPluginViewBase___trans_tmp_3;
}
void pluginElementCustomGetCallData() {
if (HeapCell *scriptObject = pluginScriptObjectFromPluginViewBase())
scriptObject->vm();
}
$ g++ unified.ii -fno-checking -c -Warray-bounds -O3
unified.ii: In member function ‘int& HeapCell::vm() const’:
unified.ii:58:55: warning: no return statement in function returning non-void
[-Wreturn-type]
58 | int &HeapCell::vm() const { preciseAllocation().vm(); }
| ^
In member function ‘void PreciseAllocation::vm()’,
inlined from ‘int& HeapCell::vm() const’ at unified.ii:58:51,
inlined from ‘void pluginElementCustomGetCallData()’ at unified.ii:94:21:
unified.ii:51:27: warning: array subscript -2 is outside array bounds of
‘HeapCell [9223372036854775807]’ [-Warray-bounds]
51 | void vm() { m_weakSet.vm(); }
| ^~
‘
during GIMPLE pass: vrp
In function ‘void pluginElementCustomGetCallData()’:
Segmentation fault
92 | void pluginElementCustomGetCallData() {
| ^~
0x11a348a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0xa440a4 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3372
0xa440a4 resolve_virtual_fun_from_obj_type_ref
/home/marxin/Programming/gcc/gcc/cp/error.c:2153
0xa48f17 dump_expr
/home/marxin/Programming/gcc/gcc/cp/error.c:2953
0xa4e862 expr_to_string(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/error.c:3224
0xa4f15c cp_printer
/home/marxin/Programming/gcc/gcc/cp/error.c:4390
0x1e43257 pp_format(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-prin
[Bug tree-optimization/101597] [12 Regression] ICE in evrp since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101597 Martin Liška changed: What|Removed |Added Summary|r12-2132-ga110855667782dac[ |[12 Regression] ICE in evrp |12 Regression] ICE in evrp |since |since |r12-2132-ga110855667782dac Target Milestone|--- |12.0 Last reconfirmed||2021-07-23 Ever confirmed|0 |1 Priority|P3 |P1 Status|UNCONFIRMED |NEW
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 51201 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51201&action=edit gcc12-pr101586.patch Untested fix.
[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587 --- Comment #4 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #3) > > I'm not suggesting designing a general purpose replacement for std::min that > handles all the possible corner cases, I'm just suggesting a convenience > function for our own internal needs. Yep, this is reasonable, just like std::__memcmp does, and it is obviously simpler than something like std::min sizeof(__d1)), decltype(__d1), decltype(__d2)>>(__d1, __d2), and thank you for your detailed explanation BTW.
[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587 --- Comment #5 from Jonathan Wakely --- Yes, much simpler than that! :-) There are lots of uses of std::min and std::max with explicit template argument lists in the Parallel Mode headers, but I have no intention of touching them, and they need to work as C++98 so couldn't use the function above anyway.
[Bug ada/101575] [gcc-11, -gdwarf-4] Missing .file directive causes invalid line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575 --- Comment #8 from Bernd Edlinger --- I can of course make the .loc go away. If you really want that. It is basically the DECL_SOURCE_LOCATION of an otherwise ignored decl. If the DECL_SOURCE_LOCATION is UNKNOWN_LOCATION the function should have no line info, and gdb should be able not to step into this function. However the location does not look really wrong to me. In create_subprog_decl it is taken over from input_location. I could imagine that this is sometimes a misleading location. But then in gnat_pushdecl we have Sloc_to_locus (Sloc (gnat_node), &DECL_SOURCE_LOCATION (decl)); and it is again the same location. In the test case the location points here: + column location v type Struct1 is limited record <- line location X : Integer := 13; Y : Integer := 19; end record;
[Bug debug/101598] New: [debug, ada] .loc generated for defs__struct1IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
Bug ID: 101598
Summary: [debug, ada] .loc generated for defs__struct1IP
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I.
Consider test-case defs.adb/defs.ads from a gdb testcase (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada/formatted_ref
).
When compiled with trunk, we have a .loc in defs__struct1IP:
...
$ ./install/bin/gcc defs.adb -c -save-temps -g
$ more defs.s
.file "defs.adb"
.text
.Ltext0:
.file 0 "/home/vries/gcc_versions/devel" "defs.adb"
.align 2
.globl defs__struct1IP
.type defs__struct1IP, @function
defs__struct1IP:
.LFB2:
.cfi_startproc
.file 1 "defs.ads"
.loc 1 18 9
pushq %rbp
...
According to PR 101575 comment 7, that's something that needs to be fixed.
II.
Concretely, the .loc being there means that when stepping through defs___elabs,
we'll step into defs__struct1IP:
...
$ gdb -q formatted_ref -ex "b defs___elabs" -ex run
Reading symbols from formatted_ref...
Breakpoint 1 at 0x402bfe: file defs.ads, line 25.
Starting program: formatted_ref
Breakpoint 1, () at defs.ads:25
25 S1 : Struct1;
(gdb) s
0x00402bcc in defs__struct1IP () at defs.ads:18
18 type Struct1 is limited record
(gdb) s
() at defs.ads:27
27 end Defs;
(gdb)
...
OTOH, with gcc-11, we have no .loc:
...
$ gcc-11 defs.adb -c -save-temps -g -gdwarf-5
$ more defs.s
.file "defs.adb"
.text
.Ltext0:
.file 0 "/home/vries/gcc_versions/devel" "defs.adb"
.align 2
.globl defs__struct1IP
.type defs__struct1IP, @function
defs__struct1IP:
.LFB2:
.cfi_startproc
pushq %rbp
...
which means means we don't step into defs__struct1IP:
...
$ gdb -q formatted_ref -ex "b defs___elabs" -ex run
Reading symbols from formatted_ref...
Breakpoint 1 at 0x402d1a: file defs.ads, line 25.
Starting program: formatted_ref
Breakpoint 1, () at defs.ads:25
25 S1 : Struct1;
(gdb) s
27 end Defs;
(gdb)
...
III.
The difference is caused by commit e69ac020372 ("Add line debug info for
virtual thunks").
[Bug ada/101575] [gcc-11, -gdwarf-4] Missing .file directive causes invalid line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575 --- Comment #9 from Tom de Vries --- (In reply to Eric Botcazou from comment #7) > (> More specifically, it's gone because we have: > > ... > > $ more defs.s > > .file "defs.adb" > > .text > > .Ltext0: > > .align 2 > > .globl defs__struct1IP > > .type defs__struct1IP, @function > > defs__struct1IP: > > .LFB2: > > .cfi_startproc > > .file 1 "defs.ads" > > .loc 1 18 9 > > ... > > Ugh, we do *not* want to have .loc directives for defs__struct1IP so > something is even more broken here. Filed as PR101598 - [debug, ada] .loc generated for defs__struct1IP.
[Bug libstdc++/95048] [9/10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #11 from Christian Fersch --- Would you accept a patch that implements my solution from comment 6? It seems to me like that would be an improvement over the current situation.
[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598 --- Comment #1 from Tom de Vries --- FWIW, this works for me: ... $ git diff diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 82783c4968b..0e21775041c 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -28390,6 +28390,8 @@ dwarf2out_source_line (unsigned int line, unsigned int column, column = 0; file_num = maybe_emit_file (lookup_filename (filename)); + if (DECL_IGNORED_P (cfun->decl) && is_ada ()) +return; /* ??? TODO: Elide duplicate line number entries. Traditionally, the debugger has used the second (possibly duplicate) line number ...
[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598 --- Comment #2 from Bernd Edlinger --- Yes, but it wont fix dwarf-4 and also not the case when this is not the first function. then we'll have the .loc from the previous function extend to this one.
[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598 --- Comment #3 from Tom de Vries --- (In reply to Tom de Vries from comment #1) > FWIW, this works for me: And, doesn't reintroduce PR101575 on trunk. AFAIU, the solution suggested in PR101575 comment 8 of setting the DECL_SOURCE_LOCATION for defs__struct1IP to UNKNOWN_LOCATION would reintroduce PR101575 on trunk.
[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598 --- Comment #4 from Tom de Vries --- (In reply to Bernd Edlinger from comment #2) > Yes, but it wont fix dwarf-4 and also not the case > when this is not the first function. then we'll > have the .loc from the previous function extend to this one. I just tried out: - dwarf-4 - manually changing order of defs__f1 and defs__struct1IP in .s file The result look fine to me. So please show a concrete example where this produces wrong results.
[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598 --- Comment #5 from Bernd Edlinger --- I will have a look.
[Bug target/101504] [12 Regression] ICE: in lra_assign, at lra-assigns.c:1649 with -O2 -march=broadwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101504 --- Comment #3 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:08573db03c2e53db368d699c47032c6c5f2e commit r12-2495-g08573db03c2e53db368d699c47032c6c5f2e Author: H.J. Lu Date: Thu Jul 22 05:17:27 2021 -0700 x86: Don't return hard register when LRA is in progress Don't return hard register in ix86_gen_scratch_sse_rtx when LRA is in progress to avoid ICE when there are no available hard registers for LRA. gcc/ PR target/101504 * config/i386/i386.c (ix86_gen_scratch_sse_rtx): Don't return hard register when LRA is in progress. gcc/testsuite/ PR target/101504 * gcc.target/i386/pr101504.c: New test.
[Bug target/101504] [12 Regression] ICE: in lra_assign, at lra-assigns.c:1649 with -O2 -march=broadwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101504 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from H.J. Lu --- Fixed.
[Bug libstdc++/101599] New: ranges::__copy_or_move missing std::move for input_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101599
Bug ID: 101599
Summary: ranges::__copy_or_move missing std::move for
input_iterator
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
ranges_algobase.h#L247:
else if constexpr (__is_normal_iterator<_Out>)
{
auto [__in,__out]
= ranges::__copy_or_move<_IsMove>(__first, __last, __result.base());
return {std::move(__in), decltype(__result){__out}};
}
We should std::move __first to recursive ranges::__copy_or_move() call since
some input_iterator such as basic_istream_view::iterator does not have the
copy constructor.
#include
#include
#include
int main() {
auto ints = std::istringstream{"42"};
auto r = std::ranges::istream_view(ints);
std::vector v(1, 0);
std::ranges::copy(r, v.begin());
}
https://godbolt.org/z/hh1o36df8
[Bug c++/101600] New: Spurious -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600
Bug ID: 101600
Summary: Spurious -Warray-bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent GCC 12 trunk (but not with e.g. gcc-c++-11.1.1-3.fc34.x86_64):
> $ cat test.cc
> struct S1 { virtual ~S1(); };
> struct S2 { int m; };
> struct S3 { virtual ~S3(); };
> struct S4: S1, S2, S3 {};
> int f1();
> void f2(S3 *);
> void f3(S2 * p) {
> for (int i = f1(); f1();) {
> if (i == 0) {
> p = nullptr;
> break;
> }
> }
> f2(static_cast(p));
> }
> $ g++ -c -O2 -Warray-bounds -O2 test.cc
> test.cc: In function ‘void f3(S2*)’:
> test.cc:14:7: warning: array subscript 0 is outside array bounds of ‘S2
> [2305843009213693951]’ [-Warray-bounds]
>14 | f2(static_cast(p));
> | ~~^~
> test.cc:7:14: note: at offset -8 into object ‘p’ of size [0,
> 9223372036854775807]
> 7 | void f3(S2 * p) {
> | ~^
[Bug c++/101592] ICE in wide_int_to_tree, at tree.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101592 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||mpolacek at gcc dot gnu.org Last reconfirmed||2021-07-23 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Taking: will be fixed with my patch https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575580.html $ xg++ -c nullptr46.C -Wlogical-op nullptr46.C: In function ‘bool bar()’: nullptr46.C:10:17: error: ordered comparison of pointer with integer zero (‘std::nullptr_t’ and ‘std::nullptr_t’) 10 | return foo () > nullptr || foo () < nullptr; | ~~~^ nullptr46.C:10:37: error: ordered comparison of pointer with integer zero (‘std::nullptr_t’ and ‘std::nullptr_t’) 10 | return foo () > nullptr || foo () < nullptr; | ~~~^
[Bug c++/101592] ICE in wide_int_to_tree, at tree.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101592 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- True, but only on the trunk, I assume we don't want to backport changes which will reject previously accepted (albeit invalid) code. I think for gcc 11 we want to return NULL_TREE in fold_const.c (make_range_step) in the comparison cases if TREE_CODE (arg0_type) == NULLPTR_TYPE. Completely untested: --- gcc/fold-const.c2021-07-15 18:50:52.590821814 +0200 +++ gcc/fold-const.c2021-07-23 16:19:20.983128939 +0200 @@ -5010,7 +5010,8 @@ make_range_step (location_t loc, enum tr being not equal to zero; "out" is leaving it alone. */ if (low == NULL_TREE || high == NULL_TREE || ! integer_zerop (low) || ! integer_zerop (high) - || TREE_CODE (arg1) != INTEGER_CST) + || TREE_CODE (arg1) != INTEGER_CST + || TREE_CODE (arg0_type) == NULLPTR_TYPE) return NULL_TREE; switch (code)
[Bug libstdc++/101599] ranges::copy_or_move missing std::move for input_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101599 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-07-23 Target Milestone|--- |10.4 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Patrick Palka --- Indeed
[Bug c++/101592] ICE in wide_int_to_tree, at tree.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101592 --- Comment #3 from Marek Polacek --- Thanks, I'll test that sometime soon.
[Bug c++/101601] New: [12 Regression] -Wall is reported as a build error (not warning): error: arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101601
Bug ID: 101601
Summary: [12 Regression] -Wall is reported as a build error
(not warning): error: arrays of functions are not
meaningful
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
The example is extracted from wine-6.13 build failure against gcc-master.
Here is the smaller example:
$ cat a.c
// x86_64-pc-linux-gnu-gcc -m32 -c -o a.o a.c -Wall -pipe -O2
typedef void f(void);
void args(void*);
f *SSCall_fun;
void SSCall(void) { args(&SSCall_fun + 1); }
$ ./xgcc -B. -m32 -c -o a.o a.c -Wall -pipe -O2
a.c: In function 'SSCall':
a.c:5:6: error: arrays of functions are not meaningful
5 | void SSCall(void) { args(&SSCall_fun + 1); }
| ^~
Note1: -Wall turns successful build into build failure.
I think it's not expected: it should still be a warning (or an unconditional
error).
$ ./xgcc -B. -m32 -c -o a.o a.c -Wall -pipe
$ ./xgcc -B. -m32 -c -o a.o a.c -pipe -O2
$ gcc-11.1.0 -m32 -c -o a.o a.c -Wall -pipe -O2
Note2: -O2 vs. -O0 causes warning to go away (maybe it's ok).
$ ./xgcc -B. -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64
--prefix=/tmp/gcc-build/../gcc-native-quick-installed --disable-nls
--without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp
--disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS='-O1 '
CXXFLAGS='-O1 '
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210723 (experimental) (GCC)
[Bug fortran/101602] New: local and local_init are not supported in DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101602 Bug ID: 101602 Summary: local and local_init are not supported in DO CONCURRENT Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Fortran 2018 (https://j3-fortran.org/doc/year/18/18-007r1.pdf) has three locality specifiers: shared, local and local_init. GCC Fortran does not support any of these. This breaks user experience for Fortran programmers using DO CONCURRENT code that works with other compilers. OpenMP supports equivalent locality specifiers already so the internal capability for this surely exists in GCC. program bug implicit none integer :: i, j, k integer, dimension(100) :: x j = 20 k = 30 x = 7 do concurrent (i=1:10) shared(x) k = k + x(i) j = k end do do concurrent (i=1:10) local(j) k = k + x(i) j = k end do do concurrent (i=1:10) local_init(k) k = k + x(i) j = k end do print*,k end program bug % gfortran-11 bug.F bug.F:8:31: 8 | do concurrent (i=1:10) shared(x) | 1 Error: Syntax error in DO statement at (1) bug.F:11:11: 11 | end do | 1 Error: Expecting END PROGRAM statement at (1) bug.F:12:31: 12 | do concurrent (i=1:10) local(j) | 1 Error: Syntax error in DO statement at (1) bug.F:15:11: 15 | end do | 1 Error: Expecting END PROGRAM statement at (1) bug.F:16:31: 16 | do concurrent (i=1:10) local_init(k) | 1 Error: Syntax error in DO statement at (1) bug.F:19:11: 19 | end do | 1 Error: Expecting END PROGRAM statement at (1) % gfortran-11 --version GNU Fortran (Homebrew GCC 11.1.0_1) 11.1.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 --- Comment #4 from qinzhao at gcc dot gnu.org --- I applied the attached patch and tested CPU2017 with -ftrivial-auto-var-init=pattern, now all the corresponding C++ failures get resolved.
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
> struct A { char a; };
> struct B : virtual A {};
> struct C : B {};
>
> void
> foo ()
> {
> C c;
> __builtin_clear_padding (&c);
> }
is the bug related to virtual table in the object? what's the root cause of the
failure? thanks.
[Bug middle-end/101601] [12 Regression] -Wall is reported as a build error (not warning): error: arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101601 Marek Polacek changed: What|Removed |Added Component|c++ |middle-end Last reconfirmed||2021-07-23 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- This comes from array_bounds_checker::check_array_bounds -> not a FE issue.
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 --- Comment #6 from Jakub Jelinek --- It is related to the weird FIELD_DECLs the C++ FE creates for the virtual inheritence, there is e.g. a FIELD_DECL with B type (where B has 16 byte size and includes the 8 byte virtual pointer and 1 byte A), but the size of the FIELD_DECL is just 8 bytes, which is something the clear padding code didn't expect to see. BTW, if you are using the clear padding code for -ftrivial*, unless it is clear_type_padding_in_mask, it can error e.g. on flexible array members, which is fine for the builtin, but probably not fine for -ftrivial*.
[Bug ada/101575] [gcc-11, -gdwarf-4] Missing .file directive causes invalid line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575 --- Comment #10 from Eric Botcazou --- > I can of course make the .loc go away. If you really want that. > > It is basically the DECL_SOURCE_LOCATION of an > otherwise ignored decl. If the DECL_SOURCE_LOCATION > is UNKNOWN_LOCATION the function should have no line info, > and gdb should be able not to step into this function. But that's not the original design, which is that a DECL_IGNORED_P function does not have .loc directives, like any other debugging information.
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 --- Comment #7 from Qing Zhao --- > On Jul 23, 2021, at 10:10 AM, jakub at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 > > --- Comment #6 from Jakub Jelinek --- > It is related to the weird FIELD_DECLs the C++ FE creates for the virtual > inheritence, there is e.g. a FIELD_DECL with B type (where B has 16 byte size > and includes the 8 byte virtual pointer and 1 byte A), but the size of the > FIELD_DECL is just 8 bytes, which is something the clear padding code didn't > expect to see. So, is such type information generated by C++FE correct? > > BTW, if you are using the clear padding code for -ftrivial*, unless it is > clear_type_padding_in_mask, it can error e.g. on flexible array members, which > is fine for the builtin, but probably not fine for -ftrivial*. I noticed this, and then I fixed this by adding a third argument for __builtin_clear_padding to indicate whether it’s for auto init or not. If for auto init, then not emit the error, is this fix good? (BTW, what’s clear_type_padding_in_mask try to do? Should I use it instead?)
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 --- Comment #8 from Jakub Jelinek --- (In reply to Qing Zhao from comment #7) > So, is such type information generated by C++FE correct? Yes. It is needed that way to follow the Itanium C++ ABI. > > BTW, if you are using the clear padding code for -ftrivial*, unless it is > > clear_type_padding_in_mask, it can error e.g. on flexible array members, > > which > > is fine for the builtin, but probably not fine for -ftrivial*. > > I noticed this, and then I fixed this by adding a third argument for > __builtin_clear_padding to indicate whether it’s for auto init or not. > If for auto init, then not emit the error, is this fix good? > > (BTW, what’s clear_type_padding_in_mask try to do? Should I use it instead?) I'd need to see a patch. The builtin itself has a single argument and shouldn't accept more than one, gimple_fold_builtin_clear_padding has also just a single argument. clear_type_padding_in_mask doesn't emit code to clear any memory, but fills in an array with bitmask which bits contain padding and which don't.
[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #9 from Qing Zhao ---
> On Jul 23, 2021, at 10:34 AM, jakub at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
>
> --- Comment #8 from Jakub Jelinek ---
> (In reply to Qing Zhao from comment #7)
>> So, is such type information generated by C++FE correct?
>
> Yes. It is needed that way to follow the Itanium C++ ABI.
Okay. I see.
Then with such type info, can clear_type_padding fill all the paddings for such
type?
>
>>> BTW, if you are using the clear padding code for -ftrivial*, unless it is
>>> clear_type_padding_in_mask, it can error e.g. on flexible array members,
>>> which
>>> is fine for the builtin, but probably not fine for -ftrivial*.
>>
>> I noticed this, and then I fixed this by adding a third argument for
>> __builtin_clear_padding to indicate whether it’s for auto init or not.
>> If for auto init, then not emit the error, is this fix good?
>>
>> (BTW, what’s clear_type_padding_in_mask try to do? Should I use it instead?)
>
> I'd need to see a patch.
Do you want me send my current patch to you for some comments for this part?
Then I can email to you with a separate email.
> The builtin itself has a single argument and
> shouldn't accept more than one, gimple_fold_builtin_clear_padding has also
> just
> a single argument.
Currently, in gimplification phase, we already added one more argument to this
call: (gimplify.c)
case BUILT_IN_CLEAR_PADDING:
if (call_expr_nargs (*expr_p) == 1)
{
/* Remember the original type of the argument in an internal
dummy second argument, as in GIMPLE pointer conversions are
useless. */
p = CALL_EXPR_ARG (*expr_p, 0);
*expr_p
= build_call_expr_loc (EXPR_LOCATION (*expr_p), fndecl, 2, p,
build_zero_cst (TREE_TYPE (p)));
return GS_OK;
=
So, I just added one more argument in the above to distinguish the auto init.
> clear_type_padding_in_mask doesn't emit code to clear any
> memory, but fills in an array with bitmask which bits contain padding and
> which
> don't.
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug libstdc++/101599] ranges::copy_or_move missing std::move for input_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101599
--- Comment #2 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #0)
>
> We should std::move __first to recursive ranges::__copy_or_move() call since
> some input_iterator such as basic_istream_view::iterator does not have the
> copy constructor.
>
And ranges::reverse_copy also forgets std::move for the
std::weakly_incrementable _Out.
#include
struct I {
using value_type = int;
using difference_type = std::ptrdiff_t;
I() = default;
I(I&&) = default;
I(const I&) = delete;
I& operator=(I&&) = default;
I& operator++();
I operator++(int);
value_type& operator*() const;
bool operator==(const I&) const;
};
int main() {
std::ranges::reverse_copy(std::array{}, I{});
}
https://godbolt.org/z/9Mfb1h3ad
[Bug middle-end/101601] [12 Regression] -Wall is reported as a build error (not warning): error: arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101601 Sergei Trofimovich changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Sergei Trofimovich --- Bisected down to r12-2132 "Correct handling of variable offset minus constant in -Warray-bounds [PR100137]"
[Bug middle-end/56337] __attribute__((aligned(N))) breaks for N=1<<28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56337 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Target||x86_64-linux-gnu --- Comment #3 from Andrew Pinski --- x86_64: [apinski@xeond2 gcc]$ ~/upstream-gcc/bin/gcc t.c -O2 -S -o - -fcommon .file "t.c" .text .comm d,512,4026531840 .comm c,512,134217728 .comm b,512,67108864 .comm a,512,33554432 .ident "GCC: (GNU) 12.0.0 20210710 (experimental) [master revision 783ce7c191d:c9543701c18:eaa5225c686d496244a6614ba2aacbf02e0f4daa]" .section.note.GNU-stack,"",@progbits aarch64: ubuntu@ubuntu:~/src/upstream-gcc-aarch64/gcc/objdir/gcc\# gcc t.c -o - -fcommon -S .arch armv8-a .file "t.c" .text .comm a,512,33554432 .comm b,512,67108864 .comm c,512,134217728 .comm d,512,268435456 .ident "GCC: (GNU) 12.0.0 20210721 (experimental) [master revision ccf3e245d4e:8edb685b0dd:a50b951c25631b9c3a5dbfa89488e84117961be1]" .section.note.GNU-stack,"",@progbits - CUT - So it looks like the problem is in the printing out the alignment for x86_64.
[Bug c++/101597] [12 Regression] ICE in pretty-printer formatting an OBJ_TYPE_REF since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101597 Martin Sebor changed: What|Removed |Added Component|tree-optimization |c++ Summary|[12 Regression] ICE in evrp |[12 Regression] ICE in |since |pretty-printer formatting |r12-2132-ga110855667782dac |an OBJ_TYPE_REF since ||r12-2132-ga110855667782dac --- Comment #1 from Martin Sebor --- The ICE happens in a call to inform(..., "...%qE...", allocfn) with allocfn set to the OBJ_TYPE_REF argument below. The pretty-printer winds up passing the argument to resolve_virtual_fun_from_obj_type_ref() in cp/error.c which computes a null pointer that it eventually dereferences. The inform() call looks valid to me so the bug is most likely in the C++ frond end's pretty-printer. QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea987bd0 method basetype arg-types chain chain >>> pointer_to_this > public unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea987f18> arg:0 public unsigned type_6 DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 5 canonical-type 0x7fffea952498 pointer_to_this > visited def_stmt _12 = *_11; version:12 ptr-info 0x7fffea9d5f30> arg:1 public unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 7 canonical-type 0x7fffea98f000 pointer_to_this > def_stmt pluginScriptObjectFromPluginViewBase_pluginWidget.2_9 = ASSERT_EXPR ; version:9 ptr-info 0x7fffea9d9000> arg:2 constant 0>>
[Bug target/56337] __attribute__((aligned(N))) breaks for N=1<<28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56337
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|middle-end |target
--- Comment #4 from Andrew Pinski ---
The problem is in the x86_64 backend. It uses int align when it should have
been unsigned align.
I have a patch:
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 51376fcc454..d8dac87c61b 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -325,9 +325,9 @@ struct ix86_address
extern int ix86_decompose_address (rtx, struct ix86_address *);
extern int memory_address_length (rtx, bool);
extern void x86_output_aligned_bss (FILE *, tree, const char *,
- unsigned HOST_WIDE_INT, int);
+ unsigned HOST_WIDE_INT, unsigned);
extern void x86_elf_aligned_decl_common (FILE *, tree, const char *,
-unsigned HOST_WIDE_INT, int);
+unsigned HOST_WIDE_INT, unsigned);
#ifdef RTX_CODE
extern void ix86_fp_comparison_codes (enum rtx_code code, enum rtx_code *,
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ff96134fb37..ad5717b3c57 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -837,7 +837,7 @@ x86_64_elf_unique_section (tree decl, int reloc)
void
x86_elf_aligned_decl_common (FILE *file, tree decl,
const char *name, unsigned HOST_WIDE_INT size,
- int align)
+ unsigned align)
{
if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
&& size > (unsigned int)ix86_section_threshold)
@@ -858,7 +858,7 @@ x86_elf_aligned_decl_common (FILE *file, tree decl,
void
x86_output_aligned_bss (FILE *file, tree decl, const char *name,
- unsigned HOST_WIDE_INT size, int align)
+ unsigned HOST_WIDE_INT size, unsigned align)
{
if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
&& size > (unsigned int)ix86_section_threshold)
[Bug middle-end/101601] [12 Regression] -Warray-bounds triggers error: arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101601 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||diagnostic Target Milestone|--- |12.0 Summary|[12 Regression] -Wall is|[12 Regression] |reported as a build error |-Warray-bounds triggers |(not warning): error: |error: arrays of functions |arrays of functions are not |are not meaningful |meaningful | --- Comment #3 from Martin Sebor --- -Warray-bounds triggers the error while formatting the type of SSCall_fun. For simplicity, it converts the type of each singleton object into a one-element array of its type, but the code is wrong for function pointers.
[Bug c/87683] Inline asm input/output operand does not prevent compiler optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Newlib has been fixed since https://sourceware.org/legacy-ml/newlib/2018/msg01061.html So closing as moved.
[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8408d34570c9fe9f3d22a25a76df2a4c64f08477 commit r12-2499-g8408d34570c9fe9f3d22a25a76df2a4c64f08477 Author: Jakub Jelinek Date: Fri Jul 23 19:55:16 2021 +0200 expmed: Fix store_integral_bit_field [PR101562] Our documentation says that paradoxical subregs shouldn't appear in strict_low_part: '(strict_low_part (subreg:M (reg:N R) 0))' This expression code is used in only one context: as the destination operand of a 'set' expression. In addition, the operand of this expression must be a non-paradoxical 'subreg' expression. but on the testcase below that triggers UB at runtime store_integral_bit_field emits exactly that. The following patch fixes it by ensuring the requirement is satisfied. 2021-07-23 Jakub Jelinek PR rtl-optimization/101562 * expmed.c (store_integral_bit_field): Only use movstrict_optab if the operand isn't paradoxical. * gcc.c-torture/compile/pr101562.c: New test.
[Bug rtl-optimization/101562] [9/10/11 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in |in insert, at |insert, at wide-int.cc:682 |wide-int.cc:682 | --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug preprocessor/96842] enhancement: copy clang Wheader-guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|c |preprocessor
[Bug c/99156] __builtin_expect is folded too soon allowing an non-integer-constant-expr to become an integer-const-expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99156
Andrew Pinski changed:
What|Removed |Added
Summary|__builtin_expect affects|__builtin_expect is folded
|the interpretation of its |too soon allowing an
|first operand |non-integer-constant-expr
||to become an
||integer-const-expr
CC||pinskia at gcc dot gnu.org
--- Comment #3 from Andrew Pinski ---
Here is another example which shows the problem even further:
int maybe_vla(int n) {
goto label;
int arr[__builtin_expect(n-n, 0)];
label:
return sizeof(arr);
}
int main() { return maybe_vla(0); }
CUT
Basically __builtin_expect is folded too soon which allows the argument to be
considered a constant integer expression :).
[Bug c++/32143] decl rtl generated with incorrect visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32143 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=39175 --- Comment #1 from Andrew Pinski --- I want to say this was fixed when PR 39175 was fixed. That is for 4.2 we get: . @GOTPCREL(%rip), %rax movl(%rax), %eax While in 4.4.0 and above we get: movl_ZN12_GLOBAL__N_11iE(%rip), %eax
[Bug c++/45501] Compiler does not find template function if member is addressed with "this"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45501 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Status|NEW |RESOLVED Target Milestone|--- |7.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed in GCC 7 and above.
[Bug fortran/101536] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101536 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e314cfc371d8b2405a1d81e51b90f9fb24b9061f commit r12-2500-ge314cfc371d8b2405a1d81e51b90f9fb24b9061f Author: Harald Anlauf Date: Fri Jul 23 21:00:10 2021 +0200 Fortran: extend check for array arguments and reject CLASS array elements. gcc/fortran/ChangeLog: PR fortran/101536 * check.c (array_check): Adjust check for the case of CLASS arrays. gcc/testsuite/ChangeLog: PR fortran/101536 * gfortran.dg/pr101536.f90: New test.
[Bug c++/45374] template keyword incorrectness// failure to parse valid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45374 --- Comment #4 from Andrew Pinski --- clang rejects the code in a similar way as GCC does: :23:27: error: 'MyClass<6>::MyFunc' is not a member of class 'MyDerivedClass' return ptr->MyClass::MyFunc(); ^ :31:33: note: in instantiation of function template specialization 'MyTemplatedFunction' requested here std::cout << "Next time: " << MyTemplatedFunction() << std::endl; ^ 1 error generated. I wonder if there is a DR report about this.
[Bug c++/101603] New: [meta-bug] pointer to member functions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 Bug ID: 101603 Summary: [meta-bug] pointer to member functions issues Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Pointer to member functions seems like an area where there are many issues so let's link them all to one bug.
[Bug c++/83137] Member function pointer template parameter not constant expression when set to nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83137 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |8.0 Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed in GCC 8.0.
[Bug c++/83912] [constexpr] struct with a pointer to one of its members, returned by a function, is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83912 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Keywords||rejects-valid Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed in GCC 10 and above.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 83912, which changed state. Bug 83912 Summary: [constexpr] struct with a pointer to one of its members, returned by a function, is not a constant expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83912 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c/97548] [11 Regression] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 Martin Sebor changed: What|Removed |Added Summary|bogus -Wvla-parameter on a |[11 Regression] bogus |bound expression involving |-Wvla-parameter on a bound |a parameter |expression involving a ||parameter --- Comment #5 from Martin Sebor --- GCC 10 doesn't warn (it doesn't provide -Wvla-parameter) so it's a regression.
[Bug c++/81678] Variadic template parameters containing pointer to member function fail to be parsed unless name of the parameter is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81678 --- Comment #2 from Andrew Pinski --- clang gives a warning now: :2:22: warning: ISO C++11 requires a parenthesized pack declaration to have a name [-Wanonymous-pack-parens] void f (void (T::*...)()) ^ So maybe GCC is correct, clang just has an extension.
[Bug c/101604] New: [meta-bug] bogus/missing -Wvla-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604 Bug ID: 101604 Summary: [meta-bug] bogus/missing -Wvla-parameter Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta-bug for false positives and negatives in and enhancements for -Wvla-parameter, new in GCC 11.
[Bug c/101604] [meta-bug] bogus/missing -Wvla-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-07-23 Keywords||diagnostic, meta-bug Alias||Wvla-parameter
[Bug c++/84287] pointer to member function type with dependent parameter cannot be mangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84287 Andrew Pinski changed: What|Removed |Added Blocks||101603 Last reconfirmed|2018-02-08 00:00:00 |2021-7-23 --- Comment #2 from Andrew Pinski --- clang mangles the function as: _Z1gIiEiT_PDTscM1SFvRKS0_EadL_ZNS1_1fERKiEE Which demangles as: int g(int, decltype (static_cast(&S::f))) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 [Bug 101603] [meta-bug] pointer to member functions issues
[Bug c++/92969] Segmentation fault compiling partial specialization of auto-deduced member function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92969 Andrew Pinski changed: What|Removed |Added Blocks||101603 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84287 Last reconfirmed||2021-07-23 Ever confirmed|0 |1 URL|https://godbolt.org/z/iypUQ | |B | Host|4.4.0-17763-Microsoft | Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- Maybe related to PR 84287. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 [Bug 101603] [meta-bug] pointer to member functions issues
[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485 Andrew Pinski changed: What|Removed |Added Blocks||101603, 55004 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Andrew Pinski --- Fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 [Bug 101603] [meta-bug] pointer to member functions issues
[Bug c++/101603] [meta-bug] pointer to member functions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 Bug 101603 depends on bug 80485, which changed state. Bug 80485 Summary: rejects-valid: constexpr static_cast of pointer-to-member-function to bool https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 80485, which changed state. Bug 80485 Summary: rejects-valid: constexpr static_cast of pointer-to-member-function to bool https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/101465] Poorly worded error from a call to a pointer-to-member function not wrapped in parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101465 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2021-07-15 00:00:00 |2021-7-23 --- Comment #2 from Andrew Pinski --- clang outputs something which is worse than even GCC does: :6:18: error: called object type 'void (foo::*)()' is not a function or function pointer x->*myfuncptr(); ~^ 1 error generated.
[Bug c/97548] [11 Regression] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548
--- Comment #6 from Martin Sebor ---
The fix isn't very robust since it only handles redeclarations with VLA
parameters that involve bounds that have the same name but not nontrivial
expressions involving different names, like in this case:
$ cat pr97548-c6.c && gcc -S -Wall pr97548-c6.c
void g (int k, int [k + 1]);
void g (int m, int [m + 1]) { } // bogus warning
pr97548-c6.c:2:16: warning: argument 2 of type ‘int[m + 1]’ declared with
mismatched bound ‘m + 1’ [-Wvla-parameter]
2 | void g (int m, int [m + 1]) { } // bogus warning
|^~~
pr97548-c6.c:1:16: note: previously declared as ‘int[k + 1]’ with bound ‘k + 1’
1 | void g (int k, int [k + 1]);
|^~~
[Bug c++/51405] [9/10/11/12 Regression] Passing method result to constructor treated as function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51405 Andrew Pinski changed: What|Removed |Added Host|ubuntu 11.10| Known to fail||9.1.0 Keywords||rejects-valid Last reconfirmed|2011-12-04 00:00:00 |2021-7-23 Summary|Passing method result to|[9/10/11/12 Regression] |constructor treated as |Passing method result to |function declaration|constructor treated as ||function declaration Target Milestone|--- |9.5 Target|i386| --- Comment #3 from Andrew Pinski --- We started to reject the code in GCC 9 with: : In function 'int main()': :43:8: error: trailing return type only available with '-std=c++11' or '-std=gnu++11' 43 | A a (B::Instance ()->Something ()); |^ And if I use -std=c++11 we get: : In function 'int main()': :43:8: error: 'parameter' function with trailing return type not declared with 'auto' type specifier 43 | A a (B::Instance ()->Something ()); |^ In GCC 8.0 and before we do get the incorrect code gen. I suspect this regressed when the start of the C++11 support (-std=c++0x) was added to the parser.
[Bug c/101289] [11 Regression] bogus -Wvla-paramater warning when using const for vla param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289 Martin Sebor changed: What|Removed |Added Summary|bogus -Wvla-paramater |[11 Regression] bogus |warning when using const|-Wvla-paramater warning |for vla param |when using const for vla ||param --- Comment #5 from Martin Sebor --- I'll backport the patch into GCC 11.
[Bug c++/10118] Bad diagnostic with cast in template argument expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10118
Andrew Pinski changed:
What|Removed |Added
Blocks||101603
Last reconfirmed|2005-12-11 23:07:23 |2021-7-23
--- Comment #11 from Andrew Pinski ---
We get now:
:7:26: error: 'void (B::*)(){((void (B::*)())A::foo), 0}' is not a
valid template argument for type 'void (B::*)()'
7 | CT c;
| ^
:7:26: note: it must be a pointer-to-member of the form '&X::Y'
ASM generation compiler returned: 1
:7:26: error: 'void (B::*)(){((void (B::*)())A::foo), 0}' is not a
valid template argument for type 'void (B::*)()'
7 | CT c;
| ^
:7:26: note: it must be a pointer-to-member of the form '&X::Y'
Execution build compiler returned: 1
While clang produces:
:7:11: error: non-type template argument is not a pointer to member
constant
CT c;
^~~
1 error generated.
ASM generation compiler returned: 1
:7:11: error: non-type template argument is not a pointer to member
constant
CT c;
^~~
Both are not obvious but gcc is still worse as it has the "{((void
(B::*)())A::foo), 0}" part there still.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
[Bug 101603] [meta-bug] pointer to member functions issues
[Bug c/101605] New: bogus -Wvla-parameter in same bound expression with differently named parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101605
Bug ID: 101605
Summary: bogus -Wvla-parameter in same bound expression with
differently named parameters
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Even with pr97548 and pr 101585 resolved there are a few outstanding
-Wvla-parameter false positives as the test case below shows:
$ (set -x && cat u.c && gcc -S -Wall u.c && gcc -S -Wall -fsanitize=undefined
u.c)
+ cat u.c
void f (int m, int (*)[m]);
void f (int n, int (*)[n]) { } // bogus warning with -fsanitize=undefined
void g (int m, int (*)[m + 1]);
void g (int n, int (*)[n + 1]) { } // bogus warning either way
+ gcc -S -Wall u.c
u.c:5:16: warning: mismatch in bound 1 of argument 2 declared as ‘int (*)[n +
1]’ [-Wvla-parameter]
5 | void g (int n, int (*)[n + 1]) { } // bogus warning either way
|^~
u.c:4:16: note: previously declared as ‘int (*)[m + 1]’
4 | void g (int m, int (*)[m + 1]);
|^~
+ gcc -S -Wall -fsanitize=undefined u.c
u.c:2:16: warning: mismatch in bound 1 of argument 2 declared as ‘int (*)[(long
int)(n) - 1]’ [-Wvla-parameter]
2 | void f (int n, int (*)[n]) { } // bogus warning with
-fsanitize=undefined
|^~
u.c:1:16: note: previously declared as ‘int (*)[(long int)(m) - 1]’
1 | void f (int m, int (*)[m]);
|^~
u.c:5:16: warning: mismatch in bound 1 of argument 2 declared as ‘int (*)[(long
int)(n + 1) - 1]’ [-Wvla-parameter]
5 | void g (int n, int (*)[n + 1]) { } // bogus warning either way
|^~
u.c:4:16: note: previously declared as ‘int (*)[(long int)(m + 1) - 1]’
4 | void g (int m, int (*)[m + 1]);
|^~
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|anlauf at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug c++/80575] unnecessary virtual function table support in member function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80575 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Resolution|--- |FIXED Blocks||101603 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 10. Most likely fixed by r10-1332. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 [Bug 101603] [meta-bug] pointer to member functions issues
[Bug c++/101603] [meta-bug] pointer to member functions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 Bug 101603 depends on bug 80575, which changed state. Bug 80575 Summary: unnecessary virtual function table support in member function call https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80575 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/78609] invalid member's visibility detection in constexpr with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78609
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-07-23
Summary|invalid member's visibility |invalid member's visibility
|detection in constexpr |detection in constexpr with
||arrays
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
Confirmed. The problem is with taking the address of a field and templates.
Here is a reduced testcase:
struct A
{
private:
char data;
public:
constexpr const char *c_str() const { return &data; }
constexpr A(char const str) : data(str) {};
constexpr A() : data() {};
};
template
struct B
{
static const constexpr A name = A{'a'};
static const constexpr char * value = name.c_str();
};
template
const constexpr A B::name;
const char *c = B<0>::value;
CUT
If I make B a non-template, then it will work correctly.
[Bug c++/98038] ICE on invalid trying to recursively invoke a lambda object with operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98038
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
Target Milestone|--- |10.3
--- Comment #3 from Andrew Pinski ---
Fixed already.
: In instantiation of 'my_mem_fn(int (Dummy::*)()
const):: [with U = std::reference_wrapper; ARGS
= {}]':
:32:13: required from here
:17:30: error: 'operator()' not defined
17 | return operator()(pmf, p.get(),
std::forward(args)...);
|
~~^~~
ASM generation compiler returned: 1
: In instantiation of 'my_mem_fn(int (Dummy::*)()
const):: [with U = std::reference_wrapper; ARGS
= {}]':
:32:13: required from here
:17:30: error: 'operator()' not defined
17 | return operator()(pmf, p.get(),
std::forward(args)...);
|
~~^~~
Execution build compiler returned: 1
[Bug target/56337] __attribute__((aligned(N))) breaks for N=1<<28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56337 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-July/57 ||5967.html --- Comment #5 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575967.html
[Bug c++/69375] GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69375 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- Dup of bug 52099. *** This bug has been marked as a duplicate of bug 52099 ***
[Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099 Andrew Pinski changed: What|Removed |Added CC||eric at efcs dot ca --- Comment #1 from Andrew Pinski --- *** Bug 69375 has been marked as a duplicate of this bug. ***
[Bug c++/101603] [meta-bug] pointer to member functions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 Bug 101603 depends on bug 69375, which changed state. Bug 69375 Summary: GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69375 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040 --- Comment #6 from Andrew Pinski --- clang fails the same way.
[Bug c++/77601] error: cannot convert 'is_same' to 'const bool' in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77601 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.4 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed in GCC 6.4 and above.
[Bug c++/78246] Incorrect vector variable set but not used warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78246 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Fixed and is a dup of bug 78949. *** This bug has been marked as a duplicate of bug 78949 ***
[Bug c++/78949] incorrect "unused variable" warning with SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78949 Andrew Pinski changed: What|Removed |Added CC||zoltan at hidvegi dot com --- Comment #11 from Andrew Pinski --- *** Bug 78246 has been marked as a duplicate of this bug. ***
[Bug c++/78280] GCC incorrectly accepts assignment in bitfield width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78280 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |8.0 --- Comment #2 from Andrew Pinski --- Fixed when C++20 support for default member initializers for bit-fields was added.
[Bug middle-end/101600] [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600 Martin Sebor changed: What|Removed |Added Blocks||56456 Target Milestone|--- |12.0 Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Last reconfirmed||2021-07-23 Summary|Spurious -Warray-bounds |[12 Regression] Spurious ||-Warray-bounds downcasting ||a polymorphic pointer Known to work||11.1.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Known to fail||12.0 --- Comment #1 from Martin Sebor --- Thanks for the small test case! I can confirm the false positive. The IL looks (close to) the following: [local count: 80404472]: # p_1 = PHI if (p_1 != 0B) goto ; [100.00%] else goto ; [0.00%] [local count: 80404472]: iftmp.1_11 = &MEM[(struct S4 *)p_1 + -8B].D.2419; <<< -Warray-bounds except that p_1 is: p_1 = PHI <0B(3), p_9(D)(4)> The bug is in access_ref::get_ref () in not clearing the base0 flag, making -Warray-bounds think the pointer points to the first byte of a declared object. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/81152] False strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81152 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Resolution|--- |FIXED Target Milestone|--- |8.5 Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed in GCC 8.5 and above.
[Bug c++/89960] Implicit derived to base conversion considered type punning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89960 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- This is a dup of bug 86922. *** This bug has been marked as a duplicate of bug 86922 ***
[Bug c++/86922] Invoking templated PTMF on subclass gives false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86922 Andrew Pinski changed: What|Removed |Added CC||cassio.neri at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 89960 has been marked as a duplicate of this bug. ***
[Bug c++/101603] [meta-bug] pointer to member functions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 Bug 101603 depends on bug 89960, which changed state. Bug 89960 Summary: Implicit derived to base conversion considered type punning. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89960 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/81152] False strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81152 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #4 from Andrew Pinski --- Actually this is a dup of bug 94951. *** This bug has been marked as a duplicate of bug 94951 ***
[Bug c++/94951] [8/9 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94951 Andrew Pinski changed: What|Removed |Added CC||rrrlasse at hotmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 81152 has been marked as a duplicate of this bug. ***
