headers
DJ Delorie | 1 May 2012 01:25
Picon
Favicon

[patch] skip tpf configure tests


	* crossconfig.m4: Since we know that all TPF builds are cross-
	builds and cannot run configuration-time link tests, do not 
	allow it; just go with known supported linker options.
	* configure: Regenerate (called as GLIBCXX_CROSSCONFIG).

Index: crossconfig.m4
===================================================================
--- crossconfig.m4	(revision 187002)
+++ crossconfig.m4	(working copy)
 <at>  <at>  -219,14 +219,14  <at>  <at>  case "${host}" in
     AC_DEFINE(HAVE_ISNANF)
     AC_DEFINE(HAVE_MODFF)
     AC_DEFINE(HAVE_HYPOT)
     ;;
   *-tpf)
     SECTION_FLAGS='-ffunction-sections -fdata-sections'
+    SECTION_LDFLAGS='-Wl,--gc-sections $SECTION_LDFLAGS'
     AC_SUBST(SECTION_FLAGS)
-    GLIBCXX_CHECK_LINKER_FEATURES
     AC_DEFINE(HAVE_FINITE)
     AC_DEFINE(HAVE_FINITEF)
     AC_DEFINE(HAVE_FREXPF)
     AC_DEFINE(HAVE_HYPOTF)
     AC_DEFINE(HAVE_ISINF)
     AC_DEFINE(HAVE_ISINFF)
Permalink | Reply | 2 comments |
headers
DJ Delorie | 1 May 2012 01:34
Picon
Favicon

Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)


> Set up a cron job to ping once a day.  :-) Did you ever dig up the
> Apple test cases from the APPLE LOCAL work I pointed you at earlier?
> They will be more comprehensive that any testing you've done, and,
> if you get them to all pass, the work should be closer to being
> complete.  The feature needed a ton of testcases, a few didn't cut
> it.

In going through the Apple test cases, I discovered one HUGE
disadvantage to using __attribute__ to tag structures for bit reversal
- it doesn't propogate.  I.e.:

	typedef __attribute__((reverse)) struct {
	  struct {
	    int x:4;
	    int y:4;
	  } a;
	} b;

The attribute seems to apply only to struct b, not to struct a.  For
PACKED, we handle the flag specially, propogating it at every step in
the layout.  The original Apple patch used a #pragma.

Suggestions on how to make a structure attribute apply to the whole
structure?

Or should I *also* add a #pragma to specify the default bit ordering?
This is what the Renesas ABIs want anyway, and what Apple did, but I
was told to use an attribute and have a target pragma set the
attribute, but I don't see how...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paolo Carlini | 1 May 2012 01:37
Picon
Favicon

Re: [RFH / Patch] PR 51222

Hi again,
> On 04/29/2012 11:42 AM, Paolo Carlini wrote:
>>> This might just be a matter of calling for_each_template_parm and
>>> returning 1 if we see any template parameter.
>> Good. Today I quickly tried something along these lines (see 'p'
>> attachment) and got some fails:
>
> Ah, well.  I guess for_each_template_parm doesn't look at the types of 
> declarations.
Just a few moments ago I noticed something interesting: if a NULL FN is 
passed to for_each_template_parm, it assumes a function which always 
returns 1, what we want when just searching for the first occurrence. 
Now, in practice, *no* front-code calls it like this! Thus, if we want, 
it's safe to tweak / extend for_each_template_parm_r for our purposes 
when !fn

And indeed, the attached passes the testsuite with no regressions ;)

I also want to remark that there is this kind of comment:

     case INDIRECT_REF:
     case COMPONENT_REF:
       /* If there's no type, then this thing must be some expression
      involving template parameters.  */
       if (!fn && !TREE_TYPE (t))
     return error_mark_node;
+      else if (!fn && for_each_template_parm (TREE_TYPE (t), fn,
+                          data, pfd->visited,
+                          pfd->include_nondeduced_p))
+    return error_mark_node;
(Continue reading)

Permalink | Reply | 16 comments |
headers
Mike Stump | 1 May 2012 02:39
Picon

Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)

I've been reading your patches...

On Apr 30, 2012, at 4:34 PM, DJ Delorie wrote:
> In going through the Apple test cases, I discovered one HUGE
> disadvantage to using __attribute__ to tag structures for bit reversal
> - it doesn't propogate.  I.e.:

This is why pragma exists.  :-)  Certainly, once you have the underlying support for an attribute, adding a
pragma is easier.
Permalink | Reply | 0 comments |
headers
H.J. Lu | 1 May 2012 02:55
Picon

Re: [PATCH] Fix predcom -fcompare-debug bug (PR debug/47684)

On Thu, Feb 10, 2011 at 1:44 PM, Jakub Jelinek <jakub <at> redhat.com> wrote:
> Hi!
>
> single_nonlooparound_use doesn't ignore debug uses, which results in
> -fcompare-debug failures.  Fixed thusly, bootstrapped/regtested on
> x86_64-linux and i686-linux, ok for trunk?
>
> 2011-02-10  Jakub Jelinek  <jakub <at> redhat.com>
>
>        PR debug/47684
>        * tree-predcom.c (single_nonlooparound_use): Ignore debug uses.
>

This may have caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53174

--

-- 
H.J.
Permalink | Reply | 0 comments |
headers
David Edelsohn | 1 May 2012 04:19
Picon

Re: [RS6000] Fix PR53038, cfa_restore out of order

On Thu, Apr 26, 2012 at 1:00 AM, Alan Modra <amodra <at> gmail.com> wrote:

>        PR target/53038
>        * config/rs6000/rs6000.c (load_lr_save, restore_saved_lr,
>        load_cr_save, add_crlr_cfa_restore): New functions.
>        (rs6000_restore_saved_cr): Rename to..
>        (restore_saved_cr): ..this.  Add cfa_restore notes for cr.
>        (rs6000_emit_epilogue): Use new functions.  Adjust condition
>        for emitting lr and cr cfa_restore.  Emit cfa_restores for fp
>        regs when using out-of-line restore only when shrink wrapping.

Okay.

Thanks, David
Permalink | Reply | 0 comments |
headers
Andrew Pinski | 1 May 2012 05:22

[PATCH] Improve COND_EXPR expansion

Hi,
  This patch improves the expansion of COND_EXPR into RTL, directly
using conditional moves.
I had to fix a bug in the x86 backend where emit_conditional_move
could cause a crash as we had a comparison mode of DImode which is not
handled by the 32bit part.  can_conditionally_move_p return true as we
had an SImode for the other operands.
Note other targets might need a similar fix as x86 had but I could not
test those targets and this is really the first time where
emit_conditional_move is being called with different modes for the
comparison and the other operands mode and the comparison mode is not
of the CC class.

The main reasoning to do this conversion early rather than wait for
ifconv as the resulting code is slightly better.  Also the compiler is
slightly faster.

OK?  Bootstrapped and tested on both mips64-linux-gnu (where it was
originally written for) and x86_64-linux-gnu.

Thanks,
Andrew Pinski

ChangeLog:
* expr.c (convert_tree_comp_to_rtx): New function.
(expand_expr_real_2): Try using conditional moves for COND_EXPRs if they exist.
* config/i386/i386.c (ix86_expand_int_movcc): Disallow comparison
modes of DImode for 32bits and TImode.

(Continue reading)






Permalink
| Reply
| 5 comments  
| 



  

  

  





headers


Jeff Law
 | 
1 May 2012 05:44






Picon

Favicon





Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI


On 04/30/2012 08:43 PM, Michael Hope wrote:
> On 1 May 2012 10:01, Jeff Law<law <at> redhat.com>  wrote:
>> On 04/30/2012 03:47 PM, Michael Hope wrote:
>>
>>>>>
>>>>> 2012-04-27  Michael Hope<michael.hope <at> linaro.org>
>>>>>
>>>>>        * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER): Pick the loader
>>>>>        using a spec rule.
>>>>>
>>>>
>>>> Michael,
>>>>
>>>> can you try this patch please.  It should make it possible to then
>>>> create linux-eabihf.h containing just
>>>>
>>>> #undef TARGET_DEFAULT_FLOAT_ABI
>>>> #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
>>>> #undef GLIBC_DYNAMIC_LINKER_DEFAULT
>>>> #define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
>>>>
>>>> Which is not quite as simple as leaving out the second re-define, but
>>>> pretty close.
>>>
>>>
>>> Hi Richard.  Your patch tests just fine.  I like it.  You could change
>>> the spec rule to the newer if-elseif-else form but that's a nit.
>>
>> So who owns creating the appropriate glibc patch now that we've got a good
>> gcc patch?

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Alan Modra
 | 
1 May 2012 06:17






Picon





Re: rs6000 toc reference rtl again


This revision splits the medium/large code model toc reference after
reload.  I expected this to be more difficult, but it turned out
surprisingly easy.  Besides creating the rtl that way, and tweaking
toc_relative_expr_p to match, it was just:  Move the 'R' constraint
handling out of various movsi/di instructions into a new instruction
that is split after reload, and modify legitimize_reload_address to
handle all the other splits inside MEMs.

Bootstrapped and regression tested powerpc-linux.  I also intend to
spec test this change.  Generated code has the expected improvements:
libstdc++.so saw a small reduction in code size due to removing silly
uses of call-saved regs to hold the high part of a toc reference.
OK to apply?

	* config/rs6000/predicates.md (input_operand): Don't match
	constant pool addresses.  Remove label_ref, high and plus from
	match_code list.  Remove redundant CONSTANT_P test.
	(splat_input_operand): Similarly update match_code list.
	(small_toc_ref): New predicate.
	* config/rs6000/rs6000-protos.h (toc_relative_expr_p): Update prototype.
	* config/rs6000/rs6000.c (tocrel_base, tocrel_offset): Make const.
	(legitimate_constant_pool_address_p): Move TARGET_TOC test and
	register checks to..
	(toc_relative_expr_p): ..here.  Add "strict" param.  Match new rtl
	generated by create_TOC_reference.
	(rs6000_legitimize_address): Update cerate_TOC_reference call.
	(rs6000_delegitimize_address): Handle new rtl for toc refs.
	(rs6000_cannot_force_const_mem, rs6000_find_base_term): Likewise.
	(use_toc_relative_ref): New function, split out from..
	(rs6000_emit_move): ..here.  Remove redundant tests.  Update

(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Jason Merrill
 | 
1 May 2012 06:28






Picon

Favicon





Re: [RFH / Patch] PR 51222


On 04/30/2012 07:37 PM, Paolo Carlini wrote:
> Thus, my question would be: is something like the below in the right
> direction? The alternate possibility I can see, would be basically
> redoing a slightly slimmed version of for_each_template_parm specialized
> for our needs (a few less conditionals)

I think either approach would be fine; I lean toward the first, but 
changing the name and adding a flag for clarity.  Changing the walking 
behavior based on fn being null is too subtle.

Jason







Permalink
| Reply
| 15 comments  
| 



  

  

  

  


  





    



Gmane