[Bug bootstrap/33781] [4.3/4.4 Regression] Arg list too long building libgcc.a
--- Comment #20 from roger at eyesopen dot com 2008-06-12 21:31 --- Hi Ralf, Thanks for your patch. Sorry for the delay in replying, I needed to check out mainline on my IRIX box and rebuild a baseline, and once that had completed make -k check, I tried with --enable-fixed-point first without, and then with your patch. The good news is that this allows the libgcc build to get further, but unfortunately the bad news is that we die just a little further on with a similar execvp: /bin/sh: Arg list too long. This second failure is where we run nm on all of the objects and pipe the results through mkmap-flat.awk to create tmp-libgcc.map. This looks to be in the same libgcc/Makefile.in in the libgcc.map rule (when SHLIB_MKMAP is defined). I do like your PR33781.diff patch which moves us in the right direction. Is it possible/safe to apply similar voodoo to the libgcc.map rule? Many thanks again for your help. I've no personal interest in using fixed point arithmetic on the MIPS, but resolving this issue on IRIX helps keep the build machinery portable. If it's not IRIX now, it'll be some other platform with a low MAXARGS limit in the near future. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #5 from roger at eyesopen dot com 2008-04-24 15:01 --- Well, I've now had time to read the Barriato, Hofri et al. 2002 paper, and the bad news is that such an approximate median selection algorithm can't be used to guarantee an O(N) worst-case std::nth_element implementation. It could be used in an implementation to guess a good pivot, but the quality of this median, i.e. how approximate it is, doesn't meet the necessary criterion to ensure an O(N) worst case. You'd still need a fallback method with guaranteed bounds or an exact median in order to achieve O(N). i.e. it could help improve the average case performance, but doesn't help with the worst case. For the mathematically inclined, in order to achieve an O(N) worst-case performance, you need to guarantee a constant fraction of elements can be eliminated at each level of the recursion. In comment #4, Steven fixates on just as long as N/2 elements are reduced each time round, but the equations for sum of geometric series show that doing better than any constant fraction guarantees O(N) worst case. Hence even if you only guarantee that you can eliminate 10% each round, you still achieve O(N) worst-case. Hence you need a method that provides an approximate median that worst-case can guarantee elimination of say 10% of elements from consideration. This is why approximate medians offer some utility over exact medians if they can be found faster. Unfortunately, the method of Battiato referenced in comment #1 doesn't provide such a constant fraction guarantee. An analysis shows that at each round, it can only eliminate (2^n-1)/3^n of the elements in its worst case, where n is log_3(N). By hand, naming the ranks 0..N-1, when N=3, the true median at rank 1 is selected. For N=9, the elements at rank 3,4 or 5 may be considered as a median, i.e. 1/3 eliminated. For N=27, the elements between ranks 8 and 20 may be returned as the median, i.e. 7/27 eliminated. In the limit, as N tends towards infinity (and n tends to infinity), the eliminated fraction (2^n-1)/3^n tends to zero unbounded. i.e. the larger the input size the less useful is the worst-case median. The poor quality of the median is lamented by the authors in the penultimate paragraph of section 4.1 of the paper. They then go on to show that statistically such a worst-case is rare, but unfortunately even a rare worst case breaks the C++ standard libraries O(N) constraint. This Achilles heel is already well documented in the algorithmic complexity community. The Blum, Floyd, Pratt, Rivest and Trarjan paper [BFRT73] and the Floyd and Rivest paper [FR75] analyse the issues with median-of-k-medians, and show that k=5 is the lowest value capable of guaranteed fractional worst case. i.e. they already consider and reject the algorithm given in the cited work (k=3) for the purpose of exact median finding. Anyway, I hope you find this interesting. There will always be efficient methods for finding approximate medians. The question is how efficient vs. how approximate. Many quicksort implementation select the first element as a pivot, an O(1) method for selecting an extremely approximate median! Statistically over all possible input orders, this first element will on average partition the input array at the median, with some variance. It's not that the paper is wrong or incorrect; it does what it describes in finding a statistically good approximate median very efficiently with excellent worst case performance. Unfortunately for the problem we need to solve, which is not the problem the paper's authors were attempting to solve, we need a better approximation perhaps using a more complex implementation. Anyway, thanks again for the reference. I'd not come across it before and really enjoyed reading it. Let me know if you spot a flaw in my reasoning above. Dr Roger Sayle, Ph.D. Computer Science -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #2 from roger at eyesopen dot com 2008-04-21 03:22 --- Yep, now that we're back in stage1, it's about time I got around to submitting the O(n) worst case nth_element implementation that I mentioned last year. For Steven's benefit, the implementation I've already coded up uses the median-of-medians in groups of five strategy as a fallback to a modified quickselect. [Though I'll need to quickly read the paper you cite] The trick for libstdc++ is to attempt to make the typical case as fast or faster than the existing implementation. Whilst the standards now require O(n) worst case, the perceived performance of g++'s users is the average case and changing to an O(n) implementation that has a large co-efficient constant may upset some folks. -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-21 03:22:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug c/34720] ICE in real_to_decimal, at real.c:1656
--- Comment #7 from roger at eyesopen dot com 2008-01-29 01:12 --- I'm also seeing this same failure with make profiledbootstrap on x86_64-unknown-linux-gnu. A make bootstrap on the same machine completes and regression tests fine (14 unexpected failures in gcc). I suspect that the miscompilation is either non-deterministic or is caused by an optimization that only triggers on some targets and/or with additional profile information. Perhaps we should regression hunt for the change that broke things. It might not be anything to do with real.c or decimal floating point. -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc64-unknown-linux-gnu |*64-unknown-linux-gnu GCC host triplet|powerpc64-unknown-linux-gnu |*64-unknown-linux-gnu GCC target triplet|powerpc64-unknown-linux-gnu |*64-unknown-linux-gnu Last reconfirmed|-00-00 00:00:00 |2008-01-29 01:12:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34720
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #8 from roger at eyesopen dot com 2007-11-02 16:41 --- Created an attachment (id=14471) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14471action=view) Default libgcc.a objects on mips-sgi-irix6.5 I'll respond to Jakub's latest comments before trying DJ's more recent patch. Running getconf ARG_MAX on my IRIX box, returns 20480, which is 20K. I believe this is the default, out of the box setting for my machine which is running IRIX 6.5.19m. Using cut'n'paste from the failing make output, I measure the current $$objects to be 25949 bytes. I've attached the attempted value of $objects to this e-mail. I'll give DJ's patch a spin... I apologise that this box isn't that speedy. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #9 from roger at eyesopen dot com 2007-11-02 17:12 --- Doh! DJ's patch gets us a little further, but it things are still broken. However, it's an excellent debugging tool which shows that its the invocation with libgcc-objects-15 that's broken. Applying the same trick as above shows that $libgcc-objects-15 alone is 19962 bytes, which combined with the ar etc.. at the beginning of the command line exceeds the limits. So it's the fixed-conv-funcs that are to blame. Perhaps gen-fixed.sh has gone insane with the large number of integer-like machine modes on MIPS. The correct fix might actually be in the optabs handling of the middle-end, so we don't need quite so many conversion functions in MIPS' libgcc.a. Or perhaps mips.md need improved support (patterns) for this functionality. I've no idea what _satfractunsUTIUHA is, it's a recent addition and I've not been following gcc-patches lately. Splitting _fract* from _sat* with a patch similar to DJ's should work. I hope this is enlightening. Is there a --disable-option to avoid building fixed point conversion support? Looks like our command line usage is O(n^2) in the number of backend integer machine modes? Thanks again for everyone's help on this. I'll owe you beers at the next GCC summit. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #4 from roger at eyesopen dot com 2007-11-01 17:15 ---
Thanks to both Jakub and DJ for their help. I just tried out the suggested
patch on my IRIX box, and was surprised that it didn't resolve the error.
My apologies that my initial analysis might have been wrong (or incomplete),
but it looks like the error occurs earlier on the same command line.
Not only does,
objects=$(objects) ; $(AR_CREATE_FOR_TARGET) $@ $$objects
Infact, stripping the command back to just
objects=$(objects)
is enough to trigger the error. Hoping that this was perhaps a limitation
of IRIX's /bin/sh, I've tried again with SHELL=/usr/local/bin/bash but alas
I get the same error.
make: execvp: /usr/local/bin/bash: Arg list too long
So it's not a bound on argc or the number of entries in argv[] that's the
problem, but a hard limitation on command line length.
So it looks like we can't even assign $objects yet alone use it, either
directly or looping over it to use xargs. Perhaps we could do something
with find. Just a wild guess here as I don't understand build machinery
but something like:
find . -name '*.o' -exec ar rc libgcc.a {} \;
And then test afterwards
if test ! -f libgcc.a ; then
{the eh_dummy.o stuff to avoid empty libgcc.a} ;
fi
I'm not sure why I'm seeing this. There mustn't be many IRIX testers for
mainline and either MIPS is building more objects than other platforms (for
saturating and fixed point math) or most OSes are less restricted than
IRIX.
Many thanks again for peoples help. Is find portable, or is there a
better way to achieve the same thing without ever placing all of the filenames
on a single command line?
Sorry for any inconvenience.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] New: [4.3 Regression] Arg list too long building libgcc.a
The recent addition of a large number of libgcc objects (for fixed point arithmetic and other things) now breaks bootstrap on IRIX. The problem is that the command line in libgcc/Makefile.in, approx line 697 reads as: $(AR_CREATE_FOR_TARGET) $@ $$objects which doesn't defend against $objects being a huge list. Currently on 32-bit IRIX this is 1762 files. Indeed, even typing ls *.o in the directory mips-sgi-irix6.5/32/libgcc, returns -bash: /usr/bin/ls: Arg list too long! Alas I'm not a wizard in build machinery, but I suspect that all that's required is a one or two line change, perhaps to use libtool to create the archive, which contains logic to circumvent these host command line limits. I believe this is what we currently do for libgcj and other large libraries. Many thanks in advance to the kind build maintainer or volunteer who looks into the problem. I'm happy to test patches on my dusty MIPS/IRIX box. -- Summary: [4.3 Regression] Arg list too long building libgcc.a Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roger at eyesopen dot com GCC host triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug target/33545] [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
--- Comment #1 from roger at eyesopen dot com 2007-10-13 04:14 --- Many thanks to Eric Botcazou! It turns out that this bug was a duplicate of PR target/32325. I can confirm that with Eric's fix, and once I'd committed my libstdc++ patch for the EOVERFLOW issue (mentioned by Eric in PR23225's comment #6), and Alex's SRA fixes stop miscompiling mips-tfile, that I can once again bootstrap mainline on alphaev67-dec-osf5.1! Thanks again to Eric for a speedy fix. I'm sorry that this was a dupe, and that it took a while for mainline to stablize to the point that I could confirm the problem is resolved. *** This bug has been marked as a duplicate of 32325 *** -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545
[Bug target/32325] [4.3 Regression] cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info
--- Comment #7 from roger at eyesopen dot com 2007-10-13 04:14 --- *** Bug 33545 has been marked as a duplicate of this bug. *** -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32325
[Bug target/33545] New: [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
I just tried compiling mainline on my dusty alphaev67-dec-osf5.1 and discovered
that recent RTL CFG changes have broken the way that exceptions are implemented
on alpha/Tru64. Natively, this is seen with configure and make bootstrap
as a breakage configuring libstdc++-v3 where the exception model can't be
detected in configure.
The underlying cause is that exceptions seem to be now be fundamentally broken
on this target. The simple source file:
struct S { ~S(); };
void bar();
void foo()
{
S s;
bar();
}
triggers the following ICE:
conf.C: In function 'void foo()':
conf.C:7: error: end insn 27 for block 7 not found in the insn stream
conf.C:7: error: head insn 24 for block 7 not found in the insn stream
conf.C:7: internal compiler error: Segmentation fault
The problem is reproduceable with a cross-compiler (for example from
x86_64-linux) which is configured as configure --target=alphaev67-dec-osf5.1
followed by make. The build fails attempting to build mips-tfile, but not
before creating a suitable cc1plus which can be used to demonstrate the
problem/logic error.
The underlying cause appears to be associated with the alpha backend's use of
the middle-end RTL function emit_insn_at_entry. Using grep it appears
alpha is the only backend that uses this function, and I suspect recent
changes to it's implementation (Honza?) are responsible for the breakage.
The flow of events is that in the rest_of_handle_eh pass,
expect.c:finish_eh_generation calls gen_exception_receiver. In alpha.md,
the define_expand for exception_receiver makes use of the function
alpha_gp_save_rtx when TARGET_LD_BUGGY_LDGP is defined (as on Tru64 with the
native ld). The implementation of alpha_gp_save_rtx in alpha/alpha.c creates a
memory slot (with assign_stack_local) and the generates some RTL to initialize
this which it tries to insert at the start of the function using
emit_insn_at_entry.
The logic error is that emit_insn_at_entry as currently implemented in cfgrtl.c
uses insert_insn_on_edge and commit_edge_insertions. This occurs during RTL
expansion when some of the basic blocks are not yet fully constructed, hence
the expected invariants are not correctly satisfied leading to the errors and
the segmentation fault.
The only other caller of emit_insn_at_entry appears to be integrate.c's
emit_initial_value_sets. However, I'm guessing that because this doesn't
occur during RTL expansion, there's no problem with using
commit_edge_insertions.
I'm not sure what the correct way to fix this is. I'd like to say that this is
a middle-end problem with the change in semantics/implementation of
emit_insn_at_entry causing a regression. However, because it's only the alpha
that's misbehaving it's probably more appropriate to classify this as a target
bug, and get Jan/RTH or someone familiar with how this should work to correct
alpha.c's alpha_gp_save_rtx. One approach might be to always emit the memory
write in the function prologue, and rely on later RTL passes to eliminate the
dead store and reclaim the unused stack slot from the function's frame.
I'm happy to test (and approve) patches for folks who don't have access to this
hardware.
--
Summary: [4.3 regression] Bootstrap failure/broken exceptions on
alpha/Tru64
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
GCC target triplet: alphaev67-dec-osf5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545
[Bug fortran/31711] rhs array is changed while assiging to same lhs array
--- Comment #10 from roger at eyesopen dot com 2007-04-27 18:20 --- Paul's fix looks correct to me. It appears that when the #if 0 was added to disable broken loop shifting at some point in the distant past, the critical functionality. if (nDepend) break; was accidentally removed. This is similar to the idiom used a few lines earlier nDepend = 1; break; I would normally have suggested that the type of nDepend and the return type of gfc_dep_resolver be changed to bool, and the dead #if 0 code removed to clean-up this code... However, I think a much better longer term strategy is to completely remove gfc_conv_resolve_dependencies, and gfc_dep_resolver and the automatic handling of temporaries in the scalarizer. Instead, in line with the TODO above gfc_conv_resolve_dependencies, I think it's much better to handle this at a higher level using the new/preferred gfc_check_dependency API that's used through-out the front-end. For example, when lhs=rhs has a dependency, this can be transformed into tmp=rhs; lhs=tmp during lowering or at the front-end tree-level, which greatly simplifies the complex code in the scalarizer. It also allows the post-assignment copy lhs=tmp to be performed efficiently [though I may have already implemented that in the scalarizer already :-)]. One benefit of doing this at a higher level of abstraction is that loop-reversal isn't a simple matter of running our default scalarized loop backwards (as hinted by the comment, and the PRs in bugzilla). Consider the general case of a(s1:e1,s2:e2,s3:e3) = rhs. The dependency analysis in gfc_check_dependency may show that s1:e1 needs to run forwards to avoid a conflict, and that s3:e3 needs to run backwards for the same reason. It's trivial then to treat this almost like a source-to-source transformation (ala KAP) and convert the assignment into a(s1:e1:1,s2:e2,s3:e3:-1) instead of attempting to shoehorn all this into the scalarizer at a low-level and perform book-keeping on the direction vectors. By the time, we've lowered gfc_expr to gfc_ss, we've made things much harder for ourselves. And things get much more complex once we start seriously tackling CSHIFT, TRANSPOSE and friends! Keeping the scalarizer simple also eases support for autovectorization and/or moving it into the middle-end (the topic of Toon's GCC summit presentation). I'm as surprised as Paul that this hasn't been a problem before. I suspect it's because we use the alternate gfc_check_dependency in the vast majority of cases, and the empirical observation in the research literature that most f90 array assignments in real code don't carry a dependency. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31711
[Bug fortran/31620] [4.3 regression] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #10 from roger at eyesopen dot com 2007-04-23 20:54 --- Many thanks to Paul for fixing this, and my apologies for being overloaded at work and not being available to investigate it fully myself. I believe that Paul's fix of explicitly checking expr1-ref-next is the correct way to determine whether a reference is too complex. My confusion is that this test should already be being checked/verified in the call to gfc_full_array_ref_p on the line immediately following his change. So on line 1124 of dependency.c in gfc_f_a_r_p is the clause if (ref-next) return false; which should be doing exactly the same thing. The reason I mention this is perhaps GCC is miscompiling itself, and this gfortran failure is the visible manifestation. Alternatively, perhaps ref-next isn't getting set properly, or is getting clobbered somehow. Paul does your new testcase fail without your fix? My apologies again if I'm missing something obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug fortran/31620] [4.3 regression] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #11 from roger at eyesopen dot com 2007-04-23 21:05 --- Duh! I am missing something obvious! The ref-u.ar.type == AR_FULL test on line 1120 returns true. The test for ref-next needs to be moved earlier. Sorry again for the inconvenience. Clearly, my brain isn't working properly at the moment :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug rtl-optimization/28173] [4.0/4.1 regression] misses constant folding
--- Comment #6 from roger at eyesopen dot com 2007-03-08 01:55 --- I suspect this problem is now fully resolved. The patch for PR24427 has been backported to the gcc-4_1-branch, and additionally on mainline, simplify-rtx.c has been enhanced to also perform the missed-optimization at the RTL level. Given that the 4.0 branch is now closed, I believe this is sufficient to close this PR. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28173
[Bug middle-end/30744] [4.2/4.3 Regression] ICE in compare_values, at tree-vrp.c:466
--- Comment #4 from roger at eyesopen dot com 2007-03-06 16:32 --- This should now be fixed on both mainline and the 4.2 release branch. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.2.0 4.3.0 | Known to work|4.1.1 |4.1.1 4.2.0 4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30744
[Bug middle-end/24427] missing optimization opportunity with binary operators
--- Comment #10 from roger at eyesopen dot com 2007-02-18 18:10 --- Hi Eric, It's not PR24427 that's the motivation for this backport, but PR 28173. In fact, it was *your* request in comment #2 of PR28173 to backport this! I'm a little disappointed you'd even question my decision/authority to backport a regression fix. :-) Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24427
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #5 from roger at eyesopen dot com 2007-02-02 00:17 --- It looks like Ian's recent subreg lowering pass patch has improved code generation on this testcase. Previously, we'd spill three integer registers to the stack for LLM, we're now down to two. [A significant improvement from the five we spilled when this bug was reported] Before: LLM:subl$12, %esp movl%ebx, (%esp) movl28(%esp), %edx movl20(%esp), %ebx movl16(%esp), %ecx movl24(%esp), %eax movl%esi, 4(%esp) movl%edx, %esi movl%edi, 8(%esp) movl%ebx, %edi movl(%esp), %ebx imull %ecx, %esi imull %eax, %edi mull%ecx addl%edi, %esi movl8(%esp), %edi leal(%esi,%edx), %edx movl4(%esp), %esi addl$12, %esp ret After: LLM:subl$8, %esp movl%ebx, (%esp) movl20(%esp), %eax movl%esi, 4(%esp) movl24(%esp), %ecx movl12(%esp), %esi movl16(%esp), %ebx imull %esi, %ecx imull %eax, %ebx mull%esi movl4(%esp), %esi addl%ebx, %ecx movl(%esp), %ebx addl$8, %esp leal(%ecx,%edx), %edx ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug middle-end/22370] Vec lower produces mis-match types
--- Comment #2 from roger at eyesopen dot com 2007-01-28 02:58 --- Hi Andrew, could you recheck whether you can reproduce this problem on mainline? Updating the MODIFY_EXPR patch in PR 22368 to check GIMPLE_MODIFY_STMT, I'm unable to reproduce this failure on x86_64-unknown-linux-gnu, even with -m32. There has been at least one type clean-up patch to veclower, so I suspect this issue may have been resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22370
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #2 from roger at eyesopen dot com 2007-01-19 20:55 --- It looks like the ivopts pass is creating dubious? array references. The symbol.c.053t.vrp1 D.12252_12 = (long unsigned int) i_2; D.12255_15 = ns_4-default_type[D.12252_12]; ts_16 = D.12255_15 + -2328B; i.e. we now have ns-default_type[i] - ns-default_type['a']. I wouldn't like to offer an opinion on whether this IV is valid in the middle-end. The transformation is certainly unsafe in C, where a pointer arithmetic is not guaranteed to be valid outside of the declared object. I think the appropriate fix is that if ivopts is going to create these suspicious array refs, it should appropriately set TREE_NO_WARNING, which will then cause the reference to be ignored by the bounds checking in VRP. Alternatively, we need more context in array bounds checking such that x['a'] is not a problem, but x['a'] on it's own is diagnosed. i.e. we could perhaps keep an in_indirect_ref_p flag during the tree walking. I hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug fortran/30404] Wrong FORALL result
--- Comment #3 from roger at eyesopen dot com 2007-01-11 16:56 --- Ok, I've now spent some time reading the code, I understand what's going wrong and what needs to be done to fix it. The problem resolves around the nest_flag argument to gfc_trans_nested_forall_loop. This argument only ever has the value zero when called from gfc_trans_forall_1 when calculating the mask for a nested forall. Unfortunately, this use is incorrect. Conceptually in a nested forall the mask needs to have one element for each execution/iteration of the assignment statement. So in Paul's reduced testcase in comment #5, the inner mask (translated as needs temp.5) to help in an array of size 4! This is required because the body of the loop may potentially affect either the inner or outer mask condition. So there's good news and bad news. The bad news is that in the general case, we can't determine how many times the loop body will be iterated at compile-time. When the loop bounds are constant, we can simply multiply together innersize * outersize. But often, the shape of the iteration may be irregular, such as triangular operations: forall(i=1:10,mask1[i]) forall(j=1:i,mask2[i,j]) foo(i,j) or completely irregular such as forall(i=1:10,mask1[i]) forall(j=1:bound[i],mask2[i,j]) bar(i,j) The good news is that the current expansion of forall loops can be restructured to get the fortran9x semantics correct. In the worst case, we need to generate another nested set of loops to determine the mask size, at run-time, before allocating and then populating the array. One nice aspect of this is that the inner mask can take into account how sparse the outermask is. i.e. for bar() above we can do better than sum(bound[1:10]). The bad news is this form of conservative implementation is likely to be less efficient than the current incorrect (and poor) implementation. The good news is that in follow-up patches, we should be able to significantly optimize FORALL much like we now do with WHERE and generate much more efficient code for the common case, with mask elimination, loop fusion etc... For Paul's example in comment #5, it should be possible to implement this loop without any mask arrays, as a single doubly-nested loop. However, the most immediate goal is rewriting gfortran's forall expansion to produce the correct result. Hopefully, I'll have the first in a series of patches to rewrite the basics of nested FORALL expansion soon. Unfortunately, its taking slightly longer than I anticipated, though I've now confirmed that this isn't a simple few-line fix, but a more fundamental design issue in nested forall expansion. Paul, Steve, Please let me know if you see an issue with the above analysis. Hopefully, the three-loop strategy of (i) determine mask size, (ii) populate mask and (iii) conditionally execute loop makes sense? -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-08 11:23:23 |2007-01-11 16:56:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30404
[Bug middle-end/30322] ((-i-1) + i) +1) is turned into ~i + (i+1) and never into 0 on the tree level
--- Comment #5 from roger at eyesopen dot com 2007-01-04 22:34 --- Can you reduce a test case for the loop, now that the code in the PR description is fixed? One thing that looks a bit odd is that in the condition you describe the constant term 1, isn't on the far right, which I believe should be the correct canonical form. Hence it looks like some of the trees/subtrees in your expression haven't been folded. With a small testcase it'll be easier to see whats going on. I agree that you might be right, and it may be profitable to disable these BIT_NOT_EXPR forms in fold, and identify them during RTL expansion or during the RTL optimizers. But I'd like to see the sequence of events before I admit defeat. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30322
[Bug middle-end/30322] ((-i-1) + i) +1) is turned into ~i + (i+1) and never into 0 on the tree level
--- Comment #3 from roger at eyesopen dot com 2007-01-01 20:46 --- Hi Richard (Happy New Year), I was wondering whether you could confirm whether the patch I committed fixes the loop termination conditions in tramp3d? It resolves the example code given in the description which now reduces to return 0;, but I'm curious if this is sufficient to catch the underlying problem or whether we really need a tree combiner and/or reassociation in order to optimize these loops. Thanks in advance, Roger -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-01 20:46:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30322
[Bug fortran/30207] [4.2/4.3 Regression] ICE in gfc_dep_resolver with where (a 0) a(:) = 1
--- Comment #4 from roger at eyesopen dot com 2006-12-16 19:28 --- Steve posted his fix at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01012.html and I came up with an improved version that correctly identifies the equivalence of z and z(:) here http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01094.html Sorry for the inconvenience. It looks like I introduced this regression whilst restructuring gfc_dep_resolver. As penance, I'm currently investigating a related gfortran optimization, that can use the proposed gfc_full_array_ref_p, to improve the code generated for your POSL function even further. -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30207
[Bug c/19976] integer division by zero in subexpression should be overflow
--- Comment #3 from roger at eyesopen dot com 2006-12-01 03:25 --- Hi Manual, This needs to be handled in the front-ends, and in fact is already handled by the front-ends. In c-typeck.c:build_binary_op, I see: case TRUNC_DIV_EXPR: case CEIL_DIV_EXPR: case FLOOR_DIV_EXPR: case ROUND_DIV_EXPR: case EXACT_DIV_EXPR: /* Floating point division by zero is a legitimate way to obtain infinities and NaNs. */ if (skip_evaluation == 0 integer_zerop (op1)) warning (OPT_Wdiv_by_zero, division by zero); Likewise, there are several references to OPT_Wdiv_by_zero in cp/typeck.c. The real issue is that OPT_Wdiv_by_zero needs to be enabled by -pedantic in order to generate an error for -pedantic-errors, as requested by Joseph in comment #1. I hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19976
[Bug c/19976] integer division by zero in subexpression should be overflow
--- Comment #5 from roger at eyesopen dot com 2006-12-01 04:04 ---
This needs to be handled in the front-ends...
^ should
^^ can only be
I was thinking of a slightly weaker form of need/must.
But there are two issues here. The division by zero is one, but its also
a red herring, we really shouldn't be accepting the code:
int x;
enum e { E = 0 * x };
which currently compiles without even a warning using -pedantic-errors.
This is exactly the sort of thing that Joseph's struct c_expr were intended
to handle. I don't think is unreasonable for fold to convert 0 * x into
0, the issue is that a front-end can't really look at a folded tree and
determine anything much about the original source code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19976
[Bug middle-end/29726] [4.2 regression] invalid folding of ((X C1) C2) != 0 or M-x is undefined in emacs
--- Comment #9 from roger at eyesopen dot com 2006-11-10 18:33 --- Thanks Paolo! Your machine must be faster than mine. My bootstrap and regression test against the 4.2 branch has only just finished. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29726
[Bug rtl-optimization/29797] [4.1/4.2/4.3 Regression] Miscompiles bit test / set in OpenOffice
--- Comment #13 from roger at eyesopen dot com 2006-11-10 19:41 --- Grr. Yep, Michael's BITS_BIG_ENDIAN test looks to be the correct thing. The effect of BITS_BIG_ENDIAN on sign_extract and zero_extract is documented in rtl.texi. Is anyone bootstrapping and regression testing this change or shall I do the honors. In fact, I'll pre-approve it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29797
[Bug middle-end/28915] [4.1/4.2/4.3 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #16 from roger at eyesopen dot com 2006-11-11 02:19 --- A patch was posted by Jason, here http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00566.html -- roger at eyesopen dot com changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/26983] [4.0 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #16 from roger at eyesopen dot com 2006-09-22 15:40 --- Fixed everywhere. Eric even has an improved patch/fix for mainline, but the backports of this change are sufficient to resolve the current PR. Thanks to Steven for coming up with the solution. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug debug/29132] [4.1 Regression] Mips exception handling broken.
--- Comment #7 from roger at eyesopen dot com 2006-09-22 16:51 --- Fixed on mainline (confirmed on mips-sgi-irix6.5). It'll take another day or two to backport to the 4.1 branch, as bootstrap and regtest on MIPS takes a while. -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail|4.1.2 4.2.0 |4.1.2 Known to work|4.1.1 |4.1.1 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-22 16:51:25 date|| Summary|[4.1/4.2 Regression] Mips |[4.1 Regression] Mips |exception handling broken. |exception handling broken. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug c/29132] [4.2 Regression] Mips exception handling broken.
--- Comment #1 from roger at eyesopen dot com 2006-09-18 21:27 --- Hi David, I was wondering if you have a MIPS tree handy, whether you could easily test the following single line patch: Index: dwarf2out.c === *** dwarf2out.c (revision 117035) --- dwarf2out.c (working copy) *** dwarf2out_begin_prologue (unsigned int l *** 2572,2578 fde = fde_table[fde_table_in_use++]; fde-decl = current_function_decl; fde-dw_fde_begin = dup_label; ! fde-dw_fde_current_label = NULL; fde-dw_fde_hot_section_label = NULL; fde-dw_fde_hot_section_end_label = NULL; fde-dw_fde_unlikely_section_label = NULL; --- 2572,2578 fde = fde_table[fde_table_in_use++]; fde-decl = current_function_decl; fde-dw_fde_begin = dup_label; ! fde-dw_fde_current_label = dup_label; fde-dw_fde_hot_section_label = NULL; fde-dw_fde_hot_section_end_label = NULL; fde-dw_fde_unlikely_section_label = NULL; Due to all the abstraction with debugging formats, its difficult to tell the order in which things get executed, and whether this initial value for dw_fde_current_label survives long enough to avoid use of a set_loc. Many thanks in advance, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #7 from roger at eyesopen dot com 2006-09-11 16:36 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00406.html -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-11 16:36:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug bootstrap/28784] [4.2 regression] Bootstrap comparison failure
--- Comment #6 from roger at eyesopen dot com 2006-09-11 16:52 --- I believe I have a patch. I'm just waiting for the fix for PR28672 (which I've just approved) to be applied, so I can complete bootstrap and regression test to confirm there are no unexpected side-effects. -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-11 16:52:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28784
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #11 from roger at eyesopen dot com 2006-09-06 15:27 --- Hmm, yep I guess it was caused my change, most probably this part of it: * tree.c (build_constructor_single): Mark a CONSTRUCTOR as constant, if all of its elements/components are constant. (build_constructor_from_list): Likewise. It looks like someplace is changing the contents of this CONSTRUCTOR to a VAR_DECL t.0, but not reseting the TREE_CONSTANT flag. Hence on PPC we end up with a bogus constant constructor during RTL expansion!? Scalar replacement perhaps?? Grr. I'll investigate. Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #12 from roger at eyesopen dot com 2006-09-06 15:36 ---
Here's the .102t.final_cleanup
;; Function f (f)
f ()
{
int D.1524;
int D.1522;
int D.1520;
int t.0;
bb 2:
t.0 = (int) t;
D.1520 = (int) t[1];
D.1522 = (int) t[2];
D.1524 = (int) t[3];
return {t.0, D.1520, D.1522, D.1524};
}
The CONSTRUCTOR in the return incorrectly has the TREE_CONSTANT flag set.
So the problem is somewhere in tree-ssa. One workaround/improvement might
be for out-of-ssa to reconstitute the constructor back to a constant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28473] [4.0/4.1/4.2 Regression] with -O, casting result of round(x) to uint64_t produces wrong values for x INT_MAX
--- Comment #6 from roger at eyesopen dot com 2006-07-25 20:02 --- Grr. I've just noticed richi has just assigned this patch to himself. I also have a patch that been bootstrapped and has nearly finished regression testing, that I was just about to post/commit. richi what does your fix look like? Mine contains several copies of: if (!TARGET_C99_FUNCTIONS) break; ! if (outprec TYPE_PRECISION (long_integer_type_node) ! || (outprec == TYPE_PRECISION (long_integer_type_node) ! !TYPE_UNSIGNED (type))) fn = mathfn_built_in (s_intype, BUILT_IN_LCEIL); + else if (outprec == TYPE_PRECISION (long_long_integer_type_node) + !TYPE_UNSIGNED (type)) + fn = mathfn_built_in (s_intype, BUILT_IN_LLCEIL); break; [Serves me right for not assigning this when pinkia asked me to investigate. I knew there was a good reason I don't normally bother with recent PRs]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug middle-end/28473] [4.0/4.1/4.2 Regression] with -O, casting result of round(x) to uint64_t produces wrong values for x INT_MAX
--- Comment #7 from roger at eyesopen dot com 2006-07-25 20:08 --- Ahh, I've just found the Richard's patch submission posting at http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01065.html I agree with Andrew Pinski, I think my changes are the better fix. We also need to investigate wether (unsigned int)round(x) is better implemented as (unsigned int)llround(x). For the time being, my patch doesn't perform this transformation, and using lround is unsafe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #39 from roger at eyesopen dot com 2006-07-24 00:45 --- My latest analysis and a possible patch/workaround have been posted here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01015.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #37 from roger at eyesopen dot com 2006-07-17 22:15 --- I've now tested make profiledbootstrap on both mainline and the gcc-4_1-branch, on both x86_64-unknown-linux-gnu and i686-pc-linux-gnu, and not only does the profiled bootstrap build fine, but the dejagnu testsuite looks identical to a baseline make bootstrap. Could anyone confirm whether they're still seeing this problem? Its likely that Andrew Pinski's patches together with the resolution of PRs 25518 and 26449 have now resolved this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug c/25995] switch/case does not detect invalid enum values if default-case is used
--- Comment #3 from roger at eyesopen dot com 2006-07-08 14:31 ---
I tried fixing this bug, only to discover why things are exactly as they are.
The short answer is that GCC will warn about the example code if you
specify the -Wswitch-enum command line option. Specifying -Wall implies
the weaker -Wswitch, which intentionally disables the checking of enumeration
literals in switch statements.
But why would anyone want to disable warning for the example code, I thought
to myself, until bootstrapping GCC itself discovered a large number of cases
identical to the one reported. Internally, GCC itself uses an enumeration
called tree_code that tracks the different types of node of GCC's abstract
syntax tree (AST). However, numerous front-ends, supplement this enumeration
with their own front-end specific tree codes, for example,
COMPOUND_LITERAL_EXPR. Hence, the various GCC front-ends are littered with
source code that looks like:
switch (TREE_CODE (t))
{
case COMPOUND_LITERAL_EXPR:
...
where the case value isn't one of the values of the original enum tree_code
enumeration. Similar problems appeared in dwarf2out.c and other GCC source
files. At first I started changing things to switch ((int) TREE_CODE (t))
to silence the warning, but quickly became overwhelmed by the number of
source files that needed updating.
Hence, the current status quo. GCC uses the default: break; idiom to
indicate which switch statements may be bending the rules, to turn off this
warning with the default -Wall/-Wswitch used during bootstrap. Well written
user code, on the other hand, should probably always use -Wswitch-enum.
If you read the documentation of -Wswitch vs. -Wswitch-enum, you'll see that
the disabling of these warnings when a default case is specified, is a curious
feature, purely to aid GCC to compile itself. As Andrew Pinskia points out
in comment #2, it's valid C/C++ so shouldn't warrant an immediate warning, so
the explicit -Wswitch-enum, requesting stricter checking seems reasonable.
I hope this helps, and the -Wswitch-enum fulfils this enhancement request.
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25995
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #2 from roger at eyesopen dot com 2006-07-06 19:17 --- Investigating... I suspect that the SH backend's rtx_costs are parameterized incorrectly, such that a 64-bit shift by the constant 32, looks to be at least 32 times more expensive than a 64-bit addition. The middle-end then uses these numbers to select the appropriate code sequence to generate. Combine also doesn't both cleaning this up because it also the same invalid rtx_costs, and discovers than combining additions into shifts doesn't appear to be a win on this target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #5 from roger at eyesopen dot com 2006-07-06 19:47 --- No the rtx_costs for a DImode shift really are wrong. The use of the constant 1 in sh.c:shift_costs instructs the middle-end to avoid using DImode shifts at all costs. The semantics of rtx_costs is that it is expected to provide an estimate of the cost of performing an instruction (either in size when optimize_size or in performance whrn !optimize_size) even if the hardware doesn't support that operation directly. For example, a backend may even need to provide estimates of the time taken for a libcall to libgcc, if such an operation is necessary, or when optimizing for size, how large such setting up and executing such a call sequence should be. It's only by providing accurate information such as this that an embedded backend such as SH is able to provide fine control over the code sequences selected by the GCC middle-end. As for the little-endian vs. big-endian issue that looks like a second bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #14 from roger at eyesopen dot com 2006-06-26 00:24 --- The problem appears to be that DECL_COMPLEX_GIMPLE_REG_P is not getting set on the declarations correctly. The VAR_DECLs that are operands to the additions don't have DECL_COMPLEX_GIMPLE_REG_P set, so fail the is_gimple_val check in verify_stmts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug middle-end/28131] [4.2 Regression] FAIL: gcc.c-torture/execute/va-arg-25.c compilation (ICE)
--- Comment #5 from roger at eyesopen dot com 2006-06-22 00:37 ---
Doh! My apologies for the breakage! I think Dave's patch looks good, but the
one suggestion that I would make would be to test for MODE_INT first, then
call the type_for_mode langhook. This saves calling type_for_mode on unusual
modes.
tree tmp = NULL_TREE;
if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT
|| GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT)
return const_vector_from_tree (exp);
if (GET_MODE_CLASS (mode) == MODE_INT)
- tmp = fold_unary (VIEW_CONVERT_EXPR,
- lang_hooks.types.type_for_mode (mode, 1),
- exp);
+ {
+ tree type_for_mode = lang_hooks.types.type_for_mode (mode, 1);
+ if (type_for_mode)
+ tmp = fold_unary (VIEW_CONVERT_EXPR, type_for_mode, exp);
+ }
if (!tmp)
I'll pre-approve that change, it bootstraps and regression tests OK.
Unfortunately, extern C conflicts for errno in the HPUX system headers
mean that I'm unable to test on my HPPA box myself at the moment :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28131
[Bug target/27861] [4.0 regression] ICE in expand_expr_real_1, at expr.c:6916
--- Comment #10 from roger at eyesopen dot com 2006-06-22 04:46 --- This should now be fixed on all active branches. Thanks to Martin for confirming the fix bootstraps and regression tests fine on mipsel-linux-gnu. And thanks, as always, to Andrew Pinski for maintaining the PR in bugzilla. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #14 from roger at eyesopen dot com 2006-06-19 23:50 --- Unfortunately, I'm unable to reproduce this failure with a cross-compiler to alphaev68-unknown-linux-gnu. However, examination of the tracebacks attached to this PR and the relevant source code reveals there is a potential problem. It looks like alpha_expand_mov can call force_const_mem on RTL expressions that are CONSTANT_P but that potentially don't satify targetm.cannot_force_const_mem, such as CONST etc... This would lead to precisely the failures observed in the discussion. operands[1] gets overwritten by NULL_RTX, and we then call validize_mem on a NULL pointer! Kaboom! I think one aspect of the solution is the following patch: Index: alpha.c === *** alpha.c (revision 114721) --- alpha.c (working copy) *** alpha_expand_mov (enum machine_mode mode *** 2227,2232 --- 2227,2237 return true; } + /* Don't call force_const_mem on things that we can't force + into the constant pool. */ + if (alpha_cannot_force_const_mem (operands[1])) + return false; + /* Otherwise we've nothing left but to drop the thing to memory. */ operands[1] = force_const_mem (mode, operands[1]); if (reload_in_progress) However, it's not impossible that this will prevent the current failure only to pass the problematic operand on to somewhere else in the compiler. Could someone who can reproduce this failure, try the above patch and see if there's any downstream fallout? It would also be great to see what the problematic RTX looks like. I'm pretty sure its either a SYMBOL_REF, a LABEL_REF or a CONST. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug target/26223] [4.0 regression] ICE on long double with -mno-80387
--- Comment #13 from roger at eyesopen dot com 2006-06-06 22:41 --- This should now be fixed on all active branches. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26223
[Bug tree-optimization/23452] Optimizing CONJG_EXPR (a) * a
--- Comment #3 from roger at eyesopen dot com 2006-06-01 02:41 --- This is now fixed on mainline provided the user specifies -ffast-math. There are some complications where imagpart(z*~z) can be non-zero, if imagpart(z) is non-finite, such as an Inf or a NaN. It's unclear from the fortran-95 standard whether gfortran is allowed to optimize this even without -ffast-math. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23452
[Bug middle-end/21067] Excessive optimization of floating point expression
--- Comment #4 from roger at eyesopen dot com 2006-05-20 15:14 --- This problem is fixed by specifying the -frounding-math command line option, which informs the compiler that non-default rounding modes may be used. With gcc-3.4, specifying this command line option disables this potentially problematic transformation. Strangely, on mainline, it looks like this transformation is no longer triggered, which may now indicate a missed optimization regression with (the default) -fno-rounding-math. We should also catch the division case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #12 from roger at eyesopen dot com 2006-05-18 01:50 --- This is now fixed on both mainline and the 4.1 branch. -- roger at eyesopen dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug rtl-optimization/14261] ICE due to if-conversion
--- Comment #5 from roger at eyesopen dot com 2006-05-15 17:37 --- This should now be fixed on both mainline and the 4.1 branch. Thanks Andreas. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14261
[Bug middle-end/26729] [4.0 regression] bad bitops folding
--- Comment #22 from roger at eyesopen dot com 2006-05-15 17:41 --- This should now be fixed on all open branches. -- roger at eyesopen dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.1.1 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug middle-end/26729] [4.0 regression] bad bitops folding
--- Comment #20 from roger at eyesopen dot com 2006-05-14 17:39 --- Hi APL, Re: comment #18. It was actually stevenb that changed the known to work line, and assigned this PR to me, after I'd committed a fix to the gcc-4_1-branch. See http://gcc.gnu.org/ml/gcc-bugs/2006-05/msg01351.html Marking 4.1.0 as known to work was a simple mistake/typo, and it should read that 4.1.0 is known to fail, but 4.1.1 is known to work. I retested b.cxx explicitly to confirm that it really is fixed on the release branch. -- roger at eyesopen dot com changed: What|Removed |Added Known to fail|3.3.6 3.4.3 4.0.2 |3.3.6 3.4.3 4.0.2 4.1.0 Known to work|2.95.4 4.2.0 4.1.0 |2.95.4 4.2.0 4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug middle-end/20722] select_section invoked with argument unlikely
--- Comment #2 from roger at eyesopen dot com 2006-05-13 18:59 ---
This is the correct documented behaviour. See the section entitled
USE_SELECT_SECTION_FOR_FUNCTIONS in doc/tm.texi, which reads:
@defmac USE_SELECT_SECTION_FOR_FUNCTIONS
Define this macro if you wish TARGET_ASM_SELECT_SECTION to be called
for @code{FUNCTION_DECL}s as well as for variables and constants.
In the case of a @code{FUNCTION_DECL}, @var{reloc} will be zero if the
function has been determined to be likely to be called, and nonzero if
it is unlikely to be called.
@end defmac
This is also cross referenced from the TARGET_ASM_SELECT_SECTION target
hook documentation, as the semantics for selecting function sections.
The only backend(s) that define USE_SELECT_SECTION_FOR_FUNCTIONS, darwin,
appears to implement the semantics as described above.
The two calls in function_section and current_function_section are guarded
by #ifdef USE_SELECT_SECTION_FOR_FUNCTIONS. Admittedly, this could have
been implemented by a second target hook, and/or the variable names in the
varasm functions could be less confusing, but this isn't a bug, and certainly
not P1.
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20722
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #8 from roger at eyesopen dot com 2006-05-11 17:22 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00472.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug tree-optimization/27285] [4.1 regression] ivopts postgresql miscompilation
--- Comment #8 from roger at eyesopen dot com 2006-05-08 15:29 --- I've now reconfirmed that this has been fixed on the gcc-4_1-branch by Jakub's backport of Zdenek's patch. Thanks to you both. -- roger at eyesopen dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27285
[Bug c/25309] [4.0/4.1/4.2 Regression] ICE on initialization of a huge array
--- Comment #10 from roger at eyesopen dot com 2006-05-04 00:14 --- This should now be fixed on mainline and all active branches. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.1.1 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug fortran/27269] Segfault with EQUIVALENCEs in modules together with ONLY clauses
--- Comment #5 from roger at eyesopen dot com 2006-05-02 14:24 --- This should now be fixed on mainline, thanks to Paul's patch. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27269
[Bug fortran/27324] Initialized module equivalence member causes assembler error
--- Comment #4 from roger at eyesopen dot com 2006-05-02 14:26 --- This should now be fixed on mainline by Paul's patch. Thanks. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27324
[Bug rtl-optimization/13335] cse of sub-expressions of zero_extend/sign_extend expressions
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 --- This bug is a duplicate of PR17104 which was fixed by Nathan Sidwell in November 2004. If you read comment #4, you'll notice that the failure of CSE to handle the rs6000's rs6000_emit_move's zero_extends is identical. *** This bug has been marked as a duplicate of 17104 *** -- roger at eyesopen dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13335
[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 --- *** Bug 13335 has been marked as a duplicate of this bug. *** -- roger at eyesopen dot com changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104
[Bug target/21283] [4.0 regression] ICE with doubles
--- Comment #6 from roger at eyesopen dot com 2006-04-26 18:59 --- This has now been fixed on the 4.1 branch. Unfortunately, its difficult to determine whether this patch is still needed on the 4.0 branch, or if other backports are also required, as libiberty and top-level configure are now incompatible between the gcc-4_0-branch and mainline src, making an uberbaum build of a 4.0 cross-compiler almost impossible. -- roger at eyesopen dot com changed: What|Removed |Added Known to fail|4.0.1 4.1.0 |4.0.1 Known to work|3.4.5 |3.4.5 4.1.1 4.2.0 Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with doubles|doubles Target Milestone|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21283
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #6 from roger at eyesopen dot com 2006-04-25 14:09 --- Paolo's fix looks good to me. The bugzilla PR shows that this is a 4.2 regression, probably due to the more aggressive RTL optimizations on mainline. So I'll preapprove Paolo's fix for mainline (please post the version you commit and a new testcase when you commit it). As for 4.1, do we have an example of a failure or wrong code generation against the branch? I can't tell from bugzilla whether this is safely latent in 4.0 and 4.1, or just hasn't been investigated there yet (known to work is blank, but the summary only lists [4.2]). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #8 from roger at eyesopen dot com 2006-04-25 15:41 --- Grr. David's patch is also good. Perhaps better if we follow the usual protocol of posting patches to gcc-patches *after* bootstrap and regression testing, for review and approval. Posting untested patch fragments to bugzilla without ChangeLog entries and asking for preapproval etc... seems to, in this instance at least, demonstrate why GCC has the contribution protocols that it has. Thanks to David for catching this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug target/16641] fr30-elf-gcc compiler error when building newlib-1.12.0
--- Comment #6 from roger at eyesopen dot com 2006-04-23 21:19 --- This should now be fixed on mainline. I've confirmed that a cross-compiler to fr30-elf currently builds newlib without problems. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16641
[Bug target/21283] [4.0/4.1 regression] ICE with doubles
--- Comment #4 from roger at eyesopen dot com 2006-04-23 21:27 --- This has now been fixed on mainline. I've confirmed that a cross-compiler to fr30-elf can currently compile all of newlib without problems. If anyone has an fr30 board or a simulator to check the testsuite that would be great. -- roger at eyesopen dot com changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with doubles|with doubles Target Milestone|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21283
[Bug target/25203] [4.0] enable checking failure in g++.dg/opt/mmx2.C
--- Comment #3 from roger at eyesopen dot com 2006-04-07 05:30 --- This appears to be a problem with instruction attributes in the x86 backend, and looks to be still present (but latent?) on mainline. The problem is that i386.c's memory define_attr tries to determine whether an insn is a load for insns of type mmxadd if either operands[1] or operands[2] is a memory operand. See the (match_operand 2 ...) line, shortly after line 460 of i386.md. This interacts badly with the definitions of the *movsi_1 and *movdi_1_rex64 define_insns where certain alternatives claim that they are of insn type mmxadd, even though they have only two operands. This leads the generated get_attr_memory to inspect the uninitialized operands[2] for these insns. The problem can be corrected by changing the insn type attribute for the problematic variants of *movsi_1 and *movdi_1_rex64. Which type they should be (and how that interacts with scheduling etc...) is beyond me. Perhaps a new mmxclr or mmxunary type, or resuse the existing mmxcvt type, to denote unary MMX operations. Alternatively, the memory attribute could be made more complex to recognize these two exceptions. Or a third alternative, is to specify the memory attribute of these two insns explicitly. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-07 05:30:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25203
[Bug middle-end/26977] [4.2 regression] ICE in emit_move_insn
--- Comment #3 from roger at eyesopen dot com 2006-04-02 15:53 --- Thanks Andreas. Well my prediction that the bogus call wouldn't come from emit_group_store was wrong. There's now a trivial fix to resolve this PR which is to add if (temp) tests around the emit_move_insn, done=true and start/end updates. But this may be papering over the problem. Could you list the arguments that we pass to the immediately preceding call to simplify_gen_subreg? Ohhh... simplify_gen_subreg can return a NULL_RTX! I'll prepare a patch, but I'm curious what SUBREG we attempt to construct on IA-64. Should have a fix tested/committed in a few hours. -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-02 15:53:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26977
[Bug middle-end/26977] [4.2 regression] ICE in emit_move_insn
--- Comment #1 from roger at eyesopen dot com 2006-04-02 03:07 --- Damn. Unfortunately, although I have four different IA-64 boxes, one none of them can I test Ada. Is it possible to attach the traceback of the failure to the bugzilla PR? Clearly the fact that y is NULL_RTX at the assertion is problematic, but I can't tell where the call to emit_move_insn is coming from. The new calls to emit_move_insn in the PR17959 fix both pass the result from simplify_gen_subreg which should never return NULL, i.e. the problematic call is probably not directly related to the change. I'll start an ia64-unknown-linux-gnu bootstrap here anyway, just to see if anything strange is happening in the testsuite. Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26977
[Bug c++/22494] C++ front-end produces mis-match types in EQ_EXPR (array deconstructor)
--- Comment #2 from roger at eyesopen dot com 2006-03-30 21:24 --- This should now be fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22494
[Bug target/17959] -mpowerpc64 can cause worse code than without it
--- Comment #3 from roger at eyesopen dot com 2006-03-30 21:35 --- This is now be fixed on mainline. With -mpowerpc64, we now generate: _div16: rldimi 3,4,0,32 srdi 4,3,4 srdi 3,3,36 blr -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17959
[Bug middle-end/22375] fold_builtins creates mis-matched types
--- Comment #3 from roger at eyesopen dot com 2006-03-30 23:01 --- This has now been fixed on mainline, and I've also checked that the extra load mentioned in comment #1 is now also resolved. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22375
[Bug middle-end/22524] fold (or the front-ends) produces UNARY (BIT_NOT_EXPR) tree with mismatch types
--- Comment #7 from roger at eyesopen dot com 2006-03-28 19:34 --- This should now be fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22524
[Bug c++/14644] enum of value zero not converted to (null) pointer
--- Comment #2 from roger at eyesopen dot com 2006-03-28 21:46 ---
I believe that this may not be a g++ bug. The wording of the standard is:
[conv.ptr] An null pointer constant is an *integral* constant expression
(_expr.const_) rvalue of integer type that evaluates to zero.
Ignoring the term rvalue which was the cause of the misinterpretation
of PR13867, the important aspect is the explicit use of integral.
Both [expr.const] and [basic.fundamental] distinguish between integral and
enumeration constants. Hence, given the definition enum { NULL = 0 };,
I believe that NULL is an enumeral constant expression, and that
(int)NULL is integral constant expression. Note that enumerators may
appear in integral constant expressions, but are not themselves integral
constant expressions.
See footnote 20) in section [basic.fundamental] that reiterates:
20) Therefore, enumerations (_dcl.enum_) are not integral; however,
enumerations can be promoted to int, unsigned int, long, or unsigned
long, as specified in _conv.prom_.
Note that a standard conversion can contain at most one conversion from
the set integral promotions [conv.prom] and pointer conversions
[conv.ptr]. i.e. you can't get from enumerator to a pointer in a
single standard conversion sequence, by my reading of the wording.
Hence in your testcase foo(NULL) is probably invalid, but foo((int)NULL)
should be fine. Notice if that foo is overloaded, i.e. foo(int) and
foo(int*), there is no ambiguity with using foo(NULL).
Although this could perhaps be supported as a GNU extension in
cp/call.c:standard_conversion, if there are other compilers that support
this, the fact that there's a simple fix to make the source code standard
conforming, means that such a patch would unlikely be accepted.
Of course, this may be poor wording in the standard. I notice that
Stroustrup originally used the wording A constant expression that
evaluates to 0 ..., and again states that a constant expression
evaluates to an integral or enumeration constant.. So this looks like
something standardization tightened up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14644
[Bug middle-end/26379] [4.0 Regression] ICE on vector shift RTL simplification
--- Comment #7 from roger at eyesopen dot com 2006-03-17 00:17 --- I've now committed this patch (as approved by Mark) to the 4.0 branch for Jakub, so this PR can be closed. -- roger at eyesopen dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26379
[Bug tree-optimization/26524] [4.1 Regression] ICE when compiling with -ffast-math and -O3 clatm5.f (lapack)
--- Comment #8 from roger at eyesopen dot com 2006-03-02 21:39 --- I think I've found the problem. On mainline, its in tree-scalar-evolution.c at around line 1652, where where handle NEGATE_EXPR in interpret_rhs_modify_expr. The code checks whether the type is SCALAR_FLOAT_TYPE_P, in which case it uses build_real, otherwise it calls build_int_cst_type. Unfortunately, with a complex type, we end up generating a (const_int (complex4) -1) which is very broken. I believe a suitable fix would be to replace this logic with something like fold_convert (type, integer_minus_one_node), which will produce the correct result for integers, reals and complex numbers. My change to fold-const.c just has stricter error checking and refuses to fold operations of mismatched types, and return NULL_TREE instead. It wasn't a fix, it just hid the problem which is still present but latent on mainline. I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26524
[Bug other/26489] [4.1/4.2 Regression] compilation of c++ fails in eh_alloc.cc on NetBSD
--- Comment #9 from roger at eyesopen dot com 2006-02-28 02:07 --- Created an attachment (id=10932) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10932action=view) patch I think this untested patch might fix things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26489
[Bug other/26489] [4.1/4.2 Regression] compilation of c++ fails in eh_alloc.cc on NetBSD
--- Comment #11 from roger at eyesopen dot com 2006-02-28 03:23 --- Created an attachment (id=10934) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10934action=view) mainline patch v2 Here is a revised and slightly more tested version of the proposed patch for mainline. The 4.1 branch patch is identical except s/static/external/ in the definition of __gthrw2. 2006-02-27 Roger Sayle [EMAIL PROTECTED] PR middle-end/26489 * gthr-posix.h (__gthrw2): Define to take three parameters, the declared name, the weak reference name, and the typeof name. (__gthrw): Avoid expanding the declared name suffix. (__gthrw3): New Tru64 specific macro to simplify the OSF/1 decls. -- roger at eyesopen dot com changed: What|Removed |Added Attachment #10932|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26489
[Bug other/26489] [4.1/4.2 Regression] compilation of c++ fails in eh_alloc.cc on NetBSD
--- Comment #12 from roger at eyesopen dot com 2006-02-28 03:30 --- Hi moof, the way that you can test this patch is to run make -k check from the top-level after bootstrapping the tree. You'll notice that even before my change (with RC1 for example), there'll be several thousand libstdc++ and libgfortran failures. With the newly proposed patch, you should now see only a handful of failures for these testsuites. I hope this helps. -- roger at eyesopen dot com changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26489
[Bug rtl-optimization/14261] ICE due to if-conversion
--- Comment #2 from roger at eyesopen dot com 2006-02-26 15:00 --- I've posted a proposed solution to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01909.html -- roger at eyesopen dot com changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14261
[Bug middle-end/21137] Convert (a 2) 1 != 0 into a 4 != 0
--- Comment #8 from roger at eyesopen dot com 2006-02-26 18:39 --- Fixed on mainline. I'm still investiating some related optimizations. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug middle-end/23673] fold does not fold (a^b) != 0 to a != b
--- Comment #7 from roger at eyesopen dot com 2006-02-25 23:36 --- Fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23673
[Bug middle-end/24952] ICE: RTL check: expected code 'set' or 'clobber', have 'unspec' in try_combine, at combine.c:2898
--- Comment #3 from roger at eyesopen dot com 2006-02-24 19:37 --- This has now been fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24952
[Bug middle-end/26236] [4.2 Regression] CHAR_TYPE is still referenced in c-tree.texi
--- Comment #3 from roger at eyesopen dot com 2006-02-20 15:05 --- Fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26236
[Bug tree-optimization/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
--- Comment #21 from roger at eyesopen dot com 2006-02-20 21:07 --- Created an attachment (id=10881) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10881action=view) patch I believe the following patch should resolve the problem. Bootstrap and regression test in progress. The issue is that -[0,(unsigned)-1] is being miscalculated in extract_range_from_unary_expr. This was simply negating the upper and lower bounds, and came up with [0,1]. If someone could double check my logic in the attached patch, [x, y] - [-y, -x] when x 0, [0, 0] - [0, 0], and [0, y] - varying, i.e. [0, (unsigned)-1] when y 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
[Bug tree-optimization/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
--- Comment #22 from roger at eyesopen dot com 2006-02-20 21:33 --- Created an attachment (id=10882) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10882action=view) revised patch Doh! Although the previous attachment contained the necessary logic, it had a few typos which will complicate people's attempts to try it out. Revised. -- roger at eyesopen dot com changed: What|Removed |Added Attachment #10881|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
[Bug tree-optimization/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
--- Comment #23 from roger at eyesopen dot com 2006-02-20 21:37 --- Created an attachment (id=10883) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10883action=view) really revised patch Grrr! The previous attachment was identical to the original. Third times a charm (or I'll just give up an commit it once bootstrap and regtest complete!). -- roger at eyesopen dot com changed: What|Removed |Added Attachment #10882|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
--- Comment #10 from roger at eyesopen dot com 2006-02-20 03:11 --- Analyzing the code in comment #5, this looks like a bad interaction between ivopts and vrp. Either of -fno-ivopts or -fno-tree-vrp cures the problem. But it looks like the output of .084t.ivopts is reasonable. -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
--- Comment #11 from roger at eyesopen dot com 2006-02-20 03:52 ---
Hmmm. Looks like the problem is in .088t.vrp2
We have
unsigned int D.1981;
unsigned int D.1982;
D.1982_9 = -D.1981_1;
D.1981_1: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1982_9: [0, 1] EQUIVALENCES: { } (0 elements)
Seems like a bug in the interval arithmetic of NEGATE_EXPR for unsigned types.
- [0, (unsigned)-1] seems to be converted to [0, 1]!!? I hope this helps.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #13 from roger at eyesopen dot com 2006-02-20 04:10 --- Many thanks to Mark, Richard and David! This is now fixed on both mainline and the gcc-4_1-branch in time for the 4.1 release. On mips-sgi-irix6.5, for the 4.1 branch I now see the following (which is much better than before!) === gfortran Summary === # of expected passes11578 # of unexpected failures18 # of expected failures 12 # of unsupported tests 26 -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug middle-end/25724] Emits call to __cmpdi2 for long long comparison in switches
--- Comment #9 from roger at eyesopen dot com 2006-02-13 18:51 --- This has now been fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25724
[Bug libgomp/25936] libgomp needs to link against rt on HPUX
--- Comment #7 from roger at eyesopen dot com 2006-02-13 19:02 --- This has now been fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25936
[Bug middle-end/24427] missing optimization opportunity with binary operators
--- Comment #4 from roger at eyesopen dot com 2006-02-14 03:07 --- This has now been fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24427
[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #10 from roger at eyesopen dot com 2006-02-09 14:41 ---
Hi David, nm $objdir/gcc/libgcc.a contains both __ctzdi2 and __ctzti2 for me.
grasp% nm libgcc.a | grep ctz
_ctzsi2.o:
T __ctzdi2
_ctzdi2.o:
T __ctzti2
The post-commit bootstrap and regression test on IRIX 6.5.19m just completed
fine for me, with the following gfortran test results.
gfortran
# of expected passes11485
# of unexpected failures20
# of expected failures 12
# of unsupported tests 26
Could you investigate this failure a bit further? I've no idea why you should
be seeing these problems. If it makes any difference I configure with:
${SRCDIR}/configure --with-gnu-as --with-as=/usr/local/bin/as \
--with-gnu-ld --with-ld=/usr/local/bin/ld
Where the above as and ld are both binutils 2.16. I've had trouble with
binutils 2.16.1's ld on IRIX built both with MIPSPro cc and gcc 3.4.3 so we
currently stick with 2.16, but I'll investigate if that makes a difference.
--
roger at eyesopen dot com changed:
What|Removed |Added
CC||roger at eyesopen dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #11 from roger at eyesopen dot com 2006-02-09 14:54 --- p.s. I can also confirm that this patch fixes the test case in PR25028 for me on mips-sgi-irix6.5. This failed previously with undefined references to __floattisf and __floattidf, but now not only compiles and links but produces the correct output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug other/25028] TImode-to-floating conversions broken
--- Comment #4 from roger at eyesopen dot com 2006-02-09 15:00 --- My recent fix for PR target/22209 adding TImode support for MIPS, just fixed this PR's testcase for me on mips-sgi-irix6.5. The new fix*.c and float*.c source files may be useful in resolving the remaining PR25028 issue on ia64/HPUX? I'll investigate. -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug libgomp/25936] libgomp needs to link against rt on HPUX
--- Comment #4 from roger at eyesopen dot com 2006-02-08 17:46 --- This problem affects both hppa*-hp-hpux* and ia64-hp-hpux*. It appears that the required sem_init, sem_wait, sem_post, etc... symbols are defined both in the -lrt libraries on HPUX and in the -lc_r libraries. The fix is to update LIB_SPEC, perhaps in the -pthread clause, for HPUX, but I'm not sure if it requires adding -lrt or changing -lc to -lc_r, or adding -lc_r? I notice that config/pa/pa-hpux10.h does mention -lc_r, but for use with -threads. Should -pthread pull in the required symbols? i.e. is this a libgomp problem or a target problem? -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25936
[Bug bootstrap/26161] New: Configure tests for pthread.h sometimes need to use -pthread
The problem is that on some systems, including Tru64 and I believe AIX, the compiler has to be passed the -pthread command line option in order to use #include pthread.h Effectively, the first lines of /usr/include/pthread.h contain the lines: #ifndef _REENTRANT #error POSIX pthreads are only available with the use of -pthreads #endif For this reason the autoconf tests of pthread.h in libstdc++-v3 and libgomp always fail. Fortunately, this was previously not serious, as the target configurations would include pthread.h anyway, and all the relevant source libraries are compiled with -pthread. In directories where they don't, GCC has workarounds, such as in gcc/gcc-posix.h which contains the lines: /* Some implementations of pthread.h require this to be defined. */ #ifndef _REENTRANT #define _REENTRANT 1 #endif #include pthread.h This issue escalcated to a bootstrap failure in libgomp recently, which now aborts whilst configuring libgomp when pthread.h isn't detected. Prior to this change, libgomp built fine and the test results were quite reasonable on Alpha/Tru64. [Stretching the definition of a regression :-)] I believe that what is needed is a local configure test for pthread.h that first decides whether the compiler supports -pthread (for example, GCC on IRIX currently does not), and then uses this flag testing for headers. This is perhaps similar to the related patch I posted recently, where we need to test system header with the same compiler options we'll be using to build the source files: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00139.html See the related definitions of THREADCXXFLAGS and THREADLDFLAGS in libjava's configure.ac. Unfortunately, my autoconf-fu isn't strong enough to tackle this. The temporary work-around is to use --disable-libgomp. The long-term fix would be to port libgomp to use GCC's gthreads library. But in the meantime, it would be good to correct the test for pthread.h and/or add a PTHREAD_CFLAGS that can be used any project. I'm happy to test patches on affected systems. However, it should be trivial to re-create a model system with the above lines and using -D_REENTRANT as the compiler option that needs to be passed. -- Summary: Configure tests for pthread.h sometimes need to use - pthread Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roger at eyesopen dot com GCC host triplet: alpha*-*-osf* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26161
[Bug bootstrap/26161] Configure tests for pthread.h sometimes need to use -pthread
--- Comment #2 from roger at eyesopen dot com 2006-02-07 21:15 --- I've discovered your bootstrap failure is PR16787. It'll take a while for me to try out your XCFLAGS fix on my slow machine. I'll also propose a fix for PR16787. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26161
