https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253
Jan Schultke changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84796
--- Comment #7 from Jan Schultke ---
Recently rediscovered here: https://stackoverflow.com/q/79364196/5740428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84796
Jan Schultke changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118178
Bug ID: 118178
Summary: No overload resolution feedback for
copy-initialization which fails to call a converting
constructor
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118173
Bug ID: 118173
Summary: reinterpret_cast from const void* casts
away constness, but is accepted
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117515
--- Comment #1 from Jan Schultke ---
The issue is not limited to constructors or constructor templates, but seems to
be related to function-style casts containing lambdas inside static_assert:
> static_assert(requires { int([] {}); });
... is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116967
--- Comment #1 from Jan Schultke ---
I really like the Clang output by the way, which GCC could copy almost
directly:
> :2:5: warning: 'constinit' specifier missing on initializing
> declaration of 'x' [-Wmissing-constinit]
> 2 | int x;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116967
Bug ID: 116967
Summary: Accepts-invalid missing constinit specifier on
initializing declaration
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116727
Bug ID: 116727
Summary: "this" is unusable in an explicit object member
function lambda capturing this
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #12 from Jan Schultke ---
On a language evolution note, https://wg21.link/P2825 would let you detect
whether an equality comparison for enumerations is overloaded by checking
whether
> declcall(E{} == E{})
... is well-formed. If th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #8 from Jan Schultke ---
It is a tiny bit pessimistic if it uses std::convertible_to instead of
std::__boolean_testable or what it was called.
I cannot come up with an example that produces a false positive though (which
is crucial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #5 from Jan Schultke ---
&operator==(E,E); is not a valid expression, but I understand what you're
trying to do there. Perhaps you can test by converting to a function pointer
bool(*)(E,E).
It would surely miss cases like an operato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Jan Schultke changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115417
Bug ID: 115417
Summary: Destructor is noexcept even though the class has a
throwing destructor subobject in an anonymous union
Product: gcc
Version: 15.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115147
--- Comment #1 from Jan Schultke ---
I did some quick low-quality benchmarks. It doesn't seem to make any kind of
difference for libc++ and clang:
https://quick-bench.com/q/aq1mZ1sKTWHzdmZf5D7BO2yJ1Yo (or for libstdc++ and
clang)
For GCC and li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115147
Bug ID: 115147
Summary: exp2 with integer arguments could be translated into
ldexp
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085
--- Comment #4 from Jan Schultke ---
https://github.com/cplusplus/CWG/issues/536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085
--- Comment #1 from Jan Schultke ---
Another user suggested that this is caused by falsely performing temporary
materialization.
This would make a an xvalue, which would also make the reference binding fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085
Bug ID: 115085
Summary: Variable unqualified-id is falsely treated as rvalue
when appearing in braced-init-list
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 114219, which changed state.
Bug 114219 Summary: [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue
conversion is not diagnosed to disqualify constant expressions for empty classes
https://gcc.gnu.org/bugzilla/show_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219
Jan Schultke changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219
--- Comment #4 from Jan Schultke ---
I don't see how lvalue-to-rvalue conversion would be bypassed here.
https://eel.is/c++draft/conv.lval#:conversion,lvalue-to-rvalue has no special
provision for empty classes.
https://eel.is/c++draft/dcl.ini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219
--- Comment #2 from Jan Schultke ---
Corresponding LLVM bug: https://github.com/llvm/llvm-project/issues/83712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219
Bug ID: 114219
Summary: [expr.const] lvalue-to-rvalue conversion is not
diagnosed to disqualify constant expressions for empty
classes
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #5 from Jan Schultke ---
Well, it's not quite equivalent to either of the bit-shifts we've posted. To
account for shifting more than the operand size, it would be:
bool foo (int x)
{
return x > 6 ? 0 : ((85 >> x) & 1);
}
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #2 from Jan Schultke ---
Yeah right, the actual optimal output (which clang finds) is:
> test_switch(E):
> test edi, -7
> sete al
> ret
Testing with -7 also makes sure that the 8-bit and greater are all zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
Bug ID: 114086
Summary: Boolean switches could have a lot better codegen,
possibly utilizing bit-vectors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114006
Bug ID: 114006
Summary: False positive diagnostic -Wpedantic for zero-size
arrays, most vexing parse
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #2 from Jan Schultke ---
Oh yeah, I should have noted that this only happens for AVX-512 targets.
Changing -march=znver4 to -march=znver3 stops the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Bug ID: 113988
Summary: during GIMPLE pass: bitintlower: internal compiler
error: in lower_stmt, at gimple-lower-bitint.cc:5470
Product: gcc
Version: 14.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982
Bug ID: 113982
Summary: Poor codegen for 64-bit add with carry widening
functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113914
Bug ID: 113914
Summary: GCC accepts user-defined integer-literal that does not
fit in any type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Bug ID: 113821
Summary: Missed optimization for final classes: expensive check
for result of dynamic cast
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113745
Bug ID: 113745
Summary: Poor diagnostics quality for resize() without a
default-constructible type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
--- Comment #1 from Jan Schultke ---
Oh, I probably should have mentioned this: This only happens when times_three
is a function template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
Bug ID: 113581
Summary: Ignoring GCC unroll loop annotation for loops with
increment in condition
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
--- Comment #5 from Jan Schultke ---
You can reproduce this as follows:
> static_assert(__builtin_clz(0u) == 32);
>
> unsigned x = 0;
>
> int main() {
> return __builtin_clz(x);
> }
For base x86_64, GCC emits: (https://godbolt.org/z/nqz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
--- Comment #4 from Jan Schultke ---
I would expect an error here because things that are undefined behavior are
generally supposed to fail in constant expressions. I don't see a good reason
why builtins should be exempt from that rule.
The lac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
Bug ID: 113565
Summary: __builtin_clz(0) is undefined behavior, but not
detected in constant expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113564
Bug ID: 113564
Summary: ICE internal compiler error when calling a concept as
a function in a template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113543
Bug ID: 113543
Summary: Poor codegen for bit-counting functions (countl_zero,
countl_one, countr_zero, countr_one)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #7 from Jan Schultke ---
I've noticed that too by now. What confuses me is that both libc++ and MSVC STL
implement it as if it was a DR, so transparent comparisons work even outside
C++23 mode.
Is it just a collective mistake, or wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #5 from Jan Schultke ---
My bad again, it's a defect report, so cppreference is fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #4 from Jan Schultke ---
My bad. https://en.cppreference.com/w/cpp/utility/pair/operator_cmp currently
shows
> template< class T1, class T2, class U1, class U2 >
> bool operator==( const std::pair& lhs, const std::pair& rhs );
> (un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #1 from Jan Schultke ---
https://godbolt.org/z/9x9n4bGKK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
Bug ID: 113386
Summary: std::pair comparison operators should be transparent,
but are not in libstdc++
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113274
--- Comment #2 from Jan Schultke ---
OOPS, I've messed up the repro. It should be true in the partial
specialization.
https://godbolt.org/z/11dW3cTfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113274
--- Comment #1 from Jan Schultke ---
Original problem and more discussion:
https://stackoverflow.com/q/4976/5740428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113274
Bug ID: 113274
Summary: Memoization in template parameters is overly
aggressive; false memoization for const pointers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113242
Bug ID: 113242
Summary: g++ rejects-valid template argument of class type
containing an lvalue reference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662
--- Comment #2 from Jan Schultke ---
Bug was originally discovered here:
https://stackoverflow.com/questions/77214665/problem-creating-template-function-alias-with-const-value-template-arguments/77215223#77215223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662
--- Comment #1 from Jan Schultke ---
See https://godbolt.org/z/Kaf7jETaY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662
Bug ID: 111662
Summary: Rejects valid: cv-qualifiers are not removed from
function parameters of variadic templated function
types
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111277
Bug ID: 111277
Summary: braced-init-list allowed in a template-argument
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57905
Jan Schultke changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74
Bug ID: 74
Summary: G++ allows re-declaring function parameters as
functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73
--- Comment #2 from Jan Schultke ---
I think the problem is that GCC treats "constinit" exactly like "const" for the
purpose of diagnostics. In https://eel.is/c++draft/dcl.fct#11, it is said that
const applied to functions is ignored.
GCC produ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73
Bug ID: 73
Summary: G++ allows constinit functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111079
Bug ID: 111079
Summary: Failing to reject a defaulted/deleted local function
definition if it is a friend of a local class
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945
--- Comment #8 from Jan Schultke ---
(In reply to Jonathan Wakely from comment #4)
> Please provide the testcase in a usable form, not just a link to an external
> site (which uses its own custom benchmark macros). This is requested at
> https:/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945
--- Comment #3 from Jan Schultke ---
When increasing the input size to 8 MiB, the results become more similar to
what clang delivers for 1 MiB too:
https://quick-bench.com/q/DFHYW6eZq-FAif8xuLkBOPwzYWA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945
--- Comment #2 from Jan Schultke ---
Also it looks like GCC doesn't emit memcpy or memmove in either of the first
benchmarks. Those statements refer to the corresponding clang output, actually.
What's consistent for both compilers is that .assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945
Jan Schultke changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945
Bug ID: 110945
Summary: std::basic_string::assign dramatically slower than
other means of copying memory
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110912
--- Comment #2 from Jan Schultke ---
(In reply to Jiang An from comment #1)
> The restriction agains aliasing was intended, see
> https://cplusplus.github.io/CWG/issues/2271.html.
>
> The status quo seems to be that in the body of `A::A(int &x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110925
Bug ID: 110925
Summary: Unnecessary dynamic initialization in trivial cases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110916
Bug ID: 110916
Summary: [12/13/14 Regression] Architecture-dependent missed
optimizations for double swapping
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110912
Bug ID: 110912
Summary: False assumption that constructors cannot alias any of
their parameters
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
68 matches
Mail list logo
