Re: [PATCH] Put a breakpoint on __asan_report_error for ASAN
H.J. Lu hjl.to...@gmail.com a écrit: 2012-11-24 H.J. Lu hongjiu...@intel.com * configure.ac: Append gdbasan.in to .gdbinit if CFLAGS contains -fsanitize=address. * configure: Regenerated. * gdbasan.in: New file. This is OK, if nobody objects in the next 48h. Thanks. -- Dodji
Re: wide-int, rtl-2
Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the half of the rtl code. This looks OK to me. -- Eric Botcazou
Re: [patch] introduce aarch64 as a Go architecture
On 1 December 2013 19:55, Michael Hudson-Doyle michael.hud...@linaro.org wrote: Ian Lance Taylor i...@google.com writes: I've gotten a patch from Michael Hudson-Doyle to set GOARCH to arm64 on an Aarch64 system (https://codereview.appspot.com/34830045/). Haha, go us. I've gotten a patch from Matthias Klose to set GOARCH to aarch64 on such a system (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03765.html). I don't care one way or another myself, but we need to pick one. I don't care too much myself. AArch64 is more correct but arm64 is more obvious. Also plan9/inferno will use arm64 IIUC. All the documentation relevant to this architecture uses the term aarch64. How is arm64 obvious? /Marcus
Re: [patch] introduce aarch64 as a Go architecture
On Mon, Dec 2, 2013 at 1:02 AM, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 1 December 2013 19:55, Michael Hudson-Doyle michael.hud...@linaro.org wrote: Ian Lance Taylor i...@google.com writes: I've gotten a patch from Michael Hudson-Doyle to set GOARCH to arm64 on an Aarch64 system (https://codereview.appspot.com/34830045/). Haha, go us. I've gotten a patch from Matthias Klose to set GOARCH to aarch64 on such a system (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03765.html). I don't care one way or another myself, but we need to pick one. I don't care too much myself. AArch64 is more correct but arm64 is more obvious. Also plan9/inferno will use arm64 IIUC. All the documentation relevant to this architecture uses the term aarch64. How is arm64 obvious? The same reason Linus used arm64: https://lkml.org/lkml/2012/7/15/133 Thanks, Andrew Pinski /Marcus
RFC ThreadSanitizer testsuite
Hi all! Currently gcc has tests for AddressSanitizer and UBSanitizer. Do you think it would make sense to add support for ThreadSanitizer testing as well? If the answer is positive, we can work on dg infrastructure (tsan-dg.exp, tsan.exp) and initial set of tests. As for the latter: should we implement our own tests in gcc or simply copy from compiler-rt testsuite? -Y
Re: [ARM] Fix register r3 wrongly used to save ip in nested APCS frame
My apologies for taking so long to look at this.
No problem, all the more so that...
2013-09-05 Eric Botcazou ebotca...@adacore.com
* config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with
arguments to push onto the stack and no varargs, save ip into a stack
slot if r3 isn't available on entry.
Sorry, but this is not quite right either, as shown by the attached
testcase (in C this time, so we can commit it to gcc.target/arm :-)
The problem is that if we have some alignment padding we end up storing
ip in one location but restoring it from another.
str ip, [sp, #4]
add ip, sp, #8
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #12
ldr ip, [fp, #4]// Should be fp + 8
@ ip needed
str r3, [fp, #8]
ldr ip, [ip]
...ugh, right, the computation of the slot address was supposed to be clever
but is totally broken instead. :-( Thanks for spotting it, I don't understand
how we haven't seen this on VxWorks (although your testcase does not fail on
VxWorks, since args_to_push is 4 instead of 8 as on arm-eabi).
The computation of the slot address is:
+ {
+ rtx x = plus_constant (Pmode, stack_pointer_rtx,
+args_to_push - 4);
+ insn = emit_insn (gen_addsi3 (stack_pointer_rtx,
+ stack_pointer_rtx,
+ GEN_INT (- args_to_push)));
+ emit_set_insn (gen_frame_mem (SImode, x), ip_rtx);
+ }
meaning that IP will be saved into the first slot on the stack. But the
restore code is:
/* Recover the static chain register. */
if (!arm_r3_live_at_start_p () || saved_pretend_args)
insn = gen_rtx_REG (SImode, 3);
else
{
insn = plus_constant (Pmode, hard_frame_pointer_rtx, 4);
insn = gen_frame_mem (SImode, insn);
}
emit_set_insn (ip_rtx, insn);
meaning that IP is restored from the last slot on the stack, so this can work
only if args_to_push == 4.
Revised patch attached, your testcase passes on arm-eabi with it. Does it
look OK to you? If so, I'll run a testing cycle on arm-vxworks and arm-eabi.
* config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with
arguments to push onto the stack and no varargs, save ip into the last
stack slot if r3 isn't available on entry.
--
Eric BotcazouIndex: config/arm/arm.c
===
--- config/arm/arm.c (revision 205579)
+++ config/arm/arm.c (working copy)
@@ -18549,8 +18549,7 @@ arm_r3_live_at_start_p (void)
/* Just look at cfg info, which is still close enough to correct at this
point. This gives false positives for broken functions that might use
uninitialized data that happens to be allocated in r3, but who cares? */
- return REGNO_REG_SET_P (df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN (cfun)),
- 3);
+ return REGNO_REG_SET_P (df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN (cfun)), 3);
}
/* Compute the number of bytes used to store the static chain register on the
@@ -20576,11 +20575,13 @@ arm_expand_prologue (void)
whilst the frame is being created. We try the following
places in order:
- 1. The last argument register r3.
- 2. A slot on the stack above the frame. (This only
- works if the function is not a varargs function).
+ 1. The last argument register r3 if it is available.
+ 2. A slot on the stack above the frame if there are no
+ arguments to push onto the stack.
3. Register r3 again, after pushing the argument registers
- onto the stack.
+ onto the stack, if this is a varargs function.
+ 4. The last slot on the stack created for the arguments to
+ push, if this isn't a varargs function.
Note - we only need to tell the dwarf2 backend about the SP
adjustment in the second variant; the static chain register
@@ -20611,21 +20612,24 @@ arm_expand_prologue (void)
{
/* Store the args on the stack. */
if (cfun-machine-uses_anonymous_args)
- insn = emit_multi_reg_push
- ((0xf0 (args_to_push / 4)) 0xf);
+ {
+ insn
+ = emit_multi_reg_push ((0xf0 (args_to_push / 4)) 0xf);
+ emit_set_insn (gen_rtx_REG (SImode, 3), ip_rtx);
+ saved_pretend_args = 1;
+ }
else
- insn = emit_insn
- (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx,
- GEN_INT (- args_to_push)));
+ {
+ insn = emit_insn (gen_addsi3 (stack_pointer_rtx,
+ stack_pointer_rtx,
+ GEN_INT (- args_to_push)));
+ emit_set_insn (gen_frame_mem (SImode, stack_pointer_rtx),
+ ip_rtx);
+ }
RTX_FRAME_RELATED_P (insn) = 1;
-
- saved_pretend_args = 1;
Re: RFC ThreadSanitizer testsuite
I'd be glad to have tsan tests in GCC. At the very least we need to have a couple of sanity tests to make sure tsan links and finds a trivial race. The only mode in which my team can truly support tsan tests is when they are verbatim copies of the upstream tests and they are merged together with the rest of libsanitizer. (Which implies that we use FileCheck or its clone) Other mode may work too, but we will not own the tests (similarly, we don't own the existing asan tests in GCC, although if the tests need fixing during integrate we do it). BTW, I am currently testing another libsanitizer merge. --kcc On Mon, Dec 2, 2013 at 2:13 PM, Yury Gribov y.gri...@samsung.com wrote: Hi all! Currently gcc has tests for AddressSanitizer and UBSanitizer. Do you think it would make sense to add support for ThreadSanitizer testing as well? If the answer is positive, we can work on dg infrastructure (tsan-dg.exp, tsan.exp) and initial set of tests. As for the latter: should we implement our own tests in gcc or simply copy from compiler-rt testsuite? -Y
Re: [golang-dev] Re: [gofrontend-dev] Re: [patch] introduce aarch64 as a Go architecture
On 2 Dec 2013, at 00:06, Rob Pike r...@golang.org wrote: arm64 it is This is perverse and completely inconsistent with the rest of the gnu tool chain. It makes no sense at all to me for go to be inconsistent in this way. R.
Re: RFC ThreadSanitizer testsuite
On Mon, Dec 02, 2013 at 02:13:42PM +0400, Yury Gribov wrote: Currently gcc has tests for AddressSanitizer and UBSanitizer. Do you think it would make sense to add support for ThreadSanitizer testing as well? If the answer is positive, we can work on dg infrastructure (tsan-dg.exp, tsan.exp) and initial set of tests. As for the latter: should we implement our own tests in gcc or simply copy from compiler-rt testsuite? IMHO we should have some tsan tests, most likely a copy of the upstream tests converted to dejagnu. The problem is that at least by default we don't want very expensive tests in the testsuite, whether it is runtime expensive or eats too much memory. Jakub
Re: [patch] introduce aarch64 as a Go architecture
On 29 Nov 2013, at 19:38, Andrew Pinski pins...@gmail.com wrote: On Fri, Nov 29, 2013 at 11:34 AM, Matthias Klose d...@ubuntu.com wrote: Please let's pick aarch64. Everybody names it this way, except of course Debian And the linux kernel. The Linux kernel reports aarch64 in its uname. It's only the source tree that uses arm64. Arm64 is also potentially problematic in regexp strings as it matches arm6*, which was used for some early ARM chips. R. :-/ If I understand ARM developers correctly, there will be something like aarch32 in the future (x32 for ARM), and I think you don't want to call it arm32. Matthias Am 29.11.2013 20:22, schrieb Ian Lance Taylor: I've gotten a patch from Michael Hudson-Doyle to set GOARCH to arm64 on an Aarch64 system (https://codereview.appspot.com/34830045/). I've gotten a patch from Matthias Klose to set GOARCH to aarch64 on such a system (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03765.html). I don't care one way or another myself, but we need to pick one. Ian On Fri, Nov 29, 2013 at 5:23 AM, Matthias Klose d...@ubuntu.com wrote: This patch introduces aarch64 as a Go architecture. Matthias
Re: RFC ThreadSanitizer testsuite
Konstantin Serebryany wrote: Other mode may work too, but we will not own the tests (similarly, we don't own the existing asan tests in GCC, although if the tests need fixing during integrate we do it). I think everyone agrees on this. Once tests are in, Gcc team will maintain them. -Y
Re: wide-int, tree-ssa
On Fri, Nov 29, 2013 at 3:59 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Only a partial reply. I'll leave Kenny and Mike to answer the VARYING
question.
Richard Biener richard.guent...@gmail.com writes:
On Sat, Nov 23, 2013 at 8:23 PM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual
port and front end maintainers can review their parts without have to
go through the entire patch. This patch covers the tree-saa code.
Ok?
Same comments as to tree-affine.c apply to tree-ssa-address.c.
@@ -887,8 +886,8 @@ copy_ref_info (tree new_ref, tree old_ref)
(TREE_INT_CST_LOW (TMR_STEP (new_ref))
align)
{
- unsigned int inc = (mem_ref_offset (old_ref)
- - mem_ref_offset (new_ref)).low;
+ unsigned int inc = (mem_ref_offset (old_ref).to_uhwi ()
+ - mem_ref_offset (new_ref).to_uhwi ());
adjust_ptr_info_misalignment (new_pi, inc);
}
else
other patches used .to_short_addr (), also your conversion isn't
correct - previously the subtraction was in infinite precision and only
the result (possibly) truncated. Now the subtraction operands are
truncated - that looks wrong.
Sorry, forgot about .to_short_addr () when doing the merge.
The conversion should be OK with that fixed though, since truncation
distributes through subtraction (and truncating first is cheaper).
+/* Return a widest_int that can be used for bitwise simplifications
from VAL. */
-static double_int
-value_to_double_int (prop_value_t val)
+static widest_int
+value_to_wide_int (prop_value_t val)
{
if (val.value
TREE_CODE (val.value) == INTEGER_CST)
-return tree_to_double_int (val.value);
- else
-return double_int_zero;
+return wi::to_widest (val.value);
+
+ return 0;
}
you also get to hope that we optimize all the widest_int return-by-value
code to elide the implied copying ... (not sure if you can do that by
adding a not implemented copy / assignment constructor - C++ folks?)
Are you worried about a copy from one widest_int to another?
Won't the return-value optimisation stop that?
If it works and applies - as far as I know this is not guaranteed. It would
be interesting to know whether any non-NRV cases are left.
Or are you worried about the copy from the tree to the widest_int?
In this particular case I suppose we could use:
wi::to_widest (integer_zero_node)
instead of 0 and return a:
generic_wide_int extended_tree MAX_BITSIZE_MODE_ANY_INT
(typedefed :-)). Is the function really hot enough to justify the
uglification though? We're thinking about these kinds of tweaks now
because it's flavour of the month, but I bet post-merge patches will
use the more obvious implementation instead.
I wasn't worried about this specifically.
OTOH maybe this is a natural candidate for C++11 auto...
case LT_EXPR:
case LE_EXPR:
{
+ widest_int o1val, o2val, o1mask, o2mask;
int minmax, maxmin;
+
+ if ((code == GE_EXPR) || (code == GT_EXPR))
+ {
+ o1val = r2val;
+ o1mask = r2mask;
+ o2val = r1val;
+ o2mask = r1mask;
+ code = swap_tree_comparison (code);
+ }
+ else
+ {
+ o1val = r1val;
+ o1mask = r1mask;
+ o2val = r2val;
+ o2mask = r2mask;
+ }
that are pretty expensive copies, no? Consider using
const widest_int o1val = swap ? r2val : r1val;
and so on. (C++ folks? Any idea how to avoid the repeated
conditional init in favor of sth that more resembles the original?)
Not a C++ person, but I can't think of one either. It probably
wouldn't be as readable as the four separate statements though.
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 6ea634c..c975a97 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -1643,7 +1643,7 @@ mem_refs_may_alias_p (mem_ref_p mem1, mem_ref_p mem2,
/* Perform BASE + OFFSET analysis -- if MEM1 and MEM2 are based on the
same
object and their offset differ in such a way that the locations cannot
overlap, then they cannot alias. */
- double_int size1, size2;
+ widest_int size1, size2;
aff_tree off1, off2;
from the names you can know this is offset_int.
I agree that's true in the overlap and get_inner_reference_aff cases,
but most of tree-affine seems to be more general than that. Is it really
worth bunging in conversions between offset_int and widest_int to save a
few HWIs of stack space?
I think so.
@@ -529,15 +526,15 @@ end:
difference of two values in TYPE. */
static void
-bounds_add (bounds *bnds, double_int delta, tree type)
+bounds_add (bounds *bnds, widest_int delta, tree type)
{
Re: RFC ThreadSanitizer testsuite
Jakub Jelinek wrote: The problem is that at least by default we don't want very expensive tests in the testsuite, whether it is runtime expensive or eats too much memory. I see. We can only merge small tests then. From what I see in compiler-rt/lib/tsan/lit_tests, most of the tests are rather short: fork one or two threads, do something fast and simple (e.g. do unsynchronized access), join and exit. -Y
Re: [wide-int] small cleanup in wide-int.*
On Sat, Nov 30, 2013 at 1:55 AM, Kenneth Zadeck zad...@naturalbridge.com wrote: Richi, this is the first of either 2 or 3 patches to fix this.There are two places that need be fixed for us to do 1X + 1 and this patch fixes the first one. There was an unnecessary call to mul_full and this was the only call to mul_full. So this patch removes the call and also the function itself. The other place is the tree-vpn that is discussed here and will be dealt with in the other patches. tested on x86-64. Ok to commit? Ok. Thanks, Richard. Kenny On 11/29/2013 05:24 AM, Richard Biener wrote: On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: This patch does three things in wide-int: 1) it cleans up some comments. 2) removes a small amount of trash. 3) it changes the max size of the wide int from being 4x of MAX_BITSIZE_MODE_ANY_INT to 2x +1. This should improve large muls and divs as well as perhaps help with some cache behavior. @@ -235,8 +233,8 @@ along with GCC; see the file COPYING3. range of a multiply. This code needs 2n + 2 bits. */ #define WIDE_INT_MAX_ELTS \ - ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ - / HOST_BITS_PER_WIDE_INT) + (((2 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ +/ HOST_BITS_PER_WIDE_INT) + 1) I always wondered why VRP (if that is the only reason we do 2*n+1) cannot simply use FIXED_WIDE_INT(MAX_BITSIZE_MODE_ANY_INT*2 + 1)? Other widest_int users should not suffer IMHO. widest_int should strictly cover all modes that the target can do any arithmetic on (thus not XImode or OImode on x86_64). Richard. ok to commit
Re: wwwdocs: Broken links due to the preprocess script
Hi Tobias, On Fri, 25 Oct 2013, Tobias Burnus wrote: http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html However, some script changes the link to: http://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html which won't work. Try yourself at http://gcc.gnu.org/gcc-4.9/changes.html Actually, a similar issue was reported at http://gcc.gnu.org/ml/gcc-help/2013-10/msg00132.html The reason for the broken links are the following lines in the /www/bin/preprocess script: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/wwwdocs/bin/preprocess.diff?r1=1.38r2=1.39f=h Gerald, do you still know why you added it 9 years ago? The commit comment is Use sed to work around makeinfo 4.7 brokenness. yes, I do recall. This was to work around a less then well advised change in makeinfo that replaced - in the local part of URLs by encoding it as _002d. I firmly believe that this approach creates ugly and harder to use URLs for what I consider theoretical benefits only. Cf. #alpha_002a_002d_002a_002d_002a vs #alpha*-*-*, for a real example. Here are some historical references http://gcc.gnu.org/ml/gcc/2004-09/msg00222.html http://gcc.gnu.org/ml/gcc/2004-09/msg00219.html I think makeinfo is still broken, but those pages do not seem to go through the preprocess script, which means that only links to that page will change to a hyphen, breaking the links. Do you think it would be sensible to remove those lines again - or, alternatively, to run a similar script (e.g. perl -i -e 's/_002d/-/g' `find onlinedocs -name \*.html`) on the onlinedocs/. From all I can tell, we should do the latter, that is, ensure that our other web pages (/onlinedocs) are adjusted properly as well. And maintainer-scripts/update_web_docs_svn was supposed to do that, alas I just realize it is only handling wwwdocs/htdocs, not what we generate for /onlinedocs. Below you'll find a patch for maintainer-scripts/update_web_docs_svn which I tested on gcc.gnu.org and the current documentation pages (not those for older releases) are adjusted now. Among others this fixes the link you reported above (though adjusting gcc-4.9/changes.html directly is now a logical next step). Thoughts? Gerald 2013-12-02 Gerald Pfeifer ger...@pfeifer.com * update_web_docs_svn: Work around makeinfo generated file names and references with _002d instead of -. Index: maintainer-scripts/update_web_docs_svn === --- update_web_docs_svn (revision 205584) +++ update_web_docs_svn (working copy) @@ -172,6 +172,19 @@ fi done +# Work around makeinfo generated file names and references with +# _002d instead of -. +find . -name '*.html' | while read f; do + # Do this for the contents of each file. + sed -i -e 's/_002d/-/g' $f + # And rename files if necessary. + ff=`echo $f | sed -e 's/_002d/-/g'`; + if [ $f != $ff ]; then +printf Renaming %s to %s\n $f $ff +mv $f $ff + fi +done + # Then build a gzipped copy of each of the resulting .html, .ps and .tar files for file in */*.html *.ps *.pdf *.tar; do cat $file | gzip --best $file.gz
Re: doc: Add -fuse-ld to option index
On Sun, 1 Dec 2013, Ryan Mansfield wrote: I noticed there wasn't an entry in the option index for -fuse-ld. If OK, can someone apply? Thanks. Thanks, Ryan! This is also covered by Tobias' patch... On Sun, 1 Dec 2013, Tobias Burnus wrote: There are many more options which lack an optindex, cf. still unreviewed and pinged patch at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03082.html ...which I approved yesterday, so I think we are good now? Gerald
[PATCH] Fix PR59199
The following fixes a bug in update_address_taken which fails
to reset debug stmts which take the address of a decl we will
rewrite into SSA form. Our verifiers don't catch this because
of an early out in the operand scanner which doesn't work in
the specific case of LTO profiledbootstrap (or because we
don't have more specific checking for this case).
Fixed like the following.
LTO profiledbootstrapped on x86_64-unknown-linux-gnu, regular
bootstrap regtest still running.
Richard.
2013-12-02 Richard Biener rguent...@suse.de
PR middle-end/59199
* tree-ssa.c (execute_update_addresses_taken): Reset debug
stmts that take the address of a no longer addressable decl.
Index: gcc/tree-ssa.c
===
*** gcc/tree-ssa.c (revision 205528)
--- gcc/tree-ssa.c (working copy)
*** execute_update_addresses_taken (void)
*** 1651,1661
{
tree *valuep = gimple_debug_bind_get_value_ptr (stmt);
tree decl;
! maybe_rewrite_mem_ref_base (valuep, suitable_for_renaming);
! decl = non_rewritable_mem_ref_base (*valuep);
if (decl
bitmap_bit_p (suitable_for_renaming, DECL_UID (decl)))
gimple_debug_bind_reset_value (stmt);
}
if (gimple_references_memory_p (stmt)
--- 1651,1666
{
tree *valuep = gimple_debug_bind_get_value_ptr (stmt);
tree decl;
! if (TREE_CODE (*valuep) == ADDR_EXPR)
! decl = get_base_address (TREE_OPERAND (*valuep, 0));
! else
! decl = non_rewritable_mem_ref_base (*valuep);
if (decl
+DECL_P (decl)
bitmap_bit_p (suitable_for_renaming, DECL_UID (decl)))
gimple_debug_bind_reset_value (stmt);
+ else
+ maybe_rewrite_mem_ref_base (valuep, suitable_for_renaming);
}
if (gimple_references_memory_p (stmt)
Re: Add TREE_INT_CST_OFFSET_NUNITS
On Sat, Nov 30, 2013 at 10:43 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
So maybe two INTEGER_CST lengths weren't enough. Because bitsizetype
can be offset_int-sized, wi::to_offset had a TYPE_PRECISION condition
to pick the array length:
template int N
inline unsigned int
wi::extended_tree N::get_len () const
{
if (N == MAX_BITSIZE_MODE_ANY_INT
|| N TYPE_PRECISION (TREE_TYPE (m_t)))
return TREE_INT_CST_EXT_NUNITS (m_t);
else
return TREE_INT_CST_NUNITS (m_t);
}
and this TYPE_PRECISION condition was relatively hot in
get_ref_base_and_extent when compiling insn-recog.ii.
Adding a third length for offset_int does seem to reduce the cost of
the offset_int + to_offset addition.
Tested on x86_64-linux-gnu. OK to install?
Hmm, that's now getting a bit excessive ...
inline unsigned int
wi::extended_tree N::get_len () const
{
- if (N == MAX_BITSIZE_MODE_ANY_INT
- || N TYPE_PRECISION (TREE_TYPE (m_t)))
+ if (N == ADDR_MAX_PRECISION)
+return TREE_INT_CST_OFFSET_NUNITS (m_t);
+ else if (N == MAX_BITSIZE_MODE_ANY_INT
+ || N TYPE_PRECISION (TREE_TYPE (m_t)))
return TREE_INT_CST_EXT_NUNITS (m_t);
else
return TREE_INT_CST_NUNITS (m_t);
Shouldn't it be N = TYPE_PRECISION () btw?
Looking at the implementation it seems it would also work with
return MIN (TREE_INT_CST_EXT_NUNITS (m_t), N / HOST_BITS_PER_WIDE_INT);
?
Richard.
Thanks,
Richard
Index: gcc/ChangeLog.wide-int
===
--- gcc/ChangeLog.wide-int 2013-11-30 09:31:16.359198395 +
+++ gcc/ChangeLog.wide-int 2013-11-30 09:41:50.987741444 +
@@ -616,6 +616,7 @@
(TREE_INT_CST_HIGH): Delete.
(TREE_INT_CST_NUNITS): New.
(TREE_INT_CST_EXT_NUNITS): Likewise.
+ (TREE_INT_CST_OFFSET_NUNITS): Likewise.
(TREE_INT_CST_ELT): Likewise.
(INT_CST_LT): Use wide-int interfaces.
(INT_CST_LE): New.
Index: gcc/tree-core.h
===
--- gcc/tree-core.h 2013-11-30 09:31:16.359198395 +
+++ gcc/tree-core.h 2013-11-30 09:41:12.011470169 +
@@ -764,11 +764,16 @@ struct GTY(()) tree_base {
struct {
/* The number of HOST_WIDE_INTs if the INTEGER_CST is accessed in
its native precision. */
- unsigned short unextended;
+ unsigned char unextended;
/* The number of HOST_WIDE_INTs if the INTEGER_CST is extended to
wider precisions based on its TYPE_SIGN. */
- unsigned short extended;
+ unsigned char extended;
+
+ /* The number of HOST_WIDE_INTs if the INTEGER_CST is accessed in
+offset_int precision, with smaller integers being extended
+according to their TYPE_SIGN. */
+ unsigned char offset;
} int_length;
/* VEC length. This field is only used with TREE_VEC. */
Index: gcc/tree.c
===
--- gcc/tree.c 2013-11-30 09:31:16.359198395 +
+++ gcc/tree.c 2013-11-30 09:41:42.965685621 +
@@ -1285,6 +1285,7 @@ wide_int_to_tree (tree type, const wide_
/* Make sure no one is clobbering the shared constant. */
gcc_checking_assert (TREE_TYPE (t) == type
TREE_INT_CST_NUNITS (t) == 1
+ TREE_INT_CST_OFFSET_NUNITS (t) == 1
TREE_INT_CST_EXT_NUNITS (t) == 1
TREE_INT_CST_ELT (t, 0) == hwi);
else
@@ -1964,6 +1965,7 @@ make_int_cst_stat (int len, int ext_len
TREE_SET_CODE (t, INTEGER_CST);
TREE_INT_CST_NUNITS (t) = len;
TREE_INT_CST_EXT_NUNITS (t) = ext_len;
+ TREE_INT_CST_OFFSET_NUNITS (t) = MIN (ext_len, OFFSET_INT_ELTS);
TREE_CONSTANT (t) = 1;
Index: gcc/tree.h
===
--- gcc/tree.h 2013-11-30 09:31:16.359198395 +
+++ gcc/tree.h 2013-11-30 09:41:29.418591391 +
@@ -907,6 +907,8 @@ #define TREE_INT_CST_NUNITS(NODE) \
(INTEGER_CST_CHECK (NODE)-base.u.int_length.unextended)
#define TREE_INT_CST_EXT_NUNITS(NODE) \
(INTEGER_CST_CHECK (NODE)-base.u.int_length.extended)
+#define TREE_INT_CST_OFFSET_NUNITS(NODE) \
+ (INTEGER_CST_CHECK (NODE)-base.u.int_length.offset)
#define TREE_INT_CST_ELT(NODE, I) TREE_INT_CST_ELT_CHECK (NODE, I)
#define TREE_INT_CST_LOW(NODE) \
((unsigned HOST_WIDE_INT) TREE_INT_CST_ELT (NODE, 0))
@@ -4623,8 +4625,10 @@ wi::extended_tree N::get_val () const
inline unsigned int
wi::extended_tree N::get_len () const
{
- if (N == MAX_BITSIZE_MODE_ANY_INT
- || N TYPE_PRECISION (TREE_TYPE (m_t)))
+ if (N == ADDR_MAX_PRECISION)
+return TREE_INT_CST_OFFSET_NUNITS (m_t);
+ else if (N == MAX_BITSIZE_MODE_ANY_INT
+ || N TYPE_PRECISION (TREE_TYPE (m_t)))
return
Re: [patch] Fix failure of ACATS c52102c
On Sat, Nov 30, 2013 at 6:24 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
this test started to fail very recently on 32-bit platforms with 64-bit HWI.
Not sure exactly why, but the issue is straightforward and was latent.
For the following reference, a call to ao_ref_init_from_ptr_and_size yields:
(gdb) p debug_generic_expr((tree_node *) 0x76e01200)
a[0 ...]{lb: 4294967292 sz: 4}
(gdb) p debug_generic_expr(size)
20
(gdb) p dref
$36 = {ref = 0x0, base = 0x76dfd260, offset = -137438953344, size = 160,
max_size = 160, ref_alias_set = 0, base_alias_set = 0, volatile_p = false}
The offset is bogus. 'a' is an array with lower bound -4 so {lb: 4294967292
sz: 4} is actually {lb: -4 sz: 4}. The computation of the offset goes wrong
in get_addr_base_and_unit_offset_1 because it is not done in sizetype.
Fixed by copying the relevant bits from get_ref_base_and_extent, where the
computation is correctly done in sizetype.
Tested on x86_64-suse-linux, OK for the mainline?
Ok, though the whole function needs double-int-ization ...
Thanks,
Richard.
2013-11-30 Eric Botcazou ebotca...@adacore.com
* tree-dfa.h (get_addr_base_and_unit_offset_1) case ARRAY_REF: Do
the
offset computation using the precision of the index type.
2013-11-30 Eric Botcazou ebotca...@adacore.com
* gnat.dg/opt30.adb: New test.
--
Eric Botcazou
Re: [wide-int]
On Sun, Dec 1, 2013 at 11:51 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
At the moment we only use host divisions for precisions =
HOST_BITS_PER_WIDE_INT. This patch extends it to any division in which
the inputs fit in HWIs. The easiest way seemed to be to construct
wide_int_refs for the numbers and reuse wi::fits_*hwi_p. This also
simplifies some of the other code.
The only tricky thing is that we need to handle HOST_WIDE_INT_MIN / -1
specially for precisions HOST_BITS_PER_WIDE_INT, since that isn't an
overflow and is the only case where the result needs two HWIs.
The slow path is now only used 7 times for insn-recog.ii, 4 for
cp/parser.ii and not at all for fold-const.ii.
Tested on x86_64-linux-gnu. OK to install?
Ok.
Thanks,
Richard.
Thanks,
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 2013-11-30 10:30:07.512582970 +
+++ gcc/wide-int.cc 2013-12-01 10:48:47.128907474 +
@@ -1663,9 +1663,10 @@ divmod_internal_2 (unsigned HOST_HALF_WI
the division overflowed. */
unsigned int
wi::divmod_internal (HOST_WIDE_INT *quotient, unsigned int *remainder_len,
-HOST_WIDE_INT *remainder, const HOST_WIDE_INT *dividend,
+HOST_WIDE_INT *remainder,
+const HOST_WIDE_INT *dividend_val,
unsigned int dividend_len, unsigned int dividend_prec,
-const HOST_WIDE_INT *divisor, unsigned int divisor_len,
+const HOST_WIDE_INT *divisor_val, unsigned int
divisor_len,
unsigned int divisor_prec, signop sgn,
bool *oflow)
{
@@ -1680,42 +1681,25 @@ wi::divmod_internal (HOST_WIDE_INT *quot
unsigned HOST_HALF_WIDE_INT
b_divisor[4 * MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_HALF_WIDE_INT];
unsigned int m, n;
- HOST_WIDE_INT u0[WIDE_INT_MAX_ELTS];
- HOST_WIDE_INT u1[WIDE_INT_MAX_ELTS];
bool dividend_neg = false;
bool divisor_neg = false;
bool overflow = false;
+ wide_int neg_dividend, neg_divisor;
- if (divisor[0] == 0 divisor_len == 1)
+ wide_int_ref dividend = wi::storage_ref (dividend_val, dividend_len,
+ dividend_prec);
+ wide_int_ref divisor = wi::storage_ref (divisor_val, divisor_len,
+ divisor_prec);
+ if (divisor == 0)
overflow = true;
- /* The smallest signed number / -1 causes overflow. */
+ /* The smallest signed number / -1 causes overflow. The dividend_len
+ check is for speed rather than correctness. */
if (sgn == SIGNED
dividend_len == BLOCKS_NEEDED (dividend_prec)
- divisor_len == 1)
-{
- HOST_WIDE_INT divisor_low = divisor[0];
- if (divisor_prec HOST_BITS_PER_WIDE_INT)
- divisor_low = sext_hwi (divisor_low, divisor_prec);
- unsigned HOST_WIDE_INT dividend_high = dividend[dividend_len - 1];
- dividend_high = -dividend_prec % HOST_BITS_PER_WIDE_INT;
- if (divisor_low == -1
- HOST_WIDE_INT (dividend_high) == HOST_WIDE_INT_MIN)
- {
- /* The smallest neg number is 100...00. The high word was
-checked above, now check the rest of the words are zero. */
- unsigned int i;
- bool all_zero = true;
- for (i = 0; i + 1 dividend_len; i++)
- if (dividend[i] != 0)
- {
- all_zero = false;
- break;
- }
- if (all_zero)
- overflow = true;
- }
-}
+ divisor == -1
+ wi::only_sign_bit_p (dividend))
+overflow = true;
/* If overflow is set, just get out. There will only be grief by
continuing. */
@@ -1737,27 +1721,30 @@ wi::divmod_internal (HOST_WIDE_INT *quot
*oflow = false;
/* Do it on the host if you can. */
- if (dividend_prec = HOST_BITS_PER_WIDE_INT
- divisor_prec = HOST_BITS_PER_WIDE_INT)
+ if (sgn == SIGNED
+ wi::fits_shwi_p (dividend)
+ wi::fits_shwi_p (divisor))
{
- if (sgn == SIGNED)
- {
- HOST_WIDE_INT o0 = sext_hwi (dividend[0], dividend_prec);
- HOST_WIDE_INT o1 = sext_hwi (divisor[0], divisor_prec);
+ HOST_WIDE_INT o0 = dividend.to_shwi ();
+ HOST_WIDE_INT o1 = divisor.to_shwi ();
+ if (o0 == HOST_WIDE_INT_MIN o1 == -1)
+ {
+ gcc_checking_assert (dividend_prec HOST_BITS_PER_WIDE_INT);
if (quotient)
- quotient[0] = o0 / o1;
+ {
+ quotient[0] = HOST_WIDE_INT_MIN;
+ quotient[1] = 0;
+ }
if (remainder)
{
- remainder[0] = o0 % o1;
+ remainder[0] = 0;
*remainder_len = 1;
}
+ return 2;
}
else
{
- unsigned HOST_WIDE_INT o0 = zext_hwi
Re: [PATCH] Fix PR59199
On Mon, Dec 02, 2013 at 12:05:57PM +0100, Richard Biener wrote:
The following fixes a bug in update_address_taken which fails
to reset debug stmts which take the address of a decl we will
rewrite into SSA form. Our verifiers don't catch this because
of an early out in the operand scanner which doesn't work in
the specific case of LTO profiledbootstrap (or because we
don't have more specific checking for this case).
Fixed like the following.
LTO profiledbootstrapped on x86_64-unknown-linux-gnu, regular
bootstrap regtest still running.
Taking address of a decl that is no longer addressable in debug stmts
is correct, that is how we generate DW_OP_GNU_implicit_ptr.
So I think this patch is going to cause huge amount of debug info quality
regressions.
2013-12-02 Richard Biener rguent...@suse.de
PR middle-end/59199
* tree-ssa.c (execute_update_addresses_taken): Reset debug
stmts that take the address of a no longer addressable decl.
Index: gcc/tree-ssa.c
===
*** gcc/tree-ssa.c(revision 205528)
--- gcc/tree-ssa.c(working copy)
*** execute_update_addresses_taken (void)
*** 1651,1661
{
tree *valuep = gimple_debug_bind_get_value_ptr (stmt);
tree decl;
! maybe_rewrite_mem_ref_base (valuep, suitable_for_renaming);
! decl = non_rewritable_mem_ref_base (*valuep);
if (decl
bitmap_bit_p (suitable_for_renaming, DECL_UID (decl)))
gimple_debug_bind_reset_value (stmt);
}
if (gimple_references_memory_p (stmt)
--- 1651,1666
{
tree *valuep = gimple_debug_bind_get_value_ptr (stmt);
tree decl;
! if (TREE_CODE (*valuep) == ADDR_EXPR)
! decl = get_base_address (TREE_OPERAND (*valuep, 0));
! else
! decl = non_rewritable_mem_ref_base (*valuep);
if (decl
+ DECL_P (decl)
bitmap_bit_p (suitable_for_renaming, DECL_UID (decl)))
gimple_debug_bind_reset_value (stmt);
+ else
+ maybe_rewrite_mem_ref_base (valuep, suitable_for_renaming);
}
if (gimple_references_memory_p (stmt)
Jakub
Re: [PATCH ARM]Refine scaled address expression on ARM
On Fri, Nov 29, 2013 at 5:10 PM, Yufeng Zhang yufeng.zh...@arm.com wrote:
On 11/29/13 10:44, Richard Biener wrote:
On Fri, Nov 29, 2013 at 8:52 AM, Bin.Chengamker.ch...@gmail.com wrote:
On Thu, Nov 28, 2013 at 8:06 PM, Bin.Chengamker.ch...@gmail.com wrote:
On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshawrearn...@arm.com
wrote:
On 18/09/13 10:15, bin.cheng wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of bin.cheng
Sent: Monday, September 02, 2013 3:09 PM
To: Richard Earnshaw
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [PATCH ARM]Refine scaled address expression on ARM
-Original Message-
From: Richard Earnshaw
Sent: Thursday, August 29, 2013 9:06 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH ARM]Refine scaled address expression on ARM
On 28/08/13 08:00, bin.cheng wrote:
Hi,
This patch refines scaled address expression on ARM. It supports
base+index*scale in arm_legitimate_address_outer_p. It also
tries
to legitimize base + index * scale + offset with reg- base +
offset; reg
+ index * scale by introducing thumb2_legitimize_address. For now
+ function
thumb2_legitimize_address is a kind of placeholder and just does
the
mentioned transformation by calling to try_multiplier_address.
Hoping we can improve it in the future.
With this patch:
1) base+index*scale is recognized.
That's because (PLUS (REG) (MULT (REG) (CONST))) is not canonical
form.
So this shouldn't be necessary. Can you identify where this
non-canoncial form is being generated?
Oh, for now ivopt constructs index*scale to test whether backend
supports scaled addressing mode, which is not valid on ARM, so I was
going
to construct base + index*scale instead. Since base + index *
scale
is not
canonical form, I will construct the canonical form and drop this
part of
the
patch.
Is rest of this patch OK?
Hi Richard, I removed the part over which you concerned and created
this
updated patch.
Is it OK?
Thanks.
bin
2013-09-18 Bin Chengbin.ch...@arm.com
* config/arm/arm.c (try_multiplier_address): New function.
(thumb2_legitimize_address): New function.
(arm_legitimize_address): Call try_multiplier_address and
thumb2_legitimize_address.
6-arm-scaled_address-20130918.txt
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c (revision 200774)
+++ gcc/config/arm/arm.c (working copy)
@@ -6652,6 +6654,106 @@ legitimize_tls_address (rtx x, rtx reg)
}
}
+/* Try to find address expression like base + index * scale + offset
+ in X. If we find one, force base + offset into register and
+ construct new expression reg + index * scale; return the new
+ address expression if it's valid. Otherwise return X. */
+static rtx
+try_multiplier_address (rtx x, enum machine_mode mode
ATTRIBUTE_UNUSED)
+{
+ rtx tmp, base_reg, new_rtx;
+ rtx base = NULL_RTX, index = NULL_RTX, scale = NULL_RTX, offset =
NULL_RTX;
+
+ gcc_assert (GET_CODE (x) == PLUS);
+
+ /* Try to find and record base/index/scale/offset in X. */
+ if (GET_CODE (XEXP (x, 1)) == MULT)
+{
+ tmp = XEXP (x, 0);
+ index = XEXP (XEXP (x, 1), 0);
+ scale = XEXP (XEXP (x, 1), 1);
+ if (GET_CODE (tmp) != PLUS)
+ return x;
+
+ base = XEXP (tmp, 0);
+ offset = XEXP (tmp, 1);
+}
+ else
+{
+ tmp = XEXP (x, 0);
+ offset = XEXP (x, 1);
+ if (GET_CODE (tmp) != PLUS)
+ return x;
+
+ base = XEXP (tmp, 0);
+ scale = XEXP (tmp, 1);
+ if (GET_CODE (base) == MULT)
+ {
+ tmp = base;
+ base = scale;
+ scale = tmp;
+ }
+ if (GET_CODE (scale) != MULT)
+ return x;
+
+ index = XEXP (scale, 0);
+ scale = XEXP (scale, 1);
+}
+
+ if (CONST_INT_P (base))
+{
+ tmp = base;
+ base = offset;
+ offset = tmp;
+}
+
+ if (CONST_INT_P (index))
+{
+ tmp = index;
+ index = scale;
+ scale = tmp;
+}
+
+ /* ARM only supports constant scale in address. */
+ if (!CONST_INT_P (scale))
+return x;
+
+ if (GET_MODE (base) != SImode || GET_MODE (index) != SImode)
+return x;
+
+ /* Only register/constant are allowed in each part. */
+ if (!symbol_mentioned_p (base)
+ !symbol_mentioned_p (offset)
+ !symbol_mentioned_p (index)
+ !symbol_mentioned_p (scale))
+{
It would be easier to do this at the top of the function --
if (symbol_mentioned_p (x))
return x;
+ /* Force base+offset into register and construct
+ register+index*scale. Return the new expression
+ only if it's valid. */
+ tmp = gen_rtx_PLUS (SImode, base, offset);
+ base_reg = force_reg (SImode, tmp);
+ tmp = gen_rtx_fmt_ee (MULT, SImode, index, scale);
+
Re: [PATCH] Fix PR59199
On Mon, 2 Dec 2013, Jakub Jelinek wrote:
On Mon, Dec 02, 2013 at 12:05:57PM +0100, Richard Biener wrote:
The following fixes a bug in update_address_taken which fails
to reset debug stmts which take the address of a decl we will
rewrite into SSA form. Our verifiers don't catch this because
of an early out in the operand scanner which doesn't work in
the specific case of LTO profiledbootstrap (or because we
don't have more specific checking for this case).
Fixed like the following.
LTO profiledbootstrapped on x86_64-unknown-linux-gnu, regular
bootstrap regtest still running.
Taking address of a decl that is no longer addressable in debug stmts
is correct, that is how we generate DW_OP_GNU_implicit_ptr.
So I think this patch is going to cause huge amount of debug info quality
regressions.
Does it? Note the decls in question will be renamed to SSA form,
so not sure what implicit pointer you'll build here...? And
what can you do with that pointer inside the debugger?
If that's desired IL (having both DECL and SSA_NAMEs of that DECL
in the IL) then explicit support for this needs to be added to
the operand scanner.
Richard.
2013-12-02 Richard Biener rguent...@suse.de
PR middle-end/59199
* tree-ssa.c (execute_update_addresses_taken): Reset debug
stmts that take the address of a no longer addressable decl.
Index: gcc/tree-ssa.c
===
*** gcc/tree-ssa.c (revision 205528)
--- gcc/tree-ssa.c (working copy)
*** execute_update_addresses_taken (void)
*** 1651,1661
{
tree *valuep = gimple_debug_bind_get_value_ptr (stmt);
tree decl;
! maybe_rewrite_mem_ref_base (valuep, suitable_for_renaming);
! decl = non_rewritable_mem_ref_base (*valuep);
if (decl
bitmap_bit_p (suitable_for_renaming, DECL_UID (decl)))
gimple_debug_bind_reset_value (stmt);
}
if (gimple_references_memory_p (stmt)
--- 1651,1666
{
tree *valuep = gimple_debug_bind_get_value_ptr (stmt);
tree decl;
! if (TREE_CODE (*valuep) == ADDR_EXPR)
! decl = get_base_address (TREE_OPERAND (*valuep, 0));
! else
! decl = non_rewritable_mem_ref_base (*valuep);
if (decl
+DECL_P (decl)
bitmap_bit_p (suitable_for_renaming, DECL_UID (decl)))
gimple_debug_bind_reset_value (stmt);
+ else
+ maybe_rewrite_mem_ref_base (valuep, suitable_for_renaming);
}
if (gimple_references_memory_p (stmt)
Jakub
--
Richard Biener rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendorffer
[ping^2] [patch] contrib/config-list.mk: Allow to build all targets individually
On Wed, 2013-11-27 02:43:08 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Sun, 2013-11-24 20:02:43 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote: 2013-11-24 Jan-Benedict Glaw jbg...@lug-owl.de * config-list.mk (host_options): Allow to override it. (LIST): Change = to EQUAL. (list): New target listing all configurations. ($(LIST)): Substitute EQUAL back to =. Ping^2: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03425.html MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html the second : signature.asc Description: Digital signature
Re: Ping Re: [gomp4] Dumping gimple for offload.
On Fri, Nov 29, 2013 at 4:03 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Nov 29, 2013 at 01:36:48PM +0100, Richard Biener wrote: Thoughts, comments? Does anyone have a good name for these accelerator targets or output targets, something that avoids the overloaded word target (I was thinking destination machine maybe)? I think offload is best word here. Note that we (SUSE/AMD) sofar think we can go an easier route, not adding a real backend that targets HSAIL/BRIG but instead use a custom GIMPLE SSA - HSAIL/BRIG translator (including a SSA based register allocator). Which if course simplifies driving this a bit as we don't need to write/read any GIMPLE. The idea is of course that the highlevel target languages, being it HSAIL/BRIG or PTX run through another compiler + optimizer anyway, so machine specific optimization is not necessary (fingers crossing...). Not sure if anybody announced it yet (but gcc-cvs readers may have noticed), there is a 'hsa' branch in svn covering work done sofar (see gcc/README.hsa for how to use it). But you probably don't want to translate GIMPLE right out of IPA into HSAIL/BRIG, do you? Actually we do currently. And various further passes depend already (well, also the early ones a little bit, but that is something to fix) heavily on targetm.* and target macros, so do you plan to switch targetm to something else and compile again a subset of functions for the HSAIL target? Otherwise, how could you e.g. vectorize code (assuming HSAIL has vector support)? Yeah, we seem to run host specific passes before HSAIL/BRIG generation so we have to address this somehow. Richard. Jakub
[ipa PATCH] Fix bug introduced by r202567
Hi All, Attached is evident fix found in process of investigation of PR 58721. Note that this fix does not resolve it. Is it OK for trunk? ChangeLog: 2013-11-02 Yuri Rumyantsev ysrum...@gmail.com * gcc/ipa-inline.c (check_callers) : Add missed pointer de-reference. ipa-inline-fix Description: Binary data
PATCH: PR driver/59321: -fuse-ld has no effect on -print-prog-name nor on --with-ld=
Hi,
ld is a special name for GCC driver. find_a_file has
#ifdef DEFAULT_LINKER
if (! strcmp (name, ld) access (DEFAULT_LINKER, mode) == 0)
return xstrdup (DEFAULT_LINKER);
#endif
#endif
It does 2 things:
1. Print DEFAULT_LINKER for -print-prog-name=ld.
2. Run DEFAULT_LINKER when ld is needed to run.
But gcc.c fails to check -print-prog-name=ld with -fuse-ld= and
collect2.c fails to properly handle -fuse-ld= when DEFAULT_LINKER
is defined. This patches fixes those 2 problems:
1. Check ld + suffix specicied by -fuse-ld= for -print-prog-name=ld.
2. Try DEFAULT_LINKER + suffix specicied by -fuse-ld=.
This patch also tries to handle HOST_EXECUTABLE_SUFFIX. Tested on
Linux/x86. OK to install?
Thanks.
H.J.
---
2013-11-30 H.J. Lu hongjiu...@intel.com
PR driver/59321
* collect2.c (main): Check -fuse-ld=[bfd|gold] when
DEFAULT_LINKER is defined.
* gcc.c (use_ld): New variable.
(process_command): Set use_ld for OPT_fuse_ld_bfd and
OPT_fuse_ld_gold.
(main): Check -fuse-ld=[bfd|gold] for -print-prog-name=ld.
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 95f817d..1d8ea4f 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -1121,7 +1121,35 @@ main (int argc, char **argv)
/* Maybe we know the right file to use (if not cross). */
ld_file_name = 0;
#ifdef DEFAULT_LINKER
- if (access (DEFAULT_LINKER, X_OK) == 0)
+ if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD)
+{
+ char *linker_name;
+# ifdef HOST_EXECUTABLE_SUFFIX
+ int len = (sizeof (DEFAULT_LINKER)
+- sizeof (HOST_EXECUTABLE_SUFFIX));
+ linker_name = NULL;
+ if (len 0)
+ {
+ char *default_linker = xstrdup (DEFAULT_LINKER);
+ /* Strip HOST_EXECUTABLE_SUFFIX if DEFAULT_LINKER contains
+HOST_EXECUTABLE_SUFFIX. */
+ if (! strcmp (default_linker[len], HOST_EXECUTABLE_SUFFIX))
+ {
+ default_linker[len] = '\0';
+ linker_name = concat (default_linker,
+ ld_suffixes[selected_linker][2],
+ HOST_EXECUTABLE_SUFFIX, NULL);
+ }
+ }
+ if (linker_name == NULL)
+# endif
+ linker_name = concat (DEFAULT_LINKER,
+ ld_suffixes[selected_linker][2],
+ NULL);
+ if (access (linker_name, X_OK) == 0)
+ ld_file_name = linker_name;
+}
+ if (ld_file_name == 0 access (DEFAULT_LINKER, X_OK) == 0)
ld_file_name = DEFAULT_LINKER;
if (ld_file_name == 0)
#endif
diff --git a/gcc/gcc.c b/gcc/gcc.c
index b895f22..68b3df6 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -105,6 +105,9 @@ static int verbose_only_flag;
static int print_subprocess_help;
+/* Linker suffix passed to -fuse-ld=... */
+static const char *use_ld;
+
/* Whether we should report subprocess execution times to a file. */
FILE *report_times_to_file = NULL;
@@ -3952,6 +3955,10 @@ process_command (unsigned int decoded_options_count,
free (fname);
continue;
}
+ else if (decoded_options[j].opt_index == OPT_fuse_ld_bfd)
+ use_ld = .bfd;
+ else if (decoded_options[j].opt_index == OPT_fuse_ld_gold)
+ use_ld = .gold;
read_cmdline_option (global_options, global_options_set,
decoded_options + j, UNKNOWN_LOCATION,
@@ -6708,6 +6715,38 @@ main (int argc, char **argv)
if (print_prog_name)
{
+ if (use_ld != NULL ! strcmp (print_prog_name, ld))
+ {
+ /* Append USE_LD to to the default linker. */
+#ifdef DEFAULT_LINKER
+ char *ld;
+# ifdef HAVE_HOST_EXECUTABLE_SUFFIX
+ int len = (sizeof (DEFAULT_LINKER)
+- sizeof (HOST_EXECUTABLE_SUFFIX));
+ ld = NULL;
+ if (len 0)
+ {
+ char *default_linker = xstrdup (DEFAULT_LINKER);
+ /* Strip HOST_EXECUTABLE_SUFFIX if DEFAULT_LINKER contains
+HOST_EXECUTABLE_SUFFIX. */
+ if (! strcmp (default_linker[len], HOST_EXECUTABLE_SUFFIX))
+ {
+ default_linker[len] = '\0';
+ ld = concat (default_linker, use_ld,
+ HOST_EXECUTABLE_SUFFIX, NULL);
+ }
+ }
+ if (ld == NULL)
+# endif
+ ld = concat (DEFAULT_LINKER, use_ld, NULL);
+ if (access (ld, X_OK) == 0)
+ {
+ printf (%s\n, ld);
+ return (0);
+ }
+#endif
+ print_prog_name = concat (print_prog_name, use_ld, NULL);
+ }
char *newname = find_a_file (exec_prefixes, print_prog_name, X_OK, 0);
printf (%s\n, (newname ? newname : print_prog_name));
return (0);
Re: [PATCH, testsuite] Fix some testcases for nds32 target and provide new nds32 target specific tests
On 11/30/13, 9:07 AM, Mike Stump wrote:
On Nov 28, 2013, at 2:03 AM, Chung-Ju Wu jasonw...@gmail.com wrote:
There is a pending testsuite patch for nds32 target:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01584.html
Is it OK for trunk? :)
Ok, but please remove:
{ target nds32*-*-* }
Ah... I see. Since I have following code fragment in nds32.exp:
# Exit immediately if this isn't a nds32 target.
if ![istarget nds32*-*-*] then {
return
}
all the { target nds32*-*-* } from gcc.target test cases are unnecessary.
Thanks. Remove it accordingly.
from the gcc.target test cases, it is not redundant with the .exp file.
A few oddities I will note, if you can improve them… that'd be nice:
+/* { dg-skip-if Variadic funcs arguments will push by caller for current
nds32 porting. { nds32*-*-* } } */
This is a bit weird. There isn't a notion of current, there isn't a notion
of porting. Variadic funcs arguments are caller pushed?
There are two approaches to deal with variadic function arguments
and I had a post on:
http://gcc.gnu.org/ml/gcc-help/2013-03/msg00208.html
So far, in the nds32 port, we are using the approach like aarch64/avr does.
This test case is almost the same as gcc/testsuite/gcc.dg/builtin-apply2.c file.
Perhaps I should have used the following description, which seems much better:
+/* { dg-skip-if Variadic funcs have all args on stack. Normal funcs have args
in registers. { nds32*-*-* } * } */
+/* { dg-skip-if nds32 target has special operations for 64-bit behavior {
nds32*-*-* } { * } { } } */
This is a bit weird.
Oops, you are right.
That is a legacy modification which is not
suitable for the nds32 port on trunk.
Thanks for the catch. I will not commit that bit.
Thank you for the review and approval.
Attachment is the revised patch and I will apply it
tomorrow if there is no other comment. :)
Best regards,
jasonwucj
diff --git gcc/testsuite/g++.dg/other/PR23205.C
gcc/testsuite/g++.dg/other/PR23205.C
index e55710b..26a9dd5 100644
--- gcc/testsuite/g++.dg/other/PR23205.C
+++ gcc/testsuite/g++.dg/other/PR23205.C
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-skip-if No stabs { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-*
hppa*64*-*-* ia64-*-* tile*-*-* *-*-vxworks } { * } { } } */
+/* { dg-skip-if No stabs { aarch64*-*-* mmix-*-* nds32*-*-* *-*-aix*
alpha*-*-* hppa*64*-*-* ia64-*-* tile*-*-* *-*-vxworks } { * } { } } */
/* { dg-options -gstabs+ -fno-eliminate-unused-debug-types } */
const int foobar = 4;
diff --git gcc/testsuite/g++.dg/other/pr23205-2.C
gcc/testsuite/g++.dg/other/pr23205-2.C
index 607e5a2..b25cb73 100644
--- gcc/testsuite/g++.dg/other/pr23205-2.C
+++ gcc/testsuite/g++.dg/other/pr23205-2.C
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-skip-if No stabs { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-*
hppa*64*-*-* ia64-*-* tile*-*-* } { * } { } } */
+/* { dg-skip-if No stabs { aarch64*-*-* mmix-*-* nds32*-*-* *-*-aix*
alpha*-*-* hppa*64*-*-* ia64-*-* tile*-*-* } { * } { } } */
/* { dg-options -gstabs+ -fno-eliminate-unused-debug-types
-ftoplevel-reorder } */
const int foobar = 4;
diff --git gcc/testsuite/gcc.dg/20020312-2.c gcc/testsuite/gcc.dg/20020312-2.c
index 2999100..7562a8d 100644
--- gcc/testsuite/gcc.dg/20020312-2.c
+++ gcc/testsuite/gcc.dg/20020312-2.c
@@ -52,6 +52,8 @@ extern void abort (void);
/* No pic register. */
#elif defined(__moxie__)
/* No pic register. */
+#elif defined(__nds32__)
+/* No pic register. */
#elif defined(__hppa__)
/* PIC register is %r27 or %r19, but is used even without -fpic. */
#elif defined(__pdp11__)
diff --git gcc/testsuite/gcc.dg/builtin-apply2.c
gcc/testsuite/gcc.dg/builtin-apply2.c
index 869f337..3ae2adc 100644
--- gcc/testsuite/gcc.dg/builtin-apply2.c
+++ gcc/testsuite/gcc.dg/builtin-apply2.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-skip-if Variadic funcs have all args on stack. Normal funcs have args
in registers. { aarch64*-*-* avr-*-* } { * } { } } */
+/* { dg-skip-if Variadic funcs have all args on stack. Normal funcs have args
in registers. { aarch64*-*-* avr-*-* nds32*-*-* } { * } { } } */
/* { dg-skip-if Variadic funcs use Base AAPCS. Normal funcs use VFP
variant. { arm*-*-* arm_hf_eabi } { * } { } } */
/* PR target/12503 */
diff --git gcc/testsuite/gcc.dg/sibcall-3.c gcc/testsuite/gcc.dg/sibcall-3.c
index c4460e2..e02a410 100644
--- gcc/testsuite/gcc.dg/sibcall-3.c
+++ gcc/testsuite/gcc.dg/sibcall-3.c
@@ -5,7 +5,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Hans-Peter Nilsson h...@bitrange.com */
-/* { dg-do run { xfail { { cris-*-* crisv32-*-* h8300-*-* hppa*64*-*-*
m32r-*-* mcore-*-* mn10300-*-* xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* } ||
{ arm*-*-* { ! arm32 } } } } } */
+/* { dg-do run { xfail { { cris-*-* crisv32-*-* h8300-*-* hppa*64*-*-*
m32r-*-* mcore-*-* mn10300-*-* nds32*-*-* xstormy16-*-* v850*-*-* vax-*-*
xtensa*-*-* } || { arm*-*-* { ! arm32 } } } } } */
/*
Re: [PATCH i386 4/8] [AVX512] [2/n] Add substed patterns: mask scalar subst.
Hello, On 19 Nov 12:05, Kirill Yukhin wrote: Hello, On 15 Nov 20:03, Kirill Yukhin wrote: Ping? Ping? Ping? -- Thanks, K
Re: PATCH: PR other/59055: gcc.texinfo warnings
On Fri, 8 Nov 2013, H.J. Lu wrote: bugreport.texi has @menu * Criteria: Bug Criteria. Have you really found a bug? * Reporting: Bug Reporting. How to report a bug effectively. * Known: Trouble.Known problems. * Help: Service. Where to ask for help. @end menu That means include order should be bugreport.texi, trouble.texi, service.texi. And we need to specify next, previous and up nodes to Service and Trouble nodes. OK to install? Thanks for looking into this, H.J.! Looking at the logic we have been using elsewhere, I am wondering whether it shouldn't be the order in bugreport.texi that should be adjusted -- switching the Known: Trouble and Reporting: Bug Reporting nodes? That way you could omit 2013-11-08 H.J. Lu hongjiu...@intel.com PR other/59055 * doc/gcc.texi: Move Trouble after Bugs in menu. Include trouble.texi after bugreport.texi. those two changes, and only update bugreport.texi? If this sounds acceptable, please go ahead and make this change. * doc/service.texi: Add next, previous and up nodes to Service nodes. * doc/trouble.texi: Add next, previous and up nodes to Trouble nodes. Why are these necessary? The texinfo documentation say the following about @node: The subsequent arguments are optional—they are the names of the ‘Next’, ‘Previous’, and ‘Up’ pointers, in that order. We strongly recommend omitting them if your Texinfo document is hierarchically organized, as virtually all are Gerald
Re: [PATCH i386 4/8] [AVX512] [5/8] Add substed patterns: rounding subst.
Hello, On 19 Nov 12:08, Kirill Yukhin wrote: Hello, On 15 Nov 20:06, Kirill Yukhin wrote: Ping. Ping. Ping. -- Thanks, K
Re: [PATCH i386 4/8] [AVX512] [7/8] Add substed patterns: `round for expand' subst.
Hello, On 19 Nov 12:12, Kirill Yukhin wrote: Hello, On 15 Nov 20:08, Kirill Yukhin wrote: Is it ok for trunk? Ping. Ping. Ping. -- Thanks, K
Re: [PATCH i386 4/8] [AVX512] [6/8] Add substed patterns: `sae' subst.
Hello, On 19 Nov 12:11, Kirill Yukhin wrote: Hello, On 15 Nov 20:07, Kirill Yukhin wrote: Is it ok for trunk? Ping. Ping. Ping. -- Thanks, K
Re: [PATCH i386 4/8] [AVX512] [8/8] Add substed patterns: `sae-only for expand' subst.
Hello, On 19 Nov 12:14, Kirill Yukhin wrote: Hello, On 15 Nov 20:09, Kirill Yukhin wrote: Is it ok for trunk? Ping. Ping. Ping. -- Thanks, K
Re: libsanitizer merge from upstream r196090
On Mon, Dec 2, 2013 at 3:52 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Another libsanitizer merge from upstream, r196090
(needs attention on ubsan side)
This hopefully fixes various build failures on non-x86-linux platforms,
although I still tested it only on our x86_64 Linux Ubuntu 12.04 box:
rm -rf */{*/,}libsanitizer make -j 50 make -C gcc
check-g{cc,++} RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
asan.exp'
This also fixed tsan; verified on a single small test.
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
I am asking gcc-ubsan maintainers to help me decipher dejagnu
diagnostics and fix the test failure.
I am ready to make any reasonable additional testing that
can be done on x86_64 Linux Ubuntu 12.04.
The upstream bots on Mac and Linux (x86, x86_64, ARM) are green.
We also verified that the upstream source builds (but does not really
work) on PowerPC64
Expected ChangeLog entries:
=== libsanitizer/ChangeLog
2013-12-0X Kostya Serebryany k...@google.com
* All source files: Merge from upstream r196090.
* tsan/Makefile.am (tsan_files): Added new files.
* tsan/Makefile.in: Regenerate.
* sanitizer_common/Makefile.am (sanitizer_common_files): Added new
fles.
* sanitizer_common/Makefile.in: Regenerate.
* lsan/Makefile.am (lsan_files): Added new files.
* lsan/Makefile.in: Regenerate.
=== gcc/testsuite/ChangeLog
2013-12-0X Kostya Serebryany k...@google.com
* c-c++-common/asan/null-deref-1.c: Update the test
to match the fresh asan run-time.
--kcc
Does it support using libbacktrace in GCC?
--
H.J.
Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.
Hello, On 19 Nov 12:14, Kirill Yukhin wrote: Hello, On 15 Nov 20:10, Kirill Yukhin wrote: Is it ok to commit to main trunk? Ping. Ping. Ping. -- Thanks, K
Re: [PATCH i386 6/8] [AVX-512] Add builtins/intrinsics.
Hello Ok for trunk? Ping? -- Thanks, K
[C++,doc] vector conditional expression
Ping. On Fri, 13 Sep 2013, Marc Glisse wrote: Ping http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01381.html On Fri, 23 Aug 2013, Marc Glisse wrote: On Sun, 4 Aug 2013, Gerald Pfeifer wrote: On Sat, 13 Jul 2013, Marc Glisse wrote: 2013-07-14 Marc Glisse marc.gli...@inria.fr gcc/cp/ * call.c (build_conditional_expr_1): Handle the case with 1 vector and 2 scalars. Call save_expr before building a vector. * typeck.c (cp_build_binary_op): Check complain before complaining. Shouldn't this be documented somewhere (gcc/doc/*.texi and our web based release notes)? Yes, it should. I had posted this some time ago: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00664.html Here is an updated version that also mentions the new scalar case: 2013-08-23 Marc Glisse marc.gli...@inria.fr * doc/extend.texi (Vector Extensions): Document ?: in C++. -- Marc Glisse
Re: [PATCH i386 7/8] [AVX-512] Add tests.
Hello, Is it ok now? Ping? -- Thanks, K
Re: [ipa PATCH] Fix bug introduced by r202567
On Mon, Dec 2, 2013 at 1:36 PM, Yuri Rumyantsev ysrum...@gmail.com wrote: Hi All, Attached is evident fix found in process of investigation of PR 58721. Note that this fix does not resolve it. Is it OK for trunk? Ok. Thanks, Richard. ChangeLog: 2013-11-02 Yuri Rumyantsev ysrum...@gmail.com * gcc/ipa-inline.c (check_callers) : Add missed pointer de-reference.
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 05:13:45AM -0800, H.J. Lu wrote: === libsanitizer/ChangeLog 2013-12-0X Kostya Serebryany k...@google.com * All source files: Merge from upstream r196090. * tsan/Makefile.am (tsan_files): Added new files. * tsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.am (sanitizer_common_files): Added new fles. * sanitizer_common/Makefile.in: Regenerate. * lsan/Makefile.am (lsan_files): Added new files. * lsan/Makefile.in: Regenerate. === gcc/testsuite/ChangeLog 2013-12-0X Kostya Serebryany k...@google.com * c-c++-common/asan/null-deref-1.c: Update the test to match the fresh asan run-time. --kcc Does it support using libbacktrace in GCC? Not on it's own, but the support in the upstream maintained files is there, so hopefully it will be just a matter of follow-up patch with configury/Makefile etc. stuff, I'll work on it once the merge is committed. What is more important now is to test the patch Kostya posted on non-x86_64 targets and/or older kernel headers (say RHEL5, older SLES, etc.). Jakub
Re: [PING^2] [PATCH] PR59063
So ok to commit this fix? --- From: Yury Gribov y.gri...@samsung.com Sent: Monday, December 02, 2013 10:12AM To: Andreas Schwab sch...@linux-m68k.org Cc: Jakub Jelinek ja...@redhat.com, gcc-patches@gcc.gnu.org, eugeni.stepa...@gmail.com, VandeVondele Joost joost.vandevond...@mat.ethz.ch, Evgeny Gavrin e.gav...@samsung.com, Viacheslav Garbuzov v.garbu...@samsung.com Subject: Re: [PING^2] [PATCH] PR59063 On 12/02/2013 10:12 AM, Yury Gribov wrote: This is causing all the tests being run on all targets, even if libsanitizer is not supported, most of them failing due to link errors. Thanks for the info and sorry about this. I should probably check non-sanitized platforms as well before commiting patches. Does the attached patch make sense to you? Worked for me on x64 and x64 with manually disabled libsanitizer. -Y
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
I am asking gcc-ubsan maintainers to help me decipher dejagnu
diagnostics and fix the test failure.
Ok, reproduced. I'll look into it.
Marek
Re: Add TREE_INT_CST_OFFSET_NUNITS
Richard Biener richard.guent...@gmail.com writes:
On Sat, Nov 30, 2013 at 10:43 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
So maybe two INTEGER_CST lengths weren't enough. Because bitsizetype
can be offset_int-sized, wi::to_offset had a TYPE_PRECISION condition
to pick the array length:
template int N
inline unsigned int
wi::extended_tree N::get_len () const
{
if (N == MAX_BITSIZE_MODE_ANY_INT
|| N TYPE_PRECISION (TREE_TYPE (m_t)))
return TREE_INT_CST_EXT_NUNITS (m_t);
else
return TREE_INT_CST_NUNITS (m_t);
}
and this TYPE_PRECISION condition was relatively hot in
get_ref_base_and_extent when compiling insn-recog.ii.
Adding a third length for offset_int does seem to reduce the cost of
the offset_int + to_offset addition.
Tested on x86_64-linux-gnu. OK to install?
Hmm, that's now getting a bit excessive ...
Well, we access trees in three different ways, and we want all of them
to be cheap, so having three fields in the tree seems pretty natural.
inline unsigned int
wi::extended_tree N::get_len () const
{
- if (N == MAX_BITSIZE_MODE_ANY_INT
- || N TYPE_PRECISION (TREE_TYPE (m_t)))
+ if (N == ADDR_MAX_PRECISION)
+return TREE_INT_CST_OFFSET_NUNITS (m_t);
+ else if (N == MAX_BITSIZE_MODE_ANY_INT
+ || N TYPE_PRECISION (TREE_TYPE (m_t)))
return TREE_INT_CST_EXT_NUNITS (m_t);
else
return TREE_INT_CST_NUNITS (m_t);
Shouldn't it be N = TYPE_PRECISION () btw?
No, TREE_INT_CST_NUNITS is for accessing the tree in TYPE_PRECISION
and TREE_INT_CST_EXT_NUNITS is for accessing it in wider precisions.
N is always = TYPE_PRECISION here, from the assert in the constructor:
gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) = N);
TREE_INT_CST_OFFSET_NUNITS is just a cached x ? TREE_INT_CST_NUNITS (m_t)
: TREE_INT_CST_EXT_NUNITS (m_t) result for a particular precision.
Looking at the implementation it seems it would also work with
return MIN (TREE_INT_CST_EXT_NUNITS (m_t), N / HOST_BITS_PER_WIDE_INT);
Yeah, the MIN in the patch was probably bogus sorry. It only works
if we can assume that no bitsizetype will have ADDR_MAX_PRECISION
significant (non-sign) bits -- in particular that there's no such thing as
an all-1s _unsigned_ bitsizetype. That might be true in practice given
the way we use offsets, but it isn't safe to generalise that to all N.
A safer form would be:
if (ext_len OFFSET_INT_ELTS)
TREE_INT_CST_OFFSET_NUNITS (t) = len;
else
TREE_INT_CST_OFFSET_NUNITS (t) = ext_len;
The reason the general form doesn't work for all N is because of the
compressed representation. E.g. the example I gave a while ago about
a 256-bit all-1s unsigned number being { -1 } as a 256-bit number and
{ -1, -1, -1, -1, 0 } as a 257+-bit number.
But the point of the patch is to avoid any runtime checks here,
so the TYPE_PRECISION case is never actually used now. I just kept
it around for completeness, since we'd been using it successfully so far.
I can put in a gcc_unreachable if you prefer.
Thanks,
Richard
Re: [PATCH] Fix PR59199
On Mon, 2 Dec 2013, Richard Biener wrote:
On Mon, 2 Dec 2013, Jakub Jelinek wrote:
On Mon, Dec 02, 2013 at 12:05:57PM +0100, Richard Biener wrote:
The following fixes a bug in update_address_taken which fails
to reset debug stmts which take the address of a decl we will
rewrite into SSA form. Our verifiers don't catch this because
of an early out in the operand scanner which doesn't work in
the specific case of LTO profiledbootstrap (or because we
don't have more specific checking for this case).
Fixed like the following.
LTO profiledbootstrapped on x86_64-unknown-linux-gnu, regular
bootstrap regtest still running.
Taking address of a decl that is no longer addressable in debug stmts
is correct, that is how we generate DW_OP_GNU_implicit_ptr.
So I think this patch is going to cause huge amount of debug info quality
regressions.
Does it? Note the decls in question will be renamed to SSA form,
so not sure what implicit pointer you'll build here...? And
what can you do with that pointer inside the debugger?
If that's desired IL (having both DECL and SSA_NAMEs of that DECL
in the IL) then explicit support for this needs to be added to
the operand scanner.
Like the following, LTO profilebootstrapped on x86_64-unknown-linux-gnu,
bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
(must resist applying more TLC to tree-ssa-operands.c at this point...)
Richard.
2013-12-02 Richard Biener rguent...@suse.de
* tree-ssa-operands.c (opf_implicit): Remove.
(opf_address_taken): New flag.
(get_expr_operands): Remove early out, pass down
opf_address_taken for ADDR_EXPRs, add a use operand only
for non-opf_address_taken bases.
(get_indirect_ref_operands): Rename to ...
(get_mem_ref_operands): ... this.
(get_asm_expr_operands): Rename to ...
(get_asm_stmt_operands): ... this.
Index: gcc/tree-ssa-operands.c
===
*** gcc/tree-ssa-operands.c (revision 205585)
--- gcc/tree-ssa-operands.c (working copy)
*** along with GCC; see the file COPYING3.
*** 105,121
VUSE for 'b'. */
#define opf_no_vops (1 1)
- /* Operand is an implicit reference. This is used to distinguish
-explicit assignments in the form of MODIFY_EXPR from
-clobbering sites like function calls or ASM_EXPRs. */
- #define opf_implicit (1 2)
-
/* Operand is in a place where address-taken does not imply addressable. */
#define opf_non_addressable (1 3)
/* Operand is in a place where opf_non_addressable does not apply. */
#define opf_not_non_addressable (1 4)
/* Array for building all the use operands. */
static vectree build_uses;
--- 105,119
VUSE for 'b'. */
#define opf_no_vops (1 1)
/* Operand is in a place where address-taken does not imply addressable. */
#define opf_non_addressable (1 3)
/* Operand is in a place where opf_non_addressable does not apply. */
#define opf_not_non_addressable (1 4)
+ /* Operand is having its address taken. */
+ #define opf_address_taken (1 5)
+
/* Array for building all the use operands. */
static vectree build_uses;
*** mark_address_taken (tree ref)
*** 597,604
FLAGS is as in get_expr_operands. */
static void
! get_indirect_ref_operands (struct function *fn,
! gimple stmt, tree expr, int flags)
{
tree *pptr = TREE_OPERAND (expr, 0);
--- 595,602
FLAGS is as in get_expr_operands. */
static void
! get_mem_ref_operands (struct function *fn,
! gimple stmt, tree expr, int flags)
{
tree *pptr = TREE_OPERAND (expr, 0);
*** maybe_add_call_vops (struct function *fn
*** 664,670
/* Scan operands in the ASM_EXPR stmt referred to in INFO. */
static void
! get_asm_expr_operands (struct function *fn, gimple stmt)
{
size_t i, noutputs;
const char **oconstraints;
--- 662,668
/* Scan operands in the ASM_EXPR stmt referred to in INFO. */
static void
! get_asm_stmt_operands (struct function *fn, gimple stmt)
{
size_t i, noutputs;
const char **oconstraints;
*** get_expr_operands (struct function *fn,
*** 750,760
!is_gimple_debug (stmt))
mark_address_taken (TREE_OPERAND (expr, 0));
- /* If the address is invariant, there may be no interesting
-variable references inside. */
- if (is_gimple_min_invariant (expr))
- return;
-
/* Otherwise, there may be variables referenced inside but there
should be no VUSEs created, since the referenced objects are
not really accessed. The only operands that we should find
--- 748,753
*** get_expr_operands (struct function *fn,
*** 762,775
(GIMPLE does not allow non-registers as array indices). */
Re: Add TREE_INT_CST_OFFSET_NUNITS
On Mon, Dec 2, 2013 at 2:48 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Sat, Nov 30, 2013 at 10:43 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
So maybe two INTEGER_CST lengths weren't enough. Because bitsizetype
can be offset_int-sized, wi::to_offset had a TYPE_PRECISION condition
to pick the array length:
template int N
inline unsigned int
wi::extended_tree N::get_len () const
{
if (N == MAX_BITSIZE_MODE_ANY_INT
|| N TYPE_PRECISION (TREE_TYPE (m_t)))
return TREE_INT_CST_EXT_NUNITS (m_t);
else
return TREE_INT_CST_NUNITS (m_t);
}
and this TYPE_PRECISION condition was relatively hot in
get_ref_base_and_extent when compiling insn-recog.ii.
Adding a third length for offset_int does seem to reduce the cost of
the offset_int + to_offset addition.
Tested on x86_64-linux-gnu. OK to install?
Hmm, that's now getting a bit excessive ...
Well, we access trees in three different ways, and we want all of them
to be cheap, so having three fields in the tree seems pretty natural.
Hmm, I guess you are right :/
inline unsigned int
wi::extended_tree N::get_len () const
{
- if (N == MAX_BITSIZE_MODE_ANY_INT
- || N TYPE_PRECISION (TREE_TYPE (m_t)))
+ if (N == ADDR_MAX_PRECISION)
+return TREE_INT_CST_OFFSET_NUNITS (m_t);
+ else if (N == MAX_BITSIZE_MODE_ANY_INT
+ || N TYPE_PRECISION (TREE_TYPE (m_t)))
return TREE_INT_CST_EXT_NUNITS (m_t);
else
return TREE_INT_CST_NUNITS (m_t);
Shouldn't it be N = TYPE_PRECISION () btw?
No, TREE_INT_CST_NUNITS is for accessing the tree in TYPE_PRECISION
and TREE_INT_CST_EXT_NUNITS is for accessing it in wider precisions.
N is always = TYPE_PRECISION here, from the assert in the constructor:
gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) = N);
TREE_INT_CST_OFFSET_NUNITS is just a cached x ? TREE_INT_CST_NUNITS (m_t)
: TREE_INT_CST_EXT_NUNITS (m_t) result for a particular precision.
Looking at the implementation it seems it would also work with
return MIN (TREE_INT_CST_EXT_NUNITS (m_t), N / HOST_BITS_PER_WIDE_INT);
Yeah, the MIN in the patch was probably bogus sorry. It only works
if we can assume that no bitsizetype will have ADDR_MAX_PRECISION
significant (non-sign) bits -- in particular that there's no such thing as
an all-1s _unsigned_ bitsizetype. That might be true in practice given
the way we use offsets, but it isn't safe to generalise that to all N.
A safer form would be:
if (ext_len OFFSET_INT_ELTS)
TREE_INT_CST_OFFSET_NUNITS (t) = len;
else
TREE_INT_CST_OFFSET_NUNITS (t) = ext_len;
The reason the general form doesn't work for all N is because of the
compressed representation. E.g. the example I gave a while ago about
a 256-bit all-1s unsigned number being { -1 } as a 256-bit number and
{ -1, -1, -1, -1, 0 } as a 257+-bit number.
But the point of the patch is to avoid any runtime checks here,
so the TYPE_PRECISION case is never actually used now. I just kept
it around for completeness, since we'd been using it successfully so far.
I can put in a gcc_unreachable if you prefer.
Yeah, I'd prefer a gcc_unreachable and a comment.
Thanks,
Richard.
Thanks,
Richard
Re: [C++,doc] vector conditional expression
Sorry, I was waiting for Jason to review (since he's the subject
matter expert), and I guess he was waiting for me?
Jason, can you please have a look and approve?
Only one comment from my side:
Index: doc/extend.texi
===
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same type and @code{a} is an
+integer vector of the same size and number of elements as @code{b} and
+@code{c}
Why same size and number of elements in the above? What is the
difference between these two?
Gerald
Re: [C++,doc] vector conditional expression
On Mon, 2 Dec 2013, Gerald Pfeifer wrote:
Only one comment from my side:
Index: doc/extend.texi
===
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same type and @code{a} is an
+integer vector of the same size and number of elements as @code{b} and
+@code{c}
Why same size and number of elements in the above? What is the
difference between these two?
(on x86_64)
A vector of 4 int and a vector of 4 long have the same number of elements
but not the same size.
A vector of 8 int and a vector of 4 long have the same size but not the
same number of elements.
For semantics, we want the same number of elements. To match the hardware,
we want the same size.
--
Marc Glisse
Re: [ipa PATCH] Fix bug introduced by r202567
On Mon, Dec 2, 2013 at 5:30 AM, Marek Polacek pola...@redhat.com wrote: On Mon, Dec 02, 2013 at 02:21:04PM +0100, Richard Biener wrote: On Mon, Dec 2, 2013 at 1:36 PM, Yuri Rumyantsev ysrum...@gmail.com wrote: Hi All, Attached is evident fix found in process of investigation of PR 58721. Note that this fix does not resolve it. Is it OK for trunk? Ok. Thanks, Richard. ChangeLog: 2013-11-02 Yuri Rumyantsev ysrum...@gmail.com * gcc/ipa-inline.c (check_callers) : Add missed pointer de-reference. But please drop the gcc/ prefix from the ChangeLog. Also, no space before :. Marek Hi. I checked it in for Yuri with updated ChangeLog. Thanks. -- H.J.
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
I am asking gcc-ubsan maintainers to help me decipher dejagnu
diagnostics and fix the test failure.
Ok, reproduced. I'll look into it.
Well, this should help. The problem is that the testcase, when run,
SIGSEGVed, but since we're doing Ugly Things (VLAs with negative
size), it of course _can_ segfault, we're just relying that it
doesn't.
diff --git a/gcc/testsuite/c-c++-common/ubsan/vla-1.c
b/gcc/testsuite/c-c++-common/ubsan/vla-1.c
index 3e47bd3..1c5d14a 100644
--- a/gcc/testsuite/c-c++-common/ubsan/vla-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/vla-1.c
@@ -13,7 +13,7 @@ main (void)
{
int x = -1;
double di = -3.2;
- V v = -666;
+ V v = -6;
int a[x];
int aa[x][x];
@@ -44,5 +44,5 @@ main (void)
/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value 0(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -1(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -1(\n|\r\n|\r) } */
-/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -666(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -6(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -42(\n|\r\n|\r) } */
Marek
Re: [PATCH] Strict volatile bit-fields clean-up
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hello Richard, as a follow-up patch to the bit-fields patch(es), I wanted to remove the dependencies on the variable flag_strict_volatile_bitfields from expand_assignment and expand_expr_real_1. Additionally I want the access mode of the field to be selected in the memory context, instead of the structure's mode. Boot-strapped and regression-tested on x86_64-linux-gnu. OK for trunk? Ok. Thanks, Richard. Thanks Bernd. FYI - these are my in-flight patches, which would be nice to go into the GCC 4.9.0 release: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02046.html :[PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2 http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02025.html :[PATCH] Fix C++0x memory model for -fno-strict-volatile-bitfields on ARM http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02291.html : [PATCH, PR 57748] Check for out of bounds access, Part 2 http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00581.html :[PATCH, PR 57748] Check for out of bounds access, Part 3 http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00133.html:[PATCH] Fix PR58115
Re: libsanitizer merge from upstream r196090
On Mon, Dec 2, 2013 at 6:41 PM, Marek Polacek pola...@redhat.com wrote:
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
I am asking gcc-ubsan maintainers to help me decipher dejagnu
diagnostics and fix the test failure.
Ok, reproduced. I'll look into it.
Well, this should help. The problem is that the testcase, when run,
SIGSEGVed, but since we're doing Ugly Things (VLAs with negative
size), it of course _can_ segfault, we're just relying that it
doesn't.
Thanks!
Shall I add this change to mine, or you want to commit it separately?
An alternative and more stable fix would be to rewrite the test to run
each case independently
and fail after the report, but that's up to you.
--kcc
diff --git a/gcc/testsuite/c-c++-common/ubsan/vla-1.c
b/gcc/testsuite/c-c++-common/ubsan/vla-1.c
index 3e47bd3..1c5d14a 100644
--- a/gcc/testsuite/c-c++-common/ubsan/vla-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/vla-1.c
@@ -13,7 +13,7 @@ main (void)
{
int x = -1;
double di = -3.2;
- V v = -666;
+ V v = -6;
int a[x];
int aa[x][x];
@@ -44,5 +44,5 @@ main (void)
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value 0(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -1(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -1(\n|\r\n|\r) } */
-/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -666(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -6(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -42(\n|\r\n|\r) } */
Marek
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
I am asking gcc-ubsan maintainers to help me decipher dejagnu
diagnostics and fix the test failure.
Ok, reproduced. I'll look into it.
Well, this should help. The problem is that the testcase, when run,
SIGSEGVed, but since we're doing Ugly Things (VLAs with negative
size), it of course _can_ segfault, we're just relying that it
doesn't.
Suppossedly it might be better to split the main from the test into multiple
functions, with __attribute__((noinline)) and just one invalid VLA in each.
diff --git a/gcc/testsuite/c-c++-common/ubsan/vla-1.c
b/gcc/testsuite/c-c++-common/ubsan/vla-1.c
index 3e47bd3..1c5d14a 100644
--- a/gcc/testsuite/c-c++-common/ubsan/vla-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/vla-1.c
@@ -13,7 +13,7 @@ main (void)
{
int x = -1;
double di = -3.2;
- V v = -666;
+ V v = -6;
int a[x];
int aa[x][x];
@@ -44,5 +44,5 @@ main (void)
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value 0(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -1(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -1(\n|\r\n|\r) } */
-/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -666(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -6(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to
non-positive value -42(\n|\r\n|\r) } */
Jakub
Re: [PATCH] Fix C++0x memory model for -fno-strict-volatile-bitfields on ARM
On Mon, Nov 25, 2013 at 1:07 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hello,
I had forgotten to run the Ada test suite when I submitted the previous
version of this patch.
And indeed there were some Ada test cases failing because in Ada packed
structures are
like bit fields, but without the DECL_BIT_FIELD_TYPE attribute.
I think they may have DECL_BIT_FIELD set though, not sure.
Please find attached the updated version of this patch.
Boot-strapped and regression-tested on x86_64-linux-gnu.
Ok for trunk?
So you mimic what Eric added in get_bit_range? Btw, I'm not sure
the conservative way of failing get_bit_range with not limiting the
access at all is good.
That is, we may want to do
+ /* The C++ memory model naturally applies to byte-aligned fields.
+However, if we do not have a DECL_BIT_FIELD_TYPE but BITPOS or
+BITSIZE are not byte-aligned, there is no need to limit the range
+we can access. This can occur with packed structures in Ada. */
+ if (bitregion_start == 0 bitregion_end == 0
+ bitsize 0
+ bitsize % BITS_PER_UNIT == 0
+ bitpos % BITS_PER_UNIT == 0)
+ {
+ bitregion_start = bitpos;
+ bitregion_end = bitpos + bitsize - 1;
+ }
thus not else if but also apply it when get_bit_range failed (as it may
fail for other reasons). A better fallback would be to track down
the outermost byte-aligned handled-component and limit the access
to that (though I guess Ada doesn't care at all about the C++ memory
model and only Ada has bit-aligned aggregates).
That said, the patch looks ok as-is to me, let's see if we can clean
things up for the next stage1.
Thanks,
Richard.
Bernd.
On Mon, 18 Nov 2013 11:37:05, Bernd Edlinger wrote:
Hi,
On Fri, 15 Nov 2013 13:30:51, Richard Biener wrote:
That looks like always pretending it is a bit field.
But it is not a bit field, and bitregion_start=bitregion_end=0
means it is an ordinary value.
I don't think it is supposed to mean that. It's supposed to mean
the access is unconstrained.
Ok, agreed, I did not regard that as a feature.
And apparently only the code path in expand_assigment
really has a problem with it.
So here my second attempt at fixing this.
Boot-strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 03:47:18PM +0100, Jakub Jelinek wrote:
On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
I am asking gcc-ubsan maintainers to help me decipher dejagnu
diagnostics and fix the test failure.
Ok, reproduced. I'll look into it.
Well, this should help. The problem is that the testcase, when run,
SIGSEGVed, but since we're doing Ugly Things (VLAs with negative
size), it of course _can_ segfault, we're just relying that it
doesn't.
Suppossedly it might be better to split the main from the test into multiple
functions, with __attribute__((noinline)) and just one invalid VLA in each.
Okay, I'll do this separately.
So, Kostya, I guess just do the merge and I'll take care of that ubsan
fail.
Marek
Re: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2
On Mon, Nov 18, 2013 at 1:11 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi,
This modified test case exposes a bug in the already approved part of the
strict-volatile-bitfields patch:
#include stdlib.h
typedef struct {
char pad;
int arr[0];
} __attribute__((packed)) str;
str *
foo (int* src)
{
str *s = malloc (sizeof (str) + sizeof (int));
s-arr[0] = 0x12345678;
asm volatile(:::memory);
*src = s-arr[0];
return s;
}
As we know this test case triggered a recursion in the store_bit_field on ARM
and on PowerPC,
which is no longer reproducible after this patch is applied:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02025.html
Additionally it triggered a recursion on extract_bit_field, but _only_ on my
local copy of the trunk.
I had this patch installed, but did not expect it to change anything unless
the values are volatile.
That was cased by this hunk in the strict-volatile-bitfields v4 patch:
@@ -1691,45 +1736,19 @@ extract_fixed_bit_field (enum machine_mo
includes the entire field. If such a mode would be larger than
a word, we won't be doing the extraction the normal way. */
- if (MEM_VOLATILE_P (op0)
- flag_strict_volatile_bitfields 0)
- {
- if (GET_MODE_BITSIZE (GET_MODE (op0)) 0)
- mode = GET_MODE (op0);
- else if (target GET_MODE_BITSIZE (GET_MODE (target)) 0)
- mode = GET_MODE (target);
- else
- mode = tmode;
- }
- else
- mode = get_best_mode (bitsize, bitnum, 0, 0,
- MEM_ALIGN (op0), word_mode, MEM_VOLATILE_P
(op0));
+ mode = GET_MODE (op0);
+ if (GET_MODE_BITSIZE (mode) == 0
+ || GET_MODE_BITSIZE (mode) GET_MODE_BITSIZE (word_mode))
+ mode = word_mode;
+ mode = get_best_mode (bitsize, bitnum, 0, 0,
+ MEM_ALIGN (op0), mode, MEM_VOLATILE_P (op0));
if (mode == VOIDmode)
/* The only way this should occur is if the field spans word
boundaries. */
return extract_split_bit_field (op0, bitsize, bitnum, unsignedp);
So the problem started, because initially this function did not look at
GET_MODE(op0)
and always used word_mode. That was changed, but now also affected
non-volatile data.
Now, if we solve this differently and install the C++ memory model patch,
we can avoid to introduce the recursion in the extract path,
and remove these two hunks in the update patch at the same time:
+ else if (MEM_P (str_rtx)
+ MEM_VOLATILE_P (str_rtx)
+ flag_strict_volatile_bitfields 0)
+/* This is a case where -fstrict-volatile-bitfields doesn't apply
+ because we can't do a single access in the declared mode of the field.
+ Since the incoming STR_RTX has already been adjusted to that mode,
+ fall back to word mode for subsequent logic. */
+str_rtx = adjust_address (str_rtx, word_mode, 0);
Attached you'll find a new version of the bitfields-update patch,
it is again relative to the already approved version of the
volatile-bitfields patch v4, part 1/2.
Boot-strapped and regression-tested on X86_64-linux-gnu.
additionally tested with an ARM cross-compiler.
OK for trunk?
Ok.
Thanks,
Richard.
Thanks
Bernd.
Re: [PATCH] Fix PR56344
On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek pola...@redhat.com wrote: Ping. Ok. (yay, oldest patch in my review queue ...) Thanks, Richard. On Tue, Mar 05, 2013 at 05:06:21PM +0100, Marek Polacek wrote: On Fri, Mar 01, 2013 at 09:41:27AM +0100, Richard Biener wrote: On Wed, Feb 27, 2013 at 6:38 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Wed, 27 Feb 2013, Richard Biener wrote: Wouldn't it be better to simply pass this using the variable size handling code? Thus, initialize args_size.var for too large constant size instead? Would that be compatible with the ABI definition of how a large (constant size) argument should be passed? I'm not sure. Another alternative is to expand to __builtin_trap (), but that's probably not easy at this very point. Or simply fix the size calculation to not overflow (either don't count bits or use a double-int). I don't think double_int will help us here. We won't detect overflow, because we overflowed here (when lower_bound is an int): lower_bound = INTVAL (XEXP (XEXP (arg-stack_slot, 0), 1)); The value from INTVAL () fits when lower_bound is a double_int, but then: i = lower_bound; ... stack_usage_map[i] the size of stack_usage_map is stored in highest_outgoing_arg_in_use, which is an int, so we're limited by an int size here. Changing the type of highest_outgoing_arg_in_use from an int to a double_int isn't worth the trouble, IMHO. Maybe the original approach, only with sorry () instead of error () and e.g. HOST_BITS_PER_INT - 1 instead of 30 would be appropriate after all. Dunno. Marek
Re: [PATCH] Fix PR58115
On Sun, Nov 3, 2013 at 11:25 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hello, on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails because of an internal compiler error, see PR58155. The reason for this is that the optab CODE_FOR_movv8sf is disabled when it should be enabled. This happens because invoke_set_current_function_hook changes the pointer this_fn_optabs after targetm.set_current_function has already modified the optab to enable/disable CODE_FOR_movv8sf, leaving that optab entry in an undefined state. Boot-strapped and regression-tested on i686-pc-linux-gnu. Ok for trunk? Ok. Thanks, Richard. Regards Bernd.
Re: [PATCH i386] Enable -freorder-blocks-and-partition
On Thu, Nov 28, 2013 at 6:06 AM, Jan Hubicka hubi...@ucw.cz wrote:
Dear Teresa and Jan,
I tried to test Teresa's patch, but I've encountered two bugs
during usage of -fprofile-generate/use (one in SPEC CPU 2006 and
Inkscape).
Thanks, this is non-LTO run. Is there a chance to get -flto version, too?
So we see how things combine with -freorder-function
This will be probably for Jan:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59266
second one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
There are numbers I recorded for GIMP with and without block reordering.
GIMP (-freorder-blocks-and-partition)
pages read (no readahead): 597 pages (4K)
GIMP (-no-freorder-blocks-and-partition)
pages read (no readahead): 596 pages (4K)
The graphs themselves seems bit odd however, why do we have so many accesses
to cold section with -fno-reorder-blocks-and-partition again?
Comparing the two graphs I don't see additional accesses in the cold
section from -freorder-blocks-and-partition. For the most part the
graphs look identical. In contrast, the graphs Martin had generated
with and without -freorder-blocks-and-partition back in August had a
significant increase in execution out of text.unlikely.
I'm wondering if the -fno-reorder-blocks-and-partition graph really
had that disabled. I am surprised that the size of the .text and
.text.hot did not shrink from splitting. And the accesses in the cold
section in both graphs look suspiciously like the accesses we ended up
with in the cold section when enabling -freorder-blocks-and-partition
back in Aug (although there are certainly a lot fewer than before,
which is good news).
Martin, can you check that the binary used for
-fno-reorder-blocks-and-partition really doesn't have any splitting?
Thanks,
Teresa
Honza
Martin
On 19 November 2013 23:18, Teresa Johnson tejohn...@google.com wrote:
On Tue, Nov 19, 2013 at 9:40 AM, Jeff Law l...@redhat.com wrote:
On 11/19/13 10:24, Teresa Johnson wrote:
On Tue, Nov 19, 2013 at 7:44 AM, Jan Hubicka hubi...@ucw.cz wrote:
Martin,
can you, please, generate the updated systemtap with
-freorder-blocks-and-partition enabled?
I am in favour of enabling this - it is usefull pass and it is pointless
ot
have passes that are not enabled by default.
Is there reason why this would not work on other ELF target? Is it
working
with Darwin and Windows?
I don't know how to test these (I don't see any machines listed in the
gcc compile farm of those types). For Windows, I assume you mean
MinGW, which should be enabled as it is under i386. Should I disable
it there and for Darwin?
This patch enables -freorder-blocks-and-partition by default for x86
at -O2 and up. It is showing some modest gains in cpu2006 performance
with profile feedback and -O2 on an Intel Westmere system.
Specifically,
I am seeing consistent improvements in 401.bzip2 (1.5-3%),
483.xalancbmk
(1.5-3%), and 453.povray (2.5-3%), and no apparent regressions.
This actually sounds very good ;)
Lets see how the systemtap graphs goes. If we will end up with problem
of too many accesses to cold section, I would suggest making cold
section
subdivided into .unlikely and .unlikely.part (we could have better name)
with the second consisting only of unlikely parts of hotnormal
functions.
This should reduce the problems we are seeing with mistakely identifying
code to be cold because of roundoff errors (and it probably makes sense
in general, too).
We will however need to update gold and ld for that.
Note that I don't think this would help much unless the linker is
changed to move the cold split section close to the hot section. There
is probably some fine-tuning we could do eventually in the linker
under -ffunction-sections without putting the split portions in a
separate section. I.e. clump the split parts together within unlikely.
But hopefully this can all be done later on as follow-on work to boost
the performance further.
Bootstrapped and tested on x86-64-unknown-linux-gnu with a normal
bootstrap, a profiledbootstrap and an LTO profiledbootstrap. All were
configured with --enable-languages=all,obj-c++ and tested for both
32 and 64-bit with RUNTESTFLAGS=--target_board=unix\{-m32,-m64\}.
It would be good to enable this for additional targets as a follow on,
but it needs more testing for both correctness and performance on those
other targets (i.e for correctness because I see a number of places
in other config/*/*.c files that do some special handling under this
option for different targets or simply disable it, so I am not sure
how well-tested it is under different architectural constraints).
Ok for trunk?
Thanks,
Teresa
2013-11-19 Teresa Johnson tejohn...@google.com
* common/config/i386/i386-common.c: Enable
-freorder-blocks-and-partition at -O2 and up for x86.
* opts.c
[PATCH] Fix PR59139
This fixes PR59139, ternary support was missing from get_val_for.
Instead of supporting it I simply chose to properly disable its
support.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-12-02 Richard Biener rguent...@suse.de
PR tree-optimization/59139
* tree-ssa-loop-niter.c (chain_of_csts_start): Properly match
code in get_val_for.
(get_val_for): Use gcc_checking_asserts.
* gcc.dg/torture/pr59139.c: New testcase.
Index: gcc/tree-ssa-loop-niter.c
===
*** gcc/tree-ssa-loop-niter.c (revision 205585)
--- gcc/tree-ssa-loop-niter.c (working copy)
*** chain_of_csts_start (struct loop *loop,
*** 2075,2081
return NULL;
}
! if (gimple_code (stmt) != GIMPLE_ASSIGN)
return NULL;
code = gimple_assign_rhs_code (stmt);
--- 2075,2082
return NULL;
}
! if (gimple_code (stmt) != GIMPLE_ASSIGN
! || gimple_assign_rhs_class (stmt) == GIMPLE_TERNARY_RHS)
return NULL;
code = gimple_assign_rhs_code (stmt);
*** get_val_for (tree x, tree base)
*** 2143,2149
{
gimple stmt;
! gcc_assert (is_gimple_min_invariant (base));
if (!x)
return base;
--- 2144,2150
{
gimple stmt;
! gcc_checking_assert (is_gimple_min_invariant (base));
if (!x)
return base;
*** get_val_for (tree x, tree base)
*** 2152,2158
if (gimple_code (stmt) == GIMPLE_PHI)
return base;
! gcc_assert (is_gimple_assign (stmt));
/* STMT must be either an assignment of a single SSA name or an
expression involving an SSA name and a constant. Try to fold that
--- 2153,2159
if (gimple_code (stmt) == GIMPLE_PHI)
return base;
! gcc_checking_assert (is_gimple_assign (stmt));
/* STMT must be either an assignment of a single SSA name or an
expression involving an SSA name and a constant. Try to fold that
Index: gcc/testsuite/gcc.dg/torture/pr59139.c
===
*** gcc/testsuite/gcc.dg/torture/pr59139.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr59139.c (working copy)
***
*** 0
--- 1,20
+ /* { dg-do compile } */
+
+ int a, b, c, d, e;
+ int fn1(p1, p2) { return p2 == 0 ? p1 : 1 % p2; }
+
+ void fn2()
+ {
+ c = 0;
+ for (;; c = (unsigned short)c)
+ {
+ b = 2;
+ for (; b; b = a)
+ {
+ e = fn1(2, c 1);
+ d = c == 0 ? e : c;
+ if (d)
+ return;
+ }
+ }
+ }
Re: wide-int, tree-vec
On Sat, Nov 23, 2013 at 8:23 PM, Mike Stump mikest...@comcast.net wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the tree-vec code. Ok? Ok. Thanks, Richard.
Re: wide-int, misc
On Sat, Nov 23, 2013 at 8:22 PM, Mike Stump mikest...@comcast.net wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the random pieces that didn't seem to fit nicely into other bins. Ok? Ok. Thanks, Richard.
Re: [PING] [PATCH] Optional alternative base_expr in finding basis for CAND_REFs
Ping~
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
Thanks,
Yufeng
On 11/26/13 15:02, Yufeng Zhang wrote:
On 11/26/13 12:45, Richard Biener wrote:
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng Zhangyufeng.zh...@arm.com wrote:
On 11/13/13 20:54, Bill Schmidt wrote:
The second version of your original patch is ok with me with the
following changes. Sorry for the little side adventure into the
next-interp logic; in the end that's going to hurt more than it helps in
this case. Thanks for having a look at it, anyway. Thanks also for
cleaning up this version to be less intrusive to common interfaces; I
appreciate it.
Thanks a lot for the review. I've attached an updated patch with the
suggested changes incorporated.
For the next-interp adventure, I was quite happy to do the experiment; it's
a good chance of gaining insight into the pass. Many thanks for your prompt
replies and patience in guiding!
Everything else looks OK to me. Please ask Richard for final approval,
as I'm not a maintainer.
Hi Richard, would you be happy to OK the patch?
Hmm,
+static tree
+get_alternative_base (tree base)
+{
+ tree *result = (tree *) pointer_map_contains (alt_base_map, base);
+
+ if (result == NULL)
+{
+ tree expr;
+ aff_tree aff;
+
+ tree_to_aff_combination_expand (base, TREE_TYPE (base),
+aff,name_expansions);
+ aff.offset = tree_to_double_int (integer_zero_node);
+ expr = aff_combination_to_tree (aff);
+
+ result = (tree *) pointer_map_insert (alt_base_map, base);
+ gcc_assert (!*result);
I believe this cache will never hit (unless you repeatedly ask for
the exact same statement?) - any non-trivial 'base' trees are
not shared and thus not pointer equivalent.
Yes, you are right about the non-trivial 'base' tree are rarely shared.
The cached is introduced mainly because get_alternative_base () may be
called twice on the same 'base' tree, once in the
find_basis_for_candidate () for look-up and the other time in
alloc_cand_and_find_basis () for record_potential_basis (). I'm happy
to leave out the cache if you think the benefit is trivial.
Also using tree_to_aff_combination_expand to get at - what
exactly? The address with any constant offset stripped?
Where do you re-construct that offset? That is, aff.offset,
which you definitely need to get at a candidate?
As explained in the previous RFC emails, the expanded and
constant-offset-stripped base expr is only used for the purpose of basis
look-up. The corresponding candidate still has the unexpanded base expr
as its 'base_expr', therefore the info on the constant offset is not
lost and doesn't need to be re-constructed.
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-slsr } */
+
+typedef int arr_2[50][50];
+
+void foo (arr_2 a2, int v1)
+{
+ int i, j;
+
+ i = v1 + 5;
+ j = i;
+ a2 [i-10] [j] = 2;
+ a2 [i] [j++] = i;
+ a2 [i+20] [j++] = i;
+ a2 [i-3] [i-1] += 1;
+ return;
+}
+
+/* { dg-final { scan-tree-dump-times MEM 5 slsr } } */
+/* { dg-final { cleanup-tree-dump slsr } } */
scanning for 5 MEMs looks non-sensical. What transform do
you expect? I see other slsr testcases do similar non-sensical
checking which is bad, too.
As the slsr optimizes CAND_REF candidates by simply lowering them to
MEM_REF from e.g. ARRAY_REF, I think scanning for the number of MEM_REFs
is an effective check. Alternatively, I can add a follow-up patch to
add some dumping facility in replace_ref () to print out the replacing
actions when -fdump-tree-slsr-details is on.
I hope these can address your concerns.
Regards,
Yufeng
Richard.
Regards,
Yufeng
gcc/
* gimple-ssa-strength-reduction.c: Include tree-affine.h.
(name_expansions): New static variable.
(alt_base_map): Ditto.
(get_alternative_base): New function.
(find_basis_for_candidate): For CAND_REF, optionally call
find_basis_for_base_expr with the returned value from
get_alternative_base.
(record_potential_basis): Add new parameter 'base' of type 'tree';
add an assertion of non-NULL base; use base to set node-base_expr.
(alloc_cand_and_find_basis): Update; call record_potential_basis
for CAND_REF with the returned value from get_alternative_base.
(execute_strength_reduction): Call pointer_map_create for
alt_base_map; call free_affine_expand_cache withname_expansions.
gcc/testsuite/
* gcc.dg/tree-ssa/slsr-41.c: New test.
diff --git a/gcc/gimple-ssa-strength-reduction.c
b/gcc/gimple-ssa-strength-reduction.c
index 88afc91..26502c3 100644
--- a/gcc/gimple-ssa-strength-reduction.c
+++ b/gcc/gimple-ssa-strength-reduction.c
@@ -53,6 +53,7 @@ along with GCC; see the file COPYING3. If not see
#include params.h
#include hash-table.h
#include tree-ssa-address.h
+#include tree-affine.h
/* Information about a strength reduction candidate. Each statement
in the candidate table
Re: libsanitizer merge from upstream r196090
Hello! Does it support using libbacktrace in GCC? Not on it's own, but the support in the upstream maintained files is there, so hopefully it will be just a matter of follow-up patch with configury/Makefile etc. stuff, I'll work on it once the merge is committed. What is more important now is to test the patch Kostya posted on non-x86_64 targets and/or older kernel headers (say RHEL5, older SLES, etc.). Unfortunately, the build breaks on CentOS 5.10 (= RHEL5) with: libtool: compile: /home/uros/gcc-build-xxx/./gcc/xgcc -shared-libgcc -B/home/uros/gcc-build-xxx/./gcc -nostdinc++ -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-svn/trunk/libsanitizer/sanitizer_common -I ../../../../gcc-svn/trunk/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-unknown-linux-gnu -I../../../../gcc-svn/trunk/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_linux.lo -MD -MP -MF .deps/sanitizer_platform_limits_linux.Tpo -c ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:54:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h ^ compilation terminated. gmake[4]: *** [sanitizer_platform_limits_linux.lo] Error 1 gmake[4]: *** Waiting for unfinished jobs Uros.
[PATCH] Adjust ubsan/vla-1.c test
This patch puts every VLA test into its separate function to make it
less like fail due to stack overflow.
Ran ubsan testsuite, ok for trunk?
2013-12-02 Marek Polacek pola...@redhat.com
testsuite/
* c-c++-common/ubsan/vla-1.c: Split the tests into individual
functions.
--- gcc/testsuite/c-c++-common/ubsan/vla-1.c.mp42013-12-02
16:32:21.139139722 +0100
+++ gcc/testsuite/c-c++-common/ubsan/vla-1.c2013-12-02 16:48:28.791731232
+0100
@@ -1,33 +1,104 @@
/* { dg-do run } */
/* { dg-options -fsanitize=vla-bound -Wall -Wno-unused-variable } */
-static int
+typedef long int V;
+int x = -1;
+double di = -3.2;
+V v = -6;
+
+static int __attribute__ ((noinline, noclone))
bar (void)
{
- return -42;
+ return -4;
}
-typedef long int V;
-int
-main (void)
+static void __attribute__ ((noinline, noclone))
+fn1 (void)
{
- int x = -1;
- double di = -3.2;
- V v = -666;
-
int a[x];
- int aa[x][x];
- int aaa[x][x][x];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn2 (void)
+{
+ int a[x][x];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn3 (void)
+{
+ int a[x][x][x];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn4 (void)
+{
int b[x - 4];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn5 (void)
+{
int c[(int) di];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn6 (void)
+{
int d[1 + x];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn7 (void)
+{
int e[1 ? x : -1];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn8 (void)
+{
int f[++x];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn9 (void)
+{
int g[(signed char) --x];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn10 (void)
+{
int h[(++x, --x, x)];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn11 (void)
+{
int i[v];
+}
+
+static void __attribute__ ((noinline, noclone))
+fn12 (void)
+{
int j[bar ()];
+}
+int
+main (void)
+{
+ fn1 ();
+ fn2 ();
+ fn3 ();
+ fn4 ();
+ fn5 ();
+ fn6 ();
+ fn7 ();
+ fn8 ();
+ fn9 ();
+ fn10 ();
+ fn11 ();
+ fn12 ();
return 0;
}
@@ -44,5 +115,5 @@ main (void)
/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value 0(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -1(\n|\r\n|\r) } */
/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -1(\n|\r\n|\r) } */
-/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -666(\n|\r\n|\r) } */
-/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -42(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -6(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*variable length array bound evaluates to non-positive
value -4(\n|\r\n|\r) } */
Marek
Re: [PATCH] Adjust ubsan/vla-1.c test
On Mon, Dec 02, 2013 at 04:57:49PM +0100, Marek Polacek wrote: This patch puts every VLA test into its separate function to make it less like fail due to stack overflow. Ran ubsan testsuite, ok for trunk? Ok, thanks. 2013-12-02 Marek Polacek pola...@redhat.com testsuite/ * c-c++-common/ubsan/vla-1.c: Split the tests into individual functions. Jakub
Re: libsanitizer merge from upstream r196090
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak ubiz...@gmail.com wrote: Hello! Does it support using libbacktrace in GCC? Not on it's own, but the support in the upstream maintained files is there, so hopefully it will be just a matter of follow-up patch with configury/Makefile etc. stuff, I'll work on it once the merge is committed. What is more important now is to test the patch Kostya posted on non-x86_64 targets and/or older kernel headers (say RHEL5, older SLES, etc.). Unfortunately, the build breaks on CentOS 5.10 (= RHEL5) with: libtool: compile: /home/uros/gcc-build-xxx/./gcc/xgcc -shared-libgcc -B/home/uros/gcc-build-xxx/./gcc -nostdinc++ -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-svn/trunk/libsanitizer/sanitizer_common -I ../../../../gcc-svn/trunk/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-unknown-linux-gnu -I../../../../gcc-svn/trunk/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_linux.lo -MD -MP -MF .deps/sanitizer_platform_limits_linux.Tpo -c ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:54:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h Sounds familiar. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068 Do things work for you w/o my patch in fresh trunk? Is there a way to test gcc in such environment w/o setting up VMs (e.g. chroot, or some such)? --kcc ^ compilation terminated. gmake[4]: *** [sanitizer_platform_limits_linux.lo] Error 1 gmake[4]: *** Waiting for unfinished jobs Uros.
Re: [PATCH i386] Enable -freorder-blocks-and-partition
On 12/02/13 08:16, Teresa Johnson wrote: I'm wondering if the -fno-reorder-blocks-and-partition graph really had that disabled. I am surprised that the size of the .text and .text.hot did not shrink from splitting. Could be due to needing longer jump opcodes to reach the unlikely sections. jeff
Re: libsanitizer merge from upstream r196090
On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: Does it support using libbacktrace in GCC? Not on it's own, but the support in the upstream maintained files is there, so hopefully it will be just a matter of follow-up patch with configury/Makefile etc. stuff, I'll work on it once the merge is committed. What is more important now is to test the patch Kostya posted on non-x86_64 targets and/or older kernel headers (say RHEL5, older SLES, etc.). Unfortunately, the build breaks on CentOS 5.10 (= RHEL5) with: libtool: compile: /home/uros/gcc-build-xxx/./gcc/xgcc -shared-libgcc -B/home/uros/gcc-build-xxx/./gcc -nostdinc++ -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-svn/trunk/libsanitizer/sanitizer_common -I ../../../../gcc-svn/trunk/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-unknown-linux-gnu -I../../../../gcc-svn/trunk/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_linux.lo -MD -MP -MF .deps/sanitizer_platform_limits_linux.Tpo -c ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:54:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h Sounds familiar. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068 Do things work for you w/o my patch in fresh trunk? No, so your patch doesn't regress anything. I can configure with --disable-libsanitizer to skip build of libsanitizer, although it would be nice to support RHEL5 derived long-term distributions. Is there a way to test gcc in such environment w/o setting up VMs (e.g. chroot, or some such)? Maybe gcc compile farm has linux-2.6.18 machine available? Uros.
Re: patch for elimination to SP when it is changed in RTL (PR57293)
On 12/1/2013, 7:57 AM, James Greenhalgh wrote: On Thu, Nov 28, 2013 at 10:11:26PM +, Vladimir Makarov wrote: Committed as rev. 205498. 2013-11-28 Vladimir Makarovvmaka...@redhat.com PR target/57293 * ira.h (ira_setup_eliminable_regset): Remove parameter. * ira.c (ira_setup_eliminable_regset): Ditto. Add SUPPORTS_STACK_ALIGNMENT for crtl-stack_realign_needed. Don't call lra_init_elimination. (ira): Call ira_setup_eliminable_regset without arguments. * loop-invariant.c (calculate_loop_reg_pressure): Remove argument from ira_setup_eliminable_regset call. * gcse.c (calculate_bb_reg_pressure): Ditto. * haifa-sched.c (sched_init): Ditto. * lra.h (lra_init_elimination): Remove the prototype. * lra-int.h (lra_insn_recog_data): New member sp_offset. Move used_insn_alternative upper. (lra_eliminate_regs_1): Add one more parameter. (lra-eliminate): Ditto. * lra.c (lra_invalidate_insn_data): Set sp_offset. (setup_sp_offset): New. (lra_process_new_insns): Call setup_sp_offset. (lra): Add argument to lra_eliminate calls. * lra-constraints.c (get_equiv_substitution): Rename to get_equiv. (get_equiv_with_elimination): New. (process_addr_reg): Call get_equiv_with_elimination instead of get_equiv_substitution. (equiv_address_substitution): Ditto. (loc_equivalence_change_p): Ditto. (loc_equivalence_callback, lra_constraints): Ditto. (curr_insn_transform): Ditto. Print the sp offset (process_alt_operands): Prevent stack pointer reloads. (lra_constraints): Remove one argument from lra_eliminate call. Move it up. Mark used hard regs bfore it. Use get_equiv_with_elimination instead of get_equiv_substitution. * lra-eliminations.c (lra_eliminate_regs_1): Add parameter and assert for param values combination. Use sp offset. Add argument to lra_eliminate_regs_1 calls. (lra_eliminate_regs): Add argument to lra_eliminate_regs_1 call. (curr_sp_change): New static var. (mark_not_eliminable): Add parameter. Update curr_sp_change. Don't prevent elimination to sp if we can calculate its change. Pass the argument to mark_not_eliminable calls. (eliminate_regs_in_insn): Add a parameter. Use sp offset. Add argument to lra_eliminate_regs_1 call. (update_reg_eliminate): Move calculation of hard regs for spill lower. Switch off lra_in_progress temporarily to generate regs involved into elimination. (lra_init_elimination): Rename to init_elimination. Make it static. Set up insn sp offset, check the offsets at the end of BBs. (process_insn_for_elimination): Add parameter. Pass its value to eliminate_regs_in_insn. (lra_eliminate): : Add parameter. Pass its value to process_insn_for_elimination. Add assert for param values combination. Call init_elimination. Don't update offsets in equivalence substitutions. * lra-spills.c (assign_mem_slot): Don't call lra_eliminate_regs_1 for created stack slot. (remove_pseudos): Call lra_eliminate_regs_1 before changing memory onto stack slot. 2013-11-28 Vladimir Makarovvmaka...@redhat.com PR target/57293 * gcc.target/i386/pr57293.c: New. Hi Vlad, This patch seems to cause some problems for AArch64. I see an assert triggering when building libgloss: /work/gcc-clean/build-aarch64-none-elf/obj/gcc1/gcc/xgcc -B/work/gcc-clean/build-aarch64-none-elf/obj/gcc1/gcc/ -B/work/gcc-clean/build-aarch64-none-elf/obj/binutils/aarch64-none-elf/newlib/ -isystem /work/gcc-clean/build-aarch64-none-elf/obj/binutils/aarch64-none-elf/newlib/targ-include -isystem /work/gcc-clean/src/binutils/newlib/libc/include -B/work/gcc-clean/build-aarch64-none-elf/obj/binutils/aarch64-none-elf/libgloss/aarch64 -L/work/gcc-clean/build-aarch64-none-elf/obj/binutils/aarch64-none-elf/libgloss/libnosys -L/work/gcc-clean/src/binutils/libgloss/aarch64 -L/work/gcc-clean/build-aarch64-none-elf/obj/binutils/./ld-O2 -g -O2 -g -I. -I/work/gcc-clean/src/binutils/libgloss/aarch64/.. -DARM_RDI_MONITOR -o rdimon-_exit.o -c /work/gcc-clean/src/binutils/libgloss/aarch64/_exit.c /work/gcc-clean/src/binutils/libgloss/aarch64/_exit.c: In function '_exit': /work/gcc-clean/src/binutils/libgloss/aarch64/_exit.c:41:1: internal compiler error: in update_reg_eliminate, at lra-eliminations.c:1157 } Thanks, James. I'll try to reproduce it with the cross-compiler. I expected that the patch might be disruptive. It is pretty big. Therefore I started to work on it (and the related PRs) first. I'll try to fix as soon as I can.
Re: [PATCH] Fix PR56344
On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek pola...@redhat.com wrote:
Ping.
Ok. (yay, oldest patch in my review queue ...)
;) thanks. Just to be sure, did you mean to ok this patch (that is,
the one with HOST_BITS_PER_INT)?
Bootstrap/regtest in progress.
2013-12-02 Marek Polacek pola...@redhat.com
PR middle-end/56344
* calls.c (expand_call): Disallow passing huge arguments
by value.
--- gcc/calls.c.mp4 2013-12-02 17:12:18.621057873 +0100
+++ gcc/calls.c 2013-12-02 17:32:35.523684716 +0100
@@ -3047,6 +3047,15 @@ expand_call (tree exp, rtx target, int i
{
rtx before_arg = get_last_insn ();
+ /* We don't allow passing huge ( 2^30 B) arguments
+by value. It would cause an overflow later on. */
+ if (adjusted_args_size.constant
+ = (1 (HOST_BITS_PER_INT - 1)))
+ {
+ sorry (passing too large argument on stack);
+ continue;
+ }
+
if (store_one_arg (args[i], argblock, flags,
adjusted_args_size.var != 0,
reg_parm_stack_space)
Marek
Re: libsanitizer merge from upstream r196090
On Mon, Dec 2, 2013 at 5:26 PM, Uros Bizjak ubiz...@gmail.com wrote: On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: Does it support using libbacktrace in GCC? Not on it's own, but the support in the upstream maintained files is there, so hopefully it will be just a matter of follow-up patch with configury/Makefile etc. stuff, I'll work on it once the merge is committed. What is more important now is to test the patch Kostya posted on non-x86_64 targets and/or older kernel headers (say RHEL5, older SLES, etc.). Unfortunately, the build breaks on CentOS 5.10 (= RHEL5) with: libtool: compile: /home/uros/gcc-build-xxx/./gcc/xgcc -shared-libgcc -B/home/uros/gcc-build-xxx/./gcc -nostdinc++ -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/uros/gcc-build-xxx/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-svn/trunk/libsanitizer/sanitizer_common -I ../../../../gcc-svn/trunk/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-unknown-linux-gnu -I../../../../gcc-svn/trunk/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_linux.lo -MD -MP -MF .deps/sanitizer_platform_limits_linux.Tpo -c ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:54:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h Sounds familiar. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068 Do things work for you w/o my patch in fresh trunk? No, so your patch doesn't regress anything. I can configure with --disable-libsanitizer to skip build of libsanitizer, although it would be nice to support RHEL5 derived long-term distributions. Ok, so this does not gate the merge. We can fix this particular failure, but unless someone helps us test the code upstream (not just that it builds, but also that it works) asan has little chance to work on old systems anyway. --kcc Is there a way to test gcc in such environment w/o setting up VMs (e.g. chroot, or some such)? Maybe gcc compile farm has linux-2.6.18 machine available? Uros.
Re: [PATCH i386] Enable -freorder-blocks-and-partition
Dear Teresa, I will today double check if the graphs are correct :) Martin On 2 December 2013 17:16, Jeff Law l...@redhat.com wrote: On 12/02/13 08:16, Teresa Johnson wrote: I'm wondering if the -fno-reorder-blocks-and-partition graph really had that disabled. I am surprised that the size of the .text and .text.hot did not shrink from splitting. Could be due to needing longer jump opcodes to reach the unlikely sections. jeff
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote: We can fix this particular failure, but unless someone helps us test the code upstream (not just that it builds, but also that it works) asan has little chance to work on old systems anyway. For these kernel headers that were added only lately and weren't existing in older kernels, perhaps you can #include linux/version.h and guard the include of such headers plus everything related to that with #if LINUX_VERSION_CODE = 132640 (at least from Kernel's git linux/perf_event.h header has been added in 2.6.32). Or alternatively use configure, but you'd need to use it in both compiler-rt buildsystem and gcc's libsanitizer configure. Jakub
Re: libsanitizer merge from upstream r196090
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term distributions.
Is there a way to test gcc in such environment w/o setting up VMs
(e.g. chroot, or some such)?
Maybe gcc compile farm has linux-2.6.18 machine available?
That or perhaps try say:
mkdir ~/centos5
cd ~/centos5
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/glibc-devel-2.5-118.x86_64.rpm
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/glibc-headers-2.5-118.x86_64.rpm
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/kernel-headers-2.6.18-371.el5.x86_64.rpm
for i in *.rpm; do
rpm2cpio $i | cpio -id
done
and then compile with
g++ -nostdinc `g++ -v -E -xc++ /dev/null 21 | sed -n '/^#include /,/^End
of/{/\/usr\/include/d;s/^ \//-isystem /p}'` -isystem ~/centos5/usr/include/
This command will use all standard C++ search paths except for /usr/include,
and will use ~/centos5/usr/include/ instead of that.
Doing this gives me:
../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:24:20:
fatal error: stddef.h: No such file or directory
because stddef.h is found in /usr/include/linux; I guess we need some
more gcc flags here.
with #if LINUX_VERSION_CODE = 132640
Good idea, let me try that.
Re: PATCH: PR other/59055: gcc.texinfo warnings
On Mon, Dec 2, 2013 at 5:10 AM, Gerald Pfeifer ger...@pfeifer.com wrote: On Fri, 8 Nov 2013, H.J. Lu wrote: bugreport.texi has @menu * Criteria: Bug Criteria. Have you really found a bug? * Reporting: Bug Reporting. How to report a bug effectively. * Known: Trouble.Known problems. * Help: Service. Where to ask for help. @end menu That means include order should be bugreport.texi, trouble.texi, service.texi. And we need to specify next, previous and up nodes to Service and Trouble nodes. OK to install? Thanks for looking into this, H.J.! Looking at the logic we have been using elsewhere, I am wondering whether it shouldn't be the order in bugreport.texi that should be adjusted -- switching the Known: Trouble and Reporting: Bug Reporting nodes? It doesn't work: /export/gnu/import/git/gcc/gcc/doc/trouble.texi:5: warning: node next `Trouble' in menu `Service' and in sectioning `Bugs' differ /export/gnu/import/git/gcc/gcc/doc/trouble.texi:5: warning: node prev `Trouble' in menu `Bug Reporting' and in sectioning `Gcov' differ /export/gnu/import/git/gcc/gcc/doc/trouble.texi:5: warning: node up `Trouble' in menu `Bugs' and in sectioning `Top' differ /export/gnu/import/git/gcc/gcc/doc/service.texi:5: warning: node prev `Service' in menu `Trouble' and in sectioning `Bugs' differ /export/gnu/import/git/gcc/gcc/doc/service.texi:5: warning: node up `Service' in menu `Bugs' and in sectioning `Top' differ That way you could omit 2013-11-08 H.J. Lu hongjiu...@intel.com PR other/59055 * doc/gcc.texi: Move Trouble after Bugs in menu. Include trouble.texi after bugreport.texi. those two changes, and only update bugreport.texi? If this sounds acceptable, please go ahead and make this change. * doc/service.texi: Add next, previous and up nodes to Service nodes. * doc/trouble.texi: Add next, previous and up nodes to Trouble nodes. Why are these necessary? The texinfo documentation say the following about @node: The subsequent arguments are optional—they are the names of the ‘Next’, ‘Previous’, and ‘Up’ pointers, in that order. We strongly recommend omitting them if your Texinfo document is hierarchically organized, as virtually all are gcc.texi has @include gcov.texi @include trouble.texi @include bugreport.texi @include service.texi and there is a menu in bugreport.texi as well as @node Bug Criteria,Bug Reporting,,Bugs @node Bug Reporting,,Bug Criteria,Bugs They aren't really hierarchically organized. H.J.
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term distributions.
Is there a way to test gcc in such environment w/o setting up VMs
(e.g. chroot, or some such)?
Maybe gcc compile farm has linux-2.6.18 machine available?
That or perhaps try say:
mkdir ~/centos5
cd ~/centos5
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/glibc-devel-2.5-118.x86_64.rpm
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/glibc-headers-2.5-118.x86_64.rpm
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/kernel-headers-2.6.18-371.el5.x86_64.rpm
for i in *.rpm; do
rpm2cpio $i | cpio -id
done
and then compile with
g++ -nostdinc `g++ -v -E -xc++ /dev/null 21 | sed -n '/^#include /,/^End
of/{/\/usr\/include/d;s/^ \//-isystem /p}'` -isystem ~/centos5/usr/include/
This command will use all standard C++ search paths except for /usr/include,
and will use ~/centos5/usr/include/ instead of that.
Doing this gives me:
../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:24:20:
fatal error: stddef.h: No such file or directory
because stddef.h is found in /usr/include/linux; I guess we need some
more gcc flags here.
Oops, sorry, should have been:
g++ -nostdinc `g++ -v -E -xc++ /dev/null 21 | sed -n '/^#include /,/^End
of/{/\/usr\/include/d;s/^ \//-isystem \//p}'` -isystem ~/centos5/usr/include/
(forgot about \/ in there, so it resulted in -isystem usr/lib/... rather than
-isystem /usr/lib/...
Jakub
Re: [C++,doc] vector conditional expression
On Mon, 2 Dec 2013, Marc Glisse wrote:
Index: doc/extend.texi
===
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same type and @code{a} is an
+integer vector of the same size and number of elements as @code{b} and
+@code{c}
Why same size and number of elements in the above? What is the
difference between these two?
(on x86_64)
A vector of 4 int and a vector of 4 long have the same number of elements but
not the same size.
A vector of 8 int and a vector of 4 long have the same size but not the same
number of elements.
For semantics, we want the same number of elements. To match the
hardware, we want the same size.
Ah, so it was good I asked. :-) Thanks for your explanation.
It seems the way this is intended is
integer vector of the (same size and number of elements) as
whereas I parsed it as
(integer vector of the same size) and (number of elements) as
hence wondering what the difference between the size of the vector and
the number of elements was.
Rephrasing this as the same number and size of elements as or better
the same number of elements of the same size as may help avoid this.
Gerald
Re: libsanitizer merge from upstream r196090
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term distributions.
Is there a way to test gcc in such environment w/o setting up VMs
(e.g. chroot, or some such)?
Maybe gcc compile farm has linux-2.6.18 machine available?
That or perhaps try say:
mkdir ~/centos5
cd ~/centos5
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/glibc-devel-2.5-118.x86_64.rpm
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/glibc-headers-2.5-118.x86_64.rpm
wget
http://mirrors.kernel.org/centos/5/os/x86_64/CentOS/kernel-headers-2.6.18-371.el5.x86_64.rpm
for i in *.rpm; do
rpm2cpio $i | cpio -id
done
and then compile with
g++ -nostdinc `g++ -v -E -xc++ /dev/null 21 | sed -n '/^#include /,/^End
of/{/\/usr\/include/d;s/^ \//-isystem /p}'` -isystem ~/centos5/usr/include/
This command will use all standard C++ search paths except for /usr/include,
and will use ~/centos5/usr/include/ instead of that.
Similarly for various other distros.
Jakub
Fix a bug in points-to solver
Points to solver has a bug that can cause complex constraints to be
skipped leading to wrong points-to results. In the case that exposed
the problem, there is sd constraint: x = *y which is never processed.
'y''s final points to set is { NULL READONLY ESCAPED NOLOCAL}, but 'x'
points-to set is {}.
What happens is before 'y'' is processed, it is merged with another
node 'z' during cycle elimination (the complex constraints get
transferred to 'z'), but 'z' is not marked as 'changed' so it is
skipped in a later iteration.
The attached patch fixed the problem. The problem is exposed by a
large program built with -fprofile-generate in LIPO mode -- so there
is no small testcase attached.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu, OK for trunk?
Index: ChangeLog
===
--- ChangeLog (revision 205579)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-12-02 Xinliang David Li davi...@google.com
+
+ * tree-ssa-structalias.c (solve_graph): Mark rep node changed
+ after cycle elimination.
+
2013-12-01 Eric Botcazou ebotca...@adacore.com
* config/i386/winnt.c (i386_pe_asm_named_section): Be prepared for an
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 205579)
+++ tree-ssa-structalias.c (working copy)
@@ -2655,8 +2655,13 @@ solve_graph (constraint_graph_t graph)
/* In certain indirect cycle cases, we may merge this
variable to another. */
- if (eliminate_indirect_cycles (i) find (i) != i)
- continue;
+ if (eliminate_indirect_cycles (i))
+{
+ unsigned int rep = find (i);
+ bitmap_set_bit (changed, rep);
+ if (i != rep)
+ continue;
+}
/* If the node has changed, we need to process the
complex constraints and outgoing edges again. */
Re: [PATCH] Avoid SIMD clone dg-do run tests if assembler doesn't support AVX2 (PR lto/59326)
On 11/29/2013 12:02 PM, Jakub Jelinek wrote: As we create SIMD clones for all of SSE2, AVX and AVX2 ISAs right now, the assembler needs to support SSE2, AVX and AVX2. Apparently some folks are still using binutils that don't handle that, this patch conditionalizes the test on that. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok. r~
Re: [PATCH] Fix PR56344
On Mon, Dec 02, 2013 at 05:40:33PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek pola...@redhat.com wrote:
Ping.
Ok. (yay, oldest patch in my review queue ...)
;) thanks. Just to be sure, did you mean to ok this patch (that is,
the one with HOST_BITS_PER_INT)?
Bootstrap/regtest in progress.
2013-12-02 Marek Polacek pola...@redhat.com
PR middle-end/56344
* calls.c (expand_call): Disallow passing huge arguments
by value.
--- gcc/calls.c.mp4 2013-12-02 17:12:18.621057873 +0100
+++ gcc/calls.c 2013-12-02 17:32:35.523684716 +0100
@@ -3047,6 +3047,15 @@ expand_call (tree exp, rtx target, int i
{
rtx before_arg = get_last_insn ();
+ /* We don't allow passing huge ( 2^30 B) arguments
+ by value. It would cause an overflow later on. */
+ if (adjusted_args_size.constant
+ = (1 (HOST_BITS_PER_INT - 1)))
Surely I meant to use HOST_BITS_PER_INT - 2 here.
Marek
Re: [wide-int] Add fast path for hosts with HWI widening multiplication
Ian Lance Taylor i...@google.com writes: On Sun, Dec 1, 2013 at 2:28 AM, Richard Sandiford rdsandif...@googlemail.com wrote: I followed Joseph's suggestion and reused longlong.h. I copied it from libgcc rather than glibc since it seemed better for GCC to have a single version across both gcc/ and libgcc/. I can put it in include/ if that seems better. Actually copying complex code like this does not seem maintainable. I think there needs to be only one copy in the GCC sources. If that requires moving it back from libgcc to gcc, or moving it to include, do that. OK, will do, but which do you prefer? Thanks, Richard
Re: [PATCH, testsuite] Fix some testcases for nds32 target and provide new nds32 target specific tests
On Dec 2, 2013, at 5:02 AM, Chung-Ju Wu jasonw...@gmail.com wrote:
Perhaps I should have used the following description, which seems much better:
+/* { dg-skip-if Variadic funcs have all args on stack. Normal funcs have
args in registers. { nds32*-*-* } * } */
Reads nicely, thanks. Also, if I do a port, and this test case fails, and I
read that and those facts apply to my port, I can just effortlessly go that
direction. To me, this is the best use of this information. Secondary would
be if people wanted to do a target_supports, it would be more clear to the
untrained why it was done in the first place.
Re: wwwdocs: Broken links due to the preprocess script
Gerald Pfeifer wrote: Below you'll find a patch for maintainer-scripts/update_web_docs_svn which I tested on gcc.gnu.org and the current documentation pages (not those for older releases) are adjusted now. Among others this fixes the link you reported above (though adjusting gcc-4.9/changes.html directly is now a logical next step). Thoughts? Looks good to me. (I fully concur that the _002d is ugly.) Tobias
Re: [wide-int] Add fast path for hosts with HWI widening multiplication
Il 02/12/2013 20:34, Richard Sandiford ha scritto: I followed Joseph's suggestion and reused longlong.h. I copied it from libgcc rather than glibc since it seemed better for GCC to have a single version across both gcc/ and libgcc/. I can put it in include/ if that seems better. Actually copying complex code like this does not seem maintainable. I think there needs to be only one copy in the GCC sources. If that requires moving it back from libgcc to gcc, or moving it to include, do that. OK, will do, but which do you prefer? libgcc/ should not use gcc/ sources too much. Please put it in include/. Paolo
Re: [patch] introduce aarch64 as a Go architecture
On Dec 2, 2013, at 1:10 AM, Andrew Pinski pins...@gmail.com wrote: All the documentation relevant to this architecture uses the term aarch64. How is arm64 obvious? The same reason Linus used arm64: https://lkml.org/lkml/2012/7/15/133 Thanks for the link, ah, now I exactly understand what that port is! :-) arm64 conveys more to me, more quickly.
Re: [wide-int] small cleanup in wide-int.*
committed as revision 205599 to wide-int branch.
kenny
On 12/02/2013 05:50 AM, Richard Biener wrote:
On Sat, Nov 30, 2013 at 1:55 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Richi,
this is the first of either 2 or 3 patches to fix this.There are two
places that need be fixed for us to do 1X + 1 and this patch fixes the first
one. There was an unnecessary call to mul_full and this was the only call
to mul_full. So this patch removes the call and also the function itself.
The other place is the tree-vpn that is discussed here and will be dealt
with in the other patches.
tested on x86-64.
Ok to commit?
Ok.
Thanks,
Richard.
Kenny
On 11/29/2013 05:24 AM, Richard Biener wrote:
On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch does three things in wide-int:
1) it cleans up some comments.
2) removes a small amount of trash.
3) it changes the max size of the wide int from being 4x of
MAX_BITSIZE_MODE_ANY_INT to 2x +1. This should improve large muls and
divs
as well as perhaps help with some cache behavior.
@@ -235,8 +233,8 @@ along with GCC; see the file COPYING3.
range of a multiply. This code needs 2n + 2 bits. */
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
- / HOST_BITS_PER_WIDE_INT)
+ (((2 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
+/ HOST_BITS_PER_WIDE_INT) + 1)
I always wondered why VRP (if that is the only reason we do 2*n+1)
cannot simply use FIXED_WIDE_INT(MAX_BITSIZE_MODE_ANY_INT*2 + 1)?
Other widest_int users should not suffer IMHO. widest_int should
strictly cover all modes that the target can do any arithmetic on
(thus not XImode or OImode on x86_64).
Richard.
ok to commit
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 205597)
+++ gcc/wide-int.cc (working copy)
@@ -1247,22 +1247,18 @@ wi_pack (unsigned HOST_WIDE_INT *result,
}
/* Multiply Op1 by Op2. If HIGH is set, only the upper half of the
- result is returned. If FULL is set, the entire result is returned
- in a mode that is twice the width of the inputs. However, that
- mode needs to exist if the value is to be usable. Clients that use
- FULL need to check for this.
-
- If HIGH or FULL are not set, throw away the upper half after the
- check is made to see if it overflows. Unfortunately there is no
- better way to check for overflow than to do this. If OVERFLOW is
- nonnull, record in *OVERFLOW whether the result overflowed. SGN
- controls the signedness and is used to check overflow or if HIGH or
- FULL is set. */
+ result is returned.
+
+ If HIGH is not set, throw away the upper half after the check is
+ made to see if it overflows. Unfortunately there is no better way
+ to check for overflow than to do this. If OVERFLOW is nonnull,
+ record in *OVERFLOW whether the result overflowed. SGN controls
+ the signedness and is used to check overflow or if HIGH is set. */
unsigned int
wi::mul_internal (HOST_WIDE_INT *val, const HOST_WIDE_INT *op1,
unsigned int op1len, const HOST_WIDE_INT *op2,
unsigned int op2len, unsigned int prec, signop sgn,
- bool *overflow, bool high, bool full)
+ bool *overflow, bool high)
{
unsigned HOST_WIDE_INT o0, o1, k, t;
unsigned int i;
@@ -1313,7 +1309,7 @@ wi::mul_internal (HOST_WIDE_INT *val, co
/* If we need to check for overflow, we can only do half wide
multiplies quickly because we need to look at the top bits to
check for the overflow. */
- if ((high || full || needs_overflow)
+ if ((high || needs_overflow)
(prec = HOST_BITS_PER_HALF_WIDE_INT))
{
unsigned HOST_WIDE_INT r;
@@ -1372,7 +1368,7 @@ wi::mul_internal (HOST_WIDE_INT *val, co
/* We did unsigned math above. For signed we must adjust the
product (assuming we need to see that). */
- if (sgn == SIGNED (full || high || needs_overflow))
+ if (sgn == SIGNED (high || needs_overflow))
{
unsigned HOST_WIDE_INT b;
if (op1[op1len-1] 0)
@@ -1420,13 +1416,7 @@ wi::mul_internal (HOST_WIDE_INT *val, co
*overflow = true;
}
- if (full)
-{
- /* compute [2prec] - [prec] * [prec] */
- wi_pack ((unsigned HOST_WIDE_INT *) val, r, 2 * half_blocks_needed);
- return canonize (val, blocks_needed * 2, prec * 2);
-}
- else if (high)
+ if (high)
{
/* compute [prec] - ([prec] * [prec]) [prec] */
wi_pack ((unsigned HOST_WIDE_INT *) val,
Index: gcc/fold-const.c
===
--- gcc/fold-const.c (revision 205597)
+++ gcc/fold-const.c (working copy)
@@ -5962,11 +5962,12 @@ extract_muldiv_1 (tree t, tree c, enum t
assuming no overflow. */
if (tcode == code)
{
- bool overflow_p;
+ bool overflow_p = false;
+ bool overflow_mul_p;
signop sign = TYPE_SIGN (ctype);
-
[PATCH] Allow compounds with empty initializer in pedantic mode (PR c/59351)
We triggered an assert on attached testcase, because when building the
compound literal with empty initial value complete_array_type returns
3, but we assert it returns 0. It returns 3 only in the pedantic mode,
where empty initializer braces are forbidden. Since we already gave
a warning, I think we could loosen the assert a bit and allow
empty initial values at that point. sizeof on such compound literal
then yields zero, which I think is correct.
The assert exists even in GCC 4.0.
Regtested/botstrapped on x86_64-linux, ok for trunk and 4.8 and
perhaps even 4.7?
2013-12-02 Marek Polacek pola...@redhat.com
PR c/59351
c/
* c-decl.c (build_compound_literal): Allow compound literals with
empty initial value.
testsuite/
* gcc.dg/pr59351.c: New test.
--- gcc/c/c-decl.c.mp3 2013-12-02 20:23:27.947224366 +0100
+++ gcc/c/c-decl.c 2013-12-02 20:25:56.618779873 +0100
@@ -4693,7 +4693,9 @@ build_compound_literal (location_t loc,
{
int failure = complete_array_type (TREE_TYPE (decl),
DECL_INITIAL (decl), true);
- gcc_assert (!failure);
+ /* If complete_array_type returns 3, it means that the
+ initial value of the compound literal is empty. Allow it. */
+ gcc_assert (failure == 0 || failure == 3);
type = TREE_TYPE (decl);
TREE_TYPE (DECL_INITIAL (decl)) = type;
--- gcc/testsuite/gcc.dg/pr59351.c.mp3 2013-12-02 20:29:05.612345428 +0100
+++ gcc/testsuite/gcc.dg/pr59351.c 2013-12-02 20:48:47.298751979 +0100
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options -std=c99 -Wpedantic } */
+
+unsigned int
+foo (void)
+{
+ return sizeof ((int[]) {}); /* { dg-warning ISO C forbids empty initializer
braces } */
+}
Marek
Re: [wwwdocs] Document Runtime CPU detection builtins
On Tue, 21 Aug 2012, Sriraman Tallam wrote: Committed after making the changes. One small problem, I am not sure how to fix this: The hyper link I referenced is : http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions whereas the committed changes.html is pointing to: http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions Please note that the _002din is missing. This makes the link broken, did I miss anything? I verified that I submitted the right link. Based on changes I just committed and applied on gcc.gnu.org, finally there won't be new files or anchors with _002d in their names, just - instead. The patch below, which I just committed, adjust the links. All simpler and nicer now. :-) Gerald Index: gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.124 diff -u -3 -p -r1.124 changes.html --- gcc-4.8/changes.html26 Nov 2013 03:21:07 - 1.124 +++ gcc-4.8/changes.html2 Dec 2013 20:17:11 - @@ -512,7 +512,7 @@ int i = A().f(); // error, f() requires added. For details, see the a href=http://gcc.gnu.org/wiki/avr-gcc#Fixed-Point_Support; GCC wiki/a and the -a href=http://gcc.gnu.org/onlinedocs/gcc/Fixed_002dPoint.html; +a href=http://gcc.gnu.org/onlinedocs/gcc/Fixed-Point.html; user manual/a. The support is not complete. /li liA new print modifier code%r/code for register operands in inline @@ -584,7 +584,7 @@ int i = A().f(); // error, f() requires code__builtin_cpu_is(westmere)/code returns a positive integer if the run-time CPU is an Intel Core i7 Westmere processor. Please refer to the a - href=http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions; + href=http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions; user manual/a for the list of valid CPU names recognized./li liA built-in function code__builtin_cpu_supports/code has been added to detect if the run-time CPU supports a particular ISA feature. @@ -592,7 +592,7 @@ int i = A().f(); // error, f() requires one string literal argument, the ISA feature. For example, code__builtin_cpu_supports(ssse3)/code returns a positive integer if the run-time CPU supports SSSE3 instructions. Please refer to the a - href=http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions; + href=http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions; user manual/a for the list of valid ISA names recognized./li /ul pCaveat: If these built-in functions are called before any static
[wide-int] Drop some lingering uses of precision 0
I noticed that there were still a couple of tests for zero precision.
This patch replaces them with asserts when handling separately-supplied
precisions and simply drops them when handling existing wide_ints.
(The idea is that most code would break for zero precision wide_ints
and only asserting in some use sites would be inconsistent.)
Also, to_shwi is called either with a nonzero precision argument or
with no argument. I think it'd be clearer to split the two cases into
separate (overloaded) functions. It's also more efficient, since the
compiler doesn't know that a variable-precision argument must be nonzero.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 2013-12-02 20:03:50.112581766 +
+++ gcc/wide-int.cc 2013-12-02 20:12:22.178998274 +
@@ -275,9 +275,8 @@ wi::from_mpz (const_tree type, mpz_t x,
wide_int
wi::max_value (unsigned int precision, signop sgn)
{
- if (precision == 0)
-return shwi (0, precision);
- else if (sgn == UNSIGNED)
+ gcc_checking_assert (precision != 0);
+ if (sgn == UNSIGNED)
/* The unsigned max is just all ones. */
return shwi (-1, precision);
else
@@ -290,7 +289,8 @@ wi::max_value (unsigned int precision, s
wide_int
wi::min_value (unsigned int precision, signop sgn)
{
- if (precision == 0 || sgn == UNSIGNED)
+ gcc_checking_assert (precision != 0);
+ if (sgn == UNSIGNED)
return uhwi (0, precision);
else
/* The signed min is all zeros except the top bit. This must be
@@ -1487,9 +1487,6 @@ wi::popcount (const wide_int_ref x)
unsigned int i;
int count;
- if (x.precision == 0)
-return 0;
-
/* The high order block is special if it is the last block and the
precision is not an even multiple of HOST_BITS_PER_WIDE_INT. We
have to clear out any ones above the precision before doing
@@ -2082,10 +2079,6 @@ wi::ctz (const wide_int_ref x)
int
wi::exact_log2 (const wide_int_ref x)
{
- /* 0-precision values can only hold 0. */
- if (x.precision == 0)
-return -1;
-
/* Reject cases where there are implicit -1 blocks above HIGH. */
if (x.len * HOST_BITS_PER_WIDE_INT x.precision x.sign_mask () 0)
return -1;
Index: gcc/wide-int.h
===
--- gcc/wide-int.h 2013-12-02 19:52:05.424989079 +
+++ gcc/wide-int.h 2013-12-02 20:12:22.179998282 +
@@ -644,8 +644,10 @@ class GTY(()) generic_wide_int : public
generic_wide_int (const T , unsigned int);
/* Conversions. */
- HOST_WIDE_INT to_shwi (unsigned int = 0) const;
- unsigned HOST_WIDE_INT to_uhwi (unsigned int = 0) const;
+ HOST_WIDE_INT to_shwi (unsigned int) const;
+ HOST_WIDE_INT to_shwi () const;
+ unsigned HOST_WIDE_INT to_uhwi (unsigned int) const;
+ unsigned HOST_WIDE_INT to_uhwi () const;
HOST_WIDE_INT to_short_addr () const;
/* Public accessors for the interior of a wide int. */
@@ -735,18 +737,23 @@ inline generic_wide_int storage::gener
inline HOST_WIDE_INT
generic_wide_int storage::to_shwi (unsigned int precision) const
{
- if (precision == 0)
-{
- if (is_sign_extended)
- return this-get_val ()[0];
- precision = this-get_precision ();
-}
if (precision HOST_BITS_PER_WIDE_INT)
return sext_hwi (this-get_val ()[0], precision);
else
return this-get_val ()[0];
}
+/* Return THIS as a signed HOST_WIDE_INT, in its natural precision. */
+template typename storage
+inline HOST_WIDE_INT
+generic_wide_int storage::to_shwi () const
+{
+ if (is_sign_extended)
+return this-get_val ()[0];
+ else
+return to_shwi (this-get_precision ());
+}
+
/* Return THIS as an unsigned HOST_WIDE_INT, zero-extending from
PRECISION. If THIS does not fit in PRECISION, the information
is lost. */
@@ -754,14 +761,20 @@ generic_wide_int storage::to_shwi (uns
inline unsigned HOST_WIDE_INT
generic_wide_int storage::to_uhwi (unsigned int precision) const
{
- if (precision == 0)
-precision = this-get_precision ();
if (precision HOST_BITS_PER_WIDE_INT)
return zext_hwi (this-get_val ()[0], precision);
else
return this-get_val ()[0];
}
+/* Return THIS as an signed HOST_WIDE_INT, in its natural precision. */
+template typename storage
+inline unsigned HOST_WIDE_INT
+generic_wide_int storage::to_uhwi () const
+{
+ return to_uhwi (this-get_precision ());
+}
+
/* TODO: The compiler is half converted from using HOST_WIDE_INT to
represent addresses to using offset_int to represent addresses.
We use to_short_addr at the interface from new code to old,
@@ -2289,9 +2302,7 @@ wi::add (const T1 x, const T2 y, signo
unsigned HOST_WIDE_INT xl = xi.ulow ();
unsigned HOST_WIDE_INT yl = yi.ulow ();
unsigned HOST_WIDE_INT resultl = xl + yl;
- if (precision == 0)
- *overflow = false;
- else if (sgn == SIGNED)
+ if (sgn
[wide-int] i am concerned about the typedef for widest-int.
see wide-int.h around line 290 the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however if the value coming in is an unsigned number of the type the represents that mode, don't we loose a bit? kenny
Re: [PATCH] Fix PR56344
Marek Polacek pola...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:40:33PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek pola...@redhat.com
wrote:
Ping.
Ok. (yay, oldest patch in my review queue ...)
;) thanks. Just to be sure, did you mean to ok this patch (that is,
the one with HOST_BITS_PER_INT)?
Yes, thanks,
Richard.
Bootstrap/regtest in progress.
2013-12-02 Marek Polacek pola...@redhat.com
PR middle-end/56344
* calls.c (expand_call): Disallow passing huge arguments
by value.
--- gcc/calls.c.mp4 2013-12-02 17:12:18.621057873 +0100
+++ gcc/calls.c 2013-12-02 17:32:35.523684716 +0100
@@ -3047,6 +3047,15 @@ expand_call (tree exp, rtx target, int i
{
rtx before_arg = get_last_insn ();
+ /* We don't allow passing huge ( 2^30 B) arguments
+ by value. It would cause an overflow later on. */
+ if (adjusted_args_size.constant
+ = (1 (HOST_BITS_PER_INT - 1)))
Surely I meant to use HOST_BITS_PER_INT - 2 here.
Marek
Re: [wide-int] i am concerned about the typedef for widest-int.
Kenneth Zadeck zad...@naturalbridge.com writes: see wide-int.h around line 290 the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however if the value coming in is an unsigned number of the type the represents that mode, don't we loose a bit? That was the +1 mentioned here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03745.html I.e. it should be widest supported arithmetic input + 1. Thanks, Richard
Re: [wide-int] i am concerned about the typedef for widest-int.
On 12/02/2013 03:34 PM, Richard Sandiford wrote: Kenneth Zadeck zad...@naturalbridge.com writes: see wide-int.h around line 290 the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however if the value coming in is an unsigned number of the type the represents that mode, don't we loose a bit? That was the +1 mentioned here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03745.html I.e. it should be widest supported arithmetic input + 1. Thanks, Richard do we want 129 or do we want to round that up to the next hwi?
RE: [PATCH] Fix C++0x memory model for -fno-strict-volatile-bitfields on ARM
Hi,
On Mon, 2 Dec 2013 15:55:08Richard Biener wrote:
On Mon, Nov 25, 2013 at 1:07 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hello,
I had forgotten to run the Ada test suite when I submitted the previous
version of this patch.
And indeed there were some Ada test cases failing because in Ada packed
structures are
like bit fields, but without the DECL_BIT_FIELD_TYPE attribute.
I think they may have DECL_BIT_FIELD set though, not sure.
Please find attached the updated version of this patch.
Boot-strapped and regression-tested on x86_64-linux-gnu.
Ok for trunk?
So you mimic what Eric added in get_bit_range? Btw, I'm not sure
the conservative way of failing get_bit_range with not limiting the
access at all is good.
That is, we may want to do
+ /* The C++ memory model naturally applies to byte-aligned fields.
+ However, if we do not have a DECL_BIT_FIELD_TYPE but BITPOS or
+ BITSIZE are not byte-aligned, there is no need to limit the range
+ we can access. This can occur with packed structures in Ada. */
+ if (bitregion_start == 0 bitregion_end == 0
+ bitsize 0
+ bitsize % BITS_PER_UNIT == 0
+ bitpos % BITS_PER_UNIT == 0)
+ {
+ bitregion_start = bitpos;
+ bitregion_end = bitpos + bitsize - 1;
+ }
thus not else if but also apply it when get_bit_range failed (as it may
fail for other reasons). A better fallback would be to track down
the outermost byte-aligned handled-component and limit the access
to that (though I guess Ada doesn't care at all about the C++ memory
model and only Ada has bit-aligned aggregates).
Good question. Most of the time the expansion can not know if it expands
Ada, C, or Fortran. In this case we know it can only be Ada, so the C++ memory
model is not mandatory. Maybe Eric can tell, if a data store race condition
may be an issue in Ada if structure is laid out like
__attribute((packed,aligned(1)))
I mean, if that is at all possible.
That said, the patch looks ok as-is to me, let's see if we can clean
things up for the next stage1.
Ok, applied as-is.
Thanks
Bernd.
Thanks,
Richard.
Bernd.
On Mon, 18 Nov 2013 11:37:05, Bernd Edlinger wrote:
Hi,
On Fri, 15 Nov 2013 13:30:51, Richard Biener wrote:
That looks like always pretending it is a bit field.
But it is not a bit field, and bitregion_start=bitregion_end=0
means it is an ordinary value.
I don't think it is supposed to mean that. It's supposed to mean
the access is unconstrained.
Ok, agreed, I did not regard that as a feature.
And apparently only the code path in expand_assigment
really has a problem with it.
So here my second attempt at fixing this.
Boot-strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
[Patch] Add comments for future regex work
...for optimization purpose. Should be done in one month.
Thanks!
--
Regards,
Tim Shen
commit cc7d58128e68455498d0257c4796cb70a9e24990
Author: tim timshe...@gmail.com
Date: Mon Dec 2 15:49:15 2013 -0500
2013-12-02 Tim Shen timshe...@gmail.com
* regex_compiler.h: Add todo comment.
* regex_executor.tcc: Likewise.
diff --git a/libstdc++-v3/include/bits/regex_compiler.h b/libstdc++-v3/include/bits/regex_compiler.h
index b9f8127..5759d48 100644
--- a/libstdc++-v3/include/bits/regex_compiler.h
+++ b/libstdc++-v3/include/bits/regex_compiler.h
@@ -237,6 +237,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
/// Matches a character range (bracket expression)
+ // TODO: Convert used _M_flags fields to template parameters, including
+ // collate and icase. Avoid using std::set, could use flat_set
+ // (sorted vector and binary search) instead; use an fixed sized (256)
+ // vectorbool for char specialization if necessary.
templatetypename _TraitsT
struct _BracketMatcher
{
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc b/libstdc++-v3/include/bits/regex_executor.tcc
index 22fd67c..150adb4 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -162,6 +162,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
}
+ // TODO: Use a function vector to dispatch, instead of using switch-case.
templatetypename _BiIter, typename _Alloc, typename _TraitsT,
bool __dfs_mode
templatebool __match_mode
Re: wwwdocs: Broken links due to the preprocess script
On Mon, 2 Dec 2013, Tobias Burnus wrote: Looks good to me. (I fully concur that the _002d is ugly.) Okay, so I applied this patch plus the one below to adjust gcc-4.9/changes.html accordingly. (The first anchor there is not stable, but for other reasons.) Thanks for pushing for this fix! Gerald Index: gcc-4.9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.43 diff -u -3 -p -r1.43 changes.html --- gcc-4.9/changes.html30 Nov 2013 16:36:59 - 1.43 +++ gcc-4.9/changes.html2 Dec 2013 21:42:24 - @@ -110,7 +110,7 @@ ul liSupport for colorizing diagnostics emitted by GCC has been added. The codea - href=http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html#index-fdiagnostics_002dcolor-239; + href=http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html#index-fdiagnostics-color-246; -fdiagnostics-color=auto/a/code will enable it when outputting to terminals, code-fdiagnostics-color=always/code unconditionally. The codeGCC_COLORS/code environment variable @@ -136,7 +136,7 @@ /pre/li liWith the new a -href=http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html; +href=http://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html; code#pragma GCC ivdep/code/a, the user can assert that there are no loop-carried dependencies which would prevent concurrent execution of consecutive iterations using SIMD (single instruction multiple data)
[Dwarf Patch] Use offset into debug_info for pubtype name referring to pubtype section
The enclosed patch fixes a mismerge from google/gcc-4_7 to main. When outputting a pubtype whose type has no skeleton section, it's DIE offset should be from the comp_unit_die, instead of zero. Zero is actually a place-holder for the end of the pubtypes. Sterling gcc/ChangeLog 2013-12-02 Sterling Augustine saugust...@google.com * dwarf2out.c (output_pubnames): Use comp_unit_die ()-die_offset when there isn't a skeleton die. pubtypes-bug.tot-patch Description: Binary data
Re: [Dwarf Patch] Use offset into debug_info for pubtype name referring to pubtype section
gcc/ChangeLog 2013-12-02 Sterling Augustine saugust...@google.com * dwarf2out.c (output_pubnames): Use comp_unit_die ()-die_offset when there isn't a skeleton die. This is OK, but your patch also has a local change to contrib/mklog. Please be careful not to commit that. Thanks! -cary
