https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111
--- Comment #10 from W E Brown ---
(In reply to Eric Estievenart from comment #9)
Sorry, but I find neither "weirdness" nor "spooky"-ness in the comment #9 code
as shown. Rather, I believe it to be simply an example of a program that the
C++
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Using (Homebrew GCC HEAD-37c2d99) 13.0.0 20221213 (experimental)
and compiling via:
g++-HEAD -std=c++23 -fmodules-ts -fcontracts -pedantic-errors \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778
--- Comment #10 from W E Brown ---
> On Dec 22, 2022, at 6:51 PM, cvs-commit at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778
>
> --- Comment #9 from CVS Commits ---
> The master branch has been updated
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Similar to bug 59123, the following code compiles with no complaint:
extern const double e; // a fwd-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103049
--- Comment #2 from W E Brown ---
(In reply to Marek Polacek from comment #1)
> Patch on review.
In the proposed patch, I respectfully recommend a slight rewording of the new
pedwarn messages in gcc/cp/semantics.c and gcc/cp/typeck2.c:
++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
The following program produces "Segmentation fault: 11 signal terminated
program cc1plus" when compiled with flags
-std=c++23 -fmodules-ts -pedantic-errors -O0 -c
using
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Using recent trunk [g++-HEAD (Homebrew GCC HEAD-5380e3c) 12.0.0 20210513],
compiling with significant flags -std=c++23 -fmodules-ts -c.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335
--- Comment #4 from W E Brown ---
I won't comment on any compiler's behavior, but do want to thank you for
reminding me of [namespace.udecl]/14:
"When a using-declarator brings declarations from a base class into a derived
class, member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #4 from W E Brown ---
(In reply to Steven Sun from comment #3)
> I would expect the complete specialization is full
> specialization for both primary templates.
No, any given explicit or partial specialization can be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #2
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Using gcc version 11.0.0 20210116 (experimental) (Homebrew GCC HEAD-2c356f2_2)
and compiling with flags:
-std=c++20 -fmodules-ts -fsanitize=undefined
produces
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95963
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #3
++
Assignee: unassigned at gcc dot gnu.org
Reporter: chengcongxiu at huawei dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
the main2.cpp as follow:
#include
using namespace std;
void FuncA(int arg1
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: antal.buss at ualberta dot ca
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
A simple
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redboltz at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92426
--- Comment #2 from W E Brown ---
Please note that the submitted test program seems not to meet the #include
requirement as articulated in N4835 clause [expr.spaceship] p10:
"10 The five comparison category types (17.11.2) (the types
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
The manual page https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html seems to be
missing descriptions of several built-in type traits in current (trunk) use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193
--- Comment #3 from W E Brown ---
Sorry; hadn't seen or recalled the note cited by comment 1.
Agreed with comment 2 that this need not be a priority. My (admittedly
hostile) experimental code caught it, so I thought to note it for the record.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
In the new header, most symbols are given a value of type int, rather
than a value of type long as mandated by [support.limits.general] Table 35 of
N4762.
For example, we find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958
--- Comment #8 from W E Brown ---
C++ seems very clear that the semantics of parameter passage are those of
initialization. For example, according to [expr.call]/7 in N4741:
"When a function is called, each parameter shall be initialized with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85689
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85439
--- Comment #5 from W E Brown ---
(In reply to Marc "Foddex" Oude Kotte from comment #4)
> The reason I was expecting the same result everywhere is because of this
> statement on cppreference.com:
>
>
> "Notes
> The 1th consecutive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80144
--- Comment #2 from W E Brown ---
> Confirmed, although I'm not sure which of those 2 options is correct...
Per N4687, [temp.concept]/4:
A concept shall not have associated constraints (17.4.2).
Since Second's declaration does specify Never
++
Assignee: unassigned at gcc dot gnu.org
Reporter: vermaelen.wouter at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
When switching from gcc-6 to gcc-7 my application triggers some new compiler
warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81263
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #1
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kmp53 at sina dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
template
class C
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d25fe0be at outlook dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
I hesitate to submit
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john.duncan at oracle dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
This problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78996
--- Comment #1 from W E Brown ---
Created attachment 40465
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40465=edit
Preprocessed source
: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Upon upgrading to g++-mp-7 (MacPorts gcc7 7-20170101_0) 7.0.0 20170101
(experimental) and compiling with significant options -std=c++1z -fconcepts, I
find a previously-unseen conflict.
At line
++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sergstrukovlink at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone
++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html documents gcc
intrinsic functions to perform integer arithmetic with overflow checking.
Addition
changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #3 from Eric Gallager ---
I think a better fixit would
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
The following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69009
--- Comment #5 from W E Brown ---
I have encountered this issue several more times since my original report, and
am writing to report a pattern I recently noticed among cases that ICE vs
similar cases that compile correctly. (I'm now using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53901
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51960
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12255
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #7
++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Created attachment 37101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37101=edit
Preprocessed source
Using g++-mp-6 (MacPorts gcc6 6-20151220_0) 6.0.0 20151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68164
W E Brown changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68164
--- Comment #2 from W E Brown ---
(In reply to Casey Carter from comment #1)
> [basic.life]/5 says:
>
> Before the lifetime of an object has started ... or, after the lifetime of
> an object has ended and before the storage which the object
++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Created attachment 36625
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36625=edit
Test program
Compiler version: g++-mp-6 (MacPorts gcc6 6-20151025_0) 6.0.0 20151
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Created attachment 36243
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36243action=edit
Test for Assignable concept
Using g++-mp-6 (MacPorts gcc6 6-20150816_0
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #4 from W E Brown webrown.cpp at gmail dot com ---
(In reply to Andrew Sutton from comment #2)
snip
If we had a rule that allowed the evaluation of a concept in any
context, then we could avoid doing this. It would also guarantee
++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
This appears to be a recently introduced regression. Although I'm using the
concepts branch, no concepts features are used to reproduce the problem.
Reduced test case:
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66743
--- Comment #1 from W E Brown webrown.cpp at gmail dot com ---
Further reduced test case:
template class T
using u_t = __underlying_type(T);
int main( ) { }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759
--- Comment #6 from W E Brown webrown.cpp at gmail dot com ---
I hadn't realized this was still open :)
FWIW, my paper N3846
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3846.pdf) summarizes
on p. 3 my recommended guidelines
++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Created attachment 35134
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35134action=edit
program producing ICE
When compiling enclosed program via
g++-mp-5 (MacPorts gcc5 5-20150308_0) 5.0.0 20150308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65553
W E Brown webrown.cpp at gmail dot com changed:
What|Removed |Added
CC||andrew.n.sutton
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Created attachment 31255
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31255action=edit
Demonstrating SFINAE failure to fail
Command: g++-mp-4.9 -O3 -std=gnu++1y bug2.cc
Version: g++-mp
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Created attachment 30342
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30342action=edit
Source file demonstrating issue
Compiling via:
g++-mp-4.9 -std=gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56041
Bug #: 56041
Summary: Constexpr conversion function definition not found in
template argument context
Classification: Unclassified
Product: gcc
Version: 4.7.2
57 matches
Mail list logo
