tryed to build mplayer
cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -fno-PIC -O4 -march=pentium3
-mtune=pentium3 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -Inative
-I.. -I../libmpdemux -I../loader
gcc-4.1-200506011 compiler ICE's using -ftree-vectorize AND
-fdump-tree-all-details-stats in conjunction. Leave out one of both
options and you got a successful compilation.
Command:
/opt/gcc-4.1-20050611/bin/gcc -O3 -march=pentium4 -msse3 -save-temps
test.c -o test -ftree-vectorize
--- Additional Comments From Ralf_Recker at gmx dot de 2005-06-21 07:25
---
To all attendants of the developer summit:
Greet the elks (moose?) from me ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22135
--
Bug 19766 depends on bug 19561, which changed state.
Bug 19561 Summary: [gfortran] wrong code generation for pointers to derived
types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
What|Old Value |New Value
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-21 08:41
---
Works on both the 4.0 branch and the mainline. Testcase forthcoming.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-21
11:18 ---
Is the emms issue mentioned in comment #14 fixed with Uros' patch proposed
here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01724.html?
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-21
11:20 ---
Uros, also for you it seems...
(http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01724.html)
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-21
11:24 ---
reg-stack has been reworked quite a bit recently. Where do we stand on
this one now?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
11:31 ---
The first one is still producing the same old stupid code.
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2005-06-21 12:04
---
New testcase (everything is initialized this time):
--cut here--
#include mmintrin.h
__v8qi test ()
{
__v8qi mm0 = {1,2,3,4,5,6,7,8};
__v8qi mm1 = {11,22,33,44,55,66,77,88};
volatile __m64 x;
x =
--- Additional Comments From uros at kss-loka dot si 2005-06-21 12:09
---
Fixed on mailine for 4.1.0, what about branches?
--
What|Removed |Added
Known to fail|3.2.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
12:48 ---
*** Bug 22135 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
12:48 ---
This is a dup of bug 22029 which I reported. Thanks for your bug report,
hopefully someone will fix
this soon.
*** This bug has been marked as a duplicate of 22029 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
12:51 ---
Hmm, reconfirmed, then.
--
What|Removed |Added
Status|REOPENED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
12:55 ---
Can you attach the preprocessing source as requested by the web site:
http://gcc.gnu.org/
bugs.html and also the output of cc -v?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
13:01 ---
Confirmed, this is a regression from 3.0.4 where we errored out and that is it
and no infinite loop.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
13:06 ---
I think this is more related to PR 14552 which was shown by me that we
regressed because we did not
output emms at all before so not emmiting mmx instructions without use of the
functions in
mmintrin.h
--- Additional Comments From guardia at sympatico dot ca 2005-06-21 13:26
---
Hum, it will be interesting to test this (it will have to wait a couple of
weeks), but the problem with this here is that there is no mov instructions
that can move stuff between MMX registers and SSE
--- Additional Comments From rohit_goel at ml dot com 2005-06-21 13:43
---
Is there a way to open the file in a+ mode using fstream. Meaning, if the
file exists, open in append mode, else create the file.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22130
--- Additional Comments From bangerth at ices dot utexas dot edu
2005-06-21 14:02 ---
Subject: Re: no compile time array index checking
Doesn't -fmudflap handle this?
The idea was to get a compile-time error whenever possible.
W.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
14:05 ---
(In reply to comment #10)
The idea was to get a compile-time error whenever possible.
It has to be a diagnostic/warning as this is just undefined and undefined code
still has to compile as
one of the DR
--- Additional Comments From debian-gcc at lists dot debian dot org
2005-06-21 14:10 ---
yes, this one is fixed in 4.0 CVS
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|NEW
--- Additional Comments From dje at gcc dot gnu dot org 2005-06-21 14:57
---
This is a bug introduced by the sync patch, not an enhancement request.
I have created a patch to restore the functionality.
--
What|Removed |Added
--- Additional Comments From webmaster at toshsoft dot de 2005-06-21 14:59
---
cc -v output:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/gcc-4.1.0_beta20050604/work/gcc-4.1-20050604/configure
--enable-version-specific-runtime-libs --prefix=/usr
--- Additional Comments From webmaster at toshsoft dot de 2005-06-21 15:02
---
Source of vf_hue.c :
#include stdio.h
#include stdlib.h
#include string.h
#include inttypes.h
#include math.h
#include ../config.h
#include ../mp_msg.h
#include ../cpudetect.h
#include img_format.h
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
15:06 ---
(In reply to comment #3)
Source of vf_hue.c :
We don't want that source, add -save-temps and attach the .i file instead. And
attach it, don't inline it
because it is easy to get at that way.
--
--- Additional Comments From cnewbold at mathworks dot com 2005-06-21
15:50 ---
Subject: Re: [3.4 only] Optimization stomps
const, initialized local array
On Mon, 2005-06-20 at 20:48 +, pinskia at gcc dot gnu dot org wrote:
Also note this is not a full testcase and
--- Additional Comments From bangerth at dealii dot org 2005-06-21 15:55
---
I also see this problem on the 4.0 branch now, with
gcc version 4.0.1 20050531 (prerelease)
I am pretty sure that it wasn't there in 4.0.0, but don't know for sure any
more...
W.
--
--- Additional Comments From trt at acm dot org 2005-06-21 15:55 ---
Since there is mudflap, it is especially important to avoid false positives.
One type occurs in code that never actually executes, e.g. conditional lookup:
#define LOOKUP(i) (i XSIZE ? x[i]: 0)
To defend against
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:00
---
Giovanni,
I can confirm that your patch for PR 8271 also fixes the problem in this PR.
I would be extremely grateful if it would move somewhere...
Cheers
Wolfgang
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
16:01 ---
Confirmed in 4.0.1 20050610 also. Hmm.
--
What|Removed |Added
Known to fail|
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:03
---
I just verified that Giovanni's patch linked to in comment #4 also fixes the
regression reported in PR 21799. Apparently some unrelated change exposed the
problem in 21799, but the underlying issue is the one
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
16:07 ---
I think this was exposed by the patch for PR 19203 (aka DR 214), could you
double check that, that
patch makes sense if it exposes this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:14
---
I don't have the time to check it today, but could try tomorrow. It certainly
sounds plausible. Nathan, could you comment on this problem?
Thanks
Wolfgang
--
What|Removed
This used to compile but doesn't any more on mainline (ok on 4.0.x branch):
---
struct B {
void foo();
};
template typename T class I : public B {};
template typename T class D : private IT {
IT::B::foo;
};
--
g/x
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
16:28 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Hi,
the following code causes GCC to crash (without any options):
#include boost/optional.hpp
class Bla;
int main()
{
boost::optionalBla test;
}
I can reproduce it with GCC 4 but not with GCC 3.3.6. Without ulimit -s this
error crashes even the whole system. Smells like kind
--- Additional Comments From Woebbeking at web dot de 2005-06-21 16:51
---
Created an attachment (id=9124)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9124action=view)
preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22137
--
What|Removed |Added
Severity|critical|normal
Keywords||ice-on-invalid-code
Known to work|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
16:56 ---
*** This bug has been marked as a duplicate of 20789 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
16:56 ---
*** Bug 22137 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Given:
void f(void)
{
templatetypename T class A
{
};
}
g++ 4.0/3.4 gives:
bug.cpp:4: error: expected primary-expression before 'template'
A better error message would be something like Local template declarations is
not allowed or something similar, instead of what is now basicly a
--- Additional Comments From scott dot tupaj at line6 dot com 2005-06-21
17:01 ---
Yes, agreeably this is 'bad' c++ practice in my example. However, if wrong
code is produced, I think it would be prudent for at least a compiler warning
or error be produced if the reason for wrong
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
17:04 ---
Confirmed, 3.3 and before gave a worse error message (at least to me):
t.cc:3: parse error before `template'
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
17:08 ---
The g-socket.o is not fixed, please file a new bug for the testsuite failures
if they have not been fixed.
--
What|Removed |Added
With attached file, I get the following segfault with mainline:
examples/step-18 /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c step-18.ii
step-18.ii:7102: warning: #8216;__malloc__#8217; attribute ignored
step-18.ii: In constructor #8216;std::_Vector_base_Tp,
_Alloc::_Vector_base(size_t, const
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
--- Additional Comments From bangerth at dealii dot org 2005-06-21 17:58
---
Created an attachment (id=9125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9125action=view)
Preprocessed sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:00
---
This looks like a memory problem -- the backtrace is this:
(gdb) r -quiet step-18.ii -o /dev/null
Starting
program:
/home/bangerth/bin/gcc-4.1-pre/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus
-quiet
--- Additional Comments From laurent at guerby dot net 2005-06-21 18:02
---
PASS on x86 and x86_64-linux as of
LAST_UPDATED: Tue Jun 21 11:01:31 UTC 2005
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22033
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:03
---
I also get essentially the same backtrace (with the call to
ggc_set_mark (p=0x14)
at the top) from the 4.0.1pre CVS as of 2005-05-31, although this
happens at a different place in the source code. I'm
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
18:04 ---
Fixed by:
2005-06-20 Daniel Berlin [EMAIL PROTECTED]
* c-typeck.c (build_function_call): Set fundecl = function again.
* tree-ssa-alias.c (find_used_portions): Address taking causes the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
18:12 ---
Hmm,
pr22139.ii:7996: internal compiler error: in ggc_set_mark, at ggc-page.c:1259
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for
--
What|Removed |Added
Summary|[4.1 regression] Segfault |[4.0/4.1 regression]
||Segfault
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-21
18:36 ---
The bug here is that the semantic analysis for a case expression,
in parse.y:java_complete_lhs(), just does this:
/* First, the case expression must be constant. Values of final
fields are
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
18:36 ---
This worked with 3.5.0 20040909 and 4.0.0 20041124 but not with 4.0.0
20050225.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
18:41 ---
I am going to try to reduce this with --param ggc-min-expand=0 --param
ggc-min-heapsize=0
which takes a long time on my poor machine.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
18:43 ---
I am starting to think this is just a stack overflow and a defect in how the GC
works (or someone forgot
chain_next which should have reduced the stack usage).
--
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:48
---
Created an attachment (id=9126)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9126action=view)
Smaller testcase
Attached is another testcase that has only half as many lines (~40k) and
that may be simpler
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
18:55 ---
Attached is another testcase that has only half as many lines (~40k) and
that may be simpler to reduce...
Well it takes a long to reduce because I am also running the Ada/ACATS
testsuite in the
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-21
19:05 ---
I'm testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
19:11 ---
Actually it is not a stack overflow but I real bug in the C++ front-end.
Hmm, we are chaning the TREE_CHAIN of error_mark node, wtf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
+===GNAT BUG DETECTED==+
| 4.1.0 20050621 (experimental) (x86_64-unknown-linux-gnu) GCC error: |
| tree check: expected integer_cst, have cond_expr in |
|do_structure_copy, at tree-ssa-structalias.c:2372
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
19:47 ---
Reduced testcase from 22019 since it was just a related bug:
WITH REPORT; USE REPORT;
PROCEDURE C37213J IS
BEGIN
DECLARE
SUBTYPE SM IS INTEGER RANGE 1..10;
TYPE REC (D1, D2 : SM) IS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
19:49 ---
Still wrong:
i_2: VARYING
i.0_6: [0, +INF] EQUIVALENCES: { } (0 elements)
# i_2 = PHI 0(0), i_9(2);
L0:;
i.0_6 = (signed char) i_2;
if (i.0_6 0) goto L2; else goto L1;
--
What
--- Additional Comments From laurent at guerby dot net 2005-06-21 20:10
---
Kazu, your patch does fix the problem, thanks!
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01293.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22026
--- Additional Comments From matz at suse dot de 2005-06-21 20:31 ---
This patch seems to be the reason for warnings like:
In file included from ../../gcc/gcov-io.h:239,
from ../../gcc/libgcov.c:51:
./auto-host.h:23:1: warning: DEFAULT_USE_CXA_ATEXIT redefined
--- Additional Comments From bangerth at ices dot utexas dot edu
2005-06-21 20:43 ---
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members
I think this was exposed by the patch for PR 19203 (aka DR 214), could you
double check that, that patch makes sense
On Jun 21, 2005, at 4:43 PM, bangerth at ices dot utexas dot edu wrote:
--- Additional Comments From bangerth at ices dot utexas dot edu
2005-06-21 20:43 ---
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to
members
I think this was exposed by the patch for
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-21
20:45 ---
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members
On Jun 21, 2005, at 4:43 PM, bangerth at ices dot utexas dot edu wrote:
--- Additional Comments From bangerth at
--- Additional Comments From bangerth at dealii dot org 2005-06-21 20:58
---
Good idea. So I tried it, and indeed this patch
2005-05-10 Nathan Sidwell [EMAIL PROTECTED]
PR c++/20723
* pt.c (more_specialized_fn): Member functions are unordered wrt
--- Additional Comments From bangerth at dealii dot org 2005-06-21 20:58
---
Unfortunately, the patch to this PR has caused the regression reported in
PR 21799 :-(
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
--- Additional Comments From pault at gcc dot gnu dot org 2005-06-21 21:05
---
Fixed in mainline.
Waiting to commit to 4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22010
--- Additional Comments From laurent at guerby dot net 2005-06-21 21:06
---
Still an infinite loop on bootstrap as of LAST_UPDATED Tue Jun 21 20:10:50 UTC
2005
stage2/xgcc -Bstage2/
-B/home/guerby/work/gcc/install/install-20050621T221553/x86_64-unknown-linux-gnu/bin/
-c -g -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
21:57 ---
(In reply to comment #10)
Actually it is not a stack overflow but I real bug in the C++ front-end.
Hmm, we are chaning the TREE_CHAIN of error_mark node, wtf.
I should a, for some reason I missed typed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
23:04 ---
This was most likely caused by:
2004-12-30 Mark Mitchell [EMAIL PROTECTED]
* decl.c (duplicate_decls): Call ggc_free on declarations we will
not be needing any longer.
The FUNCTION_DECL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
23:07 ---
(In reply to comment #12)
This was most likely caused by:
2004-12-30 Mark Mitchell [EMAIL PROTECTED]
* decl.c (duplicate_decls): Call ggc_free on declarations we will
not be needing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
23:15 ---
We still reference the old decl in DECL_TEMPLATE_SPECIALIZATIONS of the
template_decl determinant in
this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
23:43 ---
This is the reason why ggc_free is considered a bad idea, because if this was
really dead, it would have
been GC'd already but it is not dead. And isn't the reason why we moved alway
from what 2.95.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
00:18 ---
Kenner may I ask what happened to this patch, it never went in, may I test it
and apply it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
00:19 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
00:21 ---
Any news on the patch?
--
What|Removed |Added
Last reconfirmed|2005-03-22 20:37:42
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
00:23 ---
Again no feedback in 3 months :(.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From giovannibajo at libero dot it 2005-06-22
01:24 ---
For mainline, my patch has to be reworked as suggested by Jason in the review.
It is not a difficult work, but I am working on another couple of big patches
so don't hold your breath.
As for the release
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
2005-06-22 01:51 ---
Subject: Re: [4.0/4.1 Regression] Simple array of string access miscompiled
on x86 and x86_64 and PPC
Kenner may I ask what happened to this patch, it never went in,
I still have it in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
03:53 ---
Confirmed, reduced testcase:
double rint (double __x) __attribute__ ((__nothrow__));
void process_C(unsigned char *udst, unsigned char *usrc,
int w, float hue)
{
int i;
int c = rint(hue);
88 matches
Mail list logo
