--- Comment #3 from rfm at gnu dot org 2008-12-08 08:29 ---
Any news on when this can be done? The path is tiny/trivial, so even though it
might be judged low priority I'd have hoped it could be fitted in quickly.
--
rfm at gnu dot org changed:
What|Removed
--- Comment #1 from rfm at gnu dot org 2008-12-08 08:39 ---
It turns out that solving this bug, even though it's conceptually simple, is
quite a lot of work. I have new code to fix it, but it took me a whole day to
develop and involves extensive additions and alterations to sendmsg.c (t
--- Comment #10 from sergeid at il dot ibm dot com 2008-12-08 10:08 ---
Subject: Re: TreeSSA-PRE load after store
misoptimization
Sorry, forgot to attach the patch.(See attached file:
gcse-las-counter.patch)
--- Comment #11 from sergeid at il dot ibm dot com 2008-12-08 10:08 --
--- Comment #9 from sergeid at il dot ibm dot com 2008-12-08 10:03 ---
Subject: Re: TreeSSA-PRE load after store
misoptimization
Can you post your gcc configuration options?
I've created and attached a little patch which adds some more information
to dump file. Can you apply it and se
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-08 10:42 ---
Your testcase has data races, but I came up with valid testcases.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-08 11:33 ---
(In reply to comment #6)
> To add the default paths defined in gcc/cppdefault.c (cpp_include_defaults) to
> the module/INCLUDE search path, one could clone gcc/incpath.c
> (add_standard_paths) and call gfc_add_include
The following program gives -1208725329 0 as output, and no warnings are
generated despite all warnings being turned on (-W -Wall).
#include
int main()
{
int x = 0;
{
int x = x - 1;
printf("%d\n", x);
}
printf("%d\n", x);
return 0;
}
I am not sure as to the exact scoping rules
--- Comment #13 from rguenther at suse dot de 2008-12-08 12:40 ---
Subject: Re: TreeSSA-PRE load after store
misoptimization
On Mon, 8 Dec 2008, sergeid at il dot ibm dot com wrote:
> --- Comment #12 from sergeid at il dot ibm dot com 2008-12-08 11:53
> ---
> I have to ment
--- Comment #12 from sergeid at il dot ibm dot com 2008-12-08 11:53 ---
I have to mention that tree PRE still don't catch this LOAD with -O3.
Though the patch Richard posted does the job.
(In reply to comment #1)
> It works with -O3 (with partial-partial PRE enabled). At least
> phi-
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-08 10:37 ---
Subject: Bug 36802
Author: jakub
Date: Mon Dec 8 10:36:01 2008
New Revision: 142546
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142546
Log:
PR middle-end/36802
* omp-low.c (use_pointer_for_
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-12-08 12:50 ---
> A semi-proper place for .mod files is:
> /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/
> (Semi because finclude does not distinguish between e.g. 32bit and 64bit.)
One could argue that .mod files are library su
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-08 14:00 ---
Any news on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36922
--- Comment #9 from mikael at gcc dot gnu dot org 2008-12-08 14:25 ---
(In reply to comment #7)
> A semi-proper place for .mod files is:
> /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/
> (Semi because finclude does not distinguish between e.g. 32bit and 64bit.)
>
Isn't (...)/x86_64-(
IMPLICIT NONE
INTEGER :: a,b,c,d,e,f,g,h,a
a=0 ; b=0 ; c=0 ; d=0 ; e=0 ; f=0 ; g=0 ; h=0
END
this typo leads to 9 error messages.
--
Summary: poor error message
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-08 14:41 ---
It is unclear which target this was tested on, in any case current trunk tops
on this at around 1.2GB.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-12-08 14:47 ---
I think this is a dup of PR26854 on the trunk at least - the excess memory used
is used by DF (SFTs are gone on the trunk).
So, this is now a 4.2/4.3 regression only (which still have SFTs).
--
rguenth at gcc do
--- Comment #17 from dnovillo at google dot com 2008-12-08 15:03 ---
Subject: Re: [4.3/4.4 Regression] Tree memory
partitioning is spending 430 seconds of a 490 second compile.
On Sun, Dec 7, 2008 at 06:55, steven at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> ---
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-12-08 15:06 ---
Unassigning for now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assign
/buildroot.git.pentium4/i686_toolchain/mpfr
--enable-threads --disable-multilib --with-arch=core2 --with-tune=core2
--disable-libssp --disable-libssp --disable-libmudflap --disable-libgomp
--enable-decimal-float=no
Thread model: posix
gcc version 4.4.0 20081208 (experimental) [trunk revision 142549] (GCC
--- Comment #1 from aldot at gcc dot gnu dot org 2008-12-08 15:08 ---
Created an attachment (id=16851)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16851&action=view)
preprocess source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38445
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-08 15:13 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38445
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-08 15:25 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #56 from rguenth at gcc dot gnu dot org 2008-12-08 15:37
---
Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|r
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from jason at gcc dot gnu dot org 2008-12-08 16:45 ---
added regression tag.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Summar
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38410
--- Comment #2 from r dot emrich at de dot tecosim dot com 2008-12-08
17:08 ---
(In reply to comment #1)
> Created an attachment (id=16815)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16815&action=view) [edit]
> preproccesed source
>
> the following looks weired for me:
>
> #
--- Comment #2 from rth at gcc dot gnu dot org 2008-12-08 17:14 ---
Subject: Bug 38240
Author: rth
Date: Mon Dec 8 17:12:55 2008
New Revision: 142556
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142556
Log:
PR 38240
* tree.h (TYPE_MODE): Invoke vector_type_mod
gloog calls rewrite_into_sese_closed_ssa, which in turn calls
sese_find_uses_to_rename_bb. sese_find_uses_to_rename_bb looks at every phi in
every basic block. For each incoming edge into that basic block which is
associated with the corresponding use argument of the phi, graphite then calls
sese_f
--- Comment #1 from hjagasia at gcc dot gnu dot org 2008-12-08 17:26
---
Created an attachment (id=16852)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16852&action=view)
Reduced test case for bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-12-08
17:32 ---
Subject: Re: [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86
with native assembler
New patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00481.html
--
http://gcc.gnu.or
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-08 18:05 ---
Subject: Bug 35442
Author: jakub
Date: Mon Dec 8 18:03:40 2008
New Revision: 142558
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142558
Log:
PR c/35442
* c-pretty-print.c (pp_c_cast_expressi
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-08 18:06 ---
Subject: Bug 35443
Author: jakub
Date: Mon Dec 8 18:04:58 2008
New Revision: 142559
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142559
Log:
PR c/35443
* c-pretty-print.c (pp_c_expression):
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-08 18:07 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-08 18:07 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-08 18:24 ---
Yeah, this has always bothered me. I typically use -fmax-errors=1 when
developing new code because of the run-on errors for simple mistakes.
This fixes the excessive errors in this case.
Index: symbol.c
=
[gcc -v]
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-08 18:39 ---
(In reply to comment #1)
> - gfc_error (msg, sym->name, where, gfc_basic_typename
> (sym->ts.type));
> + gfc_fatal_error (msg, sym->name, where,
> + gfc_basic_typename (sym->ts.t
--- Comment #4 from dodji at gcc dot gnu dot org 2008-12-08 19:02 ---
Subject: Bug 38390
Author: dodji
Date: Mon Dec 8 19:00:46 2008
New Revision: 142562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142562
Log:
gcc/cp/ChangeLog:
2008-12-07 Dodji Seketeli <[EMAIL PROTECTED]>
Tests weak-1.c and weak-16.c from gcc.dg/weak fail on
powerpc64-unknown-linux-gnu with -m64. A small test case from the last check
in weak-1.c is:
#pragma weak weakvar
extern int weakvar;
int use_it () { return weakvar; }
That check has failed since r139233, when it started failing f
--- Comment #5 from dodji at gcc dot gnu dot org 2008-12-08 19:25 ---
Fixed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-08 19:31 ---
(In reply to comment #2)
> (In reply to comment #1)
> > - gfc_error (msg, sym->name, where, gfc_basic_typename
> > (sym->ts.type));
> > + gfc_fatal_error (msg, sym->name, where,
> > +
I see an assemble failure for gcc.dg/tree-prof/bb-reorg.c; compare-and-branch
instructions are modified to jump to another section.
Some jumps simply can't be made cross-section; one for the ones that can, it
is essential that the REG_CROSSING_JUMP note is added.
I have this patch:
* hoo
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-08 19:34 ---
|
\ ' /
-- (*) --
>*<
>0<@<
>>>@<<
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-08 19:36 ---
This bug is not related to GCC, it is up to printf/console to take into account
/b and printf is not part of GCC. Also the standard says the behavior of the
display device is unspecified.
--
pinskia at gcc dot g
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-08 19:40 ---
On the trunk we get:
t.c: In function 'main':
t.c:7: warning: 'x' is used uninitialized in this function
Which is correct. x in the inner scope comes alive right after the = sign.
--
pinskia at gcc dot gnu dot
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-08 19:49 ---
Either:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01218.html
or call
mark_symbol_refs_as_used (x);
at the very end of output_toc in rs6000.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38448
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-08 20:06 ---
What is target dependent about this, that you need a target hook for it?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from grosser at gcc dot gnu dot org 2008-12-08 20:11 ---
*** Bug 37883 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37980
--- Comment #8 from grosser at gcc dot gnu dot org 2008-12-08 20:11 ---
Fixed in branch and trunk.
Now fails in trunk on verify_ssa(). This is already solved in branch and will
be imported to trunk soon.
*** This bug has been marked as a duplicate of 37980 ***
--
grosser at gcc dot
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-12-08 20:16 ---
>From my point of view this patch seems to be ok.
Multilib is just enabled for 64-bit default target, what makes sende at the
moment. Just about the point of multilib library specifier, I am not sure.
Shouldn't it sep
--- Comment #2 from grosser at gcc dot gnu dot org 2008-12-08 20:17 ---
We get SCoPs that overlap each other. This should be easy to fix.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-08 20:20 ---
Joseph Myers introduced this in the manual with the following patch:
http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00726.html
So this is a regression.
Ah, and Joseph also explained how to fix this, see comment #2. S
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-12-08 20:29 ---
As I explained in 2003, this is a web problem, not a source code bug, and so
not a regression. It is a new feature of the manual such that each user of the
manual may need to do something to take advantage of the new
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #8 from d dot g dot gorbachev at gmail dot com 2008-12-08
20:34 ---
(In reply to comment #7)
The patch causes segfault. This is how it happens:
tree-sra.c:1612
for (f = TYPE_FIELDS (elt->type);
f; f = TREE_CHAIN (f))
{
tree-sra.c:1700
if (size !
--- Comment #18 from andreast at gcc dot gnu dot org 2008-12-08 20:34
---
Should be fixed:
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00125.html
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00124.html
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00068.html
http://gcc.gnu.org/ml/gcc-cvs/2008-12/ms
--- Comment #2 from amylaar at gcc dot gnu dot org 2008-12-08 20:36 ---
(In reply to comment #1)
> What is target dependent about this, that you need a target hook for it?
Some jumps are OK to be made section crossing, while others are not.
And which ones are OK also depends on target o
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-08 20:40 ---
Well, I can't even find this paragraph you want to reference.
And I was under the impression that there was a kind-of "you broke it, you fix
it rule" with GCC bugs. Am I wrong or does this just not apply to you?
-
--- Comment #2 from janis at gcc dot gnu dot org 2008-12-08 20:43 ---
Either of the suggestions in comment #1 fixes this, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38448
--- Comment #8 from joseph at codesourcery dot com 2008-12-08 21:00 ---
Subject: Re: dead link on onlinedocs/gccint/Top-Level.html
On Mon, 8 Dec 2008, steven at gcc dot gnu dot org wrote:
> Well, I can't even find this paragraph you want to reference.
The reference is to a whole manu
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-08 21:06 ---
reduced:
module modx
use, intrinsic :: iso_c_binding
end module modx
block data
use modx
end
A simple way to fix it would be this:
Index: resolve.c
==
--- Comment #3 from grosser at gcc dot gnu dot org 2008-12-08 21:49 ---
Created an attachment (id=16853)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16853&action=view)
Fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
--- Comment #3 from janis at gcc dot gnu dot org 2008-12-08 22:03 ---
Eric,
Your sparc patch referenced in comment #1 fixes this powerpc64-linux failure.
Are you planning to push for it to be accepted for 4.4? In
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00500.html
Mark Mitche
--- Comment #4 from sebpop at gmail dot com 2008-12-08 22:07 ---
Subject: Re: [graphite] ICE : in build_graphite_scops, at graphite.c:1829
On Mon, Dec 8, 2008 at 3:49 PM, grosser at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Fix
>
The patch looks good. Please apply to graphite
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-08 22:10 ---
(In reply to comment #0)
Do you still see the bug ?
If so, please provide more information.
Otherwise, we will close it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37497
--- Comment #9 from janis at gcc dot gnu dot org 2008-12-08 22:11 ---
Subject: Bug 36889
Author: janis
Date: Mon Dec 8 22:10:06 2008
New Revision: 142566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142566
Log:
Backport from mainline:
2008-09-16 Jakub Jelinek
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-08 22:17 ---
(In reply to comment #4)
>
> Using a different object directory I was able to compile c and c++, but not
> fortran. I configured with:
> ./configure
> --prefix=/home/rkraft/apps/gcc4
> --with-mpfr=/home/rkraft/app
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-08 22:23 ---
Is it fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-08 22:32 ---
(Sorry for the delay)
Do you still see the problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37865
--- Comment #8 from doko at ubuntu dot com 2008-12-08 22:32 ---
a current snapshot from the branch, exluding r142149 works for me. I'll try to
reduce the applied patches until the builds succeeds again with r142149, but
again, this may take a while.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-08 22:35 ---
(In reply to comment #4)
> Judging from the latest status reports, I'll find the time to look into it
> again in December before 4.4 is released.
>
We are in December, and 4.4 is not yet released. :p
--
http://g
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-08 22:42 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-08 22:51 ---
Does it still happen?
If so, can you provide more information (host, version, configure options)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38062
--- Comment #4 from danglin at gcc dot gnu dot org 2008-12-08 22:56 ---
I also see this failure on hppa-unknown-linux-gnu compiling empty2.C:
Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/home
/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ -nostdinc++
-I/ho
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-12-08 23:01
---
> a current snapshot from the branch, exluding r142149 works for me. I'll try to
> reduce the applied patches until the builds succeeds again with r142149, but
> again, this may take a while.
So are the dates in
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-08 23:03 ---
Can we close ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-12-08 23:11
---
> Your sparc patch referenced in comment #1 fixes this powerpc64-linux failure.
> Are you planning to push for it to be accepted for 4.4?
Already done yesterday: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg0041
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-08
23:17 ---
Subject: Re: FAIL: gfortran.dg/include_2.f90 -O (test for excess errors):
error: stray '#' in program
> Does it still happen?
Not sure. It takes a long time to do a full build on the this machine.
The
--- Comment #10 from hp at gcc dot gnu dot org 2008-12-08 23:25 ---
(In reply to comment #9)
> Please try this patch.
That did it! Thanks.
(Haven't checked whether this eliminates the valgrind complaints in the posted
trace, but the FAILs in this PR were fixed.)
brgds, H-P
--
h
--- Comment #5 from grosser at gcc dot gnu dot org 2008-12-08 23:35 ---
Subject: Bug 38084
Author: grosser
Date: Mon Dec 8 23:34:36 2008
New Revision: 142569
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142569
Log:
2008-12-08 Tobias Grosser <[EMAIL PROTECTED]>
PR m
--- Comment #10 from doko at ubuntu dot com 2008-12-08 23:42 ---
> So are the dates in your first message correct or not?
hmm, did reply to this, but probably in another report ...
"seen with 4.3.3 20081029, seen the last successful bootstrap with 20081022,
not
seen on the trunk."
thi
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-09 00:50 ---
(In reply to comment #2)
> The test didn't fail in my last build on head. Was there a recent backport
> that might have fixed this PR?
Not really, I was having a look at forgotten PRs
>
> > If so, can you provide m
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2008-12-09
01:11 ---
Ira() calls setup_eliminable_regset() at ira.c:1794, which calls
ix86_frame_pointer_required() at ira.c:1296, which checks
current_function_is_leaf, but this variable is updated only at ira.c:1866.
--
h
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-
prototypes -Wmissing-prototypes -Wcast-qual -fno-common -DHAVE_CONFIG_H -I..
-I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include
-I../..
/gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnum
--- Comment #1 from danglin at gcc dot gnu dot org 2008-12-09 02:56 ---
All the errors are lines like:
TYPE_MODE (record_type) = BLKmode;
Probably caused by:
2008-12-08 Richard Henderson <[EMAIL PROTECTED]>
PR 38240
* tree.h (TYPE_MODE): Invoke vector_type_mode wh
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-09 03:20
---
Subject: Bug 38430
Author: jvdelisle
Date: Tue Dec 9 03:19:09 2008
New Revision: 142575
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142575
Log:
2008-12-08 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from grosser at gcc dot gnu dot org 2008-12-09 04:44 ---
Subject: Bug 38084
Author: grosser
Date: Tue Dec 9 04:43:24 2008
New Revision: 142578
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142578
Log:
2008-12-09 Tobias Grosser <[EMAIL PROTECTED]>
PR mi
--- Comment #7 from grosser at gcc dot gnu dot org 2008-12-09 04:49 ---
Fixed in branch and current.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jason at gcc dot gnu dot org 2008-12-09 06:06 ---
Subject: Bug 38410
Author: jason
Date: Tue Dec 9 06:04:50 2008
New Revision: 142580
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142580
Log:
PR c++/38410
* gimplify.c (gimplify_init_construc
90 matches
Mail list logo
