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: [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

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

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: 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: 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: 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: 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: [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: 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: 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: 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: 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: 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

[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: 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

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: 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: 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: 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: 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: 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

+ + /* 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: 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: [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: 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: 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 ori

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: 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: 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: 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: 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: 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: 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: top-level configure

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

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: 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

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: 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: 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: 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: 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: 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: 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: 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

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: 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 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

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

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

# 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

"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

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

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

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: 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: 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: $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: 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: 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: 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: 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: 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: 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: $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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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

Is there an alternative to "git repack -a -d" that repacks everything but the first pack? That would be a pretty good idea for big repositories. If I were to implement it, I would actually add a .git/config option like pack.permanent so that more than one pack could be made permanent; then

Re: Something is broken in repack

I'm thinking about "git clone --keep" to mark initial packs precious. But 'git clone' is under rewrite to C. Let's wait until C rewrite is done. It should be the default, IMHO. Paolo

Re: CSE deletes valid REG_EQUAL?

On 17/11/20 02:12, Jeff Law wrote: Removing all REG_EQUAL notes for regs that become dead anywhere That's not what it does. seems to just be a thinko? All pseudos are dead somewhere! (Yeah okay, infinite loops, but other than that.) Yea, but the code which wipes the notes probably has no

<    6   7   8   9   10   11