https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #10 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #16 from DB ---
> -fno-ms-extensions will allow you to compile it, as long as you aren't
> relying on any of the other MSVC compatibility quirks.
That indeed fixes the problem, as well as squashing lots of other spurious
warnings (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #15 from DB ---
Aha, many thanks for the findings.
IMO the MS extensions should really be off by default, esp if compiling in a
Standard mode, until the user actually says they want them... right? They seem
liable to lead to issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #8 from DB ---
> I can reproduce it using x86_64-w64-mingw32-g++ 9.2.1
Thanks again for testing!
> I'm not yet convinced this isn't a ranges-v3 bug.
I will of course defer to your expertise! It could well be caused by something
bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #4 from DB ---
Created attachment 48470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48470&action=edit
test.ii from --save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #3 from DB ---
> Please read https://gcc.gnu.org/bugs and provide the missing information.
Fair point. Let me know if I missed anything still.
the exact version of GCC;
g++.exe (Rev2, Built by MSYS2 project) 9.3.0
the syste
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
`range-v3` has the concept of "invocable projections", i.e. simple
transformations t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93154
--- Comment #3 from DB ---
still occurs with the new g++-10 (Debian 10-20200104-1) 10.0.0 20200104
(experimental) [trunk revision 279880]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93152
--- Comment #6 from DB ---
still occurs with the new g++-10 (Debian 10-20200104-1) 10.0.0 20200104
(experimental) [trunk revision 279880]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93152
DB changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93154
--- Comment #2 from DB ---
A reduced version, without a variadic pack of functions...
```
#include
void f1(int) {}
template
auto
make_lambda(F f)
{
return [f]
requires std::invocable
(Arg a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93154
--- Comment #1 from DB ---
> preprocessed source:
Ah, whoops. It's not interesting anyway, but maybe I just don't remember how to
do it right... I just passed `-E`.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
Surely the below should work? I'm currently trying to go overboard with
declar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93152
--- Comment #4 from DB ---
Simplifying further, by getting rid of the Other structs/arguments, we get:
```
#include
#include
struct WeirdBase {};
struct WeirdSub: WeirdBase {};
template WeirdSub1>
auto
make_lambda()
{
return [](std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93152
--- Comment #3 from DB ---
The pointer-to-member-function and template argument deduction through it is
not required; rather, simply the presence of any other template argument in the
1st position is sufficient:
```
#include
#include
struct W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93050
--- Comment #1 from DB ---
This bug does not seem to occur with
g++ (Debian 9.2.1-21) 9.2.1 20191130
so either it was fixed between 9.2.0 and 9.2.1, or something peculiar to
MSYS2/MinGW64/Windows is causing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93152
--- Comment #2 from DB ---
another reduction: the Args... are not required in the templates (since the
member function takes none), and the same failure/success patterns occur either
way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93152
--- Comment #1 from DB ---
I believe this is also probably related to the fact that the WeirdSub1 template
argument is coming via a pointer-to-member function, although I haven't 100%
narrowed that down yet, I don't think.
The mentioned ICE can
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
This is as far as I've yet reduced this from my own project, compiling with
`g++-10 (Debian 10-20191217-1) 10.0.0 20191217 (experimental) [
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
I've come across this error at least twice when trying to throw from
constructor initialisation lists, so I don
https://bugzilla.gnome.org/show_bug.cgi?id=787648
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
https://github.com/gcc-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81140
DB changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81140
--- Comment #1 from DB ---
Hm, in fact, I'm not sure the GCC/g++ docs ever address what happens when a
declared non-volatile object is accessed through a volatile-qualified
reference/pointer, which by my understanding is the crux of the NB issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44943
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #2 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #2 from DB
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
As far as I can tell, according to P0162R0: NB comment CH 2
http://open-std.org/JTC1/SC22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68070
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #1 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #31 from DB ---
Uh, sorry. I mean when compiling my own application against glibmm and gtkmm,
using LTO on my app (only).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #30 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67054
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #3 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80851
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #1 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55922
--- Comment #11 from DB ---
This still occurs in 6.3.0
In the duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80849
I showed that whether or not this occurs can sometimes (I say because my
results don't seem consistent with everyone els
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55922
--- Comment #10 from DB ---
*** Bug 80849 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80849
DB changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80849
DB changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55922
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #9 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80849
DB changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80849
--- Comment #1 from DB ---
(In reply to DB from comment #0)
> With additional testing, on 6.3.0, I determined that - much like that other
> old bug - this problem only occurs if the virtual base constructor and the
> constructors of the intermedi
6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
This appears to be a lingering offshoot of this:
https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #19 from DB ---
just for anyone finding this later, note this has been raised at the level of
the C++ Standard - http://wg21.link/p0375r0 - with the conclusion being:
> EWG pointed out that most enumerations are exhaustive, and
> we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #18 from DB ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to DB from comment #12)
> > (In reply to Jonathan Wakely from comment #11)
> > > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #12 from DB ---
(In reply to Jonathan Wakely from comment #11)
> Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> -fstrict-enums tells the compiler it will never have a value outside that
> range. It does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #10 from DB ---
(In reply to Manuel López-Ibáñez from comment #8)
Thanks for the thoughts!
> Those "artificial kludges" not only silence the warning, but also make the
> code more readable and help the optimizer. A call to abort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #7 from DB ---
Interesting switch, thanks - doesn't make any difference to warnings at the
moment, though.
But it hits on what I'm going for: ensuring the compiler that I'll only use
named enumerator values. Ideally though, the Stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #5 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
--- Comment #9 from DB ---
Will the fix hit any previous major versions, esp. 6?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71793
--- Comment #4 from DB ---
(In reply to Richard Biener from comment #3)
> Well, if you look at the out-of-line copies of the function then he is
> correct.
> But the inline copy in main() does not have this constraint and is still
> mishandled.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
via http://stackoverflow.com/questions/38415131
The Standard requires a function-try block to have a corresponding
post
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71793
--- Comment #2 from DB ---
Thanks Richard! About this -
> RTL expansion expands x as register copy for some reason
- is this person's explanation about this originating in the ABI accurate?
http://stackoverflow.com/a/38248847/2757035
If so - a
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
Here's the original SO thread with more info and/or meandering pondering:
http://stackoverflo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63151
--- Comment #3 from DB ---
see also 66847, 66617, 55922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71774
--- Comment #2 from DB ---
see also 66847, 66617, 55922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
--- Comment #5 from DB ---
Another note is that, as per the other tickets, G++ seems to have multiple
possible causes of its confusion with brace-init:
* presence of virtual base in class hierarchy
* signature of calling class ctor vs base ctor
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
--- Comment #4 from DB ---
It should be noted that although I have a commented-out {brace} ctor for the
final class in main(), that was just a test; both {brace} and (parenthesis)
init in that context produce the same behaviour. That is: dependen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617
--- Comment #7 from DB ---
I just found a similar, possibly related issue with {brace} ctor call and
access specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
As mentioned in the comment there, we're looking forward to movement on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63151
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #1 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
--- Comment #3 from DB ---
Created attachment 35956
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35956&action=edit
-save-temps output .ii file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
--- Comment #2 from DB ---
Created attachment 35955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35955&action=edit
command line output after adding -v and -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #1 from DB
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
Created attachment 35953
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35953&action=edit
sour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617
--- Comment #5 from DB ---
Created attachment 35847
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35847&action=edit
-save-temps output files plus the triggering cpp file
see corresponding -v output added in latest comment. Please advise w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617
--- Comment #4 from DB ---
Attaching verbose output and tempfiles as recommended by bug reporting guide.
$ gcc -v -save-temps -std=c++11 virtual2.cpp -o virtual2.exe
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617
--- Comment #3 from Daniel Boles ---
Created attachment 35824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35824&action=edit
3 cpp files showing various permutations from totally broken braces, to fully
working parentheses
Revised versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617
Daniel Boles changed:
What|Removed |Added
Attachment #35822|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617
--- Comment #1 from Daniel Boles ---
Forgot to add the minimal replication steps mentioned, prepared by a fellow SO
users:
http://coliru.stacked-crooked.com/a/c4d031382115b59a
thanks
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
Created attachment 35822
66 matches
Mail list logo
