Hi!
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
Philippe
François-Xavier Coudert wrote:
Hi all,
Attached is a first draft of a patch to add a -fstatic-libgfortran
option. This new option is recognized by the driver and
Philippe Schaffnit wrote:
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
It wouldn't make sense -- GMP and MPFR are never linked into the
compiled output at all. (They're only used within the compiler itself,
for processing
Oops! Thanks a lot for your reply.
Philippe
Brooks Moses wrote:
Philippe Schaffnit wrote:
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
It wouldn't make sense -- GMP and MPFR are never linked into the
compiled output at
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
GMP and MPFR are host libraries, so it is actually an independent
issue. However, it might be worth having --with-static-gmp and
--with-static-mpfr to request static linking of these
Bonsoir monsieur,
je viens par ce mail solliciter votre aide pour l'ex#233;cution d'une
transaction financi#232;re. J'aimerais investir dans l'immobilier ou un
domaine prosp#232;re dans votre pays
que vous pourrez me conseiller. J'ai sept millions cinq cents mille dollars
am#233;ricains
On 4/23/07, Diego Novillo [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote on 04/23/07 14:40:
Any references?
Yes, at the last HiPEAC conference Grigori Fursin presented their
interactive compilation interface, which could be used for this.
http://gcc-ici.sourceforge.net/
That work is part
Hi everyone,
Although I'm seeing this on 3.3.3, it appears to be determined by the
backend, so I think it's still reasonable to ask:
I have some code that calls __builtin_ffs, but entirely on compile-time
constants. When I compile it (using an inhouse custom ELF-target backend)
with
On Tue, Apr 24, 2007 at 10:55:56AM +0200, François-Xavier Coudert wrote:
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
GMP and MPFR are host libraries, so it is actually an independent
issue. However, it might be worth having
Hi,
Something broke the bitfield handling recently and before I delve deeper
into it, I'm hoping someone admits guilt. :)
This is taken from execute/20040709-1.c:
struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
struct K retmeK (struct K x)
{
return x;
}
This produces the following
Hi,
On Tue, 24 Apr 2007, I wrote:
simply copying values like this it's overkill, what makes this worse is
that the rtl optimizers can often do as much with this (and in combination
^ not
with subreg it's not getting better...)
This should make more
Hi all,
I am working with GCC 4.1.1, I need some clarification for the DWARF
information generated by this sample Program,
#include stdio.h
int fun(const char*, ...);
/* Variadic function */
int fun(const char *raj,...)
{
return 9;
}
int main()
{
fun(Hello world,3,2);
return 0;
}
For
Roman Zippel [EMAIL PROTECTED] writes:
This is taken from execute/20040709-1.c:
struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
struct K retmeK (struct K x)
{
return x;
}
This produces the following code:
retmeK:
link.w %fp,#0
move.l %d3,-(%sp)
Dave Korn [EMAIL PROTECTED] writes:
Although I'm seeing this on 3.3.3, it appears to be determined by the
backend, so I think it's still reasonable to ask:
I have some code that calls __builtin_ffs, but entirely on compile-time
constants. When I compile it (using an inhouse custom
Uros Bizjak [EMAIL PROTECTED] дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED]
Hello!
I'm particularly interested in this patch
(http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html); pretty
nice for
users of Pentium 3 and Athlon. Has it been or will it be integrated into
mainline?
This patch heavily
[EMAIL PROTECTED] wrote:
Tim Prince wrote:
[EMAIL PROTECTED] wrote:
Where is gstdint.h ? Does it acctually exist ?
libdecnumber seems to use it.
decimal32|64|128.h's include decNumber.h which includes deccontext.h
which includes gstdint.h
When you configure libdecnumber (e.g. by running
On 24 April 2007 15:34, Ian Lance Taylor wrote:
Dave Korn writes:
Although I'm seeing this on 3.3.3, it appears to be determined by the
backend, so I think it's still reasonable to ask:
I have some code that calls __builtin_ffs, but entirely on compile-time
constants. When I compile
.file stdin
foo.global _ffs
Is this really a reference? It just looks like a declaration. A
typical ELF assembler will not generate an undefined symbol merely
because it sees a .global pseudo-op.
I think gas 2.17 counts as a typical ELF assembler. It does create undefined
On 24 April 2007 15:50, Dave Korn wrote:
On 24 April 2007 15:34, Ian Lance Taylor wrote:
It looks like this comes from an inappropriate call to
assemble_external. You should find out what is calling that for _ffs.
Heh, surely you mean You should find out what is calling that, ffs! ;-)
Hi,
On Tue, 24 Apr 2007, Andreas Schwab wrote:
Even without this bug gcc usage of bitfield instruction has become a
little insane lately, e.g. 2.95/3.4 produce this code:
retmeK:
link.w %a6,#0
move.l 8(%a6),%d0
unlk %a6
rts
FWIW, I get this
On 24 April 2007 15:52, Paul Brook wrote:
.file stdin
foo.global _ffs
Is this really a reference? It just looks like a declaration. A
typical ELF assembler will not generate an undefined symbol merely
because it sees a .global pseudo-op.
I think gas 2.17 counts as a
Paul Brook [EMAIL PROTECTED] writes:
.file stdin
foo.global _ffs
Is this really a reference? It just looks like a declaration. A
typical ELF assembler will not generate an undefined symbol merely
because it sees a .global pseudo-op.
I think gas 2.17 counts as a
On Apr 24, 2007, at 8:30 AM, Wolfgang Gellerich wrote:
What is the policy concerning the usage of SAVE_EXPRs?
Roughly, if you do something like:
tree foo(a, b)
return build (a, b);
You don't need any saving. If you do:
tree foo(a, b)
return build (a, build (a, b));
You need to
H. J. Lu [EMAIL PROTECTED] wrote on 24/04/2007 01:03:25:
...
There are
[EMAIL PROTECTED] vect]$ cat pmovzxbw.c
typedef unsigned char vec_t;
typedef unsigned short vecx_t;
in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667
By the way, this PR says Integer externsions aren't vectorized
On Tue, Apr 24, 2007 at 08:55:24PM +0300, Dorit Nuzman wrote:
H. J. Lu [EMAIL PROTECTED] wrote on 24/04/2007 01:03:25:
...
There are
[EMAIL PROTECTED] vect]$ cat pmovzxbw.c
typedef unsigned char vec_t;
typedef unsigned short vecx_t;
in
Hello,
I have just created a new branch for development of C++0x-specific
features in the GNU C++ front end. The branch is branches/cxx0x-branch
in Subversion, and information about this branch is available at
http://gcc.gnu.org/projects/cxx0x.html.
The intent of this branch is to collect all
I'd going to make a change to the policy for setting priorities for PRs
in Bugzilla, to try to help address two issues that have been raised:
1. There may be vitally important bugs that are not regressions, and
therefore do not get visibility before releases. (We have, in past,
allowed changes
[I apologize to those of you receiving duplicate copies of this mail. I
thought so hard about copying people that I forgot to address to the list.]
Table of contents:
1. PRs
2. Schedule
3. Rationale
If you're in the CC: list, there are possible action items for you
below. (Recent feedback was
On 24 April 2007 16:00, Dave Korn wrote:
I'd say that I've inherited a thinko-fied version of ASM_OUTPUT_EXTERNAL
Wrong, wrong, wrong. I don't have an ASM_OUTPUT_EXTERNAL at all. What I do
have, however, is TARGET_ASM_GLOBALIZE_LABEL, which appears to somehow be
equated with
On 4/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
2. PR 30222: crash on gcc.target/i386/vectorize1.c
This PR is apparently due to only part of a mainline patch being applied
to 4.2. It was so diagnosed in December 2006, but nobody has identified
the missing part of the mainline patch.
--- Comment #3 from aldot at gcc dot gnu dot org 2007-04-24 08:52 ---
Works with gcc version 4.2.0 20060922
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
The following code when compiled with GCC 4.1.2 gives wrong result
res = . Code compiled with GCC 4.0.4 or GCC 3.3.3 gives right
result: res = .
In all these cases command line was: gcc test.c -o test.exe.
Adding optimization options for GCC 4.1.2 do change the output in
--- Comment #15 from jb at gcc dot gnu dot org 2007-04-24 10:09 ---
Subject: Bug 27740
Author: jb
Date: Tue Apr 24 10:08:52 2007
New Revision: 124098
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124098
Log:
2007-04-24 Janne Blomqvist [EMAIL PROTECTED]
PR
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-04-24 10:35
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from l dot lunak at suse dot cz 2007-04-24 10:54 ---
I think the reason why the discussion here is so complicated is that you
libstdc++ people are, because of exception_defines.h, confused about what
-fno-exceptions actually does. From comment #15: Then, why what is this
gcc version 4.3.0 20070424 (experimental)
$ i586-mingw32msvc-gcc-3.4.5 -v
Reading specs from /usr/lib/gcc/i586-mingw32msvc/3.4.5/specs
Configured with:
/build/buildd/mingw32-3.4.5.20060117.1.dfsg/build_dir/src/gcc-3.4.5-20060117-1-dfsg/configure
-v --prefix=/usr --target=i586-mingw32msvc --enable
--- Comment #1 from tobivollebregt at gmail dot com 2007-04-24 11:01
---
Created an attachment (id=13434)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13434action=view)
Shell script which I used to create the 4.3.0 cross compiler
The used binutils are the official binutils. The
--- Comment #2 from tobivollebregt at gmail dot com 2007-04-24 11:06
---
Created an attachment (id=13435)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13435action=view)
Log of the compiler build.
Maybe the most useful line in the log:
Checked out revision 124096.
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #26 from jakub at gcc dot gnu dot org 2007-04-24 11:59 ---
Please define fixed. You run an invalid program, all you need is change
your expectations what will happen.
It is the same as if you write
pthread_mutex_t m;
pthread_mutex_init (m, NULL);
pthread_mutex_lock (m);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-24 12:39 ---
test.c: In function 'main':
test.c:5: warning: incompatible implicit declaration of built-in function
'printf'
include stdio.h
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from jakub at gcc dot gnu dot org 2007-04-24 12:45 ---
Even more reduced testcase:
static int s = 6;
template typename T struct F
{
~F () {}
F (T x) {}
const T operator[] (unsigned i) const { return s; }
};
template typename T FT foo (const FT x)
{
return FT
--- Comment #27 from dominiq at lps dot ens dot fr 2007-04-24 13:03 ---
Please define fixed.
For me fixed==no hanging period.
You run an invalid program,
Yes, I know, repeating that won't help!
all you need is change your expectations what will happen.
Bugzilla has plenty of
--- Comment #4 from krebbel at gcc dot gnu dot org 2007-04-24 13:08 ---
Subject: Bug 31641
Author: krebbel
Date: Tue Apr 24 13:08:05 2007
New Revision: 124099
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124099
Log:
2007-04-24 Andreas Krebbel [EMAIL PROTECTED]
PR
--- Comment #5 from krebbel at gcc dot gnu dot org 2007-04-24 13:15 ---
Subject: Bug 31641
Author: krebbel
Date: Tue Apr 24 13:15:11 2007
New Revision: 124100
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124100
Log:
2007-04-24 Andreas Krebbel [EMAIL PROTECTED]
PR
--- Comment #2 from vlasenko at bifit dot com dot ua 2007-04-24 13:16
---
Yes, it compiles with warning... so what? The bug is not in the warning. If you
insert #include stdio.h in the top of source the bug reproduces and the
problem will not leave.
ÎÊ, if you want to play in
--- Comment #6 from krebbel at gcc dot gnu dot org 2007-04-24 13:21 ---
Subject: Bug 31641
Author: krebbel
Date: Tue Apr 24 13:21:22 2007
New Revision: 124101
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124101
Log:
2007-04-24 Andreas Krebbel [EMAIL PROTECTED]
PR
--- Comment #7 from krebbel at gcc dot gnu dot org 2007-04-24 13:23 ---
Ulrich approved the patch for 4.1/4.2/4.3.
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #91 from jv244 at cam dot ac dot uk 2007-04-24 13:37 ---
current (i.e. this morning) mainline seems to miscompile CP2K (tested current
CVS of CP2K). The code compiled with '-O3 -ftree-vectorize -ffast-math
-march=native' on an opteron segfaults on several regtests. The same
--- Comment #3 from vlasenko at bifit dot com dot ua 2007-04-24 14:21
---
The bug also reproduces with GCC 4.1.2 compiled under FreeBSD:
gcc -save-temps -v test.c -o test
Using built-in specs.
Target: i386-unknown-freebsd6.0
Configured with: ../gcc-4.1.2/configure --enable-languages=c
--- Comment #92 from jv244 at cam dot ac dot uk 2007-04-24 14:31 ---
(In reply to comment #91)
/QS/regtest-gpw-1/NO2_lsd.inp.out
I'll see if I can reduce the number of optimization options.
the above testcase also fails at a plain '-O2' so I suspect it won't happen
only on opteron.
There are many failures in libmudflap in
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01222.html
=== libmudflap tests ===
Running target unix/-m32
FAIL: libmudflap.c++/pass41-frag.cxx execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
FAIL:
--- Comment #93 from jv244 at cam dot ac dot uk 2007-04-24 15:11 ---
(In reply to comment #91)
I checked that the miscompilation at '-O2' also happens for the sources in the
initial comment, so it is definitely a gfortran regression. Furthermore, by
recompiling ai_overlap_new.F and
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-24 15:17 ---
I can reproduce this on i?86 with 32bit HWI (even with optimization if you
trick around CCP):
int one(void) { return 1; }
int printf (const char *, ...);
int main()
{
long long qhat = one();
long long res =
There are many libgomp failures in
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01222.html
=== libgomp tests ===
Running target unix/-m32
=== libgomp Summary for unix/-m32 ===
# of expected passes1566
Running target unix
FAIL:
--- Comment #94 from jv244 at cam dot ac dot uk 2007-04-24 15:27 ---
In fact, gfortran gives a hint here. The file that gets miscompiled produces
the following warnings:
cp2k/obj/Linux-x86-64-gfortran/sdbg gfortran -c -O2 -g -Wall -Wextra
ai_overlap_new.f90
ai_overlap_new.f90: In
The following generates bogus warnings and is likely miscompiled:
MODULE test
IMPLICIT NONE
INTEGER, PARAMETER :: dp=KIND(0.0D0)
INTEGER, ALLOCATABLE, DIMENSION(:) :: ncoset
PRIVATE
PUBLIC :: overlap
CONTAINS
SUBROUTINE overlap(la_max_set,la_min_set,
--- Comment #95 from jv244 at cam dot ac dot uk 2007-04-24 15:42 ---
added PR 31683 with a reduced testcase
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #28 from pinskia at gcc dot gnu dot org 2007-04-24 15:46
---
Bugzilla has plenty of entries ICE on invalid, I am just asking that
hanging
on invalid is not brushed aside just because it does happen on a platform
some
people don't like.
It is hanging on undefined, I
--- Comment #29 from dominiq at lps dot ens dot fr 2007-04-24 15:59 ---
It is hanging on undefined, I think there is a difference here, a big
difference.
What is the difference for you?
Just as a side note, that's not me who classed the PR as invalid and so far I
did not see a class
I get the following ICE with current gcc 4.3. This goes back until at
least 4.3 20070303. 4.1 works. I cannot test 4.2.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 mpfr-mul.c
mpfr-mul.c: In function 'mpfr_mul':
mpfr-mul.c:19: error: unrecognizable insn:
(insn:TI 69 102 68 3
// { dg-do compile }
// { dg-options -O2 }
template typename T struct F
{
~F () {}
F (T x) {}
};
template typename T FT foo (const FT x)
{
return x;
}
static Fint z = 6;
struct G
{
G () {}
Fint operator () (Fint x) { return z; }
};
int
main ()
{
G g;
Fint j (0);
Fint f = g
See failing test, analysis, suggested patch here:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01595.html
--
Summary: wrong codegen from reload
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-24 18:46 ---
This example is not valid. As NAG f95 claims:
Error: foo.f90, line 45: ALLOCATABLE array NCOSET used but never ALLOCATEd
(gfortran actually misses such an error/warning.
--
--- Comment #2 from jv244 at cam dot ac dot uk 2007-04-24 19:07 ---
(In reply to comment #1)
This example is not valid. As NAG f95 claims:
it is not supposed to be a runable example, of course. Just remove the
'PRIVATE' from the module definition.
--
while the gcc executables reliably find their associated files / libraries /
paths
even if the executable is invoked through symlinks, this is not true for the
gnat executables.
For example, if gcc is installed with --prefix=/usr/local/gcc1
and then symlinks are made such as
cd /usr/local/bin ; ln
[Based on PR 31683]
Compiling the following program with gfortran -O -Wall gives the bogus
warning:
foo2.f90:4: warning: 'offset.7' may be used uninitialized in this function
foo2.f90:4: warning: 'stride.6' may be used uninitialized in this function
foo2.f90:4: warning: 'pab.0' may be used
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-24 19:58 ---
This example is not valid. As NAG f95 claims:
it is not supposed to be a runable example
Well, for hunting miscompilation bugs, a runable example helps.
I think there are at leastfour problems:
a) The program
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-24 20:05 ---
This is really the oldest uninitialized variable warning bug out there. PR
5035.
*** This bug has been marked as a duplicate of 5035 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-04-24 20:05
---
*** Bug 31688 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Support defining attributes at a scope level.
I'd like to request implementing the feature of defining attributes at a scope
level. For example, allow a syntax such as the following, possibly as a GNU
extension:
if (something)
__attribute__ ((section(bar))) {
/* body of if-statement */
}
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-24 20:27 ---
This is a stupid idea, it is better to use __builtin_expect and
-freorder-blocks-and-partition which means this is a dup of bug 26493.
*** This bug has been marked as a duplicate of 26493 ***
--
pinskia at gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-24 20:27 ---
*** Bug 31689 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2007-04-24 20:31 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01609.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-04-24 21:06 ---
There is a questionable practice with the original code: It uses
pab without a check whether it is present.
The compiler tries to guard against this, partially by generating
(from the *.original dump):
if (pab
Sorry to bother you, but I am too stupid to understand how to use bugzilla.
So I send this bug report via the way of last resort.
The following does not link.
module bla
logical, save :: blub= .true.
logical :: pa
equivalence (blub, pa)
end module
program po
use bla, only : pa
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
--- Comment #5 from ian at gcc dot gnu dot org 2007-04-24 21:44 ---
Subject: Bug 31602
Author: ian
Date: Tue Apr 24 21:44:45 2007
New Revision: 124120
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124120
Log:
./:
PR tree-optimization/31602
* tree-ssa-loop-ch.c
Testcase, compile with -g:
const __uint128_t fives = (((__uint128_t)(0xULL))
64)|((__uint128_t)(0xULL));
The ICE on the mainline:
t.c:0: internal compiler error: in add_const_value_attribute, at
dwarf2out.c:10005
Please submit a full bug report,
with preprocessed
--- Comment #5 from simartin at gcc dot gnu dot org 2007-04-24 21:52
---
Subject: Bug 25923
Author: simartin
Date: Tue Apr 24 21:52:16 2007
New Revision: 124121
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124121
Log:
2007-04-24 Simon Martin [EMAIL PROTECTED]
PR
The following example takes the wrong_branch when compiled with
gcc -O3 -fno-inline
gcc --version
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
= example =
#include stdio.h
static int get_kind(int v) {
volatile int k = v;
return k;
}
static int
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-04-24 22:37
---
Subject: Bug 31587
Author: fxcoudert
Date: Tue Apr 24 22:37:37 2007
New Revision: 124126
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124126
Log:
PR fortran/31587
* lib/gcc-dg.exp
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-04-24 22:38
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from mmitchel at gcc dot gnu dot org 2007-04-24 22:42
---
Zdenek, do you think this is appropriate for a backport to 4.2.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-04-24 22:43
---
Andrew, can you identify whatever portion of this patch has not yet been
applied to 4.2?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-04-24 22:44
---
(In reply to comment #17)
Zdenek, do you think this is appropriate for a backport to 4.2.0?
Well right now it causes a regression so I don't think it is appropriate until
that regression is fixed :). See PR 31676
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-04-24 22:46
---
Ulrich, in response to your question in Comment #6, yes, this bug appears in
4.1 and 4.2, not just in 4.3. So, if you think it's safe to backport the
reload patch, it would be nice to have the fix there as well.
--- Comment #33 from mmitchel at gcc dot gnu dot org 2007-04-24 22:51
---
Geoff, do you intend to backport these Darwin patches to 4.2.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
--- Comment #6 from ian at gcc dot gnu dot org 2007-04-24 22:54 ---
Subject: Bug 31602
Author: ian
Date: Tue Apr 24 22:54:22 2007
New Revision: 124127
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124127
Log:
PR tree-optimization/31602
* tree-ssa-loop-ch.c
--- Comment #6 from ian at gcc dot gnu dot org 2007-04-24 23:24 ---
Subject: Bug 31605
Author: ian
Date: Tue Apr 24 23:24:01 2007
New Revision: 124128
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124128
Log:
./:
PR tree-optimization/31605
* tree-vrp.c
--- Comment #7 from ian at gcc dot gnu dot org 2007-04-24 23:26 ---
Subject: Bug 31605
Author: ian
Date: Tue Apr 24 23:26:25 2007
New Revision: 124129
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124129
Log:
./ChangeLog:
PR tree-optimization/31605
* tree-vrp.c
--- Comment #7 from ian at airs dot com 2007-04-24 23:27 ---
Fixed on mainline and 4.2 branch.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from ian at airs dot com 2007-04-24 23:28 ---
Fixed on mainline and 4.2 branch.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #6 from paolo at gcc dot gnu dot org 2007-04-24 23:37 ---
Subject: Bug 30500
Author: paolo
Date: Tue Apr 24 23:36:53 2007
New Revision: 124130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124130
Log:
2007-04-24 Paolo Carlini [EMAIL PROTECTED]
PR c++/30500
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
--- Comment #8 from pcarlini at suse dot de 2007-04-24 23:39 ---
Problem solved in 4_2-branch too via fixing C++/30500. Nothing will be done in
older branches.
--
pcarlini at suse dot de changed:
What|Removed |Added
General
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
1 - 100 of 136 matches
Mail list logo
