--- Additional Comments From guardia at sympatico dot ca 2005-06-10 03:15
---
Through fstab, yes, but the problem is it only works with specially compiled
binaries. Right off the tar ball, gcc compiles to a native win32 program and
does not honor MSYS's fstab... so no, for a Win32 progra
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-10 03:03 ---
Re:Comment #4
Does mount /usr/include work with MSYS?
Or just create an empty /usr/include
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19607
--- Additional Comments From joseph at codesourcery dot com 2005-06-10
02:00 ---
Subject: Re: GCC should combine adjacent stdio
calls
On Fri, 10 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> Case (b) involves fmemopen, and I assume you refer to a case where you open
> memory for w
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 01:20
---
(In reply to comment #22)
> Subject: Re: GCC should combine adjacent stdio calls
> On Thu, Jun 09, 2005 at 07:52:42PM -, joseph at codesourcery dot com
wrote:
> > (a) It could be stdio's buffer (via setv
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-10
00:41 ---
Hmm, there were no libobjc changes.
There two patches which might have caused it:
-2005-06-09 Jan Hubicka <[EMAIL PROTECTED]>
-
- * cgraphunit.c (cgraph_create_edges): Do not walk BLOCK; finalize
-
With LAST_UPDATED: "Thu Jun 9 21:38:48 UTC 2005" I get:
FAIL: objc/execute/_cmd.m execution, -O0
FAIL: objc/execute/_cmd.m execution, -O1
FAIL: objc/execute/_cmd.m execution, -O2
FAIL: objc/execute/_cmd.m execution, -O3 -fomit-frame-pointer
FAIL: objc/execute/_cmd.m execution, -O3 -g
FAIL: ob
--- Additional Comments From ro at techfak dot uni-bielefeld dot de
2005-06-09 23:09 ---
Subject: Re: [4.0/4.1 Regression] Cannot build gnattools on Tru64 UNIX V5.1B
I've done some further debugging and found what's going on: running the
failing gnatmake invokation
% ../../gnatmake -c
--- Additional Comments From fitzsim at redhat dot com 2005-06-09 22:55
---
Fixed on GNU Classpath mainline.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
22:33 ---
Waiting for a testcase, it could be anything really, a target bug or even a
reload one.
--
What|Removed |Added
--
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
/*
the following case produces suboptimal code:
everything compiled with -O3 only
*/
extern char testcase(int* d)
{
int w23;
w23 = d[2] < d[3];
w23 &= d[3] < d[2];
return w23;
}
/*
4.1.0 20050410 m68k-aout (cygwin host)
testcase:
link.w %fp,#0
m
Hi,
I have observed a wrong code bug that I judge to be so serious that IMHO one
should discourage use of the avr port for 4.x.x until it is resolved.
Unfortunately the bug showed up in a deeply embedded code segment of *really*
confidential code owned by my employer. I unfortunately cannot
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-09
22:22 ---
Subject: Bug 21759
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-09 22:21:48
Modified files:
gcc: ChangeLog c-typeck.c c.opt
g
--
What|Removed |Added
AssignedTo|aldyh at gcc dot gnu dot org|unassigned at gcc dot gnu
||dot org
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
21:55 ---
(In reply to comment #4)
> Pointer subtraction is only defined for pointers to the same array object.
> So this code has undefined behaviour.
Yes that might be true but we can get a testcase where it fails
--- Additional Comments From dave dot offiler at metoffice dot gov dot uk
2005-06-09 21:53 ---
Subject: Out of Office AutoReply: SIZE() matters?
Sorry, I'm away just now. I'll be back in the office on
Monday 13th June 2005
and will read your message then.
If the matter is urgent, p
--- Additional Comments From falk at debian dot org 2005-06-09 21:48
---
Pointer subtraction is only defined for pointers to the same array object.
So this code has undefined behaviour.
--
What|Removed |Added
-
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-09
21:47 ---
(In reply to comment #3)
> Please don't assume that everyone who develops on mingw uses the MSYS build
> environment.
Fine for me. patch keyword removed accordingly.
--
What|Removed
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From guardia at sympatico dot ca 2005-06-09 20:44
---
So where exactly should we specify such a directory? I was not able to find any
other configuration variables that we can change and that would do the job...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-09 20:41 ---
The patch is not right.
mingw doesn't have a NATIVE_SYSTEM_HEADER_DIR.
Header dirs are found relative to the path to the gcc.exe bin directory, so
specifying /mingw/include as the NATIVE_SYSTE
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-09 20:33 ---
Re; comment #4
There should be no need te test for for the sake of mingw
libgcov.c already includes tsystem.h
tsystem.h includes .
On mingw, unistd.h includes
Danny
--
http://gcc.gnu.or
--- Additional Comments From joseph at codesourcery dot com 2005-06-09
20:13 ---
Subject: Re: GCC should combine adjacent stdio
calls
On Thu, 9 Jun 2005, dnovillo at redhat dot com wrote:
> Gah, so we'll need to parse the format string then. Oh, well.
We'll need to parse the format
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 19:57
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 07:52:42PM -, joseph at codesourcery dot com wrote:
> Suppose an implementation defines e.g. clearerr as a macro, and the
> ex
--- Additional Comments From joseph at codesourcery dot com 2005-06-09
19:52 ---
Subject: Re: GCC should combine adjacent stdio
calls
On Thu, 9 Jun 2005, dnovillo at redhat dot com wrote:
> > Although it may not be valid to manipulate the FILE * directly, it seems
> > quite possible
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 19:48
---
(In reply to comment #19)
> Subject: Re: GCC should combine adjacent stdio calls
> On Thu, Jun 09, 2005 at 07:29:42PM -, joseph at codesourcery dot com
wrote:
> > that function on the particular implemen
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-09
19:46 ---
Fixed in 4.1, waiting for 4.0 to reopen.
--
What|Removed |Added
Known to fail|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-09
19:43 ---
Subject: Bug 21480
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-09 19:43:27
Modified files:
libgfortran: ChangeLog
libgfortran/m4 : r
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 19:38
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 07:29:42PM -, joseph at codesourcery dot com wrote:
> Although it may not be valid to manipulate the FILE * directly, it seems
--- Additional Comments From joseph at codesourcery dot com 2005-06-09
19:29 ---
Subject: Re: GCC should combine adjacent stdio
calls
On Thu, 9 Jun 2005, dnovillo at redhat dot com wrote:
> Oh, absolutely. The algorithm I'm using will naturally do this.
> This is a purely local tran
--- Additional Comments From joseph at codesourcery dot com 2005-06-09
19:15 ---
Subject: Re: GCC should combine adjacent stdio
calls
On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> > We linked -Wformat into optimization before, then removed the link.
> > Although we coul
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 19:03
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 05:02:28PM -, ghazi at gcc dot gnu dot org wrote:
> int i=0, j=2;
> printf("%d", i);
> j++;
> printf("%d", j);
>
> Pus
--- Additional Comments From vektor at dumbterm dot net 2005-06-09 18:58
---
As it is not clear above, the PC at the crash is always on this instruction:
660F294C24 movapd [si+24],xmm1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21973
--- Additional Comments From ro at techfak dot uni-bielefeld dot de
2005-06-09 18:54 ---
Subject: Re: New: O32 libffi.so fails to link on IRIX 6
Patch submitted:
http://gcc.gnu.org/ml/java-patches/2005-q2/msg00685.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21943
--- Additional Comments From ro at techfak dot uni-bielefeld dot de
2005-06-09 18:53 ---
Subject: Re: libgfortran doesn't compile on IRIX 5.3
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00902.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-09
18:48 ---
With fresh CVS GCC, I get the following errors on libgcov.c:
../../gcc/gcc/libgcov.c: In function 'create_file_directory':
../../gcc/gcc/libgcov.c:110: warning: implicit declaration of function 'access'
.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
18:25 ---
*** Bug 21989 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
18:25 ---
*** This bug has been marked as a duplicate of 21766 ***
*** This bug has been marked as a duplicate of 21766 ***
--
What|Removed |Added
--
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-09
18:22 ---
Created an attachment (id=9057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9057&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21989
GCC no longer builds on i686-pc-mingw32 (last successful build I made:
20050519). Error is:
$ /home/FX/ibin/./gcc/xgcc -B/home/FX/ibin/./gcc/ -B/mingw/i686-pc-mingw32/bin/
-B/mingw/i686-pc-mingw32/lib/ -isystem /mingw/i686-pc-mingw32/include -isystem
/mingw/i686-pc-mingw32/sys-include -O2 -I../.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
18:15 ---
Confirmed, and yes we need to do something about stdout :).
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-09
18:13 ---
Bug confirmed and patch confirmed (I used to hack the generated Makefiles with
sed, but this is much cleaner).
--
What|Removed |Added
--
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20666
--- Additional Comments From phython at gcc dot gnu dot org 2005-06-09
18:10 ---
If there are any other builtins that can be folded then they can be filed as
separate bugs.
--
What|Removed |Added
--
GCC should optimize printf("%s",foo) and printf("foo") into fputs(foo,stdout)
and fputs("foo",stdout) respectively. As noted here:
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00859.html
We can capture stdout in an inline function using fixincl, perhaps adding the
__always_inline__ attribute.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
17:46 ---
Fixed by:
* config/ia64/ia64.c (update_set_flags): Just return for IF_THEN_ELSE.
Use SCALAR_FLOAT_MODE_P.
* config/ia64/vect.md (vcondv2sf): Remove code check on comparison.
(
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 17:21
---
(In reply to comment #14)
> Subject: Re: GCC should combine adjacent stdio
> calls
> On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> >
> > --- Additional Comments From ghazi at gcc dot gnu dot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
17:15 ---
Weird.
--
What|Removed |Added
Keywords||diagnostic
--- Additional Comments From joseph at codesourcery dot com 2005-06-09
17:11 ---
Subject: Re: GCC should combine adjacent stdio
calls
On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote:
>
> --- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09
> 16:55 --
Between 20050414 and 20050606, there occured a new testsuite failure on the
3.4 branch on alpha-dec-osf4.0f and alpha-dec-osf5.1b:
+FAIL: g++.dg/warn/conversion-function-1.C (test for excess errors)
Excess errors:
/vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/testsuite/g++.dg/warn/conversion-function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
17:08 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
17:07 ---
(In reply to comment #12)
> Pushing the first printf further down, this could be reordered as:
> int i=0, j=2;
> j++;
> printf("%d", i);
> printf("%d", j);
In fact this is how SSA works, in that the
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 17:02
---
(In reply to comment #10)
> Subject: Re: GCC should combine adjacent stdio calls
> But remember that we are not optimizing C, we are optimizing
> GIMPLE. And in GIMPLE we don't have those problems. Here's
--- Additional Comments From aj at gcc dot gnu dot org 2005-06-09 17:01
---
Let me just add the following comment so that searches for "grub miscompilation"
will find this bug:
This snippet is based on code in the grub bootloader which does not work if
compiled by GCC 4.0.0.
--
--- Additional Comments From Pierre dot Asselin at seagate dot com
2005-06-09 16:56 ---
Created an attachment (id=9056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9056&action=view)
self-contained test case, compile with "gfortran bug.f90"
--
http://gcc.gnu.org/bugzilla/show
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 16:55
---
(In reply to comment #3)
> Subject: Re: GCC should combine adjacent stdio
> calls
> Another problem case is if the first format has excess arguments (which is
> permitted by ISO C) - those arguments must be
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 16:55
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 04:49:40PM -, ghazi at gcc dot gnu dot org wrote:
>
> --- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09
version 4.1.0 20050609 (experimental)
(This is this morning's CVS snapshot)
Hmf. I don't see how to attach the "bug.f90" so I will place it in-line below.
It's short. If I split into module and main program and compile separately,
boom.f90 ICE's at line zero. Su
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
16:51 ---
(In reply to comment #8)
> I'm not sure. In my specific example above, after the combination we don't
> know which i++ gets executed first because the order is not guaranteed within
> an argument list of
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 16:49
---
(In reply to comment #4)
> (In reply to comment #1)
> > If side effects appear in the arguments, that also would be a problem, e.g.:
> >
> > printf("%d", i++);
> > printf("%d", i++);
> >
> > should not be tu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
16:45 ---
Part of this has been fixed, there is only one loading of ex1 now on the
mainline.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
16:32 ---
This has now been fixed.
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Target Milestone|4.0.2 |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21985
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
16:26 ---
Confirmed, caused by:
2004-11-10 Zdenek Dvorak <[EMAIL PROTECTED]>
* fold-const.c (fold): Attempt to use ptr_difference_const whenever
one of the arguments of MINUS_EXPR is an address.
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-09
16:18 ---
Testing patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnov
--- Additional Comments From marcus at jet dot franken dot de 2005-06-09
16:14 ---
Created an attachment (id=9055)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9055&action=view)
xx.c
gcc -c -O2 xx.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21985
Hi,
the attached code compiles fine and does calculate the offset between
the current stackpointer and the passed point in gcc versions before 4.0.
In 4.0 the expression is reduced to -16384 even in the t03.generic dump
which makes me suspect a parser problem.
Or it might just be
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21984
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: class friend declaration doesn't allow use in class scope
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-06-09
13:58 ---
Not a bug. The clause you referred to:
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: java.rmi.server.RMIClassLoader.getClassLoader() is private, should be
public
--- Additional Comments From gbenson at redhat dot com 2005-06-09 13:48
---
I need it in Fedora 5. We
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Preprocessing fortran files has some flaws
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:02 ---
Confirmed, it works fine with t.F but not with t.F90.
-
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: [4.0/4.1 Regression] Segmentation fault
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: __m64 return value should be returned in %mm0
Calling convetions for x86 specify that __m64 values should be returned in %mm0
MMX register [1]. Gcc returns __m64 values on stack.
The
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: [4.0/4.1 Regression] Segmentation fault
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: GCC should combine adjacent stdio calls
GCC should optimize adjacent stdio calls. For example:
printf("foo %d %d\n", i, j);
printf("bar %d %d\n", x, y);
could instead be emitted a
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: GCC should combine adjacent stdio calls
GCC should optimize adjacent stdio calls. For example:
printf("foo %d %d\n", i, j);
printf("bar %d %d\n", x, y);
could instead be emitted a
--- Additional Comments From schwab at suse dot de 2005-06-09 16:08 ---
Created an attachment (id=9054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9054&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21984
20050609 (experimental) (m68k-linux)
compiled by GNU C version 4.0.1 20050603 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 80ebf056a47509c89d7f404fc943abab
Breakpoint 1, fancy_abort (file
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
15:16 ---
Confirmed, I think we are picking the wrong __result decl for the outer
function (but I could be wrong, I
have not looked at it much).
--
What|Removed |Added
--
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-09 15:05
---
working on it.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gdr at gcc
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-09
15:03 ---
I concur, but you don't need it in this reduced testcase (my fault for leaving
the statement there). Have a go at this:
FUNCTION dawson_v(x)
IMPLICIT NONE
REAL, DIMENSION(:), INT
--
What|Removed |Added
Known to work||4.1.0
Last reconfirmed|2005-06-07 12:20:36 |2005-06-09 14:45:12
date|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:44 ---
Fixed in 4.1.0.
--
What|Removed |Added
Status|NEW |RESOL
--
Bug 21861 depends on bug 18403, which changed state.
Bug 18403 Summary: FAILs to vectorize testcases on ppc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403
What|Old Value |New Value
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:43 ---
Confirmed, a regression from 3.2.3.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:40 ---
Hmm, it works just fine on powerpc-darwin (I don't know why) but it ICEs on
i686-pc-linux-gnu.
And it worked just fine with "gcc version 3.5.0 20040909 (experimental)"
I don't know if I can consider this
struct base { virtual void foo() = 0; };
struct d1 : public virtual base { virtual void foo() {} };
struct d2 : public virtual base { virtual void foo() {} };
struct der : public d1, public d2 { };
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc:4: error: no unique final overrider for `virtual v
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-09
14:37 ---
(In reply to comment #1)
> If side effects appear in the arguments, that also would be a problem, e.g.:
>
> printf("%d", i++);
> printf("%d", i++);
>
> should not be turned into:
>
> printf("%d%d", i++,
--- Additional Comments From joseph at codesourcery dot com 2005-06-09
14:36 ---
Subject: Re: GCC should combine adjacent stdio
calls
Another problem case is if the first format has excess arguments (which is
permitted by ISO C) - those arguments must be evaluated but not included
i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:27 ---
Obvious reduced testcase is the following:
struct A;
template void
f (void) {A b;}
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:24 ---
Of course we cannot compile this without the nrutil module.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:16 ---
Confirmed, ICC returns it in %mm0.
Note this is the testcase which I used:
#include
__m64
aaa (__m64 x, __m64 y)
{
__m64 mm1;
mm1 = _mm_add_pi8 (x, y);
return mm1;
}
int main() {
__m64 mm0;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:07 ---
Confirmed, this might be hard, I don't know but would be nice as it should
speed up GCC itself.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
12:29 ---
3.4.x is correct. Since this is not a regression (well it does not matter as
3.3.6 was the last 3.3.x
release) I am closing as fixed in 3.4.0.
--
What|Removed |Added
--
Take this c++ code:
snip
class Test
{
private:
int val;
static Test func1 ();
static Test func2 ();
static Test (* funcp) ();
public:
Test (int val)
: val (val)
{
}
Test func ()
{
return funcp ();
}
int get () const
{
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From pluto at agmk dot net 2005-06-09 11:59 ---
hmm, I can't test the 4.1 bootstrap with -fwrapv due to xgcc error.
make -C obj-amd64-pld-linux \
bootstrap \
GCJFLAGS="%{rpmcflags}" \
BOOT_ADAFLAGS="%{rpmcflags} -fwrapv" \
GNATLIBCF
--- Additional Comments From giovannibajo at libero dot it 2005-06-09
11:52 ---
Ah sorry, for some reason I misread the bug and believed it worked in 3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-09
11:25 ---
Why would you want to binsearch this? GCC 3.0.4 was already broken,
according to the "Known to fail" list, while 2.95.3 is "Known to work".
And because the sibcall pass was new in GCC 3.0, the odds are that
1 - 100 of 133 matches
Mail list logo
