https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
Christophe Monat changed:
What|Removed |Added
CC||christophe.monat at st dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
--- Comment #10 from Christophe Monat ---
(In reply to Elad Lahav from comment #9)
Thanks for your patch proposal!
> 1. GCC emits a warning:
>/home/elahav/src/projects/aarch64_naked/aarch64_naked.c:15:1: warning: no
> return statement in fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661
--- Comment #6 from Christophe Monat ---
(In reply to Alexander Monakov from comment #5)
> sincos performs range reduction for the argument just once, which is fairly
> important. A well-optimized sincos also shares some computations for the
> si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661
--- Comment #4 from Christophe Monat ---
Hi Pratamesh,
You're absolutely right - maybe it's more efficient when there is some hardware
sincos available (Intel FSINCOS ?) but I would check also carefully the actual
performance.
Indeed, it looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661
Christophe Monat changed:
What|Removed |Added
CC||christophe.monat at st dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607
--- Comment #13 from Christophe Monat ---
(In reply to Prakhar Bahuguna from comment #12)
Hi Prakar,
> The patch has now been posted to the mailing list:
> https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00872.html
Thanks for the work, and the k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607
--- Comment #10 from Christophe Monat ---
(In reply to Ramana Radhakrishnan from comment #9)
Hello Ramana,
Is there a plan to have this patch delivered upstream at some point in the near
future ?
Best regards,
--C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68197
--- Comment #4 from Christophe Monat ---
(In reply to Jonathan Wakely from comment #3)
> No, it seems underspecified. I have raised it with the C++ committee.
Do you have feedback from the C++ committee ?
I have only easily access to a 2011 sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78236
--- Comment #3 from Christophe Monat ---
(In reply to Tim Shen from comment #2)
> I proposed another way to fix this in the list:
> https://gcc.gnu.org/ml/libstdc++/2016-11/msg8.html
Looks perfect - I was somewhat annoyed by the _M_match() c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78236
--- Comment #1 from Christophe Monat ---
Comment on attachment 39982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39982
Proposed patch to fix the regex_iterator constructor
>diff --git a/libstdc++-v3/include/bits/regex.h
>b/libstdc++-v3
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.monat at st dot com
Target Milestone: ---
Created attachment 39982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39982&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78020
--- Comment #6 from Christophe Monat ---
James,
(In reply to James Greenhalgh from comment #5)
> This bug looks invalid to me. I think you're both failing to grasp the
> intuition behind these intrinsics. Ignoring the descriptions in the
> refer
: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.monat at st dot com
Target Milestone: ---
Created attachment 39829
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
--- Comment #3 from Christophe Monat ---
Andrew,
(In reply to Andrew Pinski from comment #2)
> I really think the naked attribute as not useful at all. I think it was a
> bad idea. Why not write a .s file which does what you want?
Well, from th
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.monat at st dot com
Target Milestone: ---
With the following code fragment aarch64-attribute-naked.c :
void
__attribute__((naked))
dealwithit()
{
// Stuff removed above, below we assume that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
--- Comment #4 from Christophe Monat ---
(In reply to Richard Biener from comment #3)
> I wonder what the standards say about side-effects in those "declarations".
From my instance of ISO+IEC+9899-2011.pdf
6.7.6.2 Array declarators
Constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607
--- Comment #4 from Christophe Monat ---
(In reply to Thomas Preud'homme from comment #3)
Thomas,
I am seeing that the assignee name has been reset : does it mean that you
definitely disengage from looking at this problem ?
If this is the case
17 matches
Mail list logo
