defunct fortran built by default for cross-compiler

When I configure an sh-elf cross tool chain without a specific --enable-languages option (which used to work with gcc 4.2), I get: The following languages will be built: c,c++,fortran,java,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-l

Re: defunct fortran built by default for cross-compiler

Steven Bosscher wrote: So you don't report any error messages at all and leave us guessing? AFAIK fortran is not supposed to be configured at all for a cross-compiler. Or has that changed recently? It was certainly not configured in my previous builds of gcc 4.2 snapshots.

Re: defunct fortran built by default for cross-compiler

Joern Rennecke wrote: It appears that most of the errors are of the form: collect-ld: cannot find -lgfortranbegin I've found that the problem was related to configure deciding to build fortran and enable runtime tests for it when doing check-gcc even though libgfortran was not present;

Re: Canonical type nodes, or, comptypes considered harmful

> I can dig out actual real live numbers, if you're curious. For example, when calling comptypes, the no answers are (were) 34x more likely than yes answers. If you cannot return false immediately when point_to_type1 != pointer_to_type2, you then have to run a structural equality tester, and on

Re: Canonical type nodes, or, comptypes considered harmful

Mike Stump wrote: Now, what are the benefits and weaknesses between mine and your, you don't have to carry around type_context the way mine would, that's a big win. You don't have to do anything special move a reference to a type around, that's a big win. You have to do a structural wa

libgfortran still fails to build for sh-elf

/home/amylaar/bld/2006-11-10/sh-elf-multi/./gcc/xgcc -B/home/amylaar/bld/2006-11-10/sh-elf-multi/./gcc/ -nostdinc -B/home/amylaar/bld/2006-11-10/sh-elf-multi/sh-multi-elf/newlib/ -isystem /home/amylaar/bld/2006-11-10/sh-elf-multi/sh-multi-elf/newlib/targ-include -isystem /home/amylaar/bld/2006

Re: libgfortran still fails to build for sh-elf

François-Xavier Coudert wrote: I suggest that you test the following patch and report back to us: I got the patch wrong (it's not a real printf function we have there): Index: libgfortran/runtime/error.c === --- libgfortran/runt

Re: 32 bit jump instruction.

In http://gcc.gnu.org/ml/gcc/2006-12/msg00328.html, you wrote: >> On 06 Dec 2006 23:13:35 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> If you can't afford to lose a register, then I think your only option >> is to pick some callee-saved register and have each branch instruction >

Re: RFC: vectorizer cost model

> As a first step, to stay on conservative side, it makes sense > consider the scalar cost of smaller block while calculating scalar cost. > Note, smaller block may not exist. I think that this should be considwered quite common. We should base the weights of the costs of the two blocks on branch

Re: RS6000 call pattern clobbers

> > Do you remember why you wrote the call patterns this way? Was > > there a problem with reload and clobbers of hard registers in a register > > class containing a single register or some other historical quirk? > > I think the former. I no longer remember the details, but if you had > a clobb

Re: new auto-inc-dec pass

In http://gcc.gnu.org/ml/gcc/2007-03/msg00128.html, you wrote: > One case is about multiple increments, the tree optimizer merges them and > increments the register only once, so if one only looks at the size of the > pointer value one misses them, e.g. something like this: > > (set (mem (reg

RFC: integer division by multiply with invariant reciprocal

The strategy that the SHMEDIA port uses to do cse and loop invariant code motion for division by invariant reciprocal can in principle be used by any processor that has a reasonable fast instructions for count leading sign bits (can be substituted with count leading zero bits), widening or highpart

Re: core changes for mep port

In http://gcc.gnu.org/ml/gcc/2007-03/msg01007.html, Steven Bosscher wrote: > All of this feels (to me anyway) like adding a lot of code to the > middle end to support MEP specific arch features. I understand it is > in the mission statement that more ports is a goal for GCC, but I > wonder if this

Re: Hot and Cold Partitioning (Was: GCC 4.1 Projects)

Dale Johannesen wrote: Well, no, what is supposed to happen (I haven't tried it for a while, so I don't promise this still works) is code like this: .hotsection: loop: conditional branch (i?==1000) to L2 L1: /* do stuff */ end loop: /* still in hot section */ L2: jmp L3 .coldsection: L3

Re: Hot and Cold Partitioning (Was: GCC 4.1 Projects)

Dale Johannesen wrote: Certainly. In general it will make the total size bigger, as does inlining. If you have good information about what's hot and cold, it should reduce the number of pages that actually get swapped in. The information has to be good, though, as a branch from hot<->cold

Re: Hot and Cold Partitioning (Was: GCC 4.1 Projects)

Dale Johannesen wrote: No, you should not turn on partitioning in situations where code size is important to you. You are missing the point. In my example, with perfect profiling data, you still end up with more code in the hot section, Yes. i.e. more pages are actually swapped in. Unles

Re: Questions about trampolines

>> Any alternatives that would work for Harvard Architecture devices such as the AVR would be welcome. There are no alternatives that do not have an overhead in the case where pointers to nested functions are *not* used, which seems unacceptable in C. You could introduce some kind of pragma for a

Re: Questions about trampolines

Clifford Wolf wrote: Hi, On Wed, Mar 16, 2005 at 01:50:32PM +, Joern RENNECKE wrote: These can be provided in a separate module of the static libgcc, together with allocation and deallocation of individual trampolines from the pool (the latter has to be called from the epilogue of functions

Re: Questions about trampolines

Clifford Wolf wrote: hmm.. what's about doing it gc-like. Instead of a stack there simply is a 'pool' of trampolines from which trampolines are allocated and a pointer to the trampoline is pushed on the stack. When the last trampoline from the pool is allocated, a 'garbage collector' is runnin

Re: Questions about trampolines

Clifford Wolf wrote: Some applications have recursions which go into a depth of 1000 and more. Some architectures have only a few k ram. Which "a size that works most of the time" would you suggest? It's ugly to have a static pool size. But it's intolerable to not allow the user to change that

Re: Questions about trampolines

Robert Dewar wrote: Joern RENNECKE wrote: Of course the user can change the size, by using a library with a different size. This is not an acceptable approach in a production environment, where switching libraries can force revalidation and retesting. This sounds more like a problem with your

Re: Questions about trampolines

Robert Dewar wrote: Joern RENNECKE wrote: You need to be able to set the value of a parameter over a widely varying range, what makes you think you can pick two values that will cover all cases, or 4 or 6 for that matter. It will likely cover most, but not all cases. With 12 values, you can

RFC: ms bitfields of aligned basetypes

t001_x of the struct-layout test has such beauties as: typedef _Bool Tal16bool __attribute__((aligned (16))); struct S49 { Tal16bool a:1; } ; . a only gets BIGGEST_ALIGNMENT (i.e. 64 bits), rather than the 128 bits required for Tal16bool. Should we enforce that any storage element allocated for

Re: RFC: ms bitfields of aligned basetypes

Danny Smith wrote: Jim Wilson wrote http://gcc.gnu.org/ml/gcc/2005-04/msg01172.html Joern RENNECKE wrote: required for Tal16bool. Should we enforce that any storage element allocated for a run of ms-bitfields get the full alignment of the basetype, even when it exceeds

Re: RFC: ms bitfields of aligned basetypes

A testcase to trigger the assert was: typedef _Bool Tal16bool __attribute__ ((aligned (16))); struct S49 { Tal16bool a:1; }; and it turns out that the underlying problem is actually in the general-purpose field layout code. Both known_align and actual_align are calculated as BIGGEST_ALIGNMENT if

Another ms-bitfield question...

t002.x has this code: typedef unsigned short int Tal16ushort __attribute__ ((aligned (16))); struct S460 { unsigned long int __attribute__ ((packed)) a; Tal16ushort __attribute__ ((aligned)) b:13) - 1) & 15) + 1); unsigned short int c; }; BIGGEST_ALIGNMENT is 64 for sh64-elf. Does the ((align

ppc-eabisim is broken in mainline

Between 20050505 and 20050510, the ppc-eabisim configuration was broken. I'm seeing this error: /mnt/scratch/nightly/2005-05-10-orv/ppc/./gcc/xgcc -B/mnt/scratch/nightly/2005-05-10-orv/ppc/./gcc/ -nostdinc -B/mnt/scratch/nightly/2005-05-10-orv/ppc/powerpc-eabisim/newlib/ -isystem /mnt/scratch/n

Re: ppc-eabisim is broken in mainline

Andrew Pinski wrote: On May 10, 2005, at 1:54 PM, Joern RENNECKE wrote: Between 20050505 and 20050510, the ppc-eabisim configuration was broken. /mnt/scratch/nightly/2005-05-10-orv/ppc/gcc//:1: Warning: line numbers must be positive; line number 0 rejected That is PR 21250 and this has been

mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

I'm getting these errors: Bootstrap comparison failure! ./bt-load.o differs ./expmed.o differs build/gengtype-lex.o differs I've picked bt-load.o for a closer look because it was the smallest of the affected files. I've found that the register allocation order for branch_target_load_optimize diffe

Re: mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

Andrew Pinski wrote: Actually it is easy to peak at any of them and you will see that the tree optimizators (lim to be in fact) has changed something somewhere. The trouble is that I'm running the tests on Red hat Enterprise Linux, and even with the address randomization allegedly turned

Re: ppc-eabisim is broken in mainline

Aldy Hernandez wrote: * config/rs6000/sysv4.opt (mlittle): Handle. * config/rs6000/rs6000.c (rs6000_handle_option): Set target_flags_explicit when appropriate. Thanks, this allowed my build to complete. It's regression testing now.

Re: Mainline broken

Steven Bosscher wrote: Seems like your forgot the basic-block.h bits in this commit: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00621.html Gr. Steven Sorry. Checked in now.

sh-elf tree-ssa failure

execute/20031215-1.c passes on i686 and ppc, but fails on sh-elf - both SH1 big endian and SH4 little endian, eight times each. It still shows the same failure with mainline from 17:00 UTC today. Executing on host: /mnt/scratch/nightly/2005-05-11/sh-elf/gcc/xgcc -B/mnt/scratch/nightly/2005-05-11

Re: sh-elf tree-ssa failure

Andrew Pinski wrote: Huh, it fails on all targets. -- Pinski Sorry, my bad. It passes at -O0 and -O1 on all targets, and fails at -Os etc on all of them, too. I incorrectly asumed that eight errors per multilib must mean it fails across the board.

RFD: what to do about stale REG_EQUAL notes in dead_or_predictable

I wonder what best to do about rtl-optimization/21767. We sometimes have REG_EQUAL notes that are only true when the instruction stays exactly where it is, like: (insn 11 10 12 0 (set (reg:SI 147 t) (eq:SI (reg/v:SI 159 [ i ]) (reg:SI 161))) 1 {cmpeqsi_t} (nil) (expr_list:RE

RFA: Fix PR21767 (Was: Re: RFD: what to do about stale REG_EQUAL notes in dead_or_predictable)

I've tried removing REG_EQUAL notes altogether unless we know that the source of the move is function invariant, and got identical assembler for all the EEMBC tests as without the patch. Likewise for an entire sh4-elf multilibbed libgcc, libstdc++-v3 and newlib build. I think it is therefore rea

Re: Problem with Delayed Branch Scheduling

So you have a few instructions bundled into a VLIW instruction, and one of the instructions in the bundle is moved into the delay slot, thus breaking your VLIW bundle. Right? That is a much harder problem... I don't think it is really possible with the existing dbr scheduling pass, but maybe

Re: does the instruction combiner regards (foo & 0xff) as a special case?

But I found they fails to match if(foo & 0xff) and if(foo & 0x) These get simplified to foo. Look at the debugging dump before the combine pass to see what you need to match. It doesn't work that way. What you get from there are only the insn numbers. Then you run cc1 (or whatever lan

Re: 206 GCC HEAD regressions, 196 new, with your patch on 2005-08-23T19:50:19Z.

Joern Rennecke wrote: I've started a make check-target-libjava yesterday, in the hope that this would give me a handle on things, but it's still not finished after 22 hours. It's still not finished, but in the meantime I modifed the code to abort in the case where the

java type layout (Was: Re: 206 GCC HEAD regressions, 196 new, with your patch on 2005-08-23T19:50:19Z.)

Joern RENNECKE wrote: java uses char_type_node for its character type, which is 16 bits. gcc/java/decl.c:747 java_init_decl_processing: TYPE_PRECISION (char_type_node) = 16; On the other hand, tree.c uses char_type_node as the type of the smallest addressable unit: tree.c:489

Re: 4.2 Project: "@file" support

> applications will just work, but introducing the very serious risk of > security problems, leading to, say: > > gcc: dj:yourpassword:1234:567:DJ: invalid argument > > instead of > > gcc: @/etc/passwd: invalid argument If you want to use gcc to read a file, you get a closer likeness to the data

MEM_NONTRAP_P and push/pop alias set (Was: Re: [attn port maintainers] fix 23671)

My current thinking is that, with a few exceptions like prologue and epilogue generation, it should be considered a BUG if a port uses gen_rtx_MEM. Almost always one should be using something from the adjust_address family of routines. What are the exact semantics of MEM_NOTRAP_P ? The documen

Re: MEM_NONTRAP_P and push/pop alias set (Was: Re: [attn port maintainers] fix 23671)

Richard Henderson wrote: As a practical short-term concern, rtx_addr_can_trap_p will not return true for any stack based reference, including push/pop. So for 4.1, nothing need be done. Longer term, the answer to the "what does notrap Actually, the SHcompact save / restores use neither

Re: RFC ping: Make regname use validate_change

in http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01489.html I've described a problem where regrename renamed a general register creating an insn which does not satisfy the insn predicate anymore. I agree that regrename shouldn't make such replacements. Constraints are important to drive reload, a

sh64 support deteriorating

I can't justify spending the amount time that it would take to make the sh64 port regression free. The lack of a debugger that works reliably with recent gcc versions has led to an increasing backlog of uninvestigated execution failures.

Re: sh64 support deteriorating

Richard Henderson wrote: On Fri, Sep 09, 2005 at 04:58:50PM +0100, Joern RENNECKE wrote: The lack of a debugger that works reliably with recent gcc versions has led to an increasing backlog of uninvestigated execution failures. Do you think it's the debugger or the compiler that

SH patch applied (Was: Re: sh64 support deteriorating)

Kaz Kojima wrote: some compile time errors in c/c++ test for sh64-unknown-linux-elf http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00466.html 3 tests gcc.c-torture/compile/simd-4.c gcc.c-torture/execute/20050604-1.c gcc.dg/torture/pr21817-1.c fail with the similar ICE: gcc/gcc/testsuite

Re: Retested: RFA: fix PR middle-end/23290

Thanks for the review. Richard Henderson wrote: Though I'll state again for the record that any ABI that bases its decisions on modes instead of tree codes is broken. The specific mode that was tested against was BLKmode. If we want to make ports impervious to random use of BLKmode, we sh

reg_used_between_p vs. CLOBBER

reg_used_between_p checks the CALL_INSN_FUNCTION_USAGE of a CALL_INSN for CLOBBERS. I think it shouldn't; we are interested in uses, not sets/ clobbers.

reload_in conflicts (Was: Re: [patch RFC] SH: PR target/21623)

Kaz Kojima wrote: Joern RENNECKE <[EMAIL PROTECTED]> wrote: Sorry, I forgot that this is specified to depend on fpscr, and that we are running optimize_mode_switching before reload now. This makes this solution unusable for TARGET_FMOVD. This means we need to go the secondary / te

Re: [URGENT] GCC 4.0 Nomination

Joe Buck wrote at http://gcc.gnu.org/ml/gcc/2005-10/msg00075.html : > My suggestion: anyone who is listed in the MAINTAINERS file, and who can > make it to the dinner, could volunteer to accept the award. If more than > one want to go, and the dinner hosts are willing, you can all go up on > sta

Re: Question on Dwarf2 unwind info and optimized code

In http://gcc.gnu.org/ml/gcc/2005-10/msg00823.html, Jim Wilson wrote: > The frame info is primarily used for C++ EH stack unwinding. Since you can't throw a C++ exception in an epilogue, epilogue frame info isn't needed > for this, and was never implemented for most targets. Which is a shame.

svn diff branch woprking copy against mainline?

How do I diff a modified working copy of a branch against a specific version of the mainline? This operation is essential when sanity-checking merges from mainline to a branch of files that have changed more in mainline than in the branch. With cvs, that was as easy as saying: bash-2.05b$ cvs

Re: svn diff branch woprking copy against mainline?

Mike Stump wrote: svn diff --old svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_4_0_1_release/ gcc/file.c --new file.c Thanks, --old / --new does the trick. However, I must say the error message is rather misleading. svn needs to go on a long command line diet, it is seriously no fun to repea

Re: SH: PR target/24445

Kaz Kojima wrote: [.expand after the patch] (set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7))) (set (reg:SI 161) (plus:SI (reg:SI 12 r12) (reg/f:SI 160))) (set (reg/f:SI 159) (mem/u/c:SI (reg:SI 161))) (set (reg:SI 0 r0) (call (mem:SI (symbol_ref:SI ("bar") (set (mem/c/i:S

Re: svn diff branch woprking copy against mainline?

Daniel Berlin wrote: svn needs to go on a long command line diet, True. However, it *does* need some way to differentiate between url->url, url->wc, and wc->url commands, so even if there was an SVNROOT, you'd still have to specify it on the command lines :) I can't follow that rea

Re: svn diff branch woprking copy against mainline?

Daniel Berlin wrote: Of course, the question always raised when you try to do this is "why is this better than just using shell variables" if you can give me a good answer to take back to [EMAIL PROTECTED], i'm happy to shell variable scenario: gcc.gnu.org has a special file that people can

Re: svn diff branch woprking copy against mainline?

Branko Čibej wrote: It certainly seems that --old and --new are redundant. I suggest a search in http://svn.haxx.se/dev/. What should we search for? I tried both of --old and --new, and both searches came up empty. Also, you could consider stealing some ideas from Perforce, where

timezone of svn server for -r?

What timezone does the svn server use when I specify time & date with -r? With cvs that was never an issue because I appended UTC to the time, but svn rejects that, so it seems I have to convert the time into whatever timezone the server happens to use.

diffing directories with merged-as-deleted files?

I've a working copy of a branch in which I merged changes from mainline - including the deletion of the .cvsignore files. When I try to diff a diretory, it errors out on the .cvsignore files. Is there an option not to diff files that don't exist? bash-2.05b$ svn diff --old svn+ssh://[EMAIL

Re: diffing directories with merged-as-deleted files?

Daniel Jacobowitz wrote: On Thu, Nov 03, 2005 at 07:15:22PM +, Joern RENNECKE wrote: Index: gcc/.cvsignore === /usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore (.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)

Re: diffing directories with merged-as-deleted files?

Daniel Jacobowitz wrote: Whatever you want. It should probably either return success, or use -N. I also get a failure when I comment out the diff-cmd line in my ~/.subversion/config . Does that mean that every subversion configuration that doesn't configure a diff-cmd to deal with non-

Re: diffing directories with merged-as-deleted files?

Daniel Jacobowitz wrote: Whatever you want. It should probably either return success, or use -N. P.S.: When I use a diff-cmd with -N, I not only get a diff for the 44 files that are different, but also a header for each of the 752 files that are identical, i.e. two lines for each file

svn repository incorrectly converted or corrupted

cvs version version 1.1.1.1.2.1 of gcc/libjava/classpath/java/awt/im/InputContext.java , i.e. the sh-elf-4_1-branch head, is supposed to correspond to svn+ssh://[EMAIL PROTECTED]/svn/gcc/branches/sh-elf-4_1-branch/libjava/classpath/java/awt/im/[EMAIL PROTECTED] . However, every single line that

Re: svn diff branch woprking copy against mainline?

Branko Čibej wrote: "--old" "--new" Hmm, that finds a lot more, although not specific to options. I've found one thread that seems slightly relevant, Diff syntax changes for issue #1093 . I get the impression that you

Re: svn repository incorrectly converted or corrupted

Daniel Berlin wrote: Simply do a recopy of libjava from the approriate tag, and all will be well. Do you have a list of potentially affected files?

Re: svn diff branch woprking copy against mainline?

Joern Rennecke wrote: but you should be able to name a branch/tag and thus imply a root directory for the location, in the current head revision unless modified with @rev-number (on the branch name) or -D. P.S.: instead of adding a -D option we could also a syntax of -r [EMAIL PROTECTED]

Re: diffing directories with merged-as-deleted files?

> What version of svn? The 1.3 release candidate. > What is the exact branch you are trying to diff?? I had checked out a copy of the sh-elf-4_1-branch, and used svn merge to apply the patches from the last merge point to the current mainline. This merge deleted the .cvsignore file in my workin

Re: diffing directories with merged-as-deleted files?

Daniel Berlin wrote: I did svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch cd sh-elf-4_1-branch svn merge -r106276:106279 svn+ssh://gcc.gnu.org/svn/gcc/trunk . (rev 106276:106279 contains the change that will remove .cvsignore) [EMAIL PROTECTED]:/mnt/gccstuff/sh-elf-4_1-bran

Re: diffing directories with merged-as-deleted files?

Daniel Berlin wrote: Uh, but a diff against the pristine copy is the same as a diff against mainline at that point, since your only differences come from merging the mainline. No, the pristine copy is the pristine copy of the branch. I want to diff my working copy of the branch against t

strange result when compiling w/ -fpreprocessed but w/out -fdumpbase

When you compile a file that contains a line directive, e.g.: # 1 "../../libgcc2.c" int f () { return 0; } using the -fpreprocessed option to cc1, but without -fdumpbase, the base filename of the line number directive us used both for the assembly output file and for debugging dumps from -da.

Re: Delay branch scheduling vs. the CFG

> > > 4. An entirely new basic block on its own. > > > > When can option 4 happen?? > IIRC it occurs when there was only 1 insn in either the target > or fall-thru block.When it gets sucked into the delay > slot of a branch, then it is effectively its own basic > block. When the fall-throug

Re: Register Allocation

In http://gcc.gnu.org/ml/gcc/2005-11/msg01163.html, Ian Lance Taylor wrote: Either way, register elimination can cause addresses which were valid to become invalid, typically because valid offsets from the frame pointer become invalid offsets from the stack pointer. So that needs to be cleaned

Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1

Jakub Jelinek wrote: I have looked just at one failure, but maybe all of them are the same thing. typedef char __attribute__((vector_size (16))) v16qi; int i = __alignof__ (v16qi); with GCC 4.0 sets i to 8 (s390{,x} have BIGGEST_ALIGNMENT 64), but GCC 4.1 sets i to 16. The changes that created

Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1

Jakub Jelinek wrote: If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT) here, I'm afraid that would be much bigger ABI incompatibility. Currently, say typedef char __attribute__((vector_size (64))) v64qi; is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is m

Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1

Jakub Jelinek wrote: On Tue, Nov 29, 2005 at 10:01:25PM +, Joern RENNECKE wrote: If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT) here, I'm afraid that would be much bigger ABI incompatibility. Currently, say typedef char __attribute__((vector_size (64))) v64q

Re: RELOAD_OTHER bug?

Note that 4157 is out of order. I *think* what's happening is that the MERGE_TO_OTHER macro isn't taking into account that if you merge RELOAD_OTHER and RELOAD_FOR_OTHER_ADDRESS, you can't end up with a RELOAD_OTHER. No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER.

Re: RELOAD_OTHER bug?

DJ Delorie wrote: No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER. Why? RELOAD_FOR_OTHER_ADDRESS only lives till the RELOAD_OTHER input reloads. Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be merged with RELOAD_OTHER reloads? Yes. But if they load

Re: mainline bootstrap broken on i686-pc-linux-gnu

I see this here too. Apparently this was caused by the i386.h PUSH_ROUNDING change of this patch: 2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]> PR debug/25023 PR target/25293 * expr.c (emit_move_resolve_push): Handle PRE_MODIFY and POST_MODIFY with CONST_INT adjustm

Re: mainline bootstrap broken on i686-pc-linux-gnu

I can't reproduce it (otherwise I wouldn't have committed it), it bootstrapped/regtested just fine for me. Can one of those who can reproduce it give me preprocessed mf-runtime.i and exact gcc options that triggered it? I have attached the stripped down testcase. The bug is triggered with:

Re: RELOAD_OTHER bug?

DJ Delorie wrote: Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be merged with RELOAD_OTHER reloads? Yes. But if they load the same value as a RELOAD_OTHER input, they can share the same reload register. So why does reload specifically check for RELOAD_FOR_OTHER

Re: [PATCH] Fix bootstrap on i686-pc-linux-gnu

Jakub Jelinek wrote: While we could use pushhi2 insn (would need to use pre_modify rather than pre_dec etc.), it wouldn't buy us anything. Presumably, it would prevent a partial register stall.

Re: Huge compile time regressions

Daniel Berlin wrote: On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote: Hi, Someone caused a >10% compile time regression yesterday for CSiBE, see http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&b

Re: HARD_REGNO_MODE_OK_FOR_CLASS Might Be Nice (tm)

In http://gcc.gnu.org/ml/gcc/2005-12/msg00642.html, Bernd Jendrissek wrote: > Which leads me to the subject. Would it be a win to have a macro > HARD_REGNO_MODE_OK_FOR_CLASS (REGNO, MODE, CLASS) which would be the > authoritative test for this loop in find_reg()? On my port, and I > imagine on m

RFD: CSiBE failure: typeof sometimes copies toplevel const qualifiers

In order to investigate the CSiBE compilation time regressions observed in December when my cross-jumping patches were installed, I set out to compare the timings of current mainline with and without the patches reinstated. However, unmodified mainline (r109325) fails to compile the linux bench

Re: RFD: CSiBE failure: typeof sometimes copies toplevel const qualifiers

Richard Guenther wrote: This has been reported before and the kernel was fixed. typeof now always "returns" the effective type, including CV qualifiers in effect. Huh? Why would the effective type of __typeof__ (*(&uss->p)) x; be different from __typeof__ ((uss->p)) x; ? Moreover,

Re: Huge compile time regressions

Joern Rennecke wrote: I've found that the most striking compilation time increase was for flex / parse.c, which is a bison parser. -Os compilation for i686-pc-linux-gnu X sh-elf --disable-checking went from 0.95 to 4.5 seconds. Optimizing the REG_SET_EQ invocations gave a moderate win,

Re: Huge compile time regressions

Joern Rennecke wrote: Joern Rennecke wrote: I've found that the most striking compilation time increase was for flex / parse.c, which is a bison parser. -Os compilation for i686-pc-linux-gnu X sh-elf --disable-checking went from 0.95 to 4.5 seconds. Optimizing the REG_SET_EQ invoca

Re: A questionable predicate in sh/predicates.md

Kazu Hirata wrote: Notice that match_code at the beginning does not mention PARALLEL, but we have GET_CODE (op) != PARALLEL later. Is this predicate intended to accept PARALLEL as well? Yes, it is. If so, should we change the match_code at the beginning? Yes.

Re: merges

Jakub Jelinek wrote: Yes. I think they are useful for all branches if you backport a patch for a particular fix or e.g. fix something that is not yet fixed on the trunk and will be only when a particular devel branch with that fix is merged into trunk. But in all cases that should be a sing

RFA: re-instate struct_equiv code (Was: Re: Huge compile time regressions)

Joern Rennecke wrote: Doing only one update_life_info_in_dirty_blocks before the crossjumping makes the compilation time go right back to 0.95 seconds. If that works, is another question... if there are any transformations that invalidate global_live_at_end, we'll have to make them u

How to reverse patch reversal in cfgcleanup.c (Was: RFA: re-instate struct_equiv code)

For easier reviewing, I have attached the diff to the cfgcleanup version previous to the patch backout. I'm not sure what the best way to keep the svn history sane is. When/if the patch is approved, should I first do an svn merge -r108792:108791, check that in, and then apply the patch with t

Re: GCC 4.9.0 Released

On 22 April 2014 14:10, Jakub Jelinek wrote: > One year and one month passed from the time when the last major version > of the GNU Compiler Collection has been announced, so it is the time again > to announce a new major GCC release, 4.9.0. > > GCC 4.9.0 is a major release containing substantial

Re: LTO + conditional jump + delay slot

On 30 April 2014 12:20, Richard Biener wrote: > the delay-slot code is fragile, you probably simply run into a bug. In particular, we lack in-tree ports with multiple delay slots, so while the support exists theoretically, it is not tested and maintained in any meaningful way.

Re: soft-fp functions support without using libgcc

On 21 May 2014 14:13, Sheheryar Zahoor Qazi wrote: >>>Building libgcc is not optional. It is required for all targets. > > So, irrespective whether i provide floating point implementation by > soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST? > > What if I dont want to generate c

Re: combination of read/write and earlyclobber constraint modifier

On 2 July 2014 08:02, Marc Glisse wrote: > On Wed, 2 Jul 2014, Tom de Vries wrote: > >> On 02-07-14 08:23, Marc Glisse wrote: >>> >>> I think it could have used (match_dup 0) instead of operand 1, if there >>> had been only the first alternative. And then the constraint would have been >>> +&. >>

Re: GCC version bikeshedding

On 29 July 2014 18:14, Richard Biener wrote: > On July 29, 2014 6:45:13 PM CEST, Eric Botcazou > wrote: >>> I think that if anybody has strong objections, now is the time to >>make >>> them. Otherwise I think we should go with this plan. >> >>IMHO the cure is worse than the disease. >> >>> Give

Re: GCC version bikeshedding

On 29 July 2014 18:30, Markus Trippelsdorf wrote: > Since gcc is released annually, why not tie the version to the year of > the release, instead of choosing an arbitrary number? > > 15.o What did the Romans every do for us? Release GCC XV, obviously... Unfortunately, they couldn't release *.0 v

Re: GCC version bikeshedding

On 29 July 2014 19:29, Joern Rennecke wrote: > E.g. A GCC release on the 1st April 2015 at 09:00 UTC is made > 90 days and 9 hours after the start of the year, and should thus carry > the version number 2015.24760274 P.S.: a patchlevel release in a subsequent year can be marked by i

Re: GCC version bikeshedding

On 6 August 2014 11:31, Richard Biener wrote: > Ok, so the problematical case is > > struct X { std::string s; }; > void foo (X&); Wouldn't it be even more troublesome with an application that dynloads dsos depending on user input. The install script might check if the dso with the right soname i

  1   2   3   4   5   6   >