On 6/2/05, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 02, 2005 at 11:21:31AM +0200, Richard Guenther wrote:
> > During type checking of the middle-end in the tree-optimizers
> > we run into type mismatches like
>
> This isn't a type mismatch i
On x86_64 I see
/net/pherkad/scratch/rguenth/gcc-obj/./gcc/gcj
-B/net/pherkad/scratch/rguenth/gcc-obj/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-i
On 6/4/05, Bryce McKinlay <[EMAIL PROTECTED]> wrote:
> I've just done an x86_64 build of HEAD and didn't see this error.
Hm, ok - it seems changing java/parse.y:build_if_else_statement
to not construct a COND_EXPR with NULL_TREE type, but
void_type_node causes this. Any idea why?
Thanks,
Richard
On 6/6/05, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > There's also a fair amount of code whih relies on -1 ==
> > (int)0x.
> >
> > Or is there any truly portable and efficient way to convert a sequence
> > of bytes (in big-endian order) to a signed integer?
>
> Of course there is.
On 6/6/05, Georg Bauhaus <[EMAIL PROTECTED]> wrote:
> Daniel Kegel wrote:
>
> > So, I'm looking around for other reports of performance
> > regressions in gcc-4.0.
>
> I came across this one:
>
> int foo(int a, int b)
> {
> return a + b;
> }
>
> int bar()
> {
> int x = 0, y =
On 6/6/05, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > Better use a union for the (final) conversion, i.e
> >
> > int conv(unsigned char *c)
> > {
> > unsigned int i;
> > union {
> > unsigned int u;
> > int i;
> > } u;
> >
> > u.u = 0;
> > for (i = 0; i < s
Consider the (two) case(s)
double foo(double) __attribute__((sseregparm));
static double bar(double) __attribute__((sseregparm));
static double bar(double x) { return x; }
now, with -mno-sse we have the following choices for call
to function foo:
1 Emit the call with SSE arguments regardless
On 6/12/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> I could tell you why for PPC (where we aren't that far behind xlc or icc
> on a lot of them, if you use the right options), but no clue for x86.
It would be interesting to see what the difference is with
http://gcc.gnu.org/ml/gcc-patches/2
On 6/14/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> I wish I could do more, which is why I made (what I hoped were)
> constructive suggestions for trying to get more people involved in
> fixing bugs.
For getting more people involved in fixing bugs they need those
bugs in plain C code (read
On 6/15/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
> > Agreed. But keep in mind that it is not necessary to reply: once the bug is
> > open and confirmed, the last comment "wins", in a way. If the bugmaster
> > wanted to close it, he would just do it, so an objection in
On 6/15/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> Gabriel Dos Reis wrote:
> > Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> > | But an objection from one of the bugmasters *is* enough to keep people
> > | from presenting a patch.
> >
> > Well, I'm not sure. If the report is closed, then
On 6/21/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> I've noticed that -floop-optimize2 tends to be a pessimism on many
> algorithms.
>
> I'm hesitant to file this as a "bug", given that -floop-optimize2 is a
> "new" replacement for the older loop optimizer.
>
> Is -floop-optimize2 still in
[1st try appearantly did not get through - sorry if you get this twice]
Hi!
I'm facing a problem, that with code like
double sin(double);
double __attribute__((sseregparm)) (*mysin)(double) = sin;
double bar(double x)
{
return mysin(x);
}
we fail to recognize that mysin returns in %mm0 becaus
Hi!
I'm facing a problem, that with code like
double sin(double);
double __attribute__((sseregparm)) (*mysin)(double) = sin;
double bar(double x)
{
return mysin(x);
}
we fail to recognize that mysin returns in %mm0 because ix86_value_regno
is only ever called with NULL func argument. We corre
On Wed, 6 Jul 2005, Richard Henderson wrote:
> On Tue, Jul 05, 2005 at 05:14:44PM +0200, Richard Guenther wrote:
> > I'm lost in the mysteries of expansion of the indirect call, also
> > ix86_value_regno gets called all over the place, so the "interesting"
On Mon, 11 Jul 2005, Richard Guenther wrote:
> On Wed, 6 Jul 2005, Richard Henderson wrote:
>
> > On Tue, Jul 05, 2005 at 05:14:44PM +0200, Richard Guenther wrote:
> > > I'm lost in the mysteries of expansion of the indirect call, also
> > > ix86_value_regno
On 7/13/05, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Wednesday 13 July 2005 04:29, Josh Conner wrote:
> > > Finally, you've apparently used grep to find all the places where
> > > PARAM_MAX_INLINE_INSNS_SINGLE and its friends are used, but you hve
> > > missed the ones in opts.c and maybe el
As subject says - on x86_64 it takes a whopping 30 minutes to
compile said with -fprofile-generate! And of course profiledbootstrap
later fails with
stage1/xgcc -Bstage1/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g
-O2 -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W -Wall
-Ww
On 7/14/05, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> As subject says - on x86_64 it takes a whopping 30 minutes to
> compile said with -fprofile-generate!
It's caused by -frename-registers enabled by -funroll-loops. Compiling
with -O2 -fno-unroll-loops -fprofile-gene
On 7/25/05, Denis Zaitsev <[EMAIL PROTECTED]> wrote:
> Such an example can't be compiled:
>
>
> #include
>
> void x()
> {
> printf(__FUNCTION__ "\n");
> }
>
>
> $ gcc printf.c -o fprintf
> printf.c: In function `x':
> printf.c:5: error: syntax error before string constant
__FUNCTION__ ex
Hi all!
I reduced my array aliasing libstdc++ failures to the following
testcase:
struct iterator
{
int* ptr;
iterator(int* _ptr) : ptr(_ptr) {}
};
struct container {
int* first;
container(int* _first) : first(_first) {}
iterator begin() { return iterator(first); }
};
bool i
C testcase ;)
typedef struct { int *p; } X;
void includes(const X *);
void test4(void)
{
int array[2] = { 2, 4 };
X i;
int * _p;
_p = array;
i.p = _p;
includes(&i);
}
if you change that to
i.p = array;
it works... !? But I note this in the failing case:
Pointed-to sets for poin
On Wed, 27 Jul 2005, Diego Novillo wrote:
> On Wed, Jul 27, 2005 at 03:09:09PM +0200, Richard Guenther wrote:
>
> > i.e. while we see that the temporary pointer points to array[0], for
> > SFT.2_6 (i.p) we don't see anything? So if we'd see { SFT.1 } here, too,
>
Hi!
I'm a bit confused about the uses of the decls stored in the
implicit_builtin_decls and builtin_decls arrays. I suppose
the builtin_decls array should contain the __builtin_X variant,
while the implicit_builtin_decls variant should contain the X
variant. Most of the code emitting calls to f
On 8/2/05, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 01, 2005 at 10:12:37PM -0700, Ian Lance Taylor wrote:
> > Harald van D??k <[EMAIL PROTECTED]> writes:
> >
> > > I finally managed to track down the problem I've been having to this
> > > short code:
> > >
> > > typedef struct {
>
On 8/2/05, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 8/2/05, Diego Novillo <[EMAIL PROTECTED]> wrote:
> > On Mon, Aug 01, 2005 at 10:12:37PM -0700, Ian Lance Taylor wrote:
> > > Harald van D??k <[EMAIL PROTECTED]> writes:
> > >
> > > &
On 8/2/05, Mark Frazer <[EMAIL PROTECTED]> wrote:
> Hello. I'm not on the list, so please CC me with any replies.
>
> I have come across a bug found during some code which serializes
> doubles. The bug is only encountered when the optimization level is set
> to -O2 or greater.
>
> The bug is no
On 8/12/05, Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Subject says it all - I do not know if that is new. I just have a bug
> in Gujin-1.2 with this new compiler, because function:
>
> __attribute__ ((section (".xcode_start"), noreturn))
> void xcodeseg_never_call_address_zero (
featuring a faster sub-target specific implementation. This
includes SSE(2) ABI and implementation transcendental functions and
vectorized transcendental functions not currently in libm.
Personnel
* Richard Guenther
Delivery Date
Stage 1 of 4.2. i386 specific implementation is ready
I'm seeing splay tree usage from tree-ipa-type-escape in the first
places of profiles from tramp3d-v4:
samples %image name app name symbol
name
1418146.5462 no-vmlinux no-vmlinux (no
symbols)
71471 3.2992 cc1plus
On 8/31/05, Vahur Sinijärv <[EMAIL PROTECTED]> wrote> Hi,
>
> No, the problem I wrote about is not fixed. I used GCC from CVS head
> 30.08.2005.
> I think you found a different bug, you seem to have many unneccessary
> uses of secondary memory between moves from MMX reg to MMX reg. The code
> I wr
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Here's a fragment of the SSA dump for a shortened version of that
> test.
>
>
> D.860_8 = __gnat_malloc (20);
> # D.861_10 = V_MUST_DEF ;
> D.861 = (struct c34007p__designated *) D.860_8;
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Here's a fragment of the SSA dump for a shortened version of that
> test.
>
>
> D.860_8 = __gnat_malloc (20);
> # D.861_10 = V_MUST_DEF ;
> D.861 = (struct c34007p__designated *) D.860_8;
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I don't think we ever defined "valid GENERIC" that way.
>
> About a year ago, when we tried to define it, that's what we came up
> with. If that isn't the definition, then what *is*? The problem is that
> we have no document that says wh
On 9/14/05, shreyas krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
> I am trying to find out whats the best way to do the following.
> I want to replace some pre-defined variables at a few pre-defined
> line with a new temperory variable. I guess the front-end should be
> the best place to do it.
On 9/19/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > I applied the patch by hand (not working with CVS) and it
> > does _not_ solve the problem.
> >
> In this case, I am sorry but the probability of a fix before the release
> is close to zero.
The problem with 4.0 is that it behaves comple
On 25 Sep 2005 10:10:39 -0700, Ian Lance Taylor wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > second, how often does this actually set anything useful with restrict
> > types (I assume the value is not interesting in any other cases)?
>
> In functions which use the restrict qualifier, i
Hi!
On current mainline-gcc install-pkglibLTLIBRARIES fails re-linking
libjawtgnu:
make[5]: Entering directory
`/usr/src/packages/BUILD/gcc-4.1.0-20050929/obj-i586-suse-linux/i586-suse-linux/libjava/classpath/native/jawt'
test -z "/usr/lib/classpath" || mkdir -p --
"/var/tmp/gcc-mainline-4.1.0_
This is a summary report of a (failed) attempt to address memory and
compile-time usage of large (static array) initializers. The problem
is that we both use TREEs to do array indices arithmetic in
c-typeck.c:process_init_element and that we pin down memory for
INTEGER_CST tree nodes in both th
On 10/4/05, Peter Lupton NCH Swift Sound <[EMAIL PROTECTED]> wrote:
> Maybe I gave a too simple example on my first post. Another example common
> error which would be prevented by blocking implicit bool conversion might be:
>
> if (strcmp(szMyName, "Peter")) printf("Hello Peter");
>
> This ba
On 10/8/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > Generic but you might want to start by trying to define a type
> > system first.
Why not gimple?
> Actually, we shouldn't be writing out any of them, at least in their
> current form.
>
> (IE it shouldn't be pickled trees)
Or even dump SSA
On 10/11/05, Astroman (sent by Nabble.com) <[EMAIL PROTECTED]> wrote:
>
> I am working on a piece of software that never exits and I am trying to use
> -fprofile-arcs and gcov to gather coverage data on it.
> The code looks like this:
> int main(){
>while(1){
> foo();
> nanosleep
On 10/19/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > But if it's not a win for most of us, we probably shouldn't do it.
> > There is no perfect revision control system. None of the currently
> > production quality open source ones are any better.
>
> I think it is natural that people start
On 10/19/05, Arnaud Charlet <[EMAIL PROTECTED]> wrote:
> Here are my first impressions on trying to use subversion.
>
> Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
> the commands I saw on the gcc list. I am familiar with cvs commands and
> expect most things to be handle
On 10/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote:
> > > Most of this is ssh overhead, because your diff is so small.
> >
> > I disagree, the diff isn't small, it is of a typical/reasonable size I
> > would say.
> >
> > > The
On 10/19/05, Tobias Schlüter <[EMAIL PROTECTED]> wrote:
>
> [ I've added gcc@ to the CC list and reproduced the message in full, FX
> already got the "buy a bigger harddisk" answer there, I think it makes sense
> to show that other people care about this, too ]
>
> Steve Kargl wrote:
> > Now, to my
On 10/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:
> > On 10/19/05, Tobias Schl?ter <[EMAIL PROTECTED]> wrote:
> > > Steve Kargl wrote:
> > > > Now, to my proposal for future gfortran de
On 20 Oct 2005 08:58:36 +0200, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> | Re: moving to subversion
> |
> | On Wed, Oct 19, 2005 at 12:19:52PM -0700, Mark Mitchell wrote:
> | > We've discussed this extensively at CodeSourcery, and I think everyone
> | >
On 10/20/05, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Oct 2005, Richard Guenther wrote:
>
> > If it is at all possible we should probably try to keep read-only CVS
> > working
> > (and up-to-date) for HEAD and release-branches. This will allow o
On 10/20/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Eric Botcazou <[EMAIL PROTECTED]> wrote:
>
> > I've never created/managed branches or tagged anything in the GCC
> > tree. The important things to me are:
> >
> > - time to do a complete check-out on mainline/branch
>
> Check-out is 30% slowe
On 10/20/05, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> Since there is a big brainstorming, I will sum up my opinion here (and
> then stop spending time on this issue). From the discussion, it looks
> like the switch seems the most important constraint imposed by the switch
> is about har
On 10/21/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Paul Brook wrote:
>
> >See previous threads about how svn makes multiple connections to the server,
> >each requiring authorization.
> >
> >
> Argh! I glanced briefly over those threads...
>
> While you are at it, are you willing to summarize
On 10/26/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> Jeff Stevens wrote:
> > Is there a HowTo out there on how to cross compile GCC
> > to run on another platform? I have an x86 host
> > running linux, and an embedded PowerPC 440SP target
> > running linux. I would like to compile GCC to run on
>
Hi!
it seems that
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_component_p (ref))
{
if (TREE_CODE (ref) == INDIRECT_REF)
return true;
ref = TREE_OPERAND (ref, 0);
}
return false;
}
always returns false, because handled_component_p (ref)
On Fri, 4 Nov 2005, Richard Guenther wrote:
> Hi!
>
> it seems that
>
> static inline bool
> ref_contains_indirect_ref (tree ref)
> {
> while (handled_component_p (ref))
> {
> if (TREE_CODE (ref) == INDIRECT_REF)
> return true;
&
On Fri, 4 Nov 2005, Richard Kenner wrote:
> The following patch "fixes" this by imitating ref_contains_array_ref
> semantics. Bootstrapped on x86_64-unknonw-linux-gnu, regtest in
> progress, ok for mainline if it succeeds?
>
> Wouldn't this be simpler:
>
> static inline bool
> ref_
On Fri, 4 Nov 2005, Diego Novillo wrote:
> On Friday 04 November 2005 08:34, Richard Guenther wrote:
>
> > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > with INDIRECT_REF not in handled_component_p.
> >
> If you handle INDIRECT_REF directly, then
On Fri, 4 Nov 2005, Diego Novillo wrote:
> On Friday 04 November 2005 09:45, Richard Guenther wrote:
> > On Fri, 4 Nov 2005, Diego Novillo wrote:
> > > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> > > > * tree-flow-inline.h (re
On 11/4/05, Alex Tzanov <[EMAIL PROTECTED]> wrote:
> Dear developers,
>
>
> I have recently upgraded my PC to Suse Linux 10 (from 9.3). The
> distribution
> comes with gcc 4.0.2. The problem that arrised after the upgrade is that
> I
> cannot compile f77 codes anymore. More precisely when I try to
han
> COMPONENT_REFs.
> The comment needs to be updated.
I bootstrapped and regtested the following on x86_64-unknown-linux-gnu.
Ok for mainline?
Thanks,
Richard.
2005-11-04 Richard Guenther <[EMAIL PROTECTED]>
* tree-flow.h (ref_contains_indirect_ref): Rename to
On 11/5/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> >> I guess the issue is what does "huge" mean, it is hard to discuss based
> >> on loaded adjectives taking the place of data :-)
> >
> > Huge here means 15-20% on x86* hosts.
>
> I don't consider
On 11/5/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> >>>> I guess the issue is what does "huge" mean, it is hard to discuss based
> >>>> on loaded adjectives taking the place of data :-)
>
On 11/6/05, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
>
> > I believe you are missing my point. What is the GCC command line option for
> > "try to optimize as best as you can, please, I don't care compiletime"? I
> > believe that should be -O3. Otherwise let's make -O4. Or -O6
On 11/6/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Hi,
>
> we have this long standing issue which really we should solve, one way
> or another: otherwise there are both correctness and performance issues
> which we cannot fix, new features which we cannot implement. I have
> plenty of examples,
On 11/6/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> > We could just provide fallback libcalls in libgcc
> Indeed, this is an option. Not one I can implement myself quickly, but I
> think the idea of issuing a library call when the builtin i
On 11/6/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Paolo Carlini wrote:
>
> > Actually, the situation is not as bad, as far as I can see: the worst
> > case is i386 vs i486+, and Old-Sparc vs New-Sparc. More generally, a
> > targer either cannot implement the builtin at all (a trivial fall back
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Henderson wrote:
>
> >Actually, no, it's not possible. At least in the context we're
> >discussing here. Consider:
> >
> >One part of the application (say, libstdc++) is compiled with only
> >i386 support. Here we wind up relying on
On 11/7/05, Inder <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am compiling small program on a SPARC gcc 3.4.3
>
> test.c
> ---
>
> struct test1
> {
> int a;
> int b;
> char c;
> };
>
> struct test2
> {
> char a;
> char b;
> char c;
> };
>
> st
On 11/7/05, Inder <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am compiling small program on a SPARC gcc 3.4.3
>
> test.c
> ---
>
>
> int main()
> {
> struct test1* t1, t11;
> struct test2* t2 ;
> struct test3* t3;
>
> t1 = &t11;
> t2 = (struct t
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >Richard is right - it's enough that the inlined version doesn't agree with
> >whatever smartness is in libgcc.
> >
> Like? If you are inlining atomic operations th
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >>Like? If you are inlining atomic operations this means that you are
> >>passing -march=i686, therefore in order to run the code in the first
> >>place the machine has to be a
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Paolo Carlini wrote:
>
> >Richard Guenther wrote:
> >
> >>ou are screwed, because if you pass a std::vector (assuming it needs
> >>locking) to kdelibs to mungle with and in a separate thread mungle
On 11/8/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >Just to put some more thoughts on the table, I'm about to propose adding
> >a __gcc_cpu_feature symbol to $suitable_place, similar to what Intel is
> >doing with its __intel_c
Building a --target=avr compiler currently fails because
/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/
-B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem
/opt/cross/avr/include -isystem /o
On Sat, 12 Nov 2005, Eric Botcazou wrote:
> > Building a --target=avr compiler currently fails because
> >
> > /usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc
> > -B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/
> > -B/opt/cross/avr/bin/ -B/opt/
On 13 Nov 2005 02:00:08 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > Andrew Pinski <[EMAIL PROTECTED]> writes:
> | >
> | > | > | of what the semantics of REFERENCE_TYPE are/should be, then yes.
> | > | >
> | > | > See, it is not a sema
On 11/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I appreciate that this is quite valid according to the ANSI C
> standard and the team are within their rights to change this,
> but I am curious to know the reasoning behind the change which
> seems to me to make the object code less optim
On 13 Nov 2005 21:36:02 -0800, Ian Lance Taylor wrote:
> Jan Hubicka <[EMAIL PROTECTED]> writes:
>
> > in testsuite there are few reduced testcases where unit growth (an
> > inliner limit - inliner is allowed to inline as long as the unit don't
> > grow by given percentage, set to 50%) is too stri
On 11/15/05, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > I told about importance of early access to machines based on new
> > Itanium chip (Montecito) and documentation for gcc developers trying
> > to improve gcc for Itanium.
> >
> > As for Mark Davis remark about rewriting RTL optimizations, I t
On 11/16/05, Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:
> Hi -
>
> > What I'm wondering is whether or not mudflap should instrument accesses
> > to globals that it doesn't know the size of. In the following code:
> > [...]
> > printf("%d\n", global[3]);
> > [...] Mudflap does not emit any __
On 11/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems. When
> I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
> the file command on the executable I get
>
> hello: ELF 32-bit MSB exe
On 11/18/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I sent email about this a few months ago (I can't find it since I'm having
> a problem getting a browser to work on gcc.gnu.org) and thought I'd raise
> it again since it would be good to get this into 4.1
>
> Currently, tail call detected is
On 11/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote:
> > * This will not support !
> >
> > As describe above, we won't support every target that GCC currently
> > does. Three options are possible:
> >
> > 1. We (the GCC communit
On 11/19/05, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> I am trying to build 4.1 branch but make profiledbootstrap stops here:
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00857.html for
a patch that fixes the problem.
Richard.
tail -n 30 /work/built/mbuild/g148-rguenther-61/x86_64/Logfile.gcc-mainline.spec
-o 32/crtbeginT.o
../../gcc/libgcc2.c: In function '__fixunsdfdi':
../../gcc/libgcc2.c:1228: error: could not split insn
(insn:TI 17 65 66 ../../gcc/libgcc2.c:1219 (parallel [
(set (reg:DI 0 ax [66])
On 11/22/05, Jim Wilson <[EMAIL PROTECTED]> wrote:
> Piotr Wyderski wrote:
> > I am working on a portable low-level library of atomic operations,
>
> Like the existing libatomic-ops package?
>
> > Why does __sparc_v9__ depend on the number of bits instead of the -mcpu?
> > Is this a GCC bug? I've f
On 11/25/05, Branko Čibej <[EMAIL PROTECTED]> wrote:
> Kaveh R. Ghazi wrote:
> > > On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote:
> > > > Hi Dan,
> > > >
> > > > (BTW, sorry for the reposted messages.)
> > > >
> > > > While I was waiting for some svn commands to finish (cleanup,
> >
I wonder what magic is required to run the testsuite with an extra
--param foo=blah argument. Just using
RUNTESTFLAGS="--target-board=unix/--param foo=blah"
fails because of the space, trying to be clever and doing
RUNTESTFLAGS="--target-board=unix/--param/foo=blah"
results in --param -mfoo b
The patch below teaches points-to analysis about restrict qualifiers
of incoming parameters. It is modeled after the special handling
of malloc result type pointers, namely creating fake variables we
point to and thus trigger creation of NMTs. Unfortunately it doesn't
exactly work, as for the te
On Tue, 29 Nov 2005, Daniel Berlin wrote:
> On Tue, 2005-11-29 at 22:08 +0100, Richard Guenther wrote:
> > The patch below teaches points-to analysis about restrict qualifiers
> > of incoming parameters. It is modeled after the special handling
> > of malloc result type poin
It looks like it is safe to exchange both of them (the first one for sure)
to fold_convert (...) due to the fact that fold_unary handles NOP_EXPR
the same way than CONVERT_EXPR apart from cases that look like oversights,
f.i.
/* Convert (T1)((T2)X op Y) into (T1)X op Y, for pointer types T1
On 12/4/05, FX Coudert <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Below is the answer I got from the developer of GMP when I asked about
> support for ia64-hpux.
>
> > So, in short, my questions are: is gmp-4.1.4 supposed to work on
> > ia64-hpux?
> >
> > No, it is not. It might be possible to g
On 12/4/05, Jack Howarth <[EMAIL PROTECTED]> wrote:
> In compiling xplor-nih under gcc 4.1 (it is a mix of c, c++ and fortran)
> I discovered one of its c++ source files causes segfaults at optimization
> levels higher than -O1 unless I add -fno-strict-aliasing to the compile
> flags. In that c
Hi!
Currently there are the following builtins available from the fortran
frontends:
/* We define these separately as the fortran versions have different
semantics (they return an integer type) */
gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0],
BUILT_IN
On 12/6/05, Jurij Rosenthal <[EMAIL PROTECTED]> wrote:
> Hi gcc team,
>
> please mention gcc 4.1 in News/Announcements
> at
> http://gcc.gnu.org/index.html
>
> if this is an official release.
What makes you think it is? 4.1.0 is not yet released.
Richard.
On 12/7/05, Andreas Killaitis <[EMAIL PROTECTED]> wrote:
> Hello list,
>
> I have a question concerning the size of the code generated by gcc
> 4.0.2 and 4.1.
> We talk about a C++ app with many smaller (30k) or larger (4M) C++
> libraries.
> Being happy the size of those libs decreased by about 20
On 12/7/05, Tommy Vercetti <[EMAIL PROTECTED]> wrote:
> Hi there
>
> We had funny issue here lately. Someone wanted to create table that
> had 0 elements in C++, for instance this code:
This is a gcc extension. Try g++ -pedantic
Richard.
> int main()
> {
> char a[0];
> char b[
On 12/7/05, Morten Welinder <[EMAIL PROTECTED]> wrote:
> >> This is a joke, you are kidding, right ?
> > No, we're not kidding. RTFM: Section, 5.12 Arrays of Length Zero
>
> He is kind of right, though. Outside struct (or perhaps union),
> zero-sized arrays
> make little sense and could be reject
I have added FDO runs to the daily tramp3d tester and am observing
"intersting" things there. First of all, compile time with
-fprofile-generate (w/o leafify) skyrocketed from ~120s to 440s.
For reference, here's the hot spots in -ftime-report:
life analysis : 24.66 ( 6%) usr 0.00 (
On 12/8/05, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> I have added FDO runs to the daily tramp3d tester and am observing
> "intersting" things there.
Btw. I finally was able to move it to public webspace. You can have a look
at http://www.suse.de/~rguenther/
Richard.
201 - 300 of 2444 matches
Mail list logo
