[Bug tree-optimization/28814] [4.1/4.2 regression] in compare_values, at tree-vrp.c:415
--- Comment #2 from tbm at gcc dot gnu dot org 2006-08-23 07:05 --- Confirmed. Also happens with 4.2. -- tbm at gcc dot gnu dot org changed: What|Removed |Added CC||tbm at cyrius dot com Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-08-23 07:05:53 date|| Summary|ICE when compiling Stalin |[4.1/4.2 regression] in |under 4.1 but not 4.0 |compare_values, at tree- ||vrp.c:415 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28814
[Bug middle-end/28815] gcc-4.2-20060819 failed to compile Linux kernel 2.6.18-rc4-git1
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-23 07:07 --- Yes we need the error message and the preprocessed source and what exact version of GCC you are using and what target you are compiling for. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28815
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #11 from agner at agner dot org 2006-08-23 08:04 --- This problem wouldn't have happened if the ABI had been better maintained. Somebody decides to change the calling convention without properly documenting the change, and somebody else makes another change that is incompatible because the alignment requirement has never made it into the ABI documents. Let me help you making a decision on this issue by summarizing the pro's and con's of 16-bytes stack alignment in 32-bit x86 Linux/BSD. Advantages of enforcing 16-bytes stack alignment: - 1. The use of XMM code is becoming more common now that all new computers have support for the SSE2 or higher instructions set. The necessary alignment of XMM variables can be implemented more efficiently when the stack is aligned. 2. Variables of type double (double precision floating point) are accessed more efficiently when aligned by 8. This is easily achieved when the stack is aligned. 3. Function parameters of type double will automatically get the optimal alignment, unless the parameter is preceded by an odd number of smaller parameters (including any 'this' pointer and return pointer). This means that more than 50% of function parameters of type double will be optimally aligned, versus 50% without stack alignment. The C/C++ programmer will be able to ensure optimal alignment by manipulating the order of function parameters. 4. Functions that need to align local variables can do so without using EBP as stack frame. This frees EBP for other purposes. General purpose registers is a scarce resource in 32-bit mode. 5. 16-bytes stack alignment is officially enforced in Intel-based Mac OS X. It is desirable to have identical ABI's for Linux, BSD and Mac. This makes it possible to use the same compilers and the same function libraries for all three platforms (except for the object file format, which can be converted). 6. The stack alignment requires no extra instructions in leaf functions, which are more likely to contain the critical innermost loop than non-leaf functions. 7. The stack alignment requires no extra instructions in a non-leaf function if the function adjusts the stack pointer anyway for the sake of allocating local storage. 8. Stack alignment is already implemented in Gcc and existing code relies on it. Disadvantages of enforcing 16-bytes stack alignment: 1. A non-leaf function without any stack space allocated for local storage needs one or two extra instructions for conforming to the stack alignment requirement. 2. The alignment requirement results in unused space in the stack. This takes up to 12 bytes of extra space in the data cache for each function calling level except the innermost. Assuming that only the innermost three function levels matter in terms of speed, and that the number of unused bytes is 8 on average for all but the innermost function, the total amount of space wasted in the data cache is 16 bytes. 3. The Intel compiler does not enforce stack alignment. However, the Intel people are ready to change this as soon as you Gnu people make a decision on this issue. I have contact with the Intel people about this issue. 4. Stack alignment is not enforced in 32-bit Windows. Compatibility with the Windows ABI might be desirable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug tree-optimization/28807] [4.2 Regression] wrong code with may_alias and structs
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-23 08:06 ---
(In reply to comment #4)
> This is a hard nut to crack, my *guess* is that if you just check the
> alias set of the type of the access, we are going to end up claiming any
> access to a structure containing a char variable is aliased.
You are correct as we regress with the following testcase:
struct a
{
char a1;
};
int *aa;
void g(int *a)
{
aa = a;
*a = 2;
}
int t(int i, struct a *b)
{
g(&i);
b->a1 = 1;
i = 2;
if (b->a1 != 1)
link_failure ();
}
int main(void)
{
struct a b;
t(1, &b);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug tree-optimization/28807] [4.2 Regression] wrong code with may_alias and structs
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-23 08:11 ---
This patch fixes the problem without causing the missed optimization to
happen:Index: tree-ssa-operands.c
===
--- tree-ssa-operands.c (revision 116342)
+++ tree-ssa-operands.c (working copy)
@@ -1150,7 +1150,8 @@ access_can_touch_variable (tree ref, tre
|| TREE_CODE (TREE_TYPE (base)) != UNION_TYPE)
&& !AGGREGATE_TYPE_P (TREE_TYPE (alias))
&& TREE_CODE (TREE_TYPE (alias)) != COMPLEX_TYPE
- && !POINTER_TYPE_P (TREE_TYPE (alias)))
+ && !POINTER_TYPE_P (TREE_TYPE (alias))
+ && get_alias_set (base))
{
#ifdef ACCESS_DEBUGGING
fprintf (stderr, "Access to ");
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug tree-optimization/28814] [4.1/4.2 regression] in compare_values, at tree-vrp.c:415
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-23 08:12 --- Reducing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28814
[Bug fortran/28817] New: [gfortran] problems with -Wunused
The following code causes current mainline gfortran to produce warnings about unused variables that are somewhat confused. module test contains subroutine sub1 (arg1) integer arg1 integer var1 end subroutine subroutine sub2 (arg2) integer arg2 integer var2 call something(arg2) end subroutine end module test [EMAIL PROTECTED]:~/tmp> gfortran -c -Wunused test.f90 test.f90: In function sub2: test.f90:4: warning: unused variable var2 test.f90: In function sub1: test.f90:12: warning: unused variable arg1 test.f90:12: warning: unused variable var1 The diagnostics appear in the wrong order, and the line numbers are confused. This is most likely related to (or identical with) PR21918. -- Summary: [gfortran] problems with -Wunused Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28817
[Bug fortran/28813] gfortran.dg/direct_io_6.f90 can exhaust system disk space
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-08-23 08:28 --- Jerry, Yes. I filed the bug report after my wife lost a bunch of open word processing documents when Word crashed while the direct_io_6 test was executing in the background under MacOS X. I suspect this problem may occur with other operating systems and applications as well. This probably is the only gcc testsuite test that is certain to exhaust the available diskspace. Isn't there someway to check for available disk space within fortran? Normally when this test is executing on an idle machine, the test silently fails. However, on MacOS X at least, if you are actively using the browser or other applications, an alert comes up reporting that the disk is full. So it definitely is an issue under MacOS X. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28813
[Bug libgcj/28698] [gcj] libgcj-bc only used when building shared libs, not executables
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-08-23 09:20 --- There seems to be a mismatch in the installation of the unversioned libgcj_bc.so in the fc rpm and the trunk. On the trunk, this library is created using $(libgcj_bc_dummy_LINK) -xc /dev/null -Wl,-soname,libgcj_bc.so.1 \ -o $(DESTDIR)$(toolexeclibdir)/libgcj_bc.so.1.0.0 -lgcj where libgcj is the real libgcj.so, while in the spec file, a dummy libgcj.so is created first. mkdir libgcj_bc gcc/xgcc -B gcc/ $OPT_FLAGS $LIBGCJ_BC_CFLAGS -shared -fpic -xc /dev/null \ -o libgcj_bc/libgcj.so -Wl,-soname,libgcj.so.7rh -nostdlib gcc/xgcc -B gcc/ $OPT_FLAGS $LIBGCJ_BC_CFLAGS -shared -fpic ../libjava/libgcj_bc.c \ -o libgcj_bc/libgcj_bc.so -Wl,-soname,libgcj_bc.so.1 libgcj_bc/libgcj.so -shared-libgcc Although that code seems to be called for the biarch case only. The ldd on libgcj.so shows the dependency on the real libgcj on the trunk, no dependency with the code from the spec file. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28698
[Bug tree-optimization/28814] [4.1/4.2 regression] in compare_values, at tree-vrp.c:415
--- Comment #4 from tbm at gcc dot gnu dot org 2006-08-23 09:38 ---
Reduced testcase:
struct w49
{
union
{
}
value;
};
f9887 (struct w49 a23040)
{
unsigned r9887;
if (((struct structure_type24753 *) (r9887 - 1)) == ((void *) 0))
{
backtrace ("stalin.sc", 7222, 248274);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28814
[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #4 from doko at ubuntu dot com 2006-08-23 10:20 --- I see the problem with stlport 4.6.2: - stlport is built on a glibc-2.3 based system (using g++-4.0) - libstdc++/g++-4.1 is built on a glibc-2.4 based system - building the stlport regression tests using the installed stlport and libstdc++: c++ -pthread -Wall -I/usr/include/stlport -I. -g stl_test.o accum1.o accum2.o adjdiff0.o adjdiff1.o adjdiff2.o adjfind0.o adjfind1.o adjfind2.o advance.o alg 1.o alg2.o alg3.o alg4.o alg5.o bcompos1.o bcompos2.o bind1st1.o bind1st2.o bind2nd1.o bind2nd2.o binsert1.o binsert2.o binsrch1.o binsrch2.o bnegate1.o bnegate 2.o bvec1.o copy1.o copy2.o copy3.o copy4.o copyb.o copyb0.o count0.o count1.o countif1.o deque1.o divides.o eqlrnge0.o eqlrnge1.o eqlrnge2.o equal0.o equal1.o equal2.o equalto.o fill1.o filln1.o find0.o find1.o findif0.o findif1.o finsert1.o finsert2.o foreach0.o foreach1.o func1.o func2.o func3.o gener1.o gener2.o ge nern1.o genern2.o greateq.o greater.o incl0.o incl1.o incl2.o inplmrg1.o inplmrg2.o inrprod0.o inrprod1.o inrprod2.o insert1.o insert2.o iota1.o istmit1.o iter1 .o iter2.o iter3.o iter4.o iterswp0.o iterswp1.o less.o lesseq.o lexcmp1.o lexcmp2.o list1.o list2.o list3.o list4.o logicand.o logicnot.o logicor.o lwrbnd1.o l wrbnd2.o map1.o max1.o max2.o maxelem1.o maxelem2.o memfunptr.o merge0.o merge1.o merge2.o min1.o min2.o minelem1.o minelem2.o minus.o mismtch0.o mismtch1.o mis mtch2.o mkheap0.o mkheap1.o mmap1.o mmap2.o modulus.o mset1.o mset3.o mset4.o mset5.o negate.o nequal.o nextprm0.o nextprm1.o nextprm2.o nthelem0.o nthelem1.o n thelem2.o ostmit.o pair0.o pair1.o pair2.o parsrt0.o parsrt1.o parsrt2.o parsrtc0.o parsrtc1.o parsrtc2.o partsrt0.o partsum0.o partsum1.o partsum2.o pheap1.o p heap2.o plus.o pqueue1.o prevprm0.o prevprm1.o prevprm2.o ptition0.o ptition1.o ptrbinf1.o ptrbinf2.o ptrunf1.o ptrunf2.o queue1.o rawiter.o remcopy1.o remcpif1 .o remif1.o remove1.o repcpif1.o replace0.o replace1.o replcpy1.o replif1.o revbit1.o revbit2.o revcopy1.o reverse1.o reviter1.o reviter2.o rndshuf0.o rndshuf1. o rndshuf2.o rotate0.o rotate1.o rotcopy0.o rotcopy1.o search0.o search1.o search2.o set1.o set2.o setdiff0.o setdiff1.o setdiff2.o setintr0.o setintr1.o setint r2.o setsymd0.o setsymd1.o setsymd2.o setunon0.o setunon1.o setunon2.o sort1.o sort2.o stack1.o stack2.o stblptn0.o stblptn1.o stblsrt1.o stblsrt2.o swap1.o swp rnge1.o times.o trnsfrm1.o trnsfrm2.o ucompos1.o ucompos2.o unegate1.o unegate2.o uniqcpy1.o uniqcpy2.o unique1.o unique2.o uprbnd1.o uprbnd2.o vec1.o vec2.o ve c3.o vec4.o vec5.o vec6.o vec7.o vec8.o hmmap1.o hset2.o hmset1.o slist1.o hmap1.o string1.o bitset1.o -lstlport_gcc -lm -o stl_test.exe stl_test.o: In function `main': /home/doko/tmp/stlport4.6-4.6.2/test/regression/stl_test.cpp:493: undefined reference to `string_mt_test(int, char**)' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make: *** [stl_test.out] Error 1 I've put the subdirectory including the stlport shared libraries at http://people.ubuntu.com/~doko/stlport-regresssion-dir.tar.bz2 -- doko at ubuntu dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug tree-optimization/28814] [4.1/4.2 regression] in compare_values, at tree-vrp.c:415
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-08-23 10:26 --- We have mismatched types coming into #4 0x086244c4 in vrp_evaluate_conditional (cond=0xb7d2b168, use_equiv_p=1 '\001') at /space/rguenther/src/svn/sse-revert/gcc/tree-vrp.c:3717 3717return compare_name_with_value (TREE_CODE (cond), op0, op1); (gdb) call debug_tree (cond) unit size align 8 symtab 0 alias set -1 precision 1 min max > arg 0 unit size align 32 symtab 0 alias set -1 precision 32 min max > visited var def_stmt version 1> arg 1 constant invariant 1> t.i:11> #5 0x0821544f in fold_predicate_in (stmt=0xb7d330c8) at /space/rguenther/src/svn/sse-revert/gcc/tree-ssa-propagate.c:1045 1045 val = vrp_evaluate_conditional (*pred_p, true); (gdb) call debug_generic_expr (stmt) if (r9887D.1606_1 == 1B) goto ; else goto ; which fold produces here: /* If this is an EQ or NE comparison of a constant with a PLUS_EXPR or a MINUS_EXPR of a constant, we can convert it into a comparison with a revised constant as long as no overflow occurs. */ if (TREE_CODE (arg1) == INTEGER_CST && (TREE_CODE (arg0) == PLUS_EXPR || TREE_CODE (arg0) == MINUS_EXPR) && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST && 0 != (tem = const_binop (TREE_CODE (arg0) == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR, arg1, TREE_OPERAND (arg0, 1), 0)) && ! TREE_CONSTANT_OVERFLOW (tem)) return fold_build2 (code, type, TREE_OPERAND (arg0, 0), tem); tem is of pointer type, but arg0 is of type unsigned int. I have a fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-23 07:05:53 |2006-08-23 10:26:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28814
[Bug target/27827] [4.0 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #68 from oliver dot jennrich at googlemail dot com 2006-08-23 10:36 --- (In reply to comment #23) I read the discussion with a lot of interest - so here are the data for a Pentium-M: echo "GCC 3.x double performance:" GCC 3.x double performance: ./xdmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.281 1537.37 echo "GCC 4.x double performance:" GCC 4.x double performance: ./xdmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.265 1630.19 echo "GCC 3.x single performance:" GCC 3.x single performance: ./xsmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.281 1537.37 echo "GCC 4.x single performance:" GCC 4.x single performance: ./xsmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.266 1624.06 > Here is the machine breakdown as measured now: >LIKES GCC 4DOESN'T CARELIKES GCC 3 >====== >CoreDuoPentium 4 PentiumPRO > Pentium III > Pentium 4e > Pentium D > Athlon-64 X2 > Opteron So I guess the first column gets another entry: Pentium M -- oliver dot jennrich at googlemail dot com changed: What|Removed |Added CC||oliver dot jennrich at ||googlemail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c/28418] [4.0/4.1/4.2 regression] ICE incrementing compound literal expression
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-08-23 11:23 --- The patch in comment#3 is OK if the testcase is added to gcc.c-torture/compile. Please post the final patch to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug fortran/28818] New: C/Fortran interoperability: variable number of arguments passed from fortran to C causes Illegal instruction
With svn revision 116324, on x86_64-unknown-linux-gnu:
[EMAIL PROTECTED]:~]$ cat test.c
#include
#include
void test_(int *test, ...)
{
printf("test: %d\n", *test);
return;
}
[EMAIL PROTECTED]:~]$ cat forttest.F90
program test_printf
call test(-1, 'd')
call test(-1, 'd')
end program test_printf
[EMAIL PROTECTED]:~]$ make
gcc -c -o test.o test.c
gfortran -c -o forttest.o forttest.F90
gfortran -o test test.o forttest.o
[EMAIL PROTECTED]:~]$ ./test
test: -1
Illegal instruction
[EMAIL PROTECTED]:~]$
This does not happen if
void test_(int *test, ...)
is replaced with
void test_(int *test, char *d)
so it appears there's something wrong with variable numbers of arguments being
passed between fortran and C.
Here's what gdb says:
Breakpoint 1, test_ (test=0x400878) at test.c:6
6 printf("test: %d\n", *test);
(gdb) n
test: -1
8 }
(gdb) nexti
0x0040070e in test_ (test=0x400874) at test.c:8
8 }
(gdb) nexti
MAIN__ () at forttest.F90:4
4 call test(-1, 'd')
Current language: auto; currently fortran
(gdb) nexti
0x00400741 4 call test(-1, 'd')
(gdb) nexti
0x00400746 4 call test(-1, 'd')
(gdb) nexti
0x0040074b 4 call test(-1, 'd')
(gdb) nexti
Program received signal SIGILL, Illegal instruction.
0x004006ca in test_ (test=0x400878) at test.c:5
5 {
Current language: auto; currently c
(gdb)
but I don't know enough about assembly to help any more.
--
Summary: C/Fortran interoperability: variable number of arguments
passed from fortran to C causes Illegal instruction
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cyan+gcc at compsoc dot nuigalway dot ie
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28818
[Bug libgcj/24798] classmap.db should reside in /var/lib/gcj/
--- Comment #2 from gbenson at redhat dot com 2006-08-23 12:33 --- Note that aot-compile-rpm uses the output of gcj-dbtool -p to figure out where to install the libraries (ie /usr/lib or /usr/lib64). aot-compile-rpm will start putting them in the wrong place if the default location is changed without also fixing aot-compile-rpm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24798
[Bug c++/28819] New: gcc requires infinite memory when compiling code snippet
The following code snippet:
#include
struct A { std::vector a;};
template struct B { C c[33]; };
struct Boom { B > > > s; };
seems to make GCC to allocate huge amounts of memory:
$ gcc x.cpp
virtual memory exhausted: Cannot allocate memory
(virtual memory is limited by ulimit to 1GB)
$ gcc --version
gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: gcc requires infinite memory when compiling code snippet
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sunny at beamfile dot com
GCC host triplet: Linux 2.6
GCC target triplet: Linux 2.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28819
Re: [Bug c/28768] [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly?
pinskia at gcc dot gnu dot org wrote:- > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 05:11 > --- > Confirmed, a regression from 3.3.3. Rather, intended behaviour since 3.3.3. Neil.
[Bug c/28768] [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly?
--- Comment #6 from neil at daikokuya dot co dot uk 2006-08-23 13:16 --- Subject: Re: [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly? pinskia at gcc dot gnu dot org wrote:- > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 05:11 > --- > Confirmed, a regression from 3.3.3. Rather, intended behaviour since 3.3.3. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28768
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-23 13:20 --- Created an attachment (id=12117) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12117&action=view) Fix for this and Martin Tee's submission to the list Martin, I would be very grateful if you would test this patch to see if it fixes your problem "in the flesh". It is just now regression testing and I will run the tonto and Polyhedron testsuites before submitting it. Thanks for coming back with the problem so quickly. Whilst I was willing to be surprised, I did expect some fall-out from the derived type reform. Sorry for any inconvenience. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #4 from hosking at cs dot purdue dot edu 2006-08-23 13:40 --- Here is a stack trace showing call to resize_phi_node from execute_pre. #0 resize_phi_node (phi=0x42580028, len=9) at ../../gcc/gcc/tree-phinodes.c:271 #1 0x001415e8 in reserve_phi_args_for_new_edge (bb=0x4258) at ../../gcc/gcc/tree-phinodes.c:325 #2 0x001fd8b0 in unchecked_make_edge (src=0x425885a0, dst=0x4258, flags=1113063428) at ../../gcc/gcc/cfg.c:272 #3 0x002414fc in tree_split_edge (edge_in=0x424a12d0) at ../../gcc/gcc/tree-cfg.c:3117 #4 0x00261bcc in split_edge (e=0x4257ebe0) at ../../gcc/gcc/cfghooks.c:407 #5 0x002445b8 in tree_find_edge_insert_loc (e=0x424a12d0, bsi=0xbfffeca8, new_bb=0x0) at ../../gcc/gcc/tree-cfg.c:2975 #6 0x00244764 in bsi_commit_one_edge_insert (e=0x42580028, new_bb=0x9) at ../../gcc/gcc/tree-cfg.c:3016 #7 0x002466c8 in bsi_commit_edge_inserts () at ../../gcc/gcc/tree-cfg.c:2997 #8 0x00344098 in execute_pre (do_fre=0 '\0') at ../../gcc/gcc/tree-ssa-pre.c:2731 #9 0x002260b8 in execute_one_pass (pass=0x4ed660) at ../../gcc/gcc/passes.c:827 #10 0x00226188 in execute_pass_list (pass=0x4ed660) at ../../gcc/gcc/passes.c:859 #11 0x002261a0 in execute_pass_list (pass=0x4ec21c) at ../../gcc/gcc/passes.c:860 #12 0x00153fa4 in tree_rest_of_compilation (fndecl=0x42443580) at ../../gcc/gcc/tree-optimize.c:419 #13 0x497c in m3_expand_function (fndecl=0x42443580) at ../../gcc/gcc/m3cg/parse.c:848 #14 0x00052784 in cgraph_expand_function (node=0x424501c0) at ../../gcc/gcc/cgraphunit.c:1055 #15 0x00052fc8 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1121 #16 0x000130c0 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/parse.c:4397 #17 0x00036674 in toplev_main (argc=1079409344, argv=0x40567bcc) at ../../gcc/gcc/toplev.c:991 #18 0x1f24 in _start (argc=6, argv=0xb214, envp=0xb230) at /SourceCache/Csu/Csu-58.1.1/crt.c:272 #19 0x1dcc in start () The phi node that gets resized (and replaced in its bb) is later attempted to be deleted, at the following point: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x00141ca8 in remove_phi_node (phi=0x42577800, prev=0x0) at ../../gcc/gcc/tree-phinodes.c:454 (gdb) where #0 0x00141ca8 in remove_phi_node (phi=0x42577800, prev=0x0) at ../../gcc/gcc/tree-phinodes.c:454 #1 0x00341aac in remove_dead_inserted_code () at ../../gcc/gcc/tree-ssa-pre.c:2547 #2 0x003440a0 in execute_pre (do_fre=0 '\0') at ../../gcc/gcc/tree-ssa-pre.c:2733 #3 0x002260b8 in execute_one_pass (pass=0x4ed660) at ../../gcc/gcc/passes.c:827 #4 0x00226188 in execute_pass_list (pass=0x4ed660) at ../../gcc/gcc/passes.c:859 #5 0x002261a0 in execute_pass_list (pass=0x4ec21c) at ../../gcc/gcc/passes.c:860 #6 0x00153fa4 in tree_rest_of_compilation (fndecl=0x42443580) at ../../gcc/gcc/tree-optimize.c:419 #7 0x497c in m3_expand_function (fndecl=0x42443580) at ../../gcc/gcc/m3cg/parse.c:848 #8 0x00052784 in cgraph_expand_function (node=0x424501c0) at ../../gcc/gcc/cgraphunit.c:1055 #9 0x00052fc8 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1121 #10 0x000130c0 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/parse.c:4397 #11 0x00036674 in toplev_main (argc=1079409344, argv=0x40567bcc) at ../../gcc/gcc/toplev.c:991 #12 0x1f24 in _start (argc=6, argv=0xb214, envp=0xb230) at /SourceCache/Csu/Csu-58.1.1/crt.c:272 #13 0x1dcc in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #18 from jason at gcc dot gnu dot org 2006-08-23 14:04 --- Subject: Bug 28687 Author: jason Date: Wed Aug 23 14:04:24 2006 New Revision: 116350 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116350 Log: PR c++/28687 * rtti.c (build_dynamic_cast, build_dynamic_cast_1): Move -fno-rtti check to be more specific. Added: trunk/gcc/testsuite/g++.dg/rtti/no-rtti-voidptr.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/28820] New: sizeof == 0 for empty class
class A
{
public:
int a[0];
};
int main()
{
A a;
int size1 = sizeof(A); // == 0, should be nonzero
int size2 = sizeof(a); // == 0, should be nonzero
}
Since: ISO 14882-2003, 9 [Classes].3
Thanks,
--
Summary: sizeof == 0 for empty class
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jz201115 at zodiac dot mimuw dot edu dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28820
[Bug middle-end/28814] [4.1/4.2 regression] in compare_values, at tree-vrp.c:415
--- Comment #6 from patchapp at dberlin dot org 2006-08-23 14:16 --- Subject: Bug number PR28814 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-08/msg00830.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28814
[Bug middle-end/28683] [4.0/4.1/4.2 regression] ICE (segfault in add_reg_br_prob_note) when comparing pointers with -O (and higher)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-10 19:37:19 |2006-08-23 14:18:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28683
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #39 from jason at gcc dot gnu dot org 2006-08-23 14:22 --- Subject: Bug 23372 Author: jason Date: Wed Aug 23 14:22:41 2006 New Revision: 116351 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116351 Log: PR c++/23372 * call.c (build_over_call): Don't make a copy here if build_call will make one too. Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/call.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #40 from jason at gcc dot gnu dot org 2006-08-23 14:22 --- Subject: Bug 23372 Author: jason Date: Wed Aug 23 14:22:49 2006 New Revision: 116352 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116352 Log: PR c++/23372 * call.c (build_over_call): Don't make a copy here if build_call will make one too. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/call.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #19 from benjamin at smedbergs dot us 2006-08-23 14:23 --- Fixed on trunk for 4.2 -- benjamin at smedbergs dot us changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #41 from jason at gcc dot gnu dot org 2006-08-23 14:33 --- fixed in 4.0 and 4.1 as well. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #4 from patchapp at dberlin dot org 2006-08-23 14:51 --- Subject: Bug number PR28788 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-08/msg00831.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug c/28821] New: Unable to build Python
There are two problems:
1.) Unsatisfied code symbol '__cxa_finalize' in load module
gcc-4.1.0 compiles __cxa_finalize into shared libs as weak symbol
(4611686018427425864| 4|FUNC |WEAK |0| .text|__cxa_finalize), gcc-4.1.1
doesn't (0| 0|FUNC |GLOB |0| UNDEF|__cxa_finalize). That's a problem
for Python because it loads modules at runtime.
To solve this problem John David Anglin suggested the following patch which
forces the linkage of __cxa_finalize into main:
Index: config/pa/pa64-hpux.h
===
--- config/pa/pa64-hpux.h (revision 115902)
+++ config/pa/pa64-hpux.h (working copy)
@@ -33,7 +33,8 @@
%{!shared:%{pg:-L/lib/pa20_64/libp -L/usr/lib/pa20_64/libp %{!static:\
%nWarning: consider linking with `-static' as system libraries with\n\
%n profiling support are only provided in archive format}}}\
- %{mhp-ld:+Accept TypeMismatch -z} -E %{mlinker-opt:-O} %{!shared:-u main}\
+ %{mhp-ld:+Accept TypeMismatch -z} -E %{mlinker-opt:-O}\
+ %{!shared:-u main %{!nostdlib:%{!nodefaultlibs:-u __cxa_finalize}}}\
%{static:-a archive} %{shared:%{mhp-ld:-b}%{!mhp-ld:-shared}}"
#else
#define LINK_SPEC \
@@ -43,7 +44,8 @@
%{!shared:%{pg:-L/lib/pa20_64/libp -L/usr/lib/pa20_64/libp %{!static:\
%nWarning: consider linking with `-static' as system libraries with\n\
%n profiling support are only provided in archive format}}}\
- %{!mgnu-ld:+Accept TypeMismatch -z} -E %{mlinker-opt:-O} %{!shared:-u
main}\
+ %{!mgnu-ld:+Accept TypeMismatch -z} -E %{mlinker-opt:-O}\
+ %{!shared:-u main %{!nostdlib:%{!nodefaultlibs:-u __cxa_finalize}}}\
%{static:-a archive} %{shared:%{mgnu-ld:-shared}%{!mgnu-ld:-b}}"
#endif
2.) python aborts on exit
__deregister_frame_info_bases aborts at the gcc_assert here:
__gthread_mutex_unlock (&object_mutex);
gcc_assert (ob);
I try to debug this a little bit further.
--
Summary: Unable to build Python
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim dot com
GCC build triplet: hppa64-hp-hpux11.00
GCC host triplet: hppa64-hp-hpux11.00
GCC target triplet: hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28821
[Bug c++/28820] sizeof == 0 for empty class
--- Comment #1 from bangerth at dealii dot org 2006-08-23 15:01 --- (In reply to comment #0) >int size1 = sizeof(A); // == 0, should be nonzero >int size2 = sizeof(a); // == 0, should be nonzero What makes you think so? > Since: ISO 14882-2003, 9 [Classes].3 I don't quite know which section you refer to. Can you elaborate? Thanks W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28820
[Bug c++/28819] gcc requires infinite memory when compiling code snippet
--- Comment #1 from bangerth at dealii dot org 2006-08-23 15:08 --- I can confirm that it takes g++ 3.3: 1.5 seconds gcc 3.4: 18.6 seconds gcc 4.0: 13.2 seconds However, gcc4.1 is back down to 0.5 seconds to compile this and presumably takes a lot less memory as well. So this is fixed. For the record, you ask the compiler to lay out a type that takes up about 25.5MB of data... W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28819
[Bug c++/28820] sizeof == 0 for empty class
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-23 15:14 --- First this: int a[0]; is an extension on top of the C++ standard which means to allocate nothing so you can use malloc to allocate more than is needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28820
Re: [Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
On Wed, 2006-08-23 at 13:40 +, hosking at cs dot purdue dot edu wrote: > > --- Comment #4 from hosking at cs dot purdue dot edu 2006-08-23 13:40 > --- > Here is a stack trace showing call to resize_phi_node from execute_pre. Do you have a testcase or is this with a modified compiler? -- Pinski
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #5 from pinskia at gmail dot com 2006-08-23 15:16 --- Subject: Re: remove_phi_node attempts removal of a phi node resized by resize_phi_node On Wed, 2006-08-23 at 13:40 +, hosking at cs dot purdue dot edu wrote: > > --- Comment #4 from hosking at cs dot purdue dot edu 2006-08-23 13:40 > --- > Here is a stack trace showing call to resize_phi_node from execute_pre. Do you have a testcase or is this with a modified compiler? -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug fortran/28818] C/Fortran interoperability: variable number of arguments passed from fortran to C causes Illegal instruction
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-23 15:18 --- Technicially this is not a bug because C/Fortran interoperability is undefined. For Fortran 2003, there is a way to interopere between the two langauges but I don't think var_args are supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28818
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-08-23 15:20 --- As far as I can see, the only reason why we can have a REG_EH_REGION note on a non-call instruction is when the instruction may trap, and we compile with -fnon-call-exceptions. (In reply to comment #3) > Here is a workaround. Although it doesn't solve the issue > completely, it'd be better than nothing. It prevents to > insert the mode switching code after the last insn of BB > when that insn has the REG_EH_REGION note. I think you can get an incorect mode this way, when the fall-thorough path is supposed to have a different mode than the abnormal edge destination. In fact, if the modes were the same, and not in conflict with the last insn of the source BB, LCM would be expected to place the mode switch into the source block or even earlier in the flow graph. I think the only sane way to handle this is not to emit any mode switching code for exception edges at the potential trapping site, and make the exception handling code assume no particular mode is present (unless the compiler can prove that an exception handler can only be reached from throwing/trapping sites that all have the same mode). > It also checks > if the last insn needs a mode which doesn't match with > the mode given by the mode switching code in such case. If HONOR_SNANS of flag_trapping_math is active together with -fnon-call-exceptions, such problems can be expected for floating point operations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug c++/28820] sizeof == 0 for empty class
--- Comment #3 from pluto at agmk dot net 2006-08-23 15:59 --- (In reply to comment #1) > (In reply to comment #0) > >int size1 = sizeof(A); // == 0, should be nonzero > >int size2 = sizeof(a); // == 0, should be nonzero > > What makes you think so? > > > Since: ISO 14882-2003, 9 [Classes].3 > > I don't quite know which section you refer to. Can you elaborate? $9.3: "Complete objects and member subobjects of class type shall have nonzero size. (...)" -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28820
[Bug libgcj/28698] [gcj] libgcj-bc only used when building shared libs, not executables
--- Comment #7 from tromey at gcc dot gnu dot org 2006-08-23 16:58 --- There's some kind of skew here... I took the code on the trunk from the RH 4.1 branch, not from the FC RPM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28698
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-23 18:12 --- (In reply to comment #5) > Do you have a testcase or is this with a modified compiler? PS I delete private emails about bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug middle-end/28683] [4.0/4.1/4.2 regression] ICE (segfault in add_reg_br_prob_note) when comparing pointers with -O (and higher)
--- Comment #3 from patchapp at dberlin dot org 2006-08-23 18:16 --- Subject: Bug number PR middle-end/28683 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-08/msg00836.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28683
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #17 from tbm at gcc dot gnu dot org 2006-08-23 18:53 --- (In reply to comment #16) > Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' > undeclared > > I'll try to get around it as soon as I can. Thanks. It has been a month... would be nice if you could look at it soon. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-23 18:53:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #10 from tbm at gcc dot gnu dot org 2006-08-23 18:56 --- (In reply to comment #9) > > Jim, were you going to check this in or did you need some more testing on > > it? > > I haven't had time to test it yet. Any update on this, Jim? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug c/28823] New: sizeof not handled by pre-processor in #if statement
The following code:
#define EMS_SYSTEM_NUM 12
#define EMS_INET_NUM 12
#define EMS_SUBSYS_NUM 2
typedef struct _ercb {
struct _ercb *ercb_next;
struct _ercb *ercb_prev;
short ercb_did;
short ercb_pad;
} ems_rcb_t;
typedef struct {
ems_rcb_t *era_rcbp;
unsignedera_ecount; /* event count */
unsignedera_bcount; /* byte count */
} ems_era_elem_t;
static ems_era_elem_t ems_system[EMS_SYSTEM_NUM];
static ems_era_elem_t ems_inet[EMS_INET_NUM];
static ems_era_elem_t *ems_erm[] = {ems_system, ems_inet};
#if (sizeof(ems_erm) / sizeof(ems_era_elem_t *) != EMS_SUBSYS_NUM)
#error "EMS registration matrix not up to date"
#endif
main()
{
}
Compiled with the following command:
gcc -c testcase.c
Produces the following error:
testcase.c:22:12: error: missing binary operator before token "("
Where line 22 is the #if and the second ( is the 12th character. The problem
appears to be that the #if is parsing the line before the sizeof() is resolved
to its manifest constant. This causes the parser to treat "sizeof" as a term
and therefore to want a binary operator prior to the next term (in this case,
the open paren). The fix is to resolve the sizeof first. I tried creating a
#define for the sizeof() and replacing the defined value in the #if, but that
produced exactly the same error.
--
Summary: sizeof not handled by pre-processor in #if statement
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gmalkin at convergedaccess dot com
GCC build triplet: 4.1.1 20060525 (Red Hat 4.1.1-1)
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28823
[Bug c/28823] sizeof not handled by pre-processor in #if statement
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-23 19:18 --- sizeof is not part of the preprocessor. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28823
[Bug c++/28642] [4.0/4.1/4.2 Regression] ICE in layout_type, at stor-layout.c:1851
--- Comment #4 from jakub at gcc dot gnu dot org 2006-08-23 20:43 --- This seems to be a C++ FE bug: debug_tree (*decl) > VOID file a.C line 3 align 1 offset_align 1> shouldn't be passed to decl_attributes in generic code. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28642
[Bug other/28824] New: "no multiarch mapping for multilib" should be an error, not an ICE
The following should lead to a normal error message, not an ICE:
7910:[EMAIL PROTECTED]: ~/tmp/src] gcc -imultilib t.c
cc1: internal compiler error: no multiarch mapping for multilib (t.c)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
zsh: exit 1 gcc -imultilib t.c
7911:[EMAIL PROTECTED]: ~/tmp/src] cat t.c
int main() {
}
7912:[EMAIL PROTECTED]: ~/tmp/src]
--
Summary: "no multiarch mapping for multilib" should be an error,
not an ICE
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
[Bug c/28823] sizeof not handled by pre-processor in #if statement
--- Comment #2 from gmalkin at convergedaccess dot com 2006-08-23 21:17 --- Okay, so sizeof isn't part of the pre-processor. That doesn't change the fact that the #if as written in the code SHOULD be valid (by every C spec I've looked at). Something in gcc is not doing the right thing. Don't just close the bug because I made a mistake describing it; it's still a bug! -- gmalkin at convergedaccess dot com changed: What|Removed |Added CC||gmalkin at convergedaccess ||dot com Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28823
[Bug c/28823] sizeof not handled by pre-processor in #if statement
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-23 21:22 --- (In reply to comment #2) > Okay, so sizeof isn't part of the pre-processor. That doesn't change the fact > that the #if as written in the code SHOULD be valid (by every C spec I've > looked at). Something in gcc is not doing the right thing. Don't just close > the bug because I made a mistake describing it; it's still a bug! What spec are you reading? The preprocessor acts way before parsing/semantic anylsis happens. This is not a bug as the C preprocessor does not anything about types or any semantics of C, just themself. Even ICC rejects this code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28823
[Bug target/28825] New: return (vector float) { a, a, b, b } generates unwanted MMX insns
X-Bugzilla-Reason: CC
+++ This bug was initially created as a clone of Bug #24073 +++
Take the following example:
#define vector __attribute__((vector_size(16)))
float a; float b;
vector float f(void) { return (vector float){ a, b, 0.0, 0.0}; }
---
Currently we get:
subl$12, %esp
movss _b, %xmm0
movss _a, %xmm1
unpcklps%xmm0, %xmm1
movaps %xmm1, %xmm0
xorl%eax, %eax
xorl%edx, %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
xorps %xmm1, %xmm1
movlhps %xmm1, %xmm0
addl$12, %esp
--
We should be able to produce:
movss _b, %xmm0
movss _a, %xmm1
shufps 60, /*[0, 3, 3, 0]*/, %xmm1, %xmm0 // _a, 0, 0, _b
shufps 201, /*[3, 0, 2, 1]*/, %xmm0, %xmm0 // _a, _b, 0, 0
This is from Nathan Begeman.
--- Comment #4 From Uros Bizjak 2005-09-27 11:41 ---
I think that following example wins the contest:
vector float f(void) { return (vector float){ a, a, b, b}; }
gcc -O2 -msse -fomit-frame-pointer
subl$28, %esp
movss a, %xmm0
movss %xmm0, 4(%esp)
movss b, %xmm0
movd4(%esp), %mm0
punpckldq %mm0, %mm0
movss %xmm0, 4(%esp)
movq%mm0, 16(%esp)
movd4(%esp), %mm0
punpckldq %mm0, %mm0
movq%mm0, 8(%esp)
movlps 16(%esp), %xmm1
movhps 8(%esp), %xmm1
addl$28, %esp
movaps %xmm1, %xmm0
ret
Note the usage of MMX registers.
--- Comment #5 From Andrew Pinski 2005-09-27 14:33 ---
(In reply to comment #4)
> I think that following example wins the contest:
>
> vector float f(void) { return (vector float){ a, a, b, b}; }
For this, it is a different bug. The issue with the above is that
ix86_expand_vector_init_duplicate check
for mmx_okay is bad.
Currently, we have
if (!mmx_ok && !TARGET_SSE)
but I if I change it to:
if (!mmx_ok)
we get:
movss _a, %xmm0
movss _b, %xmm1
unpcklps%xmm0, %xmm0
unpcklps%xmm1, %xmm1
movlhps %xmm1, %xmm0
Which looks ok to me. That testcase should be opened into another bug as it is
obviously wrong.
=
Cloned from 24073 to track the MMX insn issue; the original 24073 problem is a
performance issue.
--
Summary: return (vector float) { a, a, b, b } generates unwanted
MMX insns
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
GCC target triplet: i786-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28825
[Bug target/24073] (vector float){a, b, 0, 0} code gen is not good
--- Comment #6 from stuart at apple dot com 2006-08-23 21:24 --- Cloned 28825 from this bug to track the MMX instruction issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24073
[Bug target/28826] New: return (vector float) { a, a, b, b } generates unwanted MMX insns
X-Bugzilla-Reason: CC
+++ This bug was initially created as a clone of Bug #24073 +++
Take the following example:
#define vector __attribute__((vector_size(16)))
float a; float b;
vector float f(void) { return (vector float){ a, b, 0.0, 0.0}; }
---
Currently we get:
subl$12, %esp
movss _b, %xmm0
movss _a, %xmm1
unpcklps%xmm0, %xmm1
movaps %xmm1, %xmm0
xorl%eax, %eax
xorl%edx, %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
xorps %xmm1, %xmm1
movlhps %xmm1, %xmm0
addl$12, %esp
--
We should be able to produce:
movss _b, %xmm0
movss _a, %xmm1
shufps 60, /*[0, 3, 3, 0]*/, %xmm1, %xmm0 // _a, 0, 0, _b
shufps 201, /*[3, 0, 2, 1]*/, %xmm0, %xmm0 // _a, _b, 0, 0
This is from Nathan Begeman.
--- Comment #4 From Uros Bizjak 2005-09-27 11:41 ---
I think that following example wins the contest:
vector float f(void) { return (vector float){ a, a, b, b}; }
gcc -O2 -msse -fomit-frame-pointer
subl$28, %esp
movss a, %xmm0
movss %xmm0, 4(%esp)
movss b, %xmm0
movd4(%esp), %mm0
punpckldq %mm0, %mm0
movss %xmm0, 4(%esp)
movq%mm0, 16(%esp)
movd4(%esp), %mm0
punpckldq %mm0, %mm0
movq%mm0, 8(%esp)
movlps 16(%esp), %xmm1
movhps 8(%esp), %xmm1
addl$28, %esp
movaps %xmm1, %xmm0
ret
Note the usage of MMX registers.
--- Comment #5 From Andrew Pinski 2005-09-27 14:33 ---
(In reply to comment #4)
> I think that following example wins the contest:
>
> vector float f(void) { return (vector float){ a, a, b, b}; }
For this, it is a different bug. The issue with the above is that
ix86_expand_vector_init_duplicate check
for mmx_okay is bad.
Currently, we have
if (!mmx_ok && !TARGET_SSE)
but I if I change it to:
if (!mmx_ok)
we get:
movss _a, %xmm0
movss _b, %xmm1
unpcklps%xmm0, %xmm0
unpcklps%xmm1, %xmm1
movlhps %xmm1, %xmm0
Which looks ok to me. That testcase should be opened into another bug as it is
obviously wrong.
=
Cloned from 24073 to track the MMX insn issue; the original 24073 problem is a
performance issue.
--
Summary: return (vector float) { a, a, b, b } generates unwanted
MMX insns
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
GCC target triplet: i786-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28826
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #11 from wilson at specifix dot com 2006-08-23 21:25 --- Subject: Re: [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips tbm at gcc dot gnu dot org wrote: > Any update on this, Jim? No. My life continues to be busy and complicated, making it difficult to do much gcc work. However, I did put a patch in the PR. If anyone else has time, they could try testing it. It needs a bootstrap and regression test. I think the problem is best fixed on mainline by merging in the dataflow branch, but for currently supported releases, and for the pending 4.2 release, I think the simple fix in the PR is best. So if we add this fix to the mainline now, then we need to remember to remove it when the dataflow branch goes in, or else prevent it from migrating to the dataflow branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug target/28826] return (vector float) { a, a, b, b } generates unwanted MMX insns
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-23 21:28 ---
*** This bug has been marked as a duplicate of 28825 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
Summary|return (vector float) { a, |return (vector float) { a,
|a, b, b } generates unwanted|a, b, b } generates unwanted
|MMX insns |MMX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28826
[Bug target/28825] return (vector float) { a, a, b, b } generates unwanted MMX insns
X-Bugzilla-Reason: CC --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-23 21:28 --- *** Bug 28826 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28825
[Bug target/28825] return (vector float) { a, a, b, b } generates unwanted MMX insns
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-23 21:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-08-23 21:28:21
date||
Summary|return (vector float) { a, |return (vector float) { a,
|a, b, b } generates unwanted|a, b, b } generates unwanted
|MMX insns |MMX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28825
[Bug target/28825] return (vector float) { a, a, b, b } generates unwanted MMX insns
--- Comment #3 from stuart at gcc dot gnu dot org 2006-08-23 21:41 --- Subject: Bug 28825 Author: stuart Date: Wed Aug 23 21:41:35 2006 New Revision: 116356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116356 Log: PR 28825 * gcc/config/i386/i386.c (ix86_expand_vector_init_duplicate, ix86_expand_vector_init_one_nonzero): Remove TARGET_SSE test. * gcc.target/i386/20060821-1.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/20060821-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28825
[Bug target/28825] return (vector float) { a, a, b, b } generates unwanted MMX insns
--- Comment #4 from stuart at apple dot com 2006-08-23 21:44 --- Per Ians email of 18aug2006, I've committed Andrew's fix as SVN revision 116356. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28825
[Bug target/24073] (vector float){a, b, 0, 0} code gen is not good
--- Comment #7 from stuart at apple dot com 2006-08-23 21:54 --- Time has passed, and GCC has improved on this testcase. Here is what we generate today (trunk, 23aug2006) for the original testcase: movss b(%rip), %xmm0 movss a(%rip), %xmm1 unpcklps%xmm0, %xmm1 movaps %xmm1, %xmm0 xorps %xmm1, %xmm1 movlhps %xmm1, %xmm0 ret This isn't perfect, but it's much better than before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24073
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #7 from hosking at cs dot purdue dot edu 2006-08-23 22:29 --- This is with the Modula-3 backend. I am porting it to 4.1.1 and encountered this problem with -O3 turned on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #8 from hosking at cs dot purdue dot edu 2006-08-23 23:43 --- I can send whatever traces you might need for diagnosis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
Re: [Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
hosking at cs dot purdue dot edu wrote: > --- Comment #7 from hosking at cs dot purdue dot edu 2006-08-23 22:29 > --- > This is with the Modula-3 backend. I am porting it to 4.1.1 and encountered > this problem with -O3 turned on. > > Does 4.1 have the check for EDGE_CRITICAL_P in insert_aux? If not, that is the problem.
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-08-23 23:52 --- Subject: Re: remove_phi_node attempts removal of a phi node resized by resize_phi_node hosking at cs dot purdue dot edu wrote: > --- Comment #7 from hosking at cs dot purdue dot edu 2006-08-23 22:29 > --- > This is with the Modula-3 backend. I am porting it to 4.1.1 and encountered > this problem with -O3 turned on. > > Does 4.1 have the check for EDGE_CRITICAL_P in insert_aux? If not, that is the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-08-23 23:54 --- > I think the only sane way to handle this is not to emit any mode > switching code for exception edges at the potential trapping site, > and make the exception handling code assume no particular mode is > present (unless the compiler can prove that an exception handler can only > be reached from throwing/trapping sites that all have the same mode). Although the mode switching code beyonds me, how does the exception handling code have no particular mode at its start? By calling make_preds_opaque for the corresponding BB and set no_mode to seginfo->mode? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
Re: [Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
> > > > --- Comment #8 from hosking at cs dot purdue dot edu 2006-08-23 23:43 > --- > I can send whatever traces you might need for diagnosis. Can you provide the dump generated by -fdump-tree-pre-details? -- Pinski
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #10 from pinskia at physics dot uc dot edu 2006-08-24 00:15 --- Subject: Re: remove_phi_node attempts removal of a phi node resized by resize_phi_node > > > > --- Comment #8 from hosking at cs dot purdue dot edu 2006-08-23 23:43 > --- > I can send whatever traces you might need for diagnosis. Can you provide the dump generated by -fdump-tree-pre-details? -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug driver/28528] [4.0/4.1/4.2 Regression] C language extensions override -x in C++ driver
--- Comment #9 from patchapp at dberlin dot org 2006-08-24 00:20 --- Subject: Bug number PR 28528 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-08/msg00849.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug fortran/28813] gfortran.dg/direct_io_6.f90 can exhaust system disk space
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-08-24 00:24 --- I will delete the test tonight shortly. Will add a new one later -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28813
[Bug c++/28827] New: [4.0.3 regression] ICE with nested template friend
template
struct Base : T
{
typedef T Derived;
};
struct A
{
template
friend struct Base::Derived::Crash;
// nested.cpp:10: internal compiler error: in lookup_member, at
cp/search.c:1213
// ICE with g++-4.0.3
// PASS with g++-3.4.6
};
--
Summary: [4.0.3 regression] ICE with nested template friend
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: proppy at aminche dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28827
[Bug testsuite/28828] New: FAIL: gcc.dg/attr-invalid.c
Executing on host: /home/dave/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gcc-4.2/objdi r/gcc/ /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c -fno-show-c olumn -S -o attr-invalid.s(timeout = 300) /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:12: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:14: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:17: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:18: warning: 'noinlin e' attribute does not apply to types /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:20: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'noinlin e_fn_knrarg': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:23: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: At top level: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:26: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'noinlin e_fn_vars': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:29: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:30: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: At top level: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:38: warning: 'used' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:40: warning: 'used' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:43: warning: 'used' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:44: warning: 'used' a ttribute does not apply to types /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'used_fn _knrarg': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:49: warning: 'used' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: At top level: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:52: warning: 'used' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'used_fn _vars': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:56: warning: 'used' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: At top level: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:67: warning: 'weak' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:69: warning: 'weak' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:72: warning: 'weak' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'weak_fn _knrarg': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:76: warning: 'weak' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: At top level: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:79: warning: 'weak' a ttribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:88: warning: 'dllimpo rt' attribute directive ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:90: warning: 'dllimpo rt' attribute directive ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:93: warning: 'dllimpo rt' attribute directive ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'dllimpo rt_fn_knrarg': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:97: warning: 'dllimpo rt' attribute directive ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: At top level: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:100: warning: 'dllimp ort' attribute directive ignored output is: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:12: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:14: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:17: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:18: warning: 'noinlin e' attribute does not apply to types /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:20: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'noinlin e_fn_knrarg': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:23: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: At top level: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:26: warning: 'noinlin e' attribute ignored /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c: In function 'noinlin e_fn_vars': /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/attr-invalid.c:29: warning: 'noinlin e' attribute ig
[Bug testsuite/28829] New: FAIL: gcc.dg/pr26570.c
Executing on host: /home/dave/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gcc-4.2/objdi r/gcc/ /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/pr26570.c -O2 -fprofile-gen erate -fprofile-use -fno-show-column -S -o pr26570.s(timeout = 300) /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/pr26570.c:12: error: redefinition of 'test' /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/pr26570.c:5: error: previous definit ion of 'test' was here compiler exited with status 1 output is: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/pr26570.c:12: error: redefinition of 'test' /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/pr26570.c:5: error: previous definit ion of 'test' was here FAIL: gcc.dg/pr26570.c (test for warnings, line 7) FAIL: gcc.dg/pr26570.c (test for warnings, line 14) FAIL: gcc.dg/pr26570.c (test for excess errors) Excess errors: /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/pr26570.c:12: error: redefinition of 'test' /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/pr26570.c:5: error: previous definit ion of 'test' was here -- Summary: FAIL: gcc.dg/pr26570.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28829
[Bug testsuite/28829] FAIL: gcc.dg/pr26570.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-24 00:57 --- I think this testcase is really the same testcase twice in the file. It fails everywhere too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa*-*-* | GCC host triplet|hppa*-*-* | GCC target triplet|hppa*-*-* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28829
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #11 from hosking at cs dot purdue dot edu 2006-08-24 00:57
---
(In reply to comment #9)
> Does 4.1 have the check for EDGE_CRITICAL_P in insert_aux?
Yes:
/* This can happen in the very weird case
that our fake infinite loop edges have caused a
critical edge to appear. */
if (EDGE_CRITICAL_P (pred))
{
cant_insert = true;
break;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug c++/28827] [4.0 Regression] ICE with nested template friend
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-24 01:00 --- 4.2.0 rejects the code: t.cc:10: error: 'Crash' is not a member of 'T' This code is invalid. 3.3 gave: t.cc:10: error: typename type `typename Base::Derived::Crash' declared `friend' ICC gives: t.cc(10): error: a qualified friend template declaration must refer to a specific previously declared template friend struct Base::Derived::Crash; ^ compilation aborted for t.cc (code 2) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Keywords||ice-on-invalid-code Known to fail||3.0.4 4.0.0 Summary|[4.0.3 regression] ICE with |[4.0 Regression] ICE with |nested template friend |nested template friend http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28827
[Bug libstdc++/28830] New: FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/lockfree_weaktoshared.cc
Executing on host: /home/dave/gnu/gcc-4.2/objdir/./gcc/g++ -shared-libgcc -B/hom e/dave/gnu/gcc-4.2/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc-4.2/objdir/hppa -linux/libstdc++-v3/src -L/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/ src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gn u/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-l inux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc-4.2/objdir/h ppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.2/objdir/hppa-l inux/libstdc++-v3/include -I/home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/libsupc++ -I /home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc-4. 2/gcc/libstdc++-v3/testsuite/util testsuite_abi.o testsuite_allocator.o testsuit e_character.o testsuite_hooks.o twister_rand_gen.o verified_cmd_line_input.o pro g_bar.o dbg_ex_allocator_base.o elapsed_timer.o -Wl,--gc-sections /home/dave/gnu /gcc-4.2/gcc/libstdc++-v3/testsuite/tr1/2_general_utilities/memory/shared_ptr/th read/lockfree_weaktoshared.cc -pthread -lm -o ./lockfree_weaktoshared.exe (timeout = 600) /tmp/ccljP9Ft.o: In function `std::tr1::_Sp_counted_base<(std::tr1::_Lock_policy )0>::add_ref_lock()': /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/tr1/boost_shared_p tr.h:259: undefined reference to `__sync_bool_compare_and_swap_4' /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/tr1/boost_shared_p tr.h:259: undefined reference to `__sync_bool_compare_and_swap_4' collect2: ld returned 1 exit status compiler exited with status 1 output is: /tmp/ccljP9Ft.o: In function `std::tr1::_Sp_counted_base<(std::tr1::_Lock_policy )0>::add_ref_lock()': /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/tr1/boost_shared_p tr.h:259: undefined reference to `__sync_bool_compare_and_swap_4' /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/tr1/boost_shared_p tr.h:259: undefined reference to `__sync_bool_compare_and_swap_4' collect2: ld returned 1 exit status FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/lockfree_weaktoshared.cc (test for excess errors) Excess errors: /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/tr1/boost_shared_p tr.h:259: undefined reference to `__sync_bool_compare_and_swap_4' /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/tr1/boost_shared_p tr.h:259: undefined reference to `__sync_bool_compare_and_swap_4' collect2: ld returned 1 exit status WARNING: tr1/2_general_utilities/memory/shared_ptr/thread/lockfree_weaktoshared. cc compilation failed to produce executable extra_tool_flags are: -pthread -- Summary: FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/lockfre e_weaktoshared.cc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-linux* GCC host triplet: hppa*-*-linux* GCC target triplet: hppa*-*-linux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28830
[Bug testsuite/28828] FAIL: gcc.dg/attr-invalid.c
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-08-24 01:10 --- This is my bad. Sorry. Should be fixed by: http://gcc.gnu.org/ml/gcc-cvs/2006-08/msg00514.html Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-24 01:10:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28828
[Bug fortran/28813] gfortran.dg/direct_io_6.f90 can exhaust system disk space
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-08-24 01:11 --- Subject: Bug 28813 Author: jvdelisle Date: Thu Aug 24 01:10:55 2006 New Revision: 116368 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116368 Log: 2006-08-23 Jerry DeLisle <[EMAIL PROTECTED]> PR 28813 * gfortran.dg/direct_io_6.f90: Remove test. Removed: trunk/gcc/testsuite/gfortran.dg/direct_io_6.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28813
[Bug middle-end/28815] gcc-4.2-20060819 failed to compile Linux kernel 2.6.18-rc4-git1
--- Comment #5 from happyarch at gmail dot com 2006-08-24 01:16 --- I am using binutils-2.17, glibc-2.4 and gcc, kernel version is in the below error message. > make scripts/kconfig/conf -s arch/i386/Kconfig CHK include/linux/version.h CHK include/linux/utsrelease.h ... CC kernel/configs.o CC kernel/ksysfs.o CC kernel/seccomp.o CC kernel/relay.o LD kernel/built-in.o CC mm/bootmem.o CC mm/filemap.o CC mm/mempool.o CC mm/oom_kill.o CC mm/fadvise.o CC mm/page_alloc.o CC mm/page-writeback.o CC mm/pdflush.o CC mm/readahead.o CC mm/swap.o CC mm/truncate.o CC mm/vmscan.o CC mm/prio_tree.o CC mm/util.o CC mm/mmzone.o CC mm/vmstat.o CC mm/fremap.o CC mm/highmem.o CC mm/madvise.o CC mm/memory.o CC mm/mincore.o CC mm/mlock.o CC mm/mmap.o CC mm/mprotect.o CC mm/mremap.o CC mm/msync.o CC mm/rmap.o CC mm/vmalloc.o CC mm/page_io.o CC mm/swap_state.o CC mm/swapfile.o CC mm/thrash.o CC mm/shmem.o CC mm/slab.o LD mm/built-in.o CC fs/open.o CC fs/read_write.o CC fs/file_table.o CC fs/buffer.o fs/buffer.c: In function 'nobh_prepare_write': fs/buffer.c:2378: internal compiler error: in build_polynomial_chrec, at tree-chrec.h:108 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[1]: *** [fs/buffer.o] Error 1 make: *** [fs] Error 2 > pwd /usr/src/linux-2.6.18-rc4 > cc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,treelang Thread model: posix gcc version 4.2.0 20060819 (experimental) > uname -a Linux arch 2.6.18-rc4-git1 #3 PREEMPT Tue Aug 22 08:00:26 KST 2006 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28815
[Bug middle-end/28815] gcc-4.2-20060819 failed to compile Linux kernel 2.6.18-rc4-git1
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-24 01:18 --- This is most likely a dup of bug 28776 and most likely already fixed. Can you try a build from today? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28776 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28815
[Bug c++/28553] [4.1 Regression] string processing -O3 optimization bug under GCC 4.1.1
--- Comment #4 from bangerth at dealii dot org 2006-08-24 01:52 --- Paolo has already confirmed this one. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-24 01:52:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28553
[Bug c++/28557] [4.0 regression] Trouble with templated type conversion operator
-- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-24 01:53:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28557
[Bug c++/28766] compound literal expression vs templates
--- Comment #2 from bangerth at dealii dot org 2006-08-24 01:57 --- It doesn't seem to matter for me whether the function is a template or not. Which version did you use to get to that statement? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28766
[Bug c++/28774] Request for warning where const/volatile is ignored in a cast
--- Comment #1 from bangerth at dealii dot org 2006-08-24 01:59 --- Um, why? The value "1.234" is an rvalue of type double. You cast it to an rvalue of type "const int", which can clearly be assigned to an int right away without another cast. In fact, const-volatile qualifications do not have meaning for rvalues at all, which makes the whole question kinda moot. Or do I miss something? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug middle-end/28753] [4.2 regression] ICE in extract_insn, at recog.c:2075 on powerpc
--- Comment #10 from dje at gcc dot gnu dot org 2006-08-24 02:03 --- Created an attachment (id=12118) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12118&action=view) patch to add 0->y alternative to movcc_internal1 Zdenek's patch does not change anything in GCC RTL generation that would cause this bug -- presumably the patch exposes a latent bug. This apparently is a bug in reload: it should not blindly try to apply the REG_EQUIV without checking the pattern predicates, but reload generally ignores predicates. One workaround is this patch to materialize zero in a CR. Zero luckily is easy to materialize and I doubt that other constants would appear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28753
[Bug c++/28827] [4.0 Regression] ICE with nested template friend
--- Comment #2 from proppy at aminche dot com 2006-08-24 02:22 --- (In reply to comment #1) > 4.2.0 rejects the code: > t.cc:10: error: 'Crash' is not a member of 'T' > nested.cpp:10: internal compiler error: in lookup_member, at cp/search.c:1212 on g++-4.2 version 4.2.0 20060709 (experimental) (Debian 4.2-20060709-1) which g++-4.2 revision are you using to get ?: t.cc:10: error: 'Crash' is not a member of 'T' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28827
Re: [Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
hosking at cs dot purdue dot edu wrote:
> --- Comment #11 from hosking at cs dot purdue dot edu 2006-08-24 00:57
> ---
> (In reply to comment #9)
>> Does 4.1 have the check for EDGE_CRITICAL_P in insert_aux?
>
> Yes:
>
> /* This can happen in the very weird case
> that our fake infinite loop edges have caused a
> critical edge to appear. */
> if (EDGE_CRITICAL_P (pred))
> {
> cant_insert = true;
> break;
> }
>
>
Honestly, there should be no other case in which the edge actually needs
to be split. It is just a shortcut rather than trying to whether we
want the beginning of the succ or the end of the pred (it figures it out
for us).
If you could attach the dump from
-fdump-tree-crited-vops-details-blocks-stats, and tell me what pred,
src, and block are, that would be helpful.
Without more, it's either something *very* strange in the code modula3
is creating (or broken gimplification), *or* the edge inserter is
confused and believes it needs to create a block in a case it doesn't.
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-08-24 02:45
---
Subject: Re: remove_phi_node attempts removal
of a phi node resized by resize_phi_node
hosking at cs dot purdue dot edu wrote:
> --- Comment #11 from hosking at cs dot purdue dot edu 2006-08-24 00:57
> ---
> (In reply to comment #9)
>> Does 4.1 have the check for EDGE_CRITICAL_P in insert_aux?
>
> Yes:
>
> /* This can happen in the very weird case
> that our fake infinite loop edges have caused a
> critical edge to appear. */
> if (EDGE_CRITICAL_P (pred))
> {
> cant_insert = true;
> break;
> }
>
>
Honestly, there should be no other case in which the edge actually needs
to be split. It is just a shortcut rather than trying to whether we
want the beginning of the succ or the end of the pred (it figures it out
for us).
If you could attach the dump from
-fdump-tree-crited-vops-details-blocks-stats, and tell me what pred,
src, and block are, that would be helpful.
Without more, it's either something *very* strange in the code modula3
is creating (or broken gimplification), *or* the edge inserter is
confused and believes it needs to create a block in a case it doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug c/28831] New: Aggregate copy not elided when using a return value as a pass-by-value parameter
Bug 23372 was a missed optimization with respect to GCC 3.4. It is now fixed
when the parameter is a reference. But there is still a regression when the
parameter is the return value of another function. Testcase: (-Wall -O3
--march=i386)
struct A { int a[1000]; };
struct A f();
void g(struct A);
void h() { g(f()); }
GCC 3.3 and 3.4 first allocate the stack frame of g and then require f to
directly store its return value in the parameter location. GCC 4.0, 4.1, and
4.2 (as of 2006-08-23) use another stack location for the return value of f,
then allocate the stack frame of g, and finally copy the value to this new
frame (possibly using a byte-by-byte copy, see bug 27055). The code generated
by GCC 3.x is optimal, the one by GCC 4.x is not.
GCC 3.4:
movl%esp, %eax
subl$12, %esp
pushl %eax
callf
addl$12, %esp
callg
GCC 4.2:
leal-4004(%ebp), %ebx
pushl %ebx
callf
subl$3988, %esp
movl%esp, %eax
pushl %edx
pushl $4000
pushl %ebx
pushl %eax
callmemcpy
addl$16, %esp
callg
$ LANG=C /opt/gcc/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --prefix=/opt/gcc
Thread model: posix
gcc version 4.2.0 20060823 (experimental)
--
Summary: Aggregate copy not elided when using a return value as a
pass-by-value parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC target triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
[Bug c++/28766] compound literal expression vs templates
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-24 03:29 ---
(In reply to comment #2)
> It doesn't seem to matter for me whether the function is a template or
> not. Which version did you use to get to that statement?
4.2.0 20060821 works without the template in that the following works:
struct A { int i; };
void foo()
{
((struct A) { 0 }).i += 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28766
[Bug c++/28827] [4.0 Regression] ICE with nested template friend
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-24 03:41 --- (In reply to comment #2) > which g++-4.2 revision are you using to get ?: 4.2.0 20060821 aka two days ago's. I bet it was also fixed by 28304. You are using a month's old 4.2 compiler which is why you don't see the fix. If you are going to try the mainline, please try with at a max a week old compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28827
[Bug target/28825] return (vector float) { a, a, b, b } generates unwanted MMX insns
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-24 03:41 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28825
[Bug testsuite/28828] FAIL: gcc.dg/attr-invalid.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 03:51 --- Confirmed fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28828
[Bug tree-optimization/15452] [tree-ssa] Optimize cascaded a = a == 0;
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-24 04:27 ---
Another interesting case would be (but which could be handled by VRP):
int
foo (int a)
{
a = a!=0;
a = a!=0;
a = a!=0;
a = a!=0;
a = a!=0;
return a;
}
Which should be optimized to:
int foo(int a) { return a!=0;}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15452
[Bug fortran/28771] gfortran accepts invalid variable definition
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-24 04:47 --- Subject: Bug 28771 Author: pault Date: Thu Aug 24 04:47:28 2006 New Revision: 116369 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116369 Log: 2006-08-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/derived_init_2.f90: Modify to check sibling association of derived types. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. 2006-08-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/derived_init_2.f90: Modify to check sibling association of derived types. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. Added: trunk/gcc/testsuite/gfortran.dg/used_types_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_charlen_in_main.f90 trunk/gcc/testsuite/gfortran.dg/derived_init_2.f90 trunk/gcc/testsuite/gfortran.dg/used_types_2.f90 trunk/gcc/testsuite/gfortran.dg/used_types_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28771
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #5 from pault at gcc dot gnu dot org 2006-08-24 04:47 --- Subject: Bug 28788 Author: pault Date: Thu Aug 24 04:47:28 2006 New Revision: 116369 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116369 Log: 2006-08-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/derived_init_2.f90: Modify to check sibling association of derived types. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. 2006-08-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/derived_init_2.f90: Modify to check sibling association of derived types. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. Added: trunk/gcc/testsuite/gfortran.dg/used_types_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_charlen_in_main.f90 trunk/gcc/testsuite/gfortran.dg/derived_init_2.f90 trunk/gcc/testsuite/gfortran.dg/used_types_2.f90 trunk/gcc/testsuite/gfortran.dg/used_types_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug fortran/28771] gfortran accepts invalid variable definition
--- Comment #7 from pault at gcc dot gnu dot org 2006-08-24 04:54 --- Subject: Bug 28771 Author: pault Date: Thu Aug 24 04:54:18 2006 New Revision: 116370 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116370 Log: 2006-08-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * symbol.c (shift_types): Shift the derived type references in formal namespaces. (gfc_use_derived): Return if the derived type symbol is already in another namspace. Add searches for the derived type in sibling namespaces. PR fortran/28771 * decl.c (add_init_expr_to_sym): Restore the original but restricted to parameter arrays to fix a regression. 2006-08-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_4.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_in_main.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28771
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-24 04:54 --- Subject: Bug 28788 Author: pault Date: Thu Aug 24 04:54:18 2006 New Revision: 116370 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116370 Log: 2006-08-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * symbol.c (shift_types): Shift the derived type references in formal namespaces. (gfc_use_derived): Return if the derived type symbol is already in another namspace. Add searches for the derived type in sibling namespaces. PR fortran/28771 * decl.c (add_init_expr_to_sym): Restore the original but restricted to parameter arrays to fix a regression. 2006-08-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28788 * gfortran.dg/used_types_4.f90: New test. * gfortran.dg/used_types_2.f90: Add module cleanup. * gfortran.dg/used_types_3.f90: The same. PR fortran/28771 * gfortran.dg/assumed_charlen_in_main.f90: Modify to check fix of regression. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_4.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_in_main.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug middle-end/28815] gcc-4.2-20060819 failed to compile Linux kernel 2.6.18-rc4-git1
--- Comment #7 from happyarch at gmail dot com 2006-08-24 05:47 --- revision 116368 works fine, the bug seems to be fixed. > cc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,treelang Thread model: posix gcc version 4.2.0 20060824 (experimental) > uname -a Linux arch 2.6.18-rc4-git1 #4 PREEMPT Thu Aug 24 14:39:20 KST 2006 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28815
[Bug other/28797] Problems with demangling (__cxa_demangle())
--- Comment #4 from ian at airs dot com 2006-08-24 06:20 --- Where did you get your list of symbol names and demangled strings? As Andrew has pointed out, there seem to be a few different issues here: different spacing, different qualifier order, different handling of floating point constants. It may well be appropriate to change gcc's demangler, but in my opinion these different issues should be handled as different problem reports. Other than those issues, I see one serious issue in this list: _Z1fM1AKiPKS1_, which the gcc demangler does not demangle, but you propose should be demangled as f(int const A::*, int const A::*const*). I have to agree with you that there appears to be something wrong with the demangler in this case. It is related to the long comment in d_pointer_to_member_type in cp-demangle.c. When I wrote that comment I believed that it was correct. However, it appears to now be incorrect. I haven't yet been able to track down the change to gcc which affected this. It is also possible that I was simply mistaken. -- ian at airs dot com changed: What|Removed |Added CC|ian at gcc dot gnu dot org |ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28797
