(oups, the message got stuck in my mailer, should have been sent a while
ago)
On Tue, 24 Jun 2014, DJ Delorie wrote:
Since the check for __STRICT_ANSI__ is removed, do we need to add
__extension__ in front of __GLIBCXX_TYPE_INT_N_0 to avoid warning with
-Wsystem-headers?
I copied the code fr
> The changes to dwarf2asm.c, cppbuiltin.c, optabs.c, defaults.h, expr.c,
> expmed.c, tree-dfa.c, simplify-rtx.c, lto-object.c, loop-iv.c, varasm.c,
> the msp430 back end and some of the stor-layout.c changes don't look like
> they should depend on the rest of the patch. I think it would help
> Since the test on __STRICT_ANSI__ is removed for all other uses, it would
> seem consistent to me to remove this one as well. Besides, you are already
> testing __GLIBCXX_USE_INT_N_0, which as far as I understand is protected
> by !flag_iso (with the exception of size_t).
Yup, I'll clean tha
The changes to dwarf2asm.c, cppbuiltin.c, optabs.c, defaults.h, expr.c,
expmed.c, tree-dfa.c, simplify-rtx.c, lto-object.c, loop-iv.c, varasm.c,
the msp430 back end and some of the stor-layout.c changes don't look like
they should depend on the rest of the patch. I think it would help review
i
(Adding libstdc++@ in Cc: so they see the patch at
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01655.html )
On Sat, 21 Jun 2014, DJ Delorie wrote:
New version of https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00723.html
This is a big patch, but it includes all the features/changes/support
req
> Well, it wasn't a hard requirement, it is just that the library has
> to use a more complicated way to get the precision (use (unsigned
> TYPE)(-1) to get the unsigned max and compute the precision from
> that, probably).
We could define macros for the precision too, and we already know max
and
On Thu, 8 May 2014, DJ Delorie wrote:
Assuming that the formula sizeof(type)*char_bit==precision works for all
It doesn't. THe MSP430 has __int20 for example.
Well, it wasn't a hard requirement, it is just that the library has to
use a more complicated way to get the precision (use (unsign
> Assuming that the formula sizeof(type)*char_bit==precision works for all
It doesn't. THe MSP430 has __int20 for example.
Would it be acceptable for the compiler to always define a set of
macros for each of the intN types? I would have thought that would be
discouraged, but it would be an ea
On Thu, 8 May 2014, DJ Delorie wrote:
The libstdc++v3 headers have __int128 hard-coded all over the place.
Any suggestions on parameterizing those for the __intN types that are
actually supported by the target?
(adding libstdc++@ in Cc:)
The first idea that comes to mind (so possibly not such
The libstdc++v3 headers have __int128 hard-coded all over the place.
Any suggestions on parameterizing those for the __intN types that are
actually supported by the target?
> OK (presuming the usual bootstrap and regression test, which should
> provide a reasonably thorough test of this code through the
> tests).
Bootstrapped with and without the patch on x86-64, no regressions.
Committed. Thanks!
On Sun, 4 May 2014, DJ Delorie wrote:
> > I'm not aware of any reason those macros need to have decimal values. I'd
> > suggest removing the precomputed table and printing them in hex, which is
> > easy for values of any precision.
>
> Here's an independent change that removes the decimal tabl
> After tomorrow, this should be:
>
> MAX_BITSIZE_MODE_ANY_INT, not 128.
Heh.
Ok, after tomorrow, assume my patch has that instead :-)
On May 4, 2014, at 2:09 PM, DJ Delorie wrote:
> Here's an independent change that removes the decimal table and
> replaces it with generated hex values. I included the relevent output
> of gcc -E -dM also.
> + /* Allows bit sizes up to 128 bits. */
> +#define PBOH_SZ (128/4+4)
After tomorrow,
> I'm not aware of any reason those macros need to have decimal values. I'd
> suggest removing the precomputed table and printing them in hex, which is
> easy for values of any precision.
Here's an independent change that removes the decimal table and
replaces it with generated hex values. I
On Thu, 1 May 2014, DJ Delorie wrote:
> Do we have a routine to do that already?
I don't know.
--
Joseph S. Myers
jos...@codesourcery.com
Do we have a routine to do that already?
On Mon, 14 Apr 2014, DJ Delorie wrote:
> The only non-automatic part of this is the table of pre-computed
> constants in builtin_define_type_minmax() (c-family/c-cppbuiltin.c).
I'm not aware of any reason those macros need to have decimal values. I'd
suggest removing the precomputed table and p
On Tue, 15 Apr 2014, DJ Delorie wrote:
I wasn't sure what to do with that array, since it was static and
couldn't have "empty" slots in them like the arrays in tree.h. Also,
do we need to have *every* type in that list? What's the rule for
whether a type gets installed there or not? The comme
I wasn't sure what to do with that array, since it was static and
couldn't have "empty" slots in them like the arrays in tree.h. Also,
do we need to have *every* type in that list? What's the rule for
whether a type gets installed there or not? The comment says
"guaranteed to be in the runtime
On Mon, 14 Apr 2014, DJ Delorie wrote:
* rtti.c (emit_support_tinfos): Remove __int128-specific entries.
Hello,
I wanted to check the interaction with:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00618.html
but I don't see where you moved the __int128 typeinfo generation.
21 matches
Mail list logo
