https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
Federico Kircheis changed:
What|Removed |Added
Version|8.2.0 |10.1.0
--- Comment #1 from Federico
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #3 from Federico Kircheis ---
Thank you for the analysis, explanation and references, I did not think about
testing std::lock directly.
I'm still unsure if that means that it is a bug in valgrind, unfortunately I do
not know other 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #5 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Federico Kircheis from comment #3)
> > My guess, without having looked at the implementation of std::lock, is that
> > the algorithm uses try_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #6 from Federico Kircheis ---
For what is worth, I imagined the implementation for parameters of different
type and more or less than two to be similar to
template
auto sorted_indexes(Args&... args) {
const void* addresses[
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
This is a feature request.
I'm compiling the code with "-Wall -Wextra -peda
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
While toying with a piece of code, I've noticed that the code did not get
optimized as expected.
All snippets where compiled wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96945
--- Comment #1 from Federico Kircheis ---
I've made a copy-paste error (I cant change the submitted bug), after B) it
should come C):
Adding and defaulting the constructors, except the move constructor produces
the same code as A): https://go
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Created attachment 45776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45776&action=edit
helgrind log output
Hel
++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Given following piece of code
#define DIAGNOSTIC_HELPER0(x) #x
#define DIAGNOSTIC_HELPER1(kind, y) DIAGNOSTIC_HELPER0(GCC diagnostic kind #y)
#define DIAGNOSTIC(kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
--- Comment #1 from Federico Kircheis ---
I've missed a line while copy-pasting the test program, there was a missing ')'
at the end:
#define DIAGNOSTIC_HELPER0(x) #x
#define DIAGNOSTIC_HELPER1(kind, y) DIAGNOSTIC_HELPER0(GCC diagnostic kin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89718
--- Comment #4 from Federico Kircheis ---
(In reply to Jakub Jelinek from comment #2)
> The tokens on which you expect the warning come from an area of the code
> that is not in between the pragmas, so the gcc behavior looks good to me
> here. M
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Hello,
this is partly a question, and partly a feature request
Consider following functions
int bar_ex_noexcept(int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90029
--- Comment #2 from Federico Kircheis ---
Thank you for your answer, I need to learn better how to search for related
bugs.
The bugs you linked do surely answer my question, but they do not cover exactly
the same requests.
1) optimize dead call
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Hello,
I searched for bugs related to SFINAE, and I do not think that this one has
already reported:
#include
#include
++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Hello,
consider
#include
template struct status : std::false_type{};
template struct status :
std::true_type {};
struct s1{int member;};
struct s2{int _member;};
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880
--- Comment #1 from Federico Kircheis ---
After researching a little bit more, I've convinced myself that
`status::value` should be false, as `decltype` has no special rules for
accessing private data, thus clang is correct.
If someone could con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880
--- Comment #3 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Federico Kircheis from comment #1)
> > After researching a little bit more, I've convinced myself that
> > `status::value` should be false, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #4 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #1)
> Confirmed. We shouldn't give that warning in unevaluated contexts (decltype,
> sizeof, etc.) because unevaluated operands have no effects at all, with or
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #6 from Federico Kircheis ---
> With my patch, we wouldn't warn on this second testcase. But clang++
> doesn't warn, either.
Yes, I just wanted to point out that giving warning in unevaluated contexts has
some benefits too.
I believ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #9 from Federico Kircheis ---
Hi,
did you consider my last comment (Comment 6)?
I find it unfortunate that gcc will not warn anymore about unused variables in
some circumstances.
Maybe my example was not a good one, but I guess tha
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
I've used following snippet of code for testing if inside a constepxr context:
template constexpr void test_constexpr_hel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91000
--- Comment #2 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #1)
> This would be more appropriate on the gcc-help mailing list, as you're
> asking a question not reporting a bug.
>
> The behaviour is as intended, for all -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91000
--- Comment #4 from Federico Kircheis ---
> As I explained in PR 87603 comment 6, and as the patch
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00466.html says, the old
> behaviour triggers unwanted instantiations and so causes valid code to n
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Hello,
I know this is technically speaking undefined behavior (not allowed to change
things inside namespace std), and thus not a bug but more a feature request
++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Given following program:
int main(){
char* str = "hello world!";
(void)str;
}
When compiling with "-Werror=write-strings", the expected output
++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
AFAIK, std::chrono::system_clock::now(); uses clock_gettime internally.
For various reasons (unit testing), I would like to "mock" time calls, so I
tried to use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82736
--- Comment #4 from Federico Kircheis ---
Thank you very much for your feedback.
With "-static" or "-static-libstdc++" i got the expected (at least for me)
result.
I guess that I'll need to register to https://sourceware.org/bugzilla/ to ask
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
Federico Kircheis changed:
What|Removed |Added
CC||federico.kircheis at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
Federico Kircheis changed:
What|Removed |Added
CC||federico.kircheis at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102209
--- Comment #2 from Federico Kircheis ---
Isn't the compiler allowed to do copy/move elision even if observable since
before c++17?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
--- Comment #26 from Federico Kircheis ---
As multiple people commented this Ticket, I do not know to who the least
message is sent, but I would like to give again my opinion on it, as I would
really like to use those attributes in non-toy projec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
--- Comment #27 from Federico Kircheis ---
Edit: sorry, my last comment about what GCC thinks is wrong.
GCC seems to follow the gnu::pure/gnu::const directive to the letter, it does
not ignore it when it sees the implementation of the function,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
--- Comment #28 from Federico Kircheis ---
>Edit: sorry, my last comment about what GCC thinks is wrong.
Unless it is going to inline the function call, in that case the attributes are
as-if ignored (at least the case I've tested with GCC 11.2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
--- Comment #30 from Federico Kircheis ---
It seems to me we are not going to agree as we tend to repeat ourselves, lets
see if we go around and around in circles or if it is more like a spiral ;)
Your view is more about the compiler, how it i
++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
I believe this is a missed optimization opportunity.
Given following class and functions:
struct s{
s();
s(const s&);
s(s&&);
void doit();
};
s bar0()
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Consider this code-snippet
struct s{
s() noexcept;
~s();
int value() const noexcept;
};
s foo() noexcept;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223
--- Comment #1 from Federico Kircheis ---
Sorry, I copied the wrong snippet, it should have been
#include
struct s{
s() noexcept;
~s();
int value() const noexcept;
};
s foo() noexcept;
int bar(){
const auto& v = std::move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223
--- Comment #6 from Federico Kircheis ---
> are you expecting this to go under an existing warning flag, or a new one?
Ideally -Wall, but there might already be some flags related to dangling
pointers and references.
> Your compiler explorer l
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Following program
#include
struct span {
span(std::initializer_list il) noexcept : begin(il.begin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482
--- Comment #4 from Federico Kircheis ---
Note that following equivalent snippet
#include
struct span {
span(std::initializer_list il) noexcept : begin(nullptr),
size(il.size()) { begin = il.begin();}
const int* begin;
std::s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223
--- Comment #8 from Federico Kircheis ---
> There is though, on line 10.
You are correct, I wonder how I could not see it.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Consider following snippet (https://godbolt.org/z/9e19bP1Gh)
#include
template
auto verify(F f, C1* p1){
f(p1);
return p1;
}
void bar(void* ptr
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Consider
struct s{
int* i;
s();
~s(){ delete i;}
};
void bar(){
s instance;
s instance2 = instance
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Consider following snippet
struct node {
const char* d;
const node& left;
const node& right;
};
co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
--- Comment #2 from Federico Kircheis ---
clang does not reject it:
https://godbolt.org/z/8Mq1e3o3j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
--- Comment #4 from Federico Kircheis ---
Indeed.
I just checked the latest versions.
I wonder if there is a common cause that makes this recursive data structure
harder to evaluate at compile time.
46 matches
Mail list logo
