with
some option to disable them, could be considered if it's unlikely people
will intentionally do this in C.
--
Joseph S. Myers
jos...@codesourcery.com
d)
> int (*b)[1] = &v1.b;
> int (*c)[2][3] = &v1.c;
> int (*cc)[3] = v1.c;
> -const int (*ff)[3] = v1.c; /* { dg-warning "initialization from
> incompatible pointer type" } */
> +const int (*ff)[3] = v1.c;
No, I think you should add -pedantic to this test instead of removing
tests for diagnostics from it (of course the particular text of the
diagnostics being tested for may change, that's fine).
--
Joseph S. Myers
jos...@codesourcery.com
asprintf and vasprintf aren't in
ISO C);
(b) please don't add new target macros such as
CUSTOM_STDI_WEAK_SYM_PATTERN and CUSTOM_STDO_WEAK_SYM_PATTERN (if
something is defined in tm_defines and used in architecture-independent
code, it's effectively a target macro), find a way to
object, as the same principle as "An array subscript is out of range, even
if an object is apparently accessible with the given subscript (as in the
lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6)."
(Annex J) applies).
--
Joseph S. Myers
jos...@codesourcery.com
match-and-simplify infrastructure - convert.c is not a
particularly good place for optimization, and having similar
transformations scattered around (fold-const, convert.c, front ends, SSA
optimizers) isn't helpful; hopefully match-and-simplify will allow some
unification of this sort of opt
orward.
>
> Thanks. I will wait at least until the end of next week.
>
> I'd like to hear from Joseph ;).
I approve of the change in default (I just don't think it's a change to
make on my say-so alone).
--
Joseph S. Myers
jos...@codesourcery.com
ast-math itself doesn't respect the rule
that more specific options override less specific ones, whatever the
command-line ordering, you could just as well change set_fast_math_flags
to take opts_set as well and mark the options in question explicitly set,
unless any other code checks if they were explicitly set and so would
regress from such a change.)
--
Joseph S. Myers
jos...@codesourcery.com
t argument would also lose the conversion to double (so
losing exceptions for signaling NaN arguments). In view of the many open
bugs relating to floating-point exceptions, I don't think such changes
would be problematic.
--
Joseph S. Myers
jos...@codesourcery.com
n
it's correct to apply them to binary128 operations - is it appropriate for
conversions between TFmode and XFmode or not? Of course applying to all
operations is easiest and avoids needing the soft-fp conditionals to
depend on the operation / types involved, or having different
sfp-machine.h
This aspect of pp-numbers is mentioned in the manual (trouble.texi)
because of the confusion it causes.
--
Joseph S. Myers
jos...@codesourcery.com
y from running them, and to run
each test independently, is the QMTest model, though there are other
issues with how that handles some things that come up in toolchain
testing.)
--
Joseph S. Myers
jos...@codesourcery.com
be fixed in 4.9.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 3 Sep 2014, Joern Rennecke wrote:
> On 2 September 2014 16:28, Joseph S. Myers wrote:
> > On Tue, 2 Sep 2014, Joey Ye wrote:
> >
> >> Apparently newlib is not following this specification very well, as
> >> there are symbols like _abc_r defined every w
ll to bar is with an argument
that does in fact point to at least 5 chars (if a call doesn't, there's
undefined behavior when that call is executed).
--
Joseph S. Myers
jos...@codesourcery.com
, even if the array
passed by the caller is larger, and maybe also that the caller must not
pass an array smaller than the size given.)
--
Joseph S. Myers
jos...@codesourcery.com
y
define a variable called _standard_function at block scope, then try to
call standard_function within that block. So in general it's safer to use
the double underscore in the implementation, unless there is some clear
reason to use the single underscore.
--
Joseph S. Myers
jos...@codesourcery.com
the one implementation of these checks to get right and to
optimize as much as possible.)
--
Joseph S. Myers
jos...@codesourcery.com
s (if that project
is provided with the source material in as good a quality as provided to
some other site, I hope they will ensure they provide the video in an
unencumbered format and readily accessible with only free software with
quality as good as on the other site).
--
Joseph S.
on is much smaller than the original - which
might well be the case if the original format is one that only compresses
individual frames, such formats also being more likely to be
unencumbered.)
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 24 Jul 2014, Diego Novillo wrote:
> On Thu, Jul 24, 2014 at 11:36 AM, Joseph S. Myers
> wrote:
> > On Thu, 24 Jul 2014, Diego Novillo wrote:
> >
> >> Sessions were recorded on video. We will be publishing them from
> >> the GNU Tools Google+ page whe
hat the GNU recommendation is for
licenses on videos about free software, so that should be determined
first).
--
Joseph S. Myers
jos...@codesourcery.com
is buggy unless -fno-math-errno is used
(given the existence of cases where round + cast must not set errno, but
lround may). A bug should be filed in Bugzilla for this.
--
Joseph S. Myers
jos...@codesourcery.com
__auto_type is, by design, meant to be consistent with typeof (while
avoiding multiple evaluation when VLAs are involved, as well as avoiding
exponential blowup of the size of the expansion with nested calls to
macros).
--
Joseph S. Myers
jos...@codesourcery.com
const qualifiers from atomic types. (Possibly
all qualifiers should be removed; const can be an issue for
more macros using typeof than just the
ones.) */
(If changing this, remember to change the __auto_type handling as well.)
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 3 Jun 2014, Vincent Lefevre wrote:
> On 2014-06-02 21:20:57 +0000, Joseph S. Myers wrote:
> > ([...] Conversion from __float128 to __ibm128 would presumably be
> > done in the usual way of converting to double, and, if the result is
> > finite, subtracting the doubl
libraries, with
some dynamic linker magic to pick the right ones and avoid duplicating
any libraries that don't involve long double in their interfaces, does
have some attraction.)
--
Joseph S. Myers
jos...@codesourcery.com
and short), is
called.
It probably makes sense by now to enable -Wimplicit-function-declaration
by default, though that won't catch cases where the file with the
unprototyped call has a non-prototype declaration such as "int foo();".
--
Joseph S. Myers
jos...@codesourcery.com
presumably be done in the usual way of converting to double, and, if the
result is finite, subtracting the double from the __float128 value,
converting the remainder, and renormalizing in case the low part you get
that way is exactly 0.5ulp of the high part and the high part has its low
bit set.)
--
Joseph S. Myers
jos...@codesourcery.com
t; and "supported with VSX / AltiVec ABI",
as opposed to "supported using GPRs/FPRs" and "supported with VSX /
AltiVec", then the "not supported" case could continue to be built with
older GCC - but you'd still be increasing the minimum GCC version for LE
builds.)
--
Joseph S. Myers
jos...@codesourcery.com
endianness but
"permuting load" for the other endianness, for example - see the various
past discussions of issues with big-endian NEON.) But this isn't a case
for the vectorizer caring about endianness - rather, it simply needs to
ask the back end about the available opera
t;//gcc.gnu.org/FOO") - that's what Wikipedia does for links that
should go to http or https according to how the page with the link is
being accessed - or simply all be changed to https (I don't think browsers
should object to https content such as stylesheets referenced by an ht
be possible for programs to use a common
subset that works in both languages in some cases).
--
Joseph S. Myers
jos...@codesourcery.com
d) and presume they are tested for by C99 facilities such as
fetestexcept - which has no way to return any sort of error status.
--
Joseph S. Myers
jos...@codesourcery.com
the support is in kernel.org and so the
value can be set to the actual first kernel with the support
(arch_minimum_kernel=10.0.0 may be used in future for any other cases
where glibc support for a port or port variant gets in before the kernel
support.)
--
Joseph S. Myers
jos...@codesourcery.com
ve, and so gets corrupted because the signaling NaN gets converted to
quiet along the way.)
--
Joseph S. Myers
jos...@codesourcery.com
anipulation of bit-patterns and no NaN constants,
would be don't-care by this logic).
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 18 Mar 2014, Thomas Preud'homme wrote:
> > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> > Joseph S. Myers
> >
> > The functions affected use floating-point in their public interfaces - for
> > example, __muldc3. Note
-math-optimizations then
> it should flip it back onto fast?
That seems reasonable.
--
Joseph S. Myers
jos...@codesourcery.com
that pass
arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in
RTABI) or don't involve floating point, then you can be compatible with
both calling conventions.
--
Joseph S. Myers
jos...@codesourcery.com
unctions use only the base AAPCS and so don't affect
compatibility even if they have floating-point (or vector) arguments.
(This is something that's different on some other architectures with
similar issues.)
--
Joseph S. Myers
jos...@codesourcery.com
exit
with an error means PASS, exit successfully means FAIL), that's what
dg-shouldfail is for.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 26 Feb 2014, Torvald Riegel wrote:
> On Fri, 2014-02-21 at 22:10 +0000, Joseph S. Myers wrote:
> > On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> >
> > > This needs to be as follows:
> > >
> > > [[carries_dependency]] int getzero(int i [[carr
7;t know what dependencies might be
carried. "Note: The carries_dependency attribute does not change the
meaning of the program, but may result in generation of more efficient
code. - end note".
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 17 Feb 2014, Torvald Riegel wrote:
> On Mon, 2014-02-17 at 18:59 +0000, Joseph S. Myers wrote:
> > On Sat, 15 Feb 2014, Torvald Riegel wrote:
> >
> > > glibc is a counterexample that comes to mind, although it's a smaller
> > > code base. (It&
omics (GCC builtins rather than _Atomic /
, but using __atomic_* with explicitly specified memory model
rather than the older __sync_*) on AArch64, plus in certain cases on ARM
and MIPS.
--
Joseph S. Myers
jos...@codesourcery.com
d
be safe to run on untrusted input files.
--
Joseph S. Myers
jos...@codesourcery.com
ntly glibc over the past couple
of years) and other responsibilities. I'd like to do more in various of
these areas, to get missing standard / proposed standard features
implemented in GCC and glibc, to ensure proposed standards and extensions
are high quality, to get the standards to better address areas in which
they are weak. But there are limits to both total time available and time
I can actually justify spending on these things.
--
Joseph S. Myers
jos...@codesourcery.com
read-modify-write to a word containing another field, for example) and I
think it's pretty obvious that glibc should do so as well.
(Of course, memset is not an atomic operation, and you need to allow for
that if you use it on an _Atomic object - which is I think valid, unless
the object is al
think ld.so needs to save and
restore those registers (and so there isn't much point making it avoid
floating point). See
<https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>.
--
Joseph S. Myers
jos...@codesourcery.com
ven necessarily get compatibility for the alignment of
_Atomic types yet (and no ABI document I've seen discusses that issue).
--
Joseph S. Myers
jos...@codesourcery.com
e the case that Y' interoperates with X, X' interoperates with Y, but X'
and Y' don't interoperate with each other. I'd envisage something more
like mapping not to instructions, but to concepts within the
architecture's own memory model - but that requires the architecture's
memory model to be as well defined, and probably formalized, as the C11
one.)
--
Joseph S. Myers
jos...@codesourcery.com
of the last
floating-point group meeting and agenda for the next). Again, any
comments are best sent direct to WG14.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 28 Jan 2014, DJ Delorie wrote:
> Ping? Or do I need to repost on the patches list?
Repost on the patches list (with self-contained write-up, rationale for
choices made, etc.) at the start of stage 1 for 4.10/5.0, I suggest (this
clearly isn't stage 3 material).
--
Joseph
p://gcc.gnu.org/gccmission.html>.
--
Joseph S. Myers
jos...@codesourcery.com
the resulting
patches.
* Andrew MacLeod's plans for improving static typing are I think largely
about the middle end - there is plenty of scope for improving static
typing of datastructures used in the front ends, and cleanly separating
them from the language-independent compiler as fa
t annotations for noreturn functions (so control can't actually
reach the end of the function but GCC can't tell that).
--
Joseph S. Myers
jos...@codesourcery.com
o it ?
I'll leave it to Dodji as diagnostics maintainer to advise on the best way
to implement error_at_no_args.
--
Joseph S. Myers
jos...@codesourcery.com
rror_at_no_args (location, message) that
accepts and processes only formats taking no arguments (and probably
aborts if given a format that needs arguments).
--
Joseph S. Myers
jos...@codesourcery.com
configuration.
--
Joseph S. Myers
jos...@codesourcery.com
stic text).
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 14 Jan 2014, H.J. Lu wrote:
> On Tue, Jan 14, 2014 at 11:37 AM, Joseph S. Myers
> wrote:
> > On Tue, 14 Jan 2014, H.J. Lu wrote:
> >
> >> When there is -static, -dynamic-linker won't passed to ld. -static,
> >> -shared, -pie should be mutually e
how
useful more general static PIE support would be.)
(-shared and -pie do seem mutually exclusive, as the first says what's
being linked operates as a library and the second says it operates as an
executable - although of course the same ET_DYN can operate as both.)
--
Joseph S. Myers
jos...@codesourcery.com
d line options?
That seems reasonable.
--
Joseph S. Myers
jos...@codesourcery.com
lN (for
valid N) as keywords - an infinite number of keywords - much as we handle
_Imaginary as a keyword without otherwise implementing it.)
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 8 Jan 2014, Vincent Lefevre wrote:
> On 2014-01-07 16:45:49 +0000, Joseph S. Myers wrote:
> > Sure, such a correctly rounded function is useful just like correctly
> > rounded versions of other functions. The proposed C bindings reserve cr*
> > names *only* for t
On Tue, 7 Jan 2014, Vincent Lefevre wrote:
> On 2014-01-07 14:48:01 +0000, Joseph S. Myers wrote:
> > (Except that the IEEE 754 reduction operations - subclause 9.4 - return
> > "an implementation-defined approximation". But 9.2 is "Recommended
> > correc
asymptotic cost of the exhaustive searches?
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 7 Jan 2014, Joseph S. Myers wrote:
> The IEEE 754 operations are corrected rounded. However, the C bindings
(Except that the IEEE 754 reduction operations - subclause 9.4 - return
"an implementation-defined approximation". But 9.2 is "Recommended
correctly round
On Tue, 7 Jan 2014, Florian Weimer wrote:
> On 01/04/2014 07:21 PM, Joseph S. Myers wrote:
>
> > FYI: a draft set of C bindings for additional floating-point functions
> > from IEEE 754-2008 are now available (draft TS 18661-4):
>
> Is there an accurate summary of IEEE 7
(part 2)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1784.pdf (part 3)
Any issues with these draft bindings would best be reported directly to
WG14 (sc22w...@open-std.org). Parts 1 and 2 are in ballot, parts 3 and 4
are at earlier stages of development.
--
Joseph S. Myers
jos
tually be fully configured for the C library in
use). So it might not be a good idea to make it do anything specific to
newlib.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> I think this has been discussed in some PR, unfortunately I can't find it.
Bug 57725?
--
Joseph S. Myers
jos...@codesourcery.com
still?
I think a patch is more useful once believe feature-complete, which means
replacing the __int128 support with the new mechanism.
--
Joseph S. Myers
jos...@codesourcery.com
would be
> affected (x86-64 isn't, I don't think any others are).
No existing target defines LONG_LONG_TYPE_SIZE to more than 64.
--
Joseph S. Myers
jos...@codesourcery.com
TImode, __int128) pair should be handled the same way as all the
other __intN types rather than special-cased (of course you should ensure
the patch does not end up changing the set of configurations for which
__int128 is available).
--
Joseph S. Myers
jos...@codesourcery.com
such
__SIZEOF_INT__ macros for whichever such types are available - in which
case no_backend is true.)
--
Joseph S. Myers
jos...@codesourcery.com
as __int128 does have mangling
defined in cp/mangle.c, and targets can already define their own mangling
for target-specific types through a hook.)
--
Joseph S. Myers
jos...@codesourcery.com
u isn't behaving as intended on your
system.
--
Joseph S. Myers
jos...@codesourcery.com
st with comment
> '(test for excess errors' ?
No, FAILs indicate a bug in either the compiler or the testcase (or in
your test environment, etc.); don't ignore them.
--
Joseph S. Myers
jos...@codesourcery.com
passed to the
compiler.)
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 2 Dec 2013, Jan-Benedict Glaw wrote:
> On Mon, 2013-12-02 12:08:25 +0100, Gerald Pfeifer wrote:
> > On Tue, 26 Nov 2013, Joseph S. Myers wrote:
> > > I think it's time to remove targets that have been under
> > > --enable-obsolete
> > > fo
st in
<http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00248.html>) (the avr-rtems
failures seem to be an issue with missing or broken stdint.h
configuration, though I'm not sure why it would be missing there).
--
Joseph S. Myers
jos...@codesourcery.com
7;d call neglectible.
For example, the list should include at least one target for every target
header in GCC. So if there's a header specific to an (architecture, OS)
pair, a matching configuration should be included.
--
Joseph S. Myers
jos...@codesourcery.com
ut in some new arrays supporting whatever set of intN
types the target has. That's just a guess; whether you follow or don't
follow it, your analysis of the code needs to justify your choice.
--
Joseph S. Myers
jos...@codesourcery.com
through a series
of small cleanup patches that clearly isolate anything that might possibly
change behavior at all than through one huge patch. So any small obvious
things are naturally separated out.
(c) Iteration over C types has other complications such as preferences
between different types (e.g. int and long) with the same middle-end
properties.
(d) I don't think the standard C types are particularly relevant to your
project.
--
Joseph S. Myers
jos...@codesourcery.com
e defined in builtin-types.def rather than tree.[ch]. For example,
complex_integer_type_node and float_ptr_type_node. But I don't think
cleaning up those would actually help in any way towards your goal; it
would be a completely orthogonal cleanup.
--
Joseph S. Myers
jos...@codesourcery.com
(as it was in gcc 4.5.2 I presume) ?
This is now handled through the TARGET_OPTION_OPTIMIZATION_TABLE hook (in
gcc/common/config).
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 18 Nov 2013, Basile Starynkevitch wrote:
> On Mon, 2013-11-18 at 13:17 +0000, Joseph S. Myers wrote:
> > On Sun, 17 Nov 2013, Basile Starynkevitch wrote:
> >
> > > What would be the good way to add such a plugin event to GCC 4.9?
> >
> > See the c
articular the file_change one) wouldn't be enough.
--
Joseph S. Myers
jos...@codesourcery.com
w being
substantially on par with C99 support. (I still need to update
implement-c.texi for C11 and some other bits of documentation for the
state of C99 and C11 support, but that doesn't need to be done in
development stage 1. And release notes are still needed for for _Generic,
_Atomic and _Thread_local support.)
--
Joseph S. Myers
jos...@codesourcery.com
ctions embed information about the integer and floating-point
types involved and a better way would be needed to extract the underlying
operation for a built-in function and identify the function, if any, for
an arbitrary type or pair of types.)
--
Joseph S. Myers
jos...@codesourcery.com
glibc for GCC to use in
expansion of FLT_ROUNDS and atomic compound assignment. Any hooks should
accommodate targets wishing in some cases just to generate their own libc
call like this.
--
Joseph S. Myers
jos...@codesourcery.com
n
command-line options (TImode only being supported for -m64, for example).
--
Joseph S. Myers
jos...@codesourcery.com
such operations to use modes the target supports still
takes place entirely at RTL expansion time, when it might be better to do
it on GIMPLE and let GIMPLE optimizers work on the larger-type
arithmetic).
If you do want types without corresponding modes, that goes back to having
a hook to list the relevant type sizes.
--
Joseph S. Myers
jos...@codesourcery.com
t
for integer types for now.)
--
Joseph S. Myers
jos...@codesourcery.com
value in a function returning non-void, implicit int and
implicit function declarations are all things removed in C99 for which it
may now make sense to enable warnings by default.
--
Joseph S. Myers
jos...@codesourcery.com
be arbitrary (so I suppose
there would be a single RID_INTN for them) - that seems cleaner than the
system for address space keywords with a fixed block from RID_ADDR_SPACE_0
to RID_ADDR_SPACE_15.
--
Joseph S. Myers
jos...@codesourcery.com
ignment on file who is interested in maintaining a front end
on a branch and hopefully contributing it to trunk in future.
--
Joseph S. Myers
jos...@codesourcery.com
ly
developed GPL Pascal compiler, Free Pascal, albeit for different versions
of the Pascal language).
In general, for GCC development to consider requirements of your front end
or back end, getting it into the GCC repository and developing it there is
strongly recommended.
--
Joseph S. Myers
jos...@codesourcery.com
rating GIMPLE code for the initializer and telling the middle end that
it should (ped)warn if it ends up being optimized to a constant, error if
it doesn't. But I rather hope that isn't needed.)
--
Joseph S. Myers
jos...@codesourcery.com
1 - 100 of 1215 matches
Mail list logo
