--- Comment #13 from pinskia at gcc dot gnu dot org 2006-12-19 08:28
---
Subject: Bug 29779
Author: pinskia
Date: Tue Dec 19 08:28:46 2006
New Revision: 120045
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120045
Log:
2006-12-18 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-12-19 08:29
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENE
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-19 08:30 ---
My patch for this needs to be rewritten, not because it was wrong but because
it can be cleaned up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23983
--- Comment #6 from ismail at pardus dot org dot tr 2006-12-19 09:31
---
Another MPlayer bug exposed by gcc, sorry guys!
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
--
--- Comment #7 from bonzini at gnu dot org 2006-12-19 11:01 ---
Subject: Bug 29544
Author: bonzini
Date: Tue Dec 19 11:01:36 2006
New Revision: 120048
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120048
Log:
2006-12-19 Paolo Bonzini <[EMAIL PROTECTED]>
PR bootstrap/
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2006-12-19
11:11 ---
This does not fail on mainline since mem-ssa merge (r119760).
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:27 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
pinskia at gcc dot gnu dot org writes:
> You want -fno-inline-functions-called-once which was added in 4.2.0
> IIRC (...)
I see. (Event
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:31 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
I just noticed another doc bug:
> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
That page says:
-O2
(.
--- Comment #7 from dcb314 at hotmail dot com 2006-12-19 12:34 ---
(In reply to comment #6)
> In that case, you might want to read the C++ standard text to
> appreciate the facts.
There is a strange sort of echo in this bug report ;->
I accept the point that the code is undefined, acco
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-19 12:48 ---
Created an attachment (id=12827)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12827&action=view)
Fix for the problem
With all the interface patches in place, to allow the overloading of
random_seed, the followi
--- Comment #40 from jv244 at cam dot ac dot uk 2006-12-19 12:49 ---
I've now checked that gcc trunk (revision 120045) compiles CP2K (at -O3
-ftree-vectorize -ffast-math -march=opteron) and that the numerical results
seem acceptable. Great job... I hope the the original file is kept arou
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-12-19 12:57
---
(In reply to comment #9)
> OK, so it looks like this is not a testsuite problem: the problem really is
> with the program being tested.
It is also a testsuite problem when the tests are randonly passing or failing
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2006-12-19 13:32
---
Hi!
Sorry for the late response.
The scheduler fails to process a basic block with barrier inside it.
The basic block looks like this:
- Basic block 2 - begin -
(insn:HI 14 12 16 2 (set (mem/f/c/i:SI (symbol_
--- Comment #8 from jh at suse dot cz 2006-12-19 13:39 ---
Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Hi,
barrier in the middle of basic block is invalid and should be noticed by
verify_flow_info and ICE. What part of my patch you quote is supposed
to fix
--- Comment #1 from dnovillo at gcc dot gnu dot org 2006-12-19 13:49
---
This is not a valid bug report. You have failed to include even the bare
minimal information needed. Read http://gcc.gnu.org/bugs.html.
--
dnovillo at gcc dot gnu dot org changed:
What|Remove
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2006-12-19 14:00
---
(In reply to comment #8)
> Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap
>
> Hi,
> barrier in the middle of basic block is invalid and should be noticed by
> verify_flow_info and ICE.
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2006-12-19
14:04 ---
The nan_inf_fmt.f90 failures also occur in gcc 4.2 branch. Can we apply this
fix there as well?
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Add
--- Comment #10 from jh at suse dot cz 2006-12-19 14:12 ---
Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap
>
> cfgrtl.c: rtl_verify_flow_info () makes the same statement as
> control_flow_insn_p ():
> /* We may have a barrier inside a basic block before dead
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-12-19 14:30 ---
>
> Is it reasonable and prudent to have tests like "if (n == 0)"
> optimised away at the -O2 optimisation level ?
>
Yes
> We should remember that -O2 is heavily used by lots of
> customers.
And they expect a lo
--- Comment #2 from hanwen at xs4all dot nl 2006-12-19 14:48 ---
Debian Bug#403628, resolution:
**
Sarge (and glibc 2.3.2) does not support gcc-4.1, though it is possible
get it working on some architectures.
If you want to have gcc-4.1, please upgrade to Etch (testing), or uses
at lea
--- Comment #8 from ian at airs dot com 2006-12-19 14:57 ---
I think I agree that if we spill an 80387 register to the stack, and then load
the value back into an 80387 register, that we should spill all 80 bits, rather
than implicitly converting to DFmode or SFmode.
This would unfortun
Hi everyone,
while running the regression tests for a x86_64 cross-toolchain build under
Cygwin lots of profiler tests went FAIL or UNRESOLVED. The first FAILed while
generating inliner-1.x01:
/usr/local/build-root/build-sles10-64/x86_64-pc-linux-gcc/gcc/xgcc
-B/usr/local/build-root/build-sles10-
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-12-19 15:24
---
> I would suggest put that hunk in (it was probably just merge omision
> from my side) and try to remove the verify_flow_info bit and see if
> everything works. I can do it tonight or tomorrow unless you beat me
--- Comment #9 from whaley at cs dot utsa dot edu 2006-12-19 16:04 ---
Ian,
Thanks for the info. I see I failed to consider the cross-register moves you
mentioned. However, can't those be moved through memory, where something
destined for a 64-bit register is first written from the 80
--- Comment #9 from dcb314 at hotmail dot com 2006-12-19 16:37 ---
(In reply to comment #8)
> And they expect a lot from our optimizers.
Surely not at the -O2 level ?
I thought folks serious about optimisation used -O3
and / or a bunch of other flags like -fsomething ?
> The problem i
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-19 17:02 ---
Subject: Bug 30236
Author: pault
Date: Tue Dec 19 17:02:20 2006
New Revision: 120052
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120052
Log:
2006-12-19 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #5 from pault at gcc dot gnu dot org 2006-12-19 17:06 ---
Brooks,
I did as you suggested to altreturn_3.f90. I added a couple of tests to make
sure that the alternate returns were indeed threading their way through the
programme by selection on the correct values. That soun
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-19 17:09 ---
(In reply to comment #2)
>
> With all the interface patches in place, to allow the overloading of
> random_seed, the following gives the right errors in the right places
>
In fact, I would like to get some of the ba
--- Comment #7 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30022
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh://gcc
--- Comment #37 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 29568
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh://gc
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30040
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh://gcc
--- Comment #9 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30033
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh://gcc
--- Comment #4 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 27953
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh://gcc
--- Comment #4 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30021
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh://gcc
--- Comment #10 from whaley at cs dot utsa dot edu 2006-12-19 17:18 ---
Guys,
In the interests of full disclosure, I did some quick timings on the Core2Duo,
and as I kind of suspected, scalar SSE crushed x87 there. I was pretty sure
scalar SSE could achieve 2 flop/cycle, while Intel ke
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-19 17:21 ---
Troban,
This compiles fine with versions 4.2 and 4.3 of gfortran. I have reproduced
the fault with 4.1. However, it is more now than we can do to keep all three
versions synchronised. I am going to mark this as res
--- Comment #6 from pault at gcc dot gnu dot org 2006-12-19 17:23 ---
Dennis,
Given your willingness to upgrade and Steve's check that all is well with later
versions of gfortran, I am marking this as fixed.
Paul Thomas
--
pault at gcc dot gnu dot org changed:
What|
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-12-19 17:40
---
Again use -fwrapv and forget about it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Starting on December 17, the 4.1 branch fails to build for target e500v2.
The comfiguration is:
--target=powerpc-unknown-linux-gnuspe --enable-e500_double
The failure is:
/temp/gnu_toolchain/build_area/gcc-4_1-branch/obj_gcc-4_1-branch_e500v2/./gcc/xgcc
-B/temp/gnu_toolchain/build_area/gcc-4_1-bra
--- Comment #1 from joseph at codesourcery dot com 2006-12-19 18:16 ---
Subject: Re: New: [4.1 branch] ICE on valid code
On Tue, 19 Dec 2006, edmar at freescale dot com wrote:
> ./include -fPIC -specs=ldblspecs -g -DHAVE_GTHR_DEFAULT -DIN_LIBGC
What's in ldblspecs? If it's built b
--- Comment #33 from sje at cup dot hp dot com 2006-12-19 18:23 ---
I tested Dave's patch from comment #32 and it is fixing the hppa64-* bootstrap
failure. Dave are you going to submit that patch for approval or are you
looking for someone else to pick this up?
--
sje at cup dot hp
--- Comment #2 from edmar at freescale dot com 2006-12-19 18:49 ---
Still, On December 16 I had a complete build, and on December 17 I have an ICE.
It feels more like a regression than moving forward...
Edmar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259
--- Comment #34 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-19
20:05 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 M
> --- Comment #33 from sje at cup dot hp dot com 2006-12-19 18:23 ---
> I tested D
--- Comment #30 from echristo at gcc dot gnu dot org 2006-12-19 20:26
---
Subject: Bug 29302
Author: echristo
Date: Tue Dec 19 20:25:49 2006
New Revision: 120058
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120058
Log:
2006-12-19 Eric Christopher <[EMAIL PROTECTED]>
The comments at the top of the following source file describes the bug.
This happens on gcc 4.1.0 too. for what it is worth, uname -a and
gcc -v output for the Linux box I am currently using are at the end.
The actual code is only 14 lines and only includes stdio.h.
/* source file: enum_bug.c
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-19 21:05 ---
C99 6.7.2.2 does not say that.
Read 6.7.2.2 which says:
> The expression that defines the value of an enumeration constant shall be an
> integer constant expression that has a value representable as an int.
So the
standard std::min/max use crefs for passing arguments.
such behaviour isn't optimal for primitive types.
so called call_traits ( vide boost ) could improve std::
algorithms.
e.g.:
#include
#include
long foo( long x, long y )
{
return std::max( x, y );
}
template < typename T >
typenam
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-19 21:16 ---
*** Bug 30261 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-19 21:16 ---
The problem is the same as referenced in PR 19431, see comment #5.
*** This bug has been marked as a duplicate of 19431 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from joseph at codesourcery dot com 2006-12-19 21:22 ---
Subject: Re: Enumeration types and enumeration constants
erroneously given unsigned types
On Tue, 19 Dec 2006, pinskia at gcc dot gnu dot org wrote:
> So the error with -pedantic is correct as 0U - 1 is not repre
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-12-19 21:23 ---
Reopening.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #3 from joseph at codesourcery dot com 2006-12-19 21:34 ---
Subject: Re: [4.1 branch] ICE on valid code
On Tue, 19 Dec 2006, edmar at freescale dot com wrote:
> Still, On December 16 I had a complete build, and on December 17 I have an
> ICE.
> It feels more like a regres
--- Comment #15 from kargl at gcc dot gnu dot org 2006-12-19 21:55 ---
Just a note here. My recent compilation of LAPACK with gfortran has stumbled
onto to this bug.
gfc -w -c -O3 -march=opteron -funroll-loops -ftree-vectorize \
-I/home/kargl/opt/modules sget33.f
sget33.f: In function
--- Comment #11 from dcb314 at hotmail dot com 2006-12-19 22:03 ---
(In reply to comment #10)
> Again use -fwrapv and forget about it.
Sigh. This implies using -fwrapv everywhere.
Still relatively expensive - I still don't know where the compiler
is doing the new behaviour.
For an add
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-12-19 22:05
---
See also:
http://gcc.gnu.org/ml/gcc/2006-12/msg00459.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30245
void
foo (void)
{
unsigned int x = 0;
void bar (void)
{
x = 254;
}
bar ();
asm volatile ("" :: "m" (x));
}
ICEs in various places at -O and higher in both 4.1.1 and on the trunk.
>From initial skim, it seems tree-nested.c ought to be more careful when
changing
asms.
--
int f (int n)
{
int i;
float t;
#pragma omp parallel
for (i = 1; i < n - 1; ++i)
asm volatile ("" :: "m" (t));
}
--
Summary: ICE with openmp parallel accessed var in asm "m"
constraint
Product: gcc
Version: 4.3.0
Stat
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-19 23:12 ---
OpenMP has the same problem, see PR 30263.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30262
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-19 23:13 ---
(In reply to comment #1)
> OpenMP has the same problem, see PR 30263.
This is most likely because most of the openmp lowering code was copied from
tree-nested.c :).
--
pinskia at gcc dot gnu dot org changed:
I'm trying to compile gcc c/c++ for HP 11.11
configure was executed with the following
./configure --prefix=/tech/techapp/tools --enable-threads=posix
--enable-languages=c,c++
Running make produces the following error:
/bin/sh ../libtool --tag CXX --mode=compile
/tech/techapp/tmp/gcc-4.1.1/hos
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-19 23:17 ---
Here is a rejects valid which makes this a regression in 4.0.x also.
void
foo (void)
{
unsigned int x = 0;
void bar (void)
{
x = 254;
}
bar ();
asm ("" : "=m" (x));
}
Confirmed.
--
pinskia at
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-19 23:18 ---
Here is a rejects valid:
int f (int n)
{
int i;
float t;
#pragma omp parallel
for (i = 1; i < n - 1; ++i)
asm ("" : "=m" (t));
}
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #9 from patchapp at dberlin dot org 2006-12-20 00:57 ---
Subject: Bug number PR7651
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01415.html
--
http://gcc.gnu.org/bugzilla/sho
Greetings,
g++ 4.1 compiles the following without warning, but should not:
struct B { };
struct OK1 {
typedef B X;
};
template
struct A {
friend struct T::X;
};
int main() {
A a;
A b = a;
return(0);
}
The problem is in the definition of struct A where the friend statement
should caus
I will try to get back to this bug this week. I was fighting some
other fights last week, i apologize.
--- Comment #16 from dberlin at gcc dot gnu dot org 2006-12-20 02:55
---
Subject: Re: [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
I will try to get back to this bug this week. I was fighting some
other fights last week, i apologize.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-12-20 03:25 ---
collect2 already does this on platforms which don't use GNU ld.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30205
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-20 05:01 ---
Subject: Bug 30045
Author: pinskia
Date: Wed Dec 20 05:00:50 2006
New Revision: 120069
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120069
Log:
2006-12-19 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
Testcase:
int f(float *);
int g(float x)
{
return f(&(float){x}) + f(&x);
}
When we gimplify this we get:
g (x)
{
int D.1613;
float D.1612;
int D.1614;
int D.1615;
D.1612 = x;
D.1614 = f (&D.1612);
D.1615 = f (&x);
Which is obvious invalid gimple as both D.1612 and x are non
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-20 05:07 ---
Mine, there is not a testcase in the GCC testsuite which tests this yet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-20 05:14 ---
Well this is obviously caused by:
2006-11-20 Carlos O'Donell <[EMAIL PROTECTED]>
Mark Mitchell <[EMAIL PROTECTED]>
* cppdefault.c: Define cpp_PREFIX, cpp_PREFIX_len, and
gcc_exec_prefi
--- Comment #3 from rashmihegde at hp dot com 2006-12-20 07:12 ---
(In reply to comment #2)
> Can you attach the preprocessed source?
>
hello there, sorry for the late reply.
After I added the following patch to gcc-3.4.6/gcc/config/ia64/hpux.h I could
get rid of the error in the gnus
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-20 07:32 ---
(In reply to comment #3)
> These declarations were present in the earlier gcc (3.3.2).
> Please include these declarations in the next release of gcc.
First this patch is wrong.
Second the problem in 3.4.x is that L
73 matches
Mail list logo
