https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95833
--- Comment #9 from Tony E Lewis ---
Great. I confirm my original example code now compiles and runs cleanly on
Compiler Explorer. Thanks very much for this.
And thanks to OP for the report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95833
--- Comment #3 from Tony E Lewis ---
Great. Thanks very much.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95833
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
Tony E Lewis changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96731
--- Comment #5 from Tony E Lewis ---
Thanks very much for your work on this.
That's a shame but I appreciate the problems you've highlighted.
> I don't plan to work on this any further for now.
Yes, fair enough.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #7 from Tony E Lewis ---
Thanks for this comment T vd Sijs. Yes - I'm also able to compile this without
problem in 9.3 (and in 10.1).
Manuel López-Ibáñez: are you happy that all underlying issues are resolved and
this can be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96731
--- Comment #3 from Tony E Lewis ---
Thanks for correcting my failure to find the relevant part of the standard and
for confirming this as an enhancement request.
Yes please. If libstdc++'s sample() could play nicely with range-v3's
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Following on from https://github.com/ericniebler/range-v3/issues/1532 ...
I think the static_assert requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91993
--- Comment #7 from Tony E Lewis ---
Thanks for all work on this. I confirm that the motivating testcase now
compiles successfully on Godbolt's trunk build ("10.0.1 20200331
(experimental)").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
--- Comment #10 from Tony E Lewis ---
I confirm that my testcase remains fixed on the Godbolt build of g++ trunk
("20200210").
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
--- Comment #8 from Tony E Lewis ---
I see on Godbolt that my similar-looking ICE is also fixed now.
Thanks very much.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
--- Comment #4 from Tony E Lewis ---
Sorry - forgot to include the compiler output...
In file included from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/reverse_iterator.hpp:20,
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92313
--- Comment #4 from Tony E Lewis ---
This is now fixed.
The bug we decided this was probably a duplicate of
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206) is now fixed. I've
confirmed that trunk (on Godbolt) is also now behaving itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92313
--- Comment #2 from Tony E Lewis ---
Ah yes - that looks pretty likely. Sorry, I didn't spot that one.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling:
~~~
#include
~~~
...with range-v3 0.9.1 is successful with GCC 9.2 but induces an ICE with GCC
trunk ("1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
--- Comment #1 from Tony E Lewis ---
Sorry: I should have said...
Even the original warning isn't ideal because the compiler has enough
information to know that all paths through f() either return a value or throw.
So I don't think it should
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
When I use Godbolt's GCC (9.2 or trunk ("10.0.0 20191022 (experimental)")) to
compile:
~~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90894
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling:
auto fn( const unsigned char ,
const unsigned char ,
const unsigned char ) {
return static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
--- Comment #8 from Tony E Lewis ---
That makes sense. Thanks for the quick and clear response.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
--- Comment #8 from Tony E Lewis ---
As far as I can see on Godbolt, this is now fixed in trunk. I'm happy for this
issue to be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
--- Comment #6 from Tony E Lewis ---
(also posted to the libc++ equiv: https://bugs.llvm.org/show_bug.cgi?id=35235)
Thanks to everyone involved in libc++, libstdc++ and wg21 for all work on this.
This makes sense to me. When the world is awash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80438
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #25 from Tony E Lewis ---
Yep - my original testcase now compiles without complaint on the trunk GCC on
Godbolt. Thanks very much to everyone involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093
--- Comment #8 from Tony E Lewis ---
Yep - verified on the GCC trunk on Godbolt ("9.0.0 20180915 (experimental)").
Fantastic stuff. Thanks very much Ville.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093
--- Comment #2 from Tony E Lewis ---
Thanks for the response. Yes - that makes sense to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68222
--- Comment #4 from Tony E Lewis ---
Yes - Godbolt's GCC trunk is now showing an error where I'd expect within the
original repro code.
Great stuff. Thanks very much for your work on this.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This following fails to compile under `g++ -fsyntax-only -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
--- Comment #12 from Tony E Lewis ---
I confirm that Godbolt's GCC trunk now handles my testcase correctly.
Thanks very much for all work on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
--- Comment #7 from Tony E Lewis ---
Ah yes - I'm seeing it compiling cleanly now on Godbolt's trunk (9.0.0
20180615).
Must have been a temporary glitch in the build (and couldn't possibly have been
due to my error :P ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
--- Comment #5 from Tony E Lewis ---
Thanks to all for all work on this.
(Apologies if this isn't helpful but just in case it is...) I notice that the
original Godbolt snippet ( https://godbolt.org/g/JnrZss ) has regressed from a
rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923
--- Comment #9 from Tony E Lewis ---
I'm so delighted to see:
#include
#include
using std::literals::chrono_literals::operator""s;
using std::literals::string_literals::operator""s;
...compiling cleaning on Godbolt.
Thanks for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
--- Comment #17 from Tony E Lewis ---
I confirm that I'm seeing this as fixed on GCC trunk on Godbolt. Thanks very
much to all involved in getting this sorted quickly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
--- Comment #3 from Tony E Lewis ---
Just to be clear...
I don't think it's _necessarily_ a problem that the warning is being triggered
in this particular context (because I'm not in a position to judge that). The
core problem I wish to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
--- Comment #1 from Tony E Lewis ---
Created attachment 43218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43218=edit
Verbose output from GCC 7.2.0 [Ubuntu 17.10]
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Created attachment 43217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43217=edit
Pre-processed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #21 from Tony E Lewis ---
Many thanks to all for the thought, time and work you're devoting to this
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #4 from Tony E Lewis ---
Thanks for the response. That all sounds sensible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #2 from Tony E Lewis ---
Further, even adding:
#pragma GCC diagnostic ignored "-Wduplicated-branches"
...doesn't appear to stop these warnings in this example code, though it does
correctly silence the warning in non-template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #1 from Tony E Lewis ---
Created attachment 42965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42965=edit
Intermediate file
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling with:
g++ -Werror -Wduplicated-branches -c -isystem sysheaddir b.cpp
where b.cpp is :
#include "
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Created attachment 42765
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42765=edit
Pre-processed (-save-temps) on GCC 7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
--- Comment #4 from Tony E Lewis ---
Thanks very much for your quick work on this.
I agree that changing the standard is a reasonable approach but I also think
that changing the library implementations is a reasonable approach too. Please
may I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
--- Comment #1 from Tony E Lewis ---
I should say that I've also raised the same issue against libc++ :
https://bugs.llvm.org/show_bug.cgi?id=35235
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This fails to compile:
~~~
#include
#include
int main() {
std::vector a = { 5, 7, 1, 4, 1
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
GCC rejects the following code (partly adapted from Boost's tribool), which I
think is valid:
struct dummy {
void nonnull
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This code fails to compile under g++ (including "gcc HEAD 7.0.0 201611" on
http://melpon.org/wandbox):
struct a {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77446
--- Comment #3 from Tony E Lewis ---
Great to see this will now be covered by a testcase. Thanks very much for all
work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69095
--- Comment #6 from Tony E Lewis ---
For information: mine is now fixed too.
More detail: my example that was previously triggering this Internal Compiler
Error on GCC 5.2.1 now gets sensible error messages under "gcc HEAD 7.0.0
20161004" on
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
I'm compiling the following under C++14 mode on HEAD 7.0.0 201608 of
http://melpon.org/wandbox/
struct inner {
int f
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling this code:
#include
#include
#include
template
constexpr size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69095
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
It would be very helpful if the _Safe_iterator wrapper disabled operators, such
as non-member operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
56 matches
Mail list logo
