Re: [fortran,patch] Fix Cray pointers in modules
Dear Francois-Xavier, The patch and the logic behind it, including the name dependence, is fine. OK for trunk and, I suggest, 4.9 and 4.8 after a suitable delay. Thanks! Paul On 8 June 2014 18:40, FX fxcoud...@gmail.com wrote: The attached one-line patch fixes PR45187 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45187), where we would sometimes try to create the backend_decl of Cray-pointees twice. We should simply bail out early of the procedure, following what is done in the similar situation in gfc_finish_var_decl(). Bootstrapped and regtested on x86_64-apple-darwin13, includes a testcase. OK to commit? FX -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
[Ping ^ 2] [PATCH] Fix PR 61225
Ping ^2?
Thanks!
-Zhenqiang
On 28 May 2014 15:02, Zhenqiang Chen zhenqiang.c...@linaro.org wrote:
Ping?
Thanks!
-Zhenqiang
On 22 May 2014 17:52, Zhenqiang Chen zhenqiang.c...@linaro.org wrote:
On 21 May 2014 20:43, Steven Bosscher stevenb@gmail.com wrote:
On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
Hi,
The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
test case tends to check a peephole2 optimization, which optimizes the
following sequence
2: bx:SI=ax:SI
25: ax:SI=[bx:SI]
7: {ax:SI=ax:SI-0x1;clobber flags:CC;}
8: [bx:SI]=ax:SI
9: flags:CCZ=cmp(ax:SI,0)
to
2: bx:SI=ax:SI
41: {flags:CCZ=cmp([bx:SI]-0x1,0);[bx:SI]=[bx:SI]-0x1;}
The enhanced shrink-wrapping, which calls copyprop_hardreg_forward
changes the INSN 25 to
25: ax:SI=[ax:SI]
Then peephole2 can not optimize it since two memory_operands look like
different.
To fix it, the patch adds another peephole2 rule to read one more
insn. From the register copy, it knows the address is the same.
That is one complex peephole2 to deal with a transformation like this.
It seems to be like it's a too specific solution for a bigger problem.
Could you please try one of the following solutions instead:
1. Track register values for peephole2 and try different alternatives
based on known register equivalences? E.g. in your example, perhaps
there is already a REG_EQUAL/REG_EQUIV note available on insn 25 after
copyprop_hardreg_forward, to annotate that [ax:SI] is equivalent to
[bx:SI] at that point (or if that information is not available, it is
not very difficult to make it available). Then you could try applying
peephole2 on the original pattern but also on patterns modified with
the known equivalences (i.e. try peephole2 on multiple equivalent
patterns for the same insn). This may expose other peephole2
opportunities, not just the specific one your patch addresses.
Patch is updated according to the comment. There is no REG_EQUAL. So I
add it when replace_oldest_value_reg.
ChangeLog:
2014-05-22 Zhenqiang Chen zhenqiang.c...@linaro.org
Part of PR rtl-optimization/61225
* config/i386/i386-protos.h (ix86_peephole2_rtx_equal_p): New proto.
* config/i386/i386.c (ix86_peephole2_rtx_equal_p): New function.
* regcprop.c (replace_oldest_value_reg): Add REG_EQUAL note when
propagating to SET.
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 39462bd..0c4a2b9 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -42,6 +42,7 @@ extern enum calling_abi ix86_function_type_abi
(const_tree);
extern void ix86_reset_previous_fndecl (void);
+extern bool ix86_peephole2_rtx_equal_p (rtx, rtx, rtx, rtx);
#ifdef RTX_CODE
extern int standard_80387_constant_p (rtx);
extern const char *standard_80387_constant_opcode (rtx);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6ffb788..583ebe8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -46856,6 +46856,29 @@ ix86_atomic_assign_expand_fenv (tree *hold,
tree *clear, tree *update)
atomic_feraiseexcept_call);
}
+/* OP0 is the SET_DEST of INSN and OP1 is the SET_SRC of INSN.
+ Check whether OP1 and OP6 is equal. */
+
+bool
+ix86_peephole2_rtx_equal_p (rtx insn, rtx op0, rtx op1, rtx op6)
+{
+ rtx note;
+
+ if (!reg_overlap_mentioned_p (op0, op1) rtx_equal_p (op1, op6))
+return true;
+
+ gcc_assert (single_set (insn)
+ op0 == SET_DEST (single_set (insn))
+ op1 == SET_SRC (single_set (insn)));
+
+ note = find_reg_note (insn, REG_EQUAL, NULL_RTX);
+ if (note
+ !reg_overlap_mentioned_p (op0, XEXP (note, 0))
+ rtx_equal_p (XEXP (note, 0), op6))
+return true;
+
+ return false;
+}
/* Initialize the GCC target structure. */
#undef TARGET_RETURN_IN_MEMORY
#define TARGET_RETURN_IN_MEMORY ix86_return_in_memory
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 44e80ec..b57fc86 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -16996,11 +16996,12 @@
[(match_dup 0)
(match_operand:SWI 2 nonmemory_operand)]))
(clobber (reg:CC FLAGS_REG))])
- (set (match_dup 1) (match_dup 0))
+ (set (match_operand:SWI 6 memory_operand) (match_dup 0))
(set (reg FLAGS_REG) (compare (match_dup 0) (const_int 0)))]
(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
peep2_reg_dead_p (4, operands[0])
-!reg_overlap_mentioned_p (operands[0], operands[1])
+ix86_peephole2_rtx_equal_p (peep2_next_insn (0), operands[0],
+ operands[1], operands[6])
!reg_overlap_mentioned_p (operands[0], operands[2])
(MODEmode != QImode
|| immediate_operand (operands[2], QImode)
diff --git a/gcc/regcprop.c b/gcc/regcprop.c
index
Re: [PATCH] Trust TREE_ADDRESSABLE
It is my fault here - I alwasy interpreted TREE_ADDRESSABLE this way and it seems to work for C/C++ that are the frontends I usually look into. But that's not true, see the obvious C testcase I attached in this thread! -- Eric Botcazou
Re: [PATCH] Add support for OpenMP fortran user defined reductions
On Sat, Jun 07, 2014 at 10:25:23AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com writes:
I thought complex(kind=16) is normal double _Complex, isn't it?
No, that would be complex(kind=8).
Ah, I've mixed that with complex*16, which apparently is the
same thing as complex(kind=8).
Fixed thusly, committed as obvious:
2014-06-09 Jakub Jelinek ja...@redhat.com
* gfortran.dg/gomp/udr6.f90 (f1, f2, f3): Use complex(kind=8)
instead of complex(kind=16).
--- gcc/testsuite/gfortran.dg/gomp/udr6.f90.jj 2014-06-06 09:20:49.0
+0200
+++ gcc/testsuite/gfortran.dg/gomp/udr6.f90 2014-06-09 11:09:19.770485330
+0200
@@ -14,7 +14,7 @@ subroutine f1
!$omp declare reduction (+:integer(kind=8),integer(kind=1) ! { dg-error
Redefinition of predefined }
!$omp :omp_out = omp_out + omp_in)
!$omp declare reduction (+:complex:omp_out = omp_out + omp_in) ! { dg-error
Redefinition of predefined }
-!$omp declare reduction (+:complex(kind=16):omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (+:complex(kind=8):omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
interface operator(+)
function addf1 (x, y)
use udr6, only : dt
@@ -38,7 +38,7 @@ subroutine f2
!$omp declare reduction (-:integer(kind=8),integer(kind=1) ! { dg-error
Redefinition of predefined }
!$omp :omp_out = omp_out + omp_in)
!$omp declare reduction (-:complex:omp_out = omp_out + omp_in) ! { dg-error
Redefinition of predefined }
-!$omp declare reduction (-:complex(kind=16):omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (-:complex(kind=8):omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
end subroutine f2
subroutine f3
use udr6, only : dt
@@ -55,7 +55,7 @@ subroutine f3
!$omp declare reduction (*:integer(kind=8),integer(kind=1) ! { dg-error
Redefinition of predefined }
!$omp :omp_out = omp_out * omp_in)
!$omp declare reduction (*:complex:omp_out = omp_out * omp_in) ! { dg-error
Redefinition of predefined }
-!$omp declare reduction (*:complex(kind=16):omp_out = omp_out * omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (*:complex(kind=8):omp_out = omp_out * omp_in) ! {
dg-error Redefinition of predefined }
end subroutine f3
subroutine f4
use udr6, only : dt
Jakub
Re: [PATCH] Trust TREE_ADDRESSABLE
It is my fault here - I alwasy interpreted TREE_ADDRESSABLE this way and it seems to work for C/C++ that are the frontends I usually look into. But that's not true, see the obvious C testcase I attached in this thread! You are right - I never noticed the difference in cases I looked at. I wonder if we want toupdate the frontends to set addressable flag with new sense or we want symtab to simple set addressable on all global symbols or invent a new flag. I would preffer the first case - it seems to make most sense to me. Honza -- Eric Botcazou
Re: [PATCH] Trust TREE_ADDRESSABLE
I wonder if we want toupdate the frontends to set addressable flag with new sense or we want symtab to simple set addressable on all global symbols or invent a new flag. I would preffer the first case - it seems to make most sense to me. I think you need to explain why this change is desirable/necessary for LTO, this would be a good starting point. As for setting TREE_ADDRESSABLE on every single global symbol in every single front-end, why not, but this seems more complicated than treating global symbols as so by default (in non-LTO mode). -- Eric Botcazou
Patch, fortran] PR61406 - [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression
Dear All,
This was a slip up on my part. The fix is obvious - OK for trunk and 4.9?
Cheers
Paul
2014-06-09 Paul Thomas pa...@gcc.gnu.org
PR fortran/61406
* trans-stmt.c (trans_associate_var): Check that array
constructors are constant for direct reference.
2014-06-09 Paul Thomas pa...@gcc.gnu.org
PR fortran/61406
* gfortran.dg/associate_17.f90 : New test
Index: gcc/fortran/trans-stmt.c
===
*** gcc/fortran/trans-stmt.c(revision 211365)
--- gcc/fortran/trans-stmt.c(working copy)
*** trans_associate_var (gfc_symbol *sym, gf
*** 1167,1179
{
gfc_se se;
tree desc;
desc = sym-backend_decl;
/* If association is to an expression, evaluate it and create temporary.
Otherwise, get descriptor of target for pointer assignment. */
gfc_init_se (se, NULL);
! if (sym-assoc-variable || e-expr_type == EXPR_ARRAY)
{
se.direct_byref = 1;
se.use_offset = 1;
--- 1167,1182
{
gfc_se se;
tree desc;
+ bool cst_array_ctor;
desc = sym-backend_decl;
+ cst_array_ctor = e-expr_type == EXPR_ARRAY
+ gfc_constant_array_constructor_p (e-value.constructor);
/* If association is to an expression, evaluate it and create temporary.
Otherwise, get descriptor of target for pointer assignment. */
gfc_init_se (se, NULL);
! if (sym-assoc-variable || cst_array_ctor)
{
se.direct_byref = 1;
se.use_offset = 1;
*** trans_associate_var (gfc_symbol *sym, gf
*** 1184,1190
/* If we didn't already do the pointer assignment, set associate-name
descriptor to the one generated for the temporary. */
! if (!sym-assoc-variable e-expr_type != EXPR_ARRAY)
{
int dim;
--- 1187,1193
/* If we didn't already do the pointer assignment, set associate-name
descriptor to the one generated for the temporary. */
! if (!sym-assoc-variable !cst_array_ctor)
{
int dim;
Index: gcc/testsuite/gfortran.dg/associate_17.f90
===
*** gcc/testsuite/gfortran.dg/associate_17.f90 (revision 0)
--- gcc/testsuite/gfortran.dg/associate_17.f90 (working copy)
***
*** 0
--- 1,12
+ ! { dg-do run }
+ ! Test the fix for PR61406
+ ! Contributed by Adam Hirst a...@aphirst.karoo.co.uk
+ program test
+ implicit none
+ real :: theta = 1.0
+
+ associate (n = [cos(theta), sin(theta)])
+ if (abs (norm2(n) - 1.0) .gt. 1.0e-4) call abort
+ end associate
+
+ end program test
Re: [Patch, fortran] PR61406 - [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression
Dear Paul, This was a slip up on my part. The fix is obvious - OK for trunk and 4.9? The patch fixes the ICE. Any progress about the double temporary? [Book15] f90/bug% gfc pr61406.f90 -Warray-temporaries pr61406.f90:6.18: associate (n = [cos(theta), sin(theta)]) 1 Warning: Creating array temporary at (1) pr61406.f90:6.18: associate (n = [cos(theta), sin(theta)]) 1 Warning: Creating array temporary at (1) Thanks for the patch. Dominique
[PATCH][ARM][doc] Improve description of AArch32 CRC32 intrinsics
Hi all,
The ACLE intrinsics documentation for arm can be improved a bit.
Since there are potentially other ACLE intrinsics besides the CRC32 ones
in the future, I moved the comment about their availability into the
CRC32 intrinsics subsection.
I removed the comment about the instruction form expected for AArch64
since that is a separate port and should be documented in the AArch64
section.
Tested by building the PDF doc and looking at it.
I think this should go for 4.9 as well as trunk as it is a clarification.
Ok?
Thanks,
Kyrill
2014-06-09 Kyrylo Tkachov kyrylo.tkac...@arm.com
* doc/arm-acle-intrinsics.texi: Specify when CRC32 intrinsics are
available.
Simplify description of __crc32d and __crc32cd intrinsics.
* doc/extend.texi (ARM ACLE Intrinsics): Remove comment about CRC32
availability.diff --git a/gcc/doc/arm-acle-intrinsics.texi b/gcc/doc/arm-acle-intrinsics.texi
index e68f4cd..8c5523e 100644
--- a/gcc/doc/arm-acle-intrinsics.texi
+++ b/gcc/doc/arm-acle-intrinsics.texi
@@ -4,6 +4,10 @@
@subsubsection CRC32 intrinsics
+These intrinsics are available when the CRC32 architecture extension is
+specified, e.g. when the @option{-march=armv8-a+crc} switch is used, or when
+the target processor specified with @option{-mcpu} supports it.
+
@itemize @bullet
@item uint32_t __crc32b (uint32_t, uint8_t)
@*@emph{Form of expected instruction(s):} @code{crc32b @var{r0}, @var{r0}, @var{r0}}
@@ -25,8 +29,7 @@
@itemize @bullet
@item uint32_t __crc32d (uint32_t, uint64_t)
@*@emph{Form of expected instruction(s):} Two @code{crc32w @var{r0}, @var{r0}, @var{r0}}
-instructions for AArch32. One @code{crc32w @var{w0}, @var{w0}, @var{x0}} instruction for
-AArch64.
+instructions.
@end itemize
@itemize @bullet
@@ -50,6 +53,5 @@ AArch64.
@itemize @bullet
@item uint32_t __crc32cd (uint32_t, uint64_t)
@*@emph{Form of expected instruction(s):} Two @code{crc32cw @var{r0}, @var{r0}, @var{r0}}
-instructions for AArch32. One @code{crc32cw @var{w0}, @var{w0}, @var{x0}} instruction for
-AArch64.
+instructions.
@end itemize
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index a2fe619..a68020a 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10519,9 +10519,6 @@ when the @option{-mfpu=neon} switch is used:
@node ARM ACLE Intrinsics
@subsection ARM ACLE Intrinsics
-These built-in intrinsics for the ARMv8-A CRC32 extension are available when
-the @option{-march=armv8-a+crc} switch is used:
-
@include arm-acle-intrinsics.texi
@node AVR Built-in Functions
Re: [PATCH ARM] PR/61062 Fix arm_neon.h ZIP/UZP/TRN for bigendian
Baking on trunk as of rev 211369.
--Alan
Ramana Radhakrishnan wrote:
On Wed, May 14, 2014 at 2:52 PM, Alan Lawrence alan.lawre...@arm.com wrote:
Hi,
Due to differences in how the ARM C Language Extensions and gcc's vector
extensions deal with indices within vectors, the __builtin_shuffle masks
used to implement the ZIP, UZP and TRN Neon Intrinsics in arm_neon.h are
correct only for little-endian. (The problem on bigendian has recently been
revealed by new tests in gcc.target/arm/simd/.)
This patch corrects the indices using #ifdef __ARM_BIG_ENDIAN through
arm_neon.h. I've tested all the arm-specific tests (arm.exp acle.exp
aapcs.exp simd.exp neon.exp) on both arm-none-eabi and armeb-none-eabi and
there are no regressions, and on armeb-none-eabi this patch fixes FAIL -
PASS for simd/v{uzp,zip,trn}*_1.c.
Note the patch also modifies gcc.target/arm/pr48252.c. A bit of diving into
the history of this test reveals
*the test was first written in the days when the arm_neon.h
implementation used builtins such as __builtin_neon_vzipv8qi (which were
thus correct for bigendian).
*In SVN rev 189294, ZIP intrinsics were rewritten to use
__builtin_shuffle (with little-endian masks); this broke pr48252.c on
bigendian, but this was not detected until...
*In SVN rev 191200, in which pr48252.c was modified to expect different
results according to endianness - that is, fixing the test to match the
broken implementation. (I have verified that this updated test failed on the
original __builtin_neon_vzipv8qi implementation.)
Thanks for fixing this up - This patch is ok. Please apply to trunk
and backport to 4.9 after letting it bake on trunk for a few days.
I suspect 4.8 is also afflicted from a quick look - can you please
double check and then apply.
If this goes in we need to kill the ml for 4.8 and 4.9 now.
regards
Ramana
The fix to pr48252.c here largely reverts to the original form although
keeps the (correct, proper) use of vld1.
gcc/ChangeLog:
* config/arm/arm_neon.h (vtrn_s8, vtrn_s16, vtrn_u8, vtrn_u16,
vtrn_p8,
vtrn_p16, vtrn_s32, vtrn_f32, vtrn_u32, vtrnq_s8, vtrnq_s16,
vtrnq_s32,
vtrnq_f32, vtrnq_u8, vtrnq_u16, vtrnq_u32, vtrnq_p8, vtrnq_p16,
vzip_s8,
vzip_s16, vzip_u8, vzip_u16, vzip_p8, vzip_p16, vzip_s32, vzip_f32,
vzip_u32, vzipq_s8, vzipq_s16, vzipq_s32, vzipq_f32, vzipq_u8,
vzipq_u16, vzipq_u32, vzipq_p8, vzipq_p16, vuzp_s8, vuzp_s16,
vuzp_s32,
vuzp_f32, vuzp_u8, vuzp_u16, vuzp_u32, vuzp_p8, vuzp_p16, vuzpq_s8,
vuzpq_s16, vuzpq_s32, vuzpq_f32, vuzpq_u8, vuzpq_u16, vuzpq_u32,
vuzpq_p8, vuzpq_p16): Correct mask for bigendian.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr48252.c (main): Expect same result as
endian-neutral.
Cheers, Alan
Re: [PATCH, x86] Improves x86 permutation expand
Right now we need to cover permutations coming from 3 loads/stores
group. My case covers them. I agree that another order of pblend and
pshufb covers additional cases. Good point. We can cover this in a
separate patch.
Asserts are ok if we exclude AVX2 in ISA checks.
Is the following patch ok?
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8827256..1fe2398 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -43185,6 +43185,90 @@ expand_vec_perm_palignr (struct expand_vec_perm_d *d)
return ok;
}
+/* A subroutine of ix86_expand_vec_perm_const_1. Try to simplify
+ the permutation using the SSE4_1 pblendv instruction. Potentially
+ reduces permutaion from 2 pshufb and or to 1 pshufb and pblendv. */
+
+static bool
+expand_vec_perm_pblendv (struct expand_vec_perm_d *d)
+{
+ unsigned i, which, nelt = d-nelt;
+ struct expand_vec_perm_d dcopy, dcopy1;
+ enum machine_mode vmode = d-vmode;
+ bool ok;
+
+ /* Use the same checks as in expand_vec_perm_blend, but skipping
+ AVX2 as it requires more than 2 instructions for general case. */
+ if (d-one_operand_p)
+return false;
+ if (TARGET_AVX (vmode == V4DFmode || vmode == V8SFmode))
+;
+ else if (TARGET_SSE4_1 GET_MODE_SIZE (vmode) == 16)
+;
+ else
+return false;
+
+ /* Figure out where permutation elements stay not in their
+ respective lanes. */
+ for (i = 0, which = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (e != i)
+ which |= (e nelt ? 1 : 2);
+}
+ /* We can pblend the part where elements stay not in their
+ respective lanes only when these elements are all in one
+ half of a permutation.
+ {0 1 8 3 4 5 9 7} is ok as 8, 9 are at not at their respective
+ lanes, but both 8 and 9 = 8
+ {0 1 8 3 4 5 2 7} is not ok as 2 and 8 are not at their
+ respective lanes and 8 = 8, but 2 not. */
+ if (which != 1 which != 2)
+return false;
+ if (d-testing_p)
+return true;
+
+ /* First we apply one operand permutation to the part where
+ elements stay not in their respective lanes. */
+ dcopy = *d;
+ if (which == 2)
+dcopy.op0 = dcopy.op1 = d-op1;
+ else
+dcopy.op0 = dcopy.op1 = d-op0;
+ dcopy.one_operand_p = true;
+
+ for (i = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (which == 2)
+ dcopy.perm[i] = ((e = nelt) ? (e - nelt) : e);
+}
+
+ ok = expand_vec_perm_1 (dcopy);
+ gcc_assert (ok);
+
+ /* Next we put permuted elements into thier positions. */
+ dcopy1 = *d;
+ if (which == 2)
+dcopy1.op1 = dcopy.target;
+ else
+dcopy1.op0 = dcopy.target;
+
+ for (i = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (which == 2)
+ dcopy1.perm[i] = ((e = nelt) ? (nelt + i) : e);
+ else
+ dcopy1.perm[i] = ((e nelt) ? i : e);
+}
+
+ ok = expand_vec_perm_blend (dcopy1);
+ gcc_assert (ok);
+
+ return true;
+}
+
static bool expand_vec_perm_interleave3 (struct expand_vec_perm_d *d);
/* A subroutine of ix86_expand_vec_perm_builtin_1. Try to simplify
@@ -44557,6 +44641,9 @@ ix86_expand_vec_perm_const_1 (struct
expand_vec_perm_d *d)
if (expand_vec_perm_vperm2f128 (d))
return true;
+ if (expand_vec_perm_pblendv (d))
+return true;
+
/* Try sequences of three instructions. */
if (expand_vec_perm_2vperm2f128_vshuf (d))
On Thu, Jun 5, 2014 at 8:49 PM, Richard Henderson r...@redhat.com wrote:
On 06/05/2014 08:29 AM, Evgeny Stupachenko wrote:
+ /* Figure out where permutation elements stay not in their
+ respective lanes. */
+ for (i = 0, which = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (e != i)
+ which |= (e nelt ? 1 : 2);
+}
+ /* We can pblend the part where elements stay not in their
+ respective lanes only when these elements are all in one
+ half of a permutation.
+ {0 1 8 3 4 5 9 7} is ok as 8, 9 are not at their respective
+ lanes, but both 8 and 9 = 8
+ {0 1 8 3 4 5 2 7} is not ok as 2 and 8 are not at their
+ respective lanes and 8 = 8, but 2 not. */
+ if (which != 1 which != 2)
+return false;
I was about to suggest that you'd get more success by putting the blend first,
and do the shuffle second. But I suppose it does cover a few cases that the
other way would miss, e.g.
{ 0 4 7 3 }
because we can't blend 0 and 4 (or 3 and 7) into the same vector. Whereas the
direction you're trying can't handle
{ 0 6 6 1 }
But that can be implemented with
{ 0 1 2 3 }
{ 4 5 6 7 }
---
{ 0 1 6 3 } (pblend)
---
{ 0 6 6 1 } (pshufb)
So I guess we should cover these two cases in successive patches.
+ if (!expand_vec_perm_blend (dcopy1))
+return false;
+
+ return true;
You should avoid doing any work in this function if the ISA isn't enabled.
Don't wait until the last test for blend to fail. Separate that out from the
start of expand_vec_perm_blend as a subroutine,
[C PATCH] Use inform for near initialization for (PR c/36446)
It seems that (near initialization for ) message should be a note:
message rather than error/warning. This patch changes error_at/warning
calls to inform and fixes the testsuite fallout.
Tested x86_64-unknown-linux-gnu, ok for trunk?
2014-06-09 Marek Polacek pola...@redhat.com
PR c/36446
* c-typeck.c (error_init): Call inform instead of error_at.
(pedwarn_init): Call inform instead of pedwarn.
(warning_init): Call inform instead of warning_at.
* gcc.dg/Wcxx-compat-6.c: Change dg-warning to dg-message.
* gcc.dg/array-2.c: Likewise.
* gcc.dg/array-const-2.c: Likewise.
* gcc.dg/ucnid-8.c: Likewise.
* gcc.dg/vla-init-1.c: Likewise.
* gcc.dg/array-const-3.c: Change dg-error to dg-message.
* gcc.dg/c99-flex-array-7.c: Likewise.
* gcc.dg/init-bad-1.c: Likewise.
* gcc.dg/init-bad-3.c: Likewise.
* gcc.dg/init-bad-2.c: Change dg-error and dg-warning to dg-message.
* gcc.dg/pedwarn-init.c: Add dg-warning.
* gcc.dg/pr53119.c: Remove dg-excess-errors.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index e4fa0c3..63bd65e 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -5567,7 +5567,7 @@ error_init (location_t loc, const char *gmsgid)
error_at (loc, gmsgid);
ofwhat = print_spelling ((char *) alloca (spelling_length () + 1));
if (*ofwhat)
-error_at (loc, (near initialization for %qs), ofwhat);
+inform (loc, (near initialization for %qs), ofwhat);
}
/* Issue a pedantic warning for a bad initializer component. OPT is
@@ -5579,12 +5579,13 @@ static void
pedwarn_init (location_t location, int opt, const char *gmsgid)
{
char *ofwhat;
+ bool warned;
/* The gmsgid may be a format string with % and %. */
- pedwarn (location, opt, gmsgid);
+ warned = pedwarn (location, opt, gmsgid);
ofwhat = print_spelling ((char *) alloca (spelling_length () + 1));
- if (*ofwhat)
-pedwarn (location, opt, (near initialization for %qs), ofwhat);
+ if (*ofwhat warned)
+inform (location, (near initialization for %qs), ofwhat);
}
/* Issue a warning for a bad initializer component.
@@ -5597,12 +5598,13 @@ static void
warning_init (location_t loc, int opt, const char *gmsgid)
{
char *ofwhat;
+ bool warned;
/* The gmsgid may be a format string with % and %. */
- warning_at (loc, opt, gmsgid);
+ warned = warning_at (loc, opt, gmsgid);
ofwhat = print_spelling ((char *) alloca (spelling_length () + 1));
- if (*ofwhat)
-warning_at (loc, opt, (near initialization for %qs), ofwhat);
+ if (*ofwhat warned)
+inform (loc, (near initialization for %qs), ofwhat);
}
/* If TYPE is an array type and EXPR is a parenthesized string
diff --git gcc/testsuite/gcc.dg/Wcxx-compat-6.c
gcc/testsuite/gcc.dg/Wcxx-compat-6.c
index 2b327c4..eee6768 100644
--- gcc/testsuite/gcc.dg/Wcxx-compat-6.c
+++ gcc/testsuite/gcc.dg/Wcxx-compat-6.c
@@ -109,4 +109,4 @@ f(enum E1 e1, enum E2 e2, struct s1 vs1, struct s1 *vp1)
}
/* Match all extra informative notes. */
-/* { dg-warning near initialization for expected { target *-*-* } 0 } */
+/* { dg-message near initialization for expected { target *-*-* } 0 } */
diff --git gcc/testsuite/gcc.dg/array-2.c gcc/testsuite/gcc.dg/array-2.c
index 497c586..6187500 100644
--- gcc/testsuite/gcc.dg/array-2.c
+++ gcc/testsuite/gcc.dg/array-2.c
@@ -8,7 +8,7 @@ struct f { int w; int x[]; };
struct g { struct f f; };
struct g g1 = { { 0, { } } };
struct g g2 = { { 0, { 1 } } }; /* { dg-error nested context nested } */
- /* { dg-error near init near { target *-*-*
} 10 } */
+ /* { dg-message near init near { target
*-*-* } 10 } */
struct h { int x[0]; int y; };
struct h h1 = { { 0 }, 1 }; /* { dg-warning excess elements excess } */
- /* { dg-warning near init before end { target
*-*-* } 13 } */
+ /* { dg-message near init before end { target
*-*-* } 13 } */
diff --git gcc/testsuite/gcc.dg/array-const-2.c
gcc/testsuite/gcc.dg/array-const-2.c
index f6e2bd5..6f76955 100644
--- gcc/testsuite/gcc.dg/array-const-2.c
+++ gcc/testsuite/gcc.dg/array-const-2.c
@@ -6,4 +6,4 @@
extern int i;
int a[] = { [1 ? 1 : i] = 0 }; /* { dg-warning array index in initializer is
not an integer constant expression } */
-/* { dg-warning near initialization near init { target *-*-* } 8 } */
+/* { dg-message near initialization near init { target *-*-* } 8 } */
diff --git gcc/testsuite/gcc.dg/array-const-3.c
gcc/testsuite/gcc.dg/array-const-3.c
index 5bb215c..036b0ea 100644
--- gcc/testsuite/gcc.dg/array-const-3.c
+++ gcc/testsuite/gcc.dg/array-const-3.c
@@ -6,4 +6,4 @@
extern int i;
int a[] = { [1 ? 1 : i] = 0 }; /* { dg-error array index in initializer is
not an integer constant expression } */
-/* { dg-error near initialization near init { target *-*-* } 8 } */
+/* { dg-message near initialization near init { target *-*-* } 8 }
[Patch ARM] Remove XFmode from arm-modes.def
Hi, Marc Glisse pointed out that we had an unused XFmode in the ARM backend. RichardE says that this is an FPA legacy and that means we can remove this safely. Thus removed after a sanity check that the target builds ok. Applied to trunk as nearly obvious. regards Ramana 2014-06-09 Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/arm/arm-modes.def: Remove XFmode. Index: gcc/config/arm/arm-modes.def === --- gcc/config/arm/arm-modes.def(revision 211317) +++ gcc/config/arm/arm-modes.def(working copy) @@ -21,9 +21,6 @@ along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/. */ -/* Extended precision floating point. - FIXME What format is this? */ -FLOAT_MODE (XF, 12, 0); /* Half-precision floating point */ FLOAT_MODE (HF, 2, 0);
Re: [patch] fix tests for AVX512
Hello Uroš, On 08 Jun 11:26, Uros Bizjak wrote: On Tue, May 27, 2014 at 12:28 PM, Petr Murzin petrmurz...@gmail.com wrote: Hi, I've fixed tests for AVX512, so they could be compiled with -Werror -Wall. Please have a look. From a quick look, this looks OK. Thanks, checked into trunk. Could we apply that to 4.9 branch? -- Thanks, K
Re: [PATCH] proposed fix for bug # 61144
On Fri, 6 Jun 2014, Rich Felker wrote:
On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote:
On 05/21/14 21:59, Rich Felker wrote:
On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote:
On Wed, May 21, 2014 at 3:59 AM, Rich Felker dal...@libc.org wrote:
Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc
due to aggressive and semantically-incorrect constant folding of weak
aliases. The attached patch seems to fix the issue. A weak alias
should never be a candidate for constant folding because it may always
be replaced by a strong definition from another translation unit.
For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
I do not have a copyright assignment on file but this patch should be
sufficiently trivial not to require it.
Please add a testcase. Also I wonder why it isn't better to generalize
How should a testcase be done? On the PR there's a testcase that shows
the problem in the generated code, but no automated check for it.
Testing this is actually a bit of a pain unless you're allowed to run
the generated program.
You can run the test program. Have it exit (0) on success, abort ()
on failure if at all possible. Then drop the test source file into
gcc/testsuite/gcc.c-torture/execute/pr61144.c
The test needs to be two translation units linked together: one with
a weak definition of the object as 0, and the other with a strong
definition. The test should show the weak value being used rather than
the strong one. But I'm not sure how this should be integrated with
the build process.
Please have a look at gcc/testsuite/gcc.dg/special/wkali-2{,a,b}.c. This is a
three-TU test for weak aliases, so you should be able to very easily adjust it
for this bug.
Thanks.
Alexander
Re: [patch] fix tests for AVX512
On Mon, Jun 9, 2014 at 1:34 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hello Uroš, On 08 Jun 11:26, Uros Bizjak wrote: On Tue, May 27, 2014 at 12:28 PM, Petr Murzin petrmurz...@gmail.com wrote: Hi, I've fixed tests for AVX512, so they could be compiled with -Werror -Wall. Please have a look. From a quick look, this looks OK. Thanks, checked into trunk. Could we apply that to 4.9 branch? OK, but please wait a couple of days to check if everything is OK in mainline and also for Release Manager to reject the patch. Thanks, Uros.
[patch] fix minor typo in comment
Tested x86_64-linux, committed to trunk. commit 176c3be1080e0b33fe02612e015e42eb2d74cf0e Author: Jonathan Wakely jwak...@redhat.com Date: Mon Jun 9 10:40:47 2014 +0100 * include/tr1/beta_function.tcc: Fix spelling of include guard in comment. diff --git a/libstdc++-v3/include/tr1/beta_function.tcc b/libstdc++-v3/include/tr1/beta_function.tcc index c4fe6e8..e7d7c4d 100644 --- a/libstdc++-v3/include/tr1/beta_function.tcc +++ b/libstdc++-v3/include/tr1/beta_function.tcc @@ -194,4 +194,4 @@ namespace tr1 } } -#endif // __GLIBCXX_TR1_BETA_FUNCTION_TCC +#endif // _GLIBCXX_TR1_BETA_FUNCTION_TCC
Re: [Patch, fortran] PR61406 - [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression
Dear Dominique, Committed to trunk as revision 211374. I decided that getting rid of the double temporary was delving too deep into the workings of trans-array.c to be worthwhile at the moment. Cheers Paul On 9 June 2014 12:05, Dominique Dhumieres domi...@lps.ens.fr wrote: Dear Paul, This was a slip up on my part. The fix is obvious - OK for trunk and 4.9? The patch fixes the ICE. Any progress about the double temporary? [Book15] f90/bug% gfc pr61406.f90 -Warray-temporaries pr61406.f90:6.18: associate (n = [cos(theta), sin(theta)]) 1 Warning: Creating array temporary at (1) pr61406.f90:6.18: associate (n = [cos(theta), sin(theta)]) 1 Warning: Creating array temporary at (1) Thanks for the patch. Dominique -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators
Patch posted at https://gcc.gnu.org/ml/fortran/2014-05/msg00155.html. TIA Dominique
[PATCH, ARM] Cortex-A9 MPCore volatile load workaround
Hi Richard,
As we talked about earlier, here's a patch to add a compiler option to
work around Cortex-A9 MPCore errata 761319:
http://infocenter.arm.com/help/topic/com.arm.doc.uan0004a/UAN0004A_a9_read_read.pdf
What the option does basically, is to scan for volatile loads during
reorg, and add a dmb barrier after it. It also strives to make dmb
conditionally executed under TARGET_THUMB2, which means a new Thumb-2
specific *memory_barrier_t2 pattern in sync.md, with adjusted
conds/predicable attributes and %? in output strings.
Patch originally written by Julian, with additions by Meador, and
finally a few trivial adjustments by me. Again, we've been carrying this
fix for a release or two. Okay for trunk?
Thanks,
Chung-Lin
2014-06-09 Julian Brown jul...@codesourcery.com
Meador Inge mead...@codesourcery.com
Chung-Lin Tang clt...@codesourcery.com
* config/arm/arm.c (arm_option_override): Emit warning if
-mfix-cortex-a9-volatile-hazards is used on an incompatible CPU.
(any_volatile_loads_p): New.
(arm_cortex_a9_errata_reorg): New.
(arm_reorg): Call arm_cortex_a9_errata_reorg.
* config/arm/arm.opt (mfix-cortex-a9-volatile-hazards): Add
option.
* config/arm/sync.md (*memory_barrier): Don't use on Thumb-2.
(*memory_barrier_t2): New, allow conditional execution on
Thumb-2.
* doc/invoke.texi (-mfix-cortex-a9-volatile-hazards): Add
documentation.
testsuite/
* lib/target-supports.exp (check_effective_target_arm_dmb): New.
* gcc.target/arm/a9-volatile-ordering-erratum-1.c: New test.
* gcc.target/arm/a9-volatile-ordering-erratum-2.c: New test.
* gcc.target/arm/a9-volatile-ordering-erratum-3.c: New test.
* gcc.target/arm/a9-volatile-ordering-erratum-4.c: New test.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 211364)
+++ doc/invoke.texi (working copy)
@@ -535,6 +535,7 @@ Objective-C and Objective-C++ Dialects}.
-mtp=@var{name} -mtls-dialect=@var{dialect} @gol
-mword-relocations @gol
-mfix-cortex-m3-ldrd @gol
+-mfix-cortex-a9-volatile-hazards @gol
-munaligned-access @gol
-mneon-for-64bits @gol
-mslow-flash-data @gol
@@ -12677,6 +12678,16 @@ with overlapping destination and base registers ar
generating these instructions. This option is enabled by default when
@option{-mcpu=cortex-m3} is specified.
+@item -mfix-cortex-a9-volatile-hazards
+@opindex mfix-cortex-a9-volatile-hazards
+Cortex-A9 MPCore processors have an erratum that in rare cases cause
+successive memory loads to appear out of program order if another processor
+is simultaneously writing to the same location. This causes problems if
+volatile variables are used for communication between processors.
+This option enables the ARM recommended workaround, to insert a @code{dmb}
+instruction after each volatile load. Because of the potentially high
+overhead, this workaround is not enabled by default.
+
@item -munaligned-access
@itemx -mno-unaligned-access
@opindex munaligned-access
Index: config/arm/arm.opt
===
--- config/arm/arm.opt (revision 211364)
+++ config/arm/arm.opt (working copy)
@@ -264,6 +264,11 @@ Target Report Var(fix_cm3_ldrd) Init(2)
Avoid overlapping destination and address registers on LDRD instructions
that may trigger Cortex-M3 errata.
+mfix-cortex-a9-volatile-hazards
+Target Report Var(fix_a9_volatile_hazards) Init(0)
+Avoid errata causing read-after-read hazards for concurrent volatile
+accesses on Cortex-A9 MPCore processors.
+
munaligned-access
Target Report Var(unaligned_access) Init(2)
Enable unaligned word and halfword accesses to packed data.
Index: config/arm/sync.md
===
--- config/arm/sync.md (revision 211364)
+++ config/arm/sync.md (working copy)
@@ -46,7 +46,7 @@
(define_insn *memory_barrier
[(set (match_operand:BLK 0 )
(unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BARRIER))]
- TARGET_HAVE_MEMORY_BARRIER
+ TARGET_HAVE_MEMORY_BARRIER !TARGET_THUMB2
{
if (TARGET_HAVE_DMB)
{
@@ -65,6 +65,29 @@
(set_attr conds unconditional)
(set_attr predicable no)])
+;; Thumb-2 version allows conditional execution
+(define_insn *memory_barrier_t2
+ [(set (match_operand:BLK 0 )
+ (unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BARRIER))]
+ TARGET_HAVE_MEMORY_BARRIER TARGET_THUMB2
+ {
+if (TARGET_HAVE_DMB)
+ {
+ /* Note we issue a system level barrier. We should consider issuing
+ a inner shareabilty zone barrier here instead, ie. DMB ISH. */
+ /* ??? Differentiate based on SEQ_CST vs less strict? */
+ return dmb%?\tsy;
+ }
+
+if (TARGET_HAVE_DMB_MCR)
+ return mcr%?\tp15, 0, r0, c7, c10, 5;
+
+gcc_unreachable ();
+ }
+ [(set_attr length 4)
+ (set_attr conds nocond)
+ (set_attr predicable
[PATCH,MIPS] Remove unused code relating to reloading fcc
This is a small clean-up patch to remove code relating to reloading or moving
mips fcc registers. At some point in the past these registers were allocated
as part of register allocation but they are now statically allocated in the
backend in a round robin fashion. The code for reloading them is therefore not
necessary any more. The move costs are also irrelevant so are replaced with
a comment instead (but the cases can just be deleted if that is preferred).
Matthew
gcc/
* config/mips/mips-protos.h (mips_expand_fcc_reload): Remove.
* config/mips/mips.c (mips_expand_fcc_reload): Remove.
(mips_move_to_gpr_cost): ST_REGS can't be moved.
(mips_move_from_gpr_cost): Likewise.
(mips_register_move_cost): Likewise.
---
gcc/config/mips/mips-protos.h |1 -
gcc/config/mips/mips.c| 41 -
2 files changed, 4 insertions(+), 38 deletions(-)
diff --git a/gcc/config/mips/mips-protos.h b/gcc/config/mips/mips-protos.h
index 0b8125a..0b32a70 100644
--- a/gcc/config/mips/mips-protos.h
+++ b/gcc/config/mips/mips-protos.h
@@ -232,7 +232,6 @@ extern bool mips_use_pic_fn_addr_reg_p (const_rtx);
extern rtx mips_expand_call (enum mips_call_type, rtx, rtx, rtx, rtx, bool);
extern void mips_split_call (rtx, rtx);
extern bool mips_get_pic_call_symbol (rtx *, int);
-extern void mips_expand_fcc_reload (rtx, rtx, rtx);
extern void mips_set_return_address (rtx, rtx);
extern bool mips_move_by_pieces_p (unsigned HOST_WIDE_INT, unsigned int);
extern bool mips_store_by_pieces_p (unsigned HOST_WIDE_INT, unsigned int);
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 73b6963..1fb5ba2 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -7195,35 +7195,6 @@ mips_function_ok_for_sibcall (tree decl, tree exp
ATTRIBUTE_UNUSED)
return true;
}
-/* Emit code to move general operand SRC into condition-code
- register DEST given that SCRATCH is a scratch TFmode FPR.
- The sequence is:
-
- FP1 = SRC
- FP2 = 0.0f
- DEST = FP2 FP1
-
- where FP1 and FP2 are single-precision FPRs taken from SCRATCH. */
-
-void
-mips_expand_fcc_reload (rtx dest, rtx src, rtx scratch)
-{
- rtx fp1, fp2;
-
- /* Change the source to SFmode. */
- if (MEM_P (src))
-src = adjust_address (src, SFmode, 0);
- else if (REG_P (src) || GET_CODE (src) == SUBREG)
-src = gen_rtx_REG (SFmode, true_regnum (src));
-
- fp1 = gen_rtx_REG (SFmode, REGNO (scratch));
- fp2 = gen_rtx_REG (SFmode, REGNO (scratch) + MAX_FPRS_PER_FMT);
-
- mips_emit_move (copy_rtx (fp1), src);
- mips_emit_move (copy_rtx (fp2), CONST0_RTX (SFmode));
- emit_insn (gen_slt_sf (dest, fp2, fp1));
-}
-
/* Implement MOVE_BY_PIECES_P. */
bool
@@ -12045,8 +12016,8 @@ mips_move_to_gpr_cost (enum machine_mode mode
ATTRIBUTE_UNUSED,
return 4;
case ST_REGS:
- /* LUI followed by MOVF. */
- return 4;
+ /* Not possible. ST_REGS are never moved. */
+ return 0;
case COP0_REGS:
case COP2_REGS:
@@ -12082,9 +12053,8 @@ mips_move_from_gpr_cost (enum machine_mode mode,
reg_class_t to)
return 4;
case ST_REGS:
- /* A secondary reload through an FPR scratch. */
- return (mips_register_move_cost (mode, GENERAL_REGS, FP_REGS)
- + mips_register_move_cost (mode, FP_REGS, ST_REGS));
+ /* Not possible. ST_REGS are never moved. */
+ return 0;
case COP0_REGS:
case COP2_REGS:
@@ -12117,9 +12087,6 @@ mips_register_move_cost (enum machine_mode mode,
if (to == FP_REGS mips_mode_ok_for_mov_fmt_p (mode))
/* MOV.FMT. */
return 4;
- if (to == ST_REGS)
- /* The sequence generated by mips_expand_fcc_reload. */
- return 8;
}
/* Handle cases in which only one class deviates from the ideal. */
--
1.7.1
PR54442 build_qualified_type produces a non-canonical type
Hello,
in this PR, we end up with 3 types A, B and C such that
TYPE_CANONICAL(A)=B and TYPE_CANONICAL(B)=C. I don't think that is
supposed to happen. Here, build_qualified_type fills in TYPE_CANONICAL(A)
by calling build_qualified_type (so get_qualified_type), which afaics
isn't guaranteed to return a canonical type.
I doubt the patch can be wrong, but it may be that this is a situation
that is not supposed to happen and should be fixed elsewhere?
Bootstrap+testsuite on x86_64-linux-gnu.
2014-06-09 Marc Glisse marc.gli...@inria.fr
PR c++/54442
gcc/
* tree.c (build_qualified_type): Use a canonical type for
TYPE_CANONICAL.
gcc/testsuite/
* g++.dg/pr54442.C: New file.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/pr54442.C
===
--- gcc/testsuite/g++.dg/pr54442.C (revision 0)
+++ gcc/testsuite/g++.dg/pr54442.C (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+
+struct S
+{
+ void s (int) const throw ();
+ void s (int) throw ();
+};
+
+typedef int index_t;
+
+void (S::*f) (index_t) = S::s;
+void (S::*g) (index_t) const = S::s;
Index: gcc/tree.c
===
--- gcc/tree.c (revision 211374)
+++ gcc/tree.c (working copy)
@@ -6319,22 +6319,25 @@ build_qualified_type (tree type, int typ
TYPE_ALIGN (t) = TYPE_ALIGN (atomic_type);
}
}
if (TYPE_STRUCTURAL_EQUALITY_P (type))
/* Propagate structural equality. */
SET_TYPE_STRUCTURAL_EQUALITY (t);
else if (TYPE_CANONICAL (type) != type)
/* Build the underlying canonical type, since it is different
from TYPE. */
- TYPE_CANONICAL (t) = build_qualified_type (TYPE_CANONICAL (type),
- type_quals);
+ {
+ tree c = build_qualified_type (TYPE_CANONICAL (type),
+type_quals);
+ TYPE_CANONICAL (t) = TYPE_CANONICAL (c);
+ }
else
/* T is its own canonical type. */
TYPE_CANONICAL (t) = t;
}
return t;
}
/* Create a variant of type T with alignment ALIGN. */
[C++11, C++14 PATCH 1/4] Support for SD-6: SG10 Feature Test Recommendations: libcpp
This is the second round of the SD-6 support series.
I believe I have answered everyones concerns.
Built and tested on x86_64-linux.
OK?
2014-06-09 Ed Smith-Rowland 3dw...@verizon.net
Implement SD-6: SG10 Feature Test Recommendations
* directives.c: Support __has_include__ builtin.
* expr.c (parse_has_include): New function to parse __has_include__
builtin; (eval_token()): Use it.
* files.c (_cpp_has_header()): New funtion to look for header;
(open_file_failed()): Not an error to not find a header file for
__has_include__.
* identifiers.c (_cpp_init_hashtable()): Add entry for __has_include__.
* internal.h (lexer_state, spec_nodes): Add in__has_include__.
* pch.c (cpp_read_state): Lookup __has_include__.
* traditional.c (enum ls, _cpp_scan_out_logical_line()): Walk through
__has_include__ statements.
Index: internal.h
===
--- internal.h (revision 211354)
+++ internal.h (working copy)
@@ -258,6 +258,9 @@
/* Nonzero when parsing arguments to a function-like macro. */
unsigned char parsing_args;
+ /* Nonzero to prevent macro expansion. */
+ unsigned char in__has_include__;
+
/* Nonzero if prevent_expansion is true only because output is
being discarded. */
unsigned char discarding_output;
@@ -279,6 +282,8 @@
cpp_hashnode *n_true;/* C++ keyword true */
cpp_hashnode *n_false; /* C++ keyword false */
cpp_hashnode *n__VA_ARGS__; /* C99 vararg macros */
+ cpp_hashnode *n__has_include__; /* __has_include__ operator */
+ cpp_hashnode *n__has_include_next__; /* __has_include_next__ operator */
};
typedef struct _cpp_line_note _cpp_line_note;
@@ -645,6 +650,8 @@
extern bool _cpp_read_file_entries (cpp_reader *, FILE *);
extern const char *_cpp_get_file_name (_cpp_file *);
extern struct stat *_cpp_get_file_stat (_cpp_file *);
+extern bool _cpp_has_header (cpp_reader *, const char *, int,
+enum include_type);
/* In expr.c */
extern bool _cpp_parse_expr (cpp_reader *, bool);
@@ -680,6 +687,7 @@
extern void _cpp_do_file_change (cpp_reader *, enum lc_reason, const char *,
linenum_type, unsigned int);
extern void _cpp_pop_buffer (cpp_reader *);
+extern char *_cpp_bracket_include (cpp_reader *);
/* In directives.c */
struct _cpp_dir_only_callbacks
Index: directives.c
===
--- directives.c(revision 211354)
+++ directives.c(working copy)
@@ -549,6 +549,11 @@
if (is_def_or_undef node == pfile-spec_nodes.n_defined)
cpp_error (pfile, CPP_DL_ERROR,
\defined\ cannot be used as a macro name);
+ else if (is_def_or_undef
+(node == pfile-spec_nodes.n__has_include__
+|| node == pfile-spec_nodes.n__has_include_next__))
+ cpp_error (pfile, CPP_DL_ERROR,
+ \__has_include__\ cannot be used as a macro name);
else if (! (node-flags NODE_POISONED))
return node;
}
@@ -2601,3 +2606,12 @@
node-directive_index = i;
}
}
+
+/* Extract header file from a bracket include. Parsing starts after ''.
+ The string is malloced and must be freed by the caller. */
+char *
+_cpp_bracket_include(cpp_reader *pfile)
+{
+ return glue_header_name (pfile);
+}
+
Index: expr.c
===
--- expr.c (revision 211354)
+++ expr.c (working copy)
@@ -64,6 +64,8 @@
static unsigned int interpret_int_suffix (cpp_reader *, const uchar *, size_t);
static void check_promotion (cpp_reader *, const struct op *);
+static cpp_num parse_has_include (cpp_reader *, enum include_type);
+
/* Token type abuse to create unary plus and minus operators. */
#define CPP_UPLUS ((enum cpp_ttype) (CPP_LAST_CPP_OP + 1))
#define CPP_UMINUS ((enum cpp_ttype) (CPP_LAST_CPP_OP + 2))
@@ -1041,6 +1043,10 @@
case CPP_NAME:
if (token-val.node.node == pfile-spec_nodes.n_defined)
return parse_defined (pfile);
+ else if (token-val.node.node == pfile-spec_nodes.n__has_include__)
+ return parse_has_include (pfile, IT_INCLUDE);
+ else if (token-val.node.node == pfile-spec_nodes.n__has_include_next__)
+ return parse_has_include (pfile, IT_INCLUDE_NEXT);
else if (CPP_OPTION (pfile, cplusplus)
(token-val.node.node == pfile-spec_nodes.n_true
|| token-val.node.node == pfile-spec_nodes.n_false))
@@ -2065,3 +2071,71 @@
return lhs;
}
+
+/* Handle meeting __has_include__ in a preprocessor expression. */
+static cpp_num
+parse_has_include (cpp_reader *pfile, enum include_type type)
+{
+ cpp_num result;
+ bool paren = false;
+ cpp_hashnode *node = 0;
+ const cpp_token *token;
+ bool bracket = false;
+ char *fname = 0;
+
+
[C++11, C++14 PATCH 2/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/c-family
This is the second round of the SD-6 support series.
I believe I have answered everyones concerns.
Built and tested on x86_64-linux.
OK?
2014-06-09 Ed Smith-Rowland 3dw...@verizon.net
Implement SD-6: SG10 Feature Test Recommendations
* c-cppbuiltin.c (c_cpp_builtins()): Define language feature
macros and the __has_header macro.
Index: c-cppbuiltin.c
===
--- c-cppbuiltin.c (revision 211354)
+++ c-cppbuiltin.c (working copy)
@@ -794,6 +794,12 @@
/* For stddef.h. They require macros defined in c-common.c. */
c_stddef_cpp_builtins ();
+ /* Set feature test macros for all C/C++ (not for just C++11 etc.)
+ the builtins __has_include__ and __has_include_next__ are defined
+ int libcpp. */
+ cpp_define (pfile, __has_include(STR)=__has_include__(STR));
+ cpp_define (pfile, __has_include_next(STR)=__has_include_next__(STR));
+
if (c_dialect_cxx ())
{
if (flag_weak SUPPORTS_ONE_ONLY)
@@ -805,7 +811,40 @@
if (flag_rtti)
cpp_define (pfile, __GXX_RTTI);
if (cxx_dialect = cxx11)
-cpp_define (pfile, __GXX_EXPERIMENTAL_CXX0X__);
+ {
+ cpp_define (pfile, __GXX_EXPERIMENTAL_CXX0X__);
+
+ /* Set feature test macros for C++11 */
+ cpp_define (pfile, __cpp_unicode_characters=200704);
+ cpp_define (pfile, __cpp_raw_strings=200710);
+ cpp_define (pfile, __cpp_unicode_literals=200710);
+ cpp_define (pfile, __cpp_user_defined_literals=200809);
+ cpp_define (pfile, __cpp_lambdas=200907);
+ cpp_define (pfile, __cpp_constexpr=200704);
+ cpp_define (pfile, __cpp_static_assert=200410);
+ cpp_define (pfile, __cpp_decltype=200707);
+ cpp_define (pfile, __cpp_attributes=200809);
+ cpp_define (pfile, __cpp_rvalue_reference=200610);
+ cpp_define (pfile, __cpp_variadic_templates=200704);
+ cpp_define (pfile, __cpp_alias_templates=200704);
+ }
+ if (cxx_dialect cxx11)
+ {
+ /* Set feature test macros for C++14 */
+ cpp_define (pfile, __cpp_binary_literals=201304);
+ cpp_define (pfile, __cpp_init_captures=201304);
+ cpp_define (pfile, __cpp_generic_lambdas=201304);
+ //cpp_undef (pfile, __cpp_constexpr);
+ //cpp_define (pfile, __cpp_constexpr=201304);
+ cpp_define (pfile, __cpp_decltype_auto=201304);
+ cpp_define (pfile, __cpp_return_type_deduction=201304);
+ cpp_define (pfile, __cpp_runtime_arrays=201304);
+ //cpp_define (pfile, __cpp_aggregate_nsdmi=201304);
+ //cpp_define (pfile, __cpp_variable_templates=201304);
+ cpp_define (pfile, __cpp_digit_separators=201309);
+ cpp_define (pfile, __cpp_attribute_deprecated=201309);
+ //cpp_define (pfile, __cpp_sized_deallocation=201309);
+ }
}
/* Note that we define this for C as well, so that we know if
__attribute__((cleanup)) will interface with EH. */
[C++11, C++14 PATCH 3/4] Support for SD-6: SG10 Feature Test Recommendations: libstdc++-v3
This is the second round of the SD-6 support series.
I believe I have answered everyones concerns.
Several test suite adjustments were added.
Built and tested on x86_64-linux.
OK?
2014-06-09 Ed Smith-Rowland 3dw...@verizon.net
Implement SD-6: SG10 Feature Test Recommendations
* include/bits/basic_string.h: Add __cpp_lib feature test macro.
* include/bits/stl_algobase.h: Ditto.
* include/bits/stl_function.h: Ditto.
* include/bits/unique_ptr.h: Ditto.
* include/std/array: Ditto.
* include/std/chrono: Ditto.
* include/std/complex: Ditto.
* include/std/iomanip: Ditto.
* include/std/mutex: Ditto.
* include/std/shared_mutex: Ditto.
* include/std/tuple: Ditto.
* include/std/type_traits: Ditto.
* include/std/utility: Ditto.
* testsuite/experimental/feat-cxx14.cc: New.
* testsuite/experimental/feat-lib-fund.cc: New.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust.
* testsuite/20_util/duration/literals/range.cc: Adjust.
* testsuite/20_util/duration/requirements/typedefs_neg1.cc: Adjust.
* testsuite/20_util/duration/requirements/typedefs_neg2.cc: Adjust.
* testsuite/20_util/duration/requirements/typedefs_neg3.cc: Adjust.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Adjust.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust.
* testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
Adjust.
Index: include/bits/basic_string.h
===
--- include/bits/basic_string.h (revision 211363)
+++ include/bits/basic_string.h (working copy)
@@ -3124,6 +3124,8 @@
#if __cplusplus 201103L
+#define __cpp_lib_string_udls 201304
+
inline namespace literals
{
inline namespace string_literals
Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h (revision 211363)
+++ include/bits/stl_algobase.h (working copy)
@@ -1091,6 +1091,7 @@
}
#if __cplusplus 201103L
+#define __cpp_lib_robust_nonmodifying_seq_ops 201304
/**
* @brief Tests a range for element-wise equality.
* @ingroup non_mutating_algorithms
Index: include/bits/stl_function.h
===
--- include/bits/stl_function.h (revision 211363)
+++ include/bits/stl_function.h (working copy)
@@ -217,6 +217,10 @@
};
#if __cplusplus 201103L
+
+#define __cpp_lib_transparent_operators 201210
+#define __cpp_lib_generic_associative_lookup 201304
+
template
struct plusvoid
{
Index: include/bits/unique_ptr.h
===
--- include/bits/unique_ptr.h (revision 211363)
+++ include/bits/unique_ptr.h (working copy)
@@ -743,6 +743,9 @@
};
#if __cplusplus 201103L
+
+#define __cpp_lib_make_unique 201304
+
templatetypename _Tp
struct _MakeUniq
{ typedef unique_ptr_Tp __single_object; };
Index: include/std/array
===
--- include/std/array (revision 211363)
+++ include/std/array (working copy)
@@ -35,6 +35,9 @@
# include bits/c++0x_warning.h
#else
+#undef __cpp_lib_constexpr_functions
+#define __cpp_lib_constexpr_functions 201210
+
#include stdexcept
#include bits/stl_algobase.h
#include bits/range_access.h
Index: include/std/chrono
===
--- include/std/chrono (revision 211363)
+++ include/std/chrono (working copy)
@@ -43,6 +43,9 @@
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
+#undef __cpp_lib_constexpr_functions
+#define __cpp_lib_constexpr_functions 201210
+
namespace std _GLIBCXX_VISIBILITY(default)
{
/**
@@ -782,6 +785,8 @@
#if __cplusplus 201103L
+#define __cpp_lib_chrono_udls 201304
+
inline namespace literals
{
inline namespace chrono_literals
Index: include/std/complex
===
--- include/std/complex (revision 211363)
+++ include/std/complex (working copy)
@@ -1929,6 +1929,8 @@
inline namespace literals {
inline namespace complex_literals {
+#define __cpp_lib_complex_udls 201309
+
constexpr std::complexfloat
operatorif(long double __num)
{ return std::complexfloat{0.0F, static_castfloat(__num)}; }
Index: include/std/iomanip
===
--- include/std/iomanip (revision 211363)
+++ include/std/iomanip (working copy)
@@ -339,6 +339,8 @@
#if __cplusplus 201103L
+#define __cpp_lib_quoted_string_io 201304
+
_GLIBCXX_END_NAMESPACE_VERSION
namespace __detail {
_GLIBCXX_BEGIN_NAMESPACE_VERSION
Index: include/std/mutex
[C++11, C++14 PATCH 4/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/testsuite
This is the second round of the SD-6 support series.
I believe I have answered everyones concerns.
Built and tested on x86_64-linux.
OK?
libstdc++:
2014-06-09 Ed Smith-Rowland 3dw...@verizon.net
Implement SD-6: SG10 Feature Test Recommendations
* g++.dg/cpp1y/feat-cxx11-neg.C: New.
* g++.dg/cpp1y/feat-cxx11.C: New.
* g++.dg/cpp1y/feat-cxx14-neg.C: New.
* g++.dg/cpp1y/feat-cxx14.C: New.
* g++.dg/cpp1y/phoobhar.h: New.
* g++.dg/cpp1y/testinc/phoobhar.h: New.
* g++.dg/cpp1y/testinc/phoobhar.h: New.
Index: g++.dg/cpp1y/feat-cxx11-neg.C
===
--- g++.dg/cpp1y/feat-cxx11-neg.C (revision 0)
+++ g++.dg/cpp1y/feat-cxx11-neg.C (working copy)
@@ -0,0 +1,35 @@
+// { dg-do compile { target c++11_only } }
+
+// These *are* defined in C++14 onwards.
+
+#ifndef __cpp_binary_literals
+# error __cpp_binary_literals // { dg-error error }
+#endif
+
+#ifndef __cpp_init_captures
+# error __cpp_init_captures // { dg-error error }
+#endif
+
+#ifndef __cpp_generic_lambdas
+# error __cpp_generic_lambdas // { dg-error error }
+#endif
+
+#ifndef __cpp_decltype_auto
+# error __cpp_decltype_auto // { dg-error error }
+#endif
+
+#ifndef __cpp_return_type_deduction
+# error __cpp_return_type_deduction // { dg-error error }
+#endif
+
+#ifndef __cpp_runtime_arrays
+# error __cpp_runtime_arrays // { dg-error error }
+#endif
+
+#ifndef __cpp_digit_separators
+# error __cpp_digit_separators // { dg-error error }
+#endif
+
+#ifndef __cpp_attribute_deprecated
+# error __cpp_attribute_deprecated // { dg-error error }
+#endif
Index: g++.dg/cpp1y/feat-cxx11.C
===
--- g++.dg/cpp1y/feat-cxx11.C (revision 0)
+++ g++.dg/cpp1y/feat-cxx11.C (working copy)
@@ -0,0 +1,73 @@
+// { dg-do compile { target c++11_only } }
+
+#ifndef __cpp_unicode_characters
+# error __cpp_unicode_characters
+#elif __cpp_unicode_characters != 200704
+# error __cpp_unicode_characters != 200704
+#endif
+
+#ifndef __cpp_raw_strings
+# error __cpp_raw_strings
+#elif __cpp_raw_strings != 200710
+# error __cpp_raw_strings != 200710
+#endif
+
+#ifndef __cpp_unicode_literals
+# error __cpp_unicode_literals
+#elif __cpp_unicode_literals != 200710
+# error __cpp_unicode_literals != 200710
+#endif
+
+#ifndef __cpp_user_defined_literals
+# error __cpp_user_defined_literals
+#elif __cpp_user_defined_literals != 200809
+# error __cpp_user_defined_literals != 200809
+#endif
+
+#ifndef __cpp_lambdas
+# error __cpp_lambdas
+#elif __cpp_lambdas != 200907
+# error __cpp_lambdas != 200907
+#endif
+
+#ifndef __cpp_constexpr
+# error __cpp_constexpr
+#elif __cpp_constexpr != 200704
+# error __cpp_constexpr != 200704
+#endif
+
+#ifndef __cpp_static_assert
+# error __cpp_static_assert
+#elif __cpp_static_assert != 200410
+# error __cpp_static_assert != 200410
+#endif
+
+#ifndef __cpp_decltype
+# error __cpp_decltype
+#elif __cpp_decltype != 200707
+# error __cpp_decltype != 200707
+#endif
+
+#ifndef __cpp_attributes
+# error __cpp_attributes
+#elif __cpp_attributes != 200809
+# error __cpp_attributes != 200809
+#endif
+
+#ifndef __cpp_rvalue_reference
+# error __cpp_rvalue_reference
+#elif __cpp_rvalue_reference != 200610
+# error __cpp_rvalue_reference != 200610
+#endif
+
+#ifndef __cpp_variadic_templates
+# error __cpp_variadic_templates
+#elif __cpp_variadic_templates != 200704
+# error __cpp_variadic_templates != 200704
+#endif
+
+#ifndef __cpp_alias_templates
+# error __cpp_alias_templates
+#elif __cpp_alias_templates != 200704
+# error __cpp_alias_templates != 200704
+#endif
Index: g++.dg/cpp1y/feat-cxx14-neg.C
===
--- g++.dg/cpp1y/feat-cxx14-neg.C (revision 0)
+++ g++.dg/cpp1y/feat-cxx14-neg.C (working copy)
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++1y } }
+
+// TODO: Change != to == when C++14 constexpr goes in.
+#ifndef __cpp_constexpr
+# error __cpp_constexpr
+#elif __cpp_constexpr != 200704
+# error __cpp_constexpr != 200704 // { dg-error error }
+#endif
Index: g++.dg/cpp1y/feat-cxx14.C
===
--- g++.dg/cpp1y/feat-cxx14.C (revision 0)
+++ g++.dg/cpp1y/feat-cxx14.C (working copy)
@@ -0,0 +1,187 @@
+// { dg-do compile { target c++1y } }
+// { dg-options -I . -I testinc }
+
+// Begin C++11 tests.
+
+#ifndef __cpp_unicode_characters
+# error __cpp_unicode_characters
+#endif
+
+#ifndef __cpp_raw_strings
+# error __cpp_raw_strings
+#endif
+
+#ifndef __cpp_unicode_literals
+# error __cpp_unicode_literals
+#endif
+
+#ifndef __cpp_user_defined_literals
+# error __cpp_user_defined_literals
+#endif
+
+#ifndef __cpp_lambdas
+# error __cpp_lambdas
+#endif
+
+#ifndef __cpp_constexpr
+# error __cpp_constexpr
+#endif
+
+#ifndef __cpp_static_assert
+# error __cpp_static_assert
+#endif
+
+#ifndef
Re: PR54442 build_qualified_type produces a non-canonical type
On 06/09/2014 10:18 AM, Marc Glisse wrote: I doubt the patch can be wrong, but it may be that this is a situation that is not supposed to happen and should be fixed elsewhere? Seems likely. What is the difference between the type returned from build_qualified_type (TYPE_CANONICAL and it's TYPE_CANONICAL? I would expect them to be the same. Jason
Re: PR54442 build_qualified_type produces a non-canonical type
On Mon, 9 Jun 2014, Jason Merrill wrote: On 06/09/2014 10:18 AM, Marc Glisse wrote: I doubt the patch can be wrong, but it may be that this is a situation that is not supposed to happen and should be fixed elsewhere? Seems likely. What is the difference between the type returned from build_qualified_type (TYPE_CANONICAL and it's TYPE_CANONICAL? I would expect them to be the same. throws tree_list 0x7660e5c8 purpose integer_cst 0x764d6ba0 constant 1 (in what build_qualified_type returns) -- Marc Glisse
Re: [C++11, C++14 PATCH 3/4] Support for SD-6: SG10 Feature Test Recommendations: libstdc++-v3
On 9 June 2014 15:20, Ed Smith-Rowland wrote: This is the second round of the SD-6 support series. I believe I have answered everyones concerns. Several test suite adjustments were added. Built and tested on x86_64-linux. OK? This libstdc++ part is OK, assuming the other parts get approval.
Re: [C++11, C++14 PATCH 1/4] Support for SD-6: SG10 Feature Test Recommendations: libcpp
On 06/09/2014 10:20 AM, Ed Smith-Rowland wrote:
+ if (token-type == CPP_OPEN_PAREN)
+{
+ paren = true;
+ token = cpp_get_token (pfile);
+}
+ if (token-type == CPP_STRING || token-type == CPP_HEADER_NAME)
Let's add a blank line between the ifs since it's not an else if. OK
with that change.
Jason
Re: [C++11, C++14 PATCH 2/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/c-family
On 06/09/2014 10:20 AM, Ed Smith-Rowland wrote:
+ if (cxx_dialect cxx11)
+ {
+ /* Set feature test macros for C++14 */
+ cpp_define (pfile, __cpp_binary_literals=201304);
+ cpp_define (pfile, __cpp_init_captures=201304);
...
+ cpp_define (pfile, __cpp_runtime_arrays=201304);
Again, these are supported in other cxx_dialect modes, though you
probably want to control the definition based on the strict conformance
flags (pedantic/flag_iso).
Jason
Re: [C++11, C++14 PATCH 4/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/testsuite
On 06/09/2014 10:21 AM, Ed Smith-Rowland wrote: +// TODO: Change = to when C++14 constexpr goes in. +#ifdef __cpp_constexpr +# if __cpp_constexpr = 201304 +#error __cpp_constexpr +# endif +#endif How is this passing currently? 200704 = 201304, so I would expect this to error. +#ifndef __cpp_unicode_characters +# error __cpp_unicode_characters +#endif Don't we want to test for the correct value of all these macros? Jason
Re: PR54442 build_qualified_type produces a non-canonical type
On 06/09/2014 10:32 AM, Marc Glisse wrote: On Mon, 9 Jun 2014, Jason Merrill wrote: On 06/09/2014 10:18 AM, Marc Glisse wrote: I doubt the patch can be wrong, but it may be that this is a situation that is not supposed to happen and should be fixed elsewhere? Seems likely. What is the difference between the type returned from build_qualified_type (TYPE_CANONICAL and it's TYPE_CANONICAL? I would expect them to be the same. throws tree_list 0x7660e5c8 purpose integer_cst 0x764d6ba0 constant 1 (in what build_qualified_type returns) I guess that makes sense, given that the exception specification isn't really part of the type. The patch is OK. Jason
Re: [C PATCH] Use inform for near initialization for (PR c/36446)
On Mon, 9 Jun 2014, Marek Polacek wrote: It seems that (near initialization for ) message should be a note: message rather than error/warning. This patch changes error_at/warning calls to inform and fixes the testsuite fallout. Tested x86_64-unknown-linux-gnu, ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC (second try)
Build_check_stmt is now unified for const/variable lengths
but I'd still prefer to treat the use_calls case specially
because calling single __asan_loadN is more space-efficient
than emitting two separate calls with a length check.
That is not what I meant.
1) instrument_mem_region_access/instrument_strlen should use a single
build_check_stmt call instead of two that they do now,
both for use_calls case and !use_calls case, the difference
is just that instrument_mem_region_access needs to guard
it against len == 0, while for use_calls it doesn't have to,
it seems __asan_{load,store}N handles length of 0 correctly
(still, the caller shouldn't update_mem_ref_hash_table
if length might be zero, even in the use_calls case)
2) passing always a tree length to build_check_stmt and then
recreating size_in_bytes out of it is ugly, just add a new
tree parameter, if it is non-NULL, the length is variable,
and real_size_in_bytes should be 1, and the code additionally
has to compute length - 1 at runtime and add the result,
otherwise it just keeps adding precomputed constant
Let's check if I'm on the right way. I've attached current version. It
may have some rough edges but at least all regtests pass on x64.
Some obvious problems:
1) build_check_stmt argument list has become really long and messy;
(this could be simplified to some extent if we get rid of size_of_bytes
and non_zero_len_p and recompute them from len instead
but all other parameters seem really unavoidable)
2) we can't easily check number of instrumentations in
no-redundant-instrumentation-*.c family of tests
because memory region accesses now have single error handler
(__asan_report_load_n/store_n);
the best solution I came up with is counting all 'X 7' patterns.
3) strlen instrumentation is still using two separate calls to
build_check_stmt (due to reasons I mentioned above).
-Y
diff --git a/gcc/asan.c b/gcc/asan.c
index 3397655..fb1ddb9 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -242,6 +242,19 @@ static GTY(()) tree shadow_ptr_types[2];
/* Decl for __asan_option_detect_stack_use_after_return. */
static GTY(()) tree asan_detect_stack_use_after_return;
+/* Number of instrumentations in current function so far. */
+
+static int asan_num_accesses;
+
+/* Check whether we should replace inline instrumentation with calls. */
+
+static inline bool
+use_calls_p ()
+{
+ return ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD INT_MAX
+ asan_num_accesses = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD;
+}
+
/* Hashtable support for memory references used by gimple
statements. */
@@ -1319,7 +1332,7 @@ asan_protect_global (tree decl)
IS_STORE is either 1 (for a store) or 0 (for a load). */
static tree
-report_error_func (bool is_store, HOST_WIDE_INT size_in_bytes, bool slow_p)
+report_error_func (bool is_store, HOST_WIDE_INT size_in_bytes, int *nargs)
{
static enum built_in_function report[2][6]
= { { BUILT_IN_ASAN_REPORT_LOAD1, BUILT_IN_ASAN_REPORT_LOAD2,
@@ -1328,13 +1341,37 @@ report_error_func (bool is_store, HOST_WIDE_INT size_in_bytes, bool slow_p)
{ BUILT_IN_ASAN_REPORT_STORE1, BUILT_IN_ASAN_REPORT_STORE2,
BUILT_IN_ASAN_REPORT_STORE4, BUILT_IN_ASAN_REPORT_STORE8,
BUILT_IN_ASAN_REPORT_STORE16, BUILT_IN_ASAN_REPORT_STORE_N } };
- if ((size_in_bytes (size_in_bytes - 1)) != 0
- || size_in_bytes 16
- || slow_p)
-return builtin_decl_implicit (report[is_store][5]);
+ if (size_in_bytes == -1)
+{
+ *nargs = 2;
+ return builtin_decl_implicit (report[is_store][5]);
+}
+ *nargs = 1;
return builtin_decl_implicit (report[is_store][exact_log2 (size_in_bytes)]);
}
+/* Construct a function tree for __asan_{load,store}{1,2,4,8,16,_n}.
+ IS_STORE is either 1 (for a store) or 0 (for a load). */
+
+static tree
+check_func (bool is_store, int size_in_bytes, int *nargs)
+{
+ static enum built_in_function check[2][6]
+= { { BUILT_IN_ASAN_LOAD1, BUILT_IN_ASAN_LOAD2,
+ BUILT_IN_ASAN_LOAD4, BUILT_IN_ASAN_LOAD8,
+ BUILT_IN_ASAN_LOAD16, BUILT_IN_ASAN_LOADN },
+ { BUILT_IN_ASAN_STORE1, BUILT_IN_ASAN_STORE2,
+ BUILT_IN_ASAN_STORE4, BUILT_IN_ASAN_STORE8,
+ BUILT_IN_ASAN_STORE16, BUILT_IN_ASAN_STOREN } };
+ if (size_in_bytes == -1)
+{
+ *nargs = 2;
+ return builtin_decl_implicit (check[is_store][5]);
+}
+ *nargs = 1;
+ return builtin_decl_implicit (check[is_store][exact_log2 (size_in_bytes)]);
+}
+
/* Split the current basic block and create a condition statement
insertion point right before or after the statement pointed to by
ITER. Return an iterator to the point at which the caller might
@@ -1494,6 +1531,76 @@ build_shadow_mem_access (gimple_stmt_iterator *gsi, location_t location,
return gimple_assign_lhs (g);
}
+/* BASE can already be an SSA_NAME; in that case, do not create a
+ new SSA_NAME for it. */
+
+static tree
+maybe_create_ssa_name (location_t loc, tree base,
Re: -finit-local-vars option
On 06/06/14 09:00, Florian Weimer wrote: The attached crude patch as an -finit-local-vars option to the C front end. If active, all local variables are initialized to zero. It is part of an experiment to assess the performance impact of local variable initialization. I'd expect impact to be minimal -- especially for objects which are SSA_NAMEs. This is not a real patch submission because the way the flag is implemented, it interferes with unused-variable warnings. I just want to archive it for posterity. This is the big issue. As is the fact that initializing to zero isn't necessarily is good/safe thing to do and may ultimately end up masking real bugs. To know the right initialization value you have to know how the object is used and it's probably outside the scope of what the compiler can determine. Really the way forward is to continue to improve the uninit variable warnings to give fewer false positives *and* to find a sane way to give uninit warnings for objects that aren't SSA_NAMEs. Jeff
Re: [PATCH, x86] Improves x86 permutation expand
On 06/09/2014 03:13 AM, Evgeny Stupachenko wrote:
+ /* First we apply one operand permutation to the part where
+ elements stay not in their respective lanes. */
+ dcopy = *d;
+ if (which == 2)
+dcopy.op0 = dcopy.op1 = d-op1;
+ else
+dcopy.op0 = dcopy.op1 = d-op0;
+ dcopy.one_operand_p = true;
+
+ for (i = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (which == 2)
+ dcopy.perm[i] = ((e = nelt) ? (e - nelt) : e);
This is wrong for which == 1. For both cases this simplifies to
dcopy.perm[i] = e (nelt - 1);
+
+ for (i = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (which == 2)
+ dcopy1.perm[i] = ((e = nelt) ? (nelt + i) : e);
+ else
+ dcopy1.perm[i] = ((e nelt) ? i : e);
+}
This is known to be a blend, so you know the value of E.
Simplifies to
dcopy1.perm[i] = (e = nelt ? nelt + i : i);
r~
Re: [PATCH] Fix PR middle-end/61141
On 06/08/14 12:06, John David Anglin wrote:
On 4-Jun-14, at 3:38 AM, Jeff Law wrote:
On 05/24/14 12:39, John David Anglin wrote:
The insns are being deleted in final after the assembly output has
being done. So, for example, pa_output_call is
never called with a delayed branch sequence containing a
NOTE_INSN_DELETED.
OK. That's good to know. I scanned final and final_scan_insn and see
a couple places where we delete insns, but if I'm reading the code
correctly, they would result in seeing the NOTE_INSN_DELETED rather
than a real insn in the output routines.
So what code during final is deleting these insns?
It's the PA backend. For example,
/* If this isn't a sibcall, we put the load of %r27 into the
delay slot. We can't do this in a sibcall as we don't
have a second call-clobbered scratch register available. */
if (seq_length != 0
! JUMP_P (NEXT_INSN (insn))
!sibcall)
{
final_scan_insn (NEXT_INSN (insn), asm_out_file,
optimize, 0, NULL);
/* Now delete the delay insn. */
SET_INSN_DELETED (NEXT_INSN (insn));
delay_insn_deleted = 1;
}
The insn is deleted so that it won't be emitted again. This is done in
a bunch
of places.
What's new is the verification after assembly output.
Right. Thanks for the analysis. I know it takes significant time.
The original patch is fine and I've installed it on your behalf.
Thanks again,
Jeff
Re: [PATCH] Trust TREE_ADDRESSABLE
I wonder if we want toupdate the frontends to set addressable flag with new sense or we want symtab to simple set addressable on all global symbols or invent a new flag. I would preffer the first case - it seems to make most sense to me. I think you need to explain why this change is desirable/necessary for LTO, this would be a good starting point. As for setting TREE_ADDRESSABLE on every single global symbol in every single front-end, why not, but this seems more complicated than treating global symbols as so by default (in non-LTO mode). In non-LTO compilation I think it would allows us to optimize bettter in the case address of the global symbol can not be taken by the other unit or it can not escape back to current unit. For C/C++ this would be for runtime generates symbols, like for gcov runtime (well if our initialization was not implemented in a way taking address of everything). For non-C languages I expect there are cases where you just can't take address of a given object. For LTO compilation this is useful for optimizing cases where variable is static at whole program optimization time, but it becomes hidden by partitioning and at whole program time we figure out its address is not taken. Honza
Re: [PATCH 2/5] c_diagnostic_ignored_function hack
Manuel == Manuel López-Ibáñez lopeziba...@gmail.com writes: Tom This patch makes it possible to suppress the function-name display in Tom a straightforward way: it adds a new global which the plugin can set Tom to declare the name of the dummy function. Manuel Otherwise, why not override the lang_hook itself? This way the plugin Manuel can provide its own lang_hook so that your proposed Manuel c_print_error_function lives in the plugin itself. I've changed my local tree to use this approach, as it seemed simplest. Thanks for the suggestion. Tom
Re: [PATCH] Fix PR middle-end/61141
On 6/9/2014 12:41 PM, Jeff Law wrote: What's new is the verification after assembly output. Right. Thanks for the analysis. I know it takes significant time. Not a problem. Thanks for installing the change. Dave -- John David Anglindave.ang...@bell.net
Re: [PATCH 4/5] add gcc/gdb interface files
On 06/05/14 19:54, Tom Tromey wrote: Jakub == Jakub Jelinek ja...@redhat.com writes: Jakub Another possibility would be to give the macros twice as many arguments Jakub as there are parameters and just through the odd arguments away when Jakub expanding to the template parameters. That would mean you write Jakub GCC_METHOD7 (gcc_decl, build_decl, Jakubconst char *, name, Jakubenum gcc_c_symbol_kind, sym_kind, Jakubconst char *, substitution_name, Jakubgcc_address, address, Jakubconst char *, filename, Jakubunsigned int, line_number); Jakub though it isn't very nice either, guess I'm bikeshedding... ;) Bikeshed away, I don't mind ... in this case :) I'm not super fond of this idea, though, I think because the names are all useless -- they don't have any meaning to any of the actual uses, they are just there for documentation purposes. One other random idea was something like: GCC_METHOD7 (gcc_decl, build_decl, const char *, /* Argument NAME. */ enum gcc_c_symbol_kind, /* Argument SYM_KIND. */ Works for me. jeff
[C++ Patch] PR 22556
Hi,
I believe this very old issue simply boils down to using comptypes with
COMPARE_REDECLARATION instead of same_type_p (comp_array_types is
careful with TYPE_DOMAINs).
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-06-09 Paolo Carlini paolo.carl...@oracle.com
PR c++/22556
* name-lookup.c (pushdecl_maybe_friend_1): Use comptypes.
/testsuite
2014-06-09 Paolo Carlini paolo.carl...@oracle.com
PR c++/22556
* g++.dg/other/redecl3.C: New.
Index: cp/name-lookup.c
===
--- cp/name-lookup.c(revision 211370)
+++ cp/name-lookup.c(working copy)
@@ -974,7 +974,8 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
(DECL_EXTERNAL (decl) || TREE_PUBLIC (decl))
/* If different sort of thing, we already gave an error. */
TREE_CODE (decl) == TREE_CODE (x)
- !same_type_p (TREE_TYPE (x), TREE_TYPE (decl)))
+ !comptypes (TREE_TYPE (x), TREE_TYPE (decl),
+COMPARE_REDECLARATION))
{
if (permerror (input_location, type mismatch with previous
external decl of %q#D, x))
Index: testsuite/g++.dg/other/redecl3.C
===
--- testsuite/g++.dg/other/redecl3.C(revision 0)
+++ testsuite/g++.dg/other/redecl3.C(working copy)
@@ -0,0 +1,9 @@
+// PR c++/22556
+
+extern int foo[]; // OK
+int foo[] = {1,2,3};
+extern int foo[]; // OK
+
+void bar(){
+ extern int foo[]; // g++: ERROR -- SHOULD BE OK
+}
Re: [PATCH] proposed fix for bug # 61144
On Mon, Jun 09, 2014 at 03:40:44PM +0400, Alexander Monakov wrote:
On Fri, 6 Jun 2014, Rich Felker wrote:
On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote:
On 05/21/14 21:59, Rich Felker wrote:
On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote:
On Wed, May 21, 2014 at 3:59 AM, Rich Felker dal...@libc.org wrote:
Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc
due to aggressive and semantically-incorrect constant folding of weak
aliases. The attached patch seems to fix the issue. A weak alias
should never be a candidate for constant folding because it may always
be replaced by a strong definition from another translation unit.
For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
I do not have a copyright assignment on file but this patch should be
sufficiently trivial not to require it.
Please add a testcase. Also I wonder why it isn't better to generalize
How should a testcase be done? On the PR there's a testcase that shows
the problem in the generated code, but no automated check for it.
Testing this is actually a bit of a pain unless you're allowed to run
the generated program.
You can run the test program. Have it exit (0) on success, abort ()
on failure if at all possible. Then drop the test source file into
gcc/testsuite/gcc.c-torture/execute/pr61144.c
The test needs to be two translation units linked together: one with
a weak definition of the object as 0, and the other with a strong
definition. The test should show the weak value being used rather than
the strong one. But I'm not sure how this should be integrated with
the build process.
Please have a look at gcc/testsuite/gcc.dg/special/wkali-2{,a,b}.c. This is a
three-TU test for weak aliases, so you should be able to very easily adjust it
for this bug.
Are the attached files acceptable?
Rich
/* { dg-do run } */
/* { dg-require-weak } */
/* { dg-require-alias } */
/* { dg-additional-sources wkali-3a.c } */
#include stdlib.h
static int dummy = 0;
extern int foo __attribute__((__weak__, __alias__(dummy)));
int main(void) {
if (foo)
exit(0);
else
abort();
}
/* { dg-do run } */
int foo = 1;
Re: [C++ Patch] PR 22556
OK. Jason
Re: [PATCH,MIPS] Remove unused code relating to reloading fcc
Matthew Fortune matthew.fort...@imgtec.com writes: This is a small clean-up patch to remove code relating to reloading or moving mips fcc registers. At some point in the past these registers were allocated as part of register allocation but they are now statically allocated in the backend in a round robin fashion. The code for reloading them is therefore not necessary any more. The move costs are also irrelevant so are replaced with a comment instead (but the cases can just be deleted if that is preferred). I think removing the cases would be better. OK with that change. Thanks for cleaning this up. Richard
Re: [PATCH, i386]: Correctly handle maximum size of stringop algorithm in decide_alg
Ping.
On Mon, Jun 2, 2014 at 11:12 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
A problem was uncovered by -march=corei7 -mtune=intel -m32 with
i386/memcpy-[23] testcase in decide_alg subroutine [1]. Although the
max size of the transfer was known, the memcpy was not inlined, as
expected by the testcase.
The core of the problem can be seen in the definition of 32bit
intel_memcpy stringop alg:
{libcall, {{11, loop, false}, {-1, rep_prefix_4_byte, false}}},
Please note that the last algorithm sets its maximum size to -1,
unlimited. However, in decide_alg, the same number also signals that
no algorithm sets its size, so expected_size is never calculated. In
the loop that sets maximal size for user defined algorithm, it is
assumed that -1 belongs exclusively to libcall, which is not the
case in the above intel_memcpy definition:
if (candidate != libcall candidate usable)
max = algs-size[i].max;
When the last non-libcall algorithm sets its maximum to -1 (aka
unlimited), this value fails following test:
if (max 1 (unsigned HOST_WIDE_INT) max = max_size
and expected_size is never calculated.
Attached patch fixes this oversight, so -1 means unlimited size and
0 means that size was never set. The patch also considers these two
special values when choosing a maximum size for dynamic check.
2014-06-02 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (decide_alg): Correctly handle maximum size of
stringop algorithm.
Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
{,-m32}, also with
RUNTESTFLAGS=--target_board=unix/-march=corei7/-mtune=intel\{,-m32\},
where it fixes both memcpy failures from [1].
[1] https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg00127.html
Jan, can you please review the patch, to check if the logic is OK?
Uros.
Index: ChangeLog
===
--- ChangeLog (revision 211140)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2014-06-02 Uros Bizjak ubiz...@gmail.com
+
+ * config/i386/i386.c (decide_alg): Correctly handle maximum size of
+ stringop algorithm.
+
2014-06-02 Marcus Shawcroft marcus.shawcr...@arm.com
* config/aarch64/aarch64.md (set_fpcr): Drop ISB after FPCR write.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 211140)
+++ config/i386/i386.c (working copy)
@@ -23828,7 +23828,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT exp
{
const struct stringop_algs * algs;
bool optimize_for_speed;
- int max = -1;
+ int max = 0;
const struct processor_costs *cost;
int i;
bool any_alg_usable_p = false;
@@ -23866,7 +23866,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT exp
/* If expected size is not known but max size is small enough
so inline version is a win, set expected size into
the range. */
- if (max 1 (unsigned HOST_WIDE_INT) max = max_size
+ if (((max 1 (unsigned HOST_WIDE_INT) max = max_size) || max == -1)
expected_size == -1)
expected_size = min_size / 2 + max_size / 2;
@@ -23955,7 +23955,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT exp
*dynamic_check = 128;
return loop_1_byte;
}
- if (max == -1)
+ if (max = 0)
max = 4096;
alg = decide_alg (count, max / 2, min_size, max_size, memset,
zero_memset, dynamic_check, noalign);
Re: Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators
Dear Dominique, Without the patch applied, trunk shows 360 bytes definitely missing in 3 blocks for the original testcase and 9 out of 92 allocs did not have corresponding frees. WIth the patch, I get: ==20527== ==20527== HEAP SUMMARY: ==20527== in use at exit: 0 bytes in 0 blocks ==20527== total heap usage: 92 allocs, 92 frees, 54,502 bytes allocated ==20527== ==20527== All heap blocks were freed -- no leaks are possible ==20527== ==20527== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) --20527-- --20527-- used_suppression: 2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a /usr/lib64/valgrind/default.supp:1286 ==20527== ==20527== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) Not only that, it bootstraps and regtests OK. So it definitely does what it is advertised to do :-) OK for trunk and, I would suggest 4.9. Cheers Paul PS ifort 13.01 has exactly the same fault On 9 June 2014 14:59, Dominique Dhumieres domi...@lps.ens.fr wrote: Patch posted at https://gcc.gnu.org/ml/fortran/2014-05/msg00155.html. TIA Dominique -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [PATCH, x86] Improves x86 permutation expand
Nice catch.
Patch with corresponding changes:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8827256..0b80354 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -43185,6 +43185,80 @@ expand_vec_perm_palignr (struct expand_vec_perm_d *d)
return ok;
}
+/* A subroutine of ix86_expand_vec_perm_const_1. Try to simplify
+ the permutation using the SSE4_1 pblendv instruction. Potentially
+ reduces permutaion from 2 pshufb and or to 1 pshufb and pblendv. */
+
+static bool
+expand_vec_perm_pblendv (struct expand_vec_perm_d *d)
+{
+ unsigned i, which, nelt = d-nelt;
+ struct expand_vec_perm_d dcopy, dcopy1;
+ enum machine_mode vmode = d-vmode;
+ bool ok;
+
+ /* Use the same checks as in expand_vec_perm_blend, but skipping
+ AVX2 as it requires more than 2 instructions for general case. */
+ if (d-one_operand_p)
+return false;
+ if (TARGET_AVX (vmode == V4DFmode || vmode == V8SFmode))
+;
+ else if (TARGET_SSE4_1 GET_MODE_SIZE (vmode) == 16)
+;
+ else
+return false;
+
+ /* Figure out where permutation elements stay not in their
+ respective lanes. */
+ for (i = 0, which = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (e != i)
+ which |= (e nelt ? 1 : 2);
+}
+ /* We can pblend the part where elements stay not in their
+ respective lanes only when these elements are all in one
+ half of a permutation.
+ {0 1 8 3 4 5 9 7} is ok as 8, 9 are at not at their respective
+ lanes, but both 8 and 9 = 8
+ {0 1 8 3 4 5 2 7} is not ok as 2 and 8 are not at their
+ respective lanes and 8 = 8, but 2 not. */
+ if (which != 1 which != 2)
+return false;
+ if (d-testing_p)
+return true;
+
+ /* First we apply one operand permutation to the part where
+ elements stay not in their respective lanes. */
+ dcopy = *d;
+ if (which == 2)
+dcopy.op0 = dcopy.op1 = d-op1;
+ else
+dcopy.op0 = dcopy.op1 = d-op0;
+ dcopy.one_operand_p = true;
+
+ for (i = 0; i nelt; ++i)
+dcopy.perm[i] = d-perm[i] (nelt - 1);
+
+ ok = expand_vec_perm_1 (dcopy);
+ gcc_assert (ok);
+
+ /* Next we put permuted elements into thier positions. */
+ dcopy1 = *d;
+ if (which == 2)
+dcopy1.op1 = dcopy.target;
+ else
+dcopy1.op0 = dcopy.target;
+
+ for (i = 0; i nelt; ++i)
+dcopy1.perm[i] = ((d-perm[i] = nelt) ? (nelt + i) : i);
+
+ ok = expand_vec_perm_blend (dcopy1);
+ gcc_assert (ok);
+
+ return true;
+}
+
static bool expand_vec_perm_interleave3 (struct expand_vec_perm_d *d);
/* A subroutine of ix86_expand_vec_perm_builtin_1. Try to simplify
@@ -44557,6 +44631,9 @@ ix86_expand_vec_perm_const_1 (struct
expand_vec_perm_d *d)
if (expand_vec_perm_vperm2f128 (d))
return true;
+ if (expand_vec_perm_pblendv (d))
+return true;
+
/* Try sequences of three instructions. */
if (expand_vec_perm_2vperm2f128_vshuf (d))
On Mon, Jun 9, 2014 at 8:30 PM, Richard Henderson r...@redhat.com wrote:
On 06/09/2014 03:13 AM, Evgeny Stupachenko wrote:
+ /* First we apply one operand permutation to the part where
+ elements stay not in their respective lanes. */
+ dcopy = *d;
+ if (which == 2)
+dcopy.op0 = dcopy.op1 = d-op1;
+ else
+dcopy.op0 = dcopy.op1 = d-op0;
+ dcopy.one_operand_p = true;
+
+ for (i = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (which == 2)
+ dcopy.perm[i] = ((e = nelt) ? (e - nelt) : e);
This is wrong for which == 1. For both cases this simplifies to
dcopy.perm[i] = e (nelt - 1);
+
+ for (i = 0; i nelt; ++i)
+{
+ unsigned e = d-perm[i];
+ if (which == 2)
+ dcopy1.perm[i] = ((e = nelt) ? (nelt + i) : e);
+ else
+ dcopy1.perm[i] = ((e nelt) ? i : e);
+}
This is known to be a blend, so you know the value of E.
Simplifies to
dcopy1.perm[i] = (e = nelt ? nelt + i : i);
r~
Re: RFA: Rework FOR_BB_INSNS iterators
Steven Bosscher stevenb@gmail.com writes:
On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
The two parts of the loop condition are really handling two different
kinds of block: ones like entry and exit that are completely empty
and normal ones that have at least a block note. There's no real
need to check for null INSNs in normal blocks.
Block notes should go away some day, they're just remains of a time
when there was no actual CFG in the compiler.
Yeah. I suppose when that happens empty blocks would look just like
entry and exit as far as these iterators go.
Also, refetching NEXT_INSN (BB_END (BB)) for each iteration can be expensive.
If we're prepared to say that the loop body can't insert instructions
for another block immediately after BB_END,
This can happen with block_label() if e.g. a new jump is inserted
for one reason or another. Not very likely for passes working in
cfglayout mode, but post-RA there may be places that need this
(splitters, peepholes, machine dependent reorgs, etc.).
So even if we're prepared to say what you suggest, I don't think you
can easily enforce it.
Probably true. But if we want to allow insertions after BB_END,
we need to make FOR_BB_INSNS_SAFE handle that for INSN == BB_END too.
The alternative definition:
for (rtx INSN = BB_HEAD (BB), INSN##_cond_ = INSN, INSN##_next_; \
INSN##_cond_ \
(INSN##_next_ = NEXT_INSN (INSN), \
INSN##_cond_ = BB_END (BB),\
true); \
INSN##_cond_ = (INSN == INSN##_cond_ ? NULL_RTX : (rtx) 1), \
INSN = INSN##_next_)
works too. It isn't quite as fast, but obviously correctness comes first.
It's easier to change these macros if they define the INSN variables
themselves.
If you're going to hack these iterators anyway (much appreciated BTW),
I suggest to make them similar to the gsi, loop, edge, and bitmap
iterators: A new insn_iterator structure to hold the variables and
static inline functions wrapped in the macros. This will also be
helpful if (when) we ever manage to make the type for an insn a
non-rtx...
Well, with this and...
+/* For iterating over insns in a basic block. The iterator allows the loop
+ body to delete INSN. It also ignores any instructions that the body
+ inserts between INSN and the following instruction. */
+#define FOR_BB_INSNS(BB, INSN) \
+ for (rtx INSN = BB_HEAD (BB), INSN##_cond_ = INSN, INSN##_next_, \
+ INSN##_end_ = INSN ? NEXT_INSN (BB_END (BB)) : NULL_RTX; \
+ INSN##_cond_ (INSN##_next_ = NEXT_INSN (INSN), true); \
+ INSN = INSN##_next_,\
+ INSN##_cond_ = (INSN != INSN##_end_ ? (rtx) 1 : NULL_RTX))
This just makes my eyes hurt...
What about cases where a FOR_BB_INSNS is terminated before reaching
the end of a basic block, and you need to know at what insn you
stopped? Up to now, you could do:
rtx insn; basic_block bb;
FOR_BB_INSNS (bb, insn)
{
... // do stuff
if (something) break;
}
do_something_with (insn);
Looks like this is no longer possible with the implementation of
FOR_BB_INSNS of your patch.
...this I suppose it depends where we want to go with these iterators.
I'm hoping eventually we'll move to C++11, where the natural way of
writing the loop would be:
for (rtx insn : bb-insns ())
(Or auto * instead of rtx if you prefer.)
And I think the idiom of having the FOR_* macro define the iterator
variable is much closer to that than:
rtx insn;
FOR_BB_INSNS (iter, bb, insn)
would be.
It's true that you can't leave insn with a signficant value after
the loop, but no current code wants to do that. Personally I like
the fact that loops that do want to set a final value have to make
that explicit. When the vast majority (currently all) instances of:
FOR_BB_INSNS (bb, insn)
treat insn as local to the loop, it's helpful when the exceptions
are obvious.
I think if anything the patch would make it easier to change the
type of insns to something other than rtx. It would just mean changing
the rtx at the start of the two for loops to the new type,
whereas at the moment you would need to change all the separate
rtx insns. (In particular, it's common for insn to be defined
on the same line as other rtx variables that might need to stay
as rtxes after the change.)
Thanks,
Richard
Re: [PATCH, x86] Improves x86 permutation expand
On 06/09/2014 12:10 PM, Evgeny Stupachenko wrote: Nice catch. Patch with corresponding changes: Looks ok with an appropriate changelog. r~
Re: [PATCH, i386]: Correctly handle maximum size of stringop algorithm in decide_alg
On 06/02/2014 02:32 PM, Uros Bizjak wrote: + * config/i386/i386.c (decide_alg): Correctly handle maximum size of + stringop algorithm. Looks good. r~
Re: libgo patch committed: Merge from revision 18783 of master
On 06/04/14 18:28:17, Ian Lance Taylor wrote:
I have committed a patch to libgo to merge from revision
18783:00cce3a34d7e of the master library.
Based on trunk rev. 211365, we're seeing this warning:
libgo/runtime/chan.c:484:7: error: ‘received’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
bool received;
^
Here:
481 _Bool
482 runtime_chanrecv2(ChanType *t, Hchan* c, byte* v)
483 {
484 bool received;
485
486 chanrecv(t, c, v, true, received);
487 return received;
488 }
Re: [PATCH, x86] Improves x86 permutation expand
On Mon, Jun 9, 2014 at 12:49 PM, Richard Henderson r...@redhat.com wrote: On 06/09/2014 12:10 PM, Evgeny Stupachenko wrote: Nice catch. Patch with corresponding changes: Looks ok with an appropriate changelog. It will be nice to include testcases to cover those changes. -- H.J.
RFC: C++ PATCH to remove -fabi-version=1 support
I'm updating -Wabi to allow for warnings about changes between a
previous ABI version and the currently selected one, and rather than
adjust all the warnings for -fabi-version=1 I'd like to tear it out. It
has now been 10 years since GCC 3.4.
Any thoughts?
commit a1a98ba5d18a57832ea1f3df1cc1f5f9eeb621a1
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 9 16:41:07 2014 -0400
gcc/c-family/
* c.opt (fabi-compat-version): New.
* c-opts.c (c_common_handle_option): Disallow -fabi-compat-version=1.
(c_common_post_options): Set flag_abi_compat_version.
* c-common.h (abi_version_crosses): New.
gcc/cp/
* call.c (convert_arg_to_ellipsis): Use abi_version_crosses.
* mangle.c (write_type, write_expression): Likewise.
(write_template_arg): Likewise.
(finish_mangling_internal): Adjust -Wabi warning.
(mangle_decl): Make alias based on flag_abi_compat_version.
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 83d5dee..6bf4051 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -619,6 +619,13 @@ extern const char *constant_string_class_name;
/* C++ language option variables. */
+/* Return TRUE if one of {flag_abi_version,flag_abi_compat_version} is
+ less than N and the other is at least N, for use by -Wabi. */
+#define abi_version_crosses(N) \
+ (abi_version_at_least(N) \
+ != (flag_abi_compat_version == 0 \
+ || flag_abi_compat_version = (N)))
+
/* Nonzero means generate separate instantiation control files and
juggle them at link time. */
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 4307507..8ff66a6 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -465,6 +465,15 @@ c_common_handle_option (size_t scode, const char *arg, int value,
}
break;
+case OPT_fabi_compat_version_:
+ if (value == 1)
+ {
+ /* -fabi-version=1 support was removed after GCC 4.9. */
+ warning (0, %qs is no longer supported, option-opt_text);
+ flag_abi_compat_version = 2;
+ }
+ break;
+
case OPT_fcanonical_system_headers:
cpp_opts-canonical_system_headers = value;
break;
@@ -919,6 +928,10 @@ c_common_post_options (const char **pfilename)
if (flag_declone_ctor_dtor == -1)
flag_declone_ctor_dtor = optimize_size;
+ /* Check compatibility with ABI version 2 (3.4-4.9) by default. */
+ if (flag_abi_compat_version == -1)
+flag_abi_compat_version = (flag_abi_version == 0 ? 2 : 0);
+
if (cxx_dialect = cxx11)
{
/* If we're allowing C++0x constructs, don't warn about C++98
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 76e67d7..de5d555 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -845,6 +845,10 @@ d
C ObjC C++ ObjC++ Joined
; Documented in common.opt. FIXME - what about -dI, -dD, -dN and -dD?
+fabi-compat-version=
+C++ ObjC++ Joined RejectNegative UInteger Var(flag_abi_compat_version) Init(-1)
+The version of the C++ ABI used for -Wabi warnings and link compatibility aliases
+
faccess-control
C++ ObjC++ Var(flag_access_control) Init(1)
Enforce class member access control semantics
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index ac14ce2..158984e 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6508,12 +6508,14 @@ convert_arg_to_ellipsis (tree arg, tsubst_flags_t complain)
arg = null_pointer_node;
else if (INTEGRAL_OR_ENUMERATION_TYPE_P (arg_type))
{
- if (SCOPED_ENUM_P (arg_type) !abi_version_at_least (6))
+ if (SCOPED_ENUM_P (arg_type))
{
- if (complain tf_warning)
- warning_at (loc, OPT_Wabi, scoped enum %qT will not promote to an
- integral type in a future version of GCC, arg_type);
- arg = cp_convert (ENUM_UNDERLYING_TYPE (arg_type), arg, complain);
+ if (abi_version_crosses (6)
+ (complain tf_warning))
+ warning_at (loc, OPT_Wabi, scoped enum %qT stopped promoting to
+ an integral type in -fabi-version=6, arg_type);
+ if (!abi_version_at_least (6))
+ arg = cp_convert (ENUM_UNDERLYING_TYPE (arg_type), arg, complain);
}
arg = cp_perform_integral_promotions (arg, complain);
}
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 86319c6..8ed06f2 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -2012,10 +2012,9 @@ write_type (tree type)
write_char ('_');
}
else
- {
- G.need_abi_warning = 1;
- write_string (U8__vector);
- }
+ write_string (U8__vector);
+ if (abi_version_crosses (4))
+ G.need_abi_warning = 1;
write_type (TREE_TYPE (type));
break;
@@ -2030,7 +2029,7 @@ write_type (tree type)
!DECLTYPE_FOR_LAMBDA_PROXY (type));
/* In ABI 5, we stripped decltype of a plain decl. */
- if (!abi_version_at_least (5)
+ if (abi_version_crosses (5)
DECLTYPE_TYPE_ID_EXPR_OR_MEMBER_ACCESS_P (type))
{
tree expr = DECLTYPE_TYPE_EXPR (type);
@@ -2053,8 +2052,11 @@ write_type (tree type)
if (etype !type_uses_auto
Re: [PATCH] Misc Fortran OpenMP 4.0 changes (PR fortran/60928)
Jakub Jelinek wrote:
This patch deals with various smaller things:
1) -fopenmp-simd fortran support
2) ALLOCATABLE handling fixes (e.g. copyin can't assume in OpenMP 4.0
that what it copies to has the same bounds and allocation status)
3) support for scalar ALLOCATABLE in various clauses
4) support for allocatable components
5) support for ASSOCIATE names (predetermined in OpenMP 4.0)
6) diagnostics of procedure pointers in reduction, and intent(in)
pointers in various clauses that don't allow them in OpenMP 4.0
I lost a bit track. Is this now complete in terms of F2003 and the only
missing bits is the support for devices and the test case for alignment?
Or is something else pending?
Bootstrapped/regtested on x86_64-linux and i686-linux. Does this look
ok to Fortran maintainers?
I browsed the patch and didn't spot something which I don't like. Thanks
for the patch!
+ if (n-sym-attr.pointer n-sym-attr.intent == INTENT_IN)
+ switch (list)
+ {
+ case OMP_LIST_PRIVATE:
+ case OMP_LIST_LASTPRIVATE:
+ case OMP_LIST_LINEAR:
+ /* case OMP_LIST_REDUCTION: */
+ gfc_error (INTENT(IN) POINTER '%s' in %s clause at %L,
+n-sym-name, name, where);
Why is OMP_LIST_REDUCTION commented?
@@ -822,6 +825,8 @@ struct GTY(()) lang_decl {
tree span;
/* For assumed-shape coarrays. */
tree token, caf_offset;
+ unsigned int scalar_allocatable : 1;
+ unsigned int scalar_pointer : 1;
};
I think this flag can also be used in dwarf2out for to set
DW_AT_allocated/DW_AT_associated [cf. PR59438 (a)], which would be nice.
Does one need to take any care with LTO for either OpenMP or DWARF
symbols? (I think one don't as it comes later, but I might have missed
some fine print.)
Tobias
PS: gdb is about to get proper support for Fortran arrays with
descriptor, see patch set at
https://sourceware.org/ml/gdb-patches/2014-06/msg00108.html [Joel
intents to review it tomorrow or on Wednesday].
Re: [PATCH] Misc Fortran OpenMP 4.0 changes (PR fortran/60928)
On Mon, Jun 09, 2014 at 11:49:50PM +0200, Tobias Burnus wrote:
I lost a bit track. Is this now complete in terms of F2003 and the only
missing bits is the support for devices and the test case for alignment? Or
is something else pending?
I have still some pending questions with omp lang committee.
Some are related to UDRs, some ASSOCIATE related questions (about
copyprivate e.g.), what does it mean if POINTER shows up in reduction
clause, I think we don't handle array linear right now and there are some
questions related to that.
+case OMP_LIST_PRIVATE:
+case OMP_LIST_LASTPRIVATE:
+case OMP_LIST_LINEAR:
+/* case OMP_LIST_REDUCTION: */
+ gfc_error (INTENT(IN) POINTER '%s' in %s clause at %L,
+ n-sym-name, name, where);
Why is OMP_LIST_REDUCTION commented?
See above, still don't know what pointer reduction should really mean.
@@ -822,6 +825,8 @@ struct GTY(()) lang_decl {
tree span;
/* For assumed-shape coarrays. */
tree token, caf_offset;
+ unsigned int scalar_allocatable : 1;
+ unsigned int scalar_pointer : 1;
};
I think this flag can also be used in dwarf2out for to set
DW_AT_allocated/DW_AT_associated [cf. PR59438 (a)], which would be nice.
Does one need to take any care with LTO for either OpenMP or DWARF symbols?
(I think one don't as it comes later, but I might have missed some fine
print.)
Yes, supposedly a langhook could handle this, similarly to how e.g.
the get_array_descr_info langhook handles it (and, LTO doesn't handle
the Fortran arrays yet either). But, the array langhook can't be used for
this, because it works on types rather than decls. In DWARF the attributes
belong on the type, so supposedly dwarf2out.c when langhook says some decl
is allocatable or associated should create a DW_AT_type variant for it with
that attribute set.
Jakub
Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations
Ping.
On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote:
Optimize access to globals with -fpie, x86_64 only:
Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the
module
using the GOT. This is two instructions, one to get the address of the
global
from the GOT and the other to get the value. If it turns out that the global
gets defined in the executable at link-time, it still needs to go through the
GOT as it is too late then to generate a direct access.
Examples:
foo.cc
--
int a_glob;
int main () {
return a_glob; // defined in this file
}
With -O2 -fpie -pie, the generated code directly accesses the global via
PC-relative insn:
5e0 main:
mov0x165a(%rip),%eax# 1c40 a_glob
foo.cc
--
extern int a_glob;
int main () {
return a_glob; // defined in this file
}
With -O2 -fpie -pie, the generated code accesses global via GOT using two
memory loads:
6f0 main:
mov0x1609(%rip),%rax # 1d00 _DYNAMIC+0x230
mov(%rax),%eax
This is true even if in the latter case the global was defined in the
executable through a different file.
Some experiments on google benchmarks shows that the extra memory loads
affects
performance by 1% to 5%.
Solution - Copy Relocations:
When the linker supports copy relocations, GCC can always assume that the
global will be defined in the executable. For globals that are truly extern
(come from shared objects), the linker will create copy relocations and have
them defined in the executable. Result is that no global access needs to go
through the GOT and hence improves performance.
This patch to the gold linker :
https://sourceware.org/ml/binutils/2014-05/msg00092.html
submitted recently allows gold to generate copy relocations for -pie mode
when
necessary.
I have added option -mld-pie-copyrelocs which when combined with -fpie would
do
this. Note that the BFD linker does not support pie copyrelocs yet and this
option cannot be used there.
Please review.
ChangeLog:
* config/i386/i36.opt (mld-pie-copyrelocs): New option.
* config/i386/i386.c (legitimate_pic_address_disp_p): Check if this
address is still legitimate in the presence of copy relocations
and -fpie.
* testsuite/gcc.target/i386/ld-pie-copyrelocs-1.c: New test.
* testsuite/gcc.target/i386/ld-pie-copyrelocs-2.c: New test.
Patch attached.
Thanks
Sri
Re: [PATCH] C++ thunk section names
Ping. On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, I would like this patch reviewed and considered for commit when Stage 1 is active again. Patch Description: A C++ thunk's section name is set to be the same as the original function's section name for which the thunk was created in order to place the two together. This is done in cp/method.c in function use_thunk. However, with function reordering turned on, the original function's section name can change to something like .text.hot.orginal or .text.unlikely.original in function default_function_section in varasm.c based on the node count of that function. The thunk function's section name is not updated to be the same as the original here and also is not always correct to do it as the original function can be hotter than the thunk. I have created a patch to not name the thunk function's section to be the same as the original function when function reordering is enabled. Thanks Sri
[C++ Patch] PR 19200
Hi,
another old issue, which should be also relatively easy to fix. The
problem is clear, for:
struct S {
struct T{};
friend void S(T);
};
cp_parser_direct_declarator sees a name which matches that of a kosher
constructor and sets sfk_constructor. Then things go quickly wrong
because a constructor cannot have a return type specification, thus
check_special_function_return_type, called by grokdeclarator, complains.
I tried various ideas (eg, I'm also attaching an alternate approach
passing down the friend information from cp_parser_member_declaration to
cp_parser_direct_declarator), but, all in all, I propose to adjust
things in grodeclarator itself. Tested x86_64-linux.
Thanks!
Paolo.
//
Index: cp/decl.c
===
--- cp/decl.c (revision 211389)
+++ cp/decl.c (working copy)
@@ -8774,7 +8774,8 @@ grokdeclarator (const cp_declarator *declarator,
tree type = NULL_TREE;
int longlong = 0;
int explicit_int128 = 0;
- int virtualp, explicitp, friendp, inlinep, staticp;
+ int virtualp, explicitp, inlinep, staticp;
+ int friendp = decl_spec_seq_has_spec_p (declspecs, ds_friend);
int explicit_int = 0;
int explicit_char = 0;
int defaulted_int = 0;
@@ -8880,6 +8881,26 @@ grokdeclarator (const cp_declarator *declarator,
sfk = id_declarator-declarator-u.id.sfk;
if (sfk == sfk_destructor)
flags = DTOR_FLAG;
+ else if (sfk == sfk_constructor
+ friendp
+ declspecs-type)
+ /* cp_parser_direct_declarator doesn't know about the
+ 'friend' specifier and returns sfk_constructor for
+
+ struct S {
+struct T{};
+friend void S(T);
+ };
+
+ thus adjust it here (c++/19200). Note: the return
+ type is checked because with -fpermissive we still
+ want to accept
+
+ struct S {
+struct T{};
+friend S::S(T);
+ }; */
+ sfk = sfk_none;
}
break;
@@ -9378,7 +9399,6 @@ grokdeclarator (const cp_declarator *declarator,
storage_class = sc_none;
staticp = 0;
}
- friendp = decl_spec_seq_has_spec_p (declspecs, ds_friend);
/* Issue errors about use of storage classes for parameters. */
if (decl_context == PARM)
Index: testsuite/g++.dg/parse/friend7.C
===
--- testsuite/g++.dg/parse/friend7.C(revision 211384)
+++ testsuite/g++.dg/parse/friend7.C(working copy)
@@ -17,16 +17,16 @@ struct B
struct C
{
- friend int C (); // { dg-error return type|in friend decl }
+ friend int C ();
friend int ~C ();// { dg-error return type|in friend decl }
- friend int C (const C );// { dg-error return type|in friend decl }
+ friend int C (const C );
};
struct D
{
- friend int D () {} // { dg-error return type|in friend decl }
+ friend int D () {}
friend int ~D () {} // { dg-error return type|in friend decl }
- friend int D (const D ) {} // { dg-error return type|in friend decl }
+ friend int D (const D ) {}
};
struct E
Index: testsuite/g++.dg/parse/friend9.C
===
--- testsuite/g++.dg/parse/friend9.C(revision 0)
+++ testsuite/g++.dg/parse/friend9.C(working copy)
@@ -0,0 +1,6 @@
+// PR c++/19200
+
+struct S {
+ struct T{};
+ friend void S(T);
+};
Index: cp/parser.c
===
--- cp/parser.c (revision 211384)
+++ cp/parser.c (working copy)
@@ -2078,9 +2078,9 @@ static tree cp_parser_decltype
static tree cp_parser_init_declarator
(cp_parser *, cp_decl_specifier_seq *, vecdeferred_access_check, va_gc *,
bool, bool, int, bool *, tree *);
static cp_declarator *cp_parser_declarator
- (cp_parser *, cp_parser_declarator_kind, int *, bool *, bool);
+ (cp_parser *, cp_parser_declarator_kind, int *, bool *, bool, bool);
static cp_declarator *cp_parser_direct_declarator
- (cp_parser *, cp_parser_declarator_kind, int *, bool);
+ (cp_parser *, cp_parser_declarator_kind, int *, bool, bool);
static enum tree_code cp_parser_ptr_operator
(cp_parser *, tree *, cp_cv_quals *, tree *);
static cp_cv_quals cp_parser_cv_qualifier_seq_opt
@@ -10014,7 +10014,8 @@ cp_parser_condition (cp_parser* parser)
declarator = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
/*ctor_dtor_or_conv_p=*/NULL,
/*parenthesized_p=*/NULL,
-/*member_p=*/false);
+/*member_p=*/false,
+
Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook
On 30/05/14 18:35, Ramana Radhakrishnan wrote:
+ if (!TARGET_VFP)
+return;
+
+ /* Generate the equivalence of :
s/equivalence/equivalent.
Ok with that change and if no regressions.
Hi Ramana,
Sorry, I missed the thumb1 part. There are no mrc/mcr versions of these
instructions in thumb1. So these should be conditional on not being
ARM_THUMB1.
Is this OK. Regression tested with no new refression on qemu for
arm-none-linux-gnueabi -march=armv7-a and on arm-none-linux-gnueabi
--with-mode=thumb and -march=armv5t.
Is this OK?
Thanks,
Kugan
gcc/
2014-06-10 Kugan Vivekanandarajah kug...@linaro.org
* config/arm/arm.c (arm_atomic_assign_expand_fenv): call
default_atomic_assign_expand_fenv for TARGET_THUMB1.
(arm_init_builtins) : Initialize builtins __builtins_arm_set_fpscr and
__builtins_arm_get_fpscr only when !TARGET_THUMB1.
* config/arm/vfp.md (set_fpscr): Make pattern conditional on
!TARGERT_THUMB1.
(get_fpscr) : Likewise.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f8575b9..c9f02df 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -24760,7 +24760,7 @@ arm_init_builtins (void)
if (TARGET_CRC32)
arm_init_crc32_builtins ();
- if (TARGET_VFP)
+ if (TARGET_VFP !TARGET_THUMB1)
{
tree ftype_set_fpscr
= build_function_type_list (void_type_node, unsigned_type_node, NULL);
@@ -31452,8 +31452,8 @@ arm_atomic_assign_expand_fenv (tree *hold, tree *clear,
tree *update)
tree new_fenv_var, reload_fenv, restore_fnenv;
tree update_call, atomic_feraiseexcept, hold_fnclex;
- if (!TARGET_VFP)
-return;
+ if (!TARGET_VFP || TARGET_THUMB1)
+return default_atomic_assign_expand_fenv (hold, clear, update);
/* Generate the equivalent of :
unsigned int fenv_var;
diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index a8b27bc..44d2f38 100644
--- a/gcc/config/arm/vfp.md
+++ b/gcc/config/arm/vfp.md
@@ -1325,7 +1325,7 @@
;; Write Floating-point Status and Control Register.
(define_insn set_fpscr
[(unspec_volatile [(match_operand:SI 0 register_operand r)]
VUNSPEC_SET_FPSCR)]
- TARGET_VFP
+ TARGET_VFP !TARGET_THUMB1
mcr\\tp10, 7, %0, cr1, cr0, 0\\t @SET_FPSCR
[(set_attr type mrs)])
@@ -1333,7 +1333,7 @@
(define_insn get_fpscr
[(set (match_operand:SI 0 register_operand =r)
(unspec_volatile:SI [(const_int 0)] VUNSPEC_GET_FPSCR))]
- TARGET_VFP
+ TARGET_VFP !TARGET_THUMB1
mrc\\tp10, 7, %0, cr1, cr0, 0\\t @GET_FPSCR
[(set_attr type mrs)])
Re: libgo patch committed: Merge from revision 18783 of master
On Mon, Jun 9, 2014 at 1:12 PM, Gary Funck g...@intrepid.com wrote: On 06/04/14 18:28:17, Ian Lance Taylor wrote: I have committed a patch to libgo to merge from revision 18783:00cce3a34d7e of the master library. Based on trunk rev. 211365, we're seeing this warning: libgo/runtime/chan.c:484:7: error: ‘received’ may be used uninitialized in this function [-Werror=maybe-uninitialized] bool received; ^ Thanks for the report. There is no bug here, the control flow is just too complicated for the compiler to sort out. I don't know why I'm not seeing the warning, but in any case the fix is simple. This patch bootstrapped and tested on x86_64-unknown-linux-gnu. Committed to mainline. Ian
Re: libgo patch committed: Merge from revision 18783 of master
Forgot to CC gofrontend-dev. On Mon, Jun 9, 2014 at 5:36 PM, Ian Lance Taylor i...@google.com wrote: On Mon, Jun 9, 2014 at 1:12 PM, Gary Funck g...@intrepid.com wrote: On 06/04/14 18:28:17, Ian Lance Taylor wrote: I have committed a patch to libgo to merge from revision 18783:00cce3a34d7e of the master library. Based on trunk rev. 211365, we're seeing this warning: libgo/runtime/chan.c:484:7: error: ‘received’ may be used uninitialized in this function [-Werror=maybe-uninitialized] bool received; ^ Thanks for the report. There is no bug here, the control flow is just too complicated for the compiler to sort out. I don't know why I'm not seeing the warning, but in any case the fix is simple. This patch bootstrapped and tested on x86_64-unknown-linux-gnu. Committed to mainline. Ian
Re: libgo patch committed: Merge from revision 18783 of master
And I also forgot to attach the patch. Sorry about this.
On Mon, Jun 9, 2014 at 5:37 PM, Ian Lance Taylor i...@google.com wrote:
Forgot to CC gofrontend-dev.
On Mon, Jun 9, 2014 at 5:36 PM, Ian Lance Taylor i...@google.com wrote:
On Mon, Jun 9, 2014 at 1:12 PM, Gary Funck g...@intrepid.com wrote:
On 06/04/14 18:28:17, Ian Lance Taylor wrote:
I have committed a patch to libgo to merge from revision
18783:00cce3a34d7e of the master library.
Based on trunk rev. 211365, we're seeing this warning:
libgo/runtime/chan.c:484:7: error: ‘received’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
bool received;
^
Thanks for the report. There is no bug here, the control flow is just
too complicated for the compiler to sort out. I don't know why I'm
not seeing the warning, but in any case the fix is simple. This patch
bootstrapped and tested on x86_64-unknown-linux-gnu. Committed to
mainline.
Ian
diff -r e632610ff06a libgo/runtime/chan.c
--- a/libgo/runtime/chan.c Fri Jun 06 14:52:01 2014 -0700
+++ b/libgo/runtime/chan.c Mon Jun 09 17:34:47 2014 -0700
@@ -481,7 +481,7 @@
_Bool
runtime_chanrecv2(ChanType *t, Hchan* c, byte* v)
{
- bool received;
+ bool received = false;
chanrecv(t, c, v, true, received);
return received;
Re: [C++ Patch] PR 19200
I think the parser approach is more correct.
On 06/09/2014 07:02 PM, Paolo Carlini wrote:
!TYPE_WAS_ANONYMOUS (class_type)
+ !friend_p
constructor_name_p (unqualified_name,
class_type))
But here you also need to check qualifying_scope; 'friend' does not
affect whether or not a qualified-id is a constructor.
+ friend_p
+ /* With -fpermissive we want to accept:
+ struct S {
+struct T{};
+friend S::S(T);
+ };
+
+ thus also check the return type
+ to do the right thing later in
+ cp_parser_direct_declarator. */
+decl_specifiers.type);
And then you don't need to consider decl_specifiers.type here.
Jason
[PATCH] Unchecked call to init_symbolic_number
When doing a bootstrap on x86_64-linux-gnu to test a patch I'm writing, I encountered a failure that turned out to be due to not checking the return value of init_symbolic_number in find_bswap_or_nop_load (tree-ssa-math-opts.c). The following patch fixes that and I commited it as obvious as per GCC write access policies. ChangeLog: 2014-06-09 Thomas Preud'homme thomas.preudho...@arm.com * tree-ssa-math-opts.c (find_bswap_or_nop_load): Check return value of init_symbolic_number (). diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c index a928ad9..1f011a6 100644 --- a/gcc/tree-ssa-math-opts.c +++ b/gcc/tree-ssa-math-opts.c @@ -1784,7 +1784,8 @@ find_bswap_or_nop_load (gimple stmt, tree ref, struct symbolic_number *n) if (bitsize % BITS_PER_UNIT) return false; - init_symbolic_number (n, ref); + if (!init_symbolic_number (n, ref)) +return false; n-base_addr = base_addr; n-offset = offset; n-bytepos = bitpos / BITS_PER_UNIT;
[PATCH] Fix PR61375: cancel bswap optimization when value doesn't fit in a HOST_WIDE_INT
When analyzing a bitwise AND with a constant as part of a bitwise OR,
the bswap pass stores the constant in a int64_t variable without checking
if it fits. As a result, we get ICE when the constant is an __int128 value.
This affects GCC trunk but also GCC 4.9 and 4.8 (and possibly earlier
version as well).
ChangeLog are changed as follows:
*** gcc/ChangeLog ***
2014-06-05 Thomas Preud'homme thomas.preudho...@arm.com
PR tree-optimization/61375
* tree-ssa-math-opts.c (init_symbolic_number): Cancel optimization if
symbolic number cannot be represented in an unsigned HOST_WIDE_INT.
(find_bswap_or_nop_1): Likewise.
*** gcc/testsuite/ChangeLog ***
2014-06-05 Thomas Preud'homme thomas.preudho...@arm.com
PR tree-optimization/61375
* gcc.c-torture/execute/pr61375-1.c: New test.
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr61375.c
b/gcc/testsuite/gcc.c-torture/execute/pr61375.c
new file mode 100644
index 000..58df57a
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr61375.c
@@ -0,0 +1,34 @@
+#ifdef __UINT64_TYPE__
+typedef __UINT64_TYPE__ uint64_t;
+#else
+typedef unsigned long long uint64_t;
+#endif
+
+#ifndef __SIZEOF_INT128__
+#define __int128 long long
+#endif
+
+/* Some version of bswap optimization would ICE when analyzing a mask constant
+ too big for an HOST_WIDE_INT (PR210931). */
+
+__attribute__ ((noinline, noclone)) uint64_t
+uint128_central_bitsi_ior (unsigned __int128 in1, uint64_t in2)
+{
+ __int128 mask = (__int128)0x 56;
+ return ((in1 mask) 56) | in2;
+}
+
+int main(int argc)
+{
+ __int128 in = 1;
+#ifdef __SIZEOF_INT128__
+ in = 64;
+#endif
+ if (sizeof (uint64_t) * __CHAR_BIT__ != 64)
+return 0;
+ if (sizeof (unsigned __int128) * __CHAR_BIT__ != 128)
+return 0;
+ if (uint128_central_bitsi_ior (in, 2) != 0x102)
+__builtin_abort ();
+ return 0;
+}
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index 658b341..95b3f25 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -1717,6 +1717,8 @@ init_symbolic_number (struct symbolic_number *n, tree src)
if (n-size % BITS_PER_UNIT != 0)
return false;
n-size /= BITS_PER_UNIT;
+ if (n-size (int)sizeof (unsigned HOST_WIDE_INT))
+return false;
n-range = n-size;
n-n = CMPNOP;
@@ -1883,6 +1885,8 @@ find_bswap_or_nop_1 (gimple stmt, struct symbolic_number
*n, int limit)
type_size = TYPE_PRECISION (gimple_expr_type (stmt));
if (type_size % BITS_PER_UNIT != 0)
return NULL_TREE;
+ if (type_size (int)sizeof (unsigned HOST_WIDE_INT) * 8)
+ return NULL_TREE;
if (type_size / BITS_PER_UNIT (int)(sizeof (int64_t)))
{
Is this OK for trunk? What about backports for 4.8 and 4.9? Would a
reworked patch for these versions be accepted? The change would
be trivial: the code in init_symbolic_number now was moved from
some other place.
Best regards,
Thomas
Re: libgo patch committed: Merge from revision 18783 of master
On Mon, Jun 9, 2014 at 5:36 PM, Ian Lance Taylor i...@google.com wrote: There is no bug here, the control flow is just too complicated for the compiler to sort out. I don't know why I'm not seeing the warning [...] We have these compilation flags set: CFLAGS='-g3 -O3' CFLAGS_FOR_BUILD='-g3 -O3' CFLAGS_FOR_TARGET='-g3 -O3' I tried make CFLAGS='-g3 -O2' chan.lo (the default) and it compiled without complaint.
Re: RFC: C++ PATCH to remove -fabi-version=1 support
On Jun 9, 2014, at 1:46 PM, Jason Merrill ja...@redhat.com wrote: I'm updating -Wabi to allow for warnings about changes between a previous ABI version and the currently selected one, and rather than adjust all the warnings for -fabi-version=1 I'd like to tear it out. It has now been 10 years since GCC 3.4. Apple only cared about 4.2.1… so ok from a darwin perspective.
[committed] Add missing @cindex (PR c/60988)
transparent_union was missing a @cindex entry. Tested with
info ./gcc/doc/gcc.info --index-search=transparent_union
Committed as obvious.
2014-06-10 Marek Polacek pola...@redhat.com
PR c/60988
* doc/extend.texi: Add cindex for transparent_union.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 23a7809..42db985 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -5732,6 +5732,8 @@ You may only specify this attribute on the definition of
an @code{enum},
also define the enumerated type, structure or union.
@item transparent_union
+@cindex @code{transparent_union} attribute
+
This attribute, attached to a @code{union} type definition, indicates
that any function parameter having that union type causes calls to that
function to be treated in a special way.
Marek
