Re: [PATCH][4.3] Deprecate -ftrapv

[Paolo Bonzini]

Unless printing "This application has requested the Runtime to terminate
it in an unusual way." counts an issuing a contraint_error in Ada,
it seems to me that -ftrapv and Ada have differing requirements.
How can you portabilty and correctly generate a constraint_error if
the code generated by -ftrapv calls the C runtime function abort()?


The advantage of a GIMPLE implementation would be that you could use a 
langhook to insert the appropriate function call for overflowing 
computation.



With INTO I don't
see any way distignuish the SIGSEGV it generates on Linux from any of
the myriad other ways a SIGSEGV can be generated.


sc.eip == 0xCE (if I remember x86 opcodes well :-) as I'm going by heart...)

That's similar to how Java traps SIGFPEs and transform them to 
zero-divide exceptions, IIRC.


Paolo

Re: [PATCH][4.3] Deprecate -ftrapv

[Gabriel Paubert]

On Mon, Mar 03, 2008 at 01:38:01AM +0100, Andi Kleen wrote:
> [EMAIL PROTECTED] (Ross Ridge) writes:
> 
> > Robert Dewar writes:
> > >Yes, and that is what we would want for Ada, so I am puzzled by your
> > >sigh. All Ada needs to do is to issue a constraint_error exception,
> > >it does not need to know where the exception came from or why except
> > >in very broad detail.
> > 
> > Unless printing "This application has requested the Runtime to terminate
> > it in an unusual way." counts an issuing a contraint_error in Ada,
> > it seems to me that -ftrapv and Ada have differing requirements.
> > How can you portabilty and correctly generate a constraint_error if
> > the code generated by -ftrapv calls the C runtime function abort()?
> > On Unix-like systems you can catch SIGABRT, but even there how do you
> > tell that it didn't come from CTRL-\, a signal sent from a different
> > process, or abort() called fom some other context?  With INTO I don't
> > see any way distignuish the SIGSEGV it generates on Linux from any of
> > the myriad other ways a SIGSEGV can be generated.
> 
> Easy: The signal frame that is passed as an argument to the signal handler 
> has a trapno member than will contain 4 for INTO. The only other case where 
> it would contain 4 would be a explicit int 4

Yes, but it seems that INTO has been removed for 64 bit mode. In this
case the best solution is probably to insert conditional jumps (jo)
both in 32 and 64 bit mode for uniformity. PPC can only use conditional
jumps too, although the easily testable overflow bit is sticky so you 
don't need a test after every instuction. 

The code with conditional jumps is bigger but less dependant on the 
OS environment or of any user code trying to install its own signal 
handlers (especially for SIGSEGV which multiplexes so many exception
causes). The performance impact is probably small since the jumps
will normally be correctly predicted as not taken.

Gabriel

Re: [PATCH][4.3] Deprecate -ftrapv

[Andi Kleen]

> The code with conditional jumps is bigger but less dependant on the 
> OS environment or of any user code trying to install its own signal 
> handlers (especially for SIGSEGV which multiplexes so many exception
> causes). The performance impact is probably small since the jumps
> will normally be correctly predicted as not taken.

If you generate

jo 1f
int xxx
1: 

then it will normally default as predicted unless the CPU has dynamic 
information. This means you would get a branch misprediction first,
which is bad.

If you want to generate statically predicted branches you
would need to generate

jno 1

...

ret
1:  int xxx

with out-of-line int xxx. But with that it might be difficult to actually
find the original instruction pointer. e.g. the out of line label
cannot actually be in a cold section because dwarf2 cannot express that.
And even if it's in the same section as the rest of the function the
code flow might be hard to decipher afterwards.

e.g. I assume you would want to run C++ exception handlers
when this happens and for that surely the unwinder needs the original
IP as a starting point, doesn't it?

I think you would need to generate something like

0:
jno 1

...

ret
1:  lea 0b(%rip),%rdi
jmp overflow_abort

for each occurrence which would be quite a bit larger. 

-Andi

[RFA] optimizing predictable branches on x86

[Jan Hubicka]

Hi,
I had to tweak the testcase a bit to not compute minimum: GCC optimizes
this early into MIN_EXPR throwing away any profile information.  If we
get serious here we can maintain it via histogram, but I am not sure it
is worth the effort at least until IL is sanitized and expansion cleaned
up with tupple branch.

I also had to fix bug in branch prediction ignoring __builtin_expect of
any early inlined function and update your testcase to not use
__buliltin_expect in predictable case.
However this is what I get on AthlonXP:
 no deps,   predictable -- Ccode took  13.71ns per iteration
 no deps,   predictable -- cmov code took  13.83ns per iteration
 no deps,   predictable -- jmp  code took  13.94ns per iteration
 has deps,   predictable -- Ccode took  15.54ns per iteration
 has deps,   predictable -- cmov code took  22.21ns per iteration
 has deps,   predictable -- jmp  code took  16.55ns per iteration
 no deps, unpredictable -- Ccode took  13.99ns per iteration
 no deps, unpredictable -- cmov code took  13.76ns per iteration
 no deps, unpredictable -- jmp  code took  26.12ns per iteration
 has deps, unpredictable -- Ccode took  120.37ns per iteration
 has deps, unpredictable -- cmov code took  120.76ns per iteration
 has deps, unpredictable -- jmp  code took  165.82ns per iteration

The patch is quite SPEC neutral, saving 190Kb in FDO binaries.  Still I
think it is worthwhile to have especially because I do believe that all
the target COST predicates should be populated by hotness argument so we
get same results for -Os or -O2 with profile feeback specifying that
nothing is executed or if one marks all functions cold.
At the moment profile feedback with all functions not executed leads to
code smaller than -O2 but closer to -O2 than -Os so there is quite some
fruit here. With LTO or for codebases with more __builtin_expect and
cold hints like kernel or libstdc++ we can get a lot of this benefits
without FDO too.

The patch was bootstrapped/regtested i686-linux.  I can approve the i386
and prediction changes, however I will wait for approval for the
BRANCH_COST target macro change.
Note that bit irritating fact is that BRANCH_COST is querries during
expansion when we still don't have hotness information propagated (I
have separate patch to this I will update later this week).  The patch
uses at least the overall hotness info about the function that still
should make difference.  We however also use the check from frontend
folding that probably ought to go completely.

Honza

* optabs.c (expand_abs_nojump): Update BRANCH_COST call.
* fold-cost.c (LOGICAL_OP_NON_SHORT_CIRCUIT, fold_truthop): Likewise.
* dojump.c (do_jump): Likewise.
* ifcvt.c (MAX_CONDITIONAL_EXECUTE): Likewise.
(note-if_info): Add BRANCH_COST.
(noce_try_store_flag_constants, noce_try_addcc, 
noce_try_store_flag_mask,
noce_try_cmove_arith, noce_try_cmove_arith, noce_try_cmove_arith,
noce_find_if_block, find_if_case_1, find_if_case_2): Use compuated
branch cost.
* expr.h (BRANCH_COST): Update default.
* predict.c (predictable_edge_p): New function.
* expmed.c (expand_smod_pow2, expand_sdiv_pow2, emit_store_flag):
Update BRANCH_COST call.
* basic-block.h (predictable_edge_p): Declare.
* config/alpha/alpha.h (BRANCH_COST): Update.
* config/frv/frv.h (BRANCH_COST): Update.
* config/s390/s390.h (BRANCH_COST): Update.
* config/spu/spu.h (BRANCH_COST): Update.
* config/sparc/sparc.h (BRANCH_COST): Update.
* config/m32r/m32r.h (BRANCH_COST): Update.
* config/i386/i386.h (BRANCH_COST): Update.
* config/i386/i386.c (ix86_expand_int_movcc): Update use of BRANCH_COST.
* config/sh/sh.h (BRANCH_COST): Update.
* config/pdp11/pdp11.h (BRANCH_COST): Update.
* config/avr/avr.h (BRANCH_COST): Update.
* config/crx/crx.h (BRANCH_COST): Update.
* config/xtensa/xtensa.h (BRANCH_COST): Update.
* config/stormy16/stormy16.h (BRANCH_COST): Update.
* config/m68hc11/m68hc11.h (BRANCH_COST): Update.
* config/iq2000/iq2000.h (BRANCH_COST): Update.
* config/ia64/ia64.h (BRANCH_COST): Update.
* config/rs6000/rs6000.h (BRANCH_COST): Update.
* config/arc/arc.h (BRANCH_COST): Update.
* config/score/score.h (BRANCH_COST): Update.
* config/arm/arm.h (BRANCH_COST): Update.
* config/pa/pa.h (BRANCH_COST): Update.
* config/mips/mips.h (BRANCH_COST): Update.
* config/vax/vax.h (BRANCH_COST): Update.
* config/h8300/h8300.h (BRANCH_COST): Update.
* params.def (PARAM_PREDICTABLE_BRANCH_OUTCOME): New.
* doc/invoke.texi (predictable-branch-cost-outcome): Document.
* doc/tm.texi (BRANCH_COST): Update.
Index: optabs.c
===
*** optabs.c(revision 132800)
--- optabs.c(working co

Re: [RFA] optimizing predictable branches on x86

[Paolo Bonzini]

/* High branch cost, expand as the bitwise OR of the conditions.
 Do the same if the RHS has side effects, because we're effectively
 turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR.  */
!   if (BRANCH_COST (!optimize_size, false)>= 4
! || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))


What does BRANCH_COST (!optimize_save, ...) mean?

Related -- could you define auxiliary macros for BRANCH_COST (foo, false)?

Thanks!

Paolo

Re: [RFA] optimizing predictable branches on x86

[Jan Hubicka]

> 
> >/* High branch cost, expand as the bitwise OR of the conditions.
> >  Do the same if the RHS has side effects, because we're effectively
> >  turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR.  */
> >!   if (BRANCH_COST (!optimize_size, false)>= 4
> >!  || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
> 
> What does BRANCH_COST (!optimize_save, ...) mean?

This leaked here from older version of patch.  I updated it to
!   if (BRANCH_COST (cfun->function_frequency > FUNCTION_FREQUENCY_NORMAL,
!  false) >= 4
!
like it is handled in other cases.  Once we will get hotness info
available during expansion, we will simply pass it here.  
> 
> Related -- could you define auxiliary macros for BRANCH_COST (foo, false)?

But I can also hide the cfun->function_frequency trick in
DEFAULT_BRANCH_COST macro if it seems to help.  (in longer term I hope
they will all go away as expansion needs to be aware of hotness info
anyway)

Honza
> 
> Thanks!
> 
> Paolo

Re: [RFA] optimizing predictable branches on x86

[Jan Hubicka]

> But I can also hide the cfun->function_frequency trick in
> DEFAULT_BRANCH_COST macro if it seems to help.  (in longer term I hope
> they will all go away as expansion needs to be aware of hotness info
> anyway)

Well, it definitly helps. I originally hoped there will be fewer places
querying BRANCH_COST without profile info.  I am testing updated patch.

Honza

* optabs.c (expand_abs_nojump): Update BRANCH_COST call.
* fold-cost.c (LOGICAL_OP_NON_SHORT_CIRCUIT, fold_truthop): Likewise.
* dojump.c (do_jump): Likewise.
* ifcvt.c (MAX_CONDITIONAL_EXECUTE): Likewise.
(note-if_info): Add BRANCH_COST.
(noce_try_store_flag_constants, noce_try_addcc, 
noce_try_store_flag_mask,
noce_try_cmove_arith, noce_try_cmove_arith, noce_try_cmove_arith,
noce_find_if_block, find_if_case_1, find_if_case_2): Use compuated
branch cost.
* expr.h (BRANCH_COST): Update default.
(DEFAULT_BRANCH_COST): Define.
* predict.c (predictable_edge_p): New function.
* expmed.c (expand_smod_pow2, expand_sdiv_pow2, emit_store_flag):
Update BRANCH_COST call.
* basic-block.h (predictable_edge_p): Declare.
* config/alpha/alpha.h (BRANCH_COST): Update.
* config/frv/frv.h (BRANCH_COST): Update.
* config/s390/s390.h (BRANCH_COST): Update.
* config/spu/spu.h (BRANCH_COST): Update.
* config/sparc/sparc.h (BRANCH_COST): Update.
* config/m32r/m32r.h (BRANCH_COST): Update.
* config/i386/i386.h (BRANCH_COST): Update.
* config/i386/i386.c (ix86_expand_int_movcc): Update use of BRANCH_COST.
* config/sh/sh.h (BRANCH_COST): Update.
* config/pdp11/pdp11.h (BRANCH_COST): Update.
* config/avr/avr.h (BRANCH_COST): Update.
* config/crx/crx.h (BRANCH_COST): Update.
* config/xtensa/xtensa.h (BRANCH_COST): Update.
* config/stormy16/stormy16.h (BRANCH_COST): Update.
* config/m68hc11/m68hc11.h (BRANCH_COST): Update.
* config/iq2000/iq2000.h (BRANCH_COST): Update.
* config/ia64/ia64.h (BRANCH_COST): Update.
* config/rs6000/rs6000.h (BRANCH_COST): Update.
* config/arc/arc.h (BRANCH_COST): Update.
* config/score/score.h (BRANCH_COST): Update.
* config/arm/arm.h (BRANCH_COST): Update.
* config/pa/pa.h (BRANCH_COST): Update.
* config/mips/mips.h (BRANCH_COST): Update.
* config/vax/vax.h (BRANCH_COST): Update.
* config/h8300/h8300.h (BRANCH_COST): Update.
* params.def (PARAM_PREDICTABLE_BRANCH_OUTCOME): New.
* doc/invoke.texi (predictable-branch-cost-outcome): Document.
* doc/tm.texi (BRANCH_COST): Update.
Index: doc/tm.texi
===
*** doc/tm.texi (revision 132800)
--- doc/tm.texi (working copy)
*** value to the result of that function.  T
*** 5828,5836 
  are the same as to this macro.
  @end defmac
  
! @defmac BRANCH_COST
! A C expression for the cost of a branch instruction.  A value of 1 is
! the default; other values are interpreted relative to that.
  @end defmac
  
  Here are additional macros which do not specify precise relative costs,
--- 5828,5841 
  are the same as to this macro.
  @end defmac
  
! @defmac BRANCH_COST (@var{hot_p}, @var{predictable_p})
! A C expression for the cost of a branch instruction.  A value of 1 is the
! default; other values are interpreted relative to that. Parameter @var{hot_p}
! is true when the branch in question might be hot in the compiled program.  
When
! it is false, @code{BRANCH_COST} should be returning value optimal for code 
size
! rather then performance considerations.  @var{predictable_p} is true for well
! predictable branches. On many architectures the @code{BRANCH_COST} can be
! reduced then.
  @end defmac
  
  Here are additional macros which do not specify precise relative costs,
Index: doc/invoke.texi
===
*** doc/invoke.texi (revision 132800)
--- doc/invoke.texi (working copy)
*** to the hottest structure frequency in th
*** 6807,6812 
--- 6807,6816 
  parameter, then structure reorganization is not applied to this structure.
  The default is 10.
  
+ @item predictable-branch-cost-outcome
+ When branch is predicted to be taken with probability lower than this 
threshold
+ (in percent), then it is considered well predictable. The default is 10.
+ 
  @item max-crossjump-edges
  The maximum number of incoming edges to consider for crossjumping.
  The algorithm used by @option{-fcrossjumping} is @math{O(N^2)} in
Index: optabs.c
===
*** optabs.c(revision 132800)
--- optabs.c(working copy)
*** expand_abs_nojump (enum machine_mode mod
*** 3425,3431 
   value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
 

Re: [RFA] optimizing predictable branches on x86

[Jan Hubicka]

> > But I can also hide the cfun->function_frequency trick in
> > DEFAULT_BRANCH_COST macro if it seems to help.  (in longer term I hope
> > they will all go away as expansion needs to be aware of hotness info
> > anyway)
> 
> Well, it definitly helps. I originally hoped there will be fewer places
> querying BRANCH_COST without profile info.  I am testing updated patch.
> 
> Honza
Grr
>   
> !   if (GET_MODE_CLASS (mode) == MODE_INT && BRANCH_COST >= 2)
>   {
> rtx extended = expand_shift (RSHIFT_EXPR, mode, op0,
>  size_int (GET_MODE_BITSIZE (mode) - 1),
> --- 3425,3432 
>value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
>where W is the width of MODE.  */
>   
> !   if (GET_MODE_CLASS (mode) == MODE_INT
> !   && DEFAULT_BRANCH_COST)

Should be:
> !   if (GET_MODE_CLASS (mode) == MODE_INT
> !   && DEFAULT_BRANCH_COST >= 2)

Sorry for all the mess.  I know I should re-read patches even after
trivial mechanical changes :( I am re-testing with this fixed.

Honza

Re: [RFA] optimizing predictable branches on x86

[Nick Piggin]

On Monday 03 March 2008 22:38, Jan Hubicka wrote:
> Hi,
> I had to tweak the testcase a bit to not compute minimum: GCC optimizes
> this early into MIN_EXPR throwing away any profile information.  If we
> get serious here we can maintain it via histogram, but I am not sure it
> is worth the effort at least until IL is sanitized and expansion cleaned
> up with tupple branch.
>
> I also had to fix bug in branch prediction ignoring __builtin_expect of
> any early inlined function and update your testcase to not use
> __buliltin_expect in predictable case.

I guess you mean, not to use it in the _unpredictable_ case?


> However this is what I get on AthlonXP:
>  no deps,   predictable -- Ccode took  13.71ns per iteration
>  no deps,   predictable -- cmov code took  13.83ns per iteration
>  no deps,   predictable -- jmp  code took  13.94ns per iteration
>  has deps,   predictable -- Ccode took  15.54ns per iteration
>  has deps,   predictable -- cmov code took  22.21ns per iteration
>  has deps,   predictable -- jmp  code took  16.55ns per iteration
>  no deps, unpredictable -- Ccode took  13.99ns per iteration
>  no deps, unpredictable -- cmov code took  13.76ns per iteration
>  no deps, unpredictable -- jmp  code took  26.12ns per iteration
>  has deps, unpredictable -- Ccode took  120.37ns per iteration
>  has deps, unpredictable -- cmov code took  120.76ns per iteration
>  has deps, unpredictable -- jmp  code took  165.82ns per iteration

At least for the __builtin_expect case, I guess this is showing
that gcc now does exactly what we'd like of it.


> The patch is quite SPEC neutral, saving 190Kb in FDO binaries.  Still I
> think it is worthwhile to have especially because I do believe that all
> the target COST predicates should be populated by hotness argument so we
> get same results for -Os or -O2 with profile feeback specifying that
> nothing is executed or if one marks all functions cold.
> At the moment profile feedback with all functions not executed leads to
> code smaller than -O2 but closer to -O2 than -Os so there is quite some
> fruit here. With LTO or for codebases with more __builtin_expect and
> cold hints like kernel or libstdc++ we can get a lot of this benefits
> without FDO too.

I hope so too. For the kernel we have some parts where
__builtin_expect is used quite a lot and noticably helps, and could
help even more if we cut down the use of cmov too. I guess on
architectures with even more predictated instructions it could be
even more useful too.

Thanks,
Nick

Re: [RFA] optimizing predictable branches on x86

[Jan Hubicka]

> On Monday 03 March 2008 22:38, Jan Hubicka wrote:
> > Hi,
> > I had to tweak the testcase a bit to not compute minimum: GCC optimizes
> > this early into MIN_EXPR throwing away any profile information.  If we
> > get serious here we can maintain it via histogram, but I am not sure it
> > is worth the effort at least until IL is sanitized and expansion cleaned
> > up with tupple branch.
> >
> > I also had to fix bug in branch prediction ignoring __builtin_expect of
> > any early inlined function and update your testcase to not use
> > __buliltin_expect in predictable case.
> 
> I guess you mean, not to use it in the _unpredictable_ case?

Sure ;)
> 
> I hope so too. For the kernel we have some parts where
> __builtin_expect is used quite a lot and noticably helps, and could
> help even more if we cut down the use of cmov too. I guess on
> architectures with even more predictated instructions it could be
> even more useful too.

Looking at kernel's __builtin_expect usage, I think we ought to do a lot
better on taking the hints than we do now.  In particular we should
be able to derrive more from
 likely (test1||test2) and likely (test1&&test2)
and similar cases.  I will try to prepare patch for this later too.

I am glad to hear that __builtin_expect does useful job for you and
would be interested knowing cases where it does not.

Honza
> 
> Thanks,
> Nick

Re: Possible GCC 4.3 driver regression caused by your patch

[Hans-Peter Nilsson]

On Sun, 2 Mar 2008, Greg Schafer wrote:
> Hi Carlos and Mark,
>
> Your "Relocated compiler should not look in $prefix" patch here:
>
> http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
>
> appears to have caused a regression in my GCC 4.3 testing.

So *now* I know why my cross-test setup to (non-sysrooted)
cris-axis-linux-gnu have trouble finding startfiles and
pre-installed include files!  Thanks!  It seems Carlos' fix for
the testsuite, has some flaw I'll look into.  At the very least,
cutnpasting commands from the dejagnu .log files don't work;
there's some environment variable (more than just
GCC_EXEC_PREFIX, AFAICT).  And some testsuites (forgot, maybe it
was libgomp?) need to be adjusted too.

> In summary, there is a small window *during the GCC build itself* where GCC
> does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is
> called to build the target libraries, the startfiles in $prefix/lib are not
> used. Instead, the startfiles from the host's /usr/lib are used which breaks
> my build. Note that the problem seems to rectify itself once the just-built
> GCC is installed into $prefix.

That's a problem.  Maybe it can be fixed by the build machinery
e.g. setting GCC_EXEC_PREFIX and friends at the time.  I don't
think gcc fallback-peeking into the base --prefix= tree (unless
specifically told) is the solution.

brgds, H-P

Re: [RFA] optimizing predictable branches on x86

[Nick Piggin]

On Tuesday 04 March 2008 00:01, Jan Hubicka wrote:
> > On Monday 03 March 2008 22:38, Jan Hubicka wrote:

> > I hope so too. For the kernel we have some parts where
> > __builtin_expect is used quite a lot and noticably helps, and could
> > help even more if we cut down the use of cmov too. I guess on
> > architectures with even more predictated instructions it could be
> > even more useful too.
>
> Looking at kernel's __builtin_expect usage, I think we ought to do a lot
> better on taking the hints than we do now.  In particular we should
> be able to derrive more from
>  likely (test1||test2) and likely (test1&&test2)
> and similar cases.  I will try to prepare patch for this later too.

Yes, it is used for multiple conditions like that. I would also like it
to work nicely for:

if (likely(test1) lop unlikely(test2))

It may seem unusual, but I have used it before, and also often the
__builtin_expect is hidden inside macros/inlines.

Re: [RFA] optimizing predictable branches on x86

[Paolo Bonzini]

I hope so too. For the kernel we have some parts where
__builtin_expect is used quite a lot and noticably helps, and could
help even more if we cut down the use of cmov too. I guess on
architectures with even more predictated instructions it could be
even more useful too.

Looking at kernel's __builtin_expect usage, I think we ought to do a lot
better on taking the hints than we do now.  In particular we should
be able to derrive more from
 likely (test1||test2) and likely (test1&&test2)
and similar cases.  I will try to prepare patch for this later too.


Right now it does

  1. __b_e (a && b, 1) => __b_e (a, 1) && __b_e (b, 1)
  2. __b_e (a && b, 0) => a && __b_e (b, 0)
  3. __b_e (a || b, 1) => a || __b_e (b, 1)
  4. __b_e (a || b, 0) => __b_e (a, 0) || __b_e (b, 0)

See http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00410.html

Paolo

Invalid address after reload

[Vander Aa Tom]

Hello,

I'd like to get some help on a new port I'm trying to put together. The
problem seems to be in the reload phase (where else? :-) ).

The register 176 is spilled in the following instruction (dump just
before reload):

(insn 364 363 365 57 decode_macroblock.c:280 (set (mem:SI (plus:SI
(reg/v/f:SI 176 [ dc_dct_pred ])
(const_int 8 [0x8])) [0 S4 A32])
(const_int 0 [0x0])) 12 {movsi} (nil))

This changes the instruction to: 

(insn 364 363 365 57 decode_macroblock.c:280 (set (mem:SI (plus:SI
(mem/f/c/i:SI (plus:SI (reg/f:SI 141 mac:AP)
(const_int 8 [0x8])) [0 dc_dct_pred+0 S4 A32])
(const_int 8 [0x8])) [0 S4 A32])
(const_int 0 [0x0])) 12 {movsi} (nil))

This fails the "legitimate address" constraint since I'm not allowing a
mem inside another mem.
Thus I get this error after the reload:

decode_macroblock.c:324: error: insn does not satisfy its constraints:
(insn 364 363 365 57 decode_macroblock.c:280 (set (mem:SI (plus:SI
(mem/f/c/i:SI (plus:SI (reg/f:SI 141 mac:AP)
(const_int 8 [0x8])) [0 dc_dct_pred+0 S4 A32])
(const_int 8 [0x8])) [0 S4 A32])
(const_int 0 [0x0])) 12 {movsi} (nil))
decode_macroblock.c:324: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:395

The relevant part of the .md-file looks like this:

(define_mode_iterator GPR [HI SI QI])
(define_mode_attr size [(HI "c2") (SI "i") (QI "c")])
(define_insn "mov"
  [(set (match_operand:GPR 0 "nonimmediate_operand" "=r,=m,=m,=r")
(match_operand:GPR 1 "general_operand" "m,r,i,g"))]
  ""
  { 
switch (which_alternative)
{
case 0:
  return "ld_\t%0 <- %1";
case 1:
  return "st_\t%0, %1";
case 2:
  return "st_\t%0, %1";
case 3:
  return "mov\t%0 <- %1";
default:
  gcc_unreachable();
}
  }
)

What could be the problem? Where should I start looking?

I am using a checkout from the trunk from somewhere last week.

Thanks for the help,
Tom

Re: Possible GCC 4.3 driver regression caused by your patch

[Hans-Peter Nilsson]

On Mon, 3 Mar 2008, Hans-Peter Nilsson wrote:
> cutnpasting commands from the dejagnu .log files don't work;
> there's some environment variable (more than just
> GCC_EXEC_PREFIX, AFAICT).

Wrong; I just missed the terminating / as in
env GCC_EXEC_PREFIX=/home/hp/crisprefix/lib/gcc/
(Should be dumped in the various .logs; film at 11.)

>  And some testsuites (forgot, maybe it
> was libgomp?) need to be adjusted too.

and libmudflap and all other testsuites using the just-built
gcc.  Hm.

Maybe we should, in the toplevel Makefile, set e.g.
 'GCC_FOR_TARGET=env GCC_EXEC_PREFIX=/home/hp/crisprefix/lib/gcc/ 
$real_gcc_for_target'
?

brgds, H-P

Stan Shebs appointed maintainer for Darwin, Objc and Objc++

[Kaveh R. GHAZI]

I'm pleased to announce that Stan Shebs has been (re)appointed as a
maintainer for Darwin, Objc and Objc++ by the GCC Steering Committee.
Please join me in congratulating Stan on his return to these roles.

(Stan please update your entries in these areas of the MAINTAINERS file
accordingly, and happy hacking!)

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: [RFA] optimizing predictable branches on x86

[Jan Hubicka]

> 
> >>>I hope so too. For the kernel we have some parts where
> >>>__builtin_expect is used quite a lot and noticably helps, and could
> >>>help even more if we cut down the use of cmov too. I guess on
> >>>architectures with even more predictated instructions it could be
> >>>even more useful too.
> >>Looking at kernel's __builtin_expect usage, I think we ought to do a lot
> >>better on taking the hints than we do now.  In particular we should
> >>be able to derrive more from
> >> likely (test1||test2) and likely (test1&&test2)
> >>and similar cases.  I will try to prepare patch for this later too.
> 
> Right now it does
> 
>   1. __b_e (a && b, 1) => __b_e (a, 1) && __b_e (b, 1)
>   2. __b_e (a && b, 0) => a && __b_e (b, 0)
>   3. __b_e (a || b, 1) => a || __b_e (b, 1)
>   4. __b_e (a || b, 0) => __b_e (a, 0) || __b_e (b, 0)
> 
> See http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00410.html

Andrew pointed me to that patch few weeks ago.  While we do it as part
of fold, we still miss some cases that results from inlining and other
transfromations.  We probably should be able to perform it at gimple
during fold_builtins pass where current fold behaviour does not match.
Recently I've made simple patch to dump __builtin_expects that are
complettely ignored and this seemed surprisingly common case even with
folder on place.

Other cases was missed fold oppurtunities like __builtin_expect (a==5,1)
and (a+5,1) that if applied to all uses of a dominated by the expect
call would lead to useful predictions but not with our simplified
handling.

Honza
> 
> Paolo

Release planning for GCC 4.4?

[Andrey Belevantsev]

Hello,

As GCC 4.3 is almost out of the door, I thought it possible to ask 
whether there will be a release plan for GCC 4.4 similar to the ones for 
previous releases.  The reason I'm asking is that myself and my 
colleagues are working on preparing the selective scheduler branch for 
inclusion in mainline.  We'll need another month for the final cleanup 
and compile time tuning of the scheduler, so we plan to submit it 
sometimes in April.  I would like to avoid any possible conflicts with 
other projects (though this work is unlikely to conflict with others I 
know of, except maybe Vlad's register allocator), and I think that the 
idea of a release plan used for previous development cycles worked quite 
nicely.


Thanks, Andrey

Re: Release planning for GCC 4.4?

[Richard Guenther]

On Mon, Mar 3, 2008 at 5:17 PM, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
> Hello,
>
>  As GCC 4.3 is almost out of the door, I thought it possible to ask
>  whether there will be a release plan for GCC 4.4 similar to the ones for
>  previous releases.  The reason I'm asking is that myself and my
>  colleagues are working on preparing the selective scheduler branch for
>  inclusion in mainline.  We'll need another month for the final cleanup
>  and compile time tuning of the scheduler, so we plan to submit it
>  sometimes in April.  I would like to avoid any possible conflicts with
>  other projects (though this work is unlikely to conflict with others I
>  know of, except maybe Vlad's register allocator), and I think that the
>  idea of a release plan used for previous development cycles worked quite
>  nicely.

I will post a rough schedule for 4.4 shortly together with an updated
status report.

Richard.

Re: Stan Shebs appointed maintainer for Darwin, Objc and Objc++

[Stan Shebs]

Kaveh R. GHAZI wrote:

I'm pleased to announce that Stan Shebs has been (re)appointed as a
maintainer for Darwin, Objc and Objc++ by the GCC Steering Committee.
Please join me in congratulating Stan on his return to these roles.

(Stan please update your entries in these areas of the MAINTAINERS file
accordingly, and happy hacking!)
  
Thanks! I'm still getting up to speed on open issues for Darwin and 
Obj-C/C++ support, so people should feel free to ping me about anything 
that has been getting overlooked.


Stan
[EMAIL PROTECTED]

start.encap target in gcc/Makefile.in

[Basile STARYNKEVITCH]

Hello All,

I"m adding a new makefile target into gcc/Makefile.in (rev 132840) 
melt.encap to copy the required header files (see the 
http://gcc.gnu.org/ml/gcc/2008-02/msg00673.html thread)


I just committed it, with start.encap depending also on melt.encap

and the gcc/Makefile.in rule for melt.encap does not seen to fire when I 
make in the build directory.


What did I wrote wrong?

What is the right way to add a new side-effect to the compilation?

Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: start.encap target in gcc/Makefile.in

[Basile STARYNKEVITCH]

Basile STARYNKEVITCH wrote:

Hello All,

I"m adding a new makefile target into gcc/Makefile.in (rev 132840) 
melt.encap to copy the required header files (see the 
http://gcc.gnu.org/ml/gcc/2008-02/msg00673.html thread)


I just committed it, with start.encap depending also on melt.encap

and the gcc/Makefile.in rule for melt.encap does not seen to fire when I 
make in the build directory.


What did I wrote wrong?

What is the right way to add a new side-effect to the compilation?

Regards.


Sorry for the noise. It is working apparently... (I'm not sure to 
understand why).


Regards.


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [PATCH][4.3] Deprecate -ftrapv

[Ian Lance Taylor]

Richard Guenther <[EMAIL PROTECTED]> writes:

> I believe at last years summit Ian told me that someone at google was
> working on this -- Ian is this still true?

Unfortunately that person moved on to other projects.

Ian

Re: [PATCH][4.3] Deprecate -ftrapv

[Ross Ridge]

Ross Ridge:
>With INTO I don't see any way distignuish the SIGSEGV it generates on
>Linux from any of the myriad other ways a SIGSEGV can be generated.

Paolo Bonzini writes:
>sc.eip == 0xCE (if I remember x86 opcodes well :-) as I'm going by heart...)

The INTO instruction generates a trap exception, just like INT 4 would, so
the return address on the stack points to the instruction after the INTO.

>That's similar to how Java traps SIGFPEs and transform them to
>zero-divide exceptions, IIRC.

Floating point exceptions are fault exceptions so the return address
points to the faulting instruction.

At the risk of my curiousity getting me into more trouble, could any
one explain to me how to access these "eip" and "trapno" members from
a signal handler on Linux?  I can't find any relevent documention with
man nor Google.

Ross Ridge

Google Summer of Code 2008

[Doug Gregor]

I see that it is time to submit applications to be a mentor
organization for the Google Summer of Code. I've updated the GSoC wiki
page at:

  http://gcc.gnu.org/wiki/SummerOfCode

with a class of projects I'm interested in; others should do the same.

I'll be happy to mentor C++0x projects for GCC, should any
applications for those projects come in.

Who is responsible for actually submitting GCC's application to GSoC,
and who has done so in the past?

  - Doug

Google Summer of Code 2008

[Doug Gregor]

I see that it is time to submit applications to be a mentor
organization for the Google Summer of Code. I've updated the GSoC wiki
page at:

  http://gcc.gnu.org/wiki/SummerOfCode

with a class of projects I'm interested in; others should do the same.

I'll be happy to mentor C++0x projects for GCC, should any
applications for those projects come in.

Who is responsible for actually submitting GCC's application to GSoC,
and who has done so in the past?

  - Doug

GCC 4.3.0 Status Report (2008-03-03)

[Richard Guenther]

Status
==

GCC 4.3.0rc2 is out and we are not expecting further delay of the
4.3.0 release.  The trunk is in stage1 since two weeks.

Branch status
=

We are getting additional bugreports in of which none is going
to block the 4.3.0 release.

Priority #  Change from Last Report
--  ---
P1   0  +- 0
P2  91  + 17
P3   8  + 4
--  ---
Total   99  + 21

it is too early to collect quality data on the trunk.

We expect the above numbers to improve again after the release of
GCC 4.3.0 which is due to the end of this week.

Previous Reports

http://gcc.gnu.org/ml/gcc/2008-02/msg00237.html
http://gcc.gnu.org/ml/gcc/2008-02/msg00389.html

GCC 4.4 schedule

[Richard Guenther]

As you know we have been in stage1 for about two weeks now.  Thus it
is time to present a rough schedule of GCC 4.4 and the projects we
are aware of trying to make that release.

GCC 4.4 stage1 started at Feb 18th and will end two month after that,
Apr 21st.  Stage2 will end two month after that, Jun 23th.  After
stage3 ends at Aug 18th we will go into regresion and documentation
fixes only and process with releasing after reaching zero P1 regressions.

Sofar the theory.  There are several branches thriving to merge during
the current stage1.  One of it has elected itself to be special and be
merged last, at the very end of stage1 - the tuples branch.  All other
branches are free to merge once they reach the common criteria for
branch merging.  Please announce branch merges early; the trunk will
be frozen for 24h before a scheduled branch merge to allow for merging
from trunk, bootstrapping and testing on multiple primary platforms and
finally merging the branch.

I am aware of the following merge candidates: the LTO branch, the
incremental compiler branch, the selective scheduling branch, the
YARA branch and of course the tuples branch.  Please announce those
I forgot so they have the chance of getting reviewed properly in time.

We hope you have a pleasant development during the GCC 4.4 series.

Thanks,
Richard.

Re: Google Summer of Code 2008

[Manuel López-Ibáñez]

They will be accepting organizations applications only until March 12.
http://code.google.com/soc/2008/

Cheers,

Manuel.

On 03/03/2008, Doug Gregor <[EMAIL PROTECTED]> wrote:
> I see that it is time to submit applications to be a mentor
>  organization for the Google Summer of Code. I've updated the GSoC wiki
>  page at:
>
>   http://gcc.gnu.org/wiki/SummerOfCode
>
>  with a class of projects I'm interested in; others should do the same.
>
>  I'll be happy to mentor C++0x projects for GCC, should any
>  applications for those projects come in.
>
>  Who is responsible for actually submitting GCC's application to GSoC,
>  and who has done so in the past?
>
>   - Doug
>

Re: GCC 4.4 schedule

[Jakub Jelinek]

On Mon, Mar 03, 2008 at 10:08:57PM +0100, Richard Guenther wrote:
> I am aware of the following merge candidates: the LTO branch, the
> incremental compiler branch, the selective scheduling branch, the
> YARA branch and of course the tuples branch.  Please announce those
> I forgot so they have the chance of getting reviewed properly in time.

gomp-3_0-branch

Jakub

compiler slowdown in 4.3 development

[Bruno Haible]

Hi,

Here's a case of a function whose compilation with -O2 -g (the default with
autoconf) on Linux/x86 has slowed down by 67% since the 4.2.2 release.

$ time gcc -c -O2 -g -Wall sha512.c

Measured user time.

gcc 3.2.2   42.2 sec
gcc 3.3.6   71 sec
gcc 3.4.4   29.0 sec
gcc 4.0.4   24.5 sec
gcc 4.1.2   12.6 sec
gcc 4.2.2   10.7 sec
gcc 4.3-2008021517.9 sec

Bruno

/* sha512.c - Functions to compute SHA512 and SHA384 message digest of files or
   memory blocks according to the NIST specification FIPS-180-2.

   Copyright (C) 2005, 2006, 2008 Free Software Foundation, Inc.

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see .  */

/* Written by David Madore, considerably copypasting from
   Scott G. Miller's sha1.c
*/

typedef unsigned int size_t;
extern void *memcpy (void *, const void *, size_t);

typedef unsigned long long u64;
#define u64hilo(hi, lo) ((u64) (((u64) (hi) << 32) + (lo)))
#define u64init(hi, lo) u64hilo (hi, lo)
#define u64lo(x) ((u64) (x))
#define u64lt(x, y) ((x) < (y))
#define u64and(x, y) ((x) & (y))
#define u64or(x, y) ((x) | (y))
#define u64xor(x, y) ((x) ^ (y))
#define u64plus(x, y) ((x) + (y))
#define u64shl(x, n) ((x) << (n))
#define u64shr(x, n) ((x) >> (n))
#define u64rol(x, n) u64or (u64shl (x, n), u64shr (x, 64 - n))

/* Structure to save state of computation between the single steps.  */
struct sha512_ctx
{
  u64 state[8];

  u64 total[2];
  size_t buflen;
  u64 buffer[32];
};

#define SWAP(n) \
u64or (u64or (u64or (u64shl (n, 56),\
			 u64shl (u64and (n, u64lo (0xff00)), 40)),	\
		  u64or (u64shl (u64and (n, u64lo (0x00ff)), 24),	\
			 u64shl (u64and (n, u64lo (0xff00)),  8))),	\
	   u64or (u64or (u64and (u64shr (n,  8), u64lo (0xff00)),	\
			 u64and (u64shr (n, 24), u64lo (0x00ff))),	\
		  u64or (u64and (u64shr (n, 40), u64lo (0xff00)),	\
			 u64shr (n, 56

#define BLOCKSIZE 4096

/* Copy the value from V into the memory location pointed to by *CP,
   If your architecture allows unaligned access, this is equivalent to
   * (__typeof__ (v) *) cp = v  */
static inline void
set_uint64 (char *cp, u64 v)
{
  memcpy (cp, &v, sizeof v);
}

/* --- Code below is the primary difference between sha1.c and sha512.c --- */

/* SHA512 round constants */
#define K(I) sha512_round_constants[I]
static u64 const sha512_round_constants[80] = {
  u64init (0x428a2f98, 0xd728ae22), u64init (0x71374491, 0x23ef65cd),
  u64init (0xb5c0fbcf, 0xec4d3b2f), u64init (0xe9b5dba5, 0x8189dbbc),
  u64init (0x3956c25b, 0xf348b538), u64init (0x59f111f1, 0xb605d019),
  u64init (0x923f82a4, 0xaf194f9b), u64init (0xab1c5ed5, 0xda6d8118),
  u64init (0xd807aa98, 0xa3030242), u64init (0x12835b01, 0x45706fbe),
  u64init (0x243185be, 0x4ee4b28c), u64init (0x550c7dc3, 0xd5ffb4e2),
  u64init (0x72be5d74, 0xf27b896f), u64init (0x80deb1fe, 0x3b1696b1),
  u64init (0x9bdc06a7, 0x25c71235), u64init (0xc19bf174, 0xcf692694),
  u64init (0xe49b69c1, 0x9ef14ad2), u64init (0xefbe4786, 0x384f25e3),
  u64init (0x0fc19dc6, 0x8b8cd5b5), u64init (0x240ca1cc, 0x77ac9c65),
  u64init (0x2de92c6f, 0x592b0275), u64init (0x4a7484aa, 0x6ea6e483),
  u64init (0x5cb0a9dc, 0xbd41fbd4), u64init (0x76f988da, 0x831153b5),
  u64init (0x983e5152, 0xee66dfab), u64init (0xa831c66d, 0x2db43210),
  u64init (0xb00327c8, 0x98fb213f), u64init (0xbf597fc7, 0xbeef0ee4),
  u64init (0xc6e00bf3, 0x3da88fc2), u64init (0xd5a79147, 0x930aa725),
  u64init (0x06ca6351, 0xe003826f), u64init (0x14292967, 0x0a0e6e70),
  u64init (0x27b70a85, 0x46d22ffc), u64init (0x2e1b2138, 0x5c26c926),
  u64init (0x4d2c6dfc, 0x5ac42aed), u64init (0x53380d13, 0x9d95b3df),
  u64init (0x650a7354, 0x8baf63de), u64init (0x766a0abb, 0x3c77b2a8),
  u64init (0x81c2c92e, 0x47edaee6), u64init (0x92722c85, 0x1482353b),
  u64init (0xa2bfe8a1, 0x4cf10364), u64init (0xa81a664b, 0xbc423001),
  u64init (0xc24b8b70, 0xd0f89791), u64init (0xc76c51a3, 0x0654be30),
  u64init (0xd192e819, 0xd6ef5218), u64init (0xd6990624, 0x5565a910),
  u64init (0xf40e3585, 0x5771202a), u64init (0x106aa070, 0x32bbd1b8),
  u64init (0x19a4c116, 0xb8d2d0c8), u64init (0x1e376c08, 0x5141ab53),
  u64init (0x2748774c, 0xdf8eeb99), u64init (0x34b0bcb5, 0xe19b48a8),
  u64init (0x391c0cb3, 0xc5c95a63), u64init (0x4ed8aa4a, 0xe3418acb),
  u64init (0x5b9cca4f, 0x7763e373), u64init (0x682e6ff3, 0xd6b2b8a3),
  u64init (0x748f82ee, 0x5defb2fc), u64init (0x78a5636f, 0x43172

Re: new regression on 4.3.0 branch

[DJ Delorie]

> >  PASS-FAIL: gcc.c-torture/execute/980707-1.c execution,  -O3 
> > -fomit-frame-pointer
>
> Can you pin-point the patch that caused this and investigate what is
> going wrong?

Looks like a schroedinbug.  The .s file from before ("pass") is
obviously wrong, but the right value *happens* to be in the right
register at the right time to cause the test to pass.

The non-related patch perturbed the compiler just enough to alter the
way the program was optimized (strange but true), which changed the
"just happens" into a "doesn't".

gcc-4.1-20080303 is now available

[gccadmin]

Snapshot gcc-4.1-20080303 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080303/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 132843

You'll find:

gcc-4.1-20080303.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20080303.tar.bz2 C front end and core compiler

gcc-ada-4.1-20080303.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20080303.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20080303.tar.bz2  C++ front end and runtime

gcc-java-4.1-20080303.tar.bz2 Java front end and runtime

gcc-objc-4.1-20080303.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20080303.tar.bz2The GCC testsuite

Diffs from 4.1-20080225 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH][4.3] Deprecate -ftrapv

[Eric Botcazou]

> Well let's see .. we (AdaCore) will try to focus more attention on this
> to evaluate whether it is feasible to get this feature working well
> enough to use in GNAT.

We already did that several times: -ftrapv is too broken to be used for Ada.

-- 
Eric Botcazou

Re: compiler slowdown in 4.3 development

[David Daney]

Bruno Haible wrote:

Hi,

Here's a case of a function whose compilation with -O2 -g (the default with
autoconf) on Linux/x86 has slowed down by 67% since the 4.2.2 release.

$ time gcc -c -O2 -g -Wall sha512.c

Measured user time.

gcc 3.2.2   42.2 sec
gcc 3.3.6   71 sec
gcc 3.4.4   29.0 sec
gcc 4.0.4   24.5 sec
gcc 4.1.2   12.6 sec
gcc 4.2.2   10.7 sec
gcc 4.3-2008021517.9 sec



Was it configured with --enable-checking=release?  You really should do 
that if you want a fair comparison.


David Daney

Re: [PATCH][4.3] Deprecate -ftrapv

[Eric Botcazou]

> Perhaps if the current implementation is too broken, that might be
> the most constructive approach ...

That's my opinion and the current state of affairs is a hindrance, so I think 
that -ftrapv should be reimplemented from scratch if GCC is to be serious 
about overflow checking.  Of course we would be happy to lend a hand. :-)

-- 
Eric Botcazou

Re: compiler slowdown in 4.3 development

[Bruno Haible]

> Was it configured with --enable-checking=release?

No it wasn't.

Bruno

Re: Invalid address after reload

[Jim Wilson]

Vander Aa Tom wrote:

This fails the "legitimate address" constraint since I'm not allowing a
mem inside another mem.


Sounds like a REG_OK_STRICT bug.  GO_IF_LEGITIMATE_ADDRESS should accept 
a pseudo-reg when !REG_OK_STRICT, and should reject a pseudo-reg when 
REG_OK_STRICT.  In reload, an unallocated pseudo-reg is really a memory 
reference in disguise.  This is typically handled by having two 
different versions of macros like REG_OK_FOR_BASE_P. 
GO_IF_LEGITIMATE_ADDRESS then uses these macros for its checks.  This is 
a common mistake in first time ports.


See also strict_memory_address_p in reload.c, and memory_address_p in 
recog.c.


Jim

atomic accesses

[Segher Boessenkool]

The Linux kernel, and probably some user-space applications and 
libraries

as well, depend on GCC guaranteeing (a variant of) the following:

"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction whenever possible"

and it seems the current compiler actually does work like this.

I propose we add this text to the GCC manual (where?), so at least they
are right if/when they blame us for breaking that promise :-)

Comments?  Flames?


Segher

Re: atomic accesses

[David Daney]

Segher Boessenkool wrote:

The Linux kernel, and probably some user-space applications and libraries
as well, depend on GCC guaranteeing (a variant of) the following:

"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction whenever possible"

and it seems the current compiler actually does work like this.

I propose we add this text to the GCC manual (where?), so at least they
are right if/when they blame us for breaking that promise :-)

Comments?  Flames?



It seems like a good idea.

This seems somewhat like other issues we have dealt with concerning 
thread safety.  Perhaps an entire section addressing code generation 
issues related to correct multi-threaded semantics.


David Daney

Copy constructor access check while initializing a reference

[Peter A. Felvegi]

hello,

i've found this in the known non-bugs list
(http://gcc.gnu.org/bugs.html#known), after running into the issue. gcc
3.4-4.2 gives a compile error, but 4.3 compiles it. is this a
regression, or the rules were relaxed somewhat (c++0x?) ? i checked the
changelog, but couldn't find any relevant entries there.

could someone explain the rationale behind this extra access check,
please? i'm puzzled, since the copy ctor is not needed and is not called
from the generated code.

regards, p




signature.asc
Description: OpenPGP digital signature

Re: atomic accesses

[Segher Boessenkool]

This seems somewhat like other issues we have dealt with concerning 
thread safety.  Perhaps an entire section addressing code generation 
issues related to correct multi-threaded semantics.


I like that idea.  But, we need to decide what those correct semantics 
_are_.
Or we can wait for that to be standardised.  We should decide 
*something*

though, not just wait forever, IMHO.


Segher

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Eric Botcazou wrote:

Well let's see .. we (AdaCore) will try to focus more attention on this
to evaluate whether it is feasible to get this feature working well
enough to use in GNAT.


We already did that several times: -ftrapv is too broken to be used for Ada.


In its current form, that's true, the question is what would it take for
-ftrapv to be usable. The requirements for a useful feature for C
debugging and a feature to implement required overflow checking in
Ada are not that far apart.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Eric Botcazou wrote:

Perhaps if the current implementation is too broken, that might be
the most constructive approach ...


That's my opinion and the current state of affairs is a hindrance, so I think 
that -ftrapv should be reimplemented from scratch if GCC is to be serious 
about overflow checking.  Of course we would be happy to lend a hand. :-)


Reimplementing from scratch certainly might make sense if it is a
better path. Presumably some of the library routines to be used when
there is no hardware assist could be rescued.

Re: atomic accesses

[Robert Dewar]

Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and 
libraries

as well, depend on GCC guaranteeing (a variant of) the following:

"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction whenever possible"

and it seems the current compiler actually does work like this.


Seems a pity to have the bit-field exception here, why is it there?


I propose we add this text to the GCC manual (where?), so at least they
are right if/when they blame us for breaking that promise :-)

Comments?  Flames?


Segher

Swing replacements

[geodejerry]

Pardon my intrusion, I suspect that you are not the right 
people to ask, but I'm hoping that you might know whom I 
_should_ be asking. 

In an Excelsior article by Dmitry Leskov on converting Java 
code to a Windows .exe file, (or maybe on a page I reached 
from that page), I read that while the basic Java classes 
_can_ be packaged as a .exe, Java does not allow its awt or 
Swing classes to be so packaged (I hope I've got this right).

I have a stand-alone, non-Web-based app. that I'd like to 
distribute as a .exe with some database files, to a layman 
audience, and I'd like to avoid issues of JRE distribution and 
compatibility, etc. So I'm hoping someone, somewhere, has 
written a replacement framework for Java's GUI classes. Can 
you by any chance point me in such a direction?

Thank you very much, 
Jerome Brown

Re: atomic accesses

[Segher Boessenkool]

The Linux kernel, and probably some user-space applications and 
libraries

as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction whenever possible"
and it seems the current compiler actually does work like this.


Seems a pity to have the bit-field exception here, why is it there?


Bit-fields will generally require a read-modify-write instruction,
and I don't think we actually guarantee to generate one right now.


Segher

Re: atomic accesses

[Robert Dewar]

Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and 
libraries

as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction whenever possible"
and it seems the current compiler actually does work like this.

Seems a pity to have the bit-field exception here, why is it there?


Bit-fields will generally require a read-modify-write instruction,
and I don't think we actually guarantee to generate one right now.


Well if they do require more than one instruction, the rule has
no effect ("whenever possible"). If they can be done in one
instruction  (as on the x86), then why not require this, why
make a special case?



Segher

Re: GCC 4.3.0 Status Report (2008-03-03)

[H.J. Lu]

Hi,

I'd like to fix

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

for gcc 4.3. Defines SIDD_XXX in SSE4 header file is a bad idea. SSE 4
header file
in icc will also be fixed.


H.J.
On Mon, Mar 3, 2008 at 12:56 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Status
>  ==
>
>  GCC 4.3.0rc2 is out and we are not expecting further delay of the
>  4.3.0 release.  The trunk is in stage1 since two weeks.
>
>  Branch status
>  =
>
>  We are getting additional bugreports in of which none is going
>  to block the 4.3.0 release.
>
>  Priority #  Change from Last Report
>  --  ---
>  P1   0  +- 0
>  P2  91  + 17
>  P3   8  + 4
>  --  ---
>  Total   99  + 21
>
>  it is too early to collect quality data on the trunk.
>
>  We expect the above numbers to improve again after the release of
>  GCC 4.3.0 which is due to the end of this week.
>
>  Previous Reports
>  
>  http://gcc.gnu.org/ml/gcc/2008-02/msg00237.html
>  http://gcc.gnu.org/ml/gcc/2008-02/msg00389.html
>

Re: atomic accesses

[Segher Boessenkool]

The Linux kernel, and probably some user-space applications and 
libraries

as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction whenever possible"
and it seems the current compiler actually does work like this.

Seems a pity to have the bit-field exception here, why is it there?

Bit-fields will generally require a read-modify-write instruction,
and I don't think we actually guarantee to generate one right now.


Well if they do require more than one instruction, the rule has
no effect ("whenever possible"). If they can be done in one
instruction  (as on the x86), then why not require this, why
make a special case?


Because current GCC doesn't work like this AFAIK.  I'm aiming for
a documentation-only change here, we can always extend it later.


Segher

Re: gcc-4.1-20080303 is now available

[Gabriel Dos Reis]

On 3 Mar 2008 22:40:21 -,  <[EMAIL PROTECTED]> wrote:
> Snapshot gcc-4.1-20080303 is now available on
>   ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080303/
>  and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
>  This snapshot has been generated from the GCC 4.1 SVN branch
>  with the following options: 
> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 132843

Do we still want to keep this branch alive?

-- Gaby

Re: Copy constructor access check while initializing a reference

[Gabriel Dos Reis]

On Mon, Mar 3, 2008 at 7:16 PM, Peter A. Felvegi
<[EMAIL PROTECTED]> wrote:
> hello,
>
>  i've found this in the known non-bugs list
>  (http://gcc.gnu.org/bugs.html#known), after running into the issue. gcc
>  3.4-4.2 gives a compile error, but 4.3 compiles it. is this a
>  regression, or the rules were relaxed somewhat (c++0x?) ? i checked the
>  changelog, but couldn't find any relevant entries there.
>
>  could someone explain the rationale behind this extra access check,
>  please? i'm puzzled, since the copy ctor is not needed and is not called
>  from the generated code.

 http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#391

-- Gaby

Re: Swing replacements

[Ted Byers]

--- [EMAIL PROTECTED] wrote:
> Pardon my intrusion, I suspect that you are not the
> right 
> people to ask, but I'm hoping that you might know
> whom I 
> _should_ be asking. 
> 
If you have questions about licensing and distribution
of Sun's JRE, go straight to Sun's site and ask in
their most relevant forum.

> In an Excelsior article by Dmitry Leskov on
> converting Java 
> code to a Windows .exe file, (or maybe on a page I
> reached 
> from that page), I read that while the basic Java
> classes 
> _can_ be packaged as a .exe, Java does not allow its
> awt or 
> Swing classes to be so packaged (I hope I've got
> this right).
> 
Don't know.  Haven't tried.  But who cares?  You can
make an executable jar file easy enough.  Why would it
matter whether the file extension is 'exe' or 'jar'. 
I have downloaded quite a number of executable jar
files that were perfectly adequate little
applications.

I really don't understand why this would be an issue
for you.  Anyone and everyone can download the latest
JRE from Sun's site, and it seems to me Sun has gone
out of their way to make use and distribution of it
easy.  Just look at web start, as an example.  If you
are distributing your stuff through the web, you can
use web start to do so and guarantee that the person
downloading your software has the right version of the
JRE.  Sun has provided nice and simple documentation
for how to do this.

Mind you, I use gcc only for fortran and C++ (and
eventually I'll use it to learn ada - and maybe it is
blasphemous to say so here, but I use NetBeans and
Sun's SDK/J2EE for all my java development work), but
I DO know that gcc includes java, and I can't see that
being of much use if there wasn't an application
framework like Swing, or perhaps Swing itself.  And
I'd assume it supports making executables.  It would
be pretty useless otherwise.  Read the documentation
for java as provided with gcc.  It ought to tell you
all you need to know.

> I have a stand-alone, non-Web-based app. that I'd
> like to 
> distribute as a .exe with some database files, to a
> layman 
> audience, and I'd like to avoid issues of JRE
> distribution and 
> compatibility, etc. So I'm hoping someone,
> somewhere, has 
> written a replacement framework for Java's GUI
> classes. Can 
> you by any chance point me in such a direction?
> 
Compatibility is a completely different issue, and has
plagued software developers for decades.  I have new
java code that won't run on anything older than the
most recent JRE.  There are interesting things
happening with Java, such as the introduction of
generics, so I don't care if older versions of the JRE
don't like my new code.  

If you don't like Swing, look at SWT
(http://www.eclipse.org/swt/).

HTH

Ted