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
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=edit
sample script to be called from the build system
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
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 #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 #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.
: 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=edit
exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70612
Daniel Gutson changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from Daniel
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 -mtune
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
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).
++
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 #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);
}
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=edit
test c
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
>
++
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=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.
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
: 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.g
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.
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=67064
--- Comment #30 from Daniel Gutson ---
May I ask what's wrong with Andres Tiraboschi's solution approach?
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 #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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #22 from Daniel Gutson daniel.gutson at tallertechnologies dot
com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #18 from Daniel Gutson daniel.gutson at tallertechnologies dot
com ---
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
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 #20 from Daniel Gutson daniel.gutson at tallertechnologies dot
com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #15 from Daniel Gutson daniel.gutson at tallertechnologies dot
com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Daniel Gutson daniel.gutson at tallertechnologies dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #12 from Daniel Gutson daniel.gutson at tallertechnologies dot
com ---
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 #9 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #6 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
The following code misses the warning:
#include iostream
struct PP
{
inline void m();
};
int main()
{
PP pp;
pp.m();
}
inline void PP::m()
{
std::cout hola std::endl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
--- Comment #2 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
--- Comment #8 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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=58962
--- Comment #3 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61066
--- Comment #7 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
Sorry my lack of time.
Thanks Jason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61066
--- Comment #5 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
--- Comment #6 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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
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=32606action=edit
proposed fix
#pragma GCC diagnostic ignore -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
--- Comment #2 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
It went, but I got no answer.
FWIW: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00026.html
47 matches
Mail list logo
