--- 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 due to
--- 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
--- 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 @@
--- 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 #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
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=2435package_id=241304
one finds a tar ball (gcc-4.4.0-mingw32-src-2.tar.gz) with patches.
For Fortran, I found the
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 08:58 ---
Oops...
--
ubizjak at gmail dot com changed:
What|Removed |Added
Keywords|
--- 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:
--- 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 #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 #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=gccview=revrev=148939
Log:
2009-06-25 Richard Guenther rguent...@suse.de
--- 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=gccview=revrev=148939
Log:
2009-06-25 Richard Guenther rguent...@suse.de
--- 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
--- 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 #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
--- 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 #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=gccview=revrev=148941
Log:
2009-06-25 Martin Jambor mjam...@suse.cz
PR
--- 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 #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
--- 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
--- 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; ia.size(); i++) {
va = a[i];
vb = b[i];
(*va) = (*vb) *coef;
}
this only says that a[i] and b[i] do not alias in one
--- 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
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 #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.
--- 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=18067action=view)
This program segfaults if compiled with gcc-4.4.0 and -msse on i686
--
--- 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=18068action=view)
corresponding ii-file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
--- 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
--- 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 #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=gccview=revrev=148943
Log:
2009-06-25 Richard Guenther rguent...@suse.de
--- 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
--- 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=gccview=revrev=148944
Log:
2009-06-25 Richard Guenther rguent...@suse.de
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 -
--- 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
On Tue, Jun 23, 2009 at 3:39 AM, Nick Cliftonni...@redhat.com 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’:
--- 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
--- 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 #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
--- 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.
--
--- 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
--- 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
--- 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 #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
cat bug.cc
#include string
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++
--- 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
--- 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;
--- 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 #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 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
I'm using the code from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
and added output of the result vector:
#include cstdio
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 =
--- 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=18069action=view)
failing program using vector extensions
--
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=18070action=view)
the intermediate source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
--- 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=18071action=view)
the generated assembly source by gcc-4.3.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
--- 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
--- 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=gccview=revrev=148948
Log:
2009-06-25 Andrew Pinski andrew_pin...@playstation.sony.com
--- 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 #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 #7 from rguenth at gcc dot gnu dot org 2009-06-25 19:32 ---
D.1412 = BIT_FIELD_REF a, 128, 0;
is certainly not the size of v2sf...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
Sent from my iPhone
On Jun 25, 2009, at 12:30 PM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.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
--- 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
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #6 from rguenth
--- 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=18072action=view)
detail of error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
--- 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 #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
abidmus...@gmail.com wrote:
I read the online install GCC document and other tips on line for installing
GCC.
I use the
--- 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 #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 #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
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
--- 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 gcc in
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 #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=18073action=view)
Find precision of *, /, +, -, ==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
69 matches
Mail list logo
