Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
This issue comes from the following discussion:
https://gcc.gnu.org/ml/libstdc++/2015-11/msg9.html
In short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879
--- Comment #1 from Daniel Gutson
---
Remind to consider all the overloads (throwing, nothrow, etc.) which will
require different names.
erity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
Existing security practices recommend to the arrays of automatic storage
duration (e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
--- Comment #3 from Daniel Gutson
---
Those are very good ideas but fell into the land of the backend. The red zone
IIUC is a x86_64 only ABI concept.
What do you think about adding also a -m counterpart option with the same
semantic but for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879
--- Comment #4 from Daniel Gutson
---
BTW, please reassign this to gabriel.iba...@tallertechnologies.com since
Aurelio is still working on qemu.
Sorry for the inconveniences.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
Add a -fdump-template-instantiations option in order to dump the C++ template
instantiations.
Please assign this to andres.tirabos...@tallertechnologies.com .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70201
--- Comment #2 from Daniel Gutson
---
(In reply to Jonathan Wakely from comment #1)
> What do you plan to implement? It would be better to produce output
> compatible with Templight (http://plc.inf.elte.hu/templight/) rather than a
> GCC-specif
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
Created attachment 38216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38216&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584
--- Comment #1 from Daniel Gutson
---
Additional data: an enumerator works:
int main()
{
__m128i r;
//constexpr auto index = 1;
enum { index = 1 };
r = _mm_aeskeygenassist_si128(r, index);
}
++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
This issue is created from the discussion here:
https://gcc.gnu.org/ml/gcc/2016-03/msg00260.html (please note that the thread
continues in April).
Basically, we want gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584
--- Comment #4 from Daniel Gutson
---
Thanks Martin.
Andres is finishing 70210 soon next week, and he can address this after solving
it. Feel free to assign this issue to him
(andres.tirabos...@tallertechnologies.com).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584
--- Comment #5 from Daniel Gutson
---
(In reply to Daniel Gutson from comment #4)
> Thanks Martin.
>
> Andres is finishing 70210 soon next week, and he can address this after
s/70210/70201/
> solving it. Feel free to assign this issue to
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
I didn't investigate this, but despite /proc/cpuinfo does not list aes as a
capability, I think that the combination -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70612
Daniel Gutson changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from Daniel G
: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
Created attachment 38318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38318&action=edit
examp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #2 from Daniel Gutson
---
(In reply to Andrew Pinski from comment #1)
> Let me reword the summary. what you want is div and ldiv and imaxdiv to be
> supported as a builtin, in that it expands correctly to do the div/mod
> inlined.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #3 from Daniel Gutson
---
(In reply to Andrew Pinski from comment #1)
> Let me reword the summary. what you want is div and ldiv and imaxdiv to be
and lldiv
> supported as a builtin, in that it expands correctly to do the div/mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #4 from Daniel Gutson
---
Please assign this to andres.tirabos...@tallertechnologies.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #6 from Daniel Gutson
---
(In reply to Marc Glisse from comment #5)
> It seems to me that the reason we don't already have div as a builtin is
> that we need to know the layout of div_t.
>
> In a header, you don't really need inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #9 from Daniel Gutson
---
Created attachment 38323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323&action=edit
sample script to be called from the build system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #10 from Daniel Gutson ---
(In reply to Marc Glisse from comment #8)
> "The div, ldiv, and lldiv functions return a structure of type div_t,
> ldiv_t, and lldiv_t, respectively, comprising both the quotient and the
> remainder. The st
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Created attachment 32606
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32606&action=edit
proposed fix
#pragma GCC diagnostic ignore &qu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
--- Comment #2 from Daniel Gutson
---
It went, but I got no answer.
FWIW: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00026.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
--- Comment #6 from Daniel Gutson
---
Thanks Manuel.
1) I didn't see a warning regarding the old use of -pedantic rather than
-Wpedantic
2) I'll change that, after the C++ FE maintainer sees the patch in order to not
pollute the thread with mor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61066
--- Comment #5 from Daniel Gutson
---
It seems some tests didn't run when I tested the patch, sorry about that.
I'll try to run all the tests and update them as needed.
I will post the new patch as soon as possible.
Sorry for the inconveniences.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61066
--- Comment #7 from Daniel Gutson
---
Sorry my lack of time.
Thanks Jason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962
--- Comment #3 from Daniel Gutson
---
Please do not close this issue.(In reply to Bruce Merry from comment #1)
> I've now realised that this is actually just the tip of the iceberg - I
> suspect that libstdc++'s pretty printers aren't Python 3 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Daniel Gutson changed:
What|Removed |Added
CC||daniel.gutson@tallertechnol
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
compiling the following code with -O2
#include
#include
char* function(size_t x)
{
void* ret = malloc(x);
if (x > 12)
memset(ret, 0, x);
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #2 from Daniel Gutson
---
(In reply to Marc Glisse from comment #1)
> Why do you call it wrong? It is always legal to replace malloc with calloc,
Have you seen the 'if' condition? The optimization ignores it completely.
> and if we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #4 from Daniel Gutson
---
(In reply to Andreas Schwab from comment #3)
> Trying to read the (uninitialized) contents of the allocated memory for x <=
> 12 would be undefined behaviour, so calling calloc instead does not change
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #6 from Daniel Gutson
---
(In reply to Andrew Pinski from comment #5)
> (In reply to Daniel Gutson from comment #4)
> > (In reply to Andreas Schwab from comment #3)
> > > Trying to read the (uninitialized) contents of the allocated m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #9 from Daniel Gutson
---
(In reply to Marc Glisse from comment #8)
> (bugzilla bug that reset the component...)
>
> (In reply to Daniel Gutson from comment #6)
> > That's why the 'if (ptr != NULL)' should not be ignored, which curr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #11 from Daniel Gutson ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Daniel Gutson from comment #9)
> > (In reply to Marc Glisse from comment #8)
> > > (bugzilla bug that reset the component...)
> > >
> > > (In repl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #30 from Daniel Gutson ---
May I ask what's wrong with Andres Tiraboschi's solution approach?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
The following code misses the warning:
#include
struct PP
{
inline void m();
};
int main()
{
PP pp;
pp.m();
}
inline void PP::m()
{
std::cout << "hola&qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
--- Comment #2 from Daniel Gutson
---
inline is as useful in c++ as in C regardless of ODR or any other reason but
its original purpose: performance.I want to know when my hint is not honored
which is the exact intent of this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
--- Comment #8 from Daniel Gutson
---
Could you please detail *exactly* what the problem is, what the output error is
and what does autotools do in its probe?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Daniel Gutson changed:
What|Removed |Added
CC||daniel.gutson@tallertechnol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #6 from Daniel Gutson
---
Please discard my previous comment, I read too fast.
I'll do some debugging and get back with some analysis.
It seems that cxx_mark_addressable() is wrongly called.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #9 from Daniel Gutson
---
Thanks Ville and Jens for looking into this.
I'll be able to fix this during next week, so if nobody is available to solve
this sooner, then please assign it to me.
Regarding the global register variables,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #12 from Daniel Gutson ---
I tried them all, and none of those flags reject a global variable declared as
register. I still think a separate issue should be filed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #15 from Daniel Gutson ---
(In reply to Jason Merrill from comment #14)
> (In reply to Ville Voutilainen from comment #13)
> > It is correct that currently none of the pedantic-flags diagnose the use of
> > this extension; perhaps tha
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
This is a spinoff of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
specially comment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064#c16
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #18 from Daniel Gutson ---
I created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67105
to treat that bug separately.
67064 (this bug) interferes with RTEMS in real life thus has a much higher
priority, so I will address this bug fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #20 from Daniel Gutson ---
(In reply to Manuel López-Ibáñez from comment #19)
> (In reply to Daniel Gutson from comment #18)
> > Please assign this to me. Thanks.
>
> You need to login with your @gcc.gnu.org account to be able to ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #22 from Daniel Gutson ---
(In reply to Jason Merrill from comment #21)
> (In reply to Daniel Gutson from comment #20)
> > I don't have a @gcc.gnu.org account. Should I simply send the attachment?
>
> Sure.
>
> > Otherwise please as
47 matches
Mail list logo
