Re: [Patch, Fortran] PR44350 - add constraint check for BLOCK DATA
Early *PING* Tobias Burnus wrote: A rather simple patch, which tries to implement Fortran 2008's C1116 (see also PR for the wording). While creating the patch, I found a reject-valid issue, which is now tracked as PR fortran/58857. Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias
Re: [C++14] implement [[deprecated]].
On 10/22/2013 02:28 PM, Ed Smith-Rowland wrote: I think this is pretty easy - gnu::deprecated has the same semantics. Since we decided to have this now, we should also update the docs, thus htdocs/projects/cxx1y.html (which normally would link htdocs/gcc-4.9/changes.html, thus a line or so there too). Thanks! Paolo.
[PING] [PATCH, ARM] Fix line number data for PIC register setup code
Ping. Original submission at http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00903.html . This patch fixes a regression of 174 tests in the gdb testsuite for arm-linux-gnueabi with -fPIC (or arm-linux-androideabi) caused by the fix for PR47028. The fix for PR47028 made sure that insertions on the single edge from ENTRY_BLOCK_PTR to the entry bb are committed after the parameters are available. However, the fix had as side-effect that the insertions could be committed both before and after NOTE_INSN_FUNCTION_BEG. Before the fix, the insertions were always committed before NOTE_INSN_FUNCTION_BEG. NOTE_INSN_FUNCTION_BEG has significance with respect to line number info, and insertions after the note caused wrong .loc info to be generated in the assembly in some cases, which caused the gdb test failures. This patch makes sure the insertions are committed before NOTE_INSN_FUNCTION_BEG. Thanks, - Tom
RE: FW: MAX_PATH problems with mingw gcc
> -Original Message- > From: Joey Ye [mailto:joey.ye...@gmail.com] > Sent: Monday, October 21, 2013 6:31 AM > To: Vladimir Simonov; Ian Lance Taylor; d...@redhat.com > Vladimir, > > I found no more issue on patch itself. But ChangeLogs are missing. > Please refer to format in /include/ChangeLog, and generate yours in your next > email for > > /include > /libcpp > /libiberty > > Maintainers of libiberty are in TO list. Hi Jan, DJ, Could you please clarify your positions about the problem and suggested patch? Attaching the patch for references. TBD. Here is not complete list of problems in gcc-based cross development when build platform uses DOS-style FS and target platform uses Linux-style FS: 1. If you do crossbuild with gcov support, binaries refer gcda files like C:\Myproject\Mydir\Myobj.gcda. After run on Linux files with names like "C:\Myproject\Mydir\Myobj.gcda" are created. No any directory tree; 2. Current filename_cmp fails to compare c:/a/b/.. and c:/a; 3. Include files names on DOS-style FS quite often become too long because of their "denormalization" after concatenation(i.e a/ + ../b becomes a/../b but may be used as b/); 4. The same (as 1.) problems appear in gdb during debug cross-built programs on Linux side. Best regards Vladimir gcc-4.8.1-filename-normalize-2.patch Description: gcc-4.8.1-filename-normalize-2.patch
RFA: Remove some code from c-lex.c:interpret_integer
interpret_integer has: integer = cpp_interpret_integer (parse_in, token, flags); integer = cpp_num_sign_extend (integer, options->precision); if (integer.overflow) *overflow = OT_OVERFLOW; where options->precision is the precision of (u)intmax_t. Looking at the implementation of cpp_num_sign_extend, it seems it would sign-extend (u)intmax_t-sized !integer.unsigned literals that have their top bit set. Smaller literals would stay zero-extended. Is that extension needed though? The rest of the function passes "integer" to narrowest_unsigned_type and narrowest_signed_type, both of which do unsigned comparisons between "integer" and various TYPE_MAX_VALUEs. It looks at face value like sign-extending here would make the result depend on the host. E.g. if uintmax_t occupies 2 HWIs with no excess bits, the extension would be a no-op and the result would still be <= TYPE_MAX_VALUE (uintmax_type_node). But if uintmax_t occupies only one HWI, the sign-extended integer would be greater than TYPE_MAX_VALUE (uintmax_type_node). Looking at cpp_interpret_integer, I can't see off-hand how we would end up with a !integer.unsigned literal that is still "negative" according to options->precision. 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? Thanks, Richard gcc/c-family/ * c-lex.c (interpret_integer): Remove call to cpp_num_sign_extend. Index: gcc/c-family/c-lex.c === --- gcc/c-family/c-lex.c2013-10-27 08:37:55.569236132 + +++ gcc/c-family/c-lex.c2013-10-27 11:03:57.721834320 + @@ -595,12 +595,10 @@ interpret_integer (const cpp_token *toke tree value, type; enum integer_type_kind itk; cpp_num integer; - cpp_options *options = cpp_get_options (parse_in); *overflow = OT_NONE; integer = cpp_interpret_integer (parse_in, token, flags); - integer = cpp_num_sign_extend (integer, options->precision); if (integer.overflow) *overflow = OT_OVERFLOW;
Re: [PATCH, PR 53001] Re: Patch to split out new warning flag for floating point conversion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
== Administrivia ==
This is my first patch. I have emailed in the signed copyright transfer
documents already. Several versions of this patch have been sent to
the mailing list already. I believe that I have incorporated all
comments into the attached patches.
=== Description ===
As required by the C and C++ standards, gcc automatically converts
floating point numbers to lower precision or integer values. Silently
converting these values is a problem for numerical programs. GCC
already has a flag -Wconversion which does warn about these conversions,
but -Wconversion also warns about integer conversion which means for
many programs the number of warnings will be large.
This patch adds a -Wfloat-conversion that only warns on float
conversions. Here are three examples that are warned by this new flag:
int main(int argc, char ** argv) {
int i = 3.14;
return i;
}
int foo(double x)
{
return x;
}
float foo2(double x) {
return x;
}
Additional examples can be seen in the new_testcase variants.
The -Wfloat-conversion is enabled by -Wconversion (since it is a
subset)
It was suggested on the discussion for bug 53001 that this be enabled by
- -Wextra, but this version of the patch does not because that requires
additional changes to other parts of gcc to still be able to bootstrap
with -Werror since they rely on C and C++'s implicit conversion from
floating point to integer types.
I am not certain that c.opt was modified correctly.
There are three different variants attached, they are identical but
for the testcases, so see that section for details on the differences.
Only one of them should be applied.
== Testcases ==
There are three different methods of doing the testcase for these.
0. warn_float_patch_simple_trunk.diff
This version changes the existing tests to check for float-coversion
instead of conversion in the warning text. Since the testcases
already check for floating conversion in warnings, this is a possible
method of doing this.
1. warn_float_patch_and_new_testcase.diff
This adds a new testcase and checks for float-conversion in the
warning. This will add somewhat more time for running the testcases
compared to version 1 while still testing more or less the same code
paths. This does however check that the warning occurs when
- -Wconversion is not used.
2. warn_float_patch_and_new_testcase2.diff
This is the same as 1., but the warning check is more specific. So
for example we have lines like:
fsi (3.1f); /* { dg-warning "conversion to 'int' alters 'float'
constant valu
e" } */
I am worried (possibly groundlessly) that this might not pass the
testcase on machines with different types that are available.
If you have a strong opinion or good reasons on which of these you
prefer, please tell me.
== Change logs ==
Changelog for warn_float_patch_simple_trunk.diff:
Splitting out a -Wfloat-conversion from -Wconversion for
conversions that lower floating point number precision
or conversion from floating point numbers to integers
* c-family/c-common.c Switching unsafe_conversion_p to
return an enumeration with more detail, and conversion_warning
to use this information.
* c-family/c-common.h Adding conversion_safety enumeration
and switching return type of unsafe_conversion_p
* c-family/c.opt Adding new warning float-conversion and
enabling it -Wconversion
* doc/invoke.texi Adding documentation about
-Wfloat-conversion
* testsuite/c-c++-common/Wconversion-real.c Switching tests
to use float-conversion
* testsuite/gcc.dg/Wconversion-real-integer.c Switching
tests to use float-conversion
* testsuite/gcc.dg/pr35635.c Switching tests to use
float-conversion
Changelog for warn_float_patch_and_new_testcase.diff and
warn_float_patch_and_new_testcase2.diff:
Splitting out a -Wfloat-conversion from -Wconversion for
conversions that lower floating point number precision
or conversion from floating point numbers to integers
* c-family/c-common.c Switching unsafe_conversion_p to
return an enumeration with more detail, and conversion_warning
to use this information.
* c-family/c-common.h Adding conversion_safety enumeration
and switching return type of unsafe_conversion_p
* c-family/c.opt Adding new warning float-conversion and
enabling it -Wconversion
* doc/invoke.texi Adding documentation about
-Wfloat-conversion
* testsuite/c-c++-common/Wfloat-conversion.c Copies relevant
tests from c-c++-common/Wconversion-real.c,
gcc.dg/Wconversion-real-integer.c and gcc.dg/pr35635.c into
new testcase for ones that are warned about by
-Wfloat-conversion
== Bootstrapping and testing ==
Tested bootstrap on x86_64-unknown-linux-gnu for
- --enable-languages=c,c++,fortran,java,
[C++ Patch Ping] PR 54485 (diagnose default arguments in out-of-line definitions for class template member functions)
Hi, pinging this patch of mine, sent beginning of September: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01435.html Just checked that it still applies cleanly and passes testing. Thanks! Paolo.
[wide-int] Treat order comparisons like other binary ops
Until now, eq_p and ne_p have enforced the same argument rules as things
like addition, while order comparisons like lts_p have treated the two
arguments as independent and signed. Richard, I think you said on IRC
that you thought lts_p should behave like the others. E.g. lts_p on two
trees or two rtxes should make sure that the precisions are the same.
This patch does that. I think all uses of INT_CST_LT and INT_CST_LT_UNSIGNED
are really comparing to "infinite" precision, and the UNSIGNED distinction is
only there because double_int isn't wide enough to be effectively infinite.
Is that right? Since that isn't a problem with widest_int, the patch gets
rid of INT_CST_LT_UNSIGNED and only uses INT_CST_LT.
The c-lex.c change includes a generic change that I justed posted for trunk.
I rejigged the order in tree.h slightly so that it matches trunk.
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK for wide-int?
Thanks,
Richard
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c 2013-10-27 14:11:53.006510519 +
+++ gcc/c-family/c-common.c 2013-10-27 14:19:27.667578745 +
@@ -4101,20 +4101,10 @@ shorten_compare (tree *op0_ptr, tree *op
maxval = convert (*restype_ptr, maxval);
}
- if (unsignedp && unsignedp0)
- {
- min_gt = INT_CST_LT_UNSIGNED (primop1, minval);
- max_gt = INT_CST_LT_UNSIGNED (primop1, maxval);
- min_lt = INT_CST_LT_UNSIGNED (minval, primop1);
- max_lt = INT_CST_LT_UNSIGNED (maxval, primop1);
- }
- else
- {
- min_gt = INT_CST_LT (primop1, minval);
- max_gt = INT_CST_LT (primop1, maxval);
- min_lt = INT_CST_LT (minval, primop1);
- max_lt = INT_CST_LT (maxval, primop1);
- }
+ min_gt = INT_CST_LT (primop1, minval);
+ max_gt = INT_CST_LT (primop1, maxval);
+ min_lt = INT_CST_LT (minval, primop1);
+ max_lt = INT_CST_LT (maxval, primop1);
val = 0;
/* This used to be a switch, but Genix compiler can't handle that. */
Index: gcc/c-family/c-lex.c
===
--- gcc/c-family/c-lex.c2013-10-27 14:11:53.006510519 +
+++ gcc/c-family/c-lex.c2013-10-27 14:19:27.664578718 +
@@ -48,9 +48,9 @@ static tree interpret_float (const cpp_t
enum overflow_type *);
static tree interpret_fixed (const cpp_token *, unsigned int);
static enum integer_type_kind narrowest_unsigned_type
- (const wide_int &, unsigned int);
+ (const widest_int &, unsigned int);
static enum integer_type_kind narrowest_signed_type
- (const wide_int &, unsigned int);
+ (const widest_int &, unsigned int);
static enum cpp_ttype lex_string (const cpp_token *, tree *, bool, bool);
static tree lex_charconst (const cpp_token *);
static void update_header_times (const char *);
@@ -526,7 +526,7 @@ c_lex_with_flags (tree *value, location_
there isn't one. */
static enum integer_type_kind
-narrowest_unsigned_type (const wide_int &val, unsigned int flags)
+narrowest_unsigned_type (const widest_int &val, unsigned int flags)
{
int itk;
@@ -545,7 +545,7 @@ narrowest_unsigned_type (const wide_int
continue;
upper = TYPE_MAX_VALUE (integer_types[itk]);
- if (wi::geu_p (upper, val))
+ if (wi::geu_p (wi::to_widest (upper), val))
return (enum integer_type_kind) itk;
}
@@ -554,7 +554,7 @@ narrowest_unsigned_type (const wide_int
/* Ditto, but narrowest signed type. */
static enum integer_type_kind
-narrowest_signed_type (const wide_int &val, unsigned int flags)
+narrowest_signed_type (const widest_int &val, unsigned int flags)
{
int itk;
@@ -573,7 +573,7 @@ narrowest_signed_type (const wide_int &v
continue;
upper = TYPE_MAX_VALUE (integer_types[itk]);
- if (wi::geu_p (upper, val))
+ if (wi::geu_p (wi::to_widest (upper), val))
return (enum integer_type_kind) itk;
}
@@ -588,20 +588,18 @@ interpret_integer (const cpp_token *toke
tree value, type;
enum integer_type_kind itk;
cpp_num integer;
- cpp_options *options = cpp_get_options (parse_in);
- HOST_WIDE_INT ival[2];
- wide_int wval;
+ HOST_WIDE_INT ival[3];
*overflow = OT_NONE;
integer = cpp_interpret_integer (parse_in, token, flags);
- integer = cpp_num_sign_extend (integer, options->precision);
if (integer.overflow)
*overflow = OT_OVERFLOW;
ival[0] = integer.low;
ival[1] = integer.high;
- wval = wide_int::from_array (ival, 2, HOST_BITS_PER_WIDE_INT * 2);
+ ival[2] = 0;
+ widest_int wval = widest_int::from_array (ival, 3);
/* The type of a constant with a U suffix is straightforward. */
if (flags & CPP_N_UNSIGNED)
Index: gcc/cp/call.c
===
--- gcc/cp/call.c 2013-10-27 14:11:53.006510519 +
+++ gcc/cp/c
Fix for cris-elf breakage from mudflap removal, take 2
PRED_NORETURN seems a better match; not that I see anything in the current source that actually treats them differently other than generating them, but my grep-fu may be weak and certainly my crystall-ball-fu is. After testing (no regressions compared to r204080 before the breakage), committed. * config/cris/cris.c (cris_emit_trap_for_misalignment): Replace the removed PRED_MUDFLAP with PRED_NORETURN. Correct file-path in comment. Index: gcc/config/cris/cris.c === --- gcc/config/cris/cris.c (revision 204101) +++ gcc/config/cris/cris.c (working copy) @@ -1989,17 +1989,14 @@ cris_emit_trap_for_misalignment (rtx mem /* This will yield a btstq without a separate register used, usually - with the exception for PRE hoisting the "and" but not the branch - around the trap: see gcc.dg/target/cris/sync-3s.c. */ + around the trap: see testsuite/gcc.target/cris/sync-3s.c. */ andop = gen_rtx_AND (Pmode, reg, GEN_INT (natural_alignment - 1)); emit_cmp_and_jump_insns (force_reg (SImode, andop), const0_rtx, EQ, NULL_RTX, Pmode, 1, ok_label); jmp = get_last_insn (); gcc_assert (JUMP_P (jmp)); - /* While this isn't mudflap, it is a similar kind of assertion. - If PRED_MUDFLAP stops working, use something else or introduce a - more suitable assertion predication type. */ - predict_insn_def (jmp, PRED_MUDFLAP, TAKEN); + predict_insn_def (jmp, PRED_NORETURN, TAKEN); expand_builtin_trap (); emit_label (ok_label); } brgds, H-P
[wide-int] More optimisations
This patch adds some more optimisations to the wi:: comparison functions.
It uses the:
#define CONSTANT(X) (__builtin_constant_p (X) && (X))
idiom that was mentioned before, except that I thought CONSTANT would be
too easily confused with CONSTANT_P, so I went for CAN_TELL instead.
Better names welcome.
The changes are:
- Add a fast path to eq_p for when one of the inputs isn't sign-extended.
This includes code to handle compile-time 0 specially.
- Add the opposite optimisation to Mike's lts_p change, if we can tell at
compile time that it applies.
- Add fast paths to ltu_p for constants.
E.g.:
bool
f1 (const_tree x)
{
return wi::eq_p (x, 0);
}
now gives:
xorl%eax, %eax
cmpw$1, 4(%rdi)
je .L5
rep ret
.p2align 4,,10
.p2align 3
.L5:
cmpq$0, 16(%rdi)
sete%al
ret
bool
f2 (const_tree x, HOST_WIDE_INT y)
{
return wi::eq_p (x, y);
}
gives:
movq8(%rdi), %rax
movzwl 52(%rax), %edx
xorl%eax, %eax
andw$1023, %dx
cmpw$1, 4(%rdi)
je .L10
rep ret
.p2align 4,,10
.p2align 3
.L10:
xorq16(%rdi), %rsi
movzwl %dx, %edx
movl$64, %ecx
subl%edx, %ecx
movq%rsi, %rax
salq%cl, %rax
testl %ecx, %ecx
cmovg %rax, %rsi
testq %rsi, %rsi
sete%al
ret
bool
f3 (HOST_WIDE_INT x, const_tree y)
{
return wi::lts_p (x, y);
}
is similarly ugly because of way that it ignores TYPE_SIGN and so has to
explicitly sign-extend "small-prec" cases:
movq8(%rsi), %rax
movzwl 4(%rsi), %ecx
movzwl 52(%rax), %edx
andl$1023, %edx
cmpl$1, %ecx
je .L16
leal-1(%rcx), %eax
sall$6, %ecx
subl%edx, %ecx
movq16(%rsi,%rax,8), %rax
movq%rax, %rdx
salq%cl, %rdx
testl %ecx, %ecx
cmovg %rdx, %rax
sarq$63, %rax
addl$1, %eax
ret
.p2align 4,,10
.p2align 3
.L16:
cmpl$63, %edx
movq16(%rsi), %rax
ja .L13
movb$64, %cl
subl%edx, %ecx
salq%cl, %rax
sarq%cl, %rax
.L13:
cmpq%rdi, %rax
setg%al
ret
but:
bool
f4 (HOST_WIDE_INT x, const_tree y)
{
return wi::lts_p (x, wi::to_widest (y));
}
is a bit more respectable:
movzwl 6(%rsi), %eax
cmpl$1, %eax
je .L20
subl$1, %eax
movq16(%rsi,%rax,8), %rax
sarq$63, %rax
addl$1, %eax
ret
.p2align 4,,10
.p2align 3
.L20:
cmpq%rdi, 16(%rsi)
setg%al
ret
For similar reasons:
bool
f5 (const_tree x)
{
return wi::ltu_p (x, 100);
}
gives:
movq8(%rdi), %rax
movzwl 52(%rax), %ecx
xorl%eax, %eax
andw$1023, %cx
cmpw$1, 4(%rdi)
je .L26
rep ret
.p2align 4,,10
.p2align 3
.L26:
cmpw$63, %cx
ja .L23
movl$1, %eax
salq%cl, %rax
subq$1, %rax
andq16(%rdi), %rax
.L24:
cmpq$99, %rax
setbe %al
ret
.p2align 4,,10
.p2align 3
.L23:
movq16(%rdi), %rax
jmp .L24
but:
bool
f6 (const_tree x)
{
return wi::ltu_p (wi::to_widest (x), 100);
}
gives:
xorl%eax, %eax
cmpw$1, 6(%rdi)
je .L30
rep ret
.p2align 4,,10
.p2align 3
.L30:
cmpq$99, 16(%rdi)
setbe %al
ret
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK for wide-int?
Thanks,
Richard
Index: gcc/system.h
===
--- gcc/system.h2013-10-27 14:25:19.144723977 +
+++ gcc/system.h2013-10-27 14:25:20.716738045 +
@@ -711,6 +711,12 @@ #define gcc_unreachable() __builtin_unre
#define gcc_unreachable() (fancy_abort (__FILE__, __LINE__, __FUNCTION__))
#endif
+#if GCC_VERSION >= 3001
+#define CAN_TELL(X) (__builtin_constant_p (X) && (X))
+#else
+#define CAN_TELL(X) (false && (X))
+#endif
+
/* Until we can use STATIC_ASSERT. */
#define STATIC_ASSERT(X) \
typedef int assertion1[(X) ? 1 : -1] ATTRIBUTE_UNUSED
Index: gcc/wide-int.h
===
--- gcc/wide-int.h 2013-10-27 14:25:19.144723977 +
+++ gcc/wide-int.h 2013-10-27 14:37:34.834443832 +
@@ -1495,6 +1495,7 @@ wi::eq_p (const T1 &x, const T2 &y)
WIDE_INT_REF_FOR (T2) yi (y, precision);
if (xi.is_sign_extended && yi.is_sign_extended)
{
+ /* This case reduces to array equality. */
if (xi.len != yi.len)
return false
Re: [PATCH, ARM] Fix line number data for PIC register setup code
> The PIC register setup code is emitted after NOTE_INSNS_FUNCTION_BEG,
> because it uses the insert_insn_on_edge mechanism, and the corresponding
> insertion in cfgexpand.c:gimple_expand_cfg takes care to insert the code
> after the parm_birth_insn:
> ...
> /* Avoid putting insns before parm_birth_insn. */
> if (e->src == ENTRY_BLOCK_PTR
> && single_succ_p (ENTRY_BLOCK_PTR)
> && parm_birth_insn)
> {
> rtx insns = e->insns.r;
> e->insns.r = NULL_RTX;
> emit_insn_after_noloc (insns, parm_birth_insn, e->dest);
> }
> ...
> And in the case for this test-case, parm_birth_insn is the
> NOTE_INSNS_FUNCTION_BEG.
So this means that parm_birth_insn can never be null, right?
> 2013-10-13 Tom de Vries
>
> * cfgexpand.c (gimple_expand_cfg): Don't commit insertions after
> NOTE_INSN_FUNCTION_BEG.
>
> * gcc.target/arm/require-pic-register-loc.c: New test.
OK if you also remove the test on parm_birth_insn.
--
Eric Botcazou
Rework c99status.html
GCC's c99status.html seem persistently to confuse people into thinking the state of C99 support is worse than it is, by listing things as "Missing" or "Broken" when in fact what's missing or broken isn't needed to implement C99 but is some optional extra for ideal support, or is only broken or missing on obscure platforms, or only relates to obscure corner cases most users are unlikely to encounter; people also seem to get confused by what "Library Issue" means, despite the explanation above the table. Readers don't generally seem to pay attention to the notes below the table that then explain exactly what is broken or missing for a particular entry. I've committed this patch to rework the page so it starts with a summary of the overall C99 state, then describes each feature by listing the GCC version in which it was substantially supported (not necessarily obscure corner cases), or "N/A" if no compiler support required, with further notes then directly included in the table where reasonable. Hopefully this will be less confusing to readers than the previous version. I think it would be appropriate to redirect all the c99status.html files for particular GCC versions to this file, now it covers all versions. Index: c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v retrieving revision 1.59 retrieving revision 1.62 diff -u -r1.59 -r1.62 --- c99status.html 28 Oct 2012 11:05:08 - 1.59 +++ c99status.html 27 Oct 2013 15:41:51 - 1.62 @@ -7,306 +7,363 @@ Status of C99 features in GCC +C99 is substantially completely supported as of GCC 4.5 +(with -std=c99 -pedantic-errors used), modulo bugs, +extended identifiers (supported except for corner cases +when -fextended-identifiers is used), and floating-point +issues (mainly but not entirely relating to optional C99 features from +Annexes F and G). The following table gives more details of the C99 +support in different GCC versions. + This table is based on the list in the foreword to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf";>N1256 (ISO/IEC 9899:1999 (E), consolidated with ISO/IEC 9899:1999/Cor.1:2001 (E), ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007 (E)). -Where "Library Issue" is listed in conjunction with some other -status, this means that some compiler support is needed for the -library support, or desirable in conjunction with it. Note that the -headers required of conforming freestanding implementations (clause 4 -paragraph 6) do not count as library issues. - -This page describes the C99 support in mainline GCC, not in any -particular release. Information is also available on C99 support in GCC 4.7, C99 support in GCC 4.6, C99 support in GCC 4.5, C99 support in GCC 4.4, C99 support in GCC 4.3, C99 support in GCC 4.2, C99 support in GCC 4.1, C99 support in GCC 4.0, C99 support in GCC 3.4, C99 support in GCC 3.3, C99 support in GCC 3.1 and 3.2 and on C99 support in GCC 3.0, but not on -the much more limited support in GCC 2.95. +The "Version" column indicates the first GCC version in which +support for the relevant feature was substantially present; some bugs +or corner cases may have been fixed in later versions; this column is +"N/A" if nothing is needed from the compiler for the feature to be +substantially supported (for example, if the feature refers to +addition of new library functions rather than language features), even +if additional compiler features could be useful in conjunction with +it. It is assumed that GCC is used with -std=c99 +-pedantic-errors (for versions 3.0 and later), as well +as -fextended-identifiers in the case of that feature. +Where library cooperation is required, it is assumed that a recent +version of the GNU C Library is in use, and support with other C +libraries may be less good. Where the version listed is before GCC +3.0, it should not be assumed that all corner cases follow C99 before +GCC 3.0, even if there is no specific note regarding corner cases. See below the table for further notes on some issues. Feature -Library Issue -Done -Broken -Missing +Version +Notes restricted character set support via digraphs and -(originally specified in AMD1) + (originally specified in AMD1) +GCC 2.7 -Done wide character library support in - and + and (originally specified in AMD1) -Library Issue -Missing +N/A +Library feature, no compiler support required. GCC doesn't +have wprintf, wscanf and +wcsftime format checking support. more precise aliasing rules via effective type -Done - +N/A +Optimization, no compiler support required. GCC has +optimized based on aliasing rules since GCC 2.95. restricted pointers -Done - +GCC 2.95 + -variable-length
Re: RFA: Remove some code from c-lex.c:interpret_integer
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). -- Joseph S. Myers jos...@codesourcery.com
[PATCH] Remove "keep_aligning" from get_inner_reference
Hi, On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote: > Finally I think the recursion into the VIEW_CONVERT_EXPR case > is only there because of the keep_aligning flag of get_inner_reference > which should be obsolete now that we properly handle its effects > in get_object_alignment. So you wouldn't need to adjust this path > if we finally can get rid of that. I think you are right, this flag is no longer necessary, and removing this code path would simplify everything. Therefore I'd like to propose to remove the "keep_aligning" parameter of get_inner_reference as a split-out patch. Boot-strapped (with languages=all,ada,go) and regression-tested on x86_64-linux-gnu. Ok for trunk? Thanks Bernd.2013-10-27 Bernd Edlinger Remove parameter keep_aligning from get_inner_reference. * tree.h (get_inner_reference): Adjust header. * expr.c (get_inner_reference): Remove parameter keep_aligning. (get_bit_range, expand_assignment, expand_expr_addr_expr_1, expand_expr_real_1): Adjust. * asan.c (instrument_derefs): Adjust. * builtins.c (get_object_alignment_2): Adjust. Remove handling of VIEW_CONVERT_EXPR. * cfgexpand.c (expand_debug_expr): Adjust. * dbxout.c (dbxout_expand_expr): Adjust. * dwarf2out.c (loc_list_for_address_of_addr_expr_of_indirect_ref, loc_list_from_tree, fortran_common): Adjust. * fold-const.c (optimize_bit_field_compare, decode_field_reference, fold_unary_loc, fold_comparison, split_address_to_core_and_offset): Adjust. * gimple-ssa-strength-reduction.c (slsr_process_ref): Adjust. * simplifx-rtx.c (delegitimize_mem_from_attrs): Adjust. * tree-affine.c (tree_to_aff_combination, get_inner_reference_aff): Adjust. * tree-data-ref.c (split_constant_offset_1, dr_analyze_innermost): Adjust. * tree-vect-data-refs.c (vect_check_gather, vect_analyze_data_refs): Adjust. * tree-scalar-evolution.c (interpret_rhs_expr): Adjust. * tree-ssa-loop-ivopts.c (may_be_unaligned_p, split_address_cost): Adjust. * tsan.c (instrument_expr): Adjust. * ada/gcc-interface/decl.c (elaborate_expression_1): Adjust. * ada/gcc-interface/trans.c (Attribute_to_gnu): Adjust. * ada/gcc-interface/utils2.c (build_unary_op): Adjust. * config/mips/mips.c (r10k_safe_mem_expr_p): Adjust. patch-inner-reference.diff Description: Binary data
Re: [PATCH] Enhance ifcombine to recover non short circuit branches
On Sat, Oct 26, 2013 at 4:49 PM, Andrew Pinski wrote:
> On Sat, Oct 26, 2013 at 2:30 PM, Andrew Pinski wrote:
>> On Fri, Oct 18, 2013 at 2:21 AM, Zhenqiang Chen
>> wrote:
>>> On 18 October 2013 00:58, Jeff Law wrote:
On 10/17/13 05:03, Richard Biener wrote:
>>>
>>> Is it OK for trunk?
>>
>>
>> I had a much simpler change which did basically the same from 4.7 (I
>> can update it if people think this is a better approach).
>
>
> I like that more (note you can now use is_gimple_condexpr as predicate
> for force_gimple_operand).
The obvious question is whether or not Andrew's simpler change picks up as
many transformations as Zhenqiang's change. If not are the things missed
important.
Zhenqiang, can you do some testing of your change vs Andrew P.'s change?
>>>
>>> Here is a rough compare:
>>>
>>> 1) Andrew P.'s change can not handle ssa-ifcombine-ccmp-3.c (included
>>> in my patch). Root cause is that it does not skip "LABEL". The guard
>>> to do this opt should be the same the bb_has_overhead_p in my patch.
>>
>> This should be an easy change, I am working on this right now.
>>
>>>
>>> 2) Andrew P.'s change always generate TRUTH_AND_EXPR, which is not
>>> efficient for "||". e.g. For ssa-ifcombine-ccmp-6.c, it will generate
>>>
>>> _3 = a_2(D) > 0;
>>> _5 = b_4(D) > 0;
>>> _6 = _3 | _5;
>>> _9 = c_7(D) <= 0;
>>> _10 = ~_6;
>>> _11 = _9 & _10;
>>> if (_11 == 0)
>>>
>>> With my patch, it will generate
>>>
>>> _3 = a_2(D) > 0;
>>> _5 = b_4(D) > 0;
>>> _6 = _3 | _5;
>>> _9 = c_7(D) > 0;
>>> _10 = _6 | _9;
>>> if (_10 != 0)
>>
>> As mentioned otherwise, this seems like a missed optimization inside
>> forwprop. When I originally wrote this code there used to be two
>> cases one for & and one for |, but this was removed sometime and I
>> just made the code evolve with that.
>
> Actually I can make a small patch (3 lines) to my current patch which
> causes tree-ssa-ifcombine.c to produce the behavior of your patch.
>
> if (result_inv)
>{
> t = fold_build1 (TRUTH_NOT_EXPR, TREE_TYPE (t), t);
> result_inv = false;
>}
>
> I will submit a new patch after some testing of my current patch which
> fixes items 1 and 2.
Here is my latest patch which adds the testcases from Zhenqiang's
patch and fixes item 1 and 2.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
ChangeLog:
* tree-ssa-ifcombine.c: Include rtl.h and tm_p.h.
(ifcombine_ifandif): Handle cases where
maybe_fold_and_comparisons fails, combining the branches
anyways.
(tree_ssa_ifcombine): Inverse the order of
the basic block walk, increases the number of combinings.
* gimple.h (gsi_start_nondebug_after_labels_bb): New function.
testsuite/ChangeLog:
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: New test case.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: New test case.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: New test case.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: New test case.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: New test case.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: New test case.
* gcc.dg/tree-ssa/phi-opt-9.c: Use a function call to prevent
conditional move to be used.
* gcc.dg/tree-ssa/ssa-dom-thread-3.c: Remove check for "one or more
intermediate".
>
> Thanks,
> Andrew Pinski
>
>
>>
>>>
>>> 3) The good thing of Andrew P.'s change is that "Inverse the order of
>>> the basic block walk" so it can do combine recursively.
>>>
>>> But I think we need some heuristic to control the number of ifs. Move
>>> too much compares from
>>> the inner_bb to outer_bb is not good.
>>
>>
>> I think this depends on the target. For MIPS we don't want an upper
>> bound as integer comparisons go directly to GPRs. I wrote this patch
>> with MIPS in mind as that was the target I was working on.
>>
>>>
>>> 4) Another good thing of Andrew P.'s change is that it reuses some
>>> existing functions. So it looks much simple.
>>
>>
>> Thanks,
>> Andrew Pinski
>>
>>>
>
> With that we should be able to kill the fold-const.c transform?
That would certainly be nice and an excellent follow-up for Zhenqiang.
>>>
>>> That's my final goal to "kill the fold-const.c transform". I think we
>>> may combine the two changes to make a "simple" and "good" patch.
>>>
>>> Thanks!
>>> -Zhenqiang
Index: testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c
===
--- testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c(revision 0)
+++ testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c(revision 0)
@@ -0,0 +1,14 @@
+/* { dg-do compile { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-*
powerpc*-*-* xtensa*-*-*"} } } */
+
+/* { dg-options "-O2 -g -fdump-tree-optimized" } */
+/* { dg-additional-options "-mbranch-cost=2" { target avr-*-* } } */
+
+int t (int a, int b)
+{
+ if (a > 0)
[Patch] Regex comments
Add comments for last regex commit.
Thanks!
--
Regards,
Tim Shen
commit b4aa16a08992866ca6fd60f40e422f551d0d6b2a
Author: tim
Date: Sun Oct 27 15:50:44 2013 -0400
2013-
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc b/libstdc++-v3/include/bits/regex_executor.tcc
index d3b9a04..2f677de 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -53,6 +53,52 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
}
+ // This function serves in different modes, DFS mode or BFS mode, indicated
+ // by template variable __dfs_mode. See _M_main for details.
+ //
+ //
+ //
+ // DFS mode:
+ //
+ // It applys a Depth-First-Search (aka backtracking) on given NFA and input
+ // string.
+ // At the very beginning the executor stands in the start state, then it try
+ // every possible state transition in current state recursively. Some state
+ // transitions consume input string, say, a single-char-matcher or a
+ // back-reference matcher; some don't, like assertion or other anchor nodes.
+ // When the input is exhausted and/or the current state is an accepting state,
+ // the whole executor returns true.
+ //
+ // TODO: This approach is exponentially slow for certain input.
+ // Try to compile the NFA to a DFA.
+ //
+ // Time complexity: o(match_length), O(2^(_M_nfa.size()))
+ // Space complexity: \theta(match_results.size() + match_length)
+ //
+ //
+ //
+ // BFS mode:
+ //
+ // Russ Cox's article (http://swtch.com/~rsc/regexp/regexp1.html)
+ // explained this algorithm clearly.
+ //
+ // It first computes epsilon clousure for every state that's still matching,
+ // using the same DFS algorithm, but doesn't reenter states (set true in
+ // _M_visited), nor follow _S_opcode_match.
+ //
+ // Then apply DFS to every _S_opcode_match one by one (in _M_match_queue).
+ //
+ // The order of which states needs to be recursively applied DFS matters,
+ // depend on which greedy mode we use. See _S_opcode_alternative branch in
+ // _M_dfs.
+ //
+ // It significantly reduces potential duplicate states, so have a better
+ // upper bound; but it deserves more overhead.
+ //
+ // Time complexity: o(match_length * match_results.size())
+ // O(match_length * _M_nfa.size() * match_results.size())
+ // Space complexity: o(_M_nfa.size() + match_results.size())
+ // O(_M_nfa.size() * match_results.size())
template
template
@@ -68,18 +114,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
else
{
- // Like the DFS approach, it try every possible state transition;
- // Unlike DFS, it uses a queue instead of a stack to store matching
- // states. It's a BFS approach.
- //
- // Russ Cox's article(http://swtch.com/~rsc/regexp/regexp1.html)
- // explained this algorithm clearly.
- //
- // Time complexity: o(match_length * match_results.size())
- // O(match_length * _M_nfa.size()
- //* match_results.size())
- // Space complexity: o(_M_nfa.size() + match_results.size())
- // O(_M_nfa.size() * match_results.size())
_M_match_queue->push(make_pair(_M_start_state, _M_results));
bool __ret = false;
while (1)
@@ -132,20 +166,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
}
- // A _DFSExecutor perform a DFS on given NFA and input string. At the very
- // beginning the executor stands in the start state, then it try every
- // possible state transition in current state recursively. Some state
- // transitions consume input string, say, a single-char-matcher or a
- // back-reference matcher; some not, like assertion or other anchor nodes.
- // When the input is exhausted and the current state is an accepting state,
- // the whole executor return true.
- //
- // TODO: This approach is exponentially slow for certain input.
- // Try to compile the NFA to a DFA.
- //
- // Time complexity: o(match_length), O(2^(_M_nfa.size()))
- // Space complexity: \theta(match_results.size() + match_length)
- //
template
template
@@ -164,25 +184,39 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
case _S_opcode_alternative:
// Greedy or not, this is a question ;)
+ //
+ // _M_alt branch is "match once more", while _M_next is "get me out
+ // of this quantifier".
+
+ // Greedy.
if (!__state._M_neg)
{
+ // Once more.
_M_dfs<__match_mode>(__state._M_alt);
+ // If it's DFS executor and already accepted, we're done.
if (!__dfs_mode || !_M_has_sol)
_M_dfs<__match_mode>(__state._M_next);
}
- else
+ else // Ungreedy mode
{
if (__dfs_mode)
{
+ // vice-versa.
_M_dfs<__match_mode>(__state._M_next);
if (!_M_has_sol)
_M_dfs<__match_mode>(__state._M_alt);
}
else
Re: [Patch] Regex comments
Hi, On 10/27/2013 09:12 PM, Tim Shen wrote: @@ -190,9 +224,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION } break; case _S_opcode_subexpr_begin: - // Here's the critical part: if there's nothing changed since last - // visit, do NOT continue. This prevents the executor from get into - // infinite loop when use "()*" to match "". + // If there's nothing changed since last visit, do NOT continue. + // This prevents the executor from get into infinite loop when use + // "()*" to match "". // // Every change on _M_cur_results will be roll back after the // recursion step finished. Should we move this comment too before the 'case', and aligned with it? Either way, patch Ok of course. Paolo.
Re: [Patch] Regex comments
On Sun, Oct 27, 2013 at 4:20 PM, Paolo Carlini wrote:
> Should we move this comment too before the 'case', and aligned with it?
Actually this comment is for the if statement below, not the whole
case branch. I've made this clearer by moving "Every change..." part
to the switch statement, where it should stay.
--
Regards,
Tim Shen
commit 1f13761ba34b13a52b4f41d2ebdeba1114205bac
Author: tim
Date: Sun Oct 27 15:50:44 2013 -0400
2013-10-27 Tim Shen
* regex_executor.tcc: Add comments.
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc b/libstdc++-v3/include/bits/regex_executor.tcc
index d3b9a04..c4ce362 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -53,6 +53,52 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
}
+ // This function serves in different modes, DFS mode or BFS mode, indicated
+ // by template variable __dfs_mode. See _M_main for details.
+ //
+ //
+ //
+ // DFS mode:
+ //
+ // It applys a Depth-First-Search (aka backtracking) on given NFA and input
+ // string.
+ // At the very beginning the executor stands in the start state, then it try
+ // every possible state transition in current state recursively. Some state
+ // transitions consume input string, say, a single-char-matcher or a
+ // back-reference matcher; some don't, like assertion or other anchor nodes.
+ // When the input is exhausted and/or the current state is an accepting state,
+ // the whole executor returns true.
+ //
+ // TODO: This approach is exponentially slow for certain input.
+ // Try to compile the NFA to a DFA.
+ //
+ // Time complexity: o(match_length), O(2^(_M_nfa.size()))
+ // Space complexity: \theta(match_results.size() + match_length)
+ //
+ //
+ //
+ // BFS mode:
+ //
+ // Russ Cox's article (http://swtch.com/~rsc/regexp/regexp1.html)
+ // explained this algorithm clearly.
+ //
+ // It first computes epsilon clousure for every state that's still matching,
+ // using the same DFS algorithm, but doesn't reenter states (set true in
+ // _M_visited), nor follow _S_opcode_match.
+ //
+ // Then apply DFS to every _S_opcode_match one by one (in _M_match_queue).
+ //
+ // The order of which states needs to be recursively applied DFS matters,
+ // depend on which greedy mode we use. See _S_opcode_alternative branch in
+ // _M_dfs.
+ //
+ // It significantly reduces potential duplicate states, so have a better
+ // upper bound; but it deserves more overhead.
+ //
+ // Time complexity: o(match_length * match_results.size())
+ // O(match_length * _M_nfa.size() * match_results.size())
+ // Space complexity: o(_M_nfa.size() + match_results.size())
+ // O(_M_nfa.size() * match_results.size())
template
template
@@ -68,18 +114,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
else
{
- // Like the DFS approach, it try every possible state transition;
- // Unlike DFS, it uses a queue instead of a stack to store matching
- // states. It's a BFS approach.
- //
- // Russ Cox's article(http://swtch.com/~rsc/regexp/regexp1.html)
- // explained this algorithm clearly.
- //
- // Time complexity: o(match_length * match_results.size())
- // O(match_length * _M_nfa.size()
- //* match_results.size())
- // Space complexity: o(_M_nfa.size() + match_results.size())
- // O(_M_nfa.size() * match_results.size())
_M_match_queue->push(make_pair(_M_start_state, _M_results));
bool __ret = false;
while (1)
@@ -132,20 +166,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
}
- // A _DFSExecutor perform a DFS on given NFA and input string. At the very
- // beginning the executor stands in the start state, then it try every
- // possible state transition in current state recursively. Some state
- // transitions consume input string, say, a single-char-matcher or a
- // back-reference matcher; some not, like assertion or other anchor nodes.
- // When the input is exhausted and the current state is an accepting state,
- // the whole executor return true.
- //
- // TODO: This approach is exponentially slow for certain input.
- // Try to compile the NFA to a DFA.
- //
- // Time complexity: o(match_length), O(2^(_M_nfa.size()))
- // Space complexity: \theta(match_results.size() + match_length)
- //
template
template
@@ -160,29 +180,45 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
const auto& __state = _M_nfa[__i];
+ // Every change on _M_cur_results and _M_current will be rolled back after
+ // finishing the recursion step.
switch (__state._M_opcode)
{
case _S_opcode_alternative:
// Greedy or not, this is a question ;)
+ //
+ // _M_alt branch is "match once more", while _M_next is
[PATCH, i386]: Testcases for PR 58679 (Was: reverting a LRA change)
Hello! > It seems one my yesterday patch created problems with mode switching: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679 > > I reverted it until further investigation (committed as rev. 204094). Sorry > for inconvenience. > > 2013-10-26 Vladimir Makarov > >Revert: >2013-10-25 Vladimir Makarov >* lra-spills.c (lra_final_code_change): Remove useless move insns. Thanks! I have committed a couple of testcases from the PR, the first was actually fixed by [1], the second is a short testcase that failed without the revert. 2013-10-27 Uros Bizjak PR target/58679 * gcc.target/i386/pr58679-1.c: New test. * gcc.target/i386/pr58679-2.c: Ditto. [1] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01606.html Uros.
Re: [PATCH, i386]: Testcases for PR 58679 (Was: reverting a LRA change)
On Sun, Oct 27, 2013 at 9:39 PM, Uros Bizjak wrote:
> I have committed a couple of testcases from the PR, the first was
> actually fixed by [1], the second is a short testcase that failed
> without the revert.
>
> 2013-10-27 Uros Bizjak
>
> PR target/58679
> * gcc.target/i386/pr58679-1.c: New test.
> * gcc.target/i386/pr58679-2.c: Ditto.
Now with the patch attached.
Uros.
Index: testsuite/gcc.target/i386/pr58679-1.c
===
--- testsuite/gcc.target/i386/pr58679-1.c (revision 0)
+++ testsuite/gcc.target/i386/pr58679-1.c (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx" } */
+
+typedef struct { char a; long long b; } S;
+
+S foo (S x, S y)
+{
+ S z;
+
+ z.a = 0;
+ z.b = x.b / y.b;
+ return z;
+}
Index: testsuite/gcc.target/i386/pr58679-2.c
===
--- testsuite/gcc.target/i386/pr58679-2.c (revision 0)
+++ testsuite/gcc.target/i386/pr58679-2.c (working copy)
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx" } */
+
+int f (long long a, long long b)
+{
+ return (a * b) >> 16;
+}
Re: [Patch] Regex comments
+ // This function serves in different modes, DFS mode or BFS mode, indicated + // by template variable __dfs_mode. See _M_main for details. I think this would make more sense if you replace "serves" with "operates", and __dfs_mode is a template parameter, not a variable. + // It applys a Depth-First-Search (aka backtracking) on given NFA and input + // string. s/applys/applies/ + // At the very beginning the executor stands in the start state, then it try s/try/tries/ + // It first computes epsilon clousure for every state that's still matching, s/clousure/closure/ + // The order of which states needs to be recursively applied DFS matters, + // depend on which greedy mode we use. I don't understand this sentence at all, sorry. Can you explain it in other terms, and I'll try to suggest better phrasing? + // It significantly reduces potential duplicate states, so have a better + // upper bound; but it deserves more overhead. s/have/has/ And should it say "requires" not "deserves"? + else // Ungreedy mode s/Ungreedy/non-greedy/ + // DON't attempt anything, because there's already someone s/DON't/DON'T/ someone? Should it be "something" or "another state" instead? + // has one more time ungreedy quantifier loop. ??? Maybe "requires another iteration of a non-greedy quantifier loop" ? + // This prevents the executor from get into infinite loop when use This should be "... getting into an infinite loop when using ..."
[C, C++, OpenMP] Add support for -fopenmp-simd
This patch add the new option "-fopenmp-simd", which allows to use
OpenMP 4.0's "simd" pragmas without enabling OpenMP's threading or
target features - and, thus, it also doesn't require linking of libgomp.
The purpose is to permit a fine-tuning of vectorization without adding
the additional library dependency and makes it easier to compile a code
to a single-thread program, which additionally uses OpenMP for
thread/target parallelization. Looking at other compilers, also the
Intel compiler has such a flag (-openmp-simd).
The code is written such that when "-fopenmp" is used,
-f(no-)openmp-simd has no effect. The following "simd" pragmas are
listed in OpenMP 4.0 - and will all get translated into "#pragma omp
simd", only, with -fopenmp-simd:
#pragma omp simd
#pragma omp for simd
#pragma omp distribute simd
#pragma omp distribute parallel for simd
#pragma omp parallel for simd
#pragma omp teams distribute simd
#pragma omp target teams distribute simd
#pragma omp teams distribute parallel for simd
#pragma omp target teams distribute parallel for simd
I did an all-language bootstrap, followed by regtesting on x86-64-gnu-linux.
(I did a minor change before sending this patch and will have to repeat it.)
Do you have any comments or suggestions? If not, OK for the trunk?
Tobias
2013-10-27 Tobias Burnus
gcc/
* doc/invoke.texi (-fopenmp-simd): Document new option.
* gimplify.c (gimplify_body): Accept -fopenmp-simd.
* omp-low.c (execute_expand_omp, execute_lower_omp): Ditto.
* tree.c (attribute_value_equal): Ditto.
gcc/fortran/
* lang.opt (fopenmp-simd): New option.
* gfortran.h (gfc_option_t): Add gfc_flag_openmp_simd.
* options.c (gfc_handle_option): Handle it.
gcc/c-family/
* c.opt (fopenmp-simd): New option.
* c-pragma.c (omp_pragmas): Move pragmas which can contain simd to ...
(omp_pragmas): ... this new struct.
(c_pp_lookup_pragma): Also walk omp_pragmas.
(init_pragma): Init pragmas for -fopenmp-simd.
gcc/c
* c-parser.c (c_parser_omp_for, c_parser_omp_parallel,
c_parser_omp_distribute, c_parser_omp_teams,
c_parser_omp_target, c_parser_omp_declare): Handle
-fopenmp-simd.
gcc/cp
* parser.c (cp_parser_omp_for, cp_parser_omp_parallel,
cp_parser_omp_distribute, cp_parser_omp_teams, cp_parser_omp_target,
cp_parser_omp_declare): Handle
-fopenmp-simd.
gcc/testsuite/
* g++.dg/gomp/openmp-simd-1.C: New.
* gcc.dg/gomp/openmp-simd-1.c: New.
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 4b4eb4c..c19c8c6 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -8812,7 +8812,7 @@ gimplify_body (tree fndecl, bool do_parms)
nonlocal_vlas = NULL;
}
- if (flag_openmp && gimplify_omp_ctxp)
+ if ((flag_openmp || flag_openmp_simd) && gimplify_omp_ctxp)
{
delete_omp_context (gimplify_omp_ctxp);
gimplify_omp_ctxp = NULL;
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index a5b9210..7874ff1 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -8232,7 +8232,7 @@ execute_expand_omp (void)
static bool
gate_expand_omp (void)
{
- return (flag_openmp != 0 && !seen_error ());
+ return ((flag_openmp != 0 || flag_openmp_simd != 0) && !seen_error ());
}
namespace {
@@ -10053,7 +10053,7 @@ execute_lower_omp (void)
/* This pass always runs, to provide PROP_gimple_lomp.
But there is nothing to do unless -fopenmp is given. */
- if (flag_openmp == 0)
+ if (flag_openmp == 0 && flag_openmp_simd == 0)
return 0;
all_contexts = splay_tree_new (splay_tree_compare_pointers, 0,
diff --git a/gcc/tree.c b/gcc/tree.c
index 0a42109..e7d197a 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -4701,7 +4701,7 @@ attribute_value_equal (const_tree attr1, const_tree attr2)
return (simple_cst_list_equal (TREE_VALUE (attr1),
TREE_VALUE (attr2)) == 1);
- if (flag_openmp
+ if ((flag_openmp || flag_openmp_simd)
&& TREE_VALUE (attr1) && TREE_VALUE (attr2)
&& TREE_CODE (TREE_VALUE (attr1)) == OMP_CLAUSE
&& TREE_CODE (TREE_VALUE (attr2)) == OMP_CLAUSE)
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 4f79934..f3dd348 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -517,6 +521,10 @@ fopenmp
Fortran
; Documented in C
+fopenmp-simd
+Fortran
+; Documented in C
+
fpack-derived
Fortran
Try to lay out derived types as compactly as possible
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index b28edd8..af5e68c 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2286,6 +2286,7 @@ typedef struct
int flag_cray_pointer;
int flag_d_lines;
int gfc_flag_openmp;
+ int gfc_flag_openmp_simd;
int flag_sign_zero;
int flag_stack_arrays;
int flag_module_private;
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 6e4e7c1..e05528a 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -836,6 +836,10 @@ gfc_handle_option (size_t scode, const char *arg, int value,
gfc_option.gfc_flag_openmp = value;
break;
+case OPT_fopenmp_simd:
+
Re: [SH] Cleanup endianness macros
Oleg Endo wrote: > The attached patch adds a new macro TARGET_BIG_ENDIAN. I think it's a > bit easier to read than !TARGET_LITTLE_ENDIAN. Moreover, some not so > obvious looking uses of TARGET_LITTLE_ENDIAN for selecting MSW and LSW > register offsets are clarified by using new macros SH_REG_MSW_OFFSET and > SH_REG_LSW_OFFSET. > No functional changes. Tested with make all-gcc. > OK for trunk? OK. Regards, kaz
Re: [Patch] Regex comments
Thank you for figuring out so many syntax errors, I'll be careful next time.
On Sun, Oct 27, 2013 at 5:38 PM, Jonathan Wakely wrote:
> + // The order of which states needs to be recursively applied DFS matters,
> + // depend on which greedy mode we use.
>
> I don't understand this sentence at all, sorry. Can you explain it in
> other terms, and I'll try to suggest better phrasing?
+// _M_alt branch is "match once more", while _M_next is "get me out
+// of this quantifier". Executing _M_next first or _M_alt first don't
+// mean the same thing, and we need to choose the correct order under
+// given greedy mode.
--
Regards,
Tim Shen
commit b195603ee8d79d2afd5303bcae363c47e4c89fab
Author: tim
Date: Sun Oct 27 15:50:44 2013 -0400
2013-10-28 Tim Shen
* regex_executor.tcc: Add comments.
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc b/libstdc++-v3/include/bits/regex_executor.tcc
index d3b9a04..0c42189 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -53,6 +53,49 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
}
+ // This function operates in different modes, DFS mode or BFS mode, indicated
+ // by template parameter __dfs_mode. See _M_main for details.
+ //
+ //
+ //
+ // DFS mode:
+ //
+ // It applies a Depth-First-Search (aka backtracking) on given NFA and input
+ // string.
+ // At the very beginning the executor stands in the start state, then it tries
+ // every possible state transition in current state recursively. Some state
+ // transitions consume input string, say, a single-char-matcher or a
+ // back-reference matcher; some don't, like assertion or other anchor nodes.
+ // When the input is exhausted and/or the current state is an accepting state,
+ // the whole executor returns true.
+ //
+ // TODO: This approach is exponentially slow for certain input.
+ // Try to compile the NFA to a DFA.
+ //
+ // Time complexity: o(match_length), O(2^(_M_nfa.size()))
+ // Space complexity: \theta(match_results.size() + match_length)
+ //
+ //
+ //
+ // BFS mode:
+ //
+ // Russ Cox's article (http://swtch.com/~rsc/regexp/regexp1.html)
+ // explained this algorithm clearly.
+ //
+ // It first computes epsilon closure for every state that's still matching,
+ // using the same DFS algorithm, but doesn't reenter states (set true in
+ // _M_visited), nor follows _S_opcode_match.
+ //
+ // Then apply DFS using every _S_opcode_match (in _M_match_queue) as the start
+ // state.
+ //
+ // It significantly reduces potential duplicate states, so has a better
+ // upper bound; but it requires more overhead.
+ //
+ // Time complexity: o(match_length * match_results.size())
+ // O(match_length * _M_nfa.size() * match_results.size())
+ // Space complexity: o(_M_nfa.size() + match_results.size())
+ // O(_M_nfa.size() * match_results.size())
template
template
@@ -68,18 +111,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
else
{
- // Like the DFS approach, it try every possible state transition;
- // Unlike DFS, it uses a queue instead of a stack to store matching
- // states. It's a BFS approach.
- //
- // Russ Cox's article(http://swtch.com/~rsc/regexp/regexp1.html)
- // explained this algorithm clearly.
- //
- // Time complexity: o(match_length * match_results.size())
- // O(match_length * _M_nfa.size()
- //* match_results.size())
- // Space complexity: o(_M_nfa.size() + match_results.size())
- // O(_M_nfa.size() * match_results.size())
_M_match_queue->push(make_pair(_M_start_state, _M_results));
bool __ret = false;
while (1)
@@ -132,20 +163,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
}
- // A _DFSExecutor perform a DFS on given NFA and input string. At the very
- // beginning the executor stands in the start state, then it try every
- // possible state transition in current state recursively. Some state
- // transitions consume input string, say, a single-char-matcher or a
- // back-reference matcher; some not, like assertion or other anchor nodes.
- // When the input is exhausted and the current state is an accepting state,
- // the whole executor return true.
- //
- // TODO: This approach is exponentially slow for certain input.
- // Try to compile the NFA to a DFA.
- //
- // Time complexity: o(match_length), O(2^(_M_nfa.size()))
- // Space complexity: \theta(match_results.size() + match_length)
- //
template
template
@@ -160,29 +177,44 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
const auto& __state = _M_nfa[__i];
+ // Every change on _M_cur_results and _M_current will be rolled back after
+ // finishing the recursion step.
Re: [Patch, C, C++] Accept GCC ivdep for 'do' and 'while', and for C++11's range-based loops
On 10/25/2013 04:46 PM, Tobias Burnus wrote: + do_range_for_auto_deduction (range_decl, range_expr); // FIXME:IVDEP I think in this situation let's set a flag on the RANGE_FOR_STMT so we can do ivdep handling at instantiation time. Jason
Re: Rework c99status.html
Hi Joseph, On Sun, 27 Oct 2013, Joseph S. Myers wrote: > I've committed this patch to rework the page so it starts with a summary > of the overall C99 state, then describes each feature by listing the GCC > version in which it was substantially supported (not necessarily obscure > corner cases), or "N/A" if no compiler support required, with further > notes then directly included in the table where reasonable. Hopefully > this will be less confusing to readers than the previous version. thanks for working on this! > I think it would be appropriate to redirect all the c99status.html files > for particular GCC versions to this file, now it covers all versions. To make sure I understand: you are proposing we remove all individual c99status.html pages and have the web server redirect to the one you just updated for all of those? I'll be happy to make that change once you confirmed. Gerald
Re: [Patch] Regex comments
On 28 October 2013 00:23, Tim Shen wrote: > Thank you for figuring out so many syntax errors, I'll be careful next time. No problem, I'm always happy to help review the grammar, syntax or spelling in documentation improvements. > On Sun, Oct 27, 2013 at 5:38 PM, Jonathan Wakely > wrote: >> + // The order of which states needs to be recursively applied DFS matters, >> + // depend on which greedy mode we use. >> >> I don't understand this sentence at all, sorry. Can you explain it in >> other terms, and I'll try to suggest better phrasing? > > +// _M_alt branch is "match once more", while _M_next is "get me out > +// of this quantifier". Executing _M_next first or _M_alt first don't > +// mean the same thing, and we need to choose the correct order under > +// given greedy mode. OK, that's clear, thanks! I'm happy for that latest patch to be committed, thanks for taking the time to improve the comments.
C++14 digit separators..
Here is an implementation for C++14 digit separators (single quote).
It's still testing on x86_64-linux but I wanted to give folks a chance
to check it out.
Ed
libcpp:
2013-10-28 Edward Smith-Rowland <3dw...@verizon.net>
implement C++14 digit separators.
* include/cpplib.h (cpp_options): Add digit_separators flag.
* internal.h (DIGIT_SEP(c)): New macro.
* expr.c (cpp_classify_number): Check improper placement of digit sep;
(cpp_interpret_integer): Skip over digit separators.
* init.c (lang_flags): Add digit_separators flag; (lang_defaults): Add
digit separator flags per language; (cpp_set_lang): Set
digit_separators
* lex.c (lex_number): Add digits separator to allowable characters for
C++14.
gcc/c-family:
2013-10-28 Edward Smith-Rowland <3dw...@verizon.net>
* c-lex.c (interpret_float): Remove digit separators from scratch string
before building real literal.
gcc/testsuite:
2013-10-28 Edward Smith-Rowland <3dw...@verizon.net>
* g++.dg/cpp1y/digit-sep.C: New.
* g++.dg/cpp1y/digit-sep-neg.C: New.
libstdc++-v3:
2013-10-28 Edward Smith-Rowland <3dw...@verizon.net>
implement C++14 digit separators.
* include/include/bits/parse_numbers.h: Change struct _Digit<_Base, '`'>
to struct _Digit<_Base, '\''>.
Index: libcpp/include/cpplib.h
===
--- libcpp/include/cpplib.h (revision 204043)
+++ libcpp/include/cpplib.h (working copy)
@@ -437,6 +437,9 @@
/* Nonzero for C++ 2014 Standard binary constants. */
unsigned char binary_constants;
+ /* Nonzero for C++ 2014 Standard digit separators. */
+ unsigned char digit_separators;
+
/* Holds the name of the target (execution) character set. */
const char *narrow_charset;
Index: libcpp/internal.h
===
--- libcpp/internal.h (revision 204043)
+++ libcpp/internal.h (working copy)
@@ -59,6 +59,8 @@
|| (((prevc) == 'p' || (prevc) == 'P') \
&& CPP_OPTION (pfile, extended_numbers
+#define DIGIT_SEP(c) ((c) == '\'' && CPP_OPTION (pfile, digit_separators))
+
#define CPP_OPTION(PFILE, OPTION) ((PFILE)->opts.OPTION)
#define CPP_BUFFER(PFILE) ((PFILE)->buffer)
#define CPP_BUF_COLUMN(BUF, CUR) ((CUR) - (BUF)->line_base)
Index: libcpp/expr.c
===
--- libcpp/expr.c (revision 204043)
+++ libcpp/expr.c (working copy)
@@ -394,6 +394,7 @@
unsigned int max_digit, result, radix;
enum {NOT_FLOAT = 0, AFTER_POINT, AFTER_EXPON} float_flag;
bool seen_digit;
+ bool seen_digit_sep;
if (ud_suffix)
*ud_suffix = NULL;
@@ -408,6 +409,7 @@
max_digit = 0;
radix = 10;
seen_digit = false;
+ seen_digit_sep = false;
/* First, interpret the radix. */
if (*str == '0')
@@ -436,13 +438,24 @@
if (ISDIGIT (c) || (ISXDIGIT (c) && radix == 16))
{
+ seen_digit_sep = false;
seen_digit = true;
c = hex_value (c);
if (c > max_digit)
max_digit = c;
}
+ else if (DIGIT_SEP (c))
+ {
+ if (seen_digit_sep)
+ SYNTAX_ERROR_AT (virtual_location, "adjacent digit separators");
+ seen_digit_sep = true;
+ }
else if (c == '.')
{
+ if (seen_digit_sep)
+ SYNTAX_ERROR_AT (virtual_location,
+"digit separator adjacent to decimal point");
+ seen_digit_sep = false;
if (float_flag == NOT_FLOAT)
float_flag = AFTER_POINT;
else
@@ -452,6 +465,10 @@
else if ((radix <= 10 && (c == 'e' || c == 'E'))
|| (radix == 16 && (c == 'p' || c == 'P')))
{
+ if (seen_digit_sep)
+ SYNTAX_ERROR_AT (virtual_location,
+"digit separator adjacent to exponent");
+ seen_digit_sep = false;
float_flag = AFTER_EXPON;
break;
}
@@ -463,6 +480,10 @@
}
}
+ if (DIGIT_SEP (*str))
+SYNTAX_ERROR_AT (virtual_location,
+"digit separator outside digit sequence");
+
/* The suffix may be for decimal fixed-point constants without exponent. */
if (radix != 16 && float_flag == NOT_FLOAT)
{
@@ -520,8 +541,13 @@
/* Exponent is decimal, even if string is a hex float. */
if (!ISDIGIT (*str))
- SYNTAX_ERROR_AT (virtual_location, "exponent has no digits");
-
+ {
+ if (DIGIT_SEP (*str))
+ SYNTAX_ERROR_AT (virtual_location,
+"digit separator adjacent to exponent");
+ else
+ SYNTAX_ERROR_AT (virtual_location, "exponent has no digits");
+ }
do
str++;
while (ISDIGIT (*str));
@@ -530,6 +556,10 @@
SYNTAX
Re: [PATCH]Fix computation of offset in ivopt
On Mon, Oct 21, 2013 at 8:21 PM, Richard Biener wrote: > On Fri, Oct 18, 2013 at 5:48 PM, Bin.Cheng wrote: >> Hi Richard, >> Is the first patch OK? Since there is a patch depending on it. >> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01931.html > > Yes. I committed the patch fixing strip_offset_1 as r204116. Since the root cause of the second issue is POINTER_PLUS_EXPR requires an unsigned offset operand and can't be fixed as in the second patch, I will discard that patch. Thanks. bin >> On Fri, Oct 18, 2013 at 7:18 PM, Richard Biener >> wrote: >>> On Thu, Oct 17, 2013 at 7:52 AM, bin.cheng wrote: Hi, As noted in previous messages, GCC forces offset to unsigned in middle end. It also gets offset value and stores it in HOST_WIDE_INT then uses it in various computation. In this scenario, It should use int_cst_value to do additional sign extension against the type of tree node, otherwise we might lose sign information. Take function fold_plusminus_mult_expr as an example, the sign information of arg01/arg11 might be lost because it uses TREE_INT_CST_LOW directly. I think this is the offender of the problem in this thread. I think we should fix the offender, rather the hacking strip_offset as in the original patch, so I split original patch into two as attached, with one fixing the offset of COMPONENT_REF in strip_offset_1, the other fixing the mentioned sign extension problem. >>> >>> Index: gcc/fold-const.c >>> === >>> --- gcc/fold-const.c (revision 203267) >>> +++ gcc/fold-const.c (working copy) >>> @@ -7270,8 +7270,8 @@ fold_plusminus_mult_expr (location_t loc, enum tre >>>HOST_WIDE_INT int01, int11, tmp; >>>bool swap = false; >>>tree maybe_same; >>> - int01 = TREE_INT_CST_LOW (arg01); >>> - int11 = TREE_INT_CST_LOW (arg11); >>> + int01 = int_cst_value (arg01); >>> + int11 = int_cst_value (arg11); >>> >>> this is not correct - it will mishandle all large unsigned numbers. >>> >>> The real issue is that we rely on twos-complement arithmetic to work >>> when operating on pointer offsets (because we convert them all to >>> unsigned sizetype). That makes interpreting the offsets or expressions >>> that compute offsets hard (or impossible in some cases), as you can >>> see from the issues in IVOPTs. >>> >>> The above means that strip_offset_1 cannot reliably look through >>> MULT_EXPRs as that can make an offset X * CST that is >>> "effectively" signed "surely" unsigned in the process. Think of >>> this looking into X * CST as performing a division - whose result >>> is dependent on the sign of X which we lost with our unsigned >>> casting. Now, removing the MULT_EXPR look-through might >>> be too pessimizing ... but it may be worth trying to see if it fixes >>> your issue? In this context I also remember a new bug filed >>> recently of us not folding x /[ex] 4 * 4 to x. >>> >>> In the past I was working multiple times on stopping doing that >>> (make all offsets unsigned), but I never managed to finish ... >>> >>> Richard. >>> Bootstrap and test on x86/x86_64/arm. Is it OK? Thanks. bin Patch a: 2013-10-17 Bin Cheng * tree-ssa-loop-ivopts.c (strip_offset_1): Change parameter type. Count DECL_FIELD_BIT_OFFSET when computing offset for COMPONENT_REF. Patch b: 2013-10-17 Bin Cheng * fold-const.c (fold_plusminus_mult_expr): Use int_cst_value instead of TREE_INT_CST_LOW. gcc/testsuite/ChangeLog 2013-10-17 Bin Cheng * gcc.dg/tree-ssa/ivopts-outside-loop-use-1.c: New test. > -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Wednesday, October 02, 2013 4:32 PM > To: Bin.Cheng > Cc: Bin Cheng; GCC Patches > Subject: Re: [PATCH]Fix computation of offset in ivopt > > On Tue, Oct 1, 2013 at 6:13 PM, Bin.Cheng wrote: > > On Tue, Oct 1, 2013 at 6:50 PM, Richard Biener > > wrote: > >> On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng > wrote: > >>> > >>> > >> > >> I don't think you need > >> > >> + /* Sign extend off if expr is in type which has lower precision > >> + than HOST_WIDE_INT. */ > >> + if (TYPE_PRECISION (TREE_TYPE (expr)) <= HOST_BITS_PER_WIDE_INT) > >> +off = sext_hwi (off, TYPE_PRECISION (TREE_TYPE (expr))); > >> > >> at least it would be suspicious if you did ... > > There is a problem for example of the first message. The iv base if like: > > pretmp_184 + ((sizetype) KeyIndex_180 + 1073741823) * 4 I am not sure > > why but it seems (-4/0xFFFC) is represented by (1073741823*4). > > For each operand strip_offset_1 returns exactly the positive number > > and result of multiplicati
Re: [Patch] Regex comments
On Sun, Oct 27, 2013 at 9:26 PM, Jonathan Wakely wrote: > I'm happy for that latest patch to be committed, thanks for taking the > time to improve the comments. Committed. Thanks! -- Regards, Tim Shen
