--- Comment #13 from patchapp at dberlin dot org 2007-04-20 07:45 ---
Subject: Bug number PR 27740
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01253.html
--
--- Comment #14 from jb at gcc dot gnu dot org 2007-04-20 07:45 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01253.html
Also removed the dependency on PR25709 (ISO_C_BINDING), since we don't depend
on that one anymore for this functionality.
--
jb at gcc dot gnu dot
--- Comment #14 from dannysmith at users dot sourceforge dot net
2007-04-20 07:49 ---
(In reply to comment #13)
I'm going to try again since it seems my last post was just ignored.
The test case works fine on 4.2 but it still occurs under some circumstances.
If you provide
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-04-20 08:45 ---
A binary search shows that this started to fail from
the revision 123295
* config/sh/sh.md (movsi_ie): Fix memory constraints attribute length.
I'd like to add Christian to the cc list because he must be
--- Comment #2 from pcarlini at suse dot de 2007-04-20 08:50 ---
I will check, but I don't think this can possibly happen in mainline, after we
fixed c++/30500. Otherwise, the underlying issue is libstdc++/19495, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
The sh4 port aligns blocks that have no fallthrus and that are either
frequently executed (JUMP_ALIGN) or preceeded a barrier
(LABEL_ALIGN_AFTER_BARRIER) on a cache line.
While in theory this help to avoid cache misses if the block slits over 2 cache
lines, in practise this reduces cache locality
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Summary|cache align alignment is too|cache block
--- Comment #4 from jakub at gcc dot gnu dot org 2007-04-20 12:40 ---
Subject: Bug 31632
Author: jakub
Date: Fri Apr 20 12:40:47 2007
New Revision: 123988
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123988
Log:
PR tree-optimization/31632
* fold-const.c
--- Comment #3 from ian at airs dot com 2007-04-20 16:17 ---
Created an attachment (id=13394)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13394action=view)
Proposed patch
This patch fixes the test case in the PR. I am testing it. It would be
interesting to hear whether it also
--- Comment #1 from chrbr at gcc dot gnu dot org 2007-04-20 14:13 ---
Created an attachment (id=13391)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13391action=view)
Illustrative patch to not align small basic blocks
I used this patch to reduce the number of basic blocks aligned
--- Comment #1 from tbm at cyrius dot com 2007-04-20 15:25 ---
Created an attachment (id=13392)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13392action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[ Forwarded from http://bugs.debian.org/395533 ]
We're seeing the following ICE on s390. This is with gcc 4.1, but I can
also reproduce it with current 4.3 from SVN. I haven't tried 4.0, but 3.4
works.
raptor% /usr/lib/gcc-snapshot/bin/g++ -c -O min4.c
min4.c: In member function 'void
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-20 15:33 ---
Note that this does fix the loop invariant motion only in the case of two
ifs can be merged (because that re-instantiates the A (1 B) form). The
following parts are still not resolved:
void quantum_cnot(int
Using -O2 -fno-guess-branch-probability -fno-tree-ch -fno-tree-dominator-opts
-fno-tree-lrs -fno-tree-dce -fno-tree-vrp -funit-at-a-time -ftree-copy-prop
-ftree-copyrename on the SPEC CPU2000 benchmark 176.gcc yields an infinite loop
(using the train input which usually runs for 2s runs for
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-04-20 16:09 ---
Subject: Re: Missed invariant out of the loop with conditionals and shifts
void quantum_cnot(int control, int target, unsigned long *state, int size)
{
int i;
for(i=0; isize; i++)
--- Comment #2 from chrbr at gcc dot gnu dot org 2007-04-20 15:51 ---
Created an attachment (id=13393)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13393action=view)
testcase for new instruction introduced by increased distance
In this example, the max distance between the jump
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-20 13:51 ---
Mine. I have a tree if-conversion patch that produces
L0:;
D.1993 = MEM[base: state, index: ivtmp.32, step: 8];
if (pretmp.25 == (pretmp.25 D.1993)) goto L1; else goto L3;
L1:;
MEM[base: state, index:
--- Comment #5 from jakub at gcc dot gnu dot org 2007-04-20 12:46 ---
Subject: Bug 31632
Author: jakub
Date: Fri Apr 20 12:46:06 2007
New Revision: 123990
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123990
Log:
PR tree-optimization/31632
* fold-const.c
--- Comment #6 from jakub at gcc dot gnu dot org 2007-04-20 12:49 ---
Subject: Bug 31632
Author: jakub
Date: Fri Apr 20 12:49:37 2007
New Revision: 123992
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123992
Log:
PR tree-optimization/31632
* fold-const.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-04-20 16:59 ---
I posted a patch for the tree level im instead to handle this special case
right
after the reciprocal special case. I agree it's a special case, but as it
happens
in spec 2k6...
--
--- Comment #15 from arcangelpip at hotmail dot com 2007-04-20 17:06
---
Don't you just hate idiots in these cases. (Yes, I am referring to myself here)
Well, it's completely broken again on my system, look here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31636
I apologise for
--- Comment #4 from tromey at gcc dot gnu dot org 2007-04-20 17:39 ---
Please post the output of running gcj -C -v Fail.java
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31622
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-20 18:24 ---
We need a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ddneilson at gmail dot com 2007-04-20 18:51 ---
(In reply to comment #9)
(In reply to comment #8)
The work around is doing:
get_a().template func2 int();
Which tells the compiler for sure func2 is a template.
Thanks, yeh I figured that out
--- Comment #2 from kenneth dot hoste at elis dot ugent dot be 2007-04-20
19:24 ---
(In reply to comment #1)
We need a testcase.
I would provide one if I knew how, I'm quite new at this... Any pointers?
--
kenneth dot hoste at elis dot ugent dot be changed:
What
--- Comment #1 from janis at gcc dot gnu dot org 2007-04-20 19:35 ---
This starts passing for me between 2007-03-10 and 2007-03-20. Andrew, if it
fails for you with a later mainline than that, perhaps it's an intermittent
failure rather than a regression.
--
--- Comment #4 from drow at gcc dot gnu dot org 2007-04-20 20:04 ---
Subject: Re: Overflow warning causes GDB
-Werror build failure
On Fri, Apr 20, 2007 at 03:17:19PM -, ian at airs dot com wrote:
This patch fixes the test case in the PR. I am testing it. It would be
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-20 20:30 ---
I was testing at the time 4.3.0 20070306 and I tested with yesterday's trunk
and it passes. It also works on the 4.2 branch as of 4.2.0 20070415.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from rth at gcc dot gnu dot org 2007-04-20 20:36 ---
Subject: Bug 28623
Author: rth
Date: Fri Apr 20 20:35:55 2007
New Revision: 124002
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124002
Log:
PR target/28623
* config/alpha/alpha.c
--- Comment #3 from kenneth dot hoste at elis dot ugent dot be 2007-04-20
20:51 ---
identifying source code lines corresponding to infinite loop using GDB:
(gdb) backtrace
#0 regclass (f=0x9ac29f4, nregs=71) at regclass.c:732
#1 0x08065d5c in rest_of_compilation
--- Comment #12 from bdavis at gcc dot gnu dot org 2007-04-20 20:56 ---
i can confirm the attached patch is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
--- Comment #96 from David dot Monniaux at ens dot fr 2007-04-20 21:19
---
The following paper explains how this kind of behaviour occurs, why it is
correct, why it is difficult to fix but how it can be partly fixed, and how
this breaks many testing and proving techniques:
--- Comment #20 from steven at gcc dot gnu dot org 2007-04-20 21:58 ---
It is my intention to fix see.c to work on x86* hardware, so I'm taking this
bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from steven at gcc dot gnu dot org 2007-04-20 22:10 ---
Collection of important related links:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00766.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437#c5
--
steven at gcc dot gnu dot org changed:
What
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-04-20 22:13
---
(In reply to comment #11)
Time to CC Janis?
No need. There's nothing a bit of trial-and-error can't help you write :)
The following adds the necessary dejagnu directive, and uses it in a new test.
I guess the
Problem:
When calling the out() method of a codecvt facet for a locale that specifies
UTF-8 encoding, the method fails to recognize partial (i.e., incomplete) UTF-8
encoding sequences at the end of the source string. Instead of returning the
expected
std::codecvt_base::partial status code with
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-04-20 22:29 ---
Strictly speaking, this is not a violation of the
Fortran standard, as there are no guarantees of what happens
after an error.
Nonetheless, we should fix it.
I'm investigating.
--
--- Comment #1 from jcavalla at postini dot com 2007-04-20 22:30 ---
Created an attachment (id=13395)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13395action=view)
Verbose compilation output
Produced with:
g++ -v --save-temps -Wall -ansi -pedantic -g -o localetest
--- Comment #2 from jcavalla at postini dot com 2007-04-20 22:31 ---
Created an attachment (id=13396)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13396action=view)
Original test case source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
--- Comment #3 from jcavalla at postini dot com 2007-04-20 22:31 ---
Created an attachment (id=13397)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13397action=view)
Preprocessed intermediate file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
--- Comment #4 from jcavalla at postini dot com 2007-04-20 22:32 ---
Created an attachment (id=13398)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13398action=view)
Test results
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
--- Comment #5 from jcavalla at postini dot com 2007-04-20 22:37 ---
1. Please note that 'g++' was used to compile, not 'gcc' as stated below.
Sorry.
2. I marked this bug 'major' instead or 'normal' because callers will not be
able to determine whether or not they need to supply
--- Comment #6 from jcavalla at postini dot com 2007-04-20 22:59 ---
I ran additional tests just to make sure that the shift state was valid across
calls, even though partial is not returned when a chunk ends in a partial
encoding sequence. I split several 2,3, and 4 byte UTF character
--- Comment #6 from rth at gcc dot gnu dot org 2007-04-21 00:53 ---
Subject: Bug 31628
Author: rth
Date: Sat Apr 21 00:53:37 2007
New Revision: 124014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124014
Log:
PR target/31628
* config/i386/i386.c
--- Comment #7 from rth at gcc dot gnu dot org 2007-04-21 00:58 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from ian at airs dot com 2007-04-21 02:08 ---
Created an attachment (id=13399)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13399action=view)
Proposed patch
Currently testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
--- Comment #6 from zackw at panix dot com 2007-04-21 02:56 ---
I am inclined to think that this is an operating system bug and should be
worked around in the mingw32 libraries, not in cpplib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242
47 matches
Mail list logo
