[Bug c/22134] New: vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
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 -D_GNU_SOURCE -o vf_hue.o vf_hue.c
vf_hue.c: In function 'process_C':
vf_hue.c:54: error: could not split insn
(insn:TI 31 217 218 (parallel [
(set (mem:SI (reg/f:SI 7 sp) [21 S4 A8])
(unspec:SI [
(reg:XF 8 st)
] 66))
(clobber (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [0 S4 A8]))
]) 469 {fistsi2_with_temp} (insn_list:REG_DEP_TRUE 30
(insn_list:REG_DEP_TRUE 193 (nil)))
(expr_list:REG_DEAD (reg:XF 8 st)
(nil)))
vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
Please submit a full bug report,
with preprocessed source if appropriate.
make[1]: *** [vf_hue.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/mplayer-1.0_pre7/work/MPlayer-1.0pre7/libmpcodecs'
make: *** [libmpcodecs/libmpcodecs.a] Error 2
--
Summary: vf_hue.c:54: internal compiler error: in
final_scan_insn, at final.c:2419
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: webmaster at toshsoft dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 4.1.0
GCC host triplet: 4.1.0
GCC target triplet: 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22134
[Bug tree-optimization/22135] New: The gcc-4.1-20050611 compiler ICE's using -ftree-vectorize in conjunction with -fdump-tree-all-details-stats
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 -ftree-vectorizer-verbose=5
-fdump-tree-all-details-stats
Error message:
test.c: In function 'main':
test.c:2: internal compiler error: in op_iter_init_maydef, at
tree-flow-inline.h:1065
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Source Code (I wrote a stupid little program to reproduce the error):
int main(void)
{
int a[1024];
int b[1024];
int c[1024];
int i, j = 0;
for (i = 0; i 1024; i++) {
a[i] = i;
b[i] = 1023 - i;
}
for (i = 0; i 1024; i++)
c[i] = a[i] + b[i];
for (i = 0; i 1024; i++)
j = j + c[i];
return j;
}
P.S.: Placed under GPL by Ralf Recker [EMAIL PROTECTED] :-)
Preprocessed source:
# 1 test.c
# 0 built-in
# 1 command line
# 1 test.c
int main(void)
{
int a[1024];
int b[1024];
int c[1024];
int i, j = 0;
for (i = 0; i 1024; i++) {
a[i] = i;
b[i] = 1023 - i;
}
for (i = 0; i 1024; i++)
c[i] = a[i] + b[i];
for (i = 0; i 1024; i++)
j = j + c[i];
return j;
}
--
Summary: The gcc-4.1-20050611 compiler ICE's using -ftree-
vectorize in conjunction with -fdump-tree-all-details-
stats
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf_Recker at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i586-pc-linux-gnu
GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22135
[Bug tree-optimization/22135] The gcc-4.1-20050611 compiler ICE's using -ftree-vectorize in conjunction with -fdump-tree-all-details-stats
--- 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 fortran/19766] wrong results or crash from PURE function
-- 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 Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19766
[Bug fortran/19561] [gfortran] wrong code generation for pointers to derived types
--- 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 CC||tobi at gcc dot gnu dot org Status|NEW |RESOLVED Known to fail|4.0.0 | Known to work||4.0.1 4.1.0 Resolution||WORKSFORME Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- 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 CC||uros at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- 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 CC||uros at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug target/15492] floating-point arguments are loaded too early to x87 stack
--- 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 Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15492
[Bug target/15492] floating-point arguments are loaded too early to x87 stack
--- 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 Status|WAITING |NEW Last reconfirmed|2005-06-20 02:33:16 |2005-06-21 11:31:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15492
[Bug target/22076] Strange code for MMX register moves
--- 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 = _mm_add_pi8 (mm0, mm1);
return x;
}
--cut here--
Pass 0
Register 67 costs: AD_REGS:4000 Q_REGS:4000 NON_Q_REGS:4000 INDEX_REGS:4000
LEGACY_REGS:4000 GENERAL_REGS:4000 MMX_REGS:46000 INT_SSE_REGS:38000 MEM:16000
Register 67 pref GENERAL_REGS or none
Pass 1
Register 67 costs: AD_REGS:4000 Q_REGS:4000 NON_Q_REGS:4000 INDEX_REGS:4000
LEGACY_REGS:4000 GENERAL_REGS:4000 MMX_REGS:46000 INT_SSE_REGS:38000 MEM:16000
69 registers.
...
(insn:HI 18 45 22 1 (set (reg:V8QI 67)
(mem/u/i:V8QI (symbol_ref/u:SI (*.LC2) [flags 0x2]) [0 S8 A64])) 766
{*movv8qi_internal} (nil)
(expr_list:REG_EQUIV (const_vector:V8QI [
(const_int 12 [0xc])
(const_int 24 [0x18])
(const_int 36 [0x24])
(const_int 48 [0x30])
(const_int 60 [0x3c])
(const_int 72 [0x48])
(const_int 84 [0x54])
(const_int 96 [0x60])
])
(nil)))
...
test:
pushl %ebp
movl%esp, %ebp
subl$24, %esp
movl$807671820, %eax
movl$1616136252, %edx
movl%eax, -8(%ebp)
movl%edx, -4(%ebp)
movl-8(%ebp), %eax
movl-4(%ebp), %edx
movl%eax, -24(%ebp)
movl%edx, -20(%ebp)
movq-24(%ebp), %mm1
leave
movq%mm1, %mm0
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
[Bug target/21981] __m64 return value should be returned in %mm0
--- 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 3.3.3 3.4.0 4.0.0 |3.2.3 3.3.3 3.4.0 4.0.0 |4.1.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21981
[Bug tree-optimization/22029] [4.1 Regression] ICE with -fdump-tree-copyprop3-details
--- 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 CC||Ralf_Recker at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22029
[Bug tree-optimization/22135] The gcc-4.1-20050611 compiler ICE's using -ftree-vectorize in conjunction with -fdump-tree-all-details-stats
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22135
[Bug tree-optimization/22122] [4.1 Regression] -ftree-vectorize ICE get_loop_body, at cfgloop.c:819
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21 12:51 --- Hmm, reconfirmed, then. -- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22122
[Bug target/22134] vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
--- 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 CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Component|c |target GCC build triplet|4.1.0 | GCC host triplet|4.1.0 | GCC target triplet|4.1.0 | Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22134
[Bug java/22128] [3.4/4.0/4.1 Regression] Cyclic inheritance hangs jc1
--- 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 CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||compile-time-hog Known to fail||3.2.3 3.3.3 3.4.0 4.0.0 ||4.1.0 Known to work||3.0.4 Last reconfirmed|-00-00 00:00:00 |2005-06-21 13:01:52 date|| Summary|Cyclic inheritance hangs jc1|[3.4/4.0/4.1 Regression] ||Cyclic inheritance hangs jc1 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22128
[Bug target/22076] Strange code for MMX register moves
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- 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 registers (MOVQ can't do it). In SSE2, there is one (MOVQ), but not in the original SSE. So the compiler generates movlps instructions from/to memory from/to SSE registers along MMX calculations, and, in the original SSE case, ends up not being able to reduce anymore than MMx-memory-XMMx-memory-MMx again for data that should have stayed in MMX registers all along... it does not realize up front how expensive it is to use XMM registers on SSE1 along with MMX instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug libstdc++/22130] fstream fails to create a file in ios::in| ios::out mode.
--- 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
[Bug c/8268] no compile time array index checking
--- 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. - Wolfgang Bangerth email:[EMAIL PROTECTED] www: http://www.ices.utexas.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- 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 says. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug target/18830] bootstrap of a biarch compiler fails in libstdc++.
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18830
[Bug tree-optimization/22117] [4.1 Regression] VRP thinks ptr type + ptr type is always nonnull.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22117
[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata
--- 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 AssignedTo|geoffk at gcc dot gnu dot |dje at gcc dot gnu dot org |org | Severity|enhancement |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21760
[Bug target/22134] vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
--- 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 --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0-beta20050604 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050604/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050604 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050604/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050604/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050604/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.0 20050604 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22134
[Bug target/22134] vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
--- 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
#include mp_image.h
#include vf.h
#include ../libvo/video_out.h
#include m_option.h
#include m_struct.h
static struct vf_priv_s {
uint8_t *buf[2];
float hue;
float saturation;
} vf_priv_dflt = {
{NULL, NULL},
0.0,
1.0,
};
static void process_C(uint8_t *udst, uint8_t *vdst, uint8_t *usrc, uint8_t
*vsrc, int dststride, int srcstride,
int w, int h, float hue, float sat)
{
int i;
const int s= rint(sin(hue) * (116) * sat);
const int c= rint(cos(hue) * (116) * sat);
while (h--) {
for (i = 0; iw; i++)
{
const int u= usrc[i] - 128;
const int v= vsrc[i] - 128;
int new_u= (c*u - s*v + (115) + (12816))16;
int new_v= (s*u + c*v + (115) + (12816))16;
if(new_u 768) new_u= (-new_u)31;
if(new_v 768) new_v= (-new_v)31;
udst[i]= new_u;
vdst[i]= new_v;
}
usrc += srcstride;
vsrc += srcstride;
udst += dststride;
vdst += dststride;
}
}
static void (*process)(uint8_t *udst, uint8_t *vdst, uint8_t *usrc, uint8_t
*vsrc, int dststride, int srcstride,
int w, int h, float hue, float sat);
/* FIXME: add packed yuv version of process */
static int put_image(struct vf_instance_s* vf, mp_image_t *mpi)
{
mp_image_t *dmpi;
dmpi=vf_get_image(vf-next, mpi-imgfmt,
MP_IMGTYPE_EXPORT, 0,
mpi-w, mpi-h);
dmpi-planes[0] = mpi-planes[0];
dmpi-stride[0] = mpi-stride[0];
dmpi-stride[1] = mpi-stride[1];
dmpi-stride[2] = mpi-stride[2];
if (!vf-priv-buf[0]){
vf-priv-buf[0] = malloc(mpi-stride[1]*mpi-h
mpi-chroma_y_shift);
vf-priv-buf[1] = malloc(mpi-stride[2]*mpi-h
mpi-chroma_y_shift);
}
if (vf-priv-hue == 0 vf-priv-saturation == 1){
dmpi-planes[1] = mpi-planes[1];
dmpi-planes[2] = mpi-planes[2];
}else {
dmpi-planes[1] = vf-priv-buf[0];
dmpi-planes[2] = vf-priv-buf[1];
process(dmpi-planes[1], dmpi-planes[2],
mpi-planes[1], mpi-planes[2],
dmpi-stride[1],mpi-stride[1],
mpi-w mpi-chroma_x_shift, mpi-h
mpi-chroma_y_shift,
vf-priv-hue, vf-priv-saturation);
}
return vf_next_put_image(vf,dmpi);
}
static int control(struct vf_instance_s* vf, int request, void* data)
{
vf_equalizer_t *eq;
switch (request) {
case VFCTRL_SET_EQUALIZER:
eq = data;
if (!strcmp(eq-item,hue)) {
vf-priv-hue = eq-value * M_PI / 100;
return CONTROL_TRUE;
} else if (!strcmp(eq-item,saturation)) {
vf-priv-saturation = eq-value/100.0 + 100;
return CONTROL_TRUE;
}
break;
case VFCTRL_GET_EQUALIZER:
eq = data;
if (!strcmp(eq-item,hue)) {
eq-value = rint(vf-priv-hue *100 / M_PI);
return CONTROL_TRUE;
}else if (!strcmp(eq-item,saturation)) {
eq-value = rint(vf-priv-saturation*100 - 100);
return CONTROL_TRUE;
}
break;
}
return vf_next_control(vf, request, data);
}
static int query_format(struct vf_instance_s* vf, unsigned int fmt)
{
switch (fmt) {
case IMGFMT_YVU9:
case IMGFMT_IF09:
case IMGFMT_YV12:
case IMGFMT_I420:
case IMGFMT_IYUV:
case IMGFMT_CLPL:
case IMGFMT_444P:
case IMGFMT_422P:
case IMGFMT_411P:
return vf_next_query_format(vf, fmt);
}
return 0;
}
static void uninit(struct vf_instance_s* vf)
{
if (vf-priv-buf[0]) free(vf-priv-buf[0]);
if (vf-priv-buf[1]) free(vf-priv-buf[1]);
free(vf-priv);
}
static int open(vf_instance_t *vf, char* args)
{
vf-control=control;
vf-query_format=query_format;
vf-put_image=put_image;
vf-uninit=uninit;
if(!vf-priv) {
vf-priv = malloc(sizeof(struct vf_priv_s));
memset(vf-priv, 0, sizeof(struct vf_priv_s));
}
if (args) sscanf(args, %f:%f, vf-priv-hue, vf-priv-saturation);
[Bug target/22134] vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22134
[Bug rtl-optimization/22129] [3.4 only] Optimization stomps const, initialized local array
--- 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 cannot just run, so is there way to get one which is self contained? I have not had any success limiting the scope of the source required for an executable example. The code in question comes from the self-validation code for the open-source Crypto++ library, a C++ class library of cryptographic primitives, version 4.2. Let me know what would be most useful for you at this point. One additional note, it appears that removing -fno-strict-aliasing from the compiler command line also makes the problem go away even with -O2 or -O3. I doubt this is safe, however. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22129
[Bug c++/21799] [4.1 regression] Spurious ambiguity with pointers to members
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c/8268] no compile time array index checking
--- 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 that, issue the warning only if skip_evaluation is zero. (For a more general fix, see http://gcc.gnu.org/ml/gcc/2004-10/msg00859.html) Another is taking the address one past the last element, e.g. int a[10]; int *aend = a[10]; // this is perfectly valid, and common -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c++/21799] [4.1 regression] Spurious ambiguity with pointers to members
--- 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 |Added CC||giovannibajo at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- 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||4.0.1 4.1.0 Known to work||3.4.0 Summary|[4.1 regression] Spurious |[4.0/4.1 regression] |ambiguity with pointers to |Spurious ambiguity with |members |pointers to members Target Milestone|4.1.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c++/8271] Templates and pointers to const member functions
--- 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 in the present PR, and Giovanni's patch fixes both. It would be great if it (or a suitably modified version) could be approved. Cheers Wolfgang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8271
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- 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
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- 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 |Added CC||nathan at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c++/22136] New: [4.1 regression] Rejects old-style using declaration
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 /home/bangerth/bin/gcc-4.0.1-pre/bin/c++ -c x.cc
g/x /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
x.cc:8: error: type #8216;B#8217; is not a base type for type
#8216;DT#8217;
W.
--
Summary: [4.1 regression] Rejects old-style using declaration
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug c++/22136] [4.1 regression] Rejects old-style using declaration
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug c++/22136] [4.1 regression] Rejects old-style using declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21 16:28 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-21 16:28:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug c++/22137] New: Internal error: Segmentation fault (program cc1plus)
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 of endless recursion.
Cheers,
André
--
Summary: Internal error: Segmentation fault (program cc1plus)
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Woebbeking at web dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22137
[Bug c++/22137] Internal error: Segmentation fault (program cc1plus)
--- 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
[Bug c++/22137] Internal error: Segmentation fault (program cc1plus)
-- What|Removed |Added Severity|critical|normal Keywords||ice-on-invalid-code Known to work||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22137
[Bug c++/22137] Internal error: Segmentation fault (program cc1plus)
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22137
[Bug c++/20789] [4.0 regression] ICE with incomplete type in template
--- 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 CC||Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
[Bug c++/22138] New: Better error message for rejecting local template decleration.
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 Syntax
error
--
Summary: Better error message for rejecting local template
decleration.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: betasoft at acc dot umu dot se
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22138
[Bug c++/22132] Wrong code: upcasting a const class pointer to struct the class derives from
--- 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 code is because invalid or questionable c++ syntax is being used. Every other compiler I've used, including gcc 3.x.x doesn't not corrupt access to the members in this scenario like gcc 4.0.0 does. Other compilers either error because of the const violation, or accepts it and produces the proper results when accessing the pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
[Bug c++/22138] Better error message for rejecting local template decleration.
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-06-21 17:04:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22138
[Bug tree-optimization/22019] [4.1 Regression] do_structure_copy ICE on Ada gnatlib
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22019
[Bug c++/22139] New: [4.1 regression] Segfault
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 _Alloc) [with _Tp = Vectordouble, _Alloc = std::allocatorVectordouble ]#8217;: step-18.ii:85305: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. W. -- Summary: [4.1 regression] Segfault Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bangerth at dealii dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.1 regression] Segfault
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.1 regression] Segfault
--- 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
[Bug c++/22139] [4.1 regression] Segfault
--- 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 step-18.ii -o /dev/null step-18.ii:7102: warning: #8216;__malloc__#8217; attribute ignored Program received signal SIGSEGV, Segmentation fault. 0x084da5ef in ggc_set_mark (p=0x14) at ggc-page.c:594 594 return base[L1][L2]; (gdb) bt #0 0x084da5ef in ggc_set_mark (p=0x14) at ggc-page.c:594 #1 0x0814cb1f in gt_ggc_mx_lang_tree_node (x_p=0x43683dec) at gt-cp-tree.h:69 #2 0x0814cb88 in gt_ggc_mx_lang_tree_node (x_p=0x4305fd80) at gt-cp-tree.h:349 #3 0x0814cf0d in gt_ggc_mx_lang_tree_node (x_p=0x4362c000) at gt-cp-tree.h:121 #4 0x0814ce36 in gt_ggc_mx_lang_tree_node (x_p=0x42f96930) at gt-cp-tree.h:188 #5 0x0814ca86 in gt_ggc_mx_lang_decl (x_p=0x40982a40) at gt-cp-tree.h:367 #6 0x0814cfff in gt_ggc_mx_lang_tree_node (x_p=0x4362af30) at gt-cp-tree.h:151 #7 0x0814cb88 in gt_ggc_mx_lang_tree_node (x_p=0x42f8ea50) at gt-cp-tree.h:349 #8 0x0814d757 in gt_ggc_mx_lang_type (x_p=0x4361a1b0) at gt-cp-tree.h:441 #9 0x0814d310 in gt_ggc_mx_lang_tree_node (x_p=0x4362557c) at gt-cp-tree.h:182 #10 0x0814d214 in gt_ggc_mx_lang_tree_node (x_p=0x436255e8) at gt-cp-tree.h:155 #11 0x0814cb88 in gt_ggc_mx_lang_tree_node (x_p=0x42ff3618) at gt-cp-tree.h:349 #12 0x0814d232 in gt_ggc_mx_lang_tree_node (x_p=0x4364e288) at gt-cp-tree.h:157 #13 0x0814ceef in gt_ggc_mx_lang_tree_node (x_p=0x436253cc) at gt-cp-tree.h:119 #14 0x0814cf58 in gt_ggc_mx_lang_tree_node (x_p=0x436254a4) at gt-cp-tree.h:126 #15 0x0814ce36 in gt_ggc_mx_lang_tree_node (x_p=0x42f9d738) at gt-cp-tree.h:188 and so on, for exactly 2500 frames. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug tree-optimization/22033] [4.1 Regression] ACATS ICE cd1c04e create_variable_info_for, at tree-ssa-structalias.c:2789
--- 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
[Bug c++/22139] [4.1 regression] Segfault
--- 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 pretty sure the problem is the same, though. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug tree-optimization/22033] [4.1 Regression] ACATS ICE cd1c04e create_variable_info_for, at tree-ssa-structalias.c:2789
--- 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 entire variable to be used. * tree-ssa-structalias.c (do_structure_copy): Fix handling of unknown size variables, and structure copies from addressof operations. Simplify how we do *a = *b type structure copies. (init_base_vars): Add ANYTHING = ANYTHING constraint the right way. READONLY's address is not taken by default. INTEGER dereference should point to anything. (create_variable_info_for): It's okay for the first field to not start at 0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22033
[Bug c++/22139] [4.1 regression] Segfault
--- 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 instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
-- What|Removed |Added Summary|[4.1 regression] Segfault |[4.0/4.1 regression] ||Segfault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug java/21540] switch stmt problem
--- 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 accepted. */ cn = fold (cn); However, fold() does not know about final fields and the like. fold_constant_for_init doesn't seem to be factored properly to be useful here, either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 Severity|normal |critical Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Target Milestone|4.1.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 to reduce... W. -- What|Removed |Added Attachment #9125 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 background. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug java/21540] switch stmt problem
--- 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 |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-12 21:49:59 |2005-06-21 19:05:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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
[Bug ada/22140] New: ACATS ICE c37213j c37213l do_structure_copy, at tree-ssa-structalias.c:2372
+===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 | | Error detected at c37213j.adb:320:5 | +===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 | | Error detected at c37213l.adb:329:5 | -- Summary: ACATS ICE c37213j c37213l do_structure_copy, at tree- ssa-structalias.c:2372 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22140
[Bug ada/22140] [4.1 Regression] ACATS ICE c37213j c37213l 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 RECORD NULL; END RECORD; TYPE MY_ARR IS ARRAY (SM RANGE ) OF INTEGER; GENERIC TYPE CONS IS PRIVATE; PROCEDURE SUBTYP_CHK (OBJ_XCP : BOOLEAN; TAG : STRING); PROCEDURE SUBTYP_CHK (OBJ_XCP : BOOLEAN; TAG : STRING)IS SUBTYPE SCONS IS CONS; X : SCONS; FUNCTION VALUE RETURN SCONS IS BEGIN RETURN X; END VALUE; BEGIN IF X /= VALUE THEN FAILED (); END IF; END SUBTYP_CHK; TYPE VAR_REC_DEF1 (D3 : INTEGER := 1) IS RECORD CASE D3 IS WHEN 1 = C1 : REC (D3, IDENT_INT(11)); WHEN OTHERS = C2 : INTEGER := IDENT_INT(5); END CASE; END RECORD; PROCEDURE PROC3 IS NEW SUBTYP_CHK (VAR_REC_DEF1); BEGIN PROC3 (OBJ_XCP = TRUE, TAG = PROC3); END; END C37213J; -- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-21 19:47:16 date|| Summary|ACATS ICE c37213j c37213l |[4.1 Regression] ACATS ICE |do_structure_copy, at tree- |c37213j c37213l |ssa-structalias.c:2372 |do_structure_copy, at tree- ||ssa-structalias.c:2372 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22140
[Bug tree-optimization/21959] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- 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|Removed |Added
Last reconfirmed|2005-06-08 12:32:26 |2005-06-21 19:49:54
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug tree-optimization/22026] [4.1 Regression] ACATS FAIL C45331A fixed point wrong code (VRP related)
--- 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
[Bug middle-end/19985] [3.4/4.0/4.1 Regression] executables created with -fprofile-arcs -ftest-coverage segfault in gcov_exit ()
--- 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 In file included from ./tm.h:12, from ../../gcc/libgcov.c:39: ../../gcc/defaults.h:712:1: warning: this is the location of the previous definition There are now many warnings of this type during building gcc. This is because auto-host.h is now included, but _after_ all the other headers, which do something like #ifndef BLA #define BLA ... #endif Because auto-host.h is not yet included there, BLA is not defined, so the default will be defined, and then auto-host.h is included leading to double definitions. libgcov.c talks about not able to include config.h because that's for the host, not for the target. So I don't know if auto-host.h (also for the host) should be included at all. But if it is, then it has to be earlier. Perhaps in libgcov.c directly as first file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19985
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- 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 if it exposes this bug. It has become impossible to take out Nathan's patch from mainline, because the code has been worked over again in the meantime. A run through the regression tester may be the best chance to determine which patch broke this. W. - Wolfgang Bangerth email:[EMAIL PROTECTED] www: http://www.ices.utexas.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
Re: [Bug c++/21799] [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 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 if it exposes this bug. It has become impossible to take out Nathan's patch from mainline, because the code has been worked over again in the meantime. A run through the regression tester may be the best chance to determine which patch broke this. It might be easier to try to take it out on the 4.0 branch and easier to run the regression tester there, I don't have time to either because I am looking into the other bug you filed, the seg fault one. -- Pinski
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- 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 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 if it exposes this bug. It has become impossible to take out Nathan's patch from mainline, because the code has been worked over again in the meantime. A run through the regression tester may be the best chance to determine which patch broke this. It might be easier to try to take it out on the 4.0 branch and easier to run the regression tester there, I don't have time to either because I am looking into the other bug you filed, the seg fault one. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- 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 non-members. Conversion operators are unordered wrt other functions. PR c++/19203, implement DR 214 * call.c (joust): Use more_specialized_fn. * cp-tree.h (DEDUCE_ORDER): Remove. (more_specialized): Replace with ... (more_specialized_fn): ... this. * pt.c (maybe_adjust_types_for_deduction): Remove DEDUCE_ORDER case. (type_unification_real): Remove DEDUCE_ORDER case. (more_specialized): Replace with ... (more_specialized_fn): ... this. Implement DR 214. (most_specialized_instantiation): Use get_bindings_real directly. to the 4.0 branch has caused the problem. It may be conjectured that the corresponding patch broke the same thing on mainline. That's bad -- we now have a regression between 4.0.0 and 4.0.1 :-( W. -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Known to work|3.4.0 |3.4.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug c++/19203] [3.4/4.0 Regression] [DR 214] Partial ordering failure between function reference and generic const reference
--- 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
[Bug fortran/22010] Namelists defined in modules not handled properly
--- 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
[Bug tree-optimization/21959] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- 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 -gnatpg -gnata -I- -I. -Iada -I/home/guerby/work/gcc/version-head/gcc/ada /home/guerby/work/gcc/version-head/gcc/ada/ada.ads -o ada/ada.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 is still referenced for some reason after the ggc_free. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 any longer. The FUNCTION_DECL is still referenced for some reason after the ggc_free. In fact commenting out the ggc_free, this works again so it has to be this patch as this is the same as reverting the patch. -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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
[Bug c++/22139] [4.0/4.1 regression] Segfault
--- 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 did to the GC is so we don't have hard to debug problems like this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
[Bug ada/20593] [4.0/4.1 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC
--- 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
[Bug target/20497] Building Code on AMD 64bits c
--- 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 |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20497
[Bug libgcj/6996] gij needs assertion-related command-line options
--- 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 |2005-06-22 00:21:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6996
[Bug target/20569] [ gcc 3.4.3 ] glibc 2.3.4 ldconfig segv when building with -march=pentium-m
--- 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 |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20569
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- 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 branches, my patch might be acceptable there if and only if we decide that Nathan's patch can't be backed up. In which case, Nathan can probably both decide what to do with his patch, and re-review my patch for PR 8271 just for the 4.0 release branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug ada/20593] [4.0/4.1 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC
--- 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 my tree, but never got around to doing anything with it. may I test it and apply it? Sure. It's an obviously-correct change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593
[Bug target/22134] [4.1 Regression] vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
--- 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);
for (i = 0; iw; i++)
{
int u = usrc[i];
int new_u = c*u;
if(new_u 1) new_u= (-new_u)31;
udst[i]= new_u;
}
}
rint is importrant.
-O1 -ffast-math is enough to reproduce this.
--
What|Removed |Added
CC||uros at kss-loka dot si
Status|WAITING |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-06-22 03:53:54
date||
Summary|vf_hue.c:54: internal |[4.1 Regression]
|compiler error: in |vf_hue.c:54: internal
|final_scan_insn, at |compiler error: in
|final.c:2419|final_scan_insn, at
||final.c:2419
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22134
