--- Comment #11 from bisqwit at iki dot fi 2010-01-18 07:59 ---
Ah, I see. So the reason it is not fixed in 4.5 is that it may cause new
regressions?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
We fork a pthread for some Xalan transformation and then wait for a given time
out period. The thread is started with the default cancellation policy that is
"deferred cancellation". If the thread does not finish we call pthread_cancel
on the thread. Here is the partial stack trace when it crashes
--- Comment #1 from monaka at monami-software dot com 2010-01-18 06:27
---
The origin of this issue is gengtype doesn't create gt-m32r.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
In case "make all-target" after "make all-gcc", the build is failed.
/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/./gcc/xgcc
-B/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/./gcc/
-nostdinc
-B/Users/monaka/git/sourceforge.jp/pf3g
--- Comment #2 from felyza at gmail dot com 2010-01-18 05:54 ---
Can't edit original post. Email client added line breaks where they shouldn't
be. Please use patch attached to issue, and not one orginally submitted in
description.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42786
--- Comment #1 from felyza at gmail dot com 2010-01-18 05:52 ---
Created an attachment (id=19644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19644&action=view)
Didn't have option on submission, its now attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42786
The athlon64-sse3, opteron-sse3, k8-sse3, and athlon-fx processors are
supported in the code itself, however support for the sse3 series was missing,
and the fx series was partially implemented in the configure scripts.
This patch will add support for the sse3 series as well as correct the fx
ent
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-01-18 03:06
---
Subject: Bug 42680
Author: jvdelisle
Date: Mon Jan 18 03:06:10 2010
New Revision: 156000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156000
Log:
2010-01-17 Jerry DeLisle
PR fortran/42680
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-18 02:37
---
I'm resolving this as duplicate of the first nested lambdas PR which came in, I
don't think there is anything more here.
Jason, if you disagree, please take care of re-opening, thanks.
*** This bug has been m
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-18 02:37
---
*** Bug 42738 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-01-18 02:21
---
Subject: Bug 42680
Author: jvdelisle
Date: Mon Jan 18 02:21:20 2010
New Revision: 155998
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155998
Log:
2010-01-17 Jerry DeLisle
PR fortran/42680
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-18 00:56 ---
If you use -arch ppc, then the host/build is really powerpc-apple-darwin so
obviously you are configuring GCC incorrectly and the error message is correct
as that is x86 inline-asm that is being compiled in that sour
I got "error: impossible constraint in ÂeasmÂf" on the build time.
It only happens building with "-arch ppc" option. There is no errors in case I
choice "-arch i386"/"-arch x86_64".
gcc -arch ppc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-proto
--- Comment #4 from janus at gcc dot gnu dot org 2010-01-17 23:46 ---
In addition to the parent component accessibility issue, there is also
something wrong with the error message being thrown in comment #0 and #1.
The check throwing this error resides in 'gfc_find_component', and was m
--- Comment #3 from janus at gcc dot gnu dot org 2010-01-17 23:34 ---
Here is a simple patch for setting the parent component accessibility:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 155994)
+++ gcc/fo
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-01-17 23:23
---
Noticed it is a regression against: gcc (GCC) 4.4.3 20100117 (prerelease)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42782
--- Comment #9 from kargl at gcc dot gnu dot org 2010-01-17 23:06 ---
Is this still a problem on ming32. Can we just drop support
for ming32?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-17 22:47
---
*** Bug 42784 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-17 22:47
---
*** This bug has been marked as a duplicate of 25994 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from janus at gcc dot gnu dot org 2010-01-17 22:42 ---
Another related example. This one is being accepted, although it is invalid.
module mo
implicit none
type,private :: tt
integer :: i = 1
end type
type, extends(tt) :: ttt
real :: x = 2.0
end type
end
g++ doesn't accept this code:
template struct K;
template struct K
{
void f();
};
template struct K : public K
{
using K::f;
typedef const char A[N*I];
void f(const A &) const;
};
template struct Q : public K, public K
{
using K::f;
using K::f; // error:
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-17 22:41
---
Not a regression means that as far as we know no previous release worked, it's
a long standing issue (as you can see gcc4.1.2 already failed). Thus, in
general, at this Stage in the release process toward gcc4
--- Comment #9 from bisqwit at iki dot fi 2010-01-17 22:37 ---
Out of curiosity... What does it mean it's not a regression, and what are its
practical implications?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
--- Comment #1 from janus at gcc dot gnu dot org 2010-01-17 22:35 ---
This problem is not specific to TBPs. It also appears for data components of
the parent type, as the following example shows:
module mo
implicit none
type :: tt
integer :: i = 1
end type
type, extends(tt)
--
schwab at linux-m68k dot org changed:
What|Removed |Added
Known to fail||4.3.4 4.4.3
Target Milestone|--- |4.4.4
htt
--- Comment #9 from mikpe at it dot uu dot se 2010-01-17 22:32 ---
Uros' proposed fix for 4.4 and 4.3 fixes the ICE on both branches.
The original report stated that 4.3 doesn't ICE. A vanilla 4.3-20100103
definitely ICEs for me on the reduced test case.
--
http://gcc.gnu.org/bugzi
--- Comment #13 from schwab at linux-m68k dot org 2010-01-17 22:27 ---
The bug exists since the dawn of time. The problem is that cse thinks that
(zero_extract:SI (mem:QI ...) ...) is zero if (mem:QI ...) is known to be zero,
but the first argument of zero_extract is only a base address
--- Comment #10 from hjl dot tools at gmail dot com 2010-01-17 22:11
---
(In reply to comment #7)
> Btw, if you know more about data types than nothing then do not use the
> __m128* types for data but build your vector types yourself with an
> appropriate base type like
>
> typedef T m
--- Comment #1 from anlauf at gmx dot de 2010-01-17 21:58 ---
Created an attachment (id=19643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19643&action=view)
Bug demo code (fails at runtime)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42783
--- Comment #15 from janus at gcc dot gnu dot org 2010-01-17 21:58 ---
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
Just for completeness: With trunk r152525 you get the same ICE (with a
different line number) on
Hi,
when compiled with -fbounds-check, the attached code fails at runtime
with the following error:
At line 8 of file gfcbug99.f90
Fortran runtime error: Actual string length does not match the declared one for
dummy argument 'mnem_list' (0/8)
No problem with 4.4.0 or earlier.
--
S
--- Comment #8 from ubizjak at gmail dot com 2010-01-17 21:50 ---
Created an attachment (id=19642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19642&action=view)
Patch for 4.3 and 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
--- Comment #3 from kargl at gcc dot gnu dot org 2010-01-17 21:48 ---
http://gcc.gnu.org/news.html
shows
June 6, 2008
An implementation of the OpenMP v3.0 parallel programming interface for C,
C++ and Fortran has been added. Code was contributed by Jakub Jelinek, Richard
Henderson
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #7 from mikpe at it dot uu dot se 2010-01-17 21:36 ---
Uros' proposed patch fixes the ICE in gcc-4.5. It doesn't apply to 4.4 though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
--- Comment #9 from rguenther at suse dot de 2010-01-17 21:35 ---
Subject: Re: [C++0x] Variadic templates + lambdas =
extremely poor code quality, __m128i and aliasing sucks
On Sun, 17 Jan 2010, piotr dot wyderski at gmail dot com wrote:
> --- Comment #8 from piotr dot wyderski a
--- Comment #14 from janus at gcc dot gnu dot org 2010-01-17 21:34 ---
(In reply to comment #10)
> mod1
> 1
> Error: Unclassifiable statement at (1)
Sorry, this is due to a wrapped comment in comment #8. Let's try it again:
module mod1
type :: t1
contains
procedure, nopass :: g
gcc (GCC) 4.5.0 20100117 (experimental)
x86_64-unknown-linux-gnu running -m32
Reproduced on Fedora 12: gcc-4.4.2-20.fc12.x86_64
extern void g (void);
int
f (int a)
{
g ();
return a
--- Comment #13 from dominiq at lps dot ens dot fr 2010-01-17 21:31 ---
(In reply to comment #10)
> I got
>
> pr42769-2.f90:14:
>
> mod1
> 1
> Error: Unclassifiable statement at (1)
The two lines
> logical function my_get() ! must have the same name as the function in
> mod1
hav
--- Comment #12 from janus at gcc dot gnu dot org 2010-01-17 21:29 ---
I'd argue this is not even a regression. Sure, the code in comment #1 fails to
compile with 4.4 since it contains lots of CLASS declarations. But on comment
#8, gfortran 4.4 fails with (almost) the same error:
intern
--- Comment #8 from piotr dot wyderski at gmail dot com 2010-01-17 21:29
---
It would be great to use my own vector data
types, as in simple cases it allows GCC to
automaticly vectorize them in a portable way,
but in more complex cases it would mean a lot
of explicit type casts => even
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-17 21:22 ---
Confirmed. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #11 from hjl dot tools at gmail dot com 2010-01-17 21:21
---
(In reply to comment #9)
> (In reply to comment #5)
> > It is very likely caused by revision :
> > http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
>
> Actually I don't see how this bug could be caused by r1525
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-17 21:19 ---
Btw, if you know more about data types than nothing then do not use the
__m128* types for data but build your vector types yourself with an
appropriate base type like
typedef T m128T __attribute__((__vector_size__(1
--- Comment #10 from hjl dot tools at gmail dot com 2010-01-17 21:18
---
(In reply to comment #8)
> Here is a reduced test case:
>
> module mod1
> type :: t1
> contains
> procedure, nopass :: get => my_get
> end type
> contains
> logical function my_get()
> end function
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-17 21:08 ---
If you fix that issue (simply remove all __may_alias__ attributes from
preprocessed source) you get
.L62:
addl$1, %edx
movdqa (%ebx,%eax), %xmm0
pand(%esi,%eax), %xmm0
movdqa
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-17 21:05 ---
Well, indeed - it would be far more useful to have a less convoluted testcase
where unrelated functions and source make analysis hard.
Please provide a testcase with a _single_ computation kernel applying it in
a si
--- Comment #1 from anlauf at gmx dot de 2010-01-17 21:02 ---
Created an attachment (id=19641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19641&action=view)
Source code for demo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42781
Hi,
the following error occurs only at -O1, not at -O0 or -O2 or -O3:
gfcbug98.f90: In function convert_cof:
gfcbug98.f90:36:0: internal compiler error: in pt_solutions_same_restrict_base,
at tree-ssa-structalias.c:5072
This error does not occur with 4.3.x or 4.4.0
--
Summary: [4
--- Comment #5 from kargl at gcc dot gnu dot org 2010-01-17 20:54 ---
Fixed on trunk. Not backport.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-17 20:53 ---
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
Actually I don't see how this bug could be caused by r152526. That patch was
about SELECT TYPE an
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-17 20:49
---
Still, please provide a short self-contained snippet, no includes, or in any
case, only the bare minimum. Thanks. Again, no cross-references.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
--- Comment #3 from piotr dot wyderski at gmail dot com 2010-01-17 20:46
---
This is a generic code, as it covers two bug reports.
In fact, it will probably be used as a base for additional
two missing optimization reports. So I thought it would be
good to provide the code of the entire
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-17 20:42
---
Please provide a stand-alone, minimal testcase for the purpose of showing the
spurious warning. No cross-citations, please.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #6 from ubizjak at gmail dot com 2010-01-17 20:25 ---
Created an attachment (id=19640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19640&action=view)
Patch to teach {,un}aligned_memory_operand about unaligned offsets
Mikael, can you please test attached patch on your
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-17 20:21
---
I would suggest providing a snippet *much* smaller and explain more clearly the
issue, for example, providing two small functions (say, below 10, 20 lines),
one using more high-level C++0x features and the othe
Uncomment the code of bit_vector::op_not (Attachment #19639)
and compile with
g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp
an error message will appear:
main.cpp: In
--- Comment #1 from piotr dot wyderski at gmail dot com 2010-01-17 20:15
---
Created an attachment (id=19639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19639&action=view)
Source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
The attached code compiled with
g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp
emits code which is, to put it mildly,
far from optimal. For instance, the code of
bit_ve
#include
int test1(__m128i v) {
return _mm_cvtsi128_si32(v);
}
compiled with
g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp
emits:
004012e0 <__Z5test1U8__vectorx
--- Comment #5 from hjl dot tools at gmail dot com 2010-01-17 19:57 ---
Is this related to PR 39954?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
--- Comment #4 from mikpe at it dot uu dot se 2010-01-17 19:52 ---
Created an attachment (id=19638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19638&action=view)
reduced test case
I'm attaching a really tiny test case. The trigger appears to be a 2-byte load
from the stack that
--- Comment #3 from ubizjak at gmail dot com 2010-01-17 19:47 ---
Well, gcc would just generate invalid code without this assert.
Reduced test:
--cut here--
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
typedef uint16_t u16;
typ
--- Comment #2 from mikpe at it dot uu dot se 2010-01-17 19:08 ---
Reproduced with an alpha-unknown-linux cross hosted on i686, built from
gcc-4.4-20100112.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
-
--- Comment #2 from armin76 at gentoo dot org 2010-01-17 19:07 ---
(In reply to comment #1)
> Please try to reproduce with the 4.4.3 release candidate.
>
gcc-4.4.3-RC-20100116 fails the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42775
--- Comment #28 from hjl dot tools at gmail dot com 2010-01-17 19:00
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|REOPENE
--- Comment #27 from hjl at gcc dot gnu dot org 2010-01-17 18:57 ---
Subject: Bug 42542
Author: hjl
Date: Sun Jan 17 18:57:33 2010
New Revision: 155990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155990
Log:
Backport ia64 fix for PR target/42542 from mainline.
gcc/
2010-01-
--- Comment #10 from gary at intrepid dot com 2010-01-17 18:56 ---
(In reply to comment #9)
> Since the corresponding binutils bug is fixed, should this PR be closed ?
We ran into this bug recently, running tests against a GCC (4.5 precursor)
snapshot. Discussion here:
http://gcc.gnu.o
--- Comment #26 from hjl at gcc dot gnu dot org 2010-01-17 18:55 ---
Subject: Bug 42542
Author: hjl
Date: Sun Jan 17 18:55:03 2010
New Revision: 155989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155989
Log:
Backport ia64 fix for PR target/42542 from mainline.
gcc/
2010-01-
--- Comment #25 from hjl at gcc dot gnu dot org 2010-01-17 18:52 ---
Subject: Bug 42542
Author: hjl
Date: Sun Jan 17 18:51:47 2010
New Revision: 155988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155988
Log:
Backport ia64 fix for PR target/42542 from mainline.
gcc/
2010-01-
--- Comment #6 from simartin at gcc dot gnu dot org 2010-01-17 17:44
---
The patch above is not a good idea, since it causes
g++.old-deja/g++.other/overload7.C to fail (the rest of the testsuite is OK)...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42438
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41454
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-01-17 17:01
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-17 17:00
---
Subject: Bug 42248
Author: rguenth
Date: Sun Jan 17 17:00:47 2010
New Revision: 155984
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155984
Log:
2010-01-17 Richard Guenther
PR middle-end/42248
--- Comment #15 from pthaugen at gcc dot gnu dot org 2010-01-17 16:54
---
Updated patch works for testcase and bootstrap/regtest on PPC passed. Thx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42248
Starting from r155273: Fix fall outs from Fix-PR42334.
2009-12-15 Sebastian Pop
PR middle-end/42178
PR middle-end/42334
* graphite-interchange.c (lst_try_interchange): Do not increment the
the OUTER index when there is no AFTER kernel. Do not increment the
O
--- Comment #2 from davek at gcc dot gnu dot org 2010-01-17 16:13 ---
Created an attachment (id=19637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19637&action=view)
binutils support
This is needed to extend the .section directive in the pe-coff port of gas so
that we can tell i
--- Comment #1 from davek at gcc dot gnu dot org 2010-01-17 16:09 ---
Created an attachment (id=19636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19636&action=view)
work in progress patch
should be good for mingw as well.
needs some binutils support - will attach that here too
--- Comment #14 from davek at gcc dot gnu dot org 2010-01-17 16:07 ---
(In reply to comment #13)
> Maybe. Or simply store the size of the compressed blob at the beginning?
Yep, of course. The padding trick is kinda neat because you can do it on the
fly at the end of writing the data
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-17 16:05 ---
Please try to reproduce with the 4.4.3 release candidate.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #21 from davek at gcc dot gnu dot org 2010-01-17 16:01 ---
(In reply to comment #20)
> Well. I suppose we can backport stuff for 4.5.1 if it is LTO specific
> but I don't want to have it before 4.5.0.
Thanks, that's how I'll proceed then.
> Please open an new bugreport fo
As per title, and see also the discussion in bug 41529.
There is no fundamental requirement for ELF to be the object format, as the
object file sections are just used as dumb containers for arbitrary binary
data. The interface between lto-elf.c and the rest of lto1 needs only the
ability to creat
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-17 15:58 ---
Subject: Bug 42773
Author: rguenth
Date: Sun Jan 17 15:58:08 2010
New Revision: 155982
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155982
Log:
2010-01-17 Richard Guenther
PR tree-optimization/
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-17 15:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-17 15:54
---
(In reply to comment #12)
> (In reply to comment #4)
> > The patch is not yet in but I think it's the wrong approach. Instead
> > uncompression should deal with tail padding.
>
> I think you're right. I just ran
../gcc-4.4.2/configure --enable-languages=c --disable-werror
--enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib
--prefix=/opt/cfarm/release/4.4.2 --with-cpu=v8
make bootstrap && make install
PATH=/opt/cfarm/release/4.4.2/bin:$PATH
../gcc-4.4.2/configure --enable-languages
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-17 15:51 ---
Subject: Bug 42773
Author: rguenth
Date: Sun Jan 17 15:50:53 2010
New Revision: 155981
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155981
Log:
2010-01-17 Richard Guenther
PR tree-optimization/
--- Comment #20 from rguenther at suse dot de 2010-01-17 15:48 ---
Subject: Re: LTO configuration should detect if the
target is ELF
On Sun, 17 Jan 2010, davek at gcc dot gnu dot org wrote:
> --- Comment #19 from davek at gcc dot gnu dot org 2010-01-17 15:08
> ---
> Created
--- Comment #3 from mnemo at minimum dot se 2010-01-17 15:39 ---
I tried to attach the output of "gcc -E -O2 sqlite3.c" but it's 1.5MB and
bugzilla rejects anything bigger than 1KB. Even the unmodified source is larger
than this limit, even though you can download it via the sqlite.org U
--- Comment #2 from mnemo at minimum dot se 2010-01-17 15:34 ---
Using gcc 4.4.1, I see this:
1. "gcc -O2 sqlite3.c" repros the bug
2. "gcc -E sqlite3.c > pp.c" followed by "gcc -O2 pp.c" does _NOT_ repro the
bug
However, still using gcc 4.4.1, if I do:
1. "gcc -O2 -E sqlite3.c > ppo.c"
--- Comment #12 from davek at gcc dot gnu dot org 2010-01-17 15:28 ---
(In reply to comment #4)
> The patch is not yet in but I think it's the wrong approach. Instead
> uncompression should deal with tail padding.
I think you're right. I just ran into this bug on cygwin (x86/PE-COFF)
--- Comment #19 from davek at gcc dot gnu dot org 2010-01-17 15:08 ---
Created an attachment (id=19635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
lto for cygwin, and probably other coff targets
FTR. Well, that turned out to be quite easy. Needs some suppor
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-17 14:20
---
Any news on the updated patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42248
1 - 100 of 128 matches
Mail list logo
