ing like
#define m(x) 0
int i = m(1'2)+(3'4);
that is valid in both cases, but whose semantics differ depending on
whether the feature is enabled (with an appropriate check on the value of
i, and the test being run both in cases where it should be enabled and
cases where it shouldn
atomics support during stage
1, and also get _Thread_local done, then the C11 support can be described
as substantially complete in 4.9 with the same caveats as for C99.)
--
Joseph S. Myers
jos...@codesourcery.com
On Sun, 27 Oct 2013, Richard Sandiford wrote:
> Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK to install?
> Or, if the code is still needed, is there a testcase we could add?
OK. I agree that sign-extension makes no sense here (integer constants
are always nonnegative).
--
Jo
th work
on prefetching.
-The list above differs from that in N1256 as follows:
-"LIA compatibility annex" is removed, since it refers to C99's
-conformance to another standard rather than something for C
-implementations to do. The <stdint.h> and
-<inttypes.h> entries have been separated, but are a
-single entry in C99.
-
--
Joseph S. Myers
jos...@codesourcery.com
As far as I can see, the commit left empty libmudflap directories around
rather than removing them (SVN, unlike git, allows empty directories to be
represented in the repository).
--
Joseph S. Myers
jos...@codesourcery.com
se, NULL);
+
/* Remove the qualifiers for the rest of the expressions and create
the VAL temp variable to hold the RHS. */
nonatomic_lhs_type = build_qualified_type (lhs_type, TYPE_UNQUALIFIED);
--
Joseph S. Myers
jos...@codesourcery.com
\
+{ \
+ TEST_INCDEC_ARITH ((VALUE), ++, , 1, 1); \
+ TEST_INCDEC_ARITH ((VALUE), --, , 1, -1);\
+ TEST_INCDEC_ARITH ((VALUE), , ++, 0, 1); \
+ TEST_INCDEC_ARITH ((VALUE), , --, 0, -1);\
+} \
+ while (0)
+
+static void
+test_incdec (void)
+{
+ TEST_ALL_INCDEC_ARITH (0);
+ TEST_ALL_INCDEC_ARITH (1);
+ TEST_ALL_INCDEC_ARITH (2);
+ TEST_ALL_INCDEC_ARITH (-1);
+ TEST_ALL_INCDEC_ARITH (1ULL << 60);
+ TEST_ALL_INCDEC_ARITH (1.5);
+ static int ia[2];
+ TEST_INCDEC (int *, &ia[1], ++, , 1, 1);
+ TEST_INCDEC (int *, &ia[1], --, , 1, -1);
+ TEST_INCDEC (int *, &ia[1], , ++, 0, 1);
+ TEST_INCDEC (int *, &ia[1], , --, 0, -1);
+}
+
+int
+main (void)
+{
+ test_incdec ();
+ exit (0);
+}
--
Joseph S. Myers
jos...@codesourcery.com
that patch [C++].
>
> [C/C++:] Additionally, as Jakub proposed and other compilers also support,
> the patch accepts #pragma GCC ivdep for 'do' and 'while' loops.
The C front-end changes are OK.
--
Joseph S. Myers
jos...@codesourcery.com
rite to any other fields except as
part of a sequence of consecutive non-zero-width bit-fields, unless
allow-store-data-races is set).
--
Joseph S. Myers
jos...@codesourcery.com
ing
Warn(switch %qs is no longer supported)
alongside Ignore - see various options in c.opt for examples.
--
Joseph S. Myers
jos...@codesourcery.com
`int foo(float);' prototype causes
@@ -8242,7 +8256,8 @@ store_parm_decls_oldstyle (tree fndecl, const stru
&& INTEGRAL_TYPE_P (TREE_TYPE (parm))
&& TYPE_PRECISION (TREE_TYPE (parm))
< TYPE_PRECISION (integer_type_node))
- DECL_ARG_TYPE (parm) = integer_type_node;
+ DECL_ARG_TYPE (parm)
+ = c_type_promotes_to (TREE_TYPE (parm));
/* ??? Is it possible to get here with a
built-in prototype or will it always have
@@ -8406,7 +8421,7 @@ finish_function (void)
tree type = TREE_TYPE (args);
if (INTEGRAL_TYPE_P (type)
&& TYPE_PRECISION (type) < TYPE_PRECISION (integer_type_node))
- DECL_ARG_TYPE (args) = integer_type_node;
+ DECL_ARG_TYPE (args) = c_type_promotes_to (type);
}
}
--
Joseph S. Myers
jos...@codesourcery.com
) - if the types have the same mode, they have the same set of
values and so are not different in any way that matters for this
optimization. OK with that change.
--
Joseph S. Myers
jos...@codesourcery.com
tion to be valid (in the absence of VRP saying that -128
isn't a possible value) you'd need a GIMPLE representation for
ABS_EXPR, as distinct from ABS_EXPR.
You don't have the option there is for some arithmetic operations of
converting to a corresponding operation on u
Ping. This patch
<http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01131.html> is pending
review (hook addition, rs6000/powerpc changes).
--
Joseph S. Myers
jos...@codesourcery.com
There's a whole g++.dg/cpp0x directory of tests, many of them using
-std=c++0x, for which the same principle would also suggest using the
non-deprecated option and the name for the actual standard
--
Joseph S. Myers
jos...@codesourcery.com
as an endless loop.)
>
> Do you have suggestions for a better wording? If not, is the patch okay for
> the trunk?
> Built and regtested (C only). [An all-language bootstrap + regtesting is
> underway.]
The C front-end changes in this version are OK.
--
Joseph S. Myers
jos...@codesourcery.com
ow _Alignas here.
> testsuite/
> * gcc.dg/c1x-align-5.c: Add more testing.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
.");
Also note GNU Coding Standards for diagnostics. They should not start
with uppercase letters or end with ".".
--
Joseph S. Myers
jos...@codesourcery.com
OK
> +(store_bounds_for_arg,
> + "This hook is used to emit insn to store arg's bounds\n\
> +in case bounds are not passed on register.",
> + void, (rtx, rtx, rtx, rtx),
> + default_store_bounds_for_arg)
Likewise.
--
Joseph S. Myers
jos...@codesourcery.com
by the standard it should be "false" in
c_parser_struct_declaration as well - the syntax there doesn't allow
_Alignas - but it appears to have been intended to allow it there, so
probably best not to change anything there until WG14 reaches a conclusion
on the issues I raised in N1731.)
--
Joseph S. Myers
jos...@codesourcery.com
gt; pi; /* { dg-error "distinct pointer types" } */
+ r = pai <= pi; /* { dg-error "distinct pointer types" } */
+ r = pai >= pi; /* { dg-error "distinct pointer types" } */
+ r = pav == pi; /* { dg-error "distinct pointer types" } */
+ r = pav != pi; /* { dg-error "distinct pointer types" } */
+ r = pi == pav; /* { dg-error "distinct pointer types" } */
+ r = pi != pav; /* { dg-error "distinct pointer types" } */
+ (void) (r ? pai : pi); /* { dg-error "pointer type mismatch" } */
+ (void) (r ? pi : pai); /* { dg-error "pointer type mismatch" } */
+ (void) (r ? pai : pav); /* { dg-error "pointer type mismatch" } */
+ (void) (r ? pav : pai); /* { dg-error "pointer type mismatch" } */
+}
Index: gcc/testsuite/gcc.dg/c90-atomic-1.c
===
--- gcc/testsuite/gcc.dg/c90-atomic-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/c90-atomic-1.c (revision 0)
@@ -0,0 +1,7 @@
+/* Test for _Atomic: not in C90. */
+/* { dg-do compile } */
+/* { dg-options "-std=c90 -pedantic-errors" } */
+
+_Atomic int i; /* { dg-error "_Atomic" } */
+_Atomic (int) j; /* { dg-error "_Atomic" } */
+int *_Atomic p; /* { dg-error "_Atomic" } */
--
Joseph S. Myers
jos...@codesourcery.com
ng to think of this, and alignment for cris, as things that don't
need to be done before the work is mainline-ready - if the basic support
is in, architecture maintainers can add whatever hooks they need for their
architectures later, not just in development stage 1.
--
Joseph S. Myers
jos...@codesourcery.com
tributes and hook can be completely
avoided on that basis.)
--
Joseph S. Myers
jos...@codesourcery.com
Note that the associated glibc patch
<https://sourceware.org/ml/libc-alpha/2013-10/msg00515.html> is now
approved, pending the GCC one.
--
Joseph S. Myers
jos...@codesourcery.com
s, and then be
copied in a form using -Wfloat-conversion to verify that
-Wfloat-conversion also causes the same warnings.
Looking at <http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01148.html>,
there are also some formatting problems, "if(" which should have a space
before the "(".
--
Joseph S. Myers
jos...@codesourcery.com
equirement).
You seem to be starting from a user having a program that instead of
expecting the normal target-independent semantics expects some other
semantics specified by an ABI document, where those semantics contradict
the semantics of ISO C.
--
Joseph S. Myers
jos...@codesourcery.com
structure can be similarly rewritten by the
user so the adjacent fields become bit-fields, if they want the
strict-volatile-bitfields requirements for their code to be compatible
with the memory model.
--
Joseph S. Myers
jos...@codesourcery.com
docstring relicensing maintainers and ask us
to approve the GPL relicensing in that case.
--
Joseph S. Myers
jos...@codesourcery.com
_parser_direct_declarator_inner): Likewise.
> (c_parser_parameter_declaration): Likewise.
> (c_parser_type_name): Likewise.
> testsuite/
> * gcc.dg/c1x-align-5.c: New test.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
a[_Alignas (int) 10]; /* { dg-error "meaningless in array declarator"
> } */
> + foo (a);
> + return 0;
> +}
I think this should also be tested after "static" (given that there are
two separate calls to c_parser_declspecs involved), as well as in an
abstract declarator.
--
Joseph S. Myers
jos...@codesourcery.com
0)
@@ -0,0 +1,16 @@
+/* Test __GCC_IEC_559 and __GCC_IEC_559_COMPLEX macros values. */
+/* { dg-do preprocess } */
+/* { dg-options "" } */
+
+#ifndef __GCC_IEC_559
+# error "__GCC_IEC_559 not defined"
+#endif
+#ifndef __GCC_IEC_559_COMPLEX
+# error "__GCC_IEC_559_COMPLEX not defined"
+#endif
+#if __GCC_IEC_559_COMPLEX > __GCC_IEC_559
+# error "__GCC_IEC_559_COMPLEX > __GCC_IEC_559"
+#endif
+#if __GCC_IEC_559_COMPLEX < 0
+# error "__GCC_IEC_559_COMPLEX < 0"
+#endif
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 203606)
+++ gcc/config.gcc (working copy)
@@ -2198,6 +2198,7 @@ powerpc*-*-linux*)
tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h rs6000/sysv4.h"
extra_options="${extra_options} rs6000/sysv4.opt"
tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file}
rs6000/t-ppccomm"
+ extra_objs="$extra_objs rs6000-linux.o"
case ${target} in
powerpc*le-*-*)
tm_file="${tm_file} rs6000/sysv4le.h" ;;
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 15 Oct 2013, Marek Polacek wrote:
> Ping^2. Jason, Joseph, are you fine with the C++/C FE changes?
The C changes are fine with me.
--
Joseph S. Myers
jos...@codesourcery.com
osest containing directory to the
file being modified. Since there's one in gcc/c-family, that means the
path in this case is just c-common.c.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 11 Oct 2013, David Malcolm wrote:
> Thanks. Presumably the initially posted configure/make patch still
> needs review, right?
Yes (by a build system maintainer, probably).
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 11 Oct 2013, David Malcolm wrote:
> On Thu, 2013-10-10 at 01:05 +0000, Joseph S. Myers wrote:
> > On Wed, 9 Oct 2013, David Malcolm wrote:
> >
> > > This patch adds an "--enable-host-shared" option throughout the various
> > > configure/Make ma
len" which sounds like
implementation terminology; this is the user manual and needs to describe
things in user terms, not in terms of the implementation.
--
Joseph S. Myers
jos...@codesourcery.com
My only comment is that you change the parameters to
c_parser_binary_expression, but don't change the comment above that
function documenting what they are.
--
Joseph S. Myers
jos...@codesourcery.com
particularly useful
at the stage where it just means PIC rather than actual shared libraries).
--
Joseph S. Myers
jos...@codesourcery.com
Also note that this patch needs to add testcases to the testsuite
(gcc/testsuite/c-c++-common/, probably) testing what cases generate
warnings with the new option and what cases don't.
--
Joseph S. Myers
jos...@codesourcery.com
should be submitted separately, as cleanups that can
be proposed on their own merits.
Note that casts use spaces, "(type) expr", as detailed at
<http://gcc.gnu.org/codingconventions.html#C_Formatting>.
--
Joseph S. Myers
jos...@codesourcery.com
mbler in some
cases (e.g. for large blocks of debug info) rather than generating and
then parsing text. (So some asm_out methods would gain implementations
passing such data instead of generating text.)
--
Joseph S. Myers
jos...@codesourcery.com
ion of float to long double is trivially equivalent to a conversion
involving an intermediate "double" type, so it reduces to a case for which
the standard formula involving precisions of just two types applies.)
--
Joseph S. Myers
jos...@codesourcery.com
something opened with
open_memstream, while a larger cleanup would narrow the interface to
writing such text as far as possible (to well-defined diagnostic and
dumping interfaces that don't directly take a FILE *, eliminating all ad
hoc calls to fprintf etc.).
--
Joseph S. Myers
jos...@codesourcery.com
development version in public
version control, as well as snapshots and non-FSF releases. The effect is
that if the first copyright year in a GCC source file is 1987 or later, a
single range -2013 can be used.
--
Joseph S. Myers
jos...@codesourcery.com
test macros that are only properly effective if defined
before any system headers are included, and these macros (affecting such
things as the size of off_t) need to be consistent throughout GCC.
--
Joseph S. Myers
jos...@codesourcery.com
eneric rules to be used (my understanding
was that the auto-deps patch series made lots of such changes to the
locations of .o files in the build tree to avoid needing special
compilation rules for particular files)?
--
Joseph S. Myers
jos...@codesourcery.com
; significantly simpler.
>
> Joseph, any comments on this?
No comments here.
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 16 Sep 2013, Marek Polacek wrote:
> On Fri, Sep 13, 2013 at 07:18:24PM +0000, Joseph S. Myers wrote:
> > On Fri, 13 Sep 2013, Marek Polacek wrote:
> >
> > > This is kind of fugly, but don't have anything better at the moment.
> > > 2013-09-13 Marek
xpression if we can prove it is correct.
Shouldn't the conditions used here for an expression being proved correct
match those for instrumentation, i.e. depend on flag_isoc99 and on
(cxx_dialect == cxx11 || cxx_dialect == cxx1y)?
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 13 Sep 2013, Marek Polacek wrote:
> On Thu, Sep 12, 2013 at 04:05:48PM +0000, Joseph S. Myers wrote:
> > cause stack overflow that doesn't get detected by the kernel. So maybe
> > ubsan should imply -fstack-check or similar.
>
> Well, I have a patch for that,
-ftree-slp-vectorize -fno-tree-vectorize
Should mean -ftree-slp-vectorize.
--
Joseph S. Myers
jos...@codesourcery.com
he entry should go there without the initial
c/ in the file name in the ChangeLog entry.
The patch is OK with the addition of the testcase you gave to
gcc.target/i386/.
--
Joseph S. Myers
jos...@codesourcery.com
believe sizes (in bytes) greater than target PTRDIFF_MAX, not
just SIZE_MAX, should be caught, because pointer subtraction cannot work
reliably with larger objects. So it's not just when the size or
multiplication overflow size_t, but when they overflow ptrdiff_t.)
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 12 Sep 2013, Joseph S. Myers wrote:
> (Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not
> just SIZE_MAX, should be caught, because pointer subtraction cannot work
> reliably with larger objects. So it's not just when the size or
> multip
hould be
> discussed on gcc@ before having the actual patch reviewed?
I'm thinking of this as a build-system change rather than a driver one.
--
Joseph S. Myers
jos...@codesourcery.com
ix targets with non-GNU system assembler/linker, it can be
made unconditional.)
So only targets where TLS support was a recent addition to the GNU
assembler, or those supporting a non-GNU assembler where TLS may or may
not be supported, would need such a test at all.
--
Joseph S. Myers
jos...@codesourcery.com
ar design - a clear understanding of what sort of paths should be used
where and what interfaces should translate them to other kinds of paths -
rather than just locally changing the paths used in one particular place
without a basis for arguing that the change fits a coherent design and so
won't cause problems elsewhere.
--
Joseph S. Myers
jos...@codesourcery.com
be the relocated prefix rather than
the unrelocated one.
If there is a bug, I'd say it's in whatever code is calling update_path
without having first done the make_relative_prefix relocation on the path
being passed to update_path. Thus, it is that caller that you need to
fix.
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 9 Sep 2013, Mike Stump wrote:
> On Sep 9, 2013, at 3:48 PM, "Joseph S. Myers" wrote:
> > On Mon, 9 Sep 2013, Mike Stump wrote:
> >
> >> Presently gcc just dies with a crash for an unhanded operation, the
> >> below handles it better.
> &g
e
well-defined source code feature lacking GCC support, or exceeding
implementation limits in GCC).
--
Joseph S. Myers
jos...@codesourcery.com
ourse it becomes more
complicated to identify which front-end files are still including tm.h, as
they may include it indirectly.)
--
Joseph S. Myers
jos...@codesourcery.com
x27;t
think it's a priority.)
--
Joseph S. Myers
jos...@codesourcery.com
y headers if those are available when
the compiler is configured, it only supports checking the default multilib
and not headers for other multilibs.
--
Joseph S. Myers
jos...@codesourcery.com
re. I've certainly
spent longer than that on review in this thread. It's normal for a patch
involving anything at all tricky to take hours to write up (and also
normal for one to discover, in the course of writing the detailed coherent
analysis for people who aren
as below.
This patch submission still fails to pay attention to various of my
comments.
--
Joseph S. Myers
jos...@codesourcery.com
--enable-data-races and require it to be used along with
--disable-threads, or something like that.
--
Joseph S. Myers
jos...@codesourcery.com
would
seem better to have __SIZE_MAX__ in the test (or a macro defined in the
test that defaults to __SIZE_MAX__ but is overridden for particular
targets, if some targets need it overridden).
--
Joseph S. Myers
jos...@codesourcery.com
e four types, but not
with long_double_type_node directly).
The patch submission will need to include a proper analysis to justify to
the reader why the particular inequality with particular types from those
four is correct in all cases where the relevant code may be executed.
--
Joseph S. Myers
jos...@codesourcery.com
DE (double_type_node)) &&
> +!flag_unsafe_math_optimizations)
> + break;
Please reread my previous messages on this subject and try again, with
regard to both the patch itself and the accompanying analysis.
--
Joseph S. Myers
jos...@codesourcery.com
ating point to produce the more general
analysis. But in any case, it's for the patch submitter to give the full
explanation.)
--
Joseph S. Myers
jos...@codesourcery.com
tile-bitfields implies --param allow-store-data-races=1.
And my concern is specifically about the defaults - the default for ARM
should be the same C/C++ language as on other targets - rather than what
happens if someone specifies -fstrict-volatile-bitfields explicitly.
--
Joseph S. Myers
jos...@codesourcery.com
antics for non-packed structures as well - AAPCS
strict-volatile-bitfields is only compatible with --param
allow-store-data-races=1, which is not the default for any language
variant accepted by GCC (and I say that the default language semantics
here should not depend on the target arch
o name in
#define, #ifdef etc., and does not get converted to 0 in #if conditions
but is interpreted as an operator there. (The status of "new" and
"delete" in this regard is less clear; see
<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#369>.)
--
Joseph S. Myers
jos...@codesourcery.com
ith current git glibc. The existence of a
bug in some old library is not relevant here.
(c) I always advise writing such tests as *valid C code* using hex floats
(or if really necessary, unions), not *invalid C code* with aliasing
violations.
--
Joseph S. Myers
jos...@codesourcery.com
to have ignored my explanation of the necessary and
sufficient condition on the precisions of the respective types. The
conversion is not safe for sqrt if the two types are double and long
double and long double is x86 extended, for example.
--
Joseph S. Myers
jos...@codesourcery.com
headers and compute target_header_dir that way, to
the extent that the target headers need examining to determine
configuration of the compiler proper.
--
Joseph S. Myers
jos...@codesourcery.com
ose
targets, it's probably time to deprecate them (and then freely check in
changes that break them by requiring those types to be defined).
--
Joseph S. Myers
jos...@codesourcery.com
In convert_arguments I think you should be comparing TYPE_MAIN_VARIANT
(valtype) against double_type_node and long_double_type_node, rather than
just valtype.
This is PR c/35649 (so include that number in your ChangeLog entry and
close that bug as fixed).
--
Joseph S. Myers
jos
, consider whether the
code is actually correct to be using BITS_PER_UNIT at all - whether it's
the RTL-level QImode that is really what's relevant to the code.
--
Joseph S. Myers
jos...@codesourcery.com
his sort of
conditional expression.
--
Joseph S. Myers
jos...@codesourcery.com
not that I am found of the conditional, but only by curiosity.)
Previously, each string was inside a separate call to M_() - the strings
themselves were the msgid parameters. Now, the msgid parameter is not a
single string but a more complicated expression and xgettext may not
handle such expressions properly the way it handles having just a single
string as parameter.
--
Joseph S. Myers
jos...@codesourcery.com
On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
> Instead of defining the same macro several times in different
> translation units, we can just make it a function and use it where
> needed.
Have you made sure that po/exgettext still extracts the relevant messages
for translation (I'm not sure how
On Fri, 23 Aug 2013, Zoran Jovanovic wrote:
> New test case involving unions is added.
Tests for unions should include *execution* tests that the relevant bits
have the right values after the sequence of assignments.
--
Joseph S. Myers
jos...@codesourcery.com
ake_file rather than override it.
>
> B. Do nothing. On the general principle that if it ain't broke don't fix
> it.
>
> C. Draw up another patch that restricts the AVR patterns in config.gcc to
> -none and -elf.
A and C - I think both changes should be applied.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 23 Aug 2013, Alan Modra wrote:
> I'd like to import upstream libtool into gcc to support powerpc64le,
Has the sysroot semantics issue been resolved in upstream libtool, or do
you mean "import with 3334f7ed5851ef1e96b052f2984c4acdbf39e20c reverted"?
--
J
ses after the patch. (I realise such a test may only be
able to run for a subset of targets.)
--
Joseph S. Myers
jos...@codesourcery.com
e.
(ARM does support having processes with both endiannesses - indeed, a
process can change its own endianness with the unprivileged SETEND
instruction (deprecated in ARMv8) - although the Linux kernel has no
support for this the last time I checked, and big-endian ARM is rarely
used.)
--
Joseph S. Myers
jos...@codesourcery.com
old folder). So, I think you should detect this at some point in the
GIMPLE optimizations rather than changing fold-const at all (and as a
consequence, you then shouldn't need to change front-end pretty-printers).
--
Joseph S. Myers
jos...@codesourcery.com
r cases, exhaustive searches may
be needed to determine when the conversion is safe.
(Actually, this code appears to deal with cases with up to three types
involved - the operand, the result and the function that's called. This
complicates the analysis a bit, but the same principles
linker
and cc1 to search in those paths, and how multiple relevant options get
processed by the linker and cc1 after being passed to them, would be
needed to justify that a particular patch does achieve the desired search
order.
--
Joseph S. Myers
jos...@codesourcery.com
oals) without JavaScript, for example.
--
Joseph S. Myers
jos...@codesourcery.com
avr-*-* case that is too general, matching
nonsensical targets such as AVR Linux rather than just avr-*-none /
avr-*-elf.
--
Joseph S. Myers
jos...@codesourcery.com
; If all the tests pass, is the patch OK for trunk?
This is OK, with function_gnu removed (nothing appears to use it), if no
OS port maintainers object to the changes for their OSes within the next
week.
--
Joseph S. Myers
jos...@codesourcery.com
n (created two new constraints for that).
I think the -mmpx option should be documented in invoke.texi, and the new
machine modes / mode class should be documented in rtl.texi where other
machine modes / mode classes are documented. Beyond that, I have no
comments on this patch revision.
--
J
;ENUM_BITFIELD(built_in_function) function_code : 11;
> - ENUM_BITFIELD(built_in_class) built_in_class : 2;
> + ENUM_BITFIELD(built_in_class) built_in_class : 3;
>
>unsigned static_ctor_flag : 1;
>unsigned static_dtor_flag : 1;
Again, no. See the comment "No bits left." at the bottom of this
structure. Expanding widely used datastructures is a bad idea, although
this one isn't as bad to expand as tree_base.
--
Joseph S. Myers
jos...@codesourcery.com
t end for handling of qualifiers, to see what places might need to
handle _Atomic specially; I'll do those reviews separately. As previously
noted, one thing missing is the _Atomic ( type-name ) syntax.
--
Joseph S. Myers
jos...@codesourcery.com
file in a directory also writable by an attacker) not
just because of symlink attacks but also because it was possible to create
a hard link to another user's file, with similar potential for attacks as
with symlinks. Nowadays systems are more likely to restrict such hard
link creation (b
ra multilibs).
--
Joseph S. Myers
jos...@codesourcery.com
the latter first. (And as the
relevant functionality gets added to GCC's sanitizer, issues that show up
in bootstrap with it enabled will need fixing as well.)
--
Joseph S. Myers
jos...@codesourcery.com
27;s
looking rather like this whole feature hasn't been adequately reviewed
before commit
--
Joseph S. Myers
jos...@codesourcery.com
501 - 600 of 1676 matches
Mail list logo
