https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114569
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
Reproducer:
#include
auto x =
to_native(to_fixed_size(std::experimental::native_simd::mask_type()));
This converts a native SIMD mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022
--- Comment #8 from Jens Maurer ---
I understand we're in a tangled web of partially-complete class rules here,
but the standard does give you the expectation that the inner class is complete
at its closing brace:
[class.pre] p2 says:
"A class
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
Consider:
#include
struct X
{
struct Key
{
int x = 0;
bool operator==(const Key&) const = default;
std::size_t operator()(const Key&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106812
--- Comment #1 from Jens Maurer ---
Cross-reference: clang bug https://github.com/llvm/llvm-project/issues/57519
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
gcc accepts the following program:
struct S
{
S() = default;
S(const S&) = delete;
// int x = 0; // #3
};
int main()
{
try {
throw S(); // #1
} catch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106150
--- Comment #6 from Jens Maurer ---
Related clang bug: https://github.com/llvm/llvm-project/issues/56313
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following is valid, but yields an error with gcc 12.1:
struct A {
A() { }
};
struct V {
V() { };
~V() { }
};
struct S {
S();
~S() {}
union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
This is clearly a case of ambiguous lookup:
struct B {
static int foo(int);
};
struct B2 {
int foo();
};
struct D : private B, public B2 {
};
void f()
{
D d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #10 from Jens Maurer ---
I agree with Jonathan here: The difference is that "malloc" comes with the
compiler/library and cannot be replaced (within the scope of the C or C++
standards), but "operator new" is expressly specified to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #3 from Jens Maurer ---
"We treat the global operator new as not reading from global memory"
If I implement my own global "operator new" afresh, certainly it'll need to
access global memory, e.g. to read a global pointer to the heap
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following test case works correctly with gcc 10.3 (with any of -O0, -O1, or
-O3) and works with gcc 11.1 with -O0, but the assertion at #2 fires with gcc
11.1 with -O1 (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100430
--- Comment #4 from Jens Maurer ---
Thanks.
My take-away from the discussion is that -Warray-bounds triggers when there
might be a code path with bad behavior. Whether such a code path is detected
depends very much on the details of optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100430
--- Comment #2 from Jens Maurer ---
Why does the warning go away with -O3, then? If it's intentional, it should be
consistent once the optimization level is sufficient for the necessary static
analysis.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
This code triggers a -Warray-bounds warning in gcc 11.1 (gcc 9.3 was silent;
gcc 10 did show the warning). The test case is reduced from another case (not
shown) that only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52202
--- Comment #5 from Jens Maurer ---
Core issue 1299 resolved via http://wg21.link/p0727 does in fact
lifetime-extend the temporary in the example.
This bug report should therefore be closed without action.
(If a test case is missing that lifetim
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
My understanding of -Os is that it is aimed at reducing code size. It produces
code with suboptimal size for the constructor below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84699
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment #2
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
This is a (reduced) attempt at SFINAE, which fails with gcc 7.3:
struct S {
void f(const int&);
};
template
int g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80601
--- Comment #2 from Jens Maurer ---
(In reply to Jonathan Wakely from comment #1)
> Strictly speaking the compiler is correct that the type of sizeof(T) is not
> dependent, so for LP64 targets will always need a conversion to a narrower
> type.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The all-new gcc 7.1.0 has introduced a conversion warning in template
definition context when a value-dependent sizeof is used as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80599
--- Comment #1 from Jens Maurer ---
This is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70844 ;
please close.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
All-new gcc 7.1.0 delivers a -Wuseless-cast warning for inherited constructors
involving reference parameters that the user cannot do anything about. This
did not happen
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The all-new gcc 7.1.0 now shows this disturbing warning; gcc 6.3.0 didn't. It
seems unhelpful to issue an "unused function&qu
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code violates [dcl.type] paragraph 2 "at most one type-specifier
is allowed in a type-specifier-seq" (none of the except
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #18 from Jens Maurer ---
Then you should cheat on [dcl.constexpr] p5 by carving out the nullptr case:
constexpr void less_than(int *p1, int *p2)
{
if (p1 == nullptr && p2 == nullptr)
return false;
return (size_t)p1 < (size_t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following testcase gives a "defined but not used" warning for "f", but not
for "g". I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954
--- Comment #3 from Jens Maurer ---
Ok, thanks. So, this essentially says most/all AMD CPUs have bad general-reg
-> xmm move performance. Oh well.
Please close.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code goes through the stack instead of directly moving from the
register for "x" into (the low part of) &qu
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following program:
typedef unsigned char xmmb_t __attribute__((vector_size(16)));
void f()
{
xmmb_t bla = { };
xmmb_t x = { };
bla &= ~x;
}
yie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
--- Comment #2 from Jens Maurer ---
The whole point of flexible array members seems to be to save an allocation for
the array, with the precondition that the array size can be determined at
initialization time and stays fixed for the entire lifet
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
Testcase:
struct A {
~A();
};
struct S {
S() : i(0) { }
int i;
A a[];
};
$ g++ -v flex.cc
gcc version 6.1.0 (GCC)
flex.cc: In constructor ‘S::S()’:
flex.cc:6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70827
--- Comment #2 from Jens Maurer ---
A prominent use case is that std::unique_ptr in the parameter list of an
inherited constructor stops working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847
--- Comment #1 from Jens Maurer ---
This situation is similar to bug 70342, except that my testcase
- involves no -fsanitize=undefined,
- is shorter,
- hinges on "virtual", and
- is a regression vs. gcc 5.x.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
Testcase:
struct D
{
virtual D& f();
};
void g()
{
D d;
d.f().f().f().f().f().f().f().f().f().f().f().f().f().f().f()
#if 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685
--- Comment #4 from Jens Maurer ---
Works with 5.1.0 and 5.2.0, so this seems to be resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #16 from Jens Maurer ---
(In reply to Jason Merrill from comment #14)
> '-Wpedantic' does not cause warning messages for use of the
> alternate keywords whose names begin and end with '__'. Pedantic
> warnings are also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #8 from Jens Maurer ---
In general, "x" and "(x)" have the same meaning as per 5.1.1p6.
There are a few (spelled-out) exceptions, though.
One exception is inside a decltype-specifier, where decltype(e) is different
from decltype((e)
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
I would like to switch implementations depending on whether the (Intel) CPU has
AES instructions or not. Simplified testcase:
__attribute__((target("defau
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code wrongly prints 0 instead of the correct 1:
$ g++ -std=c++11 union.cc
$ ./a.out
0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685
Jens Maurer changed:
What|Removed |Added
Version|4.8.2 |4.9.2
--- Comment #3 from Jens Maurer ---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
The first example for function multiversioning given at
https://gcc.gnu.org/wiki/FunctionMultiVersioning crashes when compiled with
-flto.
Reduced example:
__attribute__ ((target ("default&quo
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Created attachment 32465
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32465&action=edit
source code to reproduce the issue
When compiling and linking the attached two files, I get a co
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Created attachment 32262
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32262&action=edit
Testcase showing superfluous arithmetic in assembly
The attached f
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Parameter objects are not destroyed when the called function returns, but later
(too late). The C++ standard says in 5.2.2p4 [expr.call]:
"... The lifetime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59248
--- Comment #2 from Jens Maurer ---
This one:
$ cat ~/x.cc
int main()
{
int x = 2*sizeof(int);
int y { 2* sizeof(int) };
}
(sorry, forgot to attach earlier)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
The simple case was fixed with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930 (thanks, Jason), but a
slightly more involved case still warns spuriously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930
Bug #: 56930
Summary: regression: pointless -Wconversion warning with sizeof
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55972
Bug #: 55972
Summary: cannot access private member from lambda used in NSDMI
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39102
--- Comment #2 from Jens Maurer 2012-11-23
14:07:34 UTC ---
Here is another test case:
struct S {
unsigned char * p;
unsigned char * limit;
};
S g(S s);
inline __attribute__((always_inline)) S f(S s, unsigned int n);
S f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446
Bug #: 55446
Summary: array new with size zero vanishes from object code
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54079
Bug #: 54079
Summary: __builtin_ia32_palignr128 can't be called
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689
--- Comment #6 from Jens Maurer 2012-03-27
07:03:46 UTC ---
$ nm
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a
| grep GLIBCXX_3.4.14
B _ZSt15future_category@@GLIBCXX_3.4.14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689
--- Comment #3 from Jens Maurer 2012-03-23
20:14:33 UTC ---
In case it matters, here's the "configure" info etc:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689
--- Comment #2 from Jens Maurer 2012-03-23
20:13:11 UTC ---
$ find /usr/lib -name "libstdc++.a"
/usr/lib/gcc/x86_64-linux-gnu/4.6/32/libstdc++.a
/usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a
/usr/lib/gcc/x86_64-linux-gnu/4.5/libstdc++.a
However
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689
Bug #: 52689
Summary: static linking with libstdc++ fails
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
Bug #: 52099
Summary: Incorrectly applying conversion when catching
pointer-to-members
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52057
Bug #: 52057
Summary: dropping "const" in assignment gives only a warning
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48577
--- Comment #1 from Jens Maurer 2011-04-12
16:39:03 UTC ---
It works with gcc 4.5.2, so it seems to be a 4.6 regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48577
Summary: "unexpected ast of kind unordered_expr" using isnan()
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188
--- Comment #6 from Jens Maurer 2010-10-27
13:15:19 UTC ---
Thanks. Yes, the testcase was reduced from preprocessed files. Unfortunately,
you can't remove the "#pragma interface" without breaking the testcase. But
the only documented effect th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188
--- Comment #6 from Jens Maurer 2010-10-27
13:15:19 UTC ---
Thanks. Yes, the testcase was reduced from preprocessed files. Unfortunately,
you can't remove the "#pragma interface" without breaking the testcase. But
the only documented effect th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188
--- Comment #4 from Jens Maurer 2010-10-27
07:55:37 UTC ---
Created attachment 22171
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22171
two "if" conditions removed from the testcase
Two "if" conditions increase the complexity of the assem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188
--- Comment #3 from Jens Maurer 2010-10-27
06:14:31 UTC ---
Created attachment 22170
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22170
improved testcase
The previous testcase had the problem that the compiler could legitimately
assume th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188
Jens Maurer changed:
What|Removed |Added
Attachment #22164|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188
Summary: -fipa-cp removes destructor call
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.
72 matches
Mail list logo
