Re: [RFC] WHOPR - A whole program optimizer framework for GCC

They are gaming or playing with the words of the language for Google. If the world is global then ^^ what means "global optimizer" using the infraestructure for google? ^^. Wow, paranoia is a new feature of J.C.'s messages. Seriously, your future employers might search for your name in the

Re: Something is broken in repack

When I returned to the computer this morning, the repack was completed... with a 1.3GB pack instead. So... The gcc repo apparently really needs a large window to efficiently compress those large objects. So, am I right that if you have a very well-done pack (such as gcc's), you might want

Re: Bug in builtins.def, the execve. don't use execle, use execel.

The more easy specification will be int execel(const char *path, const char *arg0, char *const envp[], ... /*, (char *)0*/); with same functionality but reordered the parameters of the function following the general pattern of putting '...' in the last position. Don't blame gcc

Re: Dataflow question

Rask Ingemann Lambertsen wrote: I have a simple loop over the defs of an INSN, looking for the def of a specific register X: Should I just compare register numbers instead? I think so, or maybe even use reg_overlap_mentioned_p. It depends what you're doing. For 4.4, it may be worth mo

Re: PR1634: Request for gcc-cvs-patches list

Do people think it is a good idea to have a gcc-cvs-patches list (or gcc-svn-patches, also fine), where all patches automatically get sent to, exactly as they are committed to SVN (maybe in gzip'ed form)? This would have been especially useful before GCC started using SVN, but even today there

Re: structuring a front-end subdirectory

>> It would seem to me that if everything was moved to libada, this >> would not be necessary anymore. > > Besides our move to svn, a primary goal of the suggested change > is to move this set of sources out of a more general grabbag, to > clarify their specific purpose and simplify the grabba

Re: structuring a front-end subdirectory

A number of these sources are indeed shared (some compiler sources are used by the library and/or some tools) and moving them is not straightforward. Would it be possible to add a --enable-small option to libada, which would enable compilation of the subset used by GNAT? Then, one could

Re: Limits of stage3 changes

My favorite example of this lack of follow-through is gcse.c. It computes reg-def chains and monotonic insn IDs. Guess what df-scan provides? This is great. I did that for combine and CSE, but I didn't know GCSE as well. From the description from my first read I like this patch, and I thi

Re: Newbie

If it is possible, I would like to begin with a small project to get familiar with GCC code. I have been through the "Simple GCC projects" web page and I would be interested in project such as "Convert reorg.c to use the flow graph". Could someone help me to get involved ? I cannot but reinfo

Re: GCC 4.3.0 Status Report (2007-11-04)

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00842.html I had already approved this. Paolo

Re: $RANLIB not passed to libiberty

Is there a way of using a different ranlib for building the stage1 compiler than for stage2 and stage3 (other than using a combined tree)? I don't remember one. Remember though that when using a combined tree you can drop in only the binutils directory, and use the system gas/ld. Paolo

Re: How to avoid common subexpression elimination under this situation?

In RTL level, it is difficult to reverse the optimization. In our 3.4.6 -based porting, the GCC actually generates the latter code. How to avoid CSE under such situation? Any suggestion is greatly appreciated. You are probably not defining the ADDRESS_COST or (if you have no ADDRESS_COST hook

Re: What is a regression?

I think this is a very important point. If it didn't block a previous release, it shouldn't block the current release. It doesn't mean it shouldn't get looked at, but it also shouldn't be a blocker. I think the high priority regressions should be ones that are new to 4.3 because they have c

Re: one question: tree-ssa vs no tree-ssa? no such global optimization exists.

* Was it useful the implementation of the complicated tree-ssa code waited for long time (many years)? * Was it better the optimization without tree-ssa code? Why in a style like Yoda these questions you are asking? He not speaks like Yoda, uses the order for words that is in Spanish (no

Re: From SSA back to GIMPLE.

J.C. Pizarro wrote: Are they mixed into a single variable declaration? Are they treated as separate variables and handled later by the register allocator? If possible, the former. If not possible, they are kept as separate variables. This happens if the subscripted variables have overlappi

Re: Preparsing sprintf format strings

Andreas Schwab writes: The compiler is supposed to know the encoding of the strings. The compiler can't in general know what encoding that printf, fprintf, and sprintf will use to parse the string. It's locale dependent. It is undefined what happens if you run a program in a different char

Re: Preparsing sprintf format strings

Andreas Schwab wrote: [EMAIL PROTECTED] (Ross Ridge) writes: The entire parsing of the format string is affected by the multi-byte character encoding. I don't know how GCC would be able tell that a byte with the same value as '%' in the middle of string would actually be interpreted as '%' cha

Re: Preparsing sprintf format strings

It's too far-fetched for my tastes. I think gcc should not do it. How gcc can know what printf() and puts() mean in *my* libc? Well, that's what -fno-builtin is for. More precisely, -ffreestanding. I think such optimizations should be done in glibc. The point is that you can't. GCC knows i

Re: $RANLIB not passed to libiberty

ply it. Paolo 2007-09-27 Paolo Bonzini <[EMAIL PROTECTED]> * Makefile.tpl (AR_FOR_BUILD, AS_FOR_BUILD, CXX_FOR_BUILD, DLLTOOL_FOR_BUILD, GCJ_FOR_BUILD, GFORTRAN_FOR_BUILD, LDFLAGS_FOR_BUILD, LD_FOR_BUILD, NM_FOR_BUILD, RANLIB_FOR_BUILD, WINDMC_FOR_BUILD, W

Re: Which RTL pass should handle REG_EQUAL notes?

Uros Bizjak wrote: Hello! I would like to bring a strange optimization problem to the attention of RTL expert. The problem is outlined in PR rtl-optimization/33353, the core of the problem is that passes that follow RTL fwprop1 pass simply don't process REG_EQUAL notes that mark constant resu

Re: GCC 4.3.0 Status Report (2007-09-04)

There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. As much as I like the idea, wasn't get_non_trapping considered unsafe? Paolo

Re: recent troubles with float vectors & bitwise ops

given that we know that the processor supports bitwise-or on floating point values, using a instruction different from that for bitwise-or on integer values, then it is fair to ask why we don't support vector | vector for floating point vectors. Because processors may add weird instructions for

Re: recent troubles with float vectors & bitwise ops

If there is a reason to put in that obstacle--e.g., because we are implementing a language standard and the language standard forbids it--then fine. But citing a PowerPC specific standard to forbid code appropriate for the x86 does not count as a sufficient reason in my book. The code I want to

Re: recent troubles with float vectors & bitwise ops

Let's assume that the recent change is what we want, i.e., that the answer to (1) is "No, these operations should not be part of the vector extensions because they are not valid scalar extensions." So, that means we need to answer (2). We still have the problem that users now can't write machi

Re: recent troubles with float vectors & bitwise ops

"The types defined in this manner can be used with a subset of normal C operations. Currently, GCC will allow using the following operators on these types: +, -, *, /, unary minus, ^, |, &, ~.". What was missing is "when allowed by the base type". E.g. >> is not supported. I think we should

Re: recent troubles with float vectors & bitwise ops

# cat regressionorbugfix.cc typedef float v4sf_t __attribute__ ((__vector_size__ (16))); typedef int v4si_t __attribute__ ((__vector_size__ (16))); v4sf_t foo(v4sf_t a, v4sf_t b, v4sf_t c) { return a + (b | c); } v4sf_t bar(v4sf_t a, v4sf_t b, v4sf_t c) { return a + (v4sf_t) ((v4si_t) b

Re: recent troubles with float vectors & bitwise ops

GCC makes the problem is even worse if only SSE and not SSE 2 instructions are enabled. Since the integer bitwise instructions are only available with SSE 2, using casts instead of intrinsics causes GCC to expand the operation into a long series of instructions. This was also a bug and a patch

Re: recent troubles with float vectors & bitwise ops

tbp wrote: Paolo Bonzini wrote: To some extent I agree with Andrew Pinski here. Saying that you need support in a generic vector extension for "vector float | vector float" in order to generate ANDPS and not PXOR, is just wrong. That should be done by the back-end. I guess i fai

Re: recent troubles with float vectors & bitwise ops

"The types defined in this manner can be used with a subset of normal C operations. Currently, GCC will allow using the following operators on these types: +, -, *, /, unary minus, ^, |, &, ~.". What was missing is "when allowed by the base type". E.g. >> is not supported. Paolo

Re: recent troubles with float vectors & bitwise ops

Why did Intel split up these instructions in the first place, is it because they wanted to have a seperate vector units in some cases? I don't know and I don't care that much. To some extent I agree with Andrew Pinski here. Saying that you need support in a generic vector extension for "vec

Re: recent troubles with float vectors & bitwise ops

The IA-32 instruction set does distignuish between integer and floating point bitiwse operations. In addition to the single-precision floating-point bitwise instructions that tbp mentioned (ORPS, ANDPS, ANDNPS and XORPS) there are both distinct double-precision floating-point bitwise instructio

Re: Why is building a cross compiler "out-of-the-box" always broken?

Rask Ingemann Lambertsen wrote: On Sun, Aug 19, 2007 at 10:09:25AM +0200, Paolo Bonzini wrote: Thanks for reminding me to ping that patch. Could you try moving this case statement + case "$target" in + i[[3456]]86-*-elf* | i[[3456]]86-*-coff*) + libglos

Re: recent troubles with float vectors & bitwise ops

Apparently enough for a small vendor like Intel to propose such things as orps, andps, andnps, and xorps. I think you're running too far with your sarcasm. SSE's instructions do not go so far as to specify integer vs. floating point. To me, "ps" means "32-bit SIMD", independent of integerness

Re: Implementing VMX128 AltiVec Variant

Gordan Bobic wrote: On Tue, 21 Aug 2007, Ian Lance Taylor wrote: With the modifications I made, GCC still compiled fine. However, libgcc and libstdc++ DO still get build with the missing instructions (according to objdump -D). Why is that? Is that a consequence of the ADA files? Or something el

Re: Why is building a cross compiler "out-of-the-box" always broken?

Thanks for reminding me to ping that patch. Could you try moving this case statement + case "$target" in + i[[3456]]86-*-elf* | i[[3456]]86-*-coff*) + libgloss_dir=i386 + ;; + m68hc11-*-* | m6811-*-* | m68hc12-*-* | m6812-*-*) + libgloss_

Re: missing libtool sources?

I think we should adjust the Libtool sources in this case. While CVS HEAD's ltmain.sh is generated from ltmain.m4sh, and we prefer patches against the latter file, the former is definitely in a source code form that makes modifications just as easy: both are shell scripts without lots of redundan

Re: bootstrapping with -fopenmp

Razya Ladelsky wrote: Hi, I'm trying to bootstrap (parloop branch) with -ftree-parallelize-loops=4, which requires also -fopenmp. I'm using: make BOOTCFLAGS="-O2 -ftree-parallelize-loops=4 -fopenmp" bootstrap -j 16 I'm failing at the begining of stage2 because the compiler can't find libgomp

Re: reload question

Pat Haugen wrote: Is this being done on purpose (going on assumption that operands are commutative), such as to allow more opportunities for a successful allocation with reduced spill? I think so, but reordering the "else if"s should improve the results. I've also seen the same situation come

Re: Bootstrap failed on i386-pc-solaris2.10

Making the change above results in a successful build. Quite a difference what a '+' can make. This patch works fine on Linux/x86 and Linux/x86-64. Thanks! Paolo

Re: Bootstrap failed on i386-pc-solaris2.10

CRTSTUFF_T_CFLAGS_S = $(CRTSTUFF_T_CFLAGS) -fPIC How do you use +=? Sorry, I was looking at an old checkout. Could you simply test patching config/i386/t-crtstuff like this: -CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer -fno-asynchronous-unwind-tables +CRTSTUFF_T_CFLAGS += -fno-omit-frame-po

Re: Bootstrap failed on i386-pc-solaris2.10

That is what I missed. Thanks. This patch should work. Sure, but it makes the mess even worse. You should instead: - in config/t-svr4, change the two CFLAGS assignments to use += - in config/i386/t-sol2, change the CRTSTUFF_T_CFLAGS assignment to "+= -O2" and remove the TARGET_LIBGCC2_CFLA

Re: top-level configure

Ralf Wildenhues wrote: Hello, a gentle reminder for: Ok. Paolo

Re: RFC: Rename Non-Autpoiesis maintainers category

I really do not like the current name either, but i do not have a better one. Since the whole file is about MAINTAINERS, I would suggest changing the categories to: - Committers (i.e. committing maintainers) - Reviewers (i.e. reviewing maintainers) - Non-algorithmic committers Paolo

Re: g++ 4.3, troubles with C++ indexing idioms

For performance small arrays should be the same as individual members (I can see the annoying fact that initialization is a headache - this has annoyed me as well). For larger arrays (>4 members), aliasing will make a difference possibly, making the array variant slower. Any union variant is e

Re: no_new_pseudos

"Joe can open the door during the meeting" could mean "Joe is able to open the door (e.g., he has the keys)" or "from time to time, Joe will open the door during the meeting (e.g., it has been known to happen)." But I agree that it doesn't seem to be used that way in gcc. And in compilers in

Re: no_new_pseudos

I am going to argue that it was a bug that we did not allow new pseudos after flow had ran. And that we should have always allowed pseudos before the register allocator. Since flow was so broken, we could not, we added the hack no_new_pseudos get around that problem. Now we are saying it is a

Re: Problem with std_expand_builtin_va_start on targets where sizetype and ptr_type_node don't have the same mode

libstdc++'s bitmap_allocator.cc, because for some reason reload wants a MODE_PARTIAL_INT mode with 64 bits. There is no such mode, so get_smallest_mode_for_size aborts. I am attaching the .lreg and .greg dumps to this message (compressed). Naively speaking, shouldn't it also look for MODE_IN

Re: PATCH: Add myself as libbid maintainer

I'm also uncertain as to just who approved the commit of libgcc/config/libbid into mainline. When I look at the code I see Both x86 maintainer and build/libgcc maintainer reviewed the patch. Note that build != libgcc maintainer. One may argue whether a libgcc maintainer's approval is needed

Re: Decimal float and the Cygwin build of GFortran.

Brian Dessent wrote: Angelo Graziosi wrote: ./configure --prefix=${prefix_dir} \ According to the documentation you should not do this (build in the same dir as the source.) This is just less tested, not unsupported. If people report bugs related to "./configure" builds, we'll

Re: no_new_pseudos

Kenneth Zadeck wrote: I do not remember if it was stevenb or bonzini that observed that because of changes that came with the dataflow branch it is now trivial to get rid of no_new_pseudos. For the record, this was Steven's observation. And Kenner confirming that this was the original purpose

Re: Turning a scope block into not-quite-a nested function?

So there we are. Any suggestions? If I understand correctly, nested functions *are* what you want and there is code to do exactly what you want in the implementation of OpenMP. However, I am not into that code enough to give you any further hint. Paolo

Re: [ARM] Cirrus EP93xx Maverick Crunch Support - "bge" pattern

if (get_attr_cirrus (prev_active_insn(insn)) == CIRRUS_COMPARE) return \"beq\\t%l0\;bvs\\t%l0\"; else return \"bge\\t%l0\;nop\"; " [(set_attr "conds" "jump_clob") (set_attr "length" "8")] ) As you can see, I need to replace all bge with a maverick crunch equivalent. However, "bg

Re: old intentional gcc bug?

The differences you are seeing now are likely caused by differences in autoconf configuration for the case of GCC compiler versus non-GCC compiler. One of the results of toplevel bootstrap is to eliminate these differences in autoconf configuration. Paolo

Re: m68k bootstrap problem

+ + /* However a may or must clobber still still needs to +kill the reg. */ Add here "so that REG_DEAD notes are later placed appropriately". Ok, thanks! Paolo

Re: m68k bootstrap problem

This is one of the places where i slavishly copied what flow did. if you want to change this, go test it on at least 7 platforms and fix all of the problems that it causes. I see. Can one of you recap how it relates to the m68k problem, though? :-) Paolo

Re: m68k bootstrap problem

having the dead note there is asserting to the register allocator that they are free to use that reg after the calll in any way that it wants and there is a (small) possibility that is wrong. IMO there is nothing wrong with this. I agree with Roman. You can always put your call into an asm

Re: virtual stack regs.

ARG_POINTER_REGNUM is included in the artificial defs of all blocks (which I think is overly conservative - just having them in the entry block def should be enough). Hence, from dataflow point of view, they are always considered initialized. I think we should probably do something similar for

Re: Where can I find "sizeof" implementation in front end

[EMAIL PROTECTED] wrote: > Hello all: > > I am reading codes of gcc front end. But I can not find the implementation > of "sizeof". How does gcc front end calculate size of UNION and STRUCT? > Where is the codes for these work. Can anybody give me some advices? Thank > you so much ! The code is h

Re: Activate -mrecip with -ffast-math?

OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply 'wrong', not inaccurate ;) I still support the introduction of a special switch for this kind of transformation, -fwrong-math-optimizations. :-) Paolo

Re: PR other/32351 [Was: Re: GCC Status Report (2007-06-15)]

It is a libdecnumber bug, which only affects x86. The patch is ok. Paolo

Re: Some thoughts about steerring commitee work

Fortunately gcc 4.3 will have also faster compilation speed than 4.2 even with the df infrastructure (which may be, and I hope, helps to improve the code finally). That is because some work was done to speed up tree-SSA infrastructure (and Paolo Bonizini's frwprop) to improve the compilation

[PATCH] Fix breakage

Sorry, I committed the wrong version of the patch. 2007-06-14 Paolo Bonzini <[EMAIL PROTECTED]> * configure.ac: Fix earlier checkin. * configure: Regenerate. Index: configure.ac === --- config

Re: LOG_LINKS information after dataflow merge

Rask Ingemann Lambertsen wrote: LOG_LINKS are gone. Where do I find the equivalent information in a dump file now? LOG_LINKS are now stored in a side array. Adding some dumps in create_log_links would be a good idea indeed. Paolo

Re: Dataflow bug [RE: Large number of fortran testsuite failures]

Hmm, this looks like a dataflow bug to me. I believe the problem is that DF_LIVE_OUT assumes/requires problems_by_index[DF_LIVE] to be non-NULL. You should replace it with df_get_live_out. Please CC me if you have a patch. Paolo

Re: use of %n in genmodes.c causes trouble on Vista

printf (_("foo %s%n"), some_string, &n); is ok even with -D_FORTIFY_SOURCE=2 How is this considered ok? Is _("abc") placing the translation in non-writable memory? Paolo

Re: use of %n in genmodes.c causes trouble on Vista

the return value of sprintf). This would be pretty easy: 2007-06-06 Paolo Bonzini <[EMAIL PROTECTED]> * genmodes.c (tagged_printf, emit_insn_modes_h): Don't use %n on printf. Index: genmodes.c === ---

Re: help required for upgradation of gcc-4.1.1

3. ./configure Read the instructions. Building in the source directory is not supported. Often buggy and thus not suggested, but in principle supported. Paolo

Re: [dataflow] partial register handling

But I don't think that's enough, with the current loop it would strip the subreg of a multiword subreg and there is some logic in df_ref_record, which wouldn't see it. An alternative might be: while (GET_CODE (dst) == STRICT_LOW_PART || GET_CODE (dst) == ZERO_EXTRACT) { f

Re: BOOT_CFLAGS and gcc trunk

Jack Howarth wrote: I am puzzled about the proper use of BOOT_CFLAGS with gcc trunk. Apparently on Darwin we need to use BOOT_CFLAGS=-g -O2 -mdynamic-no-pic. However when I try... That's an optimization, actually, and one that is broken right now (PR32009). I'm waiting for feedback on that

Re: 4.3 release plan

I got the second one too. Italians must be good at acronyms. :-) IMBGAA! ...BTTOWWTD!!! PBTMAICFOTL (Probably better than me as I cannot figure out the latter). On the other hand, it may mean that we can skip stage2 altogether, since we had stage2 during stage1 for 4.3... I'm definitely

Re: 4.3 release plan

M 1 - YMMV, YGWYPF, PPINGOFR I got the first two, but what does the last one mean? Wow, you're impressive... The second one I thought would be too cryptic for all. I got the second one too. Italians must be good at acronyms. :-) BTW, the tentative timeline says that 4.3 stage 1 will end

Re: Problems with compiling svn trunk [libdecnumber]

You are compiling in the source directory which is not a well supported way of compiling GCC. Yeah, but I wasn't and still ran into that (or similar) problem. :) Anyway, this patch solves it: Index: libgcc/configure.ac === ---

Re: [dataflow] partial register handling

Richard Sandiford wrote: Paolo Bonzini <[EMAIL PROTECTED]> writes: My opinion: (set (subreg:HI (reg:SI) 2) ... DF_REF_READ_WRITE? yep, only case without PARTIAL Sorry if this is a daft question, but why would it be treated as a read? I thought that without strict_lowpart, this s

Re: [dataflow] partial register handling

The rules should be simple. Bits of the dest reg survive only if one of the following is true. - there is a STRICT_LOW_PART (of a SUBREG) - there is a ZERO_EXTRACT (not necessarily of a SUBREG!) - the subreg is part of a multiword subreg So, this is a prototype patch that I would like to

Re: [dataflow] partial register handling

First of all, scrap my other message... There was a debate several months ago on this issue: how much should the df scanner be a theorem prover with respect to how many bits survive an operation. For instance, I could easily add to your list, anding and oring operations which also preserve bits.

Re: [dataflow] partial register handling

My opinion: (set (subreg:SI (reg:DI) 4) ... DF_REF_READ_WRITE|DF_REF_PARTIAL? yep (set (subreg:HI (reg:DI) 6) ... DF_REF_READ_WRITE? Also PARTIAL. you can rely on the content of the 0-3 word. Likewise for: (set (subreg:HI (reg:DI) 2) ... here you can rely on the content of the 4-7 wo

Re: Clarification request for ipa/cgraph code

Mike Stump wrote: In ipa-type-escape.c we have: /* Return either TYPE if this is first time TYPE has been seen an compatible TYPE that has already been processed. */ I'd fix it, if I knew I knew what it meant. either, an and that are the things that are confusing to me. Return TYPE i

Re: Mercurial repository set up for GCC that mirrors SVN

Ollie Wild wrote: Just another data point, my git-svn clone of trunk comes in at 414MB, excluding the size of checked out files. I'm assuming the public svn is the complete history. I'm about 35% through the process of cloning the entire gcc repository via git-svnimport, and the .git directory

Re: live insns deleted by delete_trivially_dead_insns()

Paolo Bonzini wrote: Even if CONST_OR_PURE_CALL_P is set to 1??? :-( I don't know, but in any case __tls_get_addr is neither pure nor const rs6000 says it is, I should try doing the same for x86-64 and see what happens. See the patches I've posted; with those I

Re: live insns deleted by delete_trivially_dead_insns()

Even if CONST_OR_PURE_CALL_P is set to 1??? :-( I don't know, but in any case __tls_get_addr is neither pure nor const rs6000 says it is, I should try doing the same for x86-64 and see what happens. (and for non-TLS libcalls, we don't have to know because we never make them dead anyway ;-)

Re: live insns deleted by delete_trivially_dead_insns()

But without libcall notes, we just see a call_insn and a set to a hard register, and we have no way to tell that the call_insn is dead and can safely be removed. Even if CONST_OR_PURE_CALL_P is set to 1??? :-( Paolo

Re: live insns deleted by delete_trivially_dead_insns()

Because it's the semantics of libcall sequences. My take is that the lower subreg pass breaks it in this case. I could "fix" it at -O2 with -fno-split-wide-types or at -O1 with -fno-move-loop-invariants or -fno-split-wide-types. Can you also check -fno-forward-propagate? Yes. It'll

Re: live insns deleted by delete_trivially_dead_insns()

Eric Botcazou wrote: It isn't until the loop2_done dump that the problem shows up. delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully replacing reg 92 with const_int 0, determines that the while l

Re: REG_NO_CONFLICT vs lower-subreg

Ian Lance Taylor wrote: Paolo Bonzini <[EMAIL PROTECTED]> writes: I suppose we could add a target macro to let individual ports turn off REG_NO_CONFLICT generation? Any other ideas? A pass to reorder insns so that live ranges are shortened and register pressure is relieved. I thi

Re: REG_NO_CONFLICT vs lower-subreg

I suppose we could add a target macro to let individual ports turn off REG_NO_CONFLICT generation? Any other ideas? A pass to reorder insns so that live ranges are shortened and register pressure is relieved. Could be something like for each bb for each insn for each active insn

Re: GCC 4.2.0 Status Report (2007-04-15)

30786 is ICE-on-invalid. 30805 is ICE-on-unspecified. I don't like ICEs but these don't seem like release-blockers to me. Anyway I attached prototype patches for these. I don't have resources to test them for three weeks, so if anybody can beat me to it... Paolo

Re: Questions/Comments regarding my SoC application

Hi! Initially I meant to optimize GCC, that includes runtime and memory usage, of course. Sure. I meant that we have testcases that are good to test your work on. Profile GCC running them and fix the hotspots: this may show quadratic algorithms, and the like. For example, see the patch

Re: [MIPS] MADD issue

This should be a post-reload (i.e. predicated on reload_completed) split, I think. Actually, with the relatively recent lower-subreg work, it is desirable to split this sort of instruction before reload. That is, do an unconditional split. Right. Combine cannot cope with the resulting 4-in

Re: [MIPS] MADD issue

(define_insn "adddi3_internal_1" [(set (match_operand:DI 0 "register_operand" "=d,&d") (plus:DI (match_operand:DI 1 "register_operand" "0,d") (match_operand:DI 2 "register_operand" "d,d"))) (clobber (match_operand:SI 3 "register_operand" "=d,d"))] "!TARGET_64BIT &

how to regenerate automake files

I just found out that just running "automake" is not enough if you have installed Autoconf 2.59 as "autoconf-2.59", and a newer Autoconf as just "autoconf". You have to do AUTOM4TE=autom4te-2.59 automake (possibly something like "AUTOM4TE=autom4te-2.59 automake-1.9"). I thought that shari

Re: RFC: GIMPLE tuples. Design and implementation proposal

If you go this way (and require special GC/debugger support) you could as well xor next/prev too and save another field. Adding a xor is basically free and much cheaper than any cache miss from larger data structures. The only thing that wouldn't work is that when you have a pointer to an arbi

Re: RFC: GIMPLE tuples. Design and implementation proposal

I don't really like the idea for promoting subcodes to first-level codes, like you do for GS_COND NE and EQ. Looks complicated and confusing to me. What is the benefit of this? Fully agreed with Steven (also on the locators bit). Paolo

Re: VAX backend status

I've noticed a few things in doing the above. GCC 4.x doesn't seems to do CSE on addresses. Because the VAX binutils doesn't support non-local symbols with a non-zero addend in the GOT, PIC will do a define_expand so that (const (plus (symbol_ref) (const_int))) will be split into separate inst

Re: Questions/Comments regarding my SoC application

Dennis Weyland wrote: > Hi! > > I've applied for Google's Summer of Code 2007 with GCC as mentor > organization. I want to make GCC working faster on the algorithmic > level. I left out the detailed aims of the project, since i want to > discuss them with gcc developers/mentors first. Do you have

Re: nested backticks in Makefile

DJ Delorie wrote: > Ok, I suppose, as long as the backticks still get expanded. They do, ~ bonzinip$ echo "`echo abc`" abc Paolo

Re: nested backticks in Makefile

Dave Korn wrote: > On 27 March 2007 18:25, Andreas Schwab wrote: > >> "Dave Korn" <[EMAIL PROTECTED]> writes: >> >>> Or how about using ':=' to force immediate evaluation? >> That won't help, since backquotes are only expanded by the shell, not by >> make. > > Doh. Yes, we'd need immediate e

Re: how to obtain SSA form

Andrea Callia D'Iddio wrote: > I looked for "into" and "ssa" in passes.c, but I've not found > anything. "into" does not give much indeed. But ssa should point you to pass_build_ssa and pass_del_ssa, which should reveal a lot. > Also I tried with options -fdump-tree-ssa and -O1 but, when > my pa

Re: A question on ACX_BUGURL

H. J. Lu wrote: > On Mon, Mar 26, 2007 at 09:13:30AM +0200, Paolo Bonzini wrote: >> Please do this instead: >> >> [EMAIL PROTECTED] "$BUGURL" | sed 's/@/@@/g'`} >> > > Will it work with spaces in $BUGURL? Yes, it will. You need quoting in

Re: A question on ACX_BUGURL

Andreas Schwab wrote: > Paolo Bonzini <[EMAIL PROTECTED]> writes: > >>> + no) BUGURL=""; >> just BUGURL= (no useless trailing semicolon). >> >>> + case ${BUGURL} in >> Please quote this as "$BUGURL". > > That would

Re: A question on ACX_BUGURL

> + no) BUGURL=""; just BUGURL= (no useless trailing semicolon). > + case ${BUGURL} in Please quote this as "$BUGURL". > +REPORT_BUGS_TO="<$BUGURL>" > +REPORT_BUGS_TEXI="@uref{`echo $BUGURL | sed 's/@/@@/g'`}" Please do this instead: [EMAIL PROTECTED] "$BUGURL" | sed 's/@/@@/

<    2   3   4   5   6   7   8   9   10   11   >