[PATCH, SMS 3/3] Skip DEBUG_INSN in loop-doloop.
Hello, (sorry for multiple copies of this email) This small fix was inserted to skip DEBUG_INSNs while recognizing doloop pattern in loop-doloop.c file. It's a fix for the already approved do-loop patch (not in mainline yet, http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop.c The patch was tested together with the rest of the patches in this series and on top of the patch to support do-loop for ARM (not yet in mainline, but approved http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html). On ppc64-redhat-linux regtest as well as bootstrap with SMS flags enabling SMS also on loops with stage count 1. Regtested on SPU. On arm-linux-gnueabi regtseted on c,c++. Bootstrap c language with SMS flags enabling SMS also on loops with stage count 1. OK for mainline? Thanks, Revital Changelog: * loop-doloop.c (doloop_condition_get): Use prev_nondebug_insn instead of PREV_INSN. --- loop-doloop.c 2011-05-07 16:08:27.0 +0300 +++ loop-doloop_new.c 2011-05-07 16:07:48.0 +0300 @@ -151,7 +151,7 @@ doloop_condition_get (rtx doloop_pat) inc = XVECEXP (PATTERN (prev_insn), 0, 1); } else -inc = PATTERN (PREV_INSN (doloop_pat)); +inc = PATTERN (prev_insn); /* We expect the condition to be of the form (reg != 0) */ cond = XEXP (SET_SRC (cmp), 0); if (GET_CODE (cond) != NE || XEXP (cond, 1) != const0_rtx)
[PATCH, SMS 3/3] Skip DEBUG_INSN in loop-doloop.
Hello, (sorry for multiple copies of this email) This small fix was inserted to skip DEBUG_INSNs while recognizing doloop pattern in loop-doloop.c file. It's a fix for the already approved do-loop patch (not in mainline yet, http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop.c The patch was tested together with the rest of the patches in this series and on top of the patch to support do-loop for ARM (not yet in mainline, but approved http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html). On ppc64-redhat-linux regtest as well as bootstrap with SMS flags enabling SMS also on loops with stage count 1. Regtested on SPU. On arm-linux-gnueabi regtseted on c,c++. Bootstrap c language with SMS flags enabling SMS also on loops with stage count 1. OK for mainline? Thanks, Revital Changelog: * loop-doloop.c (doloop_condition_get): Use prev_nondebug_insn instead of PREV_INSN. --- loop-doloop.c 2011-05-07 16:08:27.0 +0300 +++ loop-doloop_new.c 2011-05-07 16:07:48.0 +0300 @@ -151,7 +151,7 @@ doloop_condition_get (rtx doloop_pat) inc = XVECEXP (PATTERN (prev_insn), 0, 1); } else -inc = PATTERN (PREV_INSN (doloop_pat)); +inc = PATTERN (prev_insn); /* We expect the condition to be of the form (reg != 0) */ cond = XEXP (SET_SRC (cmp), 0); if (GET_CODE (cond) != NE || XEXP (cond, 1) != const0_rtx)
[PATCH, SMS 3/3] Skip DEBUG_INSN in loop-doloop.
Hello, (sorry for multiple copies of this email) This small fix was inserted to skip DEBUG_INSNs while recognizing doloop pattern in loop-doloop.c file. It's a fix for the already approved do-loop patch (not in mainline yet, http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop.c The patch was tested together with the rest of the patches in this series and on top of the patch to support do-loop for ARM (not yet in mainline, but approved http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html). On ppc64-redhat-linux regtest as well as bootstrap with SMS flags enabling SMS also on loops with stage count 1. Regtested on SPU. On arm-linux-gnueabi regtseted on c,c++. Bootstrap c language with SMS flags enabling SMS also on loops with stage count 1. OK for mainline? Thanks, Revital Changelog: * loop-doloop.c (doloop_condition_get): Use prev_nondebug_insn instead of PREV_INSN. --- loop-doloop.c 2011-05-07 16:08:27.0 +0300 +++ loop-doloop_new.c 2011-05-07 16:07:48.0 +0300 @@ -151,7 +151,7 @@ doloop_condition_get (rtx doloop_pat) inc = XVECEXP (PATTERN (prev_insn), 0, 1); } else -inc = PATTERN (PREV_INSN (doloop_pat)); +inc = PATTERN (prev_insn); /* We expect the condition to be of the form (reg != 0) */ cond = XEXP (SET_SRC (cmp), 0); if (GET_CODE (cond) != NE || XEXP (cond, 1) != const0_rtx)
Re: [PATCH, SMS 3/3] Skip DEBUG_INSN in loop-doloop.c
Hi, > This small fix was inserted to skip DEBUG_INSNs while > recognizing doloop pattern in loop-doloop.c file. It's a fix > for the already approved do-loop patch (not in mainline yet, > http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop.c > > The patch was tested together with the rest of the patches in this series > and on top of the patch to support do-loop for ARM (not yet in mainline, > but approved http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html). > On ppc64-redhat-linux regtest as well as bootstrap with SMS flags > enabling SMS also on loops with stage count 1. Regtested on SPU. > On arm-linux-gnueabi regtseted on c,c++. Bootstrap c language with SMS > flags enabling SMS also on loops with stage count 1. > > OK for mainline? OK, Zdenek
Re: [SPARC] Remove unused macros
> This patch remove some unused macros from sparc.h. The > RTX_OK_FOR_OFFSET_P and RTX_OK_FOR_OLO10_P macros is used only in > sparc_legitimate_address_p function and moved to sparc.c. Thanks for spotting this. > OK to install? > > > * config/sparc/sparc.h (REG_OK_FOR_INDEX_P, REG_OK_FOR_BASE_P, > SYMBOLIC_CONST, RTX_OK_FOR_BASE_P, RTX_OK_FOR_INDEX_P): Remove. > (RTX_OK_FOR_OFFSET_P, RTX_OK_FOR_OLO10_P): Move to... > * config/sparc/sparc.c (RTX_OK_FOR_OFFSET_P, > RTX_OK_FOR_OLO10_P): ...here. > (sparc_mode_dependent_address_p): Use symbolic_operand instead of > SYMBOLIC_CONST. OK if you move... > On SPARC, the actual legitimate addresses must be REG+REG or > REG+SMALLINT - ordinarily. This changes a bit when generating PIC. ...this couple of sentences to the head comment of sparc_legitimate_address_p. -- Eric Botcazou
Re: [rs6000] Fix thinko in output_profile_hook
> 2011-03-24 Eric Botcazou > > * config/rs6000/rs6000.c (output_profile_hook): Fix thinko. Applied as obvious. -- Eric Botcazou
Re: [AVR] Couple of tweaks
> Have you run the regression test suite for the AVR for this patch? The compiler doesn't even build without the print_operand_address hunk... I've installed this hunk as obvious to make some progress. -- Eric Botcazou
C++ Patch for PR c++/48859
Hello, Here the problem is that we were recursing even if there was a user defined constructor. In fact, the check was only done at the top, not in nested fields. If there is a user defined constructor, uninitialized const or reference members are diagnosed elsewhere. Bootstraped and tested on x86_64-unknown-linux-gnu. OK for trunk and 4.6 ? gcc/cp/ChangeLog: 2011-05-07 Fabien Chêne PR c++/48859 * init.c (diagnose_uninitialized_cst_or_ref_member_1): stop the recursion if there is user defined constructor. gcc/testsuite/ChangeLog: 2001-05-07 Fabien Chêne PR c++/48859 * g++.dg/init/pr48859.C: New. -- Fabien pr48859.patch Description: Binary data
Re: Ping: Make 128 bits the default vector size for NEON
On 6 May 2011 13:29, Richard Earnshaw wrote:
>
> On Thu, 2011-04-21 at 09:02 +0300, Ira Rosen wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02172.html
>>
>> The last version:
>>
>> ChangeLog:
>>
>> * doc/invoke.texi (preferred-vector-size): Document.
>> * params.h (PREFERRED_VECTOR_SIZE): Define.
>> * config/arm/arm.c (arm_preferred_simd_mode): Use param
>> PREFERRED_VECTOR_SIZE instead of
>> TARGET_NEON_VECTORIZE_QUAD. Make 128 bits the default.
>> (arm_autovectorize_vector_sizes): Likewise.
>> * config/arm/arm.opt (NEON_VECTORIZE_QUAD): Add
>> RejectNegative.
>> * params.def (PARAM_PREFERRED_VECTOR_SIZE): Define.
>>
>> testsuite/ChangeLog:
>>
>> * lib/target-supports.exp (check_effective_target_vect_multiple_sizes):
>> New procedure.
>> (add_options_for_quad_vectors): Replace with ...
>> (add_options_for_double_vectors): ... this.
>> * gfortran.dg/vect/pr19049.f90: Expect more printings on targets that
>> support multiple vector sizes since the vectorizer attempts to
>> vectorize with both vector sizes.
>> * gcc.dg/vect/slp-reduc-6.c, gcc.dg/vect/no-vfa-vect-79.c,
>> gcc.dg/vect/no-vfa-vect-102a.c, gcc.dg/vect/vect-outer-1a.c,
>> gcc.dg/vect/vect-outer-1b.c, gcc.dg/vect/vect-outer-2b.c,
>> gcc.dg/vect/vect-outer-3a.c, gcc.dg/vect/no-vfa-vect-37.c,
>> gcc.dg/vect/vect-outer-3b.c, gcc.dg/vect/no-vfa-vect-101.c,
>> gcc.dg/vect/no-vfa-vect-102.c, gcc.dg/vect/vect-reduc-dot-s8b.c,
>> gcc.dg/vect/vect-outer-1.c, gcc.dg/vect/vect-104.c: Likewise.
>> * gcc.dg/vect/vect-16.c: Rename to...
>> * gcc.dg/vect/no-fast-math-vect-16.c: ... this to ensure that it runs
>> without -ffast-math.
>> * gcc.dg/vect/vect-42.c: Run with 64 bit vectors if applicable.
>> * gcc.dg/vect/vect-multitypes-6.c, gcc.dg/vect/vect-52.c,
>> gcc.dg/vect/vect-54.c, gcc.dg/vect/vect-46.c, gcc.dg/vect/vect-48.c,
>> gcc.dg/vect/vect-96.c, gcc.dg/vect/vect-multitypes-3.c,
>> gcc.dg/vect/vect-40.c: Likewise.
>> * gcc.dg/vect/vect-outer-5.c: Remove quad-vectors option as
>> redundant.
>> * gcc.dg/vect/vect-109.c, gcc.dg/vect/vect-peel-1.c,
>> gcc.dg/vect/vect-peel-2.c, gcc.dg/vect/slp-25.c,
>> gcc.dg/vect/vect-multitypes-1.c, gcc.dg/vect/slp-3.c,
>> gcc.dg/vect/no-vfa-pr29145.c, gcc.dg/vect/vect-multitypes-4.c:
>> Likewise.
>> * gcc.dg/vect/vect.exp: Run no-fast-math-vect*.c tests with
>> -fno-fast-math.
>>
>> Thanks,
>> Ira
>
> +@item preferred-vector-size
> +Preferred vector size in bits for targets that support multiple vector sizes.
> +Invalid values are ignored. The default is 128.
> +
>
> Shouldn't the preferred size be the largest size supported by the
> target? Setting it to 128 might be OK today, but who knows what might
> happen in future?
How about ARM specific flag similar to -mprefer-avx128 (not tested)?
Thanks,
Ira
ChangeLog:
* config/arm/arm.c (arm_preferred_simd_mode): Use
flag_prefer_neon_double instead of
TARGET_NEON_VECTORIZE_QUAD. Make 128 bits the default.
(arm_autovectorize_vector_sizes): Likewise.
* config/arm/arm.opt (NEON_VECTORIZE_QUAD): Add
RejectNegative.
(mprefer-neon-double): New flag.
(the testsuite part is unchanged).
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 173546)
+++ config/arm/arm.c(working copy)
@@ -22482,16 +22482,16 @@ arm_preferred_simd_mode (enum machine_mode mode)
switch (mode)
{
case SFmode:
- return TARGET_NEON_VECTORIZE_QUAD ? V4SFmode : V2SFmode;
- case SImode:
- return TARGET_NEON_VECTORIZE_QUAD ? V4SImode : V2SImode;
- case HImode:
- return TARGET_NEON_VECTORIZE_QUAD ? V8HImode : V4HImode;
- case QImode:
- return TARGET_NEON_VECTORIZE_QUAD ? V16QImode : V8QImode;
- case DImode:
- if (TARGET_NEON_VECTORIZE_QUAD)
- return V2DImode;
+return flag_prefer_neon_double ? V2SFmode : V4SFmode;
+ case SImode:
+return flag_prefer_neon_double ? V2SImode : V4SImode;
+ case HImode:
+return flag_prefer_neon_double ? V4HImode : V8HImode;
+ case QImode:
+return flag_prefer_neon_double ? V8QImode : V16QImode;
+ case DImode:
+if (!flag_prefer_neon_double)
+ return V2DImode;
break;
default:;
@@ -23722,7 +23722,7 @@ arm_expand_sync (enum machine_mode mode,
static unsigned int
arm_autovectorize_vector_sizes (void)
{
- return TARGET_NEON_VECTORIZE_QUAD ? 16 | 8 : 0;
+ return (!flag_prefer_neon_double) ? 16 | 8 : 0;
}
static bool
Index: config/arm/arm.opt
===
--- config/arm/arm.opt (revision 173546)
+++ config/arm/arm.opt (working copy)
@@ -160,9 +160,13 @@ Target Report RejectNegative Mask(LITTLE_WORDS)
Assume big endian bytes, little endian words
Re: [Patch, libfortran] Thread safety and simplification of error printing
On Sat, May 7, 2011 at 19:35, Janne Blomqvist wrote: > Hi, > > the error printing functionality (in io/unix.c) st_printf and > st_vprintf are not thread-safe as they use a static buffer. However, > since these routines are used when something has gone wrong, we > shouldn't use malloc() to allocate thread-specific buffers or anything > fancy like that. The way the buffer is used is that it is filled with > vs(n)printf() and then the buffer is written using write(); the > simplest way to fix this is to just print directly using vfprintf(), > which is what this patch does. Also, the patch uses > flockfile/funlockfile in a few places to increase the likelihood of > multiple related messages to end up together on the output. > > As stderr is unbuffered and stdout is buffered, this patch also gets > rid of the functionality to choose where to send the error output, as > we don't want to deal with buffering in the error handling path. IMHO > this is no loss, as all targets/shells/batch schedulers/ etc. where > this might be relevant, offer functionality to redirect stderr to > wherever stdout goes. So there is no need for a gfortran-specific > mechanism for this. While this patch makes error printing thread-safe, it's no longer async-signal-safe as the stderr lock might lead to a deadlock. So I'm retracting this patch and thinking some more about this problem. -- Janne Blomqvist
Re: Ping: Make 128 bits the default vector size for NEON
On Sun, 8 May 2011, Ira Rosen wrote: > How about ARM specific flag similar to -mprefer-avx128 (not tested)? If this goes in, please also update gcc-4.7/changes.html. Thanks, Gerald
Re: Ping: Make 128 bits the default vector size for NEON
On 8 May 2011 15:02, Gerald Pfeifer wrote: > On Sun, 8 May 2011, Ira Rosen wrote: >> How about ARM specific flag similar to -mprefer-avx128 (not tested)? > > If this goes in, please also update gcc-4.7/changes.html. Do you mean that the new flag should be documented? This patch http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00318.html updates about the change of the default vector size. Thanks, Ira > > Thanks, > Gerald >
[wwwdocs] Remove redundant bgcolor= from projects/tree-ssa/tree-browser.html
This has been redundant for 8+ years, and in the course of simplifying things globally I noticed and yanked this now. Gerald Index: projects/tree-ssa/tree-browser.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/tree-browser.html,v retrieving revision 1.2 diff -u -r1.2 tree-browser.html --- projects/tree-ssa/tree-browser.html 30 Nov 2002 15:44:50 - 1.2 +++ projects/tree-ssa/tree-browser.html 8 May 2011 12:47:53 - @@ -8,7 +8,7 @@ Until recently the only way to debug trees from gdb was to call debug_tree as follows: - + @@ -21,7 +21,7 @@ An alternative for interactively scan tree structures is to use the Tree Browser. You can access Tree Browser from anywhere during a debugging session as follows: - + @@ -37,7 +37,7 @@ For listing available commands, you could try: - + @@ -109,7 +109,7 @@ Now let's try some of these commands: we're on the declaration of the current function, we can have a look at its body. - + @@ -140,7 +140,7 @@ The above output is a pretty-print of the body of the current function. A call to debug_tree would have printed more things about the structure of the Abstract Syntax Trees (AST), as follows: - + @@ -207,7 +207,7 @@ and a block. All these fields are accessible from Tree Browser. Thus if we continue our exploration of the current tree structure, - + @@ -250,7 +250,7 @@ information about the position of this expression in the original source code. For accessing the next expression you can use the next command: - + @@ -289,7 +289,7 @@ You can choose to go backwards via the history stack: this pops the last visited node from the stack. - + @@ -310,7 +310,7 @@ Or via the previous expression command (this information is not yet included in GCC's trees, Tree Browser stores it in a hash table): - +
Re: GAS GCC FAQ query
On Fri, 6 May 2011, Jonathan Wakely wrote: >> I would propose to clarify as: >> >> "To ensure that GCC finds the GNU assembler (or the GNU linker)," > I see no harm in that change, Gerald, what do you think? Agreed. Things would have been different twenty years ago, but these days using linker is a lot more natural and common (as a grep in gcc/doc confirms, too). I went ahead and applied the patch below. Thanks for suggesting this! Gerald Index: faq.html === RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v retrieving revision 1.211 diff -u -r1.211 faq.html --- faq.html30 May 2010 15:37:32 - 1.211 +++ faq.html8 May 2011 13:01:04 - @@ -218,14 +218,14 @@ GCC can not find GNU as/GNU ld -GCC searches the PATH for an assembler and a loader, but it only +GCC searches the PATH for an assembler and a linker, but it only does so after searching a directory list hard-coded in the GCC executables. Since, on most platforms, the hard-coded list includes -directories in which the system assembler and loader can be found, you +directories in which the system assembler and linker can be found, you may have to take one of the following actions to arrange that GCC uses the GNU versions of those programs. -To ensure that GCC finds the GNU assembler (the GNU loader), which +To ensure that GCC finds the GNU assembler (the GNU linker), which are required by http://gcc.gnu.org/install/specific.html";>some configurations, you should configure these with the same --prefix option as you used
Re: GAS GCC FAQ query
> Agreed. Things would have been different twenty years ago, but these > days using linker is a lot more natural and common (as a grep in gcc/doc > confirms, too). Even 20 years ago, I think "linker" would have been the more natural word. I remember "linker" from my IBM days in the early 80's.
Re: [Patch, libfortran] Thread safety and simplification of error printing
On May 8 2011, Janne Blomqvist wrote: the error printing functionality (in io/unix.c) st_printf and st_vprintf are not thread-safe as they use a static buffer. ... While this patch makes error printing thread-safe, it's no longer async-signal-safe as the stderr lock might lead to a deadlock. So I'm retracting this patch and thinking some more about this problem. It's theoretically insoluble, given the constraints you are working under. Sorry. It is possible to do reasonably well, but there will always be likely scenarios where all you can do is to say "Aargh! I give up." Both I and the VMS people adopted the ratchet design. You have N levels of error recovery, each level allocates all of the resources it needs before startup, and any exception during level K increases the level to K+1 and calls the level K+1 error handler. When you have an exception at level N, you just die. That imposes the constraint that all diagnostics have a fixed upper bound on the resources they need (not just buffer space, but that's the main one). It's a real bummer when the system has some critical resources that you can't reserve, so you have to treat an allocation failure as an exception, but buffer space is not one such. That also tackles the thread problem, not very satisfactorily. If a resource needs to be locked, you can try to get it for a bit, and then raise a higher exception if you can't. And, typically, one or more of the highest levels are for closing down the process, and simply suspend any subsequent threads that call them (i.e. just leave them waiting for a lock they won't get). Yes, it's not pretty. But I don't know how to do better. Regards, Nick Maclaren.
Re: [PATCH] Typed DWARF stack
On Tue, May 3, 2011 at 6:33 AM, H.J. Lu wrote:
> On Sat, Apr 16, 2011 at 1:11 AM, Jakub Jelinek wrote:
>> On Fri, Mar 25, 2011 at 12:32:37PM +0100, Jakub Jelinek wrote:
>>> As I said in my GCC Summit talk, currently we just give up on
>>> any floating point/_Decimal*/__int128 and for 32-bit targets even
>>> long long expressions, as those can't be represented in DWARF4,
>>> while var-tracking has all that often available.
>>
>> ...
>>
>> This is an updated patch for the typed DWARF stack support,
>> against current trunk. I've changed DW_OP_GNU_reinterpret
>> from 0xf8 to 0xf9, because 0xf8 is taken by PGI and e.g. binutils prefers no
>> clashes between extension opcodes, otherwise readers would need to switch
>> based on producer. When we are close to running out of extension opcodes,
>> we may reconsider (especially as the HP block is quite large).
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> 2011-04-16 Jakub Jelinek
>>
>> * dwarf2.h (DW_OP_GNU_const_type, DW_OP_GNU_regval_type,
>> DW_OP_GNU_deref_type, DW_OP_GNU_convert, DW_OP_GNU_reinterpret): New.
>>
>> * dwarf2out.c (get_address_mode): New inline.
>> (mem_loc_descriptor): Add MEM_MODE parameter, adjust recursive calls,
>> if not dwarf_strict emit
>> DW_OP_GNU_{{const,regval,deref}_type,convert,reinterpret} when
>> desirable. Handle FLOAT_EXTEND, FLOAT_TRUNCATE, FLOAT,
>> UNSIGNED_FLOAT, FIX and UNSIGNED_FIX. Just return NULL for
>> FMA, STRICT_LOW_PART, CONST_VECTOR and CONST_FIXED.
>> (dwarf2out_frame_debug_cfa_expression, reg_loc_descriptor,
>> dw_loc_list_1, cst_pool_loc_descr, loc_list_from_tree): Adjust
>> mem_loc_descriptor callers.
>> (dwarf_stack_op_name, size_of_loc_descr, output_loc_operands,
>> output_loc_operands_raw, hash_loc_operands, compare_loc_operands):
>> Handle DW_OP_GNU_const_type, DW_OP_GNU_regval_type,
>> DW_OP_GNU_deref_type, DW_OP_GNU_convert and DW_OP_GNU_reinterpret.
>> (base_types): New variable.
>> (get_base_type_offset, calc_base_type_die_sizes,
>> base_type_for_mode, mark_base_types, base_type_cmp,
>> move_marked_base_types): New functions.
>> (calc_die_sizes): Assert that die_offset is 0 or equal to
>> next_die_offset.
>> (loc_descriptor): Only handle here lowpart SUBREGs of REG, for
>> others defer to mem_loc_descriptor. Adjust mem_loc_descriptor
>> callers. If not dwarf_strict, call mem_loc_descriptor even for
>> non-MODE_INT modes or MODE_INT modes larger than DWARF2_ADDR_SIZE.
>> (gen_subprogram_die): Don't give up on call site parameters
>> with non-integral or large integral modes. Adjust
>> mem_loc_descriptor callers.
>> (prune_unused_types): Call prune_unused_types_mark on base_types
>> vector entries.
>> (resolve_addr): Call mark_base_types.
>> (dwarf2out_finish): Call move_marked_base_types.
>
> This caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
>
This also caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48928
--
H.J.
[C++ patch, committed as obvious] PR 48816
Hi,
committed to mainline.
Paolo.
//
2011-05-08 Paolo Carlini
PR c++/48816
* cxx-pretty-print.c (pp_cxx_template_declaration): Remove
effectively unused variable.
Index: cxx-pretty-print.c
===
--- cxx-pretty-print.c (revision 173548)
+++ cxx-pretty-print.c (working copy)
@@ -2133,7 +2133,6 @@ pp_cxx_template_declaration (cxx_pretty_printer *p
{
tree tmpl = most_general_template (t);
tree level;
- int i = 0;
pp_maybe_newline_and_indent (pp, 0);
for (level = DECL_TEMPLATE_PARMS (tmpl); level; level = TREE_CHAIN (level))
@@ -2143,7 +2142,6 @@ pp_cxx_template_declaration (cxx_pretty_printer *p
pp_cxx_template_parameter_list (pp, TREE_VALUE (level));
pp_cxx_end_template_argument_list (pp);
pp_newline_and_indent (pp, 3);
- i += 3;
}
if (TREE_CODE (t) == FUNCTION_DECL && DECL_SAVED_TREE (t))
pp_cxx_function_definition (pp, t);
Re: Propagate BB predicates in ipa-inline-analysis
On Fri, Apr 29, 2011 at 2:18 PM, Jan Hubicka wrote: > Hi, > this more or less complettes the infrastructure for predicates by adding > logic propagating predicates across CFG. I also added switch statement > handling and __builtin_constant_p construct, so we "understand" functions > using those as one in the new testcase. > > It also turned out that the predicate handling code should be more aggressive > on simplification and canonicalization so the propagation converges quickly. > > Bootstrapped/regtested x86_64-linux, will commit it shortly. > > Honza > > * gcc.dg/tree-ssa/inline-10.c: New testcase. > * gcc.dg/tree-ssa/inline-9.c: Disable partial inlining. > * ipa-inline.h (clause_t): Turn into unsigned int. > * ipa-inline-analysis.c (add_clause): Do more simplification. > (and_predicates): Shortcut more cases. > (predicates_equal_p): Move forward; check that clauses are properly > ordered. > (or_predicates): Shortcut more cases. > (edge_execution_predicate): Rewrite as... > (set_cond_stmt_execution_predicate): ... this function; handle > __builtin_constant_p. > (set_switch_stmt_execution_predicate): New . > (compute_bb_predicates): New. > (will_be_nonconstant_predicate): Update TODO. > (estimate_function_body_sizes): Use compute_bb_predicates > and free them later, always try to estimate if stmt is constant. > (estimate_time_after_inlining, estimate_size_after_inlining): > Gracefully handle optimized out edges. > (read_predicate): Fix off by one error. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48929 -- H.J.
Re: [Patch, libfortran] Thread safety and simplification of error printing
Sorry - I should have clarified that ANYTHING that can't be used independently in multiple threads and at multiple levels in the same thread counts as a resource, and that includes stderr. Regards, Nick Maclaren.
[C++ Patch] PRs 48737 & 48744
Hi,
as far as I can see this is just another case where we want to pass down
more consistently the complain argument in order to avoid hard errors in
sfinae contexts. In particular, we don't want hard errors from
reshape_init itself (in order to fix 48737) and we want digest_init_r to
forward complain to convert_for_initialization (to fix 48744). This
requires some small adjustments elsewhere, not too much, in particular,
earlier, finish_compound_literal forwards its complain argument to
reshape_init and digest_init.
Tested x86_64-linux. Ok for mainline?
Thanks,
Paolo.
//
/cp
2011-05-08 Paolo Carlini
PR c++/48737
PR c++/48744
* decl.c (reshape_init): Take a complain parameter and do
not call error if tf_error is not set.
(check_initializer, reshape_init_r): Adjust.
* typeck2.c (digest_init_r): Take a complain parameter and
pass it to convert_for_initialization.
(digest_init, digest_init_flags, process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union):
Adjust.
* init.c (expand_default_init, build_new_1): Likewise.
* typeck.c (cp_build_modify_expr): Likewise.
* decl2.c (grokfield): Likewise.
* call.c (convert_like_real, convert_default_arg): Likewise.
* semantics.c (finish_compound_literal): Pass complain to
reshape_init and digest_init.
* cp-tree.h: Adjust declarations.
/testsuite
2011-05-08 Paolo Carlini
PR c++/48737
PR c++/48744
* g++.dg/template/sfinae28.C: New.
* g++.dg/template/sfinae29.C: Likewise.
Index: testsuite/g++.dg/template/sfinae28.C
===
--- testsuite/g++.dg/template/sfinae28.C(revision 0)
+++ testsuite/g++.dg/template/sfinae28.C(revision 0)
@@ -0,0 +1,13 @@
+// PR c++/48737
+// { dg-options "-std=c++0x" }
+
+template
+T&& create();
+
+template
+decltype(T{create()...}, char()) f(int);
+
+template
+char (&f(...))[2];
+
+static_assert(sizeof(f(0)) != 1, "Error");
Index: testsuite/g++.dg/template/sfinae29.C
===
--- testsuite/g++.dg/template/sfinae29.C(revision 0)
+++ testsuite/g++.dg/template/sfinae29.C(revision 0)
@@ -0,0 +1,23 @@
+// PR c++/48744
+// { dg-options "-std=c++0x" }
+
+template
+struct add_rval_ref {
+ typedef T&& type;
+};
+
+template<>
+struct add_rval_ref {
+ typedef void type;
+};
+
+template
+typename add_rval_ref::type create();
+
+template
+decltype(T{create()}, char()) f(int);
+
+template
+char (&f(...))[2];
+
+static_assert(sizeof(f(0)) != 1, "Error");
Index: cp/typeck.c
===
--- cp/typeck.c (revision 173549)
+++ cp/typeck.c (working copy)
@@ -6715,7 +6715,7 @@ cp_build_modify_expr (tree lhs, enum tree_code mod
}
if (check_array_initializer (lhs, lhstype, newrhs))
return error_mark_node;
- newrhs = digest_init (lhstype, newrhs);
+ newrhs = digest_init (lhstype, newrhs, complain);
}
else if (!same_or_base_type_p (TYPE_MAIN_VARIANT (lhstype),
Index: cp/init.c
===
--- cp/init.c (revision 173549)
+++ cp/init.c (working copy)
@@ -1435,7 +1435,7 @@ expand_default_init (tree binfo, tree true_exp, tr
{
/* A brace-enclosed initializer for an aggregate. In C++0x this can
happen for direct-initialization, too. */
- init = digest_init (type, init);
+ init = digest_init (type, init, complain);
init = build2 (INIT_EXPR, TREE_TYPE (exp), exp, init);
TREE_SIDE_EFFECTS (init) = 1;
finish_expr_stmt (init);
@@ -2375,7 +2375,7 @@ build_new_1 (VEC(tree,gc) **placement, tree type,
"verify length of initializer-list");
}
arraytype = build_cplus_array_type (type, domain);
- vecinit = digest_init (arraytype, vecinit);
+ vecinit = digest_init (arraytype, vecinit, complain);
}
else if (*init)
{
Index: cp/decl.c
===
--- cp/decl.c (revision 173549)
+++ cp/decl.c (working copy)
@@ -5203,7 +5203,7 @@ reshape_init_r (tree type, reshape_iter *d, bool f
{
++d->cur;
gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (init));
- return reshape_init (type, init);
+ return reshape_init (type, init, tf_warning_or_error);
}
}
@@ -5238,7 +5238,7 @@ reshape_init_r (tree type, reshape_iter *d, bool f
revised CONSTRUCTOR node is returned. */
tree
-reshape_init (tree type, tree init)
+reshape_init (tree type, tree init, tsubst_flags_t complain)
{
VEC(constructor_elt, gc) *v;
reshape_iter d;
@@ -5264,
Re: [Patch, libfortran] Thread safety and simplification of error printing
On Sun, May 8, 2011 at 14:40, Janne Blomqvist wrote:
> On Sat, May 7, 2011 at 19:35, Janne Blomqvist
> wrote:
>> Hi,
>>
>> the error printing functionality (in io/unix.c) st_printf and
>> st_vprintf are not thread-safe as they use a static buffer. However,
>> since these routines are used when something has gone wrong, we
>> shouldn't use malloc() to allocate thread-specific buffers or anything
>> fancy like that. The way the buffer is used is that it is filled with
>> vs(n)printf() and then the buffer is written using write(); the
>> simplest way to fix this is to just print directly using vfprintf(),
>> which is what this patch does. Also, the patch uses
>> flockfile/funlockfile in a few places to increase the likelihood of
>> multiple related messages to end up together on the output.
>>
>> As stderr is unbuffered and stdout is buffered, this patch also gets
>> rid of the functionality to choose where to send the error output, as
>> we don't want to deal with buffering in the error handling path. IMHO
>> this is no loss, as all targets/shells/batch schedulers/ etc. where
>> this might be relevant, offer functionality to redirect stderr to
>> wherever stdout goes. So there is no need for a gfortran-specific
>> mechanism for this.
>
> While this patch makes error printing thread-safe, it's no longer
> async-signal-safe as the stderr lock might lead to a deadlock. So I'm
> retracting this patch and thinking some more about this problem.
So here is an updated patch. Compared to the status quo the main
differences are that it uses a stack allocated buffer to do the
formatting instead of a static one. This prevents conflicts from
multiple threads and in contrast to the approach in the previous patch
should also be async-signal-safe (or at least, less likely to go
belly-up when called from within a signal handler than using
vfprintf() directly). It also introduces a new function to write a
string to standard error without any formatting (estr_write), which is
simpler and less likely to cause problems than the general purpose
vs(n)printf() used before. This can be used in lieu of st_printf in
the majority of cases where no formatting is done.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
frontend ChangeLog:
2011-05-08 Janne Blomqvist
* gfortran.texi: Remove GFORTRAN_USE_STDERR documentation.
library ChangeLog:
2011-05-08 Janne Blomqvist
* io/unix.c (st_vprintf,st_printf): Move to runtime/error.c.
* libgfortran.h (struct options_t): Remove use_stderr field.
(st_vprintf,st_printf): Move prototypes.
(estr_write): New prototype.
* runtime/error.c (sys_exit): Use estr_write instead of st_printf.
(estr_write): New function.
(st_vprintf): Move from io/unix.c, use stack allocated buffer,
always output to stderr.
(st_printf): Move from io/unix.c.
(show_locus): Use a local variable instead of static.
(os_error): Use estr_write instead of st_printf.
(runtime_error): Likewise.
(runtime_error_at): Likewise.
(runtime_warning_at): Likewise.
(internal_error): Likewise.
(generate_error): Likewise.
(generate_warning): Likewise.
(notify_std): Likewise.
* runtime/pause.c (do_pause): Likewise.
(pause_string): Likewise.
* runtime/stop.c (stop_string): Likewise.
(error_stop_string): Likewise.
* config/fpu_aix.h (set_fpu): Likewise.
* config/fpu_generic.h (set_fpu): Likewise.
* config/fpu_glibc.h (set_fpu): Likewise.
* config/fpu-sysv.h (set_fpu): Likewise.
* runtime/backtrace.c (dump_glibc_backtrace): Likewise.
(show_backtrace): Likewise.
* runtime/environ.c (print_spaces): Likewise.
(show_string): Likewise.
(show_variables): Likewise.
(variable_table[]): Remove GFORTRAN_USE_STDERR entry.
--
Janne Blomqvist
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 1284c3d..c810fe2 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -579,7 +579,6 @@ Malformed environment variables are silently ignored.
* GFORTRAN_STDIN_UNIT:: Unit number for standard input
* GFORTRAN_STDOUT_UNIT:: Unit number for standard output
* GFORTRAN_STDERR_UNIT:: Unit number for standard error
-* GFORTRAN_USE_STDERR:: Send library output to standard error
* GFORTRAN_TMPDIR:: Directory for scratch files
* GFORTRAN_UNBUFFERED_ALL:: Don't buffer I/O for all units.
* GFORTRAN_UNBUFFERED_PRECONNECTED:: Don't buffer I/O for preconnected units.
@@ -613,14 +612,6 @@ This environment variable can be used to select the unit number
preconnected to standard error. This must be a positive integer.
The default value is 0.
-@node GFORTRAN_USE_STDERR
-@section @env{GFORTRAN_USE_STDERR}---Send library output to standard error
-
-This environment variable controls where library output is sent.
-If the first letter is @samp{y}, @samp{Y} or @samp{
Better time/size estimates for ipa-cp
Hi,
this patch adds neccesary support into ipa-inline-analysis to make it useable
for ipa-cp. I.e. in the following testcase:
int test (int a)
{
if (a>10)
{
e();
e();
e();
e();
e();
e();
e();
e();
}
}
main2()
{
test(1);
test(1);
test(1);
test(1);
test(1);
test(1);
}
We now work out that size of ipcp clone of test is 3 (that is what we account
for size of empty function) and time 2 (that is time of return statement)
We also work out that all calls are optimized out in the clone:
Inline summary for test.constprop.0/3 inlinable versionable
self time: 2
global time: 2
self size: 3
global size: 3
self stack: 0
global stack:0
size:0.00, time:0.00, predicate:(true)
size:2.00, time:0.00, predicate:(not inlined)
size:1.00, time:2.00, predicate:(op0 <= 10) && (not inlined)
calls:
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
e/2 function body not available
loop depth: 0 freq: 0 size: 1 time: 10 callee size: 0 stack: 0
predicate: (false)
(the op0<=10 is completely pointless predicate, but we don't really care).
New function estimate_ipcp_clone_size_and_time is exported that allows ipa-cp
to query the estimates before transformation is done. IPA-cp don't really use
it now in any wise way, it is up to Martin's planned rewrite of the pass for
partial specialization to do so.
Main extra work is in updating virtual clone summaries based on their tree_map
info. It is similar to one already done in inliner, just it don't need to
actually
merge the summaries, just work out what clauses are false now.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
Honza
* cgraph.c (cgraph_clone_node): Add call_duplication_hook parameter.
(cgraph_create_virtual_clone): Call hooks once virtual clone is
finished.
* cgraph.h (cgraph_clone_node): Update prototype.
* ipa-cp.c (ipcp_estimate_growth): Use
estimate_ipcp_clone_size_and_time.
* ipa-inline-transform.c (clone_inlined_nodes): Update.
* lto-cgraph.c (input_node): Update.
* ipa-inline.c (recursive_inlining): Update.
* ipa-inline.h (estimate_ipcp_clone_size_and_time): New function.
(evaluate_conditions_for_known_args): Break out from ...
(evaluate_conditions_for_edge): ... here.
(evaluate_conditions_for_ipcp_clone): New function.
(inline_node_duplication_hook): Update clone summary based
on parameter map.
(estimate_callee_size_and_time): Rename to ...
(estimate_node_size_and_time): take NODE instead of EDGE;
take POSSIBLE_TRUTHS as argument.
(estimate_callee_size_and_time): Update.
(estimate_ipcp_clone_size_and_time): New function.
(do_estimate_edge_time): Update.
Index: cgraph.c
===
*** cgraph.c(revision 173549)
--- cgraph.c(working copy)
*** cgraph_clone_edge (struct cgraph_edge *e
*** 2128,2133
--- 2128,2134
return new_edge;
}
+
/* Create node representing clone of N executed COUNT times. Decrease
the execution counts from original node too.
The new clone will have decl set to DECL that may or may not be the same
*** cgraph_clone_edge (struct cgraph_edge *e
*** 2135,2145
When UPDATE_ORIGINAL is true, the counts are subtracted from the original
function's profile to reflect the fact that part of execution is handled
!by node. */
struct cgraph_node *
cgraph_clone_node (struct cgraph_node *n, tree decl, gcov_type count, int
freq,
bool update_original,
! VEC(cgraph_edge_p,heap) *redirect_callers)
{
struct cgraph_node *new_node = cgraph_create_node_1 ();
struct cgraph_edge *e;
--- 2136,2150
When UPDATE_ORIGINAL is true, the counts are subtracted from the original
function's profile to reflect the fact that part of execution is handled
!by node.
!When CALL_DUPLICATOIN_HOOK is true, the ipa
Re: [Patch, libfortran] Thread safety and simplification of error printing
On Sun, May 8, 2011 at 16:42, N.M. Maclaren wrote: > On May 8 2011, Janne Blomqvist wrote: >>> >>> the error printing functionality (in io/unix.c) st_printf and >>> st_vprintf are not thread-safe as they use a static buffer. ... >> >> While this patch makes error printing thread-safe, it's no longer >> async-signal-safe as the stderr lock might lead to a deadlock. So I'm >> retracting this patch and thinking some more about this problem. > > It's theoretically insoluble, given the constraints you are working > under. Sorry. It is possible to do reasonably well, but there will > always be likely scenarios where all you can do is to say "Aargh! > I give up." Well, I realize perfection is impossible, so I'm settling for merely improving the status quo! > Both I and the VMS people adopted the ratchet design. You have N > levels of error recovery, each level allocates all of the resources > it needs before startup, and any exception during level K increases > the level to K+1 and calls the level K+1 error handler. When you > have an exception at level N, you just die. To some extent we have a crude version of this, in that when we're entering many of the fatal error handling functions we do a recursion check and if that fails, die. Also, in a recent patch of mine (http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00584.html ) the fatal signal handler function has been reworked to hopefully deal better with other signal(s) being delivered before it's done; that code is modeled after an example in the glibc manual, and I'm a bit unsure if the recursion check thingy really works or we just end up in an infinite recursion (that is, do we need to re-set to the default handler before re-raising? I have a vague memory that the signal handler for SIGXXX must finish before starting the handler for another SIGXXX pending signal, which would make the current version safe). > That imposes the constraint that all diagnostics have a fixed upper > bound on the resources they need (not just buffer space, but that's > the main one). It's a real bummer when the system has some critical > resources that you can't reserve, so you have to treat an allocation > failure as an exception, but buffer space is not one such. > > That also tackles the thread problem, not very satisfactorily. If a > resource needs to be locked, you can try to get it for a bit, and > then raise a higher exception if you can't. And, typically, one or > more of the highest levels are for closing down the process, and > simply suspend any subsequent threads that call them (i.e. just leave > them waiting for a lock they won't get). I think in our case the situation is a bit easier in that we're not trying to recover from a serious failure, merely print some diagnostic information without getting stuck in a deadlock. -- Janne Blomqvist
[PATCH, IRA]: Fix PR 48927 - Issues with "enable" attribute and IRA register preferences
Hello!
Attached patch fixes changed register allocation where "enabled"
attribute is used. The core of the problem was with IRA, where IRA
does not look at "enabled" attribute when scanning through
alternatives string to perform various tasks (including register
allocation preferences).
Attached patch teaches IRA to handle "enabled" attribute. In effect,
the patch skips current alternative in the same way as when "#"
character is found.
2011-05-08 Uros Bizjak
PR rtl-optimization/48927
* ira-conflicts.c (commutative_constraint_p): Use
recog_data.alternative_enabled_p to disable alternatives where
"enabled" attribute is false.
(get_dup_num): Ditto.
* ira-lives.c (single_reg_class): Ditto.
(ira_implicitly_set_insn_hard_regs): Ditto.
Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
{,-m32} with and without -with-fpmath=avx. Also, the patch fixes both
i386 scan-asm failures when the patch to merge *vec_concatv4si_1_avx
and *vec_concatv4si_1 patterns is applied (please see the PR [1] for
details).
OK for mainline?
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48927
Uros.
Index: ira-conflicts.c
===
--- ira-conflicts.c (revision 173548)
+++ ira-conflicts.c (working copy)
@@ -213,19 +213,22 @@ allocnos_conflict_for_copy_p (ira_allocn
static bool
commutative_constraint_p (const char *str)
{
+ int curr_alt, c;
bool ignore_p;
- int c;
- for (ignore_p = false;;)
+ for (ignore_p = false, curr_alt = 0;;)
{
c = *str;
if (c == '\0')
break;
str += CONSTRAINT_LEN (c, str);
- if (c == '#')
+ if (c == '#' || !recog_data.alternative_enabled_p[curr_alt])
ignore_p = true;
else if (c == ',')
- ignore_p = false;
+ {
+ curr_alt++;
+ ignore_p = false;
+ }
else if (! ignore_p)
{
/* Usually `%' is the first constraint character but the
@@ -270,7 +273,7 @@ get_dup_num (int op_num, bool use_commut
c = *str;
if (c == '\0')
break;
- if (c == '#')
+ if (c == '#' || !recog_data.alternative_enabled_p[curr_alt])
ignore_p = true;
else if (c == ',')
{
Index: ira-lives.c
===
--- ira-lives.c (revision 173548)
+++ ira-lives.c (working copy)
@@ -726,18 +726,21 @@ mark_hard_reg_early_clobbers (rtx insn,
static enum reg_class
single_reg_class (const char *constraints, rtx op, rtx equiv_const)
{
- int ignore_p;
+ int curr_alt, c;
+ bool ignore_p;
enum reg_class cl, next_cl;
- int c;
cl = NO_REGS;
- for (ignore_p = false;
+ for (ignore_p = false, curr_alt = 0;
(c = *constraints);
constraints += CONSTRAINT_LEN (c, constraints))
-if (c == '#')
+if (c == '#' || !recog_data.alternative_enabled_p[curr_alt])
ignore_p = true;
else if (c == ',')
- ignore_p = false;
+ {
+ curr_alt++;
+ ignore_p = false;
+ }
else if (! ignore_p)
switch (c)
{
@@ -873,7 +876,7 @@ single_reg_operand_class (int op_num)
void
ira_implicitly_set_insn_hard_regs (HARD_REG_SET *set)
{
- int i, c, regno = 0;
+ int i, curr_alt, c, regno = 0;
bool ignore_p;
enum reg_class cl;
rtx op;
@@ -895,11 +898,16 @@ ira_implicitly_set_insn_hard_regs (HARD_
mode = (GET_CODE (op) == SCRATCH
? GET_MODE (op) : PSEUDO_REGNO_MODE (regno));
cl = NO_REGS;
- for (ignore_p = false; (c = *p); p += CONSTRAINT_LEN (c, p))
- if (c == '#')
+ for (ignore_p = false, curr_alt = 0;
+ (c = *p);
+ p += CONSTRAINT_LEN (c, p))
+ if (c == '#' || !recog_data.alternative_enabled_p[curr_alt])
ignore_p = true;
else if (c == ',')
- ignore_p = false;
+ {
+ curr_alt++;
+ ignore_p = false;
+ }
else if (! ignore_p)
switch (c)
{
Re: [Patch, libfortran] Thread safety and simplification of error printing
On May 8 2011, Janne Blomqvist wrote: It's theoretically insoluble, given the constraints you are working under. Sorry. It is possible to do reasonably well, but there will always be likely scenarios where all you can do is to say "Aargh! I give up." Well, I realize perfection is impossible, so I'm settling for merely improving the status quo! Very reasonable, given the problem. Where the effort increases rapidly with the reliability, not being too fancy is a sound strategy. I think in our case the situation is a bit easier in that we're not trying to recover from a serious failure, merely print some diagnostic information without getting stuck in a deadlock. I wasn't trying to do much more! I was mainly trying to maximise the chances of files being closed cleanly and appropriate diagnostics being produced. Once there was a serious error, I didn't allow the program to continue. But I did allow user-written exception handlers (which could only return - NOT jump out). Even that was hard enough :-( Regards, Nick Maclaren.
Re: Ping: Make 128 bits the default vector size for NEON
On Sun, 8 May 2011, Ira Rosen wrote: >> If this goes in, please also update gcc-4.7/changes.html. > Do you mean that the new flag should be documented? Yes, as we're adding new flags, it's (nearly?) always a good idea to document them as part of the release notes. > This patch http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00318.html > updates about the change of the default vector size. That one I acked, right? Gerald
Re: [wwwdocs] Use regular markup for java/projects.html
On Sat, 30 Apr 2011, Steven Bosscher wrote: >> 2011-04-26 Gerald Pfeifer >> >> * projects.html: Use regular markup for section headers >> instead of fake tables. > The "Compiler improvements" section is 10 years behind on GCC's > development (tree-ssa!). The "recently released" jMocha is from 2000 > and I can't find it anywhere for download. The "Open JVM Integration" > is obsolete. There is very little on this page that is still useful > information for someone willing to contribute to GCJ... Hard to disagree, Steven. It's just that I am not to well aware of what's happening in Java land. I was hoping my patch made it easier for someone with more background to update this page in terms of contents, but seeing that nobody took action on your analysis I cooked up the patch below which I plan on committing in a couple of days. Gerald 2011-05-09 Gerald Pfeifer * projects.html: Update name of java mailing list. (Plugin for Mozilla): Remove section. (Compiler Improvements): Remove tree inlining item. (Benchmark infrastructure): Remove reference to jMocha. Index: projects.html === RCS file: /cvs/gcc/wwwdocs/htdocs/java/projects.html,v retrieving revision 1.34 diff -u -r1.34 projects.html --- projects.html 26 Apr 2011 20:25:34 - 1.34 +++ projects.html 8 May 2011 22:59:49 - @@ -12,7 +12,7 @@ to see someone pick up and run with. If you're interested in any of these, be sure to send a note with your questions, ideas or intentions to the mailto:j...@gcc.gnu.org";>java-discuss +href="mailto:j...@gcc.gnu.org";>java mailing list. Similarly, if you would like to see a project listed here that isn't, send a patch for this HTML file to the mailto:java-patc...@gcc.gnu.org";>java-patches list. @@ -27,18 +27,6 @@ -Plugin for Mozilla - - -http://www.mozilla.org/";>Mozilla is open-source web browser, -designed for standards compliance, performance and portability. The -Open JVM Integration project (OJI) is a Mozilla sub-project, and is -working to extend the browser to allow Java virtual machines to be -plugged into Mozilla. A gij based plugin would be very nice indeed -(gijzilla?). - - - Benchmark infrastructure @@ -49,8 +37,7 @@ mailto:br...@albatross.co.nz";>Bryce McKinlay has put -together a list of some benchmarks that run on GCJ. IBM has also -recently released a set of "micro benchmarks" called jMocha. +together a list of some benchmarks that run on GCJ. Building some infrastructure around these would be incredibly useful. @@ -97,11 +84,6 @@ Compiler improvements - We'd like gcj to do tree-level inlining like the C++ - compiler. We're most of the way there (when compiling - from Java source code), since gcj already represents - entire functions as trees. - Once we have tree-level inlining, we can use it to sometimes eliminate unnecessary synchronizations. Combined with a simple "no escape" flag, this could also
[PATCH] for Re: C99 and C++0x status pages
On Tue, 31 Aug 2010, Andre Majorel wrote: > Yesterday, I spent an hour looking for the C99 and C++0x status > pages in http://gcc.gnu.org/, > > http://gcc.gnu.org/c99status.html > http://gcc.gnu.org/projects/cxx0x.html > > Apparently, the shortest path to the latter is > > "Releases" > -> "GCC 4.5.1" > -> "GCC 4.5.1 Jul 31, 2010 (changes)" > -> "Improved experimental support for the upcoming C++0x" > -> "please see the C++0x in GCC project page" > > Those are among the most useful pages of the site, it makes no > sense to bury them 4+ levels deep. You're right, these two are really nice and for lack of proper landing pages for the C and C++ languages I went ahead and committed the patch below. Thanks for pointing this out, and sorry for the "slight" delay in getting back to you. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.800 diff -u -r1.800 index.html --- index.html 1 May 2011 21:26:47 - 1.800 +++ index.html 9 May 2011 00:30:51 - @@ -15,7 +15,9 @@ The GNU Compiler Collection includes front ends for -C, C++, Objective-C, Fortran, +C, +C++, +Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...). GCC was originally written as the compiler for the
[PATCH] allow setting LDFLAGS_FOR_TARGET in top-level configuration.
Hi, The x86 Android toolchain needs setting LDFLAGS_FOR_TARGET to build. This patch does that. The patch was tested by bootstrapping natively on x86_64 linux. Do I also need to submit this to binutils as well? -Doug
Re: [PATCH] allow setting LDFLAGS_FOR_TARGET in top-level configuration.
On Sun, May 8, 2011 at 7:31 PM, Doug Kwan (關振德) wrote: > Hi, > > The x86 Android toolchain needs setting LDFLAGS_FOR_TARGET to > build. This patch does that. The patch was tested by bootstrapping > natively on x86_64 linux. Do I also need to submit this to binutils > as well? > There is no patch. -- H.J.
Re: [PATCH] allow setting LDFLAGS_FOR_TARGET in top-level configuration.
Sorry, forgot the patch and the ChangeLog
2011-05-08 Doug Kwan
* configure.ac: Propagate LDFLAGS_FOR_TARGET.
* configure: Regenerated.
* Makefile.tpl (LDFLAGS_FOR_TARGET): Use LDFLAGS_FOR_TARGET
value from configure.
* Makefile.in: Regenerated.
On Sun, May 8, 2011 at 7:31 PM, Doug Kwan (關振德) wrote:
> Hi,
>
> The x86 Android toolchain needs setting LDFLAGS_FOR_TARGET to
> build. This patch does that. The patch was tested by bootstrapping
> natively on x86_64 linux. Do I also need to submit this to binutils
> as well?
>
> -Doug
>
Index: configure.ac
===
--- configure.ac(revision 173552)
+++ configure.ac(working copy)
@@ -2110,6 +2110,8 @@ if test "x$CXXFLAGS_FOR_TARGET" = x; then
fi
AC_SUBST(CXXFLAGS_FOR_TARGET)
+AC_SUBST(LDFLAGS_FOR_TARGET)
+
# Handle --with-headers=XXX. If the value is not "yes", the contents of
# the named directory are copied to $(tooldir)/sys-include.
if test x"${with_headers}" != x && test x"${with_headers}" != xno ; then
Index: Makefile.tpl
===
--- Makefile.tpl(revision 173552)
+++ Makefile.tpl(working copy)
@@ -494,7 +494,7 @@ CXXFLAGS_FOR_TARGET = @CXXFLAGS_FOR_TARGET@
LIBCFLAGS_FOR_TARGET = $(CFLAGS_FOR_TARGET)
LIBCXXFLAGS_FOR_TARGET = $(CXXFLAGS_FOR_TARGET) -fno-implicit-templates
-LDFLAGS_FOR_TARGET =
+LDFLAGS_FOR_TARGET = @LDFLAGS_FOR_TARGET@
GOCFLAGS_FOR_TARGET = -O2 -g
FLAGS_FOR_TARGET = @FLAGS_FOR_TARGET@
Re: C++ Patch for PR c++/48859
OK. Jason
Re: [C++ Patch] PRs 48737 & 48744
On 05/08/2011 12:51 PM, Paolo Carlini wrote:
@@ -5203,7 +5203,7 @@ reshape_init_r (tree type, reshape_iter *d, bool f
{
++d->cur;
gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (init));
- return reshape_init (type, init);
+ return reshape_init (type, init, tf_warning_or_error);
Any reason not to SFINAEify reshape_init_r as well? Same question for
process_init_constructor*.
Jason
Re: Ping: Make 128 bits the default vector size for NEON
Gerald Pfeifer wrote on 09/05/2011 01:53:35 AM: > > On Sun, 8 May 2011, Ira Rosen wrote: > >> If this goes in, please also update gcc-4.7/changes.html. > > Do you mean that the new flag should be documented? > > Yes, as we're adding new flags, it's (nearly?) always a good idea to > document them as part of the release notes. OK. > > > This patch http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00318.html > > updates about the change of the default vector size. > > That one I acked, right? Yes. Thanks, Ira > > Gerald
