We held a GCC mini-summit at Google on Wednesday, April 18. About 40
people came. This is my very brief summary of what we talked about.
Corrections and additions very welcome.
The goal of the mini-summit was just to let gcc developers meet face
to face and talk. There was no goal of actually
On 20 Apr 2007, at 08:30, Ian Lance Taylor wrote:
11) H.J. Lu discussed SPEC CPU 2006. He reported that a couple of the
tests do not run successfully, and it appears to be due to bugs in
the tests which cause gcc to compile them in unexpected ways. He
has been reporting the
On 20 Apr 2007, at 08:30, Ian Lance Taylor wrote:
13) Michael Meissner raised the idea of compiling functions
differently for different processors, choosing the version based
on a runtime decision. This led to some discussion of how this
could be done effectively. In particular
Related to this: have you guys ever considered to making the -On
flags dependent on the architecture?
It came up in a few side conversations. As I understand it, RMS has
decreed that the -On optimizations shall be architecture independent.
That said, there are generic optimizations which
Hello all,
I`m working with an arm core 9260EJ-S under Linux (Linux kernel 2.6.15;
armv5l-linux toolchain with compiler gnu gcc 3.4.2). I would like to
take advantage of the asm DSP like functions the core provides. I
compile this way:
arm-linux-gnu -msoft-float -mtune=arm926ejs -S mul.c
On Apr 20, 2007, at 1:24 AM, Victor Librado wrote:
Hello all,
I`m working with an arm core 9260EJ-S under Linux (Linux kernel
2.6.15; armv5l-linux toolchain with compiler gnu gcc 3.4.2). I
would like to take advantage of the asm DSP like functions the core
provides. I compile this way:
On Fri, 2007-04-20 at 10:24 +0200, Victor Librado wrote:
Hello all,
I`m working with an arm core 9260EJ-S under Linux (Linux kernel 2.6.15;
armv5l-linux toolchain with compiler gnu gcc 3.4.2). I would like to
take advantage of the asm DSP like functions the core provides. I
compile this
10) Eric Christopher reported that Tom Tromey (who was not present)
had suggested a new mascot for gcc: a unicorn with rainbows. This
was met with general approval, and Eric suggested that everybody
e-mail Tom with their comments. I personally would like to see
the drawing.
Hi,
I have built a tool chain for m32c target using the latest sources.
I am using a third party debugger to debug the application built
using this tool chain. However, I am not able to view the complete
call stack. It seems that the .debug_frame section is not
generating the correct unwind
[adjusting Subject and also forwarding to [EMAIL PROTECTED]
On Wed, 2007-04-18 at 12:12 -0700, Vivek Rao wrote:
Here is a feature of g95 that I would like to see in
gfortran. G95 assigns numbers to warnings and allows
selected warnings to be treated as errors.
[...]
g95 -Wall -Wextra
On Fri, 20 Apr 2007, Fran?ois-Xavier Coudert wrote:
Attached is a first draft of a patch to add a -fstatic-libgfortran
option. This new option is recognized by the driver and instead of
I think -static-libgfortran (no initial f) would be a better spelling,
for consistency with -static-libgcc.
On 4/20/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
I am afraid that merging it earlier stops progress on the df
infrastructurey (e.g. Ken will work only on LTO)
There's nothing holding you, and many others, back from helping out,
other than that the work is on a branch. By merging, the
Vladimir N. Makarov wrote:
And I am disagree that it is within compilation time guidelines set
by SC. Ken fixed a big compilation time degradation a few days ago
and preliminary what I see now (comparison with the last merge point)
is
x86_64
SPECInt2000 5.7%
SPECFp200 8.7%
ppc64
On 4/20/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
Did not I write several times that the data structure of DF is too fat
(because rtl info duplication) and that is probably the problem?
Yes, you have complained that you believe the data structure of DF is
too fat. I guess that is a
Steven Bosscher wrote:
On 4/20/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
Did not I write several times that the data structure of DF is too fat
(because rtl info duplication) and that is probably the problem?
Yes, you have complained that you believe the data structure of DF is
too
On 4/20/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
Yes, you have complained that you believe the data structure of DF is
too fat. I guess that is a valid complaint. I don't see the rtl info
duplication though. You've only complained about the current data
structures, but I have not
Those frame offsets are relative to $fp, not $sp. *Those* offsets are
the same for those functions. Your debugger needs to interpret the
DW_CFA_def_cfa_reg codes.
Hi Dorit,
SSE4 has vector zero/sign-extensions like:
(define_insn sse4_1_zero_extendv2siv2di2
[(set (match_operand:V2DI 0 register_operand =x)
(zero_extend:V2DI
(vec_select:V2SI
(match_operand:V4SI 1 nonimmediate_operand xm)
(parallel [(const_int
Nigel Stephens [EMAIL PROTECTED] writes:
OK, so maybe as the person who removed adddi3 from the MIPS backend, and
the main proponent of the new fused opcodes, you get to volunteer to
implement this? :)
Hey, I was pretty happy with the status quo ;)
Richard
Richard Sandiford wrote:
Nigel Stephens [EMAIL PROTECTED] writes:
I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris,
mcore, score, arm pa backends still implement adddi3 as either a
define_insn which outputs two instructions or an explicit define_expand
followed
Kenneth Hoste [EMAIL PROTECTED] writes:
A related question: how is decided which priority a bug gets?
In general the release manager, Mark Mitchell, sets the priorities of
bugs in the bug database. He follows general guidelines where
wrong-code is more important, primary platforms are more
On 20/04/07, Joseph S. Myers [EMAIL PROTECTED] wrote:
On Fri, 20 Apr 2007, Thomas Koenig wrote:
This does sound like a useful feature, not only for
gfortran, but for all of gcc.
GCC has -Werror=foo in 4.2 or later (with warning option names, not
numbers). That gives you the command-line
Steven Bosscher wrote:
On 4/20/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
I am afraid that merging it earlier stops progress on the df
infrastructurey (e.g. Ken will work only on LTO)
There's nothing holding you, and many others, back from helping out,
other than that the work is on
Richard Sandiford wrote:
Nigel Stephens [EMAIL PROTECTED] writes:
While I agree with you philosophically, it feels like (b) might be quite
a major task. A number of optimisation passes which currently recognise
and MUL and PLUS separately (e.g. loop strength reduction) would now
need to
Nigel Stephens [EMAIL PROTECTED] writes:
I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris,
mcore, score, arm pa backends still implement adddi3 as either a
define_insn which outputs two instructions or an explicit define_expand
followed define_split and associated sub
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem to me that in the
Tree-SSA world, it makes less sense to duplicate standard optabs
in the backend purely for the reason of keeping
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem to me that in the
Tree-SSA world, it makes less sense to duplicate standard optabs
in the
Richard Sandiford [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem to me that in the
Tree-SSA world, it makes
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem
10) Eric Christopher reported that Tom Tromey (who was not present)
had suggested a new mascot for gcc: a unicorn with rainbows. This
was met with general approval, and Eric suggested that everybody
e-mail Tom with their comments. I personally would like to see
the
On Fri, Apr 20, 2007 at 12:58:39AM -0700, Ollie Wild wrote:
Related to this: have you guys ever considered to making the -On
flags dependent on the architecture?
It came up in a few side conversations. As I understand it, RMS has
decreed that the -On optimizations shall be architecture
Hi folks.
I have some preliminary code laying out the tuples infrastructure as has
been documented in the tuples design document.
I'd like to get this out for public review sooner than later, to make sure
I'm not taking any wrong approaches, and folks know where things are. I'll
be reviving the
We discussed the patch tracker. None of the active maintainers who
were there appear to use it very much or at all.
This is because it does not enable them to easily review patches, only
to see which they have missed ;)
I proposed
automatic e-mail pings, but that wasn't generally
Ok can you tell me what directives does it provide to do what I
have said . And I am not a beginner to gcc.
1. Repeating a block a certain number of times
for example
repeat expr
foo()
end
Then you can call expr 5 to have foo called 5 times.
2. Multiline macros with new lines
On 20 April 2007 18:28, drizzle drizzle wrote:
Ok can you tell me what directives does it provide to do what I
have said . And I am not a beginner to gcc.
Then you should have RTFMd by now.
cheers,
DaveK
--
Can't think of a witty .sigline today
Ian I proposed automatic e-mail pings, but that wasn't generally
Ian welcomed.
Bummer. Why?
Dan If people are okay with this, I have no problem implementing it.
If you're taking feature requests, it would be handy to canonize the
Area field somehow. I was filtering based on preprocessor and
On 20 April 2007 18:43, Tom Tromey wrote:
Ian I proposed automatic e-mail pings, but that wasn't generally
Ian welcomed.
Bummer. Why?
Dan If people are okay with this, I have no problem implementing it.
If you're taking feature requests, it would be handy to canonize the
Area field
Dave == Dave Korn [EMAIL PROTECTED] writes:
If you're taking feature requests, it would be handy to canonize the
Area field somehow. I was filtering based on preprocessor and then
yesterday noticed things filed against libcpp and cpp.
Dave Heh. Guilty as charged.
Sorry, wasn't trying to
On Fri, Apr 20, 2007 at 01:27:48PM -0400, drizzle drizzle wrote:
Ok can you tell me what directives does it provide to do what I
have said . And I am not a beginner to gcc.
The answer is that gcc provides what the C standard specifies and nothing
more. You appear to want a more
On 20 Apr 2007 11:42:57 -0600, Tom Tromey [EMAIL PROTECTED] wrote:
Ian I proposed automatic e-mail pings, but that wasn't generally
Ian welcomed.
Bummer. Why?
Dan If people are okay with this, I have no problem implementing it.
If you're taking feature requests, it would be handy to canonize
Snapshot gcc-4.3-20070420 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070420/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Any developer sense on what it might take to extend the gcc
preprocessor to do these ? I have some experience with gcc front end.
I am especially keen abt multiline macros, so that the lines can be on
separate lines. Any neat trick that can accomplish this by using
#define ?
dz
On 4/20/07, Joe
drizzle drizzle wrote:
Any developer sense on what it might take to extend the gcc
preprocessor to do these ? I have some experience with gcc front end.
I am especially keen abt multiline macros, so that the lines can be on
separate lines. Any neat trick that can accomplish this by using
#define
drizzle drizzle wrote:
Any developer sense on what it might take to extend the gcc
preprocessor to do these ? I have some experience with gcc front end.
I am especially keen abt multiline macros, so that the lines can be on
separate lines. Any neat trick that can accomplish this by using
#define
Hello,
Steve Ellcey wrote:
This seems unfortunate. I was hoping I might be able to turn on loop
unrolling for IA64 at -O2 to improve performance. I have only started
looking into this idea but it seems to help performance quite a bit,
though it is also increasing size quite a bit too so
Zdenek Dvorak wrote:
Hello,
Steve Ellcey wrote:
This seems unfortunate. I was hoping I might be able to turn on loop
unrolling for IA64 at -O2 to improve performance. I have only started
looking into this idea but it seems to help performance quite a bit,
though it is also increasing size
Diego Novillo wrote:
H. J. Lu wrote on 04/20/07 21:30:
-fprefetch-loop-arrays shouldn't be on by default since HW prefetch
usually will have negative performance impact on Intel.
We are talking about one specific architecture where it usually helps: ia64.
Right, but the follow on
H. J. Lu wrote on 04/20/07 21:30:
-fprefetch-loop-arrays shouldn't be on by default since HW prefetch
usually will have negative performance impact on Intel.
We are talking about one specific architecture where it usually helps: ia64.
Robert Dewar wrote on 04/20/07 21:42:
One possibility would be to have a -Om switch (or whatever) that
says do all optimizations for this machine that help.
I think this is a good compromise. I personally don't think we should
limit ourselves to doing the exact same optimizations across all
On Apr 20, 2007, at 6:42 PM, Robert Dewar wrote:
One possibility would be to have a -Om switch (or whatever) that
says do all optimizations for this machine that help.
Ick, gross. No.
I must say the rule about all optimizations being the same on
all machines seems odd to me
I'd look at it
--- 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
97 matches
Mail list logo
