On Fri, Jun 12, 2009 at 9:49 PM, Aldy Hernandez wrote:
> On Sat, Jun 13, 2009 at 01:51:42AM +0100, Dave Korn wrote:
>> Aldy Hernandez wrote:
>> > Hi folks.
>> >
>> > At the last minute Ian got a patch in that touched a bunch of places
>> > that I was also changing. I resolved the conflicts, and bo
On Sun, Jun 14, 2009 at 11:02:04PM +0200, Giuseppe Scrivano wrote:
> Hello,
>
> last GCC revision has a compiler warning at line 8502. Is this
> extremely trivial patch OK?
This has already been fixed:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01109.html
Sorry for the breakage.
Bye,
-Andre
Hi.
Gimple code of the program I have tried to get the pointsTo
information is as follow:
A = 0;
B = &A;
C = &B;
D = &C;
D.1255 = *D;
D = (int * * *) D.1255;
The expected pointsTo pairs are,
B = { A } , A = { }, C = { B }, D.1255 = { B }, D = { B C }
But with GCC-4.3.0, and command lin
On Mon, Jun 15, 2009 at 12:33 PM, Seema Ravandale wrote:
> Hi.
>
> Gimple code of the program I have tried to get the pointsTo
> information is as follow:
>
> A = 0;
> B = &A;
> C = &B;
> D = &C;
> D.1255 = *D;
> D = (int * * *) D.1255;
>
> The expected pointsTo pairs are,
> B = { A } , A =
On Jun 14, 2009, daniel tian wrote:
> Now, for immediate movement, it is achieved to move large immediate.
> But I don't know how to make the address mode legitimate. Now I try to
> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
> cc1 still crashed, when the frame size is la
> As I said, it's a minor polish issue. It may be sufficient to just have a
> note in the documentation as Basil suggested.
I would prefer just changing the documentation too. In general I think
that plugins
should see gcc the same way a builtin pass does. If a plugin needs to
look at the
IL early
On Mon, Jun 15, 2009 at 09:32, Rafael Espindola wrote:
>> As I said, it's a minor polish issue. It may be sufficient to just have a
>> note in the documentation as Basil suggested.
>
> I would prefer just changing the documentation too. In general I think
> that plugins
> should see gcc the same wa
oliver.kell...@t-online.de (Oliver Kellogg) writes:
> Anybody else seeing this?
>
> ‘lower_try_finally_switch’:
> ../../../SOURCES/gcc/gcc/tree-eh.c:1350:5: error: ‘tf_loc’ may be used
> uninitialized in this function
Funny, this was never picked up in any of my bootstraps, but it is
indeed a bug
> Your committal of r148442 has caused an ICE during the build of libgcc
> for targetting win64:
I have this pending patch, which may or may not fix this.
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01113.html
Can you try and see if it fixes it? Otherwise, can you find out where
the compiler i
> Mine are. I ignore all heads in gcc.git, and just map its remotes into my
> remotes by manually specifying remote.origin.fetch. Not very pretty, but it
> seems to produce the optimal result. See my stuff in the lower section of
> http://gcc.gnu.org/wiki/GitMirror for more details.
It fails wi
Rafael Espindola wrote:
As I said, it's a minor polish issue. It may be sufficient to just have a
note in the documentation as Basil suggested.
I am sorry to be picky, but my first name is spelled Basile (in France,
where I live and am a citizen).
I do know that is it written Basil in English
On 06/15/2009 10:28 AM, Rafael Espindola wrote:
It fails with
$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
That's not my section; my contribution starts at
Alternative git-svn procedure (Jason Merrill)
Jason
On Mon, Jun 15, 2009 at 9:52 AM, Aldy Hernandez wrote:
>> Your committal of r148442 has caused an ICE during the build of libgcc
>> for targetting win64:
>
> I have this pending patch, which may or may not fix this.
>
> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01113.html
>
> Can you try and see
Hi Yuanjie, Liang, et al,
This email is about further GSoC'09 developments for plugins, generic function
cloning, fine-grain optimizations
and program instrumentation this summer. Considering that the basic
infrastructure is now available I would like
to agree on further developments based on th
Mario,
I, personally, have not encountered MAXDATA limits building
application with GCC (as opposed to Java), but I can see that some
large applications might encounter them. I bootstrap GCC every night
and build many GNU applications with the default GCC configuration.
I can adjust the default G
On 06/15/09 16:28, Rafael Espindola wrote:
>> Mine are. I ignore all heads in gcc.git, and just map its remotes into my
>> remotes by manually specifying remote.origin.fetch. Not very pretty, but it
>> seems to produce the optimal result. See my stuff in the lower section of
>> http://gcc.gnu.or
Paul Edwards wrote:
> One of the things that I experienced when porting 3.2.3 to MVS
> was that GCC was sensitive to the exact floating point representation.
>
> Register selection was different depending on those slight differences.
>
> Below is what documentation I have for it. Dave Edwards,
daniel tian writes:
> There is a problem I encountered. I port gcc to 32bit RISC. The
> LOAD/STORE only has 8bit displacement. If the immediate displacement
> larger than 256, the displacement must be force into register. In
> addition, if the immediate is larger than 512, it can only move into
>
> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
> function ?make_decl_one_only?
make_decl_one_only expects one argument, and that's what's being fed.
Could you please debug this and find out what's
On Mon, Jun 15, 2009 at 2:05 PM, Aldy Hernandez wrote:
>> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>> function ?make_decl_one_only?
>
> make_decl_one_only expects one argument, and that's what
ami_stuff writes:
> I notice about 20% speed regression with GCC 4.4.0 PNGCrush build compared to
> GCC 3.4.0 build (Amiga 68...@50mhz).
>
> CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s
>
> Here are the results:
>
> GCC 3.4.0:
>
> CPU time used = 267.340 seconds (decoding
A further problem that I'm seeing is that
Lib.Writ.Write_Unit_Information assumes the current unit to depend on
all entries in Lib.Units. However, when letting Lib.Units accumulate
units across several compilations this dependency does not
necessarily hold true. The generated ALI files for compilat
Ian Lance Taylor wrote:
daniel tian writes:
There is a problem I encountered. I port gcc to 32bit RISC. The
LOAD/STORE only has 8bit displacement. If the immediate displacement
larger than 256, the displacement must be force into register. In
addition, if the immediate is larger than 512, i
Jeff Law writes:
>> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
>> TARGET_SECONDARY_RELOAD. I don't know why cc1 crashed, you will have to
>> debug that.
>>
> LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this --
> LEGITIMIZE_RELOAD_ADDRESS is to be used when target spec
Ian Lance Taylor wrote:
Jeff Law writes:
I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
TARGET_SECONDARY_RELOAD. I don't know why cc1 crashed, you will have to
debug that.
LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this --
LEGITIMIZE_RELOAD_ADDRESS is to be
Hi, I'd like to know if somebody is implementing c++0x's unrestricted
unions (N2544) in g++, or if there are any plans to do it in mid-term.
Thanks,
Rodolfo Lima
Rodolfo Lima escreveu:
> Hi, I'd like to know if somebody is implementing c++0x's unrestricted
> unions (N2544) in g++, or if there are any plans to do it in mid-term.
Sorry, by 'in mid-term' I meant "in a not too distant timeframe".
[]s,
rod
Hi,
> I assume that you are measuring the speed of the compiled code, not the
> speed of the compiler itself.
Yes.
> Can you open a bug report about this,
> with enough information for other people to reproduce the results (e.g.,
> pointer to source code being compiled and input file(s)).
Done.
Hi,
I noticed that __alignof__(uint64_t) will return 8, while
__alignof__(struct { uint64_t x; }) will give only 4. This
run on a typical 32-bit x86 CPU (GCC config below).
What I am wondering about is why GCC was coded to give different
alignments here. If aligning a single uint64_t to a bounda
29 matches
Mail list logo
