https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118893
Bug ID: 118893
Summary: ICE (internal compiler error) on building a literal
object by using an ill-formed static operator of a
lambda (coerce_template_parms)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118722
--- Comment #6 from mauro russo ---
sure,
I was not saying disagreement,
just a new point learned :-)
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118722
--- Comment #4 from mauro russo ---
> an ODR violation is still an undefined behavior
That's interesting,
I supposed this was only for the case of multiple/different definitions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25220
--- Comment #5 from mauro russo ---
found out, through the discussion on PR 118722, that my case falls in the
exceptions where there is no odr-use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118722
--- Comment #2 from mauro russo ---
ok,
I see now the example in cppreference about special cases where, despite that
static data member value is read,
it is usable in constant expressions
and
an lvalue-to-rvalue conversion is applied to it
(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118722
Bug ID: 118722
Summary: accepted undefined static integral data member
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25220
mauro russo changed:
What|Removed |Added
CC||ing.russomauro at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43720
mauro russo changed:
What|Removed |Added
CC||ing.russomauro at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
mauro russo changed:
What|Removed |Added
CC||ing.russomauro at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118641
--- Comment #9 from mauro russo ---
done here:
https://developercommunity.visualstudio.com/t/memory-leak-due-to-non-destructed-object/10834177
as I am unable to add in the "See Also" section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118641
--- Comment #6 from mauro russo ---
Yes, 'a' and 'c' destroyed in a wrongly swapped order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118641
--- Comment #8 from mauro russo ---
I see you added the reference to the similar bug I reported to Clang
[https://github.com/llvm/llvm-project/issues/124306] but I would say that there
is similar to the previously fixed bug PR 33799 for gcc that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118641
--- Comment #7 from mauro russo ---
I tried to be clear since the words:
<... the code destroys object a before returned object constructed in #1 ...>
where having written "object a" instead of "object 'a'" might likely appear
less clear.
Any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118641
Bug ID: 118641
Summary: destruction order not respected
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118641
--- Comment #1 from mauro russo ---
I am also thankful to Vincenzo Simone, having notified that quiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118463
--- Comment #4 from mauro russo ---
Agreed.
Thank you for the further contribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398
--- Comment #10 from mauro russo ---
As comment about point (a), I hope to be right in referring the following
standard text from [temp.constr.normal]-p(1.4):
"The normal form of a concept-id C is the normal form of
the constraint-expression of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118463
--- Comment #2 from mauro russo ---
I see your point, despite I consider your modified example a bit different,
because in the original example, other compilers still accept f even on the
intantiation..
However, I suppose you are implicitly men
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118463
Bug ID: 118463
Summary: requires-clause considered ill-formed but not leading
to clause failure
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96515
--- Comment #2 from mauro russo ---
Sorry for not having realized you specified "ill-formed" in your title. I was
here while I was looking for another bug.
Anyway, your ICE is still there in gcc 14.2 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96515
mauro russo changed:
What|Removed |Added
CC||ing.russomauro at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398
--- Comment #9 from mauro russo ---
ok, I would say that, for point (b),
§13.5.2.2 [temp.constr.op] - p2 and p3:
"2 A conjunction is a constraint taking two operands. To determine if a
conjunction is satisfied, the satisfaction of the first op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398
--- Comment #8 from mauro russo ---
I see, it makes sense.
However, I hope not to be too tedious to ask explicit references for the rules
you stated:
a) ignore requirements on parameters not used in the evaluation of a concept.
b) ignore erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398
--- Comment #6 from mauro russo ---
ok, I will also check for the confirmation from standard text.
What about the fact that for func2, second clause is ignored after that first
one fails ?
Do you confirm it is fair ?
Do you confirm that this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398
--- Comment #1 from mauro russo ---
sorry, let me re-style the main() function with related comments, to adapt this
80-columns views.
int main(){
func1(std::set{}); // - gcc behaves as clang about the need to resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398
Bug ID: 118398
Summary: Resolving lambda expression decltype prioritized over
the option to consider failed required concept using
that type as argument
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96821
mauro russo changed:
What|Removed |Added
CC||ing.russomauro at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118365
Bug ID: 118365
Summary: try to define an overloaded function template for a
namespace, without having first declared it in that
namespace
Product: gcc
Version: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118195
Bug ID: 118195
Summary: accepted template member definition with a different
template-head
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118060
Bug ID: 118060
Summary: ICE (internal compiler error) on requires clause
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117778
Bug ID: 117778
Summary: ICE maybe_add_lambda_conv_op
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117772
Bug ID: 117772
Summary: constrained auto in decl-specifier accepted for
function return type despite trailing-return-type
Product: gcc
Version: 14.2.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117156
--- Comment #4 from mauro russo ---
ok, thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117156
Bug ID: 117156
Summary: not applied option “-Wchanges-meaning”
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981
--- Comment #8 from mauro russo ---
sorry, in the initial post I wrongly mentioned 'A3' in the commented code line,
in place of 'A'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981
--- Comment #7 from mauro russo ---
ok.
Maybe the comment in PR 32071 about this as duplicated may also be removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981
--- Comment #5 from mauro russo ---
yes, `B` needs to be changed to `B`.
Please, may you remove the dup-relation with PR 32071 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116943
mauro russo changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981
Bug ID: 116981
Summary: wrongly accepted non-more-specialized partial
specialization of class template member for an
instantiated enclosing template
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116943
--- Comment #3 from mauro russo ---
may I suppose that the following text from [temp.inst]:
The implicit instantiation of a class template specialization causes
- the implicit instantiation of the declarations, but not of the definitions,
of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116943
--- Comment #2 from mauro russo ---
thank you Andrew Pinski,
do you have also any explanation from the standard, why it should be rejected ?
That is, where the instantiation comes on ?
Or why this does not implicitly contradicts the option to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116943
Bug ID: 116943
Summary: wrong(?) indication of specialization after (implicit)
instantiation
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111608
mauro russo changed:
What|Removed |Added
CC||ing.russomauro at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57376
mauro russo changed:
What|Removed |Added
CC||ing.russomauro at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Bug ID: 114694
Summary: dependent-name alias type accepted in elaborated type
specifier within a template
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114488
--- Comment #2 from mauro russo ---
If something is removed from sample code (e.g., b made bool instead of a
shared_ptr, or some const is removed), the problem disappears.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114488
Bug ID: 114488
Summary: internal compiler error: unexpected expression
static_cast ...
Product: gcc
Version: 9.5.0
Status: UNCONFIRMED
Severity: normal
47 matches
Mail list logo
