On 09 April 2007 02:51, Bill Wendling wrote:
(on my iMac). The problem seems to be that, in the TConvertType
function passes
type-precision as an HI instead of SI to the bork function. The
asm code is:
movl $1104150528, (%esp)
movl$0, -4(%ebp)
movl
On Apr 8, 2007, at 11:35 PM, Dave Korn wrote:
I believe I got the TOT -- .svn/entries says svn://gcc.gnu.org/svn/
gcc/trunk. Is this a known problem?
It's the first I've heard of it, please file a PR. I'm slightly
amazed this
hasn't been causing bootstrap breakage already, it looks
Florian Weimer writes:
Yeah, but that division is fairly expensive if it can't be performed
at compile time. OTOH, if __compute_size is inlined in all places,
code size does increase somewhat.
Well, I believe the assumption was that __compute_size would be inlined.
If you want to minimize code
2007/4/9, Ross Ridge [EMAIL PROTECTED] wrote:
Florian Weimer writes:
Yeah, but that division is fairly expensive if it can't be performed
at compile time. OTOH, if __compute_size is inlined in all places,
code size does increase somewhat.
Well, I believe the assumption was that __compute_size
allocate_array_april2007.tar.gz
Description: GNU Zip compressed data
2007/4/9, J.C. Pizarro [EMAIL PROTECTED] wrote:
_Z29__allocate_array_of_RossRidgejjj:
[ gcc v3.4.6 : 9 instructions ]
movl4(%esp), %edx
cmpl12(%esp), %edx # comparing and ?? i lose me
movl8(%esp), %eax
orl $-1, %eax
imull %edx,
2007/4/9, Robert Dewar [EMAIL PROTECTED]:
J.C. Pizarro wrote:
The multiply is signed. It is need more researching a little bit.
So what, the low order 32 bits are unaffected. I think this is just
confusion on your part!
Yes, i accidently eliminated the lines containing the point '.' for
Dear all,
I am not sure whether the problem I am going to describe is a problem with
gcc or with the dynamic linker on Mac OS X, but maybe someone here knows a
way to deal with it or could suggest a more appropriate mailing list. I
use gcc 3.3 on Darwin 7.9.0. On this platform the following
#include stddef.h
void *__allocate_array_of_RossRidge(size_t num, size_t size, size_t max_num) {
if (num max_num)
size = ~size_t(0);
else
size *= num;
return operator new[](size);
}
void *__allocate_array_of_JCPizarro(size_t num, size_t size, size_t
max_num) {
if (num
On Monday, 9 April 2007 13:09, J.C. Pizarro wrote:
This code is bigger than Joe Buck's.
Joe Buck's code: 10 instructions
Ross Ridge's code: 16 instructions
Ross Smith's code: 16 instructions
Well, yes, but it also doesn't have the bug Joe's code had. That was
sort of the whole point. If
2007/4/9, Ross Smith [EMAIL PROTECTED] wrote:
On Monday, 9 April 2007 13:09, J.C. Pizarro wrote:
This code is bigger than Joe Buck's.
Joe Buck's code: 10 instructions
Ross Ridge's code: 16 instructions
Ross Smith's code: 16 instructions
Well, yes, but it also doesn't have the bug Joe's
On Tue, Apr 10, 2007 at 03:44:26AM +1200, Ross Smith wrote:
On Monday, 9 April 2007 13:09, J.C. Pizarro wrote:
This code is bigger than Joe Buck's.
Joe Buck's code: 10 instructions
Ross Ridge's code: 16 instructions
Ross Smith's code: 16 instructions
Well, yes, but it also doesn't
On Mon, Apr 09, 2007 at 09:47:07AM -0700, Andrew Pinski wrote:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
#include stddef.h
void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
unsigned long long tmp = (unsigned long long)size * num;
if (tmp =
On Mon, Apr 09, 2007 at 10:51:22AM -0700, Mike Stump wrote:
On Apr 8, 2007, at 8:51 PM, Zuxy Meng wrote:
Intel's optimization reference manual says that:
I wasn't going off the documentation... I'd be more interested in
either benchmarks or in recommendations by Intel people that know the
2007/4/9, Joe Buck [EMAIL PROTECTED]:
On Mon, Apr 09, 2007 at 09:47:07AM -0700, Andrew Pinski wrote:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
#include stddef.h
void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
unsigned long long tmp = (unsigned long long)size
4. Conditional moves (cmov).
Evening all, just a quick question:
[ ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513,
[4.2/4.3 Regression] Miscompilation of Function Passing Bit Field Value to
Function ]
Should promotion of function arguments be explicitly represented in GIMPLE,
or should it be performed when
J.C. Pizarro [EMAIL PROTECTED] writes:
To optimize even more the x86, it still has to use:
1. Use imul instead of mul because it's little bit faster in cycles.
2. Use jns/js (sign's conditional jump) instead of jnc/jc (carry's
conditional jump).
3. To modify the C-preprocessor and/or C/C++
On 4/9/07, Dave Korn [EMAIL PROTECTED] wrote:
Evening all, just a quick question:
[ ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513,
[4.2/4.3 Regression] Miscompilation of Function Passing Bit Field Value to
Function ]
Should promotion of function arguments be explicitly
2007/4/9, Lawrence Crowl [EMAIL PROTECTED]:
On 4/7/07, Joe Buck [EMAIL PROTECTED] wrote:
Consider an implementation that, when given
Foo* array_of_foo = new Foo[n_elements];
passes __compute_size(elements, sizeof Foo) instead of
n_elements*sizeof Foo to operator new, where
2007/4/9, Andrew Pinski [EMAIL PROTECTED]:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
3. To modify the C-preprocessor and/or C/C++ compiler for:
#if argument X is a constant then
use this code specific of constant X
#else if argument Y is not a constant then
Ross == Ross Ridge [EMAIL PROTECTED] writes:
Ross So long as whatever switch is used to enable this check isn't on by
Ross default and its effect on code size and speed is documented, I don't
Ross think it matters that much what those effects are. Anything that works
Ross should make the people
Zuxy Meng wrote:
Mike Stump [EMAIL PROTECTED]
??:[EMAIL PROTECTED]
On Apr 8, 2007, at 2:37 AM, Uros Bizjak wrote:
My docs say that INC/DEC does not change the carry flag.
Personally, I'm having a hard time envisioning how the semantics of the
instruction are relevant at
Ching, Jimen (US SSA) wrote:
According to the manual, I should be getting a warning, but I don't.
Did
I misunderstand the manual?
A conditional expression, as per the ISO C/C++ standards, is an
expression of the form (A ? B : C). There is no conditional expression
in your testcase.
Also,
On Apr 9, 2007, at 12:14 PM, J.C. Pizarro wrote:
How many code's species are they?
One for every problem...
7. Code for IPA??? - i don't know this weird language. Is it with
attributes?.
8. Code for GIMPLE??? - i don't know this weird language.
9. Code for RTL??? - i don't know this weird
JoseD wrote:
@James
What do you mean by 16.3.3/3? GCC's version ?
This is a reference to the ISO C standard.
Still don't see what the problem whith 2 tokens is...
The problem is the fact that they are 2 tokens. You can do a ## b to
create ab, but you can not do a ## ( to create a(
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
Of course, i'm a novice because i like and i don't like the
GCC development's model.
Of course the user manual explains all what I have mentioned in my
previous email so it sounds like you like 95% of the other people who
don't read the manual
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
2007/4/9, Lawrence Crowl [EMAIL PROTECTED]:
On 4/7/07, Joe Buck [EMAIL PROTECTED] wrote:
Consider an implementation that, when given
Foo* array_of_foo = new Foo[n_elements];
passes __compute_size(elements, sizeof Foo) instead
On Mon, Apr 09, 2007 at 01:49:09PM -0700, Lawrence Crowl wrote:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
We've working in linear address spaces.
How for segmented address spaces? You give me examples.
Intel has had several popular processors with segmented addresses
including the
Hi Ian/All
That information was really very helpful. I have been able to localize the bug.
The issue is in the assembler. When I create a object file using the
assembler(as test.s -o test.o), the contents of .rdata which contains the jump
table is all wrong.
The assembly file:-
#include stddef.h // by J.C. Pîzarro
...
// See http://www.cs.sjsu.edu/~kirchher/CS047/multDiv.html
// One-operand imul: Unsigned mul:
// warning: 32 bit, i686, possible risk of -x * -y = valid x * y, ...
// warning: it's made quick dirty, possible to give clobbered situations.
//
On Sat, 7 Apr 2007, Toon Moene wrote:
I do not have easy access to the HTML repository anymore.
That's something we should be able to fix; just drop me (or
[EMAIL PROTECTED]) a note!
Martin Michlmayr asked me to add to the 4.2 changes list the inclusion
of the new compile time option
#include stddef.h // by J.C. Pîzarro
...
// This function doesn't touch the ECX register that is touched by OptionC.
__volatile__ static const int minus_one = -1;
void *__allocate_array_OptionD(size_t num, size_t size) {
register unsigned int result;
__asm__ __volatile__
(
On 09 April 2007 21:49, Lawrence Crowl wrote:
The optimization above would be wrong for such machines because
the allocation would be smaller than the requested size.
To request a size of ~size_t(0) is to request a size
of 0x or 0xULL that the allocator
will always
Paolo Bonzini schrieb:
Dennis Weyland wrote:
Hi!
I've applied for Google's Summer of Code 2007 with GCC as mentor
organization. I want to make GCC working faster on the algorithmic
level. I left out the detailed aims of the project, since i want to
discuss them with gcc developers/mentors
On Mon, Apr 09, 2007 at 11:55:14PM +0100, Dave Korn wrote:
Thanks, I think you're right on there. The comments on PR31136 make it
fairly clear what's wrong; perhaps the best solution might be for
STRIP_SIGN_NOPS to mask out the high bits when it's discarding a size-reducing
NOP_EXPR? Or
On 4/9/07, Diego Novillo [EMAIL PROTECTED] wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementation
The code below has 3 ways of declaring the template member function
ObjInitSelDot(). One of them performs as desired, the other two do not.
Comeau compiles all of them (albeit with a silly warning).
As far as I can tell, all three should compile.
template typename T
struct InitObject
{
This program:
#include stdio.h
struct tree_type {
unsigned int precision : 9;
};
void *bork(const void *Ty, unsigned Subpart) {
printf(Subpart == %08x\n, Subpart);
return 0;
}
const void *TConvertType(tree_type* type) {
asm(movl $1104150528, 4(%%esp) : : );
const void *Ty = 0;
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-09 08:57 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-04-09 10:39 ---
This is clearly my bug, but I am not able to reproduce it on i686-pc-linux-gnu.
Does the following patch fix the problem?
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00188.html
If not, which platform are you
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-09 11:07
---
See PR20278. Do we really want to separate PR for these?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
this small program causes a seg fault in libc.
i don't think this is a libc bug because insignificant changes to the program
cure the problem.
i have run valgrind with the executable, too
in the program below, change the assignment c=s[1] to c=0
and the seg fault disappears
to run the
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-04-09 13:00
---
This is a duplicate of PR 29106 which was present in GCC 4.0.3, 4.1.0, and
4.1.1.
It's fixed in GCC 4.0.4 and 4.1.2, though.
*** This bug has been marked as a duplicate of 29106 ***
--
reichelt at gcc dot
--- Comment #16 from reichelt at gcc dot gnu dot org 2007-04-09 13:00
---
*** Bug 31049 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2007-04-09 13:08 ---
Don't write beyond array bounds.
--
schwab at suse dot de changed:
What|Removed |Added
I know nothing about fortran. This occured while attempting to compile the
espresso DFT package from http://www.pwscf.org/
When compiling, the compiler seg faults and asks for a bug report to be filed
with command:
$ gfortran -c input_parameters.f90
I tried including the file in this comment
--- Comment #1 from haskell dot vivian dot mcphail at gmail dot com
2007-04-09 13:36 ---
Created an attachment (id=13341)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13341action=view)
File that causes crash
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31515
--- Comment #1 from gianni at mariani dot ws 2007-04-09 13:51 ---
I just built gcc-4.3-20070202 x86_64-redhat-linux and confirmed behaviour is
the same as 4.1.1.
--
gianni at mariani dot ws changed:
What|Removed |Added
--- Comment #7 from bangerth at dealii dot org 2007-04-09 14:49 ---
(In reply to comment #6)
This is clearly my bug, but I am not able to reproduce it on
i686-pc-linux-gnu.
This was with r123617, on i686-pc-linux-gnu. I can reproduce with this
version and Andrew's testcase, though
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-04-09 14:52
---
Fixed on mainline by Sandra's patch (revision 122411).
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bangerth at dealii dot org 2007-04-09 14:56 ---
(In reply to comment #6)
Does the following patch fix the problem?
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00188.html
Yes. I think it would be good if you added Andrew's testcase to the patch
as well,
--- Comment #18 from reichelt at gcc dot gnu dot org 2007-04-09 15:08
---
*** Bug 31277 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-04-09 15:08
---
This is a duplicate of PR 27102.
*** This bug has been marked as a duplicate of 27102 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dgregor at gcc dot gnu dot org 2007-04-09 15:09 ---
I can't reproduce this bug with r123671 on i686-pc-linux-gnu. However, since
the above patch does fix the problem, I'll add this PR to the ChangeLog for
that patch.
--
--- Comment #10 from bangerth at dealii dot org 2007-04-09 15:23 ---
Great, thanks. Hopefully someone approves the patch soon.
Talking about canonical types: I think the idea of only issuing a warning
in cases like the current one is a really bad idea. Warnings are meant for
things
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| Talking about canonical types: I think the idea of only issuing a warning
| in cases like the current one is a really bad idea.
Fully agreed. I believe we discussed this on the main list. It
should not be a warning. It should be an ICE.
--- Comment #11 from gdr at cs dot tamu dot edu 2007-04-09 15:33 ---
Subject: Re: [4.3 Regression] Canonical types failures
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| Talking about canonical types: I think the idea of only issuing a warning
| in cases like the current one
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-04-09 15:35
---
Confirmed.
The code fails to compile since GCC 3.3.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-04-09 17:19
---
Andrew, are you going to apply the patch to the 4.1 branch, too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30168
--- Comment #1 from sabre at nondot dot org 2007-04-09 17:38 ---
Among other things, this bug causes GCC 4.2 to miscompile LLVM.
--
sabre at nondot dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2007-04-09 17:51 ---
Yay to making it an ICE instead of a warning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #11 from reichelt at gcc dot gnu dot org 2007-04-09 18:16
---
This is really a non-bug.
The following code snippet illustrates this:
#define VAR1(i,j) i##j
#define VAR2(i,j) VAR1(i,j)
#define VAR(i) VAR2(i,__LINE__)
#line 385
int VAR(i) = 0;
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-04-09 18:32
---
Btw, since GCC 4.1.0 the error message is:
bug.cc:13: error: reference to 'S' is ambiguous
bug.cc:4: error: candidates are: typedef struct S AS::S
bug.cc:7: error: struct S
bug.cc:13: error:
--- Comment #3 from daney at gcc dot gnu dot org 2007-04-09 18:40 ---
Subject: Bug 23758
Author: daney
Date: Mon Apr 9 18:40:20 2007
New Revision: 123676
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123676
Log:
PR libgcj/23758
* java/lang/natPosixProcess.cc
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-04-09 18:45
---
Just a side note: You should remove the template as it is invalid
and only accidentally accepted by GCC, see PR24314.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30836
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-09 18:45 ---
comment #5 in PR19020 mentions several reasons why -ftrapv doesn't really work
right now. I'd be in favor of removing it rather than trying to fix it...
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-09 18:47 ---
Complex operations are lowered at the tree-level so this would require
vectorizing
of straight line code. Second, calling conventions are different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #4 from daney at gcc dot gnu dot org 2007-04-09 18:49 ---
Fixed on the trunk.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-09 19:21 ---
struct tree_type {
unsigned int precision : 9;
};
void bork(unsigned int Subpart);
void foo(struct tree_type *t)
{
bork(t-precision);
}
we miss the zero extension of the argument (comparing cc1 to cc1plus
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-09 19:30 ---
I want to say this is related to PR 27979.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mrs at apple dot com 2007-04-09 20:25 ---
radr://5076058
--
mrs at apple dot com changed:
What|Removed |Added
CC|
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-04-09 20:46
---
Subject: Bug 31449
Author: mmitchel
Date: Mon Apr 9 20:45:53 2007
New Revision: 123679
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123679
Log:
PR c++/31449
* class.c (build_base_path):
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-04-09 20:51
---
Fixed in 4.3.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
stephane duverger wrote:
Father was removed because of goto __end, simply because gcc thought
that this code part will never be reached. But process is cloned() and
it should have taken into account the jnz father
Gcc does not look at the contents of an asm, so it does not know that
there is
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
The following valid code snippet triggers an ICE since at least GCC 2.95.3:
=
templateint struct A
{
templateint struct B
{
templateint void foo()
{
struct C { C() {} };
}
};
};
=
bug.cc: In member function
The following invalid code snippet triggers a segfault since GCC 4.1.2:
=
template typename struct A
{
static const int i=0;
};
template typename T const int AT::i = 0=0;
=
bug.cc:6: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31517
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
The _M_max_length member variable of _Error_formatter is not configurable. It
is currently initialized directly with the value 78, in
libstdc++-v3/include/debug/formatter.h . Having this be configurable (using a
macro, for example) would nicely follow gcc's -fmessage-length=N example.
--
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18553
--- Comment #15 from pcarlini at suse dot de 2007-04-09 22:35 ---
Doesn't really block this one.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2007-04-09 22:43 ---
Fixed in 4.2 branch and trunk.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
For the program
module foo
intger :: i ! intger should be integer
end module foo
program xfoo
use foo, only: i
end program xfoo
gfortran -c -v gfbug.f90
gives
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #7 from pierre42d at 9online dot fr 2007-04-09 23:32 ---
Documentation says :
First, we highly recommend that GCC be built into a separate directory than the
sources which does not reside within the source tree. This is how we generally
build GCC; building where srcdir ==
--- Comment #1 from eweddington at cso dot atmel dot com 2007-04-09 23:33
---
Bernd, what mcu type was this compiled for?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
GCC build triplet|4.1.1 |
GCC host triplet|AVR |
GCC target
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
--- Comment #8 from pierre42d at 9online dot fr 2007-04-10 00:02 ---
Same problem with gcc 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28298
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-04-10 00:06
---
Subject: Bug 27869
Author: hubicka
Date: Tue Apr 10 00:06:16 2007
New Revision: 123682
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123682
Log:
PR target/27869
* config/i386/sse.md
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-04-10 00:19
---
I am not sure this is formatted I/O related. I will investigate further, but I
suspect we are allocating buffer memory to write to memory and we should not
have to do that.
--
jvdelisle at gcc dot gnu dot
--- Comment #1 from bangerth at dealii dot org 2007-04-10 00:30 ---
Confirmed, though this appears to work up to and including the 4.1.2
release at least, in contrast to your assertion...
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-04-10 01:22
---
Well, it crashes for me:
GCC 2.95.3:
PR31516.cc: In method `A{anon}::B{anon}::foo()::C::C()':
PR31516.cc:7: ../../../gcc-2.95.3/gcc/cp/pt.c:2493: Expect 't', have
'function_decl'
GCC 3.0.4:
PR31516.cc: In member
--- Comment #13 from echristo at apple dot com 2007-04-10 01:57 ---
Any hope of getting this in 4.2 as well? It's not a regression, but is a fairly
longstanding bug that's easier to trip than we'd like.
--
echristo at apple dot com changed:
What|Removed
1 - 100 of 111 matches
Mail list logo
