--- Comment #15 from bonzini at gnu dot org 2007-05-28 06:38 ---
Subject: Bug 32078
Author: bonzini
Date: Mon May 28 06:38:00 2007
New Revision: 125125
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125125
Log:
2007-05-27 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-05-28 07:06
---
The missed load PRE for the testcase below is fixed on the pointer plus banch
as the addition is done in unsigned int for both the ++k and the
array[k+1]. If we change ++k into k+=2 and array[k+1] into
A testcase which we should optimize all the way to return true:
int f(int a, int b)
{
int c = a+2;
int d = c*2;
int e = a*2;
int f = e+4;
return d == f;
}
--
Summary: missed PRE/FRE of a*2+4 and (a+2)*2
Product: gcc
Version: 4.3.0
Status:
According to our documentation, __label__ declarations have to come first but
the C++ accepts code where they don't which can be shown to be a bit weird with
two labels with the same name.
Here is a testcase which shows that the C++ front-end can accept a case where
we have two labels with the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.0.1 4.1.0 4.2.0 4.3.0
Known to work|
GCC accepts this:
void foo() { goto *1; }
The Labels as Values section of the doc states that indirect gotos take Any
expression of type void *. 1 is not of type void*.
it looks like gcc accepts anything convertible to a pointer type. Trying to
jump to a structure yields:
t.c:15: error:
--- Comment #1 from sabre at nondot dot org 2007-05-28 07:36 ---
isn't this also likely a 3.4 regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
This testcase fails for:
gcc -O2 -msse2 -mtune=k8 sse2-vec-6.c
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
type-escape-varAssembling functions:
i386_cpuid_ecx i386_cpuid_edx i386_extended_cpuid_ecx
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 07:54 ---
(In reply to comment #1)
isn't this also likely a 3.4 regression?
Yes but I don't have 3.4 to test with right now. Also the summary only
includes information about the currently maintained branches. The known to
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 07:58 ---
I think the problem now is related to data-ref and I think this might get fixed
after I fix PR 32075.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-05-28 08:35 ---
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
void sse2_test (void)
{
--- Comment #16 from rob1weld at aol dot com 2007-05-28 08:35 ---
Comment #11 From [EMAIL PROTECTED] 2007-05-27 07:24
Getting stuck at ?:
libtool: compile: mv -f process-Posix.o java/.libs/process-Posix.o
...
This isn't a fix.
Actually I tought if you had got that far that I had
The attached program never reaches the error message printout, contrary to the
fact that stat= is specified in the allocate statement (if the runtime aborts,
what's the point of stat= ?)
[EMAIL PROTECTED] bugtest]$ gfortran -o tryalloc tryalloc.f90
[EMAIL PROTECTED] bugtest]$ ./tryalloc
Fortran
--- Comment #1 from sfilippone at uniroma2 dot it 2007-05-28 09:35 ---
Created an attachment (id=13620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13620action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-28 10:27 ---
Confirmed. Maybe fixed by sccvn.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-28 10:29 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
--- Comment #161 from rguenther at suse dot de 2007-05-28 11:14 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
Btw, it could save us many bugs (or bug reports) if if PTA says must-alias
we'd trust it, instead of using TBAA to
--- Comment #162 from dberlin at gcc dot gnu dot org 2007-05-28 11:24
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 28 May 2007 11:14:20 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #161
--- Comment #107 from simon dot strandman at telia dot com 2007-05-28
11:49 ---
(In reply to comment #106)
I haven't tried the fix in 20218. surprisingly, moving to binutils
2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is
going on? how did the latest
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-28 12:07 ---
I had to change huge(1_4) to huge(1_8) as the former was not enough to trigger
an allocation error on my system.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-28 12:23 ---
Created an attachment (id=13621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13621action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-28 12:28 ---
Confirmed. Another mangling problem:
Program received signal SIGSEGV, Segmentation fault.
0x0827e9b8 in write_expression (expr=0xb7cdd870)
at /home/richard/src/trunk2/gcc/cp/mangle.c:2175
warning: Source file
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-28 12:54 ---
Worse, with __builtin_sin(M_PI), I get an error:
test.c:2: error: initializer element is not constant
Maybe this is fixed now in GCC 4.3 by using MPFR.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #3 from patchapp at dberlin dot org 2007-05-28 13:15 ---
Subject: Bug number PR32124
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-05/msg01870.html
--
--- Comment #3 from eedelman at gcc dot gnu dot org 2007-05-28 15:41
---
(In reply to comment #2)
Created an attachment (id=13618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618action=view) [edit]
decl.c patch (not check-gfortran tested)
Erik, are you still working on
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:17
---
Removing the wrong-code keyword until we manage to find if it actually happens
on 4.2, or if it's just not exposed. I'm reluctant to backport the patch unless
we have a proof of it happening on 4.2 (and if it
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:38
---
Patch was approved...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-28 16:39 ---
Subject: Bug 32124
Author: burnus
Date: Mon May 28 16:39:35 2007
New Revision: 125133
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125133
Log:
2007-05-28 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-28 16:41 ---
Fixed in GCC 4.3.0, won't backport to 4.2.0 (no regression)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from bkoz at gcc dot gnu dot org 2007-05-28 16:56 ---
Created an attachment (id=13622)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13622action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
The following invalid code snippet triggers an ICE on mainline:
templatetypename... struct A;
templatetypename...T struct AT*
{
A();
A(T);
};
bug.cc:3: error: parameter packs
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-05-28 16:53
---
A similar testcase crashes in a different place:
templatetypename... struct A;
templatetypename...T struct AT*
{
A() {}
};
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-05-28 16:57 ---
This should do it. I'll put it on 4.2.x branch after some testing on mainline.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-05-28 16:58 ---
This path:
$GCC_SRC_ROOT\mingw_build\mingw32\libstdc++-v3\include\ext\pb_ds\detail
Looks wrong. Are you building in the source directory?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32092
The following invalid code snippet triggers an ICE on mainline:
templatetypename... struct A;
templatetypename...T struct AT
{
static int i;
};
Achar a;
Aint b;
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-05-28 17:02 ---
Subject: Bug 31717
Author: bkoz
Date: Mon May 28 17:02:30 2007
New Revision: 125134
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125134
Log:
2007-05-28 Benjamin Kosnik [EMAIL PROTECTED]
PR
The following invalid code snippet triggers an ICE on mainline:
templatetypename...T struct A
{
static T i;
};
int j = Aint::i;
bug.cc:3: error: parameter packs not expanded with
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32127
The following invalid code snippet triggers an ICE on mainline:
templatetypename... struct A;
templatetypename...T, typename...U struct AT..., U... {};
Aint a;
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32128
This is kind of a split up of PR31564, which is unrelated.
The program is invalid as we pass an array as actual argument to the scalar
dummy argument; somehow gfortran does not detect this.
Interestingly, compare_actual_formal is never called if the actual argument is
an array section with
Starting with the patch
URL:http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html, committed as
revision 12, linking fails. From libffi/configure.log:
configure:2261: checking for C compiler default output file name
configure:2264: /home/rask/build/gcc-ppc/./gcc/xgcc
--- Comment #163 from ian at airs dot com 2007-05-28 17:30 ---
Richi, I tested my patch on every test case I saved. Can you just point me at
the one I missed? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-28 17:42 ---
I know what the trouble is:
Since the variable 'a' is not used, the equivalence is scrubbed and the
compiler goes off to look for a module variable, rather than a member of an
external union.
I have tried one or two
--- Comment #6 from sabre at nondot dot org 2007-05-28 17:44 ---
This is very useful for compilers generating C code (e.g. LLVM, and various
other source - C compilers). Why remove it? These compilers are generating
partially structured code, that don't have syntactic blocks required
--- Comment #108 from funtoos at yahoo dot com 2007-05-28 17:47 ---
but comments in bug 20218 say that its fixed in mainline, which means there was
a fix put into gcc for hidden visibility. So, are both the fix from prerelease
binutils and gcc mainline needed to fix this completely?
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-28 18:13 ---
Some debugging shows:
resolve_call calls resolve_actual_arglist, which fails.
resolve_call propagates the failure to resolve_where, which does not check for
errors.
In resolve_actual_arglist it fails here:
--- Comment #4 from eedelman at gcc dot gnu dot org 2007-05-28 18:51
---
(In reply to comment #3)
(In reply to comment #2)
Created an attachment (id=13618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618action=view) [edit]
decl.c patch (not check-gfortran tested)
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:08 ---
(In reply to comment #6)
This is very useful for compilers generating C code (e.g. LLVM, and various
other source - C compilers). Why remove it? These compilers are generating
partially structured code, that
Hopefully this is everything you need: output from the gfortran
command, the source file, and the .mod and .s files that were
generated. GFORTRAN was installed from binary using fink a day or so
ago. Since this was my first use of fink, I'm not sure why it got the
experimental version.
$
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-28 19:43 ---
Subject: Bug 32100
Author: pinskia
Date: Mon May 28 19:43:10 2007
New Revision: 125139
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125139
Log:
2007-05-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 ---
Subject: Bug 32100
Author: pinskia
Date: Mon May 28 19:47:53 2007
New Revision: 125140
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125140
Log:
2007-05-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-28 19:52 ---
A partial fix can be found at
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01873.html
Some discussions can be found by following the thread.
--
dominiq at lps dot ens dot fr changed:
What
--- Comment #3 from fang at csl dot cornell dot edu 2007-05-28 19:53
---
Yup, also fails with 3.4.0 (accepts-invalid).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
Look at this:
$ cat allocate-loop.f90
program main
implicit none
real, allocatable, dimension(:) :: a, b, c
real, dimension(10) :: d, e, f
real :: s
allocate (a(10), b(10), c(10))
call random_number(a)
call random_number(b)
c = a+b
s = sum(c)
print *,s
call random_number(d)
attached testcase produces unexpected warning at -O3:
$ g++ -Wall -Woverloaded-virtual -Werror -O3 -gdwarf-2 -g1 -fPIE \
-Wno-error -c auHexCastTest.ii
../../au/h/auHexCast.hpp: In function #8216;R au::hex_cast(const
stlp_std::string) [with R = int]#8217;:
../../au/h/auHexCast.hpp:50:
--- Comment #1 from pluto at agmk dot net 2007-05-28 20:08 ---
Created an attachment (id=13623)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13623action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 20:13 ---
This might not be a bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #3 from pluto at agmk dot net 2007-05-28 20:16 ---
(In reply to comment #2)
This might not be a bug
so, how 'r' can be used uninitialized in this case?
template typename R
R hex_cast ( const std::string s )
{
if ( s.empty ()
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 20:26 ---
so, how 'r' can be used uninitialized in this case?
Because istringstream r could have caused an error. so you need to check if
there is an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:48
---
The following two codes are handled differently:
$ cat u.f90
call foo()
contains
subroutine foo(x)
integer, dimension(:), optional :: x
interface
subroutine bar(x)
integer,
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-28 20:53 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:53:09 2007
New Revision: 125141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125141
Log:
PR 31972/fortran
* target-memory.c (gfc_target_expr_size): Add
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:54
---
Created an attachment (id=13624)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13624action=view)
Patch for this issue
This patch builds on top of Lee Millward's patch to trans-intrinsic:
--- Comment #8 from brooks at gcc dot gnu dot org 2007-05-28 20:54 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:54:49 2007
New Revision: 125142
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125142
Log:
PR fortran/31972
* transfer_hollerith_1.f90: New test.
Added:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 20:56 ---
This is an aliasing issue. The reason why we don't optimize this is because we
think a/b and escape except in Fortran that is not the case.
I think there is another bug about this case somewhere too.
--
--- Comment #9 from brooks at gcc dot gnu dot org 2007-05-28 20:57 ---
Fixed, as per above commits.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from brooks at gcc dot gnu dot org 2007-05-28 21:09 ---
Paul, I don't think that's solving the right problem. The code is legal; the
inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which
conforms with a CHARACTER scalar of len=20.
In reducing this,
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-28 21:07
---
I am no longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-05-28 21:21
---
No longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-28 21:22
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 21:24 ---
(In reply to comment #0)
Just a bug report to remind me to add support for @synchronized for 4.2.
4.3 ... (maybe once I finish pointer plus I can get back to fixing libobjc
issues).
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-28 21:48 ---
The warning is correct you need to check if str had an error after reading the
integer. This is not a GCC bug.
The IR looks like:
bb 7:
__comp_ctor (str, s, 8);
this.104 = (struct ios_base *) str.D.25711;
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-28 21:53 ---
I am no longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-28 22:07 ---
Subject: Bug 32124
Author: burnus
Date: Mon May 28 22:07:23 2007
New Revision: 125148
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125148
Log:
2007-05-28 Tobias Burnus [EMAIL PROTECTED]
PR
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
I noticed a change in the implementation of the post-increment (i++) operator
in gcc 4.0.1 (Apple build 5367).
The behaviour can be seen with the following code:
---
i += i++;
---
In older versions ( 4) of g++ the 'original' variable is returned by ++,
meaning that the statement given has the
--- Comment #1 from mckelvey at maskull dot com 2007-05-28 22:45 ---
I refetched from svn and rebuilt and it works OK now.
--
mckelvey at maskull dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 22:47 ---
You obviously did not read the bugs.html page which lists this as a nonbug:
http://gcc.gnu.org/bugs.html#nonbugs_c
Increment/decrement operator (++/--) not working as expected - a problem with
many variations.
--- Comment #76 from pinskia at gcc dot gnu dot org 2007-05-28 22:47
---
*** Bug 32133 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
,rtlflag,runtime,tree
Thread model: single
gcc version 4.3.0 20070528 (experimental)
Using minimal configure parameters _or_ trying --disable-initfini-array
--disable-__cxa_atexit was to no avail. I did search gcc-patches and bugzilla.
The intl/configure script for 4.3.0 is the same as for 4.2.0/1
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 23:57 ---
*** This bug has been marked as a duplicate of 31039 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-28 23:57 ---
*** Bug 32134 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|Latest CVS-stage 2-Cannot |[4.3
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-29 00:00 ---
This was a newlib bug which was fixed already so closing as such.
You need to update your cygwin libc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
-O2 Warray-bounds:
=== Cut ===
struct PhaseEntryType
{
char raw_field[50 + 1];
};
int
ParsePhase (char in_cols[15][250], struct PhaseEntryType *P)
{
__builtin_strncpy (P-raw_field, in_cols[2], 50);
}
~
=== Cut ===
triggered by
__builtin_strncpy ((char *) P-raw_field, (const char *)
--- Comment #2 from rob1weld at aol dot com 2007-05-29 00:06 ---
Wow Andrew, you were sure on top of that fast...
I _did_ search for various words to attempt to find a similar complaint before
posting. I found none.
I agree that this bug report is a dupe of 31039 .
Do you have some
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 00:08 ---
(In reply to comment #2)
Do you have some sort of dupe check script running or is it just your magic
powers?
I just searched for __sgetc_r. Nothing special for finding the dup.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-29 00:10 ---
The bug is in maybe_fold_offset_to_array_ref.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 00:25 ---
Subject: Bug 31339
Author: pinskia
Date: Tue May 29 00:25:25 2007
New Revision: 125156
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125156
Log:
2007-05-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-29 00:25 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from rob1weld at aol dot com 2007-05-29 00:28 ---
# cat /root/downloads/gcc-4_3-trunk/LAST_UPDATED
Mon May 28 08:39:31 UTC 2007 (revision 125125M)
Results for 4.3.0 20070528 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc
--- Comment #4 from rob1weld at aol dot com 2007-05-29 03:52 ---
I got the reply Zarro Boogs found. when I searched for:
ungetc
--- Comment #8 from rob1weld at aol dot com 2007-05-29 03:57 ---
For target i686-pc-linux-gnu it breaks at:
/root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:557: internal compiler
error: in
--- Comment #8 from rob1weld at aol dot com 2007-05-29 04:15 ---
I did just run Cygwin's setup.exe and tried a few sites - even kernel.org .
You can't get an update that way. It will either be by SVN/CVS or apply the
patches listed in the links above to your /cygwin directory.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 04:22 ---
(In reply to comment #4)
I got the reply Zarro Boogs found. when I searched for:
You are searching the summary, try the comment section instead.
You get three bugs:
PR 32134
PR 32024
PR 31039
The middle one if
1 - 100 of 106 matches
Mail list logo
