--- Comment #1 from reichelt at gcc dot gnu dot org 2009-05-06 06:59
---
Confirmed. Simple testcase (just compile with -fopenmp:
=
void foo(int n)
{
int x[n];
#pragma omp parallel private(x)
x[0] = 0;
}
=
--- Comment #4 from laurent at guerby dot net 2009-05-06 07:07 ---
The form "--param varname=value" is still not supported so I'm leaving this Pr
open.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38874
The program below compiled with gfortran 4.4.0 (and 4.3.2) and using the
-O3 optimization flag generates, in subroutine SMALL, sse instructions
which assume that the data array C is aligned on a 16 byte boundary.
For example: mulpd (%rax,%rcx,1),%xmm0
where register %rax may not be 16-byte aligne
seen in
https://buildd.debian.org/fetch.cgi?&pkg=gcc-4.4&ver=4.4.0-3&arch=mips&stamp=1241547561&file=log
PR26926 mentions these exports as unnecessary, but afaiu these are not supposed
to be removed in libstdc++.so.6.
Matthias
--
Summary: [4.4/4.5 regression] symbols ce...@glibcx
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-06 08:28 ---
What's the ICE?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-05-06 08:32
---
Fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-05-06 08:33
---
Subject: Bug 40022
Author: rguenth
Date: Wed May 6 08:32:24 2009
New Revision: 147153
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147153
Log:
2009-05-06 Richard Guenther
PR tree-optimizatio
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-06 08:34 ---
I think this is not a valid Fortran program.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mick at nag dot co dot uk 2009-05-06 08:45 ---
(In reply to comment #1)
> I think this is not a valid Fortran program.
>
The main program is illegal because it passes a REAL array argument
to a subroutine expecting DOUBLE PRECISION array. However, the subroutine
SMA
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-06 08:46 ---
Can't replicate this with a stage2 or stage3 compiler with O2, O3, Os -fPIC
{-mthumb} with r147121.
However while bootstrapping the above mentioned revision, I get a segfault as
in http://gcc.gnu.org/bugzilla/show_b
Consider the following module:
module m
contains
subroutine a(x,f)
real :: x
interface
real function f(y)
real,intent(in) :: y
end function
end interface
print *,f(x)
end subroutine
real function func(z)
real,intent(inout) :: z
func = z**2
end function
subroutine cal
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-06 09:01 ---
Yes, I'll clean this up before submission. Did it help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-06 09:17
---
Is this related to PR39491?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-06 09:18 ---
The code generated for SMALL is correct, any caller that passes argument not
aligned on 8 byte boundary (you are mistaken that it requires 16 byte
alignment,
try calling it with c(3) which is 8 byte aligned, but not 16
--- Comment #34 from paolo dot carlini at oracle dot com 2009-05-06 09:19
---
Removing 4.2 regression, branch no longer maintained.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #55 from bonzini at gnu dot org 2009-05-06 09:20 ---
Created an attachment (id=17807)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17807&action=view)
svn diff of cse.c to "fix" the performance regression (updated)
--
bonzini at gnu dot org changed:
What
Variables in Fortran modules compiled in -fPIC shared libraries will get unique
address by a copy relocation to the main executable. Still .debug_info of the
library contains absolute DW_AT_location of the variable - without any
indirection through the GOT vector.
Debugger will then print the var
(see also: http://gcc.gnu.org/ml/fortran/2009-05/msg00068.html)
$> cat foo.f
INTRINSIC ABS, MAX
a(n) = MAX(ABS(2),ABS(3),n)
END
$> gfortran-svn -Wall -Wextra foo.f
foo.f:1.21:
INTRINSIC ABS, MAX
1
Warning: Type specified for intrinsic function 'ab
--- Comment #56 from bonzini at gnu dot org 2009-05-06 09:31 ---
Created an attachment (id=17808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17808&action=view)
usable testcase
Ok, I managed to make a reasonably readable source code (uninclude stdlib
files, remove unused gambit
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-06 09:48 ---
Mark, I'm certainly willing to help fixing this, but it's not a new
regression. Before my change TER _sometimes_ worked around the pre-existing
problem, but it's trivial to construct a case exposing it also before
exp
--- Comment #57 from jakub at gcc dot gnu dot org 2009-05-06 09:49 ---
Why do you need any #include lines at all in the reduced testcase? Compiles
just fine even without them...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #58 from bonzini at gnu dot org 2009-05-06 09:56 ---
Uhm, it's better to run unpatched 4.5 with -O1 -fforward-propagate to get a
fair comparison. Also, I was counting the loop headers, which are not part of
the hot code.
4.2 -O1 4.5 -O1 -ffw-prop
--- Comment #59 from bonzini at gnu dot org 2009-05-06 09:59 ---
Created an attachment (id=17809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17809&action=view)
usable testcase
Without includes as Jakub suggested.
--
bonzini at gnu dot org changed:
What|Remov
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-05-06
10:14 ---
same for arm-linux-gnu arm-linux-gnueabi
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
---
I have found that small sized allocations can't be deleted in c++ , probably
because a bug in glibc. I didn't know where to report this, so i decided that i
will report it here too.
This behaviour affects the very basic map container too. For example by using
map with many elements.
The allocated
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-06 10:24 ---
I'd say this is actually a ld bug, not GCC.
GCC emits:
.uleb128 0x3# (DIE (0x38) DW_TAG_variable)
.ascii "var\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (pr40040lib.f90)
.byt
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-06 10:26 ---
(In reply to comment #0)
> The same warnings are given if the arguments of ABS/MAX are of default-real
> kind, so this not related to implicit typing.
I have to admit that I don't fully understand that sentence, but
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-06 10:29 ---
NAG f95 5.1 gives the following error:
Error: line 21: Dummy proc F arg 1 has different INTENT from actual proc FUNC
arg
Error: line 21: Incompatible procedure argument for F (no. 2) of A
After fixing this (intent I
--- Comment #60 from bonzini at gnu dot org 2009-05-06 10:47 ---
Actually those are created by -fmove-loop-invariants. With -O1
-fforward-propagate -fno-move-loop-invariants I get:
4.5 -O1 -ffw-prop -fno-move-loop-inv
LOOP 1183
INNER LOOP 1.11
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-06 10:52 ---
*** This bug has been marked as a duplicate of 16350 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from ramana at gcc dot gnu dot org 2009-05-06 10:52 ---
*** Bug 39975 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-05-06 10:54
---
(In reply to comment #1)
> If DW_AT_location isn't provided, how would gdb find that address out? Using
> DW_AT_MIPS_linkage_name (currently not emitted) and symbol lookup?
The GDB patch now assembles the sy
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-06 10:55 ---
This is a glibc "bug".
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-06 10:59 ---
(In reply to comment #1)
> What's the ICE?
>
With a cross arm-linux-gnueabi version r147153, I get a segfault with the
following backtrace for this particular testcase.
#0 0x082112b1 in emit_insn_after_1 (first=0
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-06 11:02
---
By the way, if you want to hear my advice, remember to regression test on those
much less widespread targets *before* major releases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40038
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-05-06 11:08
---
For optimization purposes differently aligned type variants should be treated
as a variant type, thus liked in the TYPE_NEXT_VARIANT chain (probably also
required to get correct behavior when assigning alias sets).
--- Comment #2 from joseph at codesourcery dot com 2009-05-06 11:09 ---
Subject: Re: [4.5 Regression] ICE during gimplify_init_constructor
On Tue, 5 May 2009, rguenth at gcc dot gnu dot org wrote:
> Reduced testcase, maybe due to the C const expression changes(?)
I see nothing in the
The following valid testcase triggers an ICE on trunk when compiled with "-O":
===
struct A
{
~A();
void foo();
};
void bar()
{
A a;
try
{
A b;
try
{
b.foo();
}
catch (int) {}
}
catch (int) {}
}
===
bug.cc:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|unknown |4.5.0
http:/
--- Comment #16 from matz at gcc dot gnu dot org 2009-05-06 11:20 ---
Joseph: I'd need some advise where best starting to fix this. I see some
options, when we want to deal with such construct:
struct S { T member __attribute__((packed)); };
... struct S s; ... &s->member ...
(1) make
--- Comment #19 from singler at gcc dot gnu dot org 2009-05-06 11:21
---
Subject: Bug 39546
Author: singler
Date: Wed May 6 11:20:35 2009
New Revision: 147169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147169
Log:
2009-05-06 Johannes Singler
PR libstdc++/39546
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40038
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-06 11:25
---
Benjamin, can you have a look?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40038
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-06 11:39
---
By the way, valgrind, correctly, doesn't report anything, at least together
with glibc 2.9:
==5250== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==5250== malloc/free: in use at exit: 0 bytes
--- Comment #3 from rguenther at suse dot de 2009-05-06 11:41 ---
Subject: Re: [4.5 Regression] ICE during
gimplify_init_constructor
On Wed, 6 May 2009, joseph at codesourcery dot com wrote:
> Subject: Re: [4.5 Regression] ICE during gimplify_init_constructor
>
> On Tue, 5 May 2009
--- Comment #17 from rguenther at suse dot de 2009-05-06 11:45 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:
> --- Comment #16 from matz at gcc dot gnu dot org 2009-05-
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-05-06 11:57 ---
(In reply to comment #1)
> > The same warnings are given if the arguments of ABS/MAX are of default-real
> > kind, so this not related to implicit typing.
>
> I have to admit that I don't fully understand that sente
--- Comment #18 from matz at gcc dot gnu dot org 2009-05-06 11:57 ---
The structure in this testcase is not packed. One member is. Or are you
talking about some different case?
Let's suppose you are and you mean something like this:
struct S {T1 m1; T2 m2; ...} __attribute__((packed
--- Comment #3 from simonracz at gmail dot com 2009-05-06 12:03 ---
(In reply to comment #2)
> By the way, valgrind, correctly, doesn't report anything, at least together
> with glibc 2.9:
You can see the difference in memory usage (after deleting) with top.
--
http://gcc.gnu.org/b
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-06 12:07
---
Oh well, if valgrind is happy, definitely not a libstdc++ maintainers job.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40042
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-06 12:14 ---
That just means you have no idea how a memory allocator works.
Returning all just freed pages immediately to the system is of course possible,
but terribly expensive performance wise, since often on the following mallo
The following code will ICE:
template
void f(T*);
template
struct A {};
template
void g(A > *);
int main()
{
g((A >*)0);
}
--
Summary: ICE when resolves overloaded functions
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severit
--- Comment #1 from ro at gcc dot gnu dot org 2009-05-06 13:01 ---
I've just confirmed the bug on i686-pc-solaris2.10. It doesn't occur on
i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.
I've got a few questions to resolve, though:
* Why does generating code for i686 inst
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-06 13:02 ---
Only ceill is actually missing in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-05-06 13:03 ---
Subject: Bug 40032
Author: jsm28
Date: Wed May 6 13:02:48 2009
New Revision: 147174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147174
Log:
PR c/40032
* c-decl.c (grokdeclarator): Handle in
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-05-06 13:04 ---
Fixed for 4.5.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #61 from jakub at gcc dot gnu dot org 2009-05-06 13:05 ---
Also see PR39871, maybe that's related (though on ARM).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #6 from paolo dot carlini at oracle dot com 2009-05-06 13:20
---
Excellent. Then Matthias' suggested fix makes sense to me. Better if Benjamin
could also review it, however (lately, he touched this code, IIRC).
--
paolo dot carlini at oracle dot com changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-06 13:24 ---
Reduced testcase:
void foo(void *);
void
MMAPGCD (int *A1, int *A2)
{
int *t;
do
{
t = A1;
A1 = A2;
A2 = t;
}
while (A2[-1]);
foo (A1-1);
foo (A2-1);
}
if you make foo take
Segfault with -fdump-parse-tree:
type t
end type
type, extends(t) :: t2
end type t2
end
--
Summary: ICE with type extension and -fdump-parse-tree
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severi
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-06 13:52 ---
Ok, I know what happens.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
As
There is the following line in configure script:
eval `${CC-cc} -E conftest.c | grep host_address=`
Since I have GREP_OPTIONS variable in my environment which looks like
"GREP_OPTIONS=--color=always", some color codes are generated in grep's output.
The issue is the "eval ..." does not work prope
--- Comment #11 from hjl dot tools at gmail dot com 2009-05-06 14:27
---
(In reply to comment #10)
> Yes, I'll clean this up before submission. Did it help?
>
I tried it on revision 147173 and it works on test input for
416.gamess and 465.tonto. I am running reference input now. Than
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-06 14:28 ---
> Btw, adding "REAL ABS,MAX" doesn't help either, so it's not related to the
> function's types.
Well, exactly that should trigger the warning! Thus it shall not help silencing
the warning!
Some light testing - now
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-06 14:31 ---
Confirmed and this is regression with repect to 4.4.0:
[karma] f90/bug% gfc -fdump-parse-tree pr40045.f90
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-06 14:39 ---
Regarding the segfault, valgrind shows:
==14376== Invalid read of size 1
==14376==by 0x616A4F7: fprintf (in /lib64/libc-2.9.so)
==14376==by 0x4B4BF1: show_typebound (dump-parse-tree.c:693)
The line is:
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-06 14:51 ---
(In reply to comment #1)
> I've just confirmed the bug on i686-pc-solaris2.10. It doesn't occur on
> i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.
>
> I've got a few questions to resolve, though:
>
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-06 14:58 ---
(In reply to comment #2)
> and the interesting question is: Why is it called? There are no type-bound
> procedures (and also no components [except of t2%t].
If it's a regression it may be caused by Daniel's r146733 (
--- Comment #4 from domob at gcc dot gnu dot org 2009-05-06 15:01 ---
Yes, that sounds like a problem caused by my patch; it did change the structure
of storing the type-bounds, so maybe simply changing the if to the one shown by
Tobias was wrong.
I will look into this!
--
domob at
--- Comment #1 from bonzini at gnu dot org 2009-05-06 15:06 ---
With 4.5 I see
With 4.5.0 I see:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl func
add
--- Comment #62 from bonzini at gnu dot org 2009-05-06 15:07 ---
No, totally unrelated to PR39871
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
Compiling "libgomp.c++/task-4.C" with "g++" is successful, but compiling it
with "g++ -fopenmp" gives:
libgomp.c++/task-4.C: In function 'void foo(int, int)':
libgomp.c++/task-4.C:37: error: type mismatch in indirect reference
int[0:D.2193]
int[0:<<< error >>>]
D.2218 = &(*q.1)[0];
libgomp.c++/
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|unknown |4.5.0
http://g
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #19 from bonzini at gnu dot org 2009-05-06 15:33 ---
ARM moved to PR40031 (and PR39978?).
What about AIX?
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from bonzini at gnu dot org 2009-05-06 15:35 ---
Is this reproducible with a crosscompiler and with --enable-checking=all,gcac?
You can try valgrind too.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-06 15:45 ---
Subject: Bug 40041
Author: burnus
Date: Wed May 6 15:44:18 2009
New Revision: 147183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147183
Log:
2009-05-06 Tobias Burnus
PR fortran/40041
*
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-06 15:46 ---
FIXED on the trunk (4.5). Thanks for reporting it.
Crossref: The warning was added by Daniel Franke with Rev. 126153 for PR 20373.
--
burnus at gcc dot gnu dot org changed:
What|Removed
The following was produced on a gentoo x86 linux system with a pentium-m
processor, the system compiler is Gentoo 4.3.3-r2 and kernel is
linux-2.6.28-gentoo-r5.
Last night, I built gcc 4.4.0 and installed it into /home/bgalehouse/installs.
I then reconfigured a library (CGAL) to make use of c++0
--- Comment #12 from hjl dot tools at gmail dot com 2009-05-06 15:48
---
(In reply to comment #11)
> (In reply to comment #10)
> > Yes, I'll clean this up before submission. Did it help?
> >
>
> I tried it on revision 147173 and it works on test input for
> 416.gamess and 465.tonto.
--- Comment #20 from matz at gcc dot gnu dot org 2009-05-06 15:48 ---
Bootstrap on AIX was already working on April 29:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02342.html
I just left this open for the other (ARM/Mips) problem. As that now moved
somewhere else, this here is fixed.
--- Comment #1 from bgalehouse at spamcop dot net 2009-05-06 15:53 ---
Created an attachment (id=17810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17810&action=view)
Compressed preprocessed source to recreate.
Attached proprocessed source file, compressed to fit under bugtraq s
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-06 15:56 ---
*** This bug has been marked as a duplicate of 39958 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-06 15:56 ---
*** Bug 40047 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from bgalehouse at spamcop dot net 2009-05-06 16:04 ---
Just found that it seems unrelated to c++0x features. I configured the library
to not require them, and found the 4.4.0 crashes but the system compiler works.
(both running same options, without the -std=c++0x, but ot
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-06 16:18 ---
Works for me on the branch head.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ppluzhnikov at google dot com 2009-05-06 16:36 ---
(In reply to comment #3)
> Note that this is likely not a problem in practice as
> memcpy (p, p, sizeof (*p)) is difficult to implement
> in a way that would make it not work.
>From Julian Seward:
JS> AIUI, POSIX
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-06 16:40 ---
(In reply to comment #2)
> The GDB patch now assembles the symbol name from its parent DW_TAG_module as
> `__modulename_MOD_varname'. As GDB also has to know the C++ mangling rules I
> believe this Fortran mangling i
--- Comment #13 from matz at gcc dot gnu dot org 2009-05-06 16:50 ---
Subject: Bug 40021
Author: matz
Date: Wed May 6 16:49:13 2009
New Revision: 147186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147186
Log:
PR middle-end/40021
* cfgexpand.c (maybe_cleanup_e
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-06 16:54 ---
Hence, fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #4 from janis at gcc dot gnu dot org 2009-05-06 17:01 ---
Subject: Bug 39986
Author: janis
Date: Wed May 6 16:59:53 2009
New Revision: 147188
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147188
Log:
PR middle-end/39986
* dfp.c (encode_decimal32, de
--- Comment #5 from janis at gcc dot gnu dot org 2009-05-06 17:18 ---
This was a regression after all, release branches do not have the bug. I added
the new test case to the 4.4 and 4.3 branches.
--
janis at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-06 17:39 ---
(In reply to comment #3)
> The code generated for SMALL is correct, any caller that passes argument not
> aligned on 8 byte boundary (you are mistaken that it requires 16 byte
> alignment,
> try calling it with c(3)
--- Comment #8 from hjl at gcc dot gnu dot org 2009-05-06 17:47 ---
Subject: Bug 40023
Author: hjl
Date: Wed May 6 17:45:40 2009
New Revision: 147195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06 H.J. Lu
Backport from mainline:
2009-0
--- Comment #6 from hjl at gcc dot gnu dot org 2009-05-06 17:47 ---
Subject: Bug 39983
Author: hjl
Date: Wed May 6 17:45:40 2009
New Revision: 147195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06 H.J. Lu
Backport from mainline:
2009-0
--- Comment #15 from hjl at gcc dot gnu dot org 2009-05-06 17:47 ---
Subject: Bug 40021
Author: hjl
Date: Wed May 6 17:45:40 2009
New Revision: 147195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06 H.J. Lu
Backport from mainline:
2009-
--- Comment #9 from dodji at gcc dot gnu dot org 2009-05-06 18:56 ---
I have submitted a patch for this at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00270.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17395
On machines with only a vector/vector shift like the powerpc and spu, the wrong
type is generated for the tree vector that is created with the constant
splat'ed to fill the vector. The problem is the code uses
get_vectype_for_scalar_type, and integer constants don't have a type. So
get_vectype_fo
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-06
19:08 ---
Created an attachment (id=17811)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17811&action=view)
Patch to fix vector shift by constant on machines with vector/vector shift
This patch fixes the pr
1 - 100 of 138 matches
Mail list logo
