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 -
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 t
> 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
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
/* 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 (TR
>
> >/* 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_EFFEC
> 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 BRA
> > 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
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
> 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
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-sysr
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
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 __
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
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 dump
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 hap
>
> >>>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
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 i
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
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 f
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
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
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
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 excepti
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
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
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
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,
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
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
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
> > 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 i
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
> 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
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
> 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
> Was it configured with --enable-checking=release?
No it wasn't.
Bruno
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 una
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
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
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
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
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
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 che
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
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
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
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 m
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.
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
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
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 rule
--- [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 re
53 matches
Mail list logo
