https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #4 from m.cencora at gmail dot com ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am not sure this is related to SFINAE though.
> >
> > Rather it is in an unevaluated context where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #6 from m.cencora at gmail dot com ---
Another argument for not showing the deprecation is that if I change:
string a;
to
const string a;
I don't get any deprecation warnings, but only for gcc-11+.
This means that internal implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #3 from m.cencora at gmail dot com ---
I think it should be marked rejects-valid because it makes valid program
ill-formed if compiled with -Werror. The problematic diagnostic is user-defined
but in code that is never reached, so shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #5 from m.cencora at gmail dot com ---
> I'd say that warning is not expected, because user's code didn't (directly
> or indirectly) call the deprecated constructor.
Or to state it differently: user calls the Bar(const string&) over
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
Bug ID: 117293
Summary: SFINAE in class partial specialization "leaks" its
side-effects
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
--- Comment #2 from m.cencora at gmail dot com ---
(In reply to m.cencora from comment #1)
> Also this is specific to types exported from GMF, if type is declared
> directly in named module it works fine, i.e.
>
> $ cat base.cpp
> export module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
--- Comment #1 from m.cencora at gmail dot com ---
Also this is specific to types exported from GMF, if type is declared directly
in named module it works fine, i.e.
$ cat base.cpp
export module base;
export
{
using int8_t = signed char;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
Bug ID: 115798
Summary: [15 Regression][modules] ICE when re-exporting a type
exported from base module's GMF
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #15 from m.cencora at gmail dot com ---
Thanks!
Unfortunately it seems that your changes broke reexporting of types declared in
other module. It works fine on gcc-14.
$ cat base.cpp
module;
#include
export module base;
export
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115445
--- Comment #1 from m.cencora at gmail dot com ---
Works fine on gcc-14 and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115446
Bug ID: 115446
Summary: [15 Regression] Segfault when exporting operator new
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115445
Bug ID: 115445
Summary: [15 Regression] ICE when repeating an export of
function declared in GMF
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114867
--- Comment #1 from m.cencora at gmail dot com ---
The unreduced code is actually a regression from gcc-12.
@Jonathan Wakely:
Could you maybe workaround it in libstdc++ by declaring the std::swap overload
for exception_ptr in additional inline n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
--- Comment #4 from m.cencora at gmail dot com ---
I've stumbled upon a related error when trying to export std::vector after
inclusion of in GMF:
module;
namespace std
{
class vector;
namespace __format {
using std::vector;
}
}
export module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114868
Bug ID: 114868
Summary: [modules] func declared in GMF and exported via
using-decl in module partition is not actually
exported
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114867
Bug ID: 114867
Summary: [modules] name lookup issues when a function overload
set is exported from GMF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
--- Comment #1 from m.cencora at gmail dot com ---
Oops, the -isystem and -std options are not necessary for reproduction.
This is enough:
$ g++ -fmodules-ts lldiv_t.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
m.cencora at gmail dot com changed:
What|Removed |Added
Attachment #57921|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #9 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)
> Thanks. I hope we'll end up auto-generating a file like that from
> ../gcc/cp/cxxapi-data.csv
Hmm, then that file will have to be extended because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
Bug ID: 114685
Summary: [modules] ICE when exporting a type through a
different alias then one declared in GMF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Bug ID: 114683
Summary: [modules] name declared in GMF in inline namespace and
exported via using-decl from parent namespace is not
visible to importer
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #7 from m.cencora at gmail dot com ---
Created attachment 57921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57921&action=edit
Full "std" module
FYI if you want to stress test the modules impl w.r.t. similar issues, here is
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #1 from m.cencora at gmail dot com ---
gcc version info:
g++-14 (Ubuntu 14-20240330-1ubuntu2) 14.0.1 20240330 (experimental) [master
r14-9728-g6fc84f680d0]
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Bug ID: 114600
Summary: [modules] redefinition errors when using certain std
headers in GMF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #11 from m.cencora at gmail dot com ---
This is surprising to say the least because apparently for following code
(where both conversion operators return same type) the compiler somehow
correctly chooses && qualified overload:
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113219
--- Comment #2 from m.cencora at gmail dot com ---
So I guess this falls into the "confusing overload resolution for user-defined
conversion" but I fail to see what can be confusing here.
createInt() returns prvalue, so later it binds to xvalue f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113219
Bug ID: 113219
Summary: Overloaded ref-qualified conversion operator triggers
bogus -Wconversion
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #5 from m.cencora at gmail dot com ---
(In reply to m.cencora from comment #4)
> This also might be a just another symptom of the same root cause:
This one is actually a regression (worked on gcc 8.3 and older)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #4 from m.cencora at gmail dot com ---
This also might be a just another symptom of the same root cause:
struct bar
{
bar() = default;
bar(const bar&);
bar(bar&&);
bar& operator=(const bar&);
bar& operator=(bar&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #2 from m.cencora at gmail dot com ---
> When invoking the conversion operator the problem does not occur.
When invoking the conversion operator *explicitly* the problem does not occur.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #1 from m.cencora at gmail dot com ---
Fixed sample (a typo in else branch of WORKAROUND2):
struct no_copy
{
no_copy() = default;
no_copy(const no_copy&) = delete;
no_copy(no_copy&&);
no_copy& operator=(const no_cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
Bug ID: 113064
Summary: assignement from temporary sometimes invokes
copy-assign instead of move-assign operator
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #7 from m.cencora at gmail dot com ---
This seems to be fixed in gcc 12.3 and gcc 13+
Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511
--- Comment #4 from m.cencora at gmail dot com ---
Ack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110303
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109770
--- Comment #8 from m.cencora at gmail dot com ---
(In reply to Richard Biener from comment #7)
>
> Ah, interesting. I was looking for an answer whether
>
> new T
>
> may produce anything other than an object with dynamic type T or if there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109770
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #14 from m.cencora at gmail dot com ---
Yeah, in CWG issue comments it is much more clear - but I cannot find such a
wording in C++ latest draft.
English is not my native language so this one is on me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #11 from m.cencora at gmail dot com ---
Nvm, I understood this rule differently. You are saying that initialization is
two step:
- first zero-initialized,
- then default-initialized.
For me the way this rule is written is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
--- Comment #8 from m.cencora at gmail dot com ---
Ah, I see that gcc doesn't support nested designated initializer in C++ mode
(compared to C mode, or clang in both C and C++ modes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108788
Bug ID: 108788
Summary: Lookup of injected class name should be type-dependent
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108594
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506
--- Comment #1 from m.cencora at gmail dot com ---
"that is the only difference between the two funcs"
I mean that deserialize and deserialize2 differ only by the way they perform
store from v32uc to output (bit_cast vs memcpy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506
Bug ID: 108506
Summary: bit_cast from 32-byte vector generates worse code than
memcpy
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #7 from m.cencora at gmail dot com ---
Hmm, ok.
So if I wanted to workaround this in generic code, what kind of types should I
exclude from aggregate initialization? Any type that has a base class with a
tail padding? Or just the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #4 from m.cencora at gmail dot com ---
(In reply to Andrew Pinski from comment #3)
> I am 99% sure this is the same issue as pr98995 even though this is a crash.
> The ice is the same as PR 93711.
>
> This code has both an abi issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #1 from m.cencora at gmail dot com ---
The problem seems to occur if base class has a tail padding, and derived class
is trying to reuse it to store its members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
Bug ID: 108417
Summary: [ICE] Crash on aggregate initialization of base class
Product: gcc
Version: 10.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108181
Bug ID: 108181
Summary: [missed optimization] Call to virtual function under
runtime index should be optimized into jump with an
offset
Product: gcc
Version: 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106889
Bug ID: 106889
Summary: __builtin_strlen fails for some constexpr constructs
Product: gcc
Version: 10.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
--- Comment #5 from m.cencora at gmail dot com ---
Yeah, __is_same builtin beats custom unique-id comparisons, but it is available
only since gcc-10 so unavailable for me.
Recently I discovered this one (only works for unique types), and it is t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105737
--- Comment #3 from m.cencora at gmail dot com ---
FWIW Ordered evaluation of elements in braced-init-list exists since C++11 (it
was not a part of P0145).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105737
Bug ID: 105737
Summary: Incorrect evaluation order in new expression
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105592
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #6 from m.cencora at gmail dot com ---
Furthermore in all the scenarios the same function is called, with same
arguments, so the calling convention/ABI is same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #5 from m.cencora at gmail dot com ---
I've slighlty refactored the code, to remove the auto variables. This issue
remains
#include
inline unsigned deserializeUInt(const unsigned char* &in)
{
unsigned out;
__builtin_memcpy(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #4 from m.cencora at gmail dot com ---
I dont think ABI is an issue here. The Foo variable is spilled into stack, and
then reloaded back into RDI register before invoking dummyFunc.
Also clang generates optimal code as can be seen her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
Bug ID: 105260
Summary: Union with user-defined empty destructor leads to
worse code-gen
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104597
--- Comment #2 from m.cencora at gmail dot com ---
Similarly when indirect call is a result of virtual function call, gcc cannot
optimize it, while clang can:
// main.cpp
struct foo
{
virtual int getInt0() const = 0;
virtual int getInt1()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104597
--- Comment #1 from m.cencora at gmail dot com ---
clang-12 optimizes it to:
Dump of assembler code for function main:
0x00401110 <+0>: mov$0x1,%eax
0x00401115 <+5>: ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104597
Bug ID: 104597
Summary: LTO does not inline indirect call
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104302
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #5 from m.cencora at gmail dot com ---
I think I was able to narrow it down to the true root cause. Following fails in
all gcc versions that supports C++11 and newer:
struct foo
{
void baz();
void bar();
};
static_assert(&foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103563
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #4 from m.cencora at gmail dot com ---
This might be related to CWG2487 "Type dependence of function-style cast to
incomplete array type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #5 from m.cencora at gmail dot com ---
Actually standard seems to require it - at least to my understanding of wait()
description in in chapter 31.8.1: it explicitly states that waiting is
performed in a loop, and loop is exited only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #3 from m.cencora at gmail dot com ---
If my analysis is correct then:
- we need to force __all = true param in __waiter_pool_base::_M_notify,
- protect from spurious wakeups in __waiter_pool::_M_do_wait by rechecking if
the value h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #2 from m.cencora at gmail dot com ---
I have adapted the test to gcc trunk, but I am not entirely sure it is correct,
because I don't have gcc trunk locally, I was just testing this on wandbox.org
The problem is even bigger here, be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #1 from m.cencora at gmail dot com ---
This test assumes previous waiter implementation (I used gcc-11 available from
Ubuntu 21.04), latest atomic_wait impl has the same problem, it is just that
waiter is selected in a different way,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Bug ID: 100334
Summary: atomic::notify_one() sometimes wakes wrong thread
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
--- Comment #8 from m.cencora at gmail dot com ---
It does not matter whether A constructor is default or empty. If class instance
cannot be constant-initialized then dynamic initialization will take place.
I think gcc just incorrectly performs c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
--- Comment #6 from m.cencora at gmail dot com ---
Now that I think about and having read relevant chapters of C++20 spec,
observed behavior seems to be expected.
A cannot be constant initialized (because it has missing initializer for
'value' me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99186
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98637
Bug ID: 98637
Summary: Changing active union member via assignment expression
should require trivial default constructor in
constexpr context
Product: gcc
Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98620
Bug ID: 98620
Summary: SFINAE code in class specialization generate warnings
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122
Bug ID: 98122
Summary: [regression] Accessing union member through
pointer-to-member is not a constant expression
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #4 from m.cencora at gmail dot com ---
I have done some more experiments, and it seems the problem applies to all
pointer-to-member (not just pointer to member function, but also for pointer to
data member).
Also it doesn't matter if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #3 from m.cencora at gmail dot com ---
Still fails on gcc 10.2 and trunk, in all std C++11-20 modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #3 from m.cencora at gmail dot com ---
Still broken in gcc 10.2 and trunk, also in C++20 mode.
The problem seems to show up only when address of member function (virtual or
not) is passed as template parameter - only then gcc fails du
92 matches
Mail list logo
