On Mon, Aug 19, 2019 at 8:06 PM John Darrington
wrote:
>
> On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote:
>
> > ? As I remember there were a few other ideas from Richard Biener and
> > Segher Boessenkool.? I also proposed to add a new address register
> which
>
Thank you (and others) for your answers. Now I'm just as smart as before,
however.
Is it a supported, documented, 'long term' feature we can rely on or not?
If yes, I would expect it to be properly documented. If not, never mind.
> Gesendet: Montag, 19. August 2019 um 16:08 Uhr
> Von: "Alexande
Hello.
The deadline for final evaluations is 26th of August and there are
certain things that I need to submit along with the code.
A link has to be submitted of the codes that I have written and I am
thinking of doing it as a github gist along with links to commits to
my gcc fork. I know that the
On Mon, 2019-08-19 at 17:05 -0600, Jeff Law wrote:
>
> There's a real good chance Martin Liska has already fixed this. He's
> made a couple fixes in the last week or so with the interactions
> between
> the GC system and the symbol tables.
>
>
> 2019-08-15 Martin Liska
>
> PR ipa/91
On 8/19/19 4:59 PM, Steve Ellcey wrote:
> I was wondering if anyone could help me investigate a bug I am
> seeing in the GCC garbage collector. This bug (which may or may not
> be PR 89179) is causing a segfault in GCC, but when I try to create
> a preprocessed source file, the bug doesn't trigger
I was wondering if anyone could help me investigate a bug I am seeing
in the GCC garbage collector. This bug (which may or may not be PR
89179) is causing a segfault in GCC, but when I try to create a
preprocessed source file, the bug doesn't trigger. The problem is with
the garbage collector try
On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote:
> ? As I remember there were a few other ideas from Richard Biener and
> Segher Boessenkool.? I also proposed to add a new address register which
> will be always a fixed stack memory slot at the end. Unfortunatel
Hi Cale,
On Mon, 19 Aug 2019 at 19:50, Cale McCollough wrote:
>
> My name is Cale McCollough and I'm the author of the Fastest Method to
> Print Integers and Floating-point Numbers, the Puff algorithm, that
> eliminates over half of the division instructions from the
> industry-standard mod 100 d
My name is Cale McCollough and I'm the author of the Fastest Method to
Print Integers and Floating-point Numbers, the Puff algorithm, that
eliminates over half of the division instructions from the
industry-standard mod 100 div 100 technique, saving hundreds to thousands
of clock cycles and elimina
On Mon, Aug 19, 2019 at 09:14:22AM -0400, Vladimir Makarov wrote:
> On 2019-08-19 3:35 a.m., John Darrington wrote:
> >On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
> > No I meant something like that
> >
> > (define_special_memory_constraint "a" ...)
> > (de
On Mon, 19 Aug 2019, Tejas Joshi wrote:
> How can I add a target hook to specify the FP_INT_* values from libm ?
See target.def.
You'll need a GCC-specific enum (GCC_FP_INT_*, say) that GCC uses
internally, and a hook that maps between that and FP_INT_*. I'm guessing
that for the likely uses,
> On Aug 19, 2019, at 10:08 AM, Alexander Monakov wrote:
>
> On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
>
>> Correct, but note that you can only pack structs and unions, not basic types.
>> there is no way of under-aligning a basic type except by wrapping it in a
>> struct.
>
> I d
On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
> Correct, but note that you can only pack structs and unions, not basic types.
> there is no way of under-aligning a basic type except by wrapping it in a
> struct.
I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been
s
On 19/08/2019 14:57, Paul Koning wrote:
On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the
following code:
#include
typedef uint32_t uuint32_t _
> On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
>
> All,
>
> this is my first post on these lists, so please bear with me.
>
> My question is about gcc's __attribute__((aligned()). Please consider the
> following code:
>
> #include
>
> typedef uint32_t uuint32_t __attribute__((alig
On 2019-08-19 3:35 a.m., John Darrington wrote:
On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
No I meant something like that
(define_special_memory_constraint "a" ...)
(define_predicate "my_special_predicate" ...
Hi Richard,
On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote:
> Tejas Joshi writes:
> >> It's just a different name, nothing more, nothing less. Because it is
> >> a different name it can not be accidentally generated from actual
> >> truncations.
> >
> > I have introduced float
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the
following code:
#include
typedef uint32_t uuint32_t __attribute__((aligned(1)));
uint32_t getuuint32(uint8_t p[]) {
return *(uuint32_t*)p;
}
T
Hello.
The fromfp/fromfpx variants round to integers with a specified number
of bits, to a specified rounding mode. They come with their own
complications as Joseph had stated in an initial mail and expected to
expand them in AArch64 :
> The fromfp / fromfpx / ufromfp / ufromfpx functions (round t
> but an unspec is of course easiest for now.
So, at this point, should I proceed with UNSPEC considering the
complications that might arise as Richard points out?
On Sat, 17 Aug 2019 at 13:51, Richard Sandiford
wrote:
>
> Tejas Joshi writes:
> > Hi,
> >
> >> It's just a different name, nothin
On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
No I meant something like that
(define_special_memory_constraint "a" ...)
(define_predicate "my_special_predicate" ...
{
if (lra_in_progress_p)
return REG_P (o
21 matches
Mail list logo
