Re: RFA: implement C11 _Generic
> "Joseph" == Joseph S Myers writes: Joseph> I have now revised this patch from a year ago in line with my Joseph> understanding of how _Generic ought to handle the various special Joseph> cases Thanks for doing this. Joseph> + /* The association's type, or NULL_TREE for 'default'.. */ It's trivial, but I happened to notice that this ".." should be just ".". The extra "." was in the original patch too. Tom
[Committed] S/390: Fix fpr numbering when creating fallback frame state
Hi,
when creating the fallback framestate for unwinding through a signal
frame we currently use a linear mapping from the hard regs to dwarf
regs also for FPRs. This is wrong. In order to deal with FPR
register pairs as required by the hardware there is a specific mapping
defined in the ABI which we have to take into account here.
I've committed the patch after successful regtest.
This fixes some Java failures which I can only reproduce with another
patch.
Bye,
-Andreas-
2013-07-23 Andreas Krebbel
* config/s390/linux-unwind.h: Use the proper dwarf to hard reg
mapping for FPRs when creating the fallback framestate.
---
libgcc/config/s390/linux-unwind.h |4 ++!!
1 file changed, 2 insertions(+), 2 modifications(!)
Index: libgcc/config/s390/linux-unwind.h
===
*** libgcc/config/s390/linux-unwind.h.orig
--- libgcc/config/s390/linux-unwind.h
*** static _Unwind_Reason_Code
*** 31,36
--- 31,38
s390_fallback_frame_state (struct _Unwind_Context *context,
_Unwind_FrameState *fs)
{
+ static const unsigned char dwarf_to_fpr_map[16] =
+ { 0, 2, 4, 6, 1, 3, 5, 7, 8, 10, 12, 14, 9, 11, 13, 15 };
unsigned char *pc = context->ra;
long new_cfa;
int i;
*** s390_fallback_frame_state (struct _Unwin
*** 112,118
{
fs->regs.reg[16+i].how = REG_SAVED_OFFSET;
fs->regs.reg[16+i].loc.offset =
! (long)®s->fprs[i] - new_cfa;
}
/* Load return addr from PSW into dummy register 32. */
--- 114,120
{
fs->regs.reg[16+i].how = REG_SAVED_OFFSET;
fs->regs.reg[16+i].loc.offset =
! (long)®s->fprs[dwarf_to_fpr_map[i]] - new_cfa;
}
/* Load return addr from PSW into dummy register 32. */
[PING] 3 patches waiting for approval/review
[RFC] Allow functions calling mcount before prologue to be leaf functions http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html [PATCH] PR57377: Fix mnemonic attribute http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html [PATCH] Doc: Add documentation for the mnemonic attribute http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01436.html Bye, -Andreas-
Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
Hi,
On 07/22/2013 11:38 PM, Jason Merrill wrote:
I guess ptr_reasonably_similar should return false if one of the
target types is incomplete.
Thanks.
The below passes testing on x86_64-linux. I'm also taking the chance to
change the return type to bool, consistently with comptypes,
error_type_p, etc.
A slightly less conservative version just doing:
if (!COMPLETE_TYPE_P (to) || !COMPLETE_TYPE_P (from))
return false;
also passes testing.
Thanks!
Paolo.
/
/cp
2013-07-23 Paolo Carlini
PR c++/57942
* typeck.c (ptr_reasonably_similar): Return false if one of the
target types is incomplete; return a bool, not an int.
* cp-tree.h (ptr_reasonably_similar): Adjust declaration.
/testsuite
2013-07-23 Paolo Carlini
PR c++/57942
* g++.dg/inherit/pr57942.C: New.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 201148)
+++ cp/cp-tree.h(working copy)
@@ -6022,7 +6022,7 @@ extern tree convert_for_initialization(tree,
tre
extern int comp_ptr_ttypes (tree, tree);
extern bool comp_ptr_ttypes_const (tree, tree);
extern bool error_type_p (const_tree);
-extern int ptr_reasonably_similar (const_tree, const_tree);
+extern bool ptr_reasonably_similar (const_tree, const_tree);
extern tree build_ptrmemfunc (tree, tree, int, bool,
tsubst_flags_t);
extern int cp_type_quals (const_tree);
Index: cp/typeck.c
===
--- cp/typeck.c (revision 201148)
+++ cp/typeck.c (working copy)
@@ -8599,10 +8599,10 @@ error_type_p (const_tree type)
}
}
-/* Returns 1 if to and from are (possibly multi-level) pointers to the same
+/* Returns true if to and from are (possibly multi-level) pointers to the same
type or inheritance-related types, regardless of cv-quals. */
-int
+bool
ptr_reasonably_similar (const_tree to, const_tree from)
{
for (; ; to = TREE_TYPE (to), from = TREE_TYPE (from))
@@ -8614,8 +8614,11 @@ ptr_reasonably_similar (const_tree to, const_tree
return !error_type_p (to);
if (TREE_CODE (to) != TREE_CODE (from))
- return 0;
+ return false;
+ if (COMPLETE_TYPE_P (to) != COMPLETE_TYPE_P (from))
+ return false;
+
if (TREE_CODE (from) == OFFSET_TYPE
&& comptypes (TYPE_OFFSET_BASETYPE (to),
TYPE_OFFSET_BASETYPE (from),
@@ -8624,11 +8627,11 @@ ptr_reasonably_similar (const_tree to, const_tree
if (TREE_CODE (to) == VECTOR_TYPE
&& vector_types_convertible_p (to, from, false))
- return 1;
+ return true;
if (TREE_CODE (to) == INTEGER_TYPE
&& TYPE_PRECISION (to) == TYPE_PRECISION (from))
- return 1;
+ return true;
if (TREE_CODE (to) == FUNCTION_TYPE)
return !error_type_p (to) && !error_type_p (from);
Index: testsuite/g++.dg/inherit/pr57942.C
===
--- testsuite/g++.dg/inherit/pr57942.C (revision 0)
+++ testsuite/g++.dg/inherit/pr57942.C (working copy)
@@ -0,0 +1,7 @@
+// PR c++/57942
+
+template struct S { typename T::error type; };
+struct X {};
+void f(S*);
+void f(...);
+void g() { f((X*)0); }
Re: [PATCH] Fix for PR c/57490
Rainer Orth writes: > "Iyer, Balaji V" writes: > >>> -Original Message- >>> From: Jakub Jelinek [mailto:ja...@redhat.com] >>> Sent: Monday, July 01, 2013 1:09 PM >>> To: Iyer, Balaji V >>> Cc: gcc-patches@gcc.gnu.org; Rainer Orth >>> Subject: Re: [PATCH] Fix for PR c/57490 >>> >>> On Mon, Jul 01, 2013 at 05:02:57PM +, Iyer, Balaji V wrote: >>> > OK. The fixed patch is attached. Here are the ChangeLog entries: >>> > >>> > gcc/cp/ChangeLog >>> > 2013-07-01 Balaji V. Iyer >>> > >>> >>> Still >>> PR c/57490 >>> hasn't been added to cp/ChangeLog and c/ChangeLog entries. >>> > --- /dev/null >>> > +++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c >>> > @@ -0,0 +1,25 @@ >>> >> >> Fixed as you suggested. Here is the fixed Changelogs and patch is attached. >> >> gcc/cp/ChangeLog >> 2013-07-01 Balaji V. Iyer >> >> PR c/57490 >> * cp-array-notation.c (cp_expand_cond_array_notations): Added a >> check for truth values. >> (expand_array_notation_exprs): Added truth values case. Removed an >> unwanted else. Added for-loop to walk through subtrees in default >> case. >> >> gcc/c/ChangeLog >> 2013-07-01 Balaji V. Iyer >> >> PR c/57490 >> * c-array-notation.c (fix_conditional_array_notations_1): Added a >> check for truth values. >> (expand_array_notation_exprs): Added truth values case. Removed an >> unwanted else. Added for-loop to walk through subtrees in default >> case. >> >> >> gcc/testsuite/ChangeLog >> 2013-07-01 Balaji V. Iyer >> >> PR c/57490 >> * c-c++-common/cilk-plus/AN/pr57490.c: New test. > > I've just tested this patch on i386-pc-solaris2.10: > > The c-c++-common/cilk-plus/AN/an-if.c test still FAILs for C++: > > FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus (internal compiler error) > FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus (test for excess errors) > Excess errors: > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5: > error: mismatching comparison operand types > float > int > if (D.2198 == 24) goto ; else goto ; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5: > error: mismatching comparison operand types > float > int > if (D.2200 == D.2282) goto ; else goto ; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5: > error: mismatching comparison operand types > float > int > if (D.2202 == 0) goto ; else goto ; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5: > error: mismatching comparison operand types > float > int > if (D.2205 == 24) goto ; else goto ; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5: > error: mismatching comparison operand types > float > int > if (D.2207 == D.2338) goto ; else goto ; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5: > error: mismatching comparison operand types > float > int > if (D.2209 == iftmp.16) goto ; else goto ; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5: > internal compiler error: verify_gimple failed > 0x87f1a27 verify_gimple_in_seq(gimple_statement_d*) > /vol/gcc/src/hg/trunk/local/gcc/tree-cfg.c:4474 > 0x863ce54 gimplify_body(tree_node*, bool) > /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8240 > 0x863d19a gimplify_function_tree(tree_node*) > /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8325 > 0x84a9437 analyze_function > /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:631 > 0x84ac97a analyze_functions > /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:914 > 0x84ae029 finalize_compilation_unit() > /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2097 > 0x829255f cp_write_global_declarations() > /vol/gcc/src/hg/trunk/local/gcc/cp/decl2.c:4356 > > WARNING: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus compilation failed to > produce executable > > While the C an-if.c test now passes, the new pr57490.c test (which is > identical to an-if.c modulo the assert to __builtin_abort change) FAILs: > > FAIL: c-c++-common/cilk-plus/AN/pr57490.c -fcilkplus -std=c99 (internal > compiler error) > FAIL: c-c++-common/cilk-plus/AN/pr57490.c -fcilkplus -std=c99 (test for > excess errors) > Excess errors: > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5: > error: invalid types in conversion to floating point > long double > float > D.1656 = (long double) D.1604; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5: > error: invalid types in conversion to floating point > long double > float > D.1671 = (long double) D.1609; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5: > error: invalid types in conversion to floating point > long double > float > D.1731 = (long double) D.1619; > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/
RE: [PATCH][4.8 backport] Fix PR57735
Hi Richard, > Richard Sandiford writes: > > "Kyrylo Tkachov" writes: > >> Hi all, > >> > >> The fix for PR57735 is in current trunk (for a different issue I > think), just > >> needs a backport to 4.8. > >> It is r198462 by Richard Sandiford: > >> > >> 2013-04-30 Richard Sandiford > >> > >>* explow.c (plus_constant): Pass "mode" to immed_double_int_const. > >>Use gen_int_mode rather than GEN_INT. > >> > >> Ok to backport to the 4.8 branch? > > > > Sorry for dropping the ball. It's already been approved for 4.8, > > and I think I even remembered to test it ready for commit. I just > > never actually hit commit afterwards :-( > > *sigh*. Scratch that. I'd confused it with: > > 2013-05-22 Richard Sandiford > > * recog.c (offsettable_address_addr_space_p): Fix calculation of > address mode. Move pointer mode initialization to the same place. > > which I _did_ apply to 4.8. Sorry about the confusion instead... It's ok, didn't have time to act on the confusion anyway :) So is the proposed one ok to backport? I've bootstrapped it on arm-none-linux-gnueabihf and tested on arm-none-eabi with qemu. Thanks, Kyrill
Re: [v3] libstdc++/57920
2013/7/22 Paolo Carlini :
> Hi,
>
> see audit trail for details. I tested on x86_64-linux (with/without
> _GLIBCXX_X86_RDRAND artificially undefined) the below straightforward patch
> and checked by hand the strace. I'm going to apply it soon.
>
> Thanks,
> Paolo.
>
> ///
Hi, Paolo,
In this patch I can see that you thought cstdio is unnecessary:
Index: include/std/random
--- include/std/random (revision 201122)
+++ include/std/random (working copy)
@@ -36,7 +36,6 @@
#else
#include
-#include
#include
#include
#include
However, for some cases the file libstdc++-v3/include/std/random
may include libstdc++-v3/include/bits/random.h, in which there is
a declaration using FILE type:
[libstdc++-v3/include/std/random]
46 #ifdef _GLIBCXX_USE_C99_STDINT_TR1
47
48 #include // For uint_fast32_t, uint_fast64_t, uint_least32_t
49 #include
50 #include
51 #include
52
53 #endif // _GLIBCXX_USE_C99_STDINT_TR1
[libstdc++-v3/include/bits/random.h]
1639 union
1640 {
1641 FILE*_M_file;
1642 mt19937 _M_mt;
1643 };
causing the following error:
libstdc++-v3/include/bits/random.h:1641:5: error: 'FILE' does not name a type
FILE*_M_file;
Perhaps cstdio is necessary in this case. What do you think? :-)
Best regards,
jasonwucj
Re: [Patch] regex_iterator and regex_token_iterator implementation
On Mon, Jul 22, 2013 at 6:10 PM, Jonathan Wakely wrote: > They're not specified by the standard, it says > > // these members are shown for exposition only: > > Which means the names are used only for the purposes of describing the > semantics of the class, they are not normative requirements. See > 17.5.2.3 [objects.within.classes]. I see. Are other parts ok? Could you please look at them? Thank you! -- Tim Shen
[Patch] Fix selector for vect-iv-5.c
Hello
gcc.dg/vect/vect-iv-5.c XPASSes for arm-*-* since gcc.dg/vect/*.c tests are
always run with -ffast-math for arm-*-*. This patch makes xfail conditional
for this test by adding effective target keyword !arm_neon_ok.
OK for trunk?
Regards
VP
--
gcc/testsuite/ChangeLog:
2013-07-22 Vidya Praveen
* gcc.dg/vect/vect-iv-5.c: Make xfail conditional with !arm_neon_ok.
diff --git a/gcc/testsuite/gcc.dg/vect/vect-iv-5.c b/gcc/testsuite/gcc.dg/vect/vect-iv-5.c
index 1766ae6..8861095 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-iv-5.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-iv-5.c
@@ -36,5 +36,5 @@ int main (void)
return main1 ();
}
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { xfail *-*-* } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { xfail {! arm_neon_ok } } } } */
/* { dg-final { cleanup-tree-dump "vect" } } */
Re: [v3] libstdc++/57920
Hi,
On 07/23/2013 11:17 AM, Chung-Ju Wu wrote:
2013/7/22 Paolo Carlini :
Hi,
see audit trail for details. I tested on x86_64-linux (with/without
_GLIBCXX_X86_RDRAND artificially undefined) the below straightforward patch
and checked by hand the strace. I'm going to apply it soon.
Thanks,
Paolo.
///
[libstdc++-v3/include/bits/random.h]
1639 union
1640 {
1641 FILE*_M_file;
1642 mt19937 _M_mt;
1643 };
causing the following error:
libstdc++-v3/include/bits/random.h:1641:5: error: 'FILE' does not name a type
FILE*_M_file;
Perhaps cstdio is necessary in this case. What do you think? :-)
The issue is theoretical at the moment because ends up
including anyway, thus the above can't really happen. It's true
that the above union - which by way I didn't invent - it's rather
annoying if we manage to *really* avoid including , which is
very big.
Currently you can't really get the error above.
Paolo.
Typo in GCC Internals documentation.
Hi,
Found a typo in the GCC Internals documentation in one of the code
examples in 16.18.2 RTL to RTL Peephole Optimizers.
Best,
Nicklas
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 201156)
+++ gcc/doc/md.texi (working copy)
@@ -7578,7 +7578,7 @@
"/* @r{determine 1 does not overlap 0 and 2} */"
[(set (match_dup 4) (match_dup 1))
(set (match_dup 0) (match_dup 4))
- (set (match_dup 2) (match_dup 4))]
+ (set (match_dup 2) (match_dup 4))
(set (match_dup 3) (match_dup 4))]
"")
@end smallexample
Re: [v3] libstdc++/57920
On 07/23/2013 11:26 AM, Paolo Carlini wrote: Currently you can't really get the error above. Ah Ok, now I see when it can happen, not on Linux, it can happen when string_conversions.h aren't available. Ok, I'll add back the include momentarily. Paolo.
Re: [v3] libstdc++/57920
2013/7/23 Paolo Carlini : > On 07/23/2013 11:26 AM, Paolo Carlini wrote: >> >> Currently you can't really get the error above. > > Ah Ok, now I see when it can happen, not on Linux, it can happen when > string_conversions.h aren't available. Ok, I'll add back the include > momentarily. > > Paolo. Yes, the problem happened when I was building an elf toolchain. Thank you so much to take a look at this issue. :-) Best regards, jasonwucj
[PATCH, libfortran]: Committed: Read rounding mode from SSE mxcsr register on x86_64.
Hello!
On x86_64, we can look into SSE mxcsr register to determine rounding mode.
2013-07-23 Uros Bizjak
* config/fpu-387.h (get_fpu_rounding_mode): Read rounding mode
from SSE mxcsr register on x86_64.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline svn.
BTW. gfortran.dg/round_4.f90 test will fail on glibc < 2.17 due to
glibc bug 3479 [1], "Incorrect rounding in strtod()".
[1] http://sourceware.org/bugzilla/show_bug.cgi?id=3479
Uros.
Index: config/fpu-387.h
===
--- config/fpu-387.h(revision 201156)
+++ config/fpu-387.h(working copy)
@@ -102,11 +102,11 @@ has_sse (void)
/* i387 rounding modes. */
#define _FPU_RC_NEAREST 0x0
-#define _FPU_RC_DOWN0x400
-#define _FPU_RC_UP 0x800
-#define _FPU_RC_ZERO0xc00
+#define _FPU_RC_DOWN0x1
+#define _FPU_RC_UP 0x2
+#define _FPU_RC_ZERO0x3
-#define _FPU_RC_MASK0xc00
+#define _FPU_RC_MASK0x3
void
@@ -202,8 +202,9 @@ set_fpu_rounding_mode (int round)
__asm__ __volatile__ ("fnstcw\t%0" : "=m" (cw));
- cw &= ~_FPU_RC_MASK;
- cw |= round_mode;
+ /* The x87 round control bits are shifted by 10 bits. */
+ cw &= ~(_FPU_RC_MASK << 10);
+ cw |= round_mode << 10;
__asm__ __volatile__ ("fldcw\t%0" : : "m" (cw));
@@ -213,9 +214,9 @@ set_fpu_rounding_mode (int round)
__asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (cw_sse));
- /* The SSE round control bits are shifted by 3 bits. */
- cw_sse &= ~(_FPU_RC_MASK << 3);
- cw_sse |= round_mode << 3;
+ /* The SSE round control bits are shifted by 13 bits. */
+ cw_sse &= ~(_FPU_RC_MASK << 13);
+ cw_sse |= round_mode << 13;
__asm__ __volatile__ ("%vldmxcsr\t%0" : : "m" (cw_sse));
}
@@ -224,13 +225,27 @@ set_fpu_rounding_mode (int round)
int
get_fpu_rounding_mode (void)
{
+ int round_mode;
+
+#ifdef __x86_64__
+ unsigned int cw;
+
+ __asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (cw));
+
+ /* The SSE round control bits are shifted by 13 bits. */
+ round_mode = cw >> 13;
+#else
unsigned short cw;
__asm__ __volatile__ ("fnstcw\t%0" : "=m" (cw));
- cw &= _FPU_RC_MASK;
+ /* The x87 round control bits are shifted by 10 bits. */
+ round_mode = cw >> 10;
+#endif
- switch (cw)
+ round_mode &= _FPU_RC_MASK;
+
+ switch (round_mode)
{
case _FPU_RC_NEAREST:
return GFC_FPE_TONEAREST;
Re: [v3] libstdc++/57920
... in the future, when we manage to actually avoid including
from I think we can avoid including it from if we play
a bit with void*. Should be safe aliasing-wise. Something like the
below, completely untested.
Paolo.
Index: include/bits/random.h
===
--- include/bits/random.h (revision 201148)
+++ include/bits/random.h (working copy)
@@ -1638,10 +1638,10 @@
union
{
-FILE*_M_file;
-mt19937 _M_mt;
+ void* _M_file;
+ mt19937_M_mt;
+};
};
- };
/* @} */ // group random_generators
Index: include/std/random
===
--- include/std/random (revision 201160)
+++ include/std/random (working copy)
@@ -36,7 +36,6 @@
#else
#include
-#include // For FILE
#include
#include
#include
Index: src/c++11/random.cc
===
--- src/c++11/random.cc (revision 201160)
+++ src/c++11/random.cc (working copy)
@@ -30,6 +30,8 @@
# include
#endif
+#include
+
#ifdef _GLIBCXX_HAVE_UNISTD_H
# include
#endif
@@ -102,7 +104,7 @@
std::__throw_runtime_error(__N("random_device::"
"random_device(const std::string&)"));
-_M_file = std::fopen(fname, "rb");
+_M_file = reinterpret_cast(std::fopen(fname, "rb"));
if (! _M_file)
goto fail;
}
@@ -117,7 +119,7 @@
random_device::_M_fini()
{
if (_M_file)
- std::fclose(_M_file);
+ std::fclose(reinterpret_cast(_M_file));
}
random_device::result_type
@@ -130,10 +132,11 @@
result_type __ret;
#ifdef _GLIBCXX_HAVE_UNISTD_H
-read(fileno(_M_file), reinterpret_cast(&__ret),
sizeof(result_type));
+read(fileno(reinterpret_cast(_M_file)),
+reinterpret_cast(&__ret), sizeof(result_type));
#else
std::fread(reinterpret_cast(&__ret), sizeof(result_type),
- 1, _M_file);
+ 1, reinterpret_cast(_M_file));
#endif
return __ret;
}
Re: Typo in GCC Internals documentation.
On Tue, Jul 23, 2013 at 11:32:39AM +0200, Nicklas Bo Jensen wrote:
> Hi,
>
> Found a typo in the GCC Internals documentation in one of the code
> examples in 16.18.2 RTL to RTL Peephole Optimizers.
Thanks, looks good, though the ChangeLog entry is missing, so
something like:
2013-07-23 Nicklas Bo Jensen
* doc/md.texi (Machine-Specific Peephole Optimizers): Fix a typo.
> Best,
> Nicklas
>
> Index: gcc/doc/md.texi
> ===
> --- gcc/doc/md.texi (revision 201156)
> +++ gcc/doc/md.texi (working copy)
> @@ -7578,7 +7578,7 @@
>"/* @r{determine 1 does not overlap 0 and 2} */"
>[(set (match_dup 4) (match_dup 1))
> (set (match_dup 0) (match_dup 4))
> - (set (match_dup 2) (match_dup 4))]
> + (set (match_dup 2) (match_dup 4))
> (set (match_dup 3) (match_dup 4))]
>"")
> @end smallexample
Marek
Re: [v3] libstdc++/57920
On 07/23/2013 11:56 AM, Paolo Carlini wrote: ... in the future, when we manage to actually avoid including from The C++11 string conversions could be exported by the *.so, aren't templates. Paolo.
[PATCH 1/5] Fix typos in fortran.
Hi, this is next in series of typo fixing patches.
I cleaned up http://kam.mff.cuni.cz/~ondra/gcc_misspells and fixed misspells
for letters a-d. I combined this list with what I done previously and here is
result.
I according to Joseph suggestion split it by directory.
This is done with following two scripts.
https://github.com/neleai/stylepp/tree/master/maintained/gcc/split_patch
https://github.com/neleai/stylepp/tree/master/maintained/gcc/prepare_patch
To simplify review I added stylepp_strip_diff tool. It takes a diff and
displays
them in compact way. Here you often fix same typo ten times which is much
easier to check
when you have them next to each other.
t counts and indices, including commas, asterices and brackets. */
t counts and indices, including commas, asterisks and brackets. */
^ ^
- for calling a ISO_C_BINDING becase c_loc and c_funloc
+ for calling a ISO_C_BINDING because c_loc and c_funloc
^ ^
- for calling a ISO_C_BINDING becase c_loc and c_funloc
+ for calling a ISO_C_BINDING because c_loc and c_funloc
^ ^
- /* Handle wide chracters. */
+ /* Handle wide characters. */
^ ^
- /* Handle wide chracters. */
+ /* Handle wide characters. */
^ ^
- /* Set this for compatibilty with g77 for /dev/null. */
+ /* Set this for compatibility with g77 for /dev/null.
*/
^ ^
* Restore the saved locus. Only used in conjonction with
* Restore the saved locus. Only used in conjunction with
^ ^
- /* Temporarily disable namelist delimters. */
+ /* Temporarily disable namelist delimiters. */
^^
- /* Obtain the umask without distroying the setting. */
+ /* Obtain the umask without destroying the setting. */
^^
- type; otherwise the allocation and initialisation proceeds as for any
+ type; otherwise the allocation and initialization proceeds as for any
^ ^
parameters seem to be for making parameterized derived types.
parameters seem to be for making parametrized derived types.
^ ^
-/* Status codes specifyed by the standard. */
+/* Status codes specified by the standard. */
^ ^
ould be an error. If a GENERIC already targetted this binding, it may
ould be an error. If a GENERIC already targeted this binding, it may
^ ^
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index c531d03..74ec79e 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,11 @@
+2013-07-23 Ondřej Bílka
+
+ * decl.c: Fix typos in fortran.
+ * interface.c: Likewise.
+ * symbol.c: Likewise.
+ * trans-array.c: Likewise.
+ * trans.c: Likewise.
+
2013-07-22 Tobias Burnus
PR fortran/57906
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index f1aa31e..1525119 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -8255,7 +8255,7 @@ match_procedure_in_type (void)
}
/* See if we already have a binding with this name in the symtree which
-would be an error. If a GENERIC already targetted this binding, it may
+would be an error. If a GENERIC already targeted this binding, it may
be already there but then typebound is still NULL. */
stree = gfc_find_symtree (ns->tb_sym_root, name);
if (stree && stree->n.tb)
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index f06ecfe..8d31d1c 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3170,7 +3170,7 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist
**ap, locus *where)
gfc_formal_arglist *dummy_args;
/* Warn about calls with an implicit interface. Special case
- for calling a ISO_C_BINDING becase c_loc and c_funloc
+ for calling a ISO_C_BINDING because c_loc and c_funloc
are pseudo-unknown. Additionally, warn about procedures not
explicitly declared at all if requested. */
if (sym->attr.if_source == IFSRC_UNKNOWN && ! sym->attr.is_iso_c)
@@ -3287,7 +3287,7 @@ void
gfc_ppc_use (gfc_component *comp, gfc_actual_arglist **ap, locus *where)
{
/* Warn about calls with an implicit interface. Special case
- for calling a ISO_C_BINDING becase c_loc and c_funloc
+ for calling a ISO_C_BINDING because c_loc and c_funloc
are pseudo-unknown. */
[PATCH 1/5] Fix typos in ada.
Hi, this is next in series of typo fixing patches.
I cleaned up http://kam.mff.cuni.cz/~ondra/gcc_misspells and fixed misspells
for letters a-d. I combined this list with what I done previously and here is
result.
I according to Joseph suggestion split it by directory.
This is done with following two scripts.
https://github.com/neleai/stylepp/tree/master/maintained/gcc/split_patch
https://github.com/neleai/stylepp/tree/master/maintained/gcc/prepare_patch
To simplify review I added stylepp_strip_diff tool. It takes a diff and
displays
them in compact way. Here you often fix same typo ten times which is much
easier to check
when you have them next to each other.
-@emph{AI-0177 Parameterized expressions (2010-07-10)}
+@emph{AI-0177 Parametrized expressions (2010-07-10)}
^ ^
e subprograms from Sinput are also made acessable here. */
e subprograms from Sinput are also made accessible here. */
^ ^
-alllocation, but it does use the
secondary stack, so an
+allocation, but it does use the
secondary stack, so an
^^
-@file{my_main.adb} file will be analysed in @file{my_main.adb.gcov}.
+@file{my_main.adb} file will be analyzed in @file{my_main.adb.gcov}.
^^
-indicate that the analysed set of sources is incomplete
to make up a
+indicate that the analyzed set of sources is incomplete
to make up a
^^
-been analysed, this is a typical case for
subprograms from precompiled
+been analyzed, this is a typical case for
subprograms from precompiled
^^
nonym of @option{-fdump-scos}, kept for backards compatibility.
nonym of @option{-fdump-scos}, kept for backwards compatibility.
^ ^
code{0} for the identification, because cancelling such a timer
code{0} for the identification, because canceling such a timer
^ ^
-@cindex Wide characte representations
+@cindex Wide character representations
^ ^
- /* If it was a DEC Ada specific condtiion, make it GNAT otherwise
+ /* If it was a DEC Ada specific condition, make it GNAT otherwise
^^
e no mechargs. We rely on the fact that condtions
e no mechargs. We rely on the fact that conditions
^ ^
atic exponents) are computed from their consistuents.
atic exponents) are computed from their constituents.
^^
-the corrresponding consequence is True on
exit. Other consequence expressions
+the corresponding consequence is True on
exit. Other consequence expressions
^^
active or when declarations generate initialisation
active or when declarations generate initialization
^ ^
-be treated as an initialisation routine by the linker (a
constructor). This
+be treated as an initialization routine by the linker (a
constructor). This
^ ^
- The new Ada 2012 notion of parameterized expressions is
implemented. The form
+ The new Ada 2012 notion of parametrized expressions is
implemented. The form
^ ^
-generate multiple or parameterized source files by means of
macro
+generate multiple or parametrized source files by means of
macro
^ ^
-preprocessing is triggered and parameterized.
+preprocessing is triggered and parametrized.
^ ^
- recommanded (through
"/dev/ptym/clone"). Indeed it seems that there are
+ recommended (through
"/dev/ptym/clone"). Indeed it seems that there are
^ ^
diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog
index 4e0b0a8..f1904b1 100644
--- a/gcc/ada/ChangeLog
+++ b/gcc/ada/ChangeLog
@@ -1,3 +1,11 @@
+2013-07-23 Ondřej Bílka
+
+ * gnat_rm.texi: Fix typos in ada.
+ * gnat_ugn.texi: Likewise.
+ * init.c: Likewise.
+ * namet.h: Likewise.
+ * terminals.c: Likewise.
+
2013-07-21 OndÅej BÃlka
* gcc-interface/gigi.h: Likewise.
diff
[PATCH 3/5] Fix typos in java.
Hi, this is next in series of typo fixing patches. I cleaned up http://kam.mff.cuni.cz/~ondra/gcc_misspells and fixed misspells for letters a-d. I combined this list with what I done previously and here is result. I according to Joseph suggestion split it by directory. This is done with following two scripts. https://github.com/neleai/stylepp/tree/master/maintained/gcc/split_patch https://github.com/neleai/stylepp/tree/master/maintained/gcc/prepare_patch To simplify review I added stylepp_strip_diff tool. It takes a diff and displays them in compact way. Here you often fix same typo ten times which is much easier to check when you have them next to each other. - // Aquire info using the current info as template for matching + // Acquire info using the current info as template for matching ^^ -// that this MUST NOT aquire any Java lock, as this could result in +// that this MUST NOT acquire any Java lock, as this could result in ^^ t the thread's interrupted flag *after* aquiring its wait_mutex. This t the thread's interrupted flag *after* acquiring its wait_mutex. This ^^ - // allways on. You always want this as far as I can see, but it also + // always on. You always want this as far as I can see, but it also ^^ - next free colorcell, atleast in one of the passes. */ + next free colorcell, at least in one of the passes. */ ^ ^ -// Our solution is to keep a vector of candiate offsets in each interface +// Our solution is to keep a vector of candidate offsets in each interface ^^ "_0xXX". Class names containing such chracters are uncommon, but "_0xXX". Class names containing such characters are uncommon, but ^ ^ - /* the likelyhood of object, int, or void return is very high, + /* the likelihood of object, int, or void return is very high, ^^ all frames in the interpreted stack and occurances all frames in the interpreted stack and occurrences ^ ^ - // if everything proceeded sucessfully, we're loaded. + // if everything proceeded successfully, we're loaded. ^ ^ ncremented to point after the character thta gets returns. ncremented to point after the character that gets returns. ^ ^ diff --git a/gcc/java/ChangeLog b/gcc/java/ChangeLog index 9cc34c5..517f17a 100644 --- a/gcc/java/ChangeLog +++ b/gcc/java/ChangeLog @@ -1,3 +1,7 @@ +2013-07-23 Ondřej Bílka + + * class.c: Fix typos in java. + 2013-06-05 Jan Hubicka * class.c (emit_register_classes_in_jcr_section): Use DECL_PRESERVE_P diff --git a/gcc/java/class.c b/gcc/java/class.c index cb67896..62bda1f 100644 --- a/gcc/java/class.c +++ b/gcc/java/class.c @@ -314,7 +314,7 @@ mangled_classname (const char *prefix, tree type) result = identifier_subst (ident, prefix, '.', '_', ""); /* Replace any characters that aren't in the set [0-9a-zA-Z_$] with - "_0xXX". Class names containing such chracters are uncommon, but + "_0xXX". Class names containing such characters are uncommon, but they do sometimes occur in class files. Without this check, these names cause assembly errors. diff --git a/libjava/ChangeLog b/libjava/ChangeLog index 23a6acc..b0c951a 100644 --- a/libjava/ChangeLog +++ b/libjava/ChangeLog @@ -1,3 +1,16 @@ +2013-07-23 Ondřej Bílka + + * defineclass.cc: Fix typos in java. + * gnu/gcj/runtime/natFinalizerThread.cc: Likewise. + * gnu/gcj/xlib/natColormap.cc: Likewise. + * gnu/gcj/xlib/natVisual.cc: Likewise. + * include/jvm.h: Likewise. + * interpret-run.cc: Likewise. + * java/lang/natVMClassLoader.cc: Likewise. + * link.cc: Likewise. + * posix-threads.cc: Likewise. + * stacktrace.cc: Likewise. + 2013-06-20 Roland Lutz * contrib/aot-compile.in: Fix typo in option list. diff --git a/libjava/defineclass.cc b/libjava/defineclass.cc index c7a32cc..3051444 100644 --- a/libjava/defineclass.cc +++ b/libjava/defineclass.cc @@ -81,7 +81,7 @@ struct _Jv_ClassReader // do verification? Currently, there is no option to disable this. // This flag just controls the verificaiton done by the class loader; // i.e., checking the integrity of the constant pool; and it is - // allways on. You always want this as far as I can see, but it also + // always on. You always
Re: [v3] libstdc++/57920
2013/7/23 Paolo Carlini : > ... in the future, when we manage to actually avoid including from > I think we can avoid including it from if we play a bit > with void*. Should be safe aliasing-wise. Something like the below, > completely untested. I tested it on my target. At least the elf toolchain can be successfully built with such changes. Best regards, jasonwucj
Re: [PATCH 1/5] Fix typos in ada.
I'm not thrilled by changing all refs to Parameterized by Parametrized. Is Parameterized UK only, or is this an OK spelling for American/International english as well? If the latter, I wouldn't change these references. Other changes are OK. Arno
Re: [PATCH 1/5] Fix typos in ada.
> > I'm not thrilled by changing all refs to Parameterized by Parametrized. > > > > Is Parameterized UK only, or is this an OK spelling for > > American/International > > english as well? > > > From http://gcc.gnu.org/codingconventions.html#Spelling > > Use......instead of > Rationale > American spelling (in particular -ize, -or) British spelling (in > particular -ise, -our) Yes, the above is compatible with the spelling Parameterized. > If you do not want that change ask to remove this rule. See above, the rule is fine as is. Arno
Re: [PATCH 4/5] Fix typos in libstdc++.
Hi, spotted a few debatable items. On 07/23/2013 12:45 PM, Ondřej Bílka wrote: -Ammend D.12.1 [auto.ptr]p2: +Amend D.12.1 [auto.ptr]p2: ^^ -Ammend [list.capacity] p1: +Amend [list.capacity] p1: ^^ -Ammend in both: +Amend in both: ^^ -Ammend p3 Freestanding implementations 17.6.1.3 [compliance] +Amend p3 Freestanding implementations 17.6.1.3 [compliance] ^^ -Ammend the tuple class template declaration in 20.4.2 [tuple.tuple] as +Amend the tuple class template declaration in 20.4.2 [tuple.tuple] as ^^ -Initialisation of atomics: +Initialization of atomics: ^ ^ -// Remeber the PID for the process that created the semaphore set +// Remember the PID for the process that created the semaphore set ^ ^ ressions should be well-formed, even in absense of access: ressions should be well-formed, even in absence of access: ^^ -member function and other acessors return the stored value as a void*. +member function and other accesors return the stored value as a void*. ^ ^ I think accessor is fine. to Review. Unfortunately the issue was accidently to Review. Unfortunately the issue was accidentally ^^ got swap for pair but accidently got swap for pair but accidentally ^^ ects.html#541">LWG 541 for how this accidently ects.html#541">LWG 541 for how this accidentally ^^ issue was voted to WP in Bellevue, but accidently got stepped on by issue was voted to WP in Bellevue, but accidentally got stepped on by ^^ We do not want to be in a position of accidently introducing this We do not want to be in a position of accidentally introducing this ^^ r type. I believe this restriction was accidently removed r type. I believe this restriction was accidentally removed ^^ 1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798. 1.2 [func.bind.bind]/p3, p6 and p7 were accidentally removed from N2798. ^^ - * resized to a value which it cannot accomodate at runtime. Illegal + * resized to a value which it cannot accommodate at runtime. Illegal ^ ^ -purpose without complications to accomodate other uses: +purpose without complications to accommodate other uses: ^ ^ empting to engineer forward to accomodate uses other than perfect empting to engineer forward to accommodate uses other than perfect ^ ^ - type capable of accomodating 32-bit quantities. + type capable of accommodating 32-bit quantities. ^ ^ -contributor acknowledgements and/or dedications given therein. +contributor acknowledgments and/or dedications given therein. ^^ -2010-11-03 Daniel comments and adjustes the currently proposed wording changes: +2010-11-03 Daniel comments and adjusts the currently proposed wording changes: ^^ -all the other heap alogorithms. The should be called out in the +all the other heap algorithms. The should be called out in the ^^ -dynamically allcoated memory, passing ownership of dynamically allocated +dynamically allocated memory, passing ownership of dynamically allocated ^ ^ -Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording. +Bellevue: Wording is already presen
Re: [PATCH 4/5] Fix typos in libstdc++.
I agree with all Paolo's comments. Also libstdc++-v3/doc/html/ext/lwg-active.html is imported from elsewhre so it's pointless fixing it, the upstream version comes from https://github.com/cplusplus/LWG Most of the changes are replacing British English with American English, so low priority. I'll apply the correct parts of the patch and commit it. Thanks.
Re: [PATCH, AArch64] Change to pass -mabi=* directly to the assembler
On 19 July 2013 11:45, Yufeng Zhang wrote: > Hi, > > Following the work in AArch64 GAS to unify the ABI command line interface, > this patch updates the compiler driver to pass -mabi=* directly to the > assembler. > > The related GAS patch is here: > http://www.sourceware.org/ml/binutils/2013-07/msg00180.html > > OK for the trunk (after the initial ILP32 patch set are committed)? OK /Marcus
Re: [Patch, AArch64, ILP32] Pad pointer-typed stack argument downward in ILP32
On 27 June 2013 17:00, Yufeng Zhang wrote: > This patch fixes the bug that pointer-typed argument passed on stack is not > padded properly in ILP32. > > OK for the trunk? OK /Marcus
Re: [PATCH, AArch64] Add support for "wsp" register
On 4 July 2013 08:07, Yufeng Zhang wrote:
> Hi,
>
> This patch adds support for the register "wsp"; in ILP32, this is necessary
> in order to support the global register variable associated the stack
> pointer with the syntax asm ("wsp"); it is used in libgloss to get the stack
> pointer.
>
> OK for the trunk?
OK
/Marcus
Re: [Patch] regex_iterator and regex_token_iterator implementation
On 23 July 2013 10:18, Tim Shen wrote: > > Are other parts ok? Could you please look at them? In regex_token_iterator::_M_init the for loop could be replaced with either for (auto __i : subs) or a call to std::find, which wouldn't need the cast to int, but that's just stylistic and a matter of taste. With the uglified names restored the patch is good to commit, thanks very much.
Re: [PATCH 1/5] Fix typos in fortran.
Ondřej Bílka wrote: Hi, this is next in series of typo fixing patches. I committed the this Fortran as Rev. 201162, skipping only the "parameterized"-to-"parametrized" change. That change was disputed at other parts of this patch series and Merriam-Webster lists the former as default entry and the "-trized" only as variant. (Same for Oxford's dictionary, while Thunderbird's spellchecker only knows the latter.) I did include the -ise to -ize and the -tt- to -t- change to make the readers on the other side of the pond happy. (Admittedly, both are also the preferred spelling in the Oxford Dictionary of English.) Tobias
Re: [PATCH 1/5] Fix typos in fortran.
Ondřej Bílka wrote: Hi, this is next in series of typo fixing patches. I committed the this Fortran as Rev. 201162, skipping only the "parameterized"-to-"parametrized" change. That change was disputed at other parts of this patch series and Merriam-Webster lists the former as default entry and the "-trized" only as variant. (Same for Oxford's dictionary, while Thunderbird's spellchecker only knows the latter.) I did include the -ise to -ize and the -tt- to -t- change to make the readers on the other side of the pond happy. (Admittedly, both are also the preferred spelling in the Oxford Dictionary of English.) Tobias
Re: [PATCH 4/5] Fix typos in libstdc++.
On Tue, Jul 23, 2013 at 12:26:23PM +0100, Jonathan Wakely wrote: > I agree with all Paolo's comments. > > Also libstdc++-v3/doc/html/ext/lwg-active.html is imported from > elsewhre so it's pointless fixing it, the upstream version comes from > https://github.com/cplusplus/LWG > ok, I have one redirection more. > Most of the changes are replacing British English with American > English, so low priority. I'll apply the correct parts of the patch > and commit it. > > Thanks.
[PATCH, AArch64] Support NEG in vector registers for DI and SI mode
Support added for scalar NEG instruction in vector registers.
Execution testcase included.
Tested on usual GCC Linux regressions.
OK for trunk?
Cheers,
Ian
2013-07-23 Ian Bolton
gcc/
* config/aarch64/aarch64-simd.md (neg2): Offer alternative
that uses vector registers.
testsuite/
* gcc.target/aarch64/neg_1.c: New test.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index e88e5be..d76056c 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -2004,12 +2004,17 @@
)
(define_insn "neg2"
- [(set (match_operand:GPI 0 "register_operand" "=r")
- (neg:GPI (match_operand:GPI 1 "register_operand" "r")))]
+ [(set (match_operand:GPI 0 "register_operand" "=r,w")
+ (neg:GPI (match_operand:GPI 1 "register_operand" "r,w")))]
""
- "neg\\t%0, %1"
+ "@
+ neg\\t%0, %1
+ neg\\t%0, %1"
[(set_attr "v8type" "alu")
- (set_attr "mode" "")]
+ (set_attr "simd_type" "*,simd_negabs")
+ (set_attr "simd" "*,yes")
+ (set_attr "mode" "")
+ (set_attr "simd_mode" "")]
)
;; zero_extend version of above
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 8e40c5d..7acbcfd 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -277,6 +277,12 @@
(V2DI "") (V2SF "")
(V4SF "") (V2DF "")])
+;; Register Type Name and Vector Arrangement Specifier for when
+;; we are doing scalar for DI and SIMD for SI (ignoring all but
+;; lane 0).
+(define_mode_attr rtn [(DI "d") (SI "")])
+(define_mode_attr vas [(DI "") (SI ".2s")])
+
;; Map a floating point mode to the appropriate register name prefix
(define_mode_attr s [(SF "s") (DF "d")])
diff --git a/gcc/testsuite/gcc.target/aarch64/neg_1.c
b/gcc/testsuite/gcc.target/aarch64/neg_1.c
new file mode 100644
index 000..04b0fdd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/neg_1.c
@@ -0,0 +1,67 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fno-inline --save-temps" } */
+
+extern void abort (void);
+
+long long
+neg64 (long long a)
+{
+ /* { dg-final { scan-assembler "neg\tx\[0-9\]+" } } */
+ return 0 - a;
+}
+
+long long
+neg64_in_dreg (long long a)
+{
+ /* { dg-final { scan-assembler "neg\td\[0-9\]+, d\[0-9\]+" } } */
+ register long long x asm ("d8") = a;
+ register long long y asm ("d9");
+ asm volatile ("" : : "w" (x));
+ y = 0 - x;
+ asm volatile ("" : : "w" (y));
+ return y;
+}
+
+int
+neg32 (int a)
+{
+ /* { dg-final { scan-assembler "neg\tw\[0-9\]+" } } */
+ return 0 - a;
+}
+
+int
+neg32_in_sreg (int a)
+{
+ /* { dg-final { scan-assembler "neg\tv\[0-9\]+\.2s, v\[0-9\]+\.2s" } } */
+ register int x asm ("s8") = a;
+ register int y asm ("s9");
+ asm volatile ("" : : "w" (x));
+ y = 0 - x;
+ asm volatile ("" : : "w" (y));
+ return y;
+}
+
+int
+main (void)
+{
+ long long a;
+ int b;
+ a = 61;
+ b = 313;
+
+ if (neg64 (a) != -61)
+abort ();
+
+ if (neg64_in_dreg (a) != -61)
+abort ();
+
+ if (neg32 (b) != -313)
+abort ();
+
+ if (neg32_in_sreg (b) != -313)
+abort ();
+
+ return 0;
+}
+
+/* { dg-final { cleanup-saved-temps } } */
[Patch] Reimplment regex matcher using DFS
This is the most exciting patch from me so far! XD Here I temporarily shadow the Thompson NFA matcher[1](original _Grep_matcher), and use the Depth-First Search(DFS, or backtracking) approach instead. Yes, DFS is *exponentially slow* :( However we need it, because when encountering the feature "back-reference", like "\1" in "([A-Z])\1*", DFS is the best choice[1]. Thompson NFA matcher, which essentially is a memoized Breadth-first search, probably can not hold large scale back-references : there may be a huge space consumption for saving different matching statuses. It will come back, but now let's keep this in mind : "Premature optimization is the root of all evil". At last, two bug reports(libstdc++/53622 and libstdc++/57173) said that there're regex grouping problems. It's relatively simple fix it in the DFS approach, and I added them to the testsuite. Shall I write PR in the ChangeLog? What does PR stand for? By the way, probably I shouldn't add too much comment in the code(what if it's changed for reasons?). At the final section of my GSoC participation, I'll spend all time adding documents and comments. Waiting for reviewing. Thank you all! [1] http://swtch.com/~rsc/regexp/regexp1.html -- Tim Shen dfs-matcher.patch Description: Binary data
Re: Minor Cygwin patches
On 7/19/2013 15:21, Yaakov (Cygwin/X) wrote: > On 2013-07-14 20:15, JonY wrote: >> 2013-03-08 Yaakov Selkowitz >> >> * (gcc/testsuite/gcc.target/i386/pr25993.c): Skip unsupported test. > > This patch was Dave Korn's. > > OK. Changelog 2013-03-08 Dave Korn * (gcc/testsuite/gcc.target/i386/pr25993.c): Skip unsupported test. signature.asc Description: OpenPGP digital signature
Re: Minor Cygwin patches
On 7/19/2013 15:23, Yaakov (Cygwin/X) wrote: > On 2013-07-14 20:15, JonY wrote: >> 2013-03-08 Dave Korn >> >> * (gcc/config.gcc): Include Cygwin specific file. >> * (gcc/config/i386/cygwin.h): Link shared libgcc by default. >> * (gcc/config/i386/cygwin.h): Add --large-address-aware, and use >>--tsaware for exes >> * (gcc/config/i386/cygwin.h): Add -pthreads, -rdynamic stubs. >> * (gcc/config/i386/cygwin.opt): New file. > > Only the "link shared libgcc by default" part was Dave's; the rest is mine. > > OK Changelog 2013-03-08 Dave Korn * (gcc/config/i386/cygwin.h): Link shared libgcc by default. 2013-03-08 Yaakov Selkowitz * (gcc/config.gcc): Include Cygwin specific file. * (gcc/config/i386/cygwin.h): Add --large-address-aware, and use --tsaware for exes * (gcc/config/i386/cygwin.h): Add -pthreads, -rdynamic stubs. * (gcc/config/i386/cygwin.opt): New file. signature.asc Description: OpenPGP digital signature
Re: [Patch] Reimplment regex matcher using DFS
Hi, On 07/23/2013 03:07 PM, Tim Shen wrote: At last, two bug reports(libstdc++/53622 and libstdc++/57173) said that there're regex grouping problems. It's relatively simple fix it in the DFS approach, and I added them to the testsuite. Shall I write PR in the ChangeLog? What does PR stand for? PR stands for Problem Report. Traditionally adding this kind of header to the ChangeLog entry triggered a script on the machine running Subversion which sent a message to Bugzilla, which added the commit log to the Audit Trail of the corresponding bug report. Nice. Unfortunately, the thing doesn't work now (apparently we need another Google Summer of Code person for it ;) but I don't see why we shouldn't keep on decorating the ChangeLog entry like this, in this specific way instead of another. The general idea is that if a commit is fixing a bug, that should be clear in the ChangeLog and I think it makes a lot of sense. Of course, if the commit does *much* more than fixing a bug, it's debatable whether the header really makes sense, we could as well only write the bug number in a comment inside the testcase, or use it as the name itself of the testcase (or both). Paolo.
Re: Add more info to google/gcc-4_8 powerpc64 xfails file.
On Tue, Jul 23, 2013 at 1:50 AM, Brooks Moses wrote: > Diego - > > The attached patch adds a little more analysis info to the powerpc64 > xfails file. Ok to commit? OK. Diego.
Re: [Patch] Reimplment regex matcher using DFS
On 07/23/2013 03:07 PM, Tim Shen wrote:
+ inline
+ bool _Grep_matcher::
+ _M_dfs_match()
+ { return _M_dfs(_M_nfa->_M_start()); }
+
+ inline
+ bool _Grep_matcher::
+ _M_dfs_search_from_first()
+ { return _M_dfs(_M_nfa->_M_start()); }
This doesn't make much sense to me: if the functions are inside a *.tcc
file why are marked inline? First blush seem indeed good candidates for
inline, but then should be in the *.h
Paolo.
Re: [Patch] Reimplment regex matcher using DFS
.. not that, in general, *all* the testcases coming from a bug report in Bugzilla, should either be named after the bug # or have the information in a comment inside (or both, as I said already) Paolo.
Go patch committed: Don't include "except.h" in go-lang.c
This patch removes the #include of "except.h" from go-lang.c. I added it in order to call build_personality_function, but that declaration is now in tree.h. except.h is considered to be a backend header that should not be included in frontend code. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2013-07-23 Ian Lance Taylor * go-lang.c: Don't #include "except.h". * Make-lang.in (go/go-lang.o): Don't depend on $(EXCEPT_H). Index: go-lang.c === --- go-lang.c (revision 200210) +++ go-lang.c (working copy) @@ -33,7 +33,6 @@ along with GCC; see the file COPYING3. #include "diagnostic.h" #include "langhooks.h" #include "langhooks-def.h" -#include "except.h" #include "target.h" #include "common/common-target.h" Index: Make-lang.in === --- Make-lang.in (revision 200210) +++ Make-lang.in (working copy) @@ -248,7 +248,7 @@ CFLAGS-go/go-lang.o += -DDEFAULT_TARGET_ go/go-lang.o: go/go-lang.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(OPTS_H) \ $(TREE_H) $(GIMPLE_H) $(GGC_H) $(TOPLEV_H) debug.h options.h \ $(FLAGS_H) convert.h $(DIAGNOSTIC_H) langhooks.h \ - $(LANGHOOKS_DEF_H) $(EXCEPT_H) $(TARGET_H) $(GO_C_H) \ + $(LANGHOOKS_DEF_H) $(TARGET_H) $(GO_C_H) \ gt-go-go-lang.h gtype-go.h $(COMMON_TARGET_H) GOINCLUDES = -I $(srcdir)/go -I $(srcdir)/go/gofrontend
Re: Go patch committed: Update libgo to 1.1.1
Hello!
I have committed a large patch to update libgo to the library that was
part of the Go 1.1.1 release. As usual, I'm not including the entire
patch in this e-mail message, because it is too large. I'm only
including the changes to the files that are partially gccgo-specific.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
>>>
>>> I have hit following build failure on non-USING_SPLIT_STACK target
>>> (alpha-linux-gnu):
>>
>> Thanks. Fixed like so. Committed to mainline and 4.8 branch.
>
> Thanks, with your patch, I was able to compile libgo without problems.
> The testsuite run exposes a timeout in net/http, I am looking into it.
>
> Another problem was triggered on CentOS 5.9, where compile fails with:
>
> ../../../gcc-svn/trunk/libgo/runtime/netpoll_epoll.c: In function
> ‘runtime_epollcreate1’:
> ../../../gcc-svn/trunk/libgo/runtime/netpoll_epoll.c:41:2: error:
> implicit declaration of function ‘epoll_create1’
> [-Werror=implicit-function-declaration]
> r = epoll_create1(flags);
> ^
> cc1: all warnings being treated as errors
> gmake[4]: *** [netpoll_epoll.lo] Error 1
> gmake[4]: *** Waiting for unfinished jobs
>
> CentOS has glibc 2.5 and epoll_create1 is not supported.
Attached patch fixes this problem by providing prototype, missing from
sys/poll.h in netpoll_epoll.c.
Patch was tested on x86_64-pc-linux-gnu {,-m32} on CentOS 5.9 and Fedora 19.
Uros.
Index: runtime/netpoll_epoll.c
===
--- runtime/netpoll_epoll.c (revision 201156)
+++ runtime/netpoll_epoll.c (working copy)
@@ -20,6 +20,10 @@
#define EPOLL_CLOEXEC 0200
#endif
+#ifndef HAVE_EPOLL_CREATE1
+extern int epoll_create1 (int __flags);
+#endif
+
typedef struct epoll_event EpollEvent;
static int32
Re: [Patch] Reimplment regex matcher using DFS
On Tue, Jul 23, 2013 at 9:42 PM, Paolo Carlini wrote: > This doesn't make much sense to me: if the functions are inside a *.tcc file > why are marked inline? First blush seem indeed good candidates for inline, > but then should be in the *.h My view is like this : When I put something into the class definition, I expected it doesn't frequently changing. It's part of the interfaces. When I find some small function body, I inline it. In the future the function _M_dfs_match() and _M_dfs_search_from_first() may change. So I decide to pull them out of the class definition. Is this naive or not? -- Tim Shen
Re: [patch] [python libstdc++ printers] Fix gdb/15195
> "Phil" == Phil Muldoon writes: Phil> On 03/07/13 08:33, Phil Muldoon wrote: >> This new patch replaces and obsoletes the previous. On further >> inspection of some other pretty printer related bugs, it seems that >> all of the printers need to fetch the referenced value where the value >> type is a reference. This patch applies that change, and adds a >> number of reference based tests. Phil> ping I sent a reply last Thursday: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00713.html Tom
Re: [PATCH] [ARM] Fix PR57909 : ICE with internal memcpy and -mno-unaligned-access
Hi, I forgot to add the test case with the PR fix, the attached patch add it. Thanks, Yvan ChangeLog gcc/testsuite 2013-07-23 Yvan Roux PR target/57909 * gcc.target/arm/pr57909.c: New test. On 17 July 2013 10:58, Ramana Radhakrishnan wrote: > On 07/17/13 09:53, Yvan Roux wrote: >> >> Hi, >> >> this patch fixes the issue described in PR57909, where we have an ICE >> during the internal memcpy, as some UNSPEC_UNALIGNED insns are emitted >> even if -mno-unaligned-access flag is passed. See the link below for a >> more detailled description: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 >> >> Tested without any regression. >> >> Thanks, >> Yvan >> >> ChangeLog >> >> gcc/ >> >> 2013-07-17 Yvan Roux >> >> PR target/57909 >> * config/arm/arm.c (gen_movmem_ldrd_strd): Fix unaligned >> load/store >> usage in HI mode. >> > > Ok. > > regards > Ramana > > pr57909-test.diff Description: Binary data
Re: [Patch] Reimplment regex matcher using DFS
Hi, >Is this naive or not? I don't know. For sure we don't want inline code in *.tcc headers. Paolo
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
Hi,
On Mon, Jul 22, 2013 at 03:22:33PM -0400, David Malcolm wrote:
> On Mon, 2013-07-22 at 20:25 +0200, Martin Jambor wrote:
> > On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote:
> > > gcc/
> > >
> > > Explicitly number the instances of passes within passes.def.
> > >
> > > This is needed by a subsequent patch so that we can create
> > > fields within the pipeline class for each pass instance (to help
> > > locate pass instances when debugging).
> > >
> >
> > I don't really understand what you want to achieve. Are you sure the
> > benefits are worth the work necessary to implement the processing of
> > passes.def.in? Especially given that we already initialize
> > static_pass_number at run time and copy stuff around in
> > make_pass_instance when it is already set. I assume this would
> > somehow allow us to directly dump data of say forwprop3 as apposed to
> > forwprop2 to but that would require constant awareness of the sequence
> > number of the currently running pass, which I think is also unpleasant
> > and error-prone.
> >
> > I mean, you may have perfectly legitimate reasons for doing this, I'm
> > just wondering whether we are perhaps over-engineering this a bit.
>
> The main goal here is part of eliminating global variables from gcc [1],
> to be able to create:
>
> class pipeline
> {
> /* omitting various other fields for clarity */
>
> opt_pass *pass_warn_unused_result;
> opt_pass *pass_diagnose_omp_blocks;
> opt_pass *pass_diagnose_tm_blocks;
> opt_pass *pass_mudflap_1;
> opt_pass *pass_lower_omp;
> opt_pass *pass_lower_cf;
> opt_pass *pass_lower_tm;
> opt_pass *pass_refactor_eh;
> opt_pass *pass_lower_eh;
> opt_pass *pass_build_cfg;
> opt_pass *pass_warn_function_return;
> opt_pass *pass_expand_omp;
> opt_pass *pass_build_cgraph_edges;
> opt_pass *pass_ipa_free_lang_data;
> opt_pass *pass_ipa_function_and_variable_visibility;
> opt_pass *pass_early_local_passes;
> opt_pass *pass_fixup_cfg;
> opt_pass *pass_init_datastructures;
> /* etc */
> opt_pass *pass_clean_state;
> };
>
> without having to list all of the pass kinds again, thus reusing the
> pass description from passes.def. Without the numbering, I couldn't see
> a good way to avoid duplicate field names in the class. So the
> numbering gives us uniqueness of field names in that class (and also
> makes debugging slightly easier, but that's a minor side-benefit).
>
I really think the easier debugging benefit is really very small, if
any. Is there another one? Otherwise, I wouldn't bother with
explicit static fields for each pass but just have a linked list of
them. If we ever make the pass manager to really be a manager of some
sort, this will happen anyway.
And as far as gdb is concerned, I'd rather avoid typing:
p
current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[1]->stuff
p
current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[2]->stuff
p
current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[3]->stuff
and instead do
set $d = (my_great_pass_class *) current_context->current_pass
p $d->my_array[1]->stuff
p $d->my_array[2]->stuff
p $d->my_array[3]->stuff
Or am I missing something? Otherwise I'd just say don't bother with awk.
Thanks,
Martin
Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
Hmm, I suppose this could still end up doing unnecessary completions if both types are incomplete. What happens if X is also incomplete? The version that returns false if either is incomplete would give the wrong answer if the types are the same. I think a better way would be to use COMPARE_STRICT if either type is incomplete. Jason
Re: [Patch] Reimplment regex matcher using DFS
Revised version, with _M_dfs_* moved to the class definition, PR testcases, and some comments on _M_dfs(). Thanks. -- Tim Shen dfs-matcher.patch Description: Binary data
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
On Tue, 2013-07-23 at 16:46 +0200, Martin Jambor wrote:
> Hi,
>
> On Mon, Jul 22, 2013 at 03:22:33PM -0400, David Malcolm wrote:
> > On Mon, 2013-07-22 at 20:25 +0200, Martin Jambor wrote:
> > > On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote:
> > > > gcc/
> > > >
> > > > Explicitly number the instances of passes within passes.def.
> > > >
> > > > This is needed by a subsequent patch so that we can create
> > > > fields within the pipeline class for each pass instance (to help
> > > > locate pass instances when debugging).
> > > >
> > >
> > > I don't really understand what you want to achieve. Are you sure the
> > > benefits are worth the work necessary to implement the processing of
> > > passes.def.in? Especially given that we already initialize
> > > static_pass_number at run time and copy stuff around in
> > > make_pass_instance when it is already set. I assume this would
> > > somehow allow us to directly dump data of say forwprop3 as apposed to
> > > forwprop2 to but that would require constant awareness of the sequence
> > > number of the currently running pass, which I think is also unpleasant
> > > and error-prone.
> > >
> > > I mean, you may have perfectly legitimate reasons for doing this, I'm
> > > just wondering whether we are perhaps over-engineering this a bit.
> >
> > The main goal here is part of eliminating global variables from gcc [1],
> > to be able to create:
> >
> > class pipeline
> > {
> > /* omitting various other fields for clarity */
> >
> > opt_pass *pass_warn_unused_result;
> > opt_pass *pass_diagnose_omp_blocks;
> > opt_pass *pass_diagnose_tm_blocks;
> > opt_pass *pass_mudflap_1;
> > opt_pass *pass_lower_omp;
> > opt_pass *pass_lower_cf;
> > opt_pass *pass_lower_tm;
> > opt_pass *pass_refactor_eh;
> > opt_pass *pass_lower_eh;
> > opt_pass *pass_build_cfg;
> > opt_pass *pass_warn_function_return;
> > opt_pass *pass_expand_omp;
> > opt_pass *pass_build_cgraph_edges;
> > opt_pass *pass_ipa_free_lang_data;
> > opt_pass *pass_ipa_function_and_variable_visibility;
> > opt_pass *pass_early_local_passes;
> > opt_pass *pass_fixup_cfg;
> > opt_pass *pass_init_datastructures;
> > /* etc */
> > opt_pass *pass_clean_state;
> > };
> >
> > without having to list all of the pass kinds again, thus reusing the
> > pass description from passes.def. Without the numbering, I couldn't see
> > a good way to avoid duplicate field names in the class. So the
> > numbering gives us uniqueness of field names in that class (and also
> > makes debugging slightly easier, but that's a minor side-benefit).
> >
>
> I really think the easier debugging benefit is really very small, if
> any. Is there another one? Otherwise, I wouldn't bother with
> explicit static fields for each pass but just have a linked list of
> them. If we ever make the pass manager to really be a manager of some
> sort, this will happen anyway.
>
> And as far as gdb is concerned, I'd rather avoid typing:
>
> p
> current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[1]->stuff
> p
> current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[2]->stuff
> p
> current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[3]->stuff
Thanks - yes - I completely agree, having spent a lot of time in gdb
with this lately :)
Note that there is only one "pipeline" per context, and I've kept the
existing pass struct names (meaning "pass_vrp" rather than "vrp").
BTW, you mentioned dumping in an earlier post, sorry for not clarifying
that aspect. I haven't changed how dumping works, and I've taken some
care to ensure that the numbering of the pass instances isn't disturbed
(an earlier version of my patches broke that, leading to some of the
test suite failing). So whatever static_pass_number the 2nd instance
of vrp ended up with before, it will continue to end up with after my
patches.
> and instead do
>
> set $d = (my_great_pass_class *) current_context->current_pass
> p $d->my_array[1]->stuff
> p $d->my_array[2]->stuff
> p $d->my_array[3]->stuff
>
> Or am I missing something? Otherwise I'd just say don't bother with awk.
To give you a flavor of what I'm aiming at, here's a transcript from gdb
on a build with some further patches, with some comments added inline:
The global "current context" variable is simply "g", for ease of typing
- and my hope is that eventually this will be the *only* global variable
[1]:
(gdb) p g
$1 = (gcc::context *) 0x15652a0
In the talk I gave at Cauldron [2], this was a (universe*), but I've
changed my mind again, and prefer (gcc::context*) i.e. it's now a
"context" within a "gcc" namespace. The namespace is confusing
gengtype, so I'm not sure about that aspect.
The pipeline of passes is simply the "passes_" field of the context;
here's an example of tab-completion:
(gdb) p g->passes_->
Display all 2
Re: Typo in GCC Internals documentation.
On 07/23/2013 04:01 AM, Marek Polacek wrote: On Tue, Jul 23, 2013 at 11:32:39AM +0200, Nicklas Bo Jensen wrote: Hi, Found a typo in the GCC Internals documentation in one of the code examples in 16.18.2 RTL to RTL Peephole Optimizers. Thanks, looks good, though the ChangeLog entry is missing, so something like: 2013-07-23 Nicklas Bo Jensen * doc/md.texi (Machine-Specific Peephole Optimizers): Fix a typo. Thanks. Installed. jeff
Re: [Patch, PR 57811] Wasted work in find_reloads()
On 07/22/2013 10:39 AM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached one-line patches that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 Bootstrap and regression-tested on x86_64-linux. In method "find_reloads()" in gcc/reload.c, the loop on line 3324 should break immediately after "badop" is set to "1". Also, the loop on line 4641 should break after "ok" is set to "0". 2013-07-22 Chang * reload.c (find_reloads): Exit loop once we find this operand cannot be reloaded somehow for this alternative. * reload.c (find_reloads): Exit loop once we find a hard register. Thanks. Installed. jeff
Re: [Patch, PR 57787] Wasted work in ix86_pad_returns()
On 07/22/2013 12:01 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787. Bootstrap and regression-tested on x86_64-linux. In method "ix86_pad_returns()" in i386.c, the loop on line 35723 should break immediately after "replace" is set to "true". 2013-07-22 Chang * i386.c (ix86_pad_returns): Exit loop after setting replace. Thanks. Installed. jeff
Re: [Patch, PR 57782] Wasted work in remove_path()
On 07/22/2013 03:59 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 200945 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782 In method "remove_path()" in cfgloopmanip.c, the loop on line 343 should break immediately after "irred_invalidated" is set to "true". 2013-07-22 Chang * cfgloopmanip.c (remove_path): Exit loop after setting irred_invalidated. Thanks. Installed. jeff
Go patch committed: Don't call init_varasm_once again
In http://gcc.gnu.org/ml/gcc-patches/2010-08/msg02019.html I added code
to call init_varasm_once again if a package imports unsafe. As that
message explains, this is to avoid an assert in
mems_in_disjoint_alias_sets_p if it sees a non-zero alias set when
flag_strict_aliasing is false. However, I tested removing the call to
init_varasm_once in the current compiler, and the assert never triggers.
This appears to be because the alias set allocate in init_varasm_once is
only used for constant memory addresses (MEM_READONLY_P). The patch
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01758.html fixed
canon_true_dependence so that it gets out quickly for a MEM_READONLY_P
address. So as far as I can tell const_alias_set is no longer used for
anything, so it is no longer necessary to reinitialize it to avoid the
assert.
This patch avoids the call to init_varasm_once and lets me remove the
#include of the backend-only rtl.h from the frontend go-backend.c.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
2013-07-23 Ian Lance Taylor
* go-backend.c: Don't #include "rtl.h".
(go_imported_unsafe): Don't call init_varasm_once.
* Make-lang.in (go/go-backend.o): Don't depend on $(RTL_H).
Index: Make-lang.in
===
--- Make-lang.in (revision 201171)
+++ Make-lang.in (working copy)
@@ -240,7 +240,7 @@ GO_RUNTIME_H = go/gofrontend/runtime.h g
GO_AST_DUMP_H = go/gofrontend/ast-dump.h go/gofrontend/string-dump.h
go/go-backend.o: go/go-backend.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
- $(TM_H) $(RTL_H) $(TREE_H) $(TM_P_H) output.h $(TARGET_H) \
+ $(TM_H) $(TREE_H) $(TM_P_H) output.h $(TARGET_H) \
$(COMMON_TARGET_H)
CFLAGS-go/go-lang.o += -DDEFAULT_TARGET_VERSION=\"$(version)\" \
Index: go-backend.c
===
--- go-backend.c (revision 200210)
+++ go-backend.c (working copy)
@@ -22,7 +22,6 @@ along with GCC; see the file COPYING3.
#include "coretypes.h"
#include "simple-object.h"
#include "tm.h"
-#include "rtl.h"
#include "tree.h"
#include "tm_p.h"
#include "intl.h"
@@ -91,12 +90,6 @@ go_imported_unsafe (void)
{
flag_strict_aliasing = false;
- /* This is a real hack. init_varasm_once has already grabbed an
- alias set, which we don't want when we aren't doing strict
- aliasing. We reinitialize to make it do it again. This should
- be OK in practice since we haven't really done anything yet. */
- init_varasm_once ();
-
/* Let the backend know that the options have changed. */
targetm.override_options_after_change ();
}
Re: [Patch, PR 57780] Waste work in subst_dup()
On 07/22/2013 07:39 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57780 Bootstrap and regression-tested on x86_64-linux. In method "subst_dup()" in gensupport.c, the loop on line 2181 should not be executed when "code" equals to "MATCH_DUP" or "MATCH_OP_DUP". 2013-07-22 Chang * gensupport.c (subst_dup): Avoid loop if code is not MATCH_DUP nor MATCH_OP_DUP. Thanks. Installed. We're probably getting to a point where the sum of all these fixes is going to require a copyright assignment. If you could start that process with the FSF it would be greatly appreciated. http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future You may also need an employer disclaimer. ass...@gnu.org can help you with ensuring you get the right paperwork. It also seems to me you should get an account on gcc.gnu.org so that you can commit approved changes, close PRs, etc. Here's the form. List me as the sponsor/approver: http://sourceware.org/cgi-bin/pdw/ps_form.cgi You might also want to review: http://gcc.gnu.org/svnwrite.html Thanks again, Jeff
[PATCH, PowerPC] altivec_expand_vec_perm_const selects wrong field for splat in LE mode
This patch fixes another small little-endian problem with vectors on
PowerPC. Element numbering is reversed when selecting a field for a
vector splat operation. Fixing this removes a regression from the test
suite when run in LE mode (gcc.dg/vect/slp-perm-3.c).
Patch by Anton Blanchard. Bootstrapped and tested on
powerpc64-unknown-linux-gnu with no new regressions. Ok for trunk?
Thanks,
Bill
2013-07-23 Bill Schmidt
Anton Blanchard
* config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Correct
selection of field for vector splat in little endian mode.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 201149)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -28460,9 +28460,10 @@ altivec_expand_vec_perm_const (rtx operands[4])
break;
if (i == 16)
{
+ int field = BYTES_BIG_ENDIAN ? elt / 2 : 7 - elt / 2;
x = gen_reg_rtx (V8HImode);
emit_insn (gen_altivec_vsplth (x, gen_lowpart (V8HImode, op0),
-GEN_INT (elt / 2)));
+GEN_INT (field)));
emit_move_insn (target, gen_lowpart (V16QImode, x));
return true;
}
@@ -28478,9 +28479,10 @@ altivec_expand_vec_perm_const (rtx operands[4])
break;
if (i == 16)
{
+ int field = BYTES_BIG_ENDIAN ? elt / 4 : 3 - elt / 4;
x = gen_reg_rtx (V4SImode);
emit_insn (gen_altivec_vspltw (x, gen_lowpart (V4SImode, op0),
-GEN_INT (elt / 4)));
+GEN_INT (field)));
emit_move_insn (target, gen_lowpart (V16QImode, x));
return true;
}
[patch, mips] Size savings for MIPS16 switch statements
While doing some space optimization work with mips16 I found that using a
larger case threshold value could shrink the code. I did testing on some
libraries like libpng and libjpeg as well as some test cases I wrote and
came up with 10 as the best value for space savings in mips16 mode. I did
some testing of mips32 code as well and found that this change did not
help with that code so I restricted the change to mips16 only.
Tested on mips-mti-elf target, OK for checkin?
Steve Ellcey
sell...@mips.com
2013-07-23 Steve Ellcey
* config/mips/mips.c (mips_case_values_threshold): New.
(TARGET_CASE_VALUES_THRESHOLD): Define.
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index a3735dc..fb39f7c 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -18613,6 +18613,19 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
x = gen_rtx_IOR (vmode, t0, t1);
emit_insn (gen_rtx_SET (VOIDmode, target, x));
}
+
+/* Implement `CASE_VALUES_THRESHOLD'. */
+/* Supply the default for --param case-values-threshold=0 */
+
+unsigned int
+mips_case_values_threshold (void)
+{
+ /* In MIPS16 mode using a larger case threshold generates smaller code. */
+ if (TARGET_MIPS16 && optimize_size)
+return 10;
+ else
+return default_case_values_threshold ();
+}
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
@@ -18844,6 +18857,9 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
#undef TARGET_VECTORIZE_VEC_PERM_CONST_OK
#define TARGET_VECTORIZE_VEC_PERM_CONST_OK mips_vectorize_vec_perm_const_ok
+#undef TARGET_CASE_VALUES_THRESHOLD
+#define TARGET_CASE_VALUES_THRESHOLD mips_case_values_threshold
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-mips.h"
Re: [PATCH, PowerPC] altivec_expand_vec_perm_const selects wrong field for splat in LE mode
On Tue, Jul 23, 2013 at 1:10 PM, Bill Schmidt wrote: > This patch fixes another small little-endian problem with vectors on > PowerPC. Element numbering is reversed when selecting a field for a > vector splat operation. Fixing this removes a regression from the test > suite when run in LE mode (gcc.dg/vect/slp-perm-3.c). > > Patch by Anton Blanchard. Bootstrapped and tested on > powerpc64-unknown-linux-gnu with no new regressions. Ok for trunk? > > Thanks, > Bill > > > 2013-07-23 Bill Schmidt > Anton Blanchard > > * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Correct > selection of field for vector splat in little endian mode. This patch is okay. Thanks, David
Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode
On Mon, Jul 22, 2013 at 9:09 PM, Bill Schmidt wrote: > OK, currently testing the following. OK if it passes? > > Index: gcc/config/rs6000/rs6000.c > === > --- gcc/config/rs6000/rs6000.c (revision 201149) > +++ gcc/config/rs6000/rs6000.c (working copy) > @@ -28518,6 +28518,11 @@ altivec_expand_vec_perm_const (rtx operands[4]) > enum machine_mode omode = insn_data[icode].operand[0].mode; > enum machine_mode imode = insn_data[icode].operand[1].mode; > > + /* For little-endian, the two input operands must be swapped > +(or swapped back) to ensure proper right-to-left numbering > +from 0 to 2N-1. */ > + if (!BYTES_BIG_ENDIAN) > +swapped = !swapped; > if (swapped) > x = op0, op0 = op1, op1 = x; > if (imode != V16QImode) I would prefer something like if (swapped ^ ! BYTES_BIG_ENDIAN) ... to make it more clear that the test only is affecting that specific swapping of arguments and not the other uses of "swapped" within the loop, i.e., not the earlier pattern comparison. Thanks, David
Re: [patch, mips] Size savings for MIPS16 switch statements
"Steve Ellcey " writes: > While doing some space optimization work with mips16 I found that using a > larger case threshold value could shrink the code. I did testing on some > libraries like libpng and libjpeg as well as some test cases I wrote and > came up with 10 as the best value for space savings in mips16 mode. I did > some testing of mips32 code as well and found that this change did not > help with that code so I restricted the change to mips16 only. Thanks for doing this. casesi certainly isn't small, so I can believe a larger threshold makes sense. OK with a minor change: > +/* Implement `CASE_VALUES_THRESHOLD'. */ > +/* Supply the default for --param case-values-threshold=0 */ > + > +unsigned int Please just use: /* Implement TARGET_CASE_VALUES_THRESHOLD. */ instead of these two comments. I was worried whether this would work for mips16 attributes, but it looks like the function is called on demand rather than cached, so there should be no problem there. Thanks, Richard
[C, C++] Implement -Wstatic-local
We sometimes deal with code bases which use static local variables to
cut down frame size, for compatibility with legacy targets. Obviously,
this is bad for thread safety. This new warning can be used to track
down such cases once you suspect they exist.
Bootstrapped and regression-tested on x86_64-redhat-linux-gnu. Okay for
trunk?
--
Florian Weimer / Red Hat Product Security Team
gcc/ChangeLog:
2013-07-23 Florian Weimer
* doc/invoke.texi (Warning Options): Document -Wstatic-local.
c-family/ChangeLog:
2013-07-23 Florian Weimer
* c.opt (Wstatic-local): Add option -Wstatic-local.
c/ChangeLog:
2013-07-23 Florian Weimer
* c-decl.c (pushdecl): Implement -Wstatic-local.
cp/ChangeLog:
2013-07-23 Florian Weimer
* decl.c (cp_finish_decl): Implement -Wstatic-local.
testsuite/ChangeLog:
2013-07-23 Florian Weimer
* c-c++-common/Wstatic-local.c: New.
* g++.dg/warn/Wstatic-local-1.C: New.
* g++.dg/warn/Wstatic-local-2.C: New.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 9690a08..7b9f3a2 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -745,6 +745,10 @@ Wmaybe-uninitialized
C ObjC C++ ObjC++ LangEnabledBy(C ObjC C++ ObjC++,Wall)
;
+Wstatic-local
+C ObjC C++ ObjC++ Warning Var(warn_static_local)
+Warn about static local variables
+
Wunknown-pragmas
C ObjC C++ ObjC++ Warning Var(warn_unknown_pragmas) LangEnabledBy(C ObjC C++ ObjC++,Wall, 1, 0)
Warn about unrecognized pragmas
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index f7ae648..9c718b5 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -2608,6 +2608,14 @@ pushdecl (tree x)
|| DECL_INITIAL (x) || !DECL_EXTERNAL (x)))
DECL_CONTEXT (x) = current_function_decl;
+ /* Optionally warn about non-const static variables declared inside
+ functions. */
+ if (current_function_decl && warn_static_local
+ && TREE_CODE (x) == VAR_DECL && TREE_STATIC (x)
+ && !TREE_READONLY (x))
+warning_at (DECL_SOURCE_LOCATION (x), OPT_Wstatic_local,
+ "local variable declared static, but not const");
+
/* Anonymous decls are just inserted in the scope. */
if (!name)
{
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 6fe4fed..1cd3726 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6387,6 +6387,14 @@ cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
non local class. Record the types it uses
so that we can decide later to emit debug info for them. */
record_types_used_by_current_var_decl (decl);
+
+ /* Optionally warn about static local variables which are
+ not const. */
+ if (warn_static_local && TREE_STATIC (decl)
+ && DECL_FUNCTION_SCOPE_P (decl)
+ && !TREE_READONLY (decl) && TREE_CODE (type) != REFERENCE_TYPE)
+ warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wstatic_local,
+ "local variable declared static, but not const");
}
else if (TREE_CODE (decl) == FIELD_DECL
&& TYPE_FOR_JAVA (type) && MAYBE_CLASS_TYPE_P (type))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3df4662..df94214 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4393,6 +4393,13 @@ programs.
Warn for variables that might be changed by @samp{longjmp} or
@samp{vfork}. This warning is also enabled by @option{-Wextra}.
+@item -Wstatic-local
+@opindex Wstatic-local
+@opindex Wno-static-local
+Warn for variables declared inside functions which are static, but not
+declared const. These local variables represent potential thread
+safety hazards.
+
@item -Wconditionally-supported @r{(C++ and Objective-C++ only)}
@opindex Wconditionally-supported
@opindex Wno-conditionally-supported
diff --git a/gcc/testsuite/c-c++-common/Wstatic-local.c b/gcc/testsuite/c-c++-common/Wstatic-local.c
new file mode 100644
index 000..a900569
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wstatic-local.c
@@ -0,0 +1,26 @@
+/* Test for -Wstatic-local */
+
+/* { dg-do compile } */
+/* { dg-options "-Wstatic-local" } */
+
+int a;
+static int b;
+const int c = 1;
+static const int d = 2;
+
+void
+g (void)
+{
+ static int v; /* { dg-warning "local variable declared static" } */
+ static const int v1 = 3;
+ static int *v2 = &v; /* { dg-warning "local variable declared static" } */
+ static const int *v3 = &v1; /* { dg-warning "local variable declared static" } */
+ static int *const v4 = &v;
+ static const char *w1 = "string"; /* { dg-warning "local variable declared static" } */
+ static const char *const w2 = "string";
+ static const char *x[] = {"string", 0}; /* { dg-warning "local variable declared static" } */
+ static const char *const x1[] = {"string", 0};
+
+ int z1;
+ const int z2 = 1;
+}
diff --git a/gcc/testsuite/g++.dg/warn/Wstatic-local-1.C b/gcc/testsuite/g++.dg/warn/Wstatic-local-1.C
new file mode 100644
index 000..bf6b965
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wstatic-local-1.C
@@ -0,0 +1,27 @@
+// Test -Wstatic-local. Also see c-c++-common/Wstatic-local.c.
+
+// { dg-do compile }
+// { dg-options "-Wstat
Re: [C, C++] Implement -Wstatic-local
On Tue, Jul 23, 2013 at 12:48 PM, Florian Weimer wrote: > We sometimes deal with code bases which use static local variables to cut > down frame size, for compatibility with legacy targets. Obviously, this is > bad for thread safety. This new warning can be used to track down such > cases once you suspect they exist. Hmm, since you mentioned bad for thread safety but then I see in your patch you don't check to see if the variable is a thread local variable. Maybe you should not mention thread safety at all here or change the code not to include TLS variables. Thanks, Andrew > > Bootstrapped and regression-tested on x86_64-redhat-linux-gnu. Okay for > trunk? > > -- > Florian Weimer / Red Hat Product Security Team >
Re: [C, C++] Implement -Wstatic-local
On 07/23/2013 09:51 PM, Andrew Pinski wrote: On Tue, Jul 23, 2013 at 12:48 PM, Florian Weimer wrote: We sometimes deal with code bases which use static local variables to cut down frame size, for compatibility with legacy targets. Obviously, this is bad for thread safety. This new warning can be used to track down such cases once you suspect they exist. Hmm, since you mentioned bad for thread safety but then I see in your patch you don't check to see if the variable is a thread local variable. Maybe you should not mention thread safety at all here or change the code not to include TLS variables. Good point. What about this instead? Warn for variables declared inside functions which are static, but not declared const. Such local variables can make functions not reentrant. -- Florian Weimer / Red Hat Product Security Team
Re: RFA: implement C11 _Generic
On Tue, 23 Jul 2013, Tom Tromey wrote:
> Joseph> + /* The association's type, or NULL_TREE for 'default'.. */
>
> It's trivial, but I happened to notice that this ".." should be just
> ".". The extra "." was in the original patch too.
Thanks, I've applied this patch to fix this typo.
Index: c-parser.c
===
--- c-parser.c (revision 201177)
+++ c-parser.c (working copy)
@@ -6238,7 +6238,7 @@
{
/* The location of the starting token of the type. */
location_t type_location;
- /* The association's type, or NULL_TREE for 'default'.. */
+ /* The association's type, or NULL_TREE for 'default'. */
tree type;
/* The association's expression. */
struct c_expr expression;
Index: ChangeLog
===
--- ChangeLog (revision 201177)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-07-23 Joseph Myers
+
+ * c-parser.c (struct c_generic_association): Fix typo.
+
2013-07-23 Tom Tromey
Joseph Myers
--
Joseph S. Myers
jos...@codesourcery.com
libgo patch committed: Fix cgo callbacks from non-Go threads
This patch to libgo fixes cgo callbacks from non-Go threads. Those
threads will not have an M or G structure. This basically adjusts the
support in the master Go library to work with gccgo.
There are also some cgo patches required. They are in
https://codereview.appspot.com/11406047/ and will be applied to the
master repository when approved.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
diff -r b916a03755cf libgo/runtime/go-cgo.c
--- a/libgo/runtime/go-cgo.c Mon Jul 22 21:40:43 2013 -0700
+++ b/libgo/runtime/go-cgo.c Tue Jul 23 13:19:03 2013 -0700
@@ -35,6 +35,9 @@
M* m;
G* g;
+ if (runtime_needextram && runtime_cas (&runtime_needextram, 1, 0))
+runtime_newextram ();
+
m = runtime_m ();
++m->ncgocall;
g = runtime_g ();
@@ -71,7 +74,24 @@
void
syscall_cgocallback ()
{
+ M *mp;
+
+ mp = runtime_m ();
+ if (mp == NULL)
+{
+ runtime_needm ();
+ mp = runtime_m ();
+ mp->dropextram = true;
+}
+
runtime_exitsyscall ();
+
+ mp = runtime_m ();
+ if (mp->needextram)
+{
+ mp->needextram = 0;
+ runtime_newextram ();
+}
}
/* Prepare to return to C/C++ code from a callback to Go code. */
@@ -79,7 +99,15 @@
void
syscall_cgocallbackdone ()
{
+ M *mp;
+
runtime_entersyscall ();
+ mp = runtime_m ();
+ if (mp->dropextram && runtime_g ()->ncgo == 0)
+{
+ mp->dropextram = false;
+ runtime_dropm ();
+}
}
/* Allocate memory and save it in a list visible to the Go garbage
diff -r b916a03755cf libgo/runtime/go-defer.c
--- a/libgo/runtime/go-defer.c Mon Jul 22 21:40:43 2013 -0700
+++ b/libgo/runtime/go-defer.c Tue Jul 23 13:19:03 2013 -0700
@@ -42,6 +42,7 @@
{
struct __go_defer_stack *d;
void (*pfn) (void *);
+ M *m;
d = g->defer;
pfn = d->__pfn;
@@ -51,7 +52,14 @@
(*pfn) (d->__arg);
g->defer = d->__next;
- __go_free (d);
+
+ /* This may be called by a cgo callback routine to defer the
+ call to syscall.CgocallBackDone, in which case we will not
+ have a memory context. Don't try to free anything in that
+ case--the GC will release it later. */
+ m = runtime_m ();
+ if (m != NULL && m->mcache != NULL)
+ __go_free (d);
/* Since we are executing a defer function here, we know we are
returning from the calling function. If the calling
diff -r b916a03755cf libgo/runtime/go-panic.c
--- a/libgo/runtime/go-panic.c Mon Jul 22 21:40:43 2013 -0700
+++ b/libgo/runtime/go-panic.c Tue Jul 23 13:19:03 2013 -0700
@@ -54,6 +54,7 @@
{
struct __go_defer_stack *d;
void (*pfn) (void *);
+ M *m;
d = g->defer;
if (d == NULL)
@@ -95,7 +96,14 @@
}
g->defer = d->__next;
- __go_free (d);
+
+ /* This may be called by a cgo callback routine to defer the
+ call to syscall.CgocallBackDone, in which case we will not
+ have a memory context. Don't try to free anything in that
+ case--the GC will release it later. */
+ m = runtime_m ();
+ if (m != NULL && m->mcache != NULL)
+ __go_free (d);
}
/* The panic was not recovered. */
diff -r b916a03755cf libgo/runtime/proc.c
--- a/libgo/runtime/proc.c Mon Jul 22 21:40:43 2013 -0700
+++ b/libgo/runtime/proc.c Tue Jul 23 13:19:03 2013 -0700
@@ -397,7 +397,8 @@
Sched runtime_sched;
int32 runtime_gomaxprocs;
bool runtime_singleproc;
-bool runtime_iscgo;
+bool runtime_iscgo = true;
+uint32 runtime_needextram = 1;
uint32 runtime_gcwaiting;
M runtime_m0;
G runtime_g0; // idle goroutine for m0
@@ -901,8 +902,8 @@
#ifdef USING_SPLIT_STACK
{
- int dont_block_signals = 0;
- __splitstack_block_signals(&dont_block_signals, nil);
+ int dont_block_signals = 0;
+ __splitstack_block_signals(&dont_block_signals, nil);
}
#endif
@@ -944,7 +945,7 @@
// Allocate a new m unassociated with any thread.
// Can use p for allocation context if needed.
M*
-runtime_allocm(P *p)
+runtime_allocm(P *p, int32 stacksize, byte** ret_g0_stack, size_t* ret_g0_stacksize)
{
M *mp;
@@ -961,7 +962,7 @@
mp = runtime_mal(sizeof *mp);
mcommoninit(mp);
- mp->g0 = runtime_malg(-1, nil, nil);
+ mp->g0 = runtime_malg(stacksize, ret_g0_stack, ret_g0_stacksize);
if(p == m->p)
releasep();
@@ -1006,6 +1007,9 @@
//
// When the callback is done with the m, it calls dropm to
// put the m back on the list.
+//
+// Unlike the gc toolchain, we start running on curg, since we are
+// just going to return and let the caller continue.
void
runtime_needm(void)
{
@@ -1027,18 +1031,40 @@
mp->needextram = mp->schedlink == nil;
unlockextra(mp->schedlink);
- // Install m and g (= m->g0) and set the stack bounds
- // to match the current stack. We don't actually know
- // how big the stack is, like we don't know how big any
- // scheduling stack is, but we assume there's at least 32 kB,
- // which is more than enough for us.
- runtime_setmg(mp, mp->g0);
+ // Install m and g (= m->curg).
Re: Go patch committed: Update libgo to 1.1.1
On Tue, Jul 23, 2013 at 6:50 AM, Uros Bizjak wrote:
>>
>> Another problem was triggered on CentOS 5.9, where compile fails with:
>>
>> ../../../gcc-svn/trunk/libgo/runtime/netpoll_epoll.c: In function
>> ‘runtime_epollcreate1’:
>> ../../../gcc-svn/trunk/libgo/runtime/netpoll_epoll.c:41:2: error:
>> implicit declaration of function ‘epoll_create1’
>> [-Werror=implicit-function-declaration]
>> r = epoll_create1(flags);
>> ^
>> cc1: all warnings being treated as errors
>> gmake[4]: *** [netpoll_epoll.lo] Error 1
>> gmake[4]: *** Waiting for unfinished jobs
>>
>> CentOS has glibc 2.5 and epoll_create1 is not supported.
>
> Attached patch fixes this problem by providing prototype, missing from
> sys/poll.h in netpoll_epoll.c.
>
> Patch was tested on x86_64-pc-linux-gnu {,-m32} on CentOS 5.9 and Fedora 19.
Thanks! Committed to mainline and 4.8 branch.
Ian
RE: [ping] Re: [patch 0/4] reimplement -fstrict-volatile-bitfields, v3
On Tue, 23 Jul 2013, Bernd Edlinger wrote: > H-P: I hope you can approve my little patch for trunk now, > although it turned out to be less trivial than I'd have expected. Sorry, I'm not an approver. (People who are not approvers are welcome to review any gcc patch where they might say something useful, whether unique or according to the gcc line, in order to ease the burden of those with actual approval burdens^wrights. In this case I *did* ask for the warning, so all the reason for me to do a little review.) Thanks! Looks reasonable (to my tree-ignorant eyes) modulo a few nits: Please put the "as it would" parts of the changelog entries as comments in the code instead. (ChangeLog says "what", not "why".) I'd also tweak the head comment of warn_portable_volatility_p (like the documentation change) to not refer to -fstrict-volatile-bitfields as the sole intended cause of concern; it should instead say something like "at present this function only covers -fstrict-volatile-bitfields" in order to open up for future amendments. Please also change the name to check_portable_volatility instead of warn_portable_volatility_p; the "_p" suffix is canonically used for boolean predicates. (You might have copied the wrong use of _p from somewhere else in the gcc code, but that's also in error.) > Of course it is dependent on Sandra's patch part 1 and part 2, > which must be applied first. brgds, H-P
Re: Go patch committed: Update libgo to 1.1.1
On Thu, Jul 18, 2013 at 6:59 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> I have committed a large patch to update libgo to the library that was
>> part of the Go 1.1.1 release. As usual, I'm not including the entire
>> patch in this e-mail message, because it is too large. I'm only
>> including the changes to the files that are partially gccgo-specific.
>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
>> Committed to mainline and 4.8 branch.
>
> This broke the Solaris build:
>
> /vol/gcc/src/hg/trunk/local/libgo/go/net/sock_solaris.go:20:1: error:
> redefinition of 'listenerSockaddr'
> func listenerSockaddr(s, f int, la syscall.Sockaddr, toAddr
> func(syscall.Sockaddr) Addr) (syscall.Sockaddr, error) {
> ^
> /vol/gcc/src/hg/trunk/local/libgo/go/net/sock_unix.go:11:1: note: previous
> definition of 'listenerSockaddr' was here
> func listenerSockaddr(s, f int, la syscall.Sockaddr, toAddr
> func(syscall.Sockaddr) Addr) (syscall.Sockaddr, error) {
> ^
> make[2]: *** [net.lo] Error 1
>
> Seems enought to just remove the sock_solaris.go definition.
I agree. I committed this patch to mainline and 4.8 branch. Thanks
for reporting the problem.
Ian
foo.patch
Description: Binary data
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 07/14/13 21:37, David Holsgrove wrote: Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Saturday, 13 July 2013 9:33 am To: David Holsgrove Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail; Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the "%l" operand was not a label. This is the first occasion when this routine is called. I had sent a separate patch which should have been applied prior to this one which extended the jump insn to accommodate branching without the "%l" print operand, but I've since reworked our thunk support to avoid needing this second patch. Please find attached updated patch, and new Changelog entry; 2013-07-15 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK I'll post updated patches on the other threads out for review now. thanks, David Committed revision 201185. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add -fstack-usage support
On 07/22/13 22:50, David Holsgrove wrote: Hi Eric / Chung-Ju, On 21 July 2013 01:33, Chung-Ju Wu wrote: On 7/20/13 4:14 PM, Eric Botcazou wrote: 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c (microblaze_expand_prologue): Add check for flag_stack_usage to handle -fstack-usage support Signed-off-by: David Holsgrove Patch remains the same, please apply when ready. The patch is incorrect, please adjust it to match the other architectures. Hi, David, Specifically speaking, what Eric meant is to check flag_stack_usage_info rather than flag_stack_usage due to the changes after gcc-4.7. Ah, thanks for the catch - patch had been sitting in my tree for quite a while, hadn't realised the variable name had changed on trunk. Patch attached which adjusts microblaze's usage to align with other archs. Committed revision 201186. Please send an updated ChangeLog when it is different from the original. ChangeLog: 2013-07-23 David Holsgrove * config/microblaze/microblaze.c (microblaze_expand_prologue): Rename flag_stack_usage to flag_stack_usage_info. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Go patch committed: Update libgo to 1.1.1
On Thu, Jul 18, 2013 at 6:59 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> I have committed a large patch to update libgo to the library that was
>> part of the Go 1.1.1 release. As usual, I'm not including the entire
>> patch in this e-mail message, because it is too large. I'm only
>> including the changes to the files that are partially gccgo-specific.
>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
>> Committed to mainline and 4.8 branch.
>
> This broke the Solaris build:
>
> /vol/gcc/src/hg/trunk/local/libgo/go/log/syslog/syslog_libc.go:18:25: error:
> use of undefined type 'serverConn'
> func unixSyslog() (conn serverConn, err error) {
> ^
> make[6]: *** [log/syslog.lo] Error 1
>
> Didn't make much progress on this one.
The interface I put in a while back for Solaris support got taken out
from the master library, and I missed it. This patch restores it.
Committed to mainline and 4.8 branch. I've also sent a patch to the
master library to restore the interface.
Ian
foo.patch
Description: Binary data
Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
Hi,
On 07/23/2013 05:27 PM, Jason Merrill wrote:
Hmm, I suppose this could still end up doing unnecessary completions
if both types are incomplete. What happens if X is also incomplete?
Indeed, it fails and shouldn't. I thought I had tested this case but
didn't. Thus I extended a bit the testcase.
The version that returns false if either is incomplete would give the
wrong answer if the types are the same.
I think a better way would be to use COMPARE_STRICT if either type is
incomplete.
I see. Just don't bother looking for inheritance in all such cases, can
only cause troubles. Thus shall we implement this like in the below? It
passes testing.
Thanks!
Paolo.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 201148)
+++ cp/cp-tree.h(working copy)
@@ -6022,7 +6022,7 @@ extern tree convert_for_initialization(tree,
tre
extern int comp_ptr_ttypes (tree, tree);
extern bool comp_ptr_ttypes_const (tree, tree);
extern bool error_type_p (const_tree);
-extern int ptr_reasonably_similar (const_tree, const_tree);
+extern bool ptr_reasonably_similar (const_tree, const_tree);
extern tree build_ptrmemfunc (tree, tree, int, bool,
tsubst_flags_t);
extern int cp_type_quals (const_tree);
Index: cp/typeck.c
===
--- cp/typeck.c (revision 201148)
+++ cp/typeck.c (working copy)
@@ -8599,10 +8599,10 @@ error_type_p (const_tree type)
}
}
-/* Returns 1 if to and from are (possibly multi-level) pointers to the same
+/* Returns true if to and from are (possibly multi-level) pointers to the same
type or inheritance-related types, regardless of cv-quals. */
-int
+bool
ptr_reasonably_similar (const_tree to, const_tree from)
{
for (; ; to = TREE_TYPE (to), from = TREE_TYPE (from))
@@ -8614,7 +8614,7 @@ ptr_reasonably_similar (const_tree to, const_tree
return !error_type_p (to);
if (TREE_CODE (to) != TREE_CODE (from))
- return 0;
+ return false;
if (TREE_CODE (from) == OFFSET_TYPE
&& comptypes (TYPE_OFFSET_BASETYPE (to),
@@ -8624,19 +8624,24 @@ ptr_reasonably_similar (const_tree to, const_tree
if (TREE_CODE (to) == VECTOR_TYPE
&& vector_types_convertible_p (to, from, false))
- return 1;
+ return true;
if (TREE_CODE (to) == INTEGER_TYPE
&& TYPE_PRECISION (to) == TYPE_PRECISION (from))
- return 1;
+ return true;
if (TREE_CODE (to) == FUNCTION_TYPE)
return !error_type_p (to) && !error_type_p (from);
if (!TYPE_PTR_P (to))
- return comptypes
- (TYPE_MAIN_VARIANT (to), TYPE_MAIN_VARIANT (from),
- COMPARE_BASE | COMPARE_DERIVED);
+ {
+ /* When either type is incomplete avoid DERIVED_FROM_P,
+which may call complete_type (c++/57942). */
+ bool b = !COMPLETE_TYPE_P (to) || !COMPLETE_TYPE_P (from);
+ return comptypes
+ (TYPE_MAIN_VARIANT (to), TYPE_MAIN_VARIANT (from),
+b ? COMPARE_STRICT : COMPARE_BASE | COMPARE_DERIVED);
+ }
}
}
Index: testsuite/g++.dg/inherit/pr57942.C
===
--- testsuite/g++.dg/inherit/pr57942.C (revision 0)
+++ testsuite/g++.dg/inherit/pr57942.C (working copy)
@@ -0,0 +1,9 @@
+// PR c++/57942
+
+template struct S { typename T::error type; };
+struct X {};
+void f(S*);
+void f(...);
+void g() { f((X*)0); }
+struct Y;
+void h() { f((Y*)0); }
[Patch, PR 57800] Waste work in gfc_match_call()
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800
Bootstrap and regression-tested on x86_64-linux.
In method "gfc_match_call()" in gcc/fortran/match.c, the loop on line
4189 should break immediately after "i" is set to 1.
2013-07-22 Chang
* match.c (gfc_match_call): Exit loop after setting i.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 201034)
+++ gcc/fortran/match.c (working copy)
@@ -4188,7 +4188,10 @@
i = 0;
for (a = arglist; a; a = a->next)
if (a->expr == NULL)
- i = 1;
+ {
+ i = 1;
+ break;
+ }
if (i)
{
-ChangIndex: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 201034)
+++ gcc/fortran/match.c (working copy)
@@ -4188,7 +4188,10 @@
i = 0;
for (a = arglist; a; a = a->next)
if (a->expr == NULL)
- i = 1;
+ {
+ i = 1;
+ break;
+ }
if (i)
{
[Patch, PR 57801] Waste work in resolve_variable()
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801
Bootstrap and regression-tested on x86_64-linux.
In method "resolve_variable()" in gcc/fortran/resolve.c, the loop on
line 4908 should break immediately after "seen" is set to "true".
2013-07-23 Chang
* resolve.c (resolve_variable): Exit loop after setting seen.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 201034)
+++ gcc/fortran/resolve.c (working copy)
@@ -4908,7 +4908,10 @@
for (formal = entry->sym->formal; formal; formal = formal->next)
{
if (formal->sym && sym->name == formal->sym->name)
- seen = true;
+ {
+ seen = true;
+ break;
+ }
}
/* If it has not been seen as a dummy, this is an error. */
-ChangIndex: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 201034)
+++ gcc/fortran/resolve.c (working copy)
@@ -4908,7 +4908,10 @@
for (formal = entry->sym->formal; formal; formal = formal->next)
{
if (formal->sym && sym->name == formal->sym->name)
- seen = true;
+ {
+ seen = true;
+ break;
+ }
}
/* If it has not been seen as a dummy, this is an error. */
[Patch, PR 57791] Waste work in gfc_check_pointer_assign()
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791
Bootstrap and regression-tested on x86_64-linux.
In method "gfc_check_pointer_assign()" in expr.c, the loop on line
3763 should break immediately after "warn" is set to "true".
2013-07-23 Chang
* expr.c (gfc_check_pointer_assign): Exit loop after setting warn.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 201034)
+++ gcc/fortran/expr.c (working copy)
@@ -3764,7 +3764,10 @@
ns && ns->proc_name && ns->proc_name->attr.flavor != FL_PROCEDURE;
ns = ns->parent)
if (ns->parent == lvalue->symtree->n.sym->ns)
- warn = true;
+ {
+ warn = true;
+ break;
+ }
if (warn)
gfc_warning ("Pointer at %L in pointer assignment might outlive the "
-ChangIndex: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 201034)
+++ gcc/fortran/expr.c (working copy)
@@ -3764,7 +3764,10 @@
ns && ns->proc_name && ns->proc_name->attr.flavor != FL_PROCEDURE;
ns = ns->parent)
if (ns->parent == lvalue->symtree->n.sym->ns)
- warn = true;
+ {
+ warn = true;
+ break;
+ }
if (warn)
gfc_warning ("Pointer at %L in pointer assignment might outlive the "
[Patch, PR 57802] Wasted work in set_loop_bounds()
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802
Bootstrap and regression-tested on x86_64-linux.
In method "set_loop_bounds()" in gcc/fortran/trans-array.c, the loop
on line 4456 should break immediately after "nonoptional_arr" is set
to "true".
2013-07-23 Chang
* trans-array.c (set_loop_bounds): Exit loop after
setting nonoptional_arr.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 201034)
+++ gcc/fortran/trans-array.c (working copy)
@@ -4456,7 +4456,10 @@
for (ss = loop->ss; ss != gfc_ss_terminator; ss = ss->loop_chain)
if (ss->info->type != GFC_SS_SCALAR && ss->info->type != GFC_SS_TEMP
&& ss->info->type != GFC_SS_REFERENCE && !ss->info->can_be_null_ref)
- nonoptional_arr = true;
+ {
+ nonoptional_arr = true;
+ break;
+ }
/* We use one SS term, and use that to determine the bounds of the
loop for this dimension. We try to pick the simplest term. */
-ChangIndex: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 201034)
+++ gcc/fortran/trans-array.c (working copy)
@@ -4456,7 +4456,10 @@
for (ss = loop->ss; ss != gfc_ss_terminator; ss = ss->loop_chain)
if (ss->info->type != GFC_SS_SCALAR && ss->info->type != GFC_SS_TEMP
&& ss->info->type != GFC_SS_REFERENCE && !ss->info->can_be_null_ref)
- nonoptional_arr = true;
+ {
+ nonoptional_arr = true;
+ break;
+ }
/* We use one SS term, and use that to determine the bounds of the
loop for this dimension. We try to pick the simplest term. */
[Patch, PR 57804] Wasted work in gfc_trans_transfer()
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804
Bootstrap and regression-tested on x86_64-linux.
In method "gfc_trans_transfer()" in gcc/fortran/trans-io.c, the loop
on line 2261 should break immediately after "seen_vector" is set to
"true".
2013-07-23 Chang
* trans-io.c (gfc_trans_transfer): Exit loop after
setting seen_vector.
Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c (revision 201034)
+++ gcc/fortran/trans-io.c (working copy)
@@ -2260,7 +2260,10 @@
{
for (n = 0; n < ref->u.ar.dimen; n++)
if (ref->u.ar.dimen_type[n] == DIMEN_VECTOR)
- seen_vector = true;
+ {
+ seen_vector = true;
+ break;
+ }
}
if (seen_vector && last_dt == READ)
-ChangIndex: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c (revision 201034)
+++ gcc/fortran/trans-io.c (working copy)
@@ -2260,7 +2260,10 @@
{
for (n = 0; n < ref->u.ar.dimen; n++)
if (ref->u.ar.dimen_type[n] == DIMEN_VECTOR)
- seen_vector = true;
+ {
+ seen_vector = true;
+ break;
+ }
}
if (seen_vector && last_dt == READ)
Re: Go patch committed: Update libgo to 1.1.1
On Mon, Jul 22, 2013 at 6:38 AM, Uros Bizjak wrote: > >> I have committed a large patch to update libgo to the library that was >> part of the Go 1.1.1 release. As usual, I'm not including the entire >> patch in this e-mail message, because it is too large. I'm only >> including the changes to the files that are partially gccgo-specific. >> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. >> Committed to mainline and 4.8 branch. > > I have hit following build failure on non-USING_SPLIT_STACK target > (alpha-linux-gnu): Thanks. Fixed like so. Committed to mainline and 4.8 branch. >>> >>> Thanks, with your patch, I was able to compile libgo without problems. >>> The testsuite run exposes a timeout in net/http, I am looking into it. > > I have also managed to trigger the timeout on x86_64-pc-linux-gnu. > > The test was re-run with GOTESTFLAGS=--keep. When running the > resulting a.out with "strace -f -o strace-x86_64 ./a.out" from the > saved test directory, the test behaved in the same way as on alpha - > it hever finished. I have attached the resulting trace (the test was > killed with ctrl-c after some time). Thanks. The problematic test is TestLinuxSendfile in libgo/net/http/fs_test.go. That test binary invokes itself using strace. In the trace here, that strace fails: 8511 ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted) 8511 write(2, "strace: test_ptrace_setoptions_f"..., 96) = 96 The strace is supposed to start up a little server, and the test binary tries to connect to that server. Since the server hasn't started, the test times out. The strace invocation is strace -f -q -e trace=sendfile,sendfile64 ./a.out -test.run=TestLinuxSendfileChild Any idea why that would fail? The Alpha stack trace you send also indicates a failure in this test. It could be for the same reason; hard to say. The Alpha strace output you send doesn't tell me much, since it wasn't done with -f. Ian
Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode
On Tue, 2013-07-23 at 14:02 -0400, David Edelsohn wrote: > On Mon, Jul 22, 2013 at 9:09 PM, Bill Schmidt > wrote: > > > OK, currently testing the following. OK if it passes? > > > > Index: gcc/config/rs6000/rs6000.c > > === > > --- gcc/config/rs6000/rs6000.c (revision 201149) > > +++ gcc/config/rs6000/rs6000.c (working copy) > > @@ -28518,6 +28518,11 @@ altivec_expand_vec_perm_const (rtx operands[4]) > > enum machine_mode omode = insn_data[icode].operand[0].mode; > > enum machine_mode imode = insn_data[icode].operand[1].mode; > > > > + /* For little-endian, the two input operands must be swapped > > +(or swapped back) to ensure proper right-to-left numbering > > +from 0 to 2N-1. */ > > + if (!BYTES_BIG_ENDIAN) > > +swapped = !swapped; > > if (swapped) > > x = op0, op0 = op1, op1 = x; > > if (imode != V16QImode) > > I would prefer something like > > if (swapped ^ ! BYTES_BIG_ENDIAN) ... > > to make it more clear that the test only is affecting that specific > swapping of arguments and not the other uses of "swapped" within the > loop, i.e., not the earlier pattern comparison. OK, makes sense. I tested with that variant and everything checks out. I went ahead and committed the fix in the form you suggested. Thanks, Bill > > Thanks, David >
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 24 July 2013 07:10, Michael Eager wrote: > On 07/14/13 21:37, David Holsgrove wrote: >> >> Hi Michael, >> >>> -Original Message- >>> From: Michael Eager [mailto:ea...@eagerm.com] >>> Sent: Saturday, 13 July 2013 9:33 am >>> To: David Holsgrove >>> Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod >>> Kathail; >>> Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui >>> Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to >>> support varargs thunk >>> >>> On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and >>> >>> TARGET_ASM_CAN_OUTPUT_MI_THUNK >>> >>> Sorry it has taken so long to review this patch. >>> >>> The gcc microblaze-xilinx-elf build with this patch fails here: >>> >>> +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl >>> ATTRIBUTE_UNUSED, >>> + HOST_WIDE_INT delta, HOST_WIDE_INT >>> vcall_offset, >>> + tree function) >>> ... >>> + emit_insn (gen_jump (funexp)); >>> >>> (actually, in output_operand() downstream from this statement) while >>> compiling >>> c++98/strstream.cc, with an error that the "%l" operand was not a label. >>> >>> This is the first occasion when this routine is called. >>> >> >> I had sent a separate patch which should have been applied prior to this >> one which >> extended the jump insn to accommodate branching without the "%l" print >> operand, >> but I've since reworked our thunk support to avoid needing this second >> patch. >> >> Please find attached updated patch, and new Changelog entry; >> >> 2013-07-15 David Holsgrove >> >> * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk >> and define TARGET_ASM_OUTPUT_MI_THUNK and >> TARGET_ASM_CAN_OUTPUT_MI_THUNK >> >> I'll post updated patches on the other threads out for review now. >> >> thanks, >> David > > > > Committed revision 201185. > Thanks Michael. I think the content of your commit doesnt line up with this Changelog entry or mail though, http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c4fcbf4cd03c11aa1bc707b00dd95ba52f963b39 It looks like the atomic builtin patch which was posted as this mail; http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00551.html thanks, David > > -- > Michael Eagerea...@eagercon.com > 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add atomic builtin implementation
On 07/14/13 21:43, David Holsgrove wrote: Hi Michael, On 21 March 2013 03:00, Richard Henderson wrote: On 03/18/2013 05:48 AM, David Holsgrove wrote: * gcc/config/microblaze/sync.md: New file. * gcc/config/microblaze/microblaze.md: Add UNSPEC_SYNC_CAS, UNSPEC_SYNC_XCHG and include sync.md. * gcc/config/microblaze/microblaze.c: Add print_operand 'y'. * gcc/config/microblaze/constraints.md: Add memory_contraint 'Q' which is a single register. Do not add new __sync implementations. Use the __atomic builtins. r~ Please find attached reworked patch using __atomic builtin. Changelog entry would be; 2013-07-15 David Holsgrove * gcc/config/microblaze/sync.md: New file. * gcc/config/microblaze/microblaze.md: Include sync.md * gcc/config/microblaze/microblaze.c: Add print_operand 'y'. * gcc/config/microblaze/constraints.md: Add memory_contraint 'Q' which is a single register. thanks, David Committed revision 201185. ChangeLog corrected: revision 201200 -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 07/23/13 16:23, David Holsgrove wrote: On 24 July 2013 07:10, Michael Eager wrote: On 07/14/13 21:37, David Holsgrove wrote: Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Saturday, 13 July 2013 9:33 am To: David Holsgrove Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail; Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the "%l" operand was not a label. This is the first occasion when this routine is called. I had sent a separate patch which should have been applied prior to this one which extended the jump insn to accommodate branching without the "%l" print operand, but I've since reworked our thunk support to avoid needing this second patch. Please find attached updated patch, and new Changelog entry; 2013-07-15 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK I'll post updated patches on the other threads out for review now. thanks, David Committed revision 201185. Thanks Michael. I think the content of your commit doesnt line up with this Changelog entry or mail though, http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c4fcbf4cd03c11aa1bc707b00dd95ba52f963b39 It looks like the atomic builtin patch which was posted as this mail; http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00551.html Yes, I picked up the wrong ChangeLog and email. I fixed the ChangeLog. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 24 July 2013 10:22, Michael Eager wrote: > On 07/23/13 16:23, David Holsgrove wrote: >> >> On 24 July 2013 07:10, Michael Eager wrote: >>> >> Thanks Michael. >> >> I think the content of your commit doesnt line up with this Changelog >> entry or mail though, >> >> http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c4fcbf4cd03c11aa1bc707b00dd95ba52f963b39 >> >> It looks like the atomic builtin patch which was posted as this mail; >> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00551.html > > > Yes, I picked up the wrong ChangeLog and email. I fixed the ChangeLog. > No worries, thanks Michael. regards, David > > -- > Michael Eagerea...@eagercon.com > 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [C, C++] Implement -Wstatic-local
On Tue, Jul 23, 2013 at 3:02 PM, Florian Weimer wrote: > On 07/23/2013 09:51 PM, Andrew Pinski wrote: >> >> On Tue, Jul 23, 2013 at 12:48 PM, Florian Weimer >> wrote: >>> >>> We sometimes deal with code bases which use static local variables to cut >>> down frame size, for compatibility with legacy targets. Obviously, this >>> is >>> bad for thread safety. This new warning can be used to track down such >>> cases once you suspect they exist. >> >> >> Hmm, since you mentioned bad for thread safety but then I see in your >> patch you don't check to see if the variable is a thread local >> variable. Maybe you should not mention thread safety at all here or >> change the code not to include TLS variables. > > > Good point. What about this instead? > > Warn for variables declared inside functions which are static, but not > declared const. Such local variables can make functions not reentrant. Do you envision this to be useful for C++ too? There are many bits here. 'const' in C++ does not necessary prevent race conditions with the variable's type has to run non-atomic constructors, or if the object has data members declared mutable, etc. It used to be idiomatic in C++ to use local statics in order to enforce initialization of "morally global" objects -- the function returns a pointer or reference to the object. I think the C++ ABI mandates that the implementation adds implicit locks to enforce orderly initialization -- Gaby
[PATCH, ARM/Thumb1] Adjust rtx cost to prevent expanding MULT into shift/add instructions
Hi there,
This patch intends to update thumb1_size_rtx_costs function to correctly
handle those RTXs defined by RTL expansion pass. Thus the GIMPLE
multiplication will be expanded to single mul instruction instead of a bunch
of shift/add/sub instructions which are in fact more expensive.
Tested with GCC regression test on QEMU ARM926, no regression. Is it OK to
trunk and 4.8 branch?
BR,
Terry
gcc/ChangeLog:
2013-07-24 Terry Guo
* config/arm/arm.c (thumb1_size_rtx_costs): Assign proper cost for
shift_add/shift_sub0/shift_sub1 RTXs.
gcc/testsuite/ChangeLog:
2013-07-24 Terry Guo
* gcc.target/arm/thumb1-Os-mult.c: New test case.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index e6fd420..5c07832 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7925,6 +7925,15 @@ thumb1_size_rtx_costs (rtx x, enum rtx_code code, enum
rtx_code outer)
case PLUS:
case MINUS:
+ /* Thumb-1 needs two instructions to fulfill shiftadd/shiftsub0/shiftsub1
+defined by RTL expansion, especially for the expansion of
+multiplication. */
+ if ((GET_CODE (XEXP (x, 0)) == MULT
+ && power_of_two_operand (XEXP (XEXP (x,0),1), SImode))
+ || (GET_CODE (XEXP (x, 1)) == MULT
+ && power_of_two_operand (XEXP (XEXP (x, 1), 1), SImode)))
+ return COSTS_N_INSNS (2);
+ /* On purpose fall through for normal RTX. */
case COMPARE:
case NEG:
case NOT:
diff --git a/gcc/testsuite/gcc.target/arm/thumb1-Os-mult.c
b/gcc/testsuite/gcc.target/arm/thumb1-Os-mult.c
new file mode 100644
index 000..31b8bd6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/thumb1-Os-mult.c
@@ -0,0 +1,12 @@
+/* { dg-require-effective-target arm_thumb1_ok } */
+/* { dg-do compile } */
+/* { dg-options "-Os" } */
+/* { dg-skip-if "" { ! { arm_thumb1 } } } */
+
+int
+mymul3 (int x)
+{
+ return x * 0x555;
+}
+
+/* { dg-final { scan-assembler "mul\[\\t \]*r.,\[\\t \]*r." } } */
[PATCH, PowerPC] Fix unaligned Altivec load/stores in LE mode
In order to use vperm for aligning loads and stores in little endian
mode, we need to reverse the order of the input operands and use lvsl
instead of lvsr. This corrects 32 regressions in the test suite when
run in LE mode.
Bootstrapped and tested on powerpc64-unknown-linux-gnu in BE mode with
no new regressions. Is this ok for trunk?
Patch by Anton Blanchard.
Thanks,
Bill
2013-07-23 Bill Schmidt
Anton Blanchard
* vector.md (vec_realign_load_): Reorder input operands to
vperm for little endian.
* rs6000.c (rs6000_expand_builtin): Use lvsr instead of lvsl to
create the control mask for a vperm for little endian.
Index: gcc/config/rs6000/vector.md
===
--- gcc/config/rs6000/vector.md (revision 201194)
+++ gcc/config/rs6000/vector.md (working copy)
@@ -936,8 +936,12 @@
(match_operand:V16QI 3 "vlogical_operand" "")]
"VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)"
{
- emit_insn (gen_altivec_vperm_ (operands[0], operands[1], operands[2],
- operands[3]));
+ if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vperm_ (operands[0], operands[1],
+operands[2], operands[3]));
+ else
+emit_insn (gen_altivec_vperm_ (operands[0], operands[2],
+operands[1], operands[3]));
DONE;
})
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 201195)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -12351,7 +12351,8 @@ rs6000_expand_builtin (tree exp, rtx target, rtx s
case ALTIVEC_BUILTIN_MASK_FOR_LOAD:
case ALTIVEC_BUILTIN_MASK_FOR_STORE:
{
- int icode = (int) CODE_FOR_altivec_lvsr;
+ int icode = (BYTES_BIG_ENDIAN ? (int) CODE_FOR_altivec_lvsr
+: (int) CODE_FOR_altivec_lvsl);
enum machine_mode tmode = insn_data[icode].operand[0].mode;
enum machine_mode mode = insn_data[icode].operand[1].mode;
tree arg;
Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?
OK. Jason
