On 5/12/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> But for the following example
> int a = 1;
> int b = 2;
> int c = 3;
> c = c + a * b;
> the MAC pattern is not getting recognized, instead it is still using
> PLUS and MULT patterns.
Your example is bogus. This is optimized to "c = 5" w
Matt Thomas <[EMAIL PROTECTED]> writes:
> In handle_aligned_attributes in c-common.c, at line 5146, it does
>
> type = &TREE_TYPE (decl);
>
> Then at 5179 it does
>
> TREE_TYPE (decl) = *type;
>
> In between, type doesn't change so that's really
>
> TREE_TYPE (decl) = * &TRE
On May 15, 2007, at 2:03 PM, J.C. Pizarro wrote:
2007/5/12, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>
> 1. Can you localize it
This has nothing to do with the development of gcc, so please take it
elsewhere.
On May 15, 2007, at 2:20 AM, Patrick Olinet wrote:
Finally, I've tried it the dirty way, ie by commenting out all the
"stfd" instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
Wonderful. If you could, would you submit the patch to gcc-
patches... I suspect
2007/5/16, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
For instance, this tuple stored in the memory's cell of the user
process gives an idea
* number of quantum's subcontext: long64
* moment of time that the subcontext started: long64 (CPU cycles, from RDTSC)
* (optional) moment subcontext sta
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> gmon.out file is created in mcleanup function.This function however
> doesn't dump the data in the grof gmon.out data format. When i looked
> into the code for i386 and sparc in the backend nothing has been done
> to store the profiling info the requir
On Tue, May 15, 2007 at 06:04:11PM -0700, Joe Buck wrote:
> #3: sparc-sun-solaris2.8: failure in building jv-convert (while
> building libjava).
I think this is due to libiconv problems. It's a machine I don't control
where someone put a GNU libiconv in /usr/local, which tends to mess things
Here are some build/test results for the 4.2.0 release.
#1: i686-pc-linux-gnu on RHEL 3, booted with gcc 3.4.2
(all languages except Ada).
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00713.html
(NOTE: booting with the RHEL-supplied compiler fails the
compare).
#2: x86_64-un
The GCC 4.2.0 release is done, so the 4.2 branch is now open for
checkins under the usual branch rules: regression fixes only.
I know that the GCC 4.2.0 release was a long time coming. Thanks to
everyone who worked on it, and for the constructive comments and
criticisms!
I'll be thinking about
2007/5/16, Joe Buck <[EMAIL PROTECTED]> wrote:
On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote:
> 2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote:
> [ explanation of why gprof is as it is ]
> It's not well reasoned.
If you don't like my explanation, feel free to rewrite the software;
On 5/15/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote:
> 2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote:
> [ explanation of why gprof is as it is ]
> It's not well reasoned.
If you don't like my explanation, feel free to rewrite the software;
On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote:
> 2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote:
> [ explanation of why gprof is as it is ]
> It's not well reasoned.
If you don't like my explanation, feel free to rewrite the software;
it is free software after all. This list usually
2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote:
On Tue, May 15, 2007 at 10:32:09PM +0200, J.C. Pizarro wrote:
> For the current trunk of GCC, thinking about
> the related thing of gprof and option -pg of GCC,
>
> it's important to output correctly the data with non-fatal accuracy,
> preferably 4 d
On Tue, May 15, 2007 at 10:32:09PM +0200, J.C. Pizarro wrote:
> For the current trunk of GCC, thinking about
> the related thing of gprof and option -pg of GCC,
>
> it's important to output correctly the data with non-fatal accuracy,
> preferably 4 digits decimal instead of 2, e.g 0. ms instea
On Tue, May 15, 2007 at 04:28:33PM -0400, Jack Howarth wrote:
>The tarballs for gcc 4.2.0 have been up on the gcc.gnu.org
> ftp site for a couple of days now.
Actually, they've been up for less than 24 hours. As a general
rule, the announcement isn't posted until 24 hours after the
tarballs g
2007/5/12, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>
> 1. Can you localize its last output that stops in its internal
> infinit
2007/5/15, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
http://en.wikipedia.org/wiki/Amdahl's_law
It's a wrong link, the next is the correct
http://en.wikipedia.org/wiki/Amdahl%27s_law
Hi developers,
For the current trunk of GCC, thinking about
the related thing of gprof and option -pg of GCC,
it's important to output correctly the data with non-fatal accuracy,
preferably 4 digits decimal instead of 2, e.g 0. ms instead of 0.00 s.
It's important so that the Amdahl's Law c
The tarballs for gcc 4.2.0 have been up on the gcc.gnu.org
ftp site for a couple of days now. Should we consider gcc
4.2.0 is be released now?
Jack
I'm sure there are some at your school's website. Or you can ask you
TA for help with your homework.
-bw
On May 15, 2007, at 11:33 AM, craig clow wrote:
Hello,
Does anyone know of a good web site for sample C code supported by
GCC 3.3.2?
Specifically, I am looking for code that can read f
Hello,
Does anyone know of a good web site for sample C code supported by GCC
3.3.2?
Specifically, I am looking for code that can read files from a directory and
do I/O.
thanks,
Craig
_
PC Magazines 2007 editors choice for bes
> > On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:
> >>
> >> it gets farther. Anyone want to claim this is obvious? I glanced at
> >> the code and it seems reasonable.
> >
> > Nothing has changed in dwarf2out.c since April 24.
> >
> > Now on the other hand c-format.c changed, which might have
Bernd Schmidt wrote:
Mark Shinwell wrote:
These dumps are of course taken before the application of my patch.
Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
I'm afraid I'm not sure exactly --
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1,
[snip]
Index: reload1.c
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
> I'm fairly certain that this is the correct approach to fix this
> issue, but I'm less certain that I have correctly guarded the call
> to forget_old_reloads_1,
[snip]
> Index: reload1.c
> ===
Mark Shinwell wrote:
> These dumps are of course taken before the application of my patch.
>
> Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
Bernd
--
This footer brought to you by insane German
On 5/15/07, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello,
as a result of my decision to leave STMicroelectronics by the end of the
month, I'm stepping down as the maintainer of the st/cli development
branch (the home of the CLI back-end).
In my next job, I will be working in quite a different f
Bernd Schmidt wrote:
Mark Shinwell wrote:
The bug is currently only exhibiting itself on a proprietary testcase
when compiled for an ARM target and is extremely sensitive to the
particular code involved. It arises as follows, using the same notation
as in Richard's mail:
If you can't post the
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1, and indeed that I've done everything to
era
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
> I'm fairly certain that this is the correct approach to fix this
> issue, but I'm less certain that I have correctly guarded the call
> to forget_old_reloads_1, and indeed that I've done everything to
> eradicate the previous reloads
Hello,
as a result of my decision to leave STMicroelectronics by the end of the
month, I'm stepping down as the maintainer of the st/cli development
branch (the home of the CLI back-end).
In my next job, I will be working in quite a different field; I already
know it won't be compatible with a
Hello all,
gmon.out file is created in mcleanup function.This function however
doesn't dump the data in the grof gmon.out data format. When i looked
into the code for i386 and sparc in the backend nothing has been done
to store the profiling info the required format. How is it that the
file thus
Mark Shinwell wrote:
> The bug is currently only exhibiting itself on a proprietary testcase
> when compiled for an ARM target and is extremely sensitive to the
> particular code involved. It arises as follows, using the same notation
> as in Richard's mail:
If you can't post the testcase, the be
Rask Ingemann Lambertsen wrote:
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for
Patrick Olinet writes:
> > > I thought that fpu emulation worked by trapping cpu exceptions when a
> > > fpu instruction is being executed and then emulating this instruction
> > > on software level.
> >
> > Yes.
> >
> > > Isn't the mechanism implemented by the "--with-float=soft" option
Patrick Olinet writes:
> Finally, I've tried it the dirty way, ie by commenting out all the
> "stfd" instructions at the beginning of the ppc_closure.S file and
> things seem to work !!!
>
> "stfd" are used to save fpu registers and were always executed, even
> if no float/double arguments w
Finally, I've tried it the dirty way, ie by commenting out all the
"stfd" instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
"stfd" are used to save fpu registers and were always executed, even
if no float/double arguments were involved in the call and if no fpu
i
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
> Rask Ingemann Lambertsen wrote:
> >On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
> >
> >[snip]
> >>- the last use of reg2 (in B) is inside a matched input operand;
> >[snip]
> >>The reload used for the instruction
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks like this:
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9 [3275
40 matches
Mail list logo
