: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
Let's say Foo is a trivially copyable type without an assignment operator.
In C++23, std::pair is currently triv
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile on GCC:
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511
--- Comment #5 from Louis Dionne ---
Note that my claim about TriviallyCopyable is taken from the Standard here, for
reference (even though Jason probably knows this by heart :-).
https://eel.is/c++draft/class.prop#1:
> A trivially copyable cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #13 from Louis Dionne ---
Nikolas already answered some, but just to expand on this:
> But on the topic of this enhancement request, I don't see why functions
> should be excluded from explicit instantiation if they're already abi-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #9 from Louis Dionne ---
(In reply to Andrew Pinski from comment #3)
> I am getting a feeling this attribute is well defined enough.
>
> Is it really just supposed to block explicit instantiation of templates?
> Is there a decent se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795
--- Comment #13 from Louis Dionne ---
Let me rephrase my whole request here.
I understand that what GCC does work for GCC and GCC-adjacent projects. This
report is about making the behavior of more friendly to
implementations that are not GCC-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795
--- Comment #11 from Louis Dionne ---
(In reply to Andrew Pinski from comment #9)
>
> GCC version specific includes > GCC version specific fixincludes > C library
> includes
>
> That is for C.
> C++ is:
> libstdc++ library includes > ... (rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795
--- Comment #8 from Louis Dionne ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Louis Dionne from comment #4)
> > (In reply to Andrew Pinski from comment #2)
> > > You should not be building on top of GCC's limits.h header at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795
--- Comment #4 from Louis Dionne ---
(In reply to Andrew Pinski from comment #2)
> You should not be building on top of GCC's limits.h header at all really.
> Rather implementations should have their own.
What do you mean by "implementations"?
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The header currently includes "syslimits.h", which then recursively
includes after defining the _GCC_NEXT_LIMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104760
--- Comment #3 from Louis Dionne ---
(In reply to Marek Polacek from comment #2)
> And I think this is the same problem as in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911#c18. Not sure if we want
> to change anything.
Yup, I agree this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
When using the [[deprecated]] attribute on a class template, a diagnostic is
produced even if that class template is never
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
erity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile when I believe it should succeed
(https://godbolt.org/z/z9aved8Wb):
#in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675
--- Comment #3 from Louis Dionne ---
Thanks a lot!
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
In the LLVM libc++abi test suite, we test that an exception of type 'Child' is
being caught by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745
--- Comment #4 from Louis Dionne ---
Thanks for your replies, all. We resolved the problem on our side by not trying
to workaround the lack of error, which means that we might end up passing
`-Wno-foo` to GCC when it's not supported. I think that
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
GCC does not diagnose unsupported -Wno-meow command line flags unless another
error happens during compilation.
For example, the following compiles just fine even though -Wno
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
It seems that the position where the source file is specified to GCC has an
impact on how it is linked when other
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile with GCC trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164
--- Comment #14 from Louis Dionne ---
I think so -- all the reproducers posted in this bug report can compile with
GCC trunk.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following program causes an ICE with GCC 6.1.0 and up. GCC 5.5.0 compiles
this fine
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code prints true on GCC 4.x, 5.x and 6.x, but not on GCC 7.x and
trunk:
#include
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
--- Comment #7 from Louis Dionne ---
Then, I think there's another bug in GCC (or maybe just a QOI issue), since the
following code compiles (wandbox[1]):
template constexpr T v;
template constexpr T v(888);
struct S {
constexpr S()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82000
--- Comment #2 from Louis Dionne ---
> The example you wrote in the bug report makes no sense: missing includes, and
> with the includes added it optimizes to return 0.
Sorry, I did not mean the example I pasted here to be a complete reproducti
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
In the following code, the calculation of the string length is not folded,
despite the input string being visible to the compiler
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile with GCC 7,
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code prints
i = 0
N = 0
when it should print
i = 0
N = 1
This seems to be a regression since GCC 7
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code triggers a spurious warning on GCC trunk (8.0 ish):
struct function_t {
template
void ope
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
When doing an indirect call (through a function pointer), GCC generates
different code depending on whether the function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
--- Comment #12 from Louis Dionne ---
Not sure, as I've been off pure-type computations for a while now. Looking at
how Meta does it might be useful:
https://github.com/ericniebler/meta/blob/master/include/meta/meta.hpp#L819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #13 from Louis Dionne ---
Actually, the problem is much worse than I thought. It turns out that with -O1,
the following code does not pass the assertion:
#include
template
struct tuple {
Xn storage_;
c
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile on GCC trunk:
struct F { void member() & { } };
using Member = void()&;
Member F::* fptr = &F::member;
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code has a codegen issue that causes the read of an uninitialized
value, which can lead to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #12 from Louis Dionne ---
The following code still fails to compile on GCC trunk:
template
struct tuple {
Xn storage_;
constexpr tuple(Xn const& xn)
: storage_(xn)
{ }
template
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to link on GCC trunk:
template struct Foo;
template int variable_template = 0;
template int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
--- Comment #2 from Louis Dionne ---
I know but using a runtime assert allows showing that with/without constexpr
have different results. Also, I wanted to emphasize the fact that it could
result into a runtime error, since these are much more in
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code triggers a runtime assertion:
--
#include
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164
--- Comment #6 from Louis Dionne ---
The code I posted above does not seem to trigger the bug anymore on GCC trunk.
However, the following code still produces an ICE on trunk:
> ~/code/gcc/prefix/bin/g++ --version
> g++ (GCC) 6.0.0 20160226 (ex
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile on GCC trunk (g++ 6.0.0 20151226
experimental):
template
struct hold {
T value;
T&
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile with GCC trunk (g++ 6.0.0 20151226
experimental):
template
struct holder { T value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050
--- Comment #7 from Louis Dionne ---
Yes, it seems like a dup. However, it would still be nice to know when this bug
was fixed, because it seems unlikely to have been fixed by chance... It could
be that something's still wrong, but the compiler s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050
--- Comment #5 from Louis Dionne ---
Agreed, the ICE seems to be fixed on trunk. However, the error you're getting
is still a bug, right? The code compiles if I use `this->X()`,
but not `X()` alone.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile on GCC 5.3.0:
struct base { };
struct derived : base {
constexpr derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #1 from Louis Dionne ---
Ping. This is one of the last bugs preventing Boost.Hana [1] to work with GCC.
I would be eternally grateful if someone could fix this!
[1]: https://github.com/ldionne/hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66135
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile on GCC trunk:
struct array {
int elems_[1];
};
constexpr array a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371
--- Comment #1 from Louis Dionne ---
This is almost certainly a duplicate of #66026, yet it is still unconfirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164
--- Comment #4 from Louis Dionne ---
Still fails on trunk. Out of curiosity Markus, do you use software to reduce
test cases? Did you generate these A, B, ... structs yourself?
Anyway, I was able to reduce to the following:
---
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile on GCC trunk:
constexpr void f() {
if (false)
throw;
}
Th
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile with GCC trunk:
template
void expand(T const& ...);
template
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code triggers a compilation error on GCC trunk:
template
struct element : Xn {
constexpr elem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041
--- Comment #1 from Louis Dionne ---
Can be simplified to:
template
auto variable_template = [] { };
int main() {
variable_template<>;
}
Still fails on GCC trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
Hi,
The following code triggers an ICE (segmentation fault) on
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile on GCC trunk:
---
template
auto variable_template = [] { return 1
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails on GCC trunk:
--
#include
int main() {
std::tuple_size const
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code triggers a "unused but set variable" warning on GCC trunk:
int main() {
auto f = []() { };
[=](auto) {
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile on GCC trunk:
auto f = [](auto&& x) -> decltype((void)x) { };
The failure is
error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719
--- Comment #9 from Louis Dionne ---
I can confirm that my original use case now works. Thanks a bunch!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719
--- Comment #4 from Louis Dionne ---
I added Jason to the CC list since he's the one who committed r213641. Jason,
any clue about how to fix this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719
--- Comment #3 from Louis Dionne ---
This bug is a real, real pain. I'm willing to help fixing it and/or to provide
test cases, but it'll take me forever if someone on your side does not assist,
since I don't know the GCC code base. I've looked a
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
Hi,
The following code causes an ICE on GCC trunk (couple of weeks old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473
--- Comment #4 from Louis Dionne ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Louis Dionne from comment #2)
> > Does the standard specify which headers should define those macros?
>
> Of course not, __GLIBCXX__ is not specifi
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
The following code triggers a link error on GCC trunk:
--
struct FunctionObject {
void operator()() const { }
};
template
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
The following code produces an error on GCC trunk. The error says that there
is no matching `f` to call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
The following code triggers an ICE on GCC trunk:
--
#include
template
struct when;
template
struct always_true
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
The following code produces an error on GCC trunk:
--
void allow_expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473
--- Comment #2 from Louis Dionne ---
Does the standard specify which headers should define those macros? If not,
then it's a QOI issue that could easily be solved. In all cases, does stdcxx
document which headers must be included in order to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498
--- Comment #5 from Louis Dionne ---
[Just a quick comment: thank you for being so responsive. Most of my bug
reports on Clang are left hanging for a long while before anyone ever considers
them, and I appreciate it not being the case here.]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498
--- Comment #1 from Louis Dionne ---
Apologies; the lines of the example run were wrapped and it's unreadable from
here. Here's what it looks like:
https://gist.github.com/ldionne/054e276caf90f16e3223
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
The following code triggers an ICE on GCC trunk:
--
#include
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Hi,
One would expect that including _any_ header from the standard library defines
the relevant detection macros. For example, I usually include the
header to check for libc++ (per http://goo.gl/eXNYJH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
--- Comment #8 from Louis Dionne ---
I made further experiments to try and workaround this (I need it badly!) and
I found some things that might be of interest to you. The following test case
compiles on GCC 4.9.1 but not on Clang 3.5.0 (trunk):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
--- Comment #7 from Louis Dionne ---
I ran into this problem in another context, and I think it justifies some
thinking about how this issue is going to be handled by the language. I
_really_ think the following should be valid C++. This is a C++
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
GCC Version
---
gcc-4.9 (GCC) 4.9.0 20131201 (experimental)
Installed with Homebrew.
System
--
OS X 10.8.5
Command line to trigger the bug
---
gcc-4.9 -std=c++11
83 matches
Mail list logo
