--- Comment #7 from abidmuslim at gmail dot com 2009-06-26 06:20 ---
Subject: Re: problem with libgfortran
ThanksIts work.
I read the installation part but ignore the build part.
Thanks again
On Fri, Jun 26, 2009 at 11:48 AM, kargl at gcc dot gnu dot
org wrote:
>
>
> --- Com
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-06-26 06:19
---
Confirmed.
The bug apeeared between 2009-03-28 and 2009-04-24.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-26 06:12 ---
Adding IPA-CP to CC...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40557
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-26 06:06 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
The following valid code snippet triggers an ICE on the trunk:
==
struct A
{
typedef int X;
};
template union B
{
A::X x;
};
==
bug.cc:8:6: internal compiler error: in
append_type_to_template_for_access_check_1, at cp/pt.c:17353
Please
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-26 06:06 ---
Subject: Bug 40525
Author: steven
Date: Fri Jun 26 06:06:04 2009
New Revision: 148961
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148961
Log:
PR middle-end/40525
* ifcvt.c (dead_or_predicab
--- Comment #2 from tydeman at tybor dot com 2009-06-26 05:57 ---
Created an attachment (id=18073)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18073&action=view)
Find precision of *, /, +, -, ==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
The following valid code snippet triggers an ICE when compiled with "-O2":
===
struct A {};
struct A foo()
{
return foo();
}
void bar()
{
foo();
}
===
bug.c:11:1: internal compiler error: in ipcp_analyze_node, at ipa-cp.c:183
Please submit a full bug report,
--- Comment #6 from kargl at gcc dot gnu dot org 2009-06-26 03:48 ---
(In reply to comment #5)
> Subject: Re: problem with libgfortran
>
> Hello:
>
> I checked 35619 . However, I could not understand what is the solution
> to the error. I apologize for this.
>
Do not try to build gc
This is a special case because all the logic has to be done in md5.c
as preprocessor macros. You'd need someone familiar with the platform
(Chris, Danny, Kai) to specify a reliable way to detect that platform
and/or define the types accordingly. If it can typedef md5_uintptr
directly, or use the
--- Comment #5 from abidmuslim at gmail dot com 2009-06-26 03:10 ---
Subject: Re: problem with libgfortran
Hello:
I checked 35619 . However, I could not understand what is the solution
to the error. I apologize for this.
Thanks
On Fri, Jun 26, 2009 at 11:03 AM, pinskia at gcc dot gn
--- Comment #28 from pinskia at gcc dot gnu dot org 2009-06-26 03:03
---
*** Bug 40555 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-26 03:03 ---
*** This bug has been marked as a duplicate of 35619 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from abidmuslim at gmail dot com 2009-06-26 03:00 ---
Subject: Re: problem with libgfortran
On Fri, Jun 26, 2009 at 10:58 AM, Abid Muslim Malik
wrote:
>
> I read the online install GCC document and other tips on line for installing
> GCC.
>
> I use the following to co
--- Comment #2 from kargl at gcc dot gnu dot org 2009-06-26 02:27 ---
Are you trying to build gcc in its source directory?
Have you read http://gcc.gnu.org/install/?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
--- Comment #1 from abidmuslim at gmail dot com 2009-06-26 02:09 ---
Created an attachment (id=18072)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18072&action=view)
detail of error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
I am trying to compile GCC4.4.0 and and getting the following error.( I am
writing part of the errors)
./libs/backtrace.o:/usr/include/stdlib.h:384: first defined here
./lib/in_unpack_generic.o: In function `strtod':
./lib/include/stdlib.h:330:multiple definition of `atof'
./libs/backtrace.o:/usr/
On Linux/x86-64, revision 148941
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00925.html
miscompiled 447.dealII in SPEC CPU 2006 with -O2 -ffast-math.
--
Summary: [4.5 Regression] Revision 148941 miscompiled 447.dealII
in SPEC CPU 2006
Product: gcc
--- Comment #3 from danglin at gcc dot gnu dot org 2009-06-26 01:01 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from danglin at gcc dot gnu dot org 2009-06-26 00:41 ---
Subject: Bug 40468
Author: danglin
Date: Fri Jun 26 00:40:55 2009
New Revision: 148959
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148959
Log:
PR target/40468
* pa.c (branch_to_delay_slot_
--- Comment #5 from manu at gcc dot gnu dot org 2009-06-25 20:52 ---
GCC 4.5 produces nothing with -Wall -O2. With -Wstrict-aliasing=1 it says:
pr40517.c:4514:8: warning: dereferencing type-punned pointer might break
strict-aliasing rules
pr40517.c:4536:6: warning: dereferencing type-pu
--- Comment #2 from xenofears at gmail dot com 2009-06-25 20:44 ---
(In reply to comment #1)
> I imagine this applies to any target, not just win64 targets. I can't change
> that setting, though.
I am quite sure it applies to any target, but I am unable to test any target.
Feel free to
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-25 20:24 ---
Patch posted.
Many thanks to Google for doing all this code analysis.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-06-25 20:10
---
Looking at a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-25 19:51 ---
Works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WA
--- Comment #7 from pinskia at gmail dot com 2009-06-25 19:33 ---
Subject: Re: nop insertion does not look see restrict pointers
Sent from my iPhone
On Jun 25, 2009, at 12:30 PM, "rguenth at gcc dot gnu dot org"
wrote:
>
>
> --- Comment #6 from rguenth at gcc dot gnu dot org
Sent from my iPhone
On Jun 25, 2009, at 12:30 PM, "rguenth at gcc dot gnu dot org" > wrote:
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25
19:30 ---
which makes this bug ... ???
dependent on a bug you're going to file?
Most likely closing as won't fix as this
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-25 19:32 ---
D.1412 = BIT_FIELD_REF ;
is certainly not the size of v2sf...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 19:30 ---
which makes this bug ... ???
dependent on a bug you're going to file?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-25 19:01 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-25 19:00 ---
Subject: Bug 38731
Author: pinskia
Date: Thu Jun 25 19:00:26 2009
New Revision: 148948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148948
Log:
2009-06-25 Andrew Pinski
PR target/38731
--- Comment #4 from CaptainSifff at gmx dot de 2009-06-25 18:55 ---
As an additional note:
if compiled with -m3dnow the program produces nans
if compiled with -msse the program produces a segfault which seems to be due to
the same alignment issue as in bug
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from CaptainSifff at gmx dot de 2009-06-25 18:51 ---
Created an attachment (id=18071)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18071&action=view)
the generated assembly source by gcc-4.3.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
--- Comment #2 from CaptainSifff at gmx dot de 2009-06-25 18:51 ---
Created an attachment (id=18070)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18070&action=view)
the intermediate source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
--- Comment #1 from CaptainSifff at gmx dot de 2009-06-25 18:50 ---
Created an attachment (id=18069)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18069&action=view)
failing program using vector extensions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
I'm using the code from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
and added output of the result vector:
#include
typedef float v2sf __attribute__ ((vector_size (2 * sizeof(float;
int main()
{
v2sf a = {1.0, 0.0};
v2sf b = {0.0, 1.0};
v2sf d;
d = a + b;
float* dp = (float*)
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-25 17:57 ---
Well the nop insertion is not working any more ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 17:49 ---
Middle end.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Component|target
--- Comment #5 from ubizjak at gmail dot com 2009-06-25 17:32 ---
The problem is also present on 4.5.0. The executable won't segfault, because
-O0 generates more temporaries on stack. However:
xorps %xmm1, %xmm1
movlps 56(%esp), %xmm1
(*) movhps 64(%esp), %xmm1
--- Comment #4 from ubizjak at gmail dot com 2009-06-25 17:09 ---
4.4 fixed movaps isse by calling ix86_expand_vector_move to generate unaligned
move.
The core of the problem is however in the middle end, where we expnd from:
main ()
{
vector float D.1414;
vector float D.1413;
ve
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-25 16:04 ---
I think I would go for option (b) of creating a new array descriptor, which is
then used for copy out. The place where currently the creation of a temporary
is prevented is:
gfc_trans_arrayfunc_assign
If the return
> cat bug.cc
#include
void f() {
throw 1;
}
struct Foo {
Foo(const std::string& s);
std::string s;
};
Foo::Foo(const std::string& s_)
: s(s_)
{
f();
}
int main() {
try {
Foo foo("");
} catch (...) {
}
}
> g++ -O2
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-25 15:43 ---
(In reply to comment #3)
> Another example.
Which is invalid. Mea culpa:
"A procedure ... shall have an explicit interface if ... (3) The procedure has
a result that (a) is an array"
(That is something, -fwhole-file
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-06-25
15:37 ---
Hmm, I'm getting somewhere with this.
By compiling the g++ testsuite "ptrflags.C" case with --save-temps, manually
hacking all the superfluous typeinfo stuff out, and re-assembling and linking
it, I
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2009-06-25
15:31 ---
(In reply to comment #7)
> With the new restrict implementation baz() works and all the rest would work
> as well if the calls to link_error () would not cause the malloced memory
> to be clobbered. The a
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-25 15:06 ---
Another example. The following two subroutines are essentially identical,
except that one has an explicit interface and one an implicit interface. The
only extra information the explicit interface provides is that the
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-25 14:21 ---
> The following program should produce 1 2 -42 -42
> but it produces 1 -42 2 -42
You probably mean the opposite! If so, I confirm the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-25 14:21
---
I have checked out trunk 148941, compiled binutils with it (configured
with --disable-werror), ran the testsuite and there were no failures.
Thus I consider this fixed.
--
jamborm at gcc dot gnu dot org changed
--- Comment #7 from hjl dot tools at gmail dot com 2009-06-25 14:12 ---
It is easier to support C++ with option 3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
--- Comment #1 from nightstrike at gmail dot com 2009-06-25 13:58 ---
I imagine this applies to any target, not just win64 targets. I can't change
that setting, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40516
On Tue, Jun 23, 2009 at 3:39 AM, Nick Clifton wrote:
> Hi,
>
>> NightStrike wrote:
>>
>> When building a binutils where host=target=x86_64-w64-mingw32, I see
>> the following warnings that should be cleaned up:
>>
>> ../../src/libiberty/md5.c: In function ‘md5_process_bytes’:
>> ../../src/libiberty
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-25 13:32 ---
Fails with 4.3.x to 4.5.0
(In 4.1.x/4.2.x it also fails, but there no return value is set at all, i.e.
one gets "warning: Function does not return a value" - and four times "-42".)
--
burnus at gcc dot gnu dot org
Bug reported (with longer test case) by Maciej Zwierzycki
at http://gcc.gnu.org/ml/fortran/2009-06/msg00254.html
The following program should produce 1 2 -42 -42
but it produces 1 -42 2 -42
For
a(1,:) = func()
gfortran decides to pass result value by reference - an
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-06-25 12:40
---
Subject: Bug 38396
Author: rguenth
Date: Thu Jun 25 12:40:30 2009
New Revision: 148944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148944
Log:
2009-06-25 Richard Guenther
Backport from mainl
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-25 12:40
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 12:39 ---
Subject: Bug 38751
Author: rguenth
Date: Thu Jun 25 12:39:01 2009
New Revision: 148943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148943
Log:
2009-06-25 Richard Guenther
Backport from mainlin
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-25 12:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-25 12:36 ---
Confirmed. With 4.4 the issue seems to be different as we use mov{l,h}ps but
access beyond the stack clobbering the return location. Oops. Doesn't
segfault with -fstack-protector.
--
rguenth at gcc dot gnu dot
--- Comment #2 from tux008 at googlemail dot com 2009-06-25 12:28 ---
Created an attachment (id=18068)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18068&action=view)
corresponding ii-file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
--- Comment #1 from tux008 at googlemail dot com 2009-06-25 12:27 ---
Created an attachment (id=18067)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18067&action=view)
This program segfaults if compiled with gcc-4.4.0 and -msse on i686
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #11 from rguenther at suse dot de 2009-06-25 12:25 ---
Subject: Re: [4.3 Regression] offsetof buglet
On Thu, 25 Jun 2009, mikpe at it dot uu dot se wrote:
> --- Comment #10 from mikpe at it dot uu dot se 2009-06-25 12:12 ---
> (In reply to comment #9)
> > Fixed.
>
The following code is misscompiled on 32 bit machines using gcc-4.4.0,
gcc-4.3.3 and gcc-4.3.2 with the -msse switch
===
typedef float v2sf __attribute__ ((vector_size (2 * sizeof(float;
int main()
{
v2sf a = {1.0, 0.0};
v2sf b = {0.0, 1.0};
v2sf d;
d = a + b;
return 0;
}
=
--- Comment #10 from mikpe at it dot uu dot se 2009-06-25 12:12 ---
(In reply to comment #9)
> Fixed.
The gcc-4.3 backport or PR32041 to c-parser.c adds an assignment to `loc'. The
mainline version needed that for build_array_ref, but in 4.3 build_array_ref
does not take a loc parameter
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-25 11:19 ---
double* __restrict__ va;
const double* __restrict__ vb;
for(unsigned i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=38012
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-25 11:15 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-25 11:14 ---
I don't have nops on either of the two functions with trunk. And
-minsert-sched-nops doesn't exist there either.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-25 11:10 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #14 from jamborm at gcc dot gnu dot org 2009-06-25 10:38
---
Subject: Bug 40493
Author: jamborm
Date: Thu Jun 25 10:38:13 2009
New Revision: 148941
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148941
Log:
2009-06-25 Martin Jambor
PR tree-optimization/4
--- Comment #4 from ivmai at mail dot ru 2009-06-25 10:31 ---
Bug confirmed in mingw-w64 gcc v4.5.0 (32-bit target).
Bug also observed in MinGW gcc v3.4.5 and v4.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-25 10:28 ---
With the new restrict implementation baz() works and all the rest would work
as well if the calls to link_error () would not cause the malloced memory
to be clobbered. The artifact here is that malloced memory is co
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-25 09:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-25 09:45
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-25 09:44 ---
Subject: Bug 32041
Author: rguenth
Date: Thu Jun 25 09:44:12 2009
New Revision: 148939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148939
Log:
2009-06-25 Richard Guenther
Backport from mainlin
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-06-25 09:44
---
Subject: Bug 36891
Author: rguenth
Date: Thu Jun 25 09:44:12 2009
New Revision: 148939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148939
Log:
2009-06-25 Richard Guenther
Backport from mainl
--- Comment #141 from ubizjak at gmail dot com 2009-06-25 09:03 ---
*** Bug 40537 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #9 from ubizjak at gmail dot com 2009-06-25 09:03 ---
*** This bug has been marked as a duplicate of 21920 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-06-25 09:01
---
Executing predictive commoning without unrolling.
with -m32. One of the cases SCEV is confused about pointer-plus offsets
being sizetype:
(Data Ref:
stmt: (*x_58(D))[D.1627_54] = D.1638_71;
ref: (*x_58(D))[D
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 08:58 ---
Oops...
--
ubizjak at gmail dot com changed:
What|Removed |Added
Keywords|
MinGW (http://www.mingw.org/) now has an official 4.4.0 release - and thus
finally a 4.x release. If one looks at the release,
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304
one finds a tar ball (gcc-4.4.0-mingw32-src-2.tar.gz) with patches.
For Fortran, I found the f
--- Comment #15 from ubizjak at gmail dot com 2009-06-25 08:31 ---
(In reply to comment #14)
> (In reply to comment #13)
> > Predictive commoning does exactly what you want.
Predictive commoning failed: no suitable chains
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #14 from ubizjak at gmail dot com 2009-06-25 08:25 ---
(In reply to comment #13)
> Predictive commoning does exactly what you want.
It is not effective for the testcase in Comment #9. The dumps for innermost
loop are the same for -O2 -funroll-loops [-fpredictive-commoning]:
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-25 08:17 ---
Tentative patch:
Index: ifcvt.c
===
--- ifcvt.c (revision 148927)
+++ ifcvt.c (working copy)
@@ -3780,6 +3780,8 @@
basic_blo
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 07:33 ---
(In reply to comment #5)
> I will simply disable builtins-65.c for non-C99 targets
... like this:
Index: builtins-65.c
===
--- builtins-65.c (revisio
--- Comment #5 from ubizjak at gmail dot com 2009-06-25 07:26 ---
(In reply to comment #2)
> > Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the
> > approach from builtins-18.c) ?
>
> Attached diff. However, there's still a call left to linK_error.
This is d
85 matches
Mail list logo
