(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
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 that
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
(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
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
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
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
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?
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
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
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 table and
OK (presuming the usual bootstrap and regression test, which should
provide a reasonably thorough test of this code through the stdint.h
tests).
Bootstrapped with and without the patch on x86-64, no regressions.
Committed. Thanks!
On May 4, 2014, at 2:09 PM, DJ Delorie d...@redhat.com 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, this should be:
MAX_BITSIZE_MODE_ANY_INT, not 128.
Heh.
Ok, after tomorrow, assume my patch has that instead :-)
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
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
Do we have a routine to do that already?
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
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
