https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98859
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #3 from
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
https://godbolt.org/z/rjMjeG7T1
template
concept vt = true;
vt auto v = 1;
| ^~
internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061
--- Comment #1 from Will Wray ---
Hmm, the accepted simplified version ^^^ with typename parameter removed
is then rejected if 'unsigned' is replaced with 'uint32_t' from
#include
template
struct uint_offset_bitfield { uint32_t :
: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
A very specific regression: https://godbolt.org/z/dWxnvd93j
template
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238
--- Comment #4 from Will Wray ---
First cut implementation in two patches, submitted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585105.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
Will Wray changed:
What|Removed |Added
Attachment #51828|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
Will Wray changed:
What|Removed |Added
Attachment #51737|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238
--- Comment #2 from Will Wray ---
(It was my own 'interesting suggestion' to myself; going stir crazy coding!)
(Apologies if I stirred anything other than thought.)
Thank you for emphasising the important point on DRs. It's true that some
C++ D
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
This is a feature-tracking PR for an incoming patch to implement
C++ proposal P1997 "Relaxing restrictio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103140
--- Comment #1 from Will Wray ---
Created attachment 51750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51750&action=edit
c++: __builtin_bit_cast To C array target type
Proposed patch, submitted here:
https://gcc.gnu.org/pipermail/gcc-p
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
__builtin_bit_cast(To,from) can usefully be made to materialise a C array
as its target type To:
__builtin_bit_cast( unsigned char[sizeof x], x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #11 from Will Wray ---
Created attachment 51737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51737&action=edit
Proposed patch Nov 4
Sent to gcc-patches for review
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #10 from Will Wray ---
Note that the initialization of 'c0' takes a different codepath:
struct C {char a[2];};
C c0{.a="a"}; // [dcl.init.aggr]
C c1{.a=""};
C c2{.a={"a"}};
C c3{.a={""}};
c1, c2 and c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #9 from Will Wray ---
Adding a reshape_iter, and checking has_designator_problem,
for a brace-enclosed string-literal fixes this secondary issue
+ reshape_iter e {CONSTRUCTOR_ELT (stripped_a_init, 0), e.cur + 1};
+ if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #8 from Will Wray ---
The patch above doesn't address the secondary issue,
of ignored and unchecked nested designators:
C b {{.bogus="b"}};
Perhaps reshape_init should be recursed into once more?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #7 from Will Wray ---
The patch below fixes the main issue (I think, checking)
by adding first_initializer_p to the error condition
it errors only where designators are not allowed.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95806
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #1 from
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
This fails to compile, going back many revisions, in any std version:
https://godbolt.org/z/Kz9Mnz9aW
#include
std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90031
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100231
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #1
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
GCC11 rejects:
constexpr decltype(auto) i = 0;
GCC>10 error: decltype(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96268
--- Comment #4 from Will Wray ---
This now appears fixed on 11 trunk
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
Same as bug 99436, submitting with [modules] subject and CE link
https://godbolt.org/z/8ME9d8
export module foo;
This works: -std=c++20
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
P0388 "Permit conversions to arrays of unknown bound" in C++20
does not explicitly discuss conversion back from unknown bound
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480
--- Comment #4 from Will Wray ---
Thanks Jakub;
I applied your patch to trunk and ran more test cases for
nested arrays (including zero-size in various positions),
union element type, base classes - all passed as expected.
I tried to grok the pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480
--- Comment #2 from Will Wray ---
For reference, here's a macro-free workaround to provide portable
operator<=> for templated classes with array members, defaulting
where possible (current Clang and MSVC) otherwise dispatching to
a user-defined i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #1 from
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
A deduced argument pack T... v now gives a
"mismatched argument pack lengths" error for T... and v...
i.e. static_assert( sizeof...(T) == sizeof...(v)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92411
--- Comment #4 from Will Wray ---
I mis-read this so was too hasty in suggesting "can be closed".
The standard states that a expression evaluation fails to be a constant
expression if it evaluates "reinterpret_cast" (i.e., by named token,
not by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92411
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96268
--- Comment #2 from Will Wray ---
Thanks Marek (and thanks again for implementing it) - it does seem so.
I've asked around a little - tcanens and brevzin point to a core issue
to do with NTTP CTAD but didn't offer an opinion or encourage this bug
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
I understand that gcc is ahead of the standard in its implementation of class-
type NTTP, along with CTAD and accepting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96252
--- Comment #1 from Will Wray ---
Here's the code, compiler invocation and codegen output.
The longer codegen expands memcpy to copy the std::array by-value arguments.
-fno-inline shows the compiler call the first function from the second, then
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
(Stumbled on this odd effect while examining codegen for operator<=>)
The reduced sample compiles c++11 and u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #9 from Will Wray ---
An earlier draft had __builtin_tuple_size as the magic behind the P2141
proposed std::tuple_size automagic generalization to Case 3 class types.
There was opposition to that name because it specifically doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #7 from Will Wray ---
Oops, __builtin_bit_cast available in MSVC and Clang (when in GCC?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #6 from Will Wray ---
Thanks for the comment on approach Jonathan:
I'd noticed some collaboration and agreement around previous builtins
such as __builtin_bit_cast which is now available in both GCC & Clang
(though with some small in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #2 from Will Wray ---
On the Clang ticket, linked above, Richard Smith comments:
Instead of the proposed direction, I'd suggest we (and other implementers)
prioritize implementation of https://wg21.link/p1061r1
(which is on its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96170
--- Comment #2 from Will Wray ---
A much better idea, submitted here as bug 96185
and simultaneously submitted to Clang and MSVC -
a portable builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #1 from Will Wray ---
Clang ticket https://bugs.llvm.org/show_bug.cgi?id=46704
MSVC ticket
https://developercommunity.visualstudio.com/idea/203/enhancement-please-add-a-builtin-to-count-bindings.html#
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
(Submitting simultaneous requests for each of GCC, Clang and MSVC.
Coordination between vendors will be beneficial for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96170
--- Comment #1 from Will Wray ---
Opened an equivalent enhancement request for Clang
https://bugs.llvm.org/show_bug.cgi?id=46691
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
Some sort of sfinae on statement expressions containing structured bindings
can provide a convenient way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862
--- Comment #8 from Will Wray ---
OK. I'll try to get full confirmation and clarification on legality,
with links to wording if possible, then open a new bug if valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862
--- Comment #6 from Will Wray ---
Thanks for the quick work.
However, I'm not sure that (2) and (3) _are_ invalid.
(Sorry, I didn't have time to follow the email thread).
I should have provided this link to an exchange with Richard Smith.
I'd wa
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
https://wandbox.org/permlink/ZaGwU3l7WbEc91Hw
1st line below an rvalue array binds, with lifetime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93191
--- Comment #4 from Will Wray ---
Reduced code for deduction of element type
for reference-to-array https://godbolt.org/z/tpkKjN:
int f(auto(&a)[1]);
int g(auto(&a)[ ]);
int test_f = f("");
int test_g = g(""); // error: no match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93191
--- Comment #2 from Will Wray ---
Actually, the issue now appears to be not with variadic args directly but with
deduction (variadic Args are necessarily deduced, whether via template Arg or
auto placeholder).
So, for single arg, this works with
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
The P0388 permitted conversion from array of known bound to
array-reference of unknown bound fails for variadic arguments
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91364
--- Comment #9 from Will Wray ---
The variadic unknown-bound 1st overload matches exact T(&)[] only
https://godbolt.org/z/9qZpWX
#include
void cat(auto const(&...cstr)[]) { (((void)cstr,puts("G'bye")),...); }
void cat(auto const(&...cstr)[6]) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91364
--- Comment #8 from Will Wray ---
Reduced example (but still with puts output) https://godbolt.org/z/Ttc2Za
#include
void cat(auto const(&...cstr)[]) { (puts(cstr),...); }
// Comment out this next line[6]
void cat(auto const(&..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91364
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92402
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
Will Wray changed:
What|Removed |Added
Attachment #45683|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #14 from Will Wray ---
I intend to submit a patch, or two patches, for these scalar braced init
issues:
Case 1: GCC rejects braced-init of scalars in aggregates. It should accept.
Case 2: GCC accepts empty braced-init of scalars (com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88170
--- Comment #7 from Will Wray ---
Thanks for the fix - apologies again for the break.
Works for me.
I'd lost the trail but see now that pp_c_flag_gnu_v3
is set in error.c calls
decl_as_dwarf_string
lang_decl_dwarf_name
in turn called from cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #13 from Will Wray ---
Re-reviewing, I notice that the patch I posted in comment #9
now rejects nested empty-brace scalar init:
int i{{}};
which was previously accepted. So we'll need a decision on this too.
Clang rejects with -p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #12 from Will Wray ---
On further investigation the logic of using first_initializer_p looks correct.
The comment on reshape_init suggests that it wasn't intended for scalar init:
/* Undo the brace-elision allowed by [dcl.init.aggr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #10 from Will Wray ---
Re: warnings; I certainly prefer to have this accepted with no warning
(i.e. remove the 'else if' warning in the patch above).
Saves having to disable the warning in GCC, as I have to do in Clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #9 from Will Wray ---
The patch below seems to work as far as I've tested - please review.
It looks like the bool first_initializer_p argument to reshape_init_r
gives the context that is needed, according to the function comment;
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #7 from Will Wray ---
I guess that the bug persisted so long *because* of the status quo;
portable code had to delete extra braces to silence warnings or to compile
i.e. the warning on Clang served the purpose of promoting portability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #5 from Will Wray ---
Right; the patch should only apply within aggregate initialization -
arrays and aggregate structures - as the initialization of actual scalars
was already correct.
I'll take a look now (as I meaning to fix my en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #12 from Will Wray ---
I can take a look at the weekend or early next week -
reproduce the test fails and diagnose some more.
I'll try to find answers to the questions I raised in comment #4
(about name mangling of enum types) and se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #1 from Will Wray ---
This bug is straightforward to confirm.
Compile this snippet (-std=c++11 / 14 / 17 / 2a):
struct S { int i; };
S s{{0}};
Gives error: braces around scalar initializer for type 'int'
Should be a wa
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
CC: bangerth at apex68 dot ticam.utexas.edu,
gcc-bugs at gcc dot gnu.org, loewis at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #6 from Will Wray ---
Created attachment 44811
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44811&action=edit
Patch v2, passes check_GNU_style
Submitted to gcc-patches mailing list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #5 from Will Wray ---
re: https://gcc.gnu.org/ml/gcc/2018-02/msg9.html
discussion on removing literal suffixes from Integral constants
(part a bigger conversation I'll pick up on below).
That change brought GCC into line with cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #4 from Will Wray ---
Thanks Martin,
I investigated enum template args with GCC bug 81932 test code,
repeating its GDB Python-debug-print test case for enum args.
Conclusion:
This change to enum printing does not cause GDB to fail t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #2 from Will Wray ---
Created attachment 44735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44735&action=edit
Test for enumerator id pretty print patch
pp_enum_test
auto_name returns std::array, splitting the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #1 from Will Wray ---
Created attachment 44734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44734&action=edit
Fix to pretty-print enumerator ids
c-pretty-print.c
c_pretty_printer::constant(tree)
Remove fall through f
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wjwray at gmail dot com
Target Milestone: ---
In c-pretty-print.c
c_pretty_printer::constant calls pp_c_enumeration_constant
75 matches
Mail list logo
