[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #8 from daney at gcc dot gnu dot org 2007-09-04 06:01 --- Created an attachment (id=14154) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14154action=view) Reduced testcase. -- daney at gcc dot gnu dot org changed: What|Removed |Added Attachment #14149|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug tree-optimization/32975] [4.3 Regression] ICE segfault (verify_cgraph failure after ipa-cp) with -finline-functions -fipa-cp
--- Comment #3 from jakub at gcc dot gnu dot org 2007-09-04 06:14 --- Can't reproduce this, neither on x86_64-linux, nor on ppc-linux, on the former I tried cc1's I had laying around back through to 2007-08-21 and all of them worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32975
[Bug fortran/33281] gfortran crt2.o not found under Vista
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-04
06:17 ---
The solution is to build gcc/gfortran wiith -D__USE_MINGW_ACCESS in CFLAGS;
From mingw/include/io.h
/* Some defines for _access nAccessMode (MS doesn't define them, but
* it doesn't seem to hurt to add them). */
#define F_OK0 /* Check for file existence */
/* Well maybe it does hurt. On newer versions of MSVCRT, an access mode
of 1 causes invalid parameter error. */
#define X_OK1 /* MS access() doesn't check for execute permission. */
#define W_OK2 /* Check for write permission */
#define R_OK4 /* Check for read permission */
and later:
#ifdef __USE_MINGW_ACCESS
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code. This will restore the
old behaviour */
static inline int __mingw_access (const char* __fname, int __mode)
{ return _access (__fname, __mode ~X_OK); }
#define access(__f,__m) __mingw_access (__f, __m)
#endif
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-04 06:17:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #9 from daney at gcc dot gnu dot org 2007-09-04 06:32 --- Fixing things up when we are calculating relocations does not seem like it will work. We cannot go adding an offest to a %lo() relocation and expect it not to overflow on occasion. Probably we need to load the value into a register and handle the casting there, as is done at -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug tree-optimization/32772] [4.3 Regression] error: found real variable when subvariables should have appeared
--- Comment #12 from jakub at gcc dot gnu dot org 2007-09-04 06:48 --- Which testcase is not fixed? ./xgcc -B ./ -Wall -Wundef -m32 -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Werror-implicit-function-declaration -Os -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=athlon -ffreestanding -maccumulate-outgoing-args -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -fno-stack-protector pr32772-1.i -S In file included from include/asm/thread_info.h:17, from include/linux/thread_info.h:22, from include/linux/preempt.h:10, from include/linux/spinlock.h:50, from include/linux/mmzone.h:8, from include/linux/gfp.h:5, from include/linux/mm.h:9, from mm/page_alloc.c:19: include/asm/processor.h: In function `cpuid_count': include/asm/processor.h:622: warning: pointer targets in passing argument 1 of `__cpuid' differ in signedness include/asm/processor.h:622: warning: pointer targets in passing argument 2 of `__cpuid' differ in signedness include/asm/processor.h:622: warning: pointer targets in passing argument 3 of `__cpuid' differ in signedness include/asm/processor.h:622: warning: pointer targets in passing argument 4 of `__cpuid' differ in signedness succeeds on the http://gcc.gnu.org/bugzilla/attachment.cgi?id=13918action=view testcase, and the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772#c6 testcase as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
[Bug fortran/33298] New: Wrong code for SPREAD on dummy arguments
This code: REAL X(2,3), Y(2) Y=[1.,2.] CALL SUB(X,Y) DO I = 1, 3 PRINT*,X(:,I) ENDDO END SUBROUTINE SUB(A,B) REAL A(:,:), B(:) A(:,:) = SPREAD(B(:),2,SIZE(A,2)) END results in: 0.00 0.00 0.00 0.00 0.00 0.00 using: /usr/snp/bin/gfortran -static -v -g -O2 -fbacktrace spread.f Driving: /usr/snp/bin/gfortran -static -v -g -O2 -fbacktrace spread.f -lgfortranbegin -lgfortran -lm Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/usr/snp/ --disable-multilib --disable-nls --enable-languages=fortran Thread model: posix gcc version 4.3.0 20070903 (experimental) (GCC) /usr/snp/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 spread.f -ffixed-form -quiet -dumpbase spread.f -mtune=generic -auxbase spread -g -O2 -version -fbacktrace -fintrinsic-modules-path /usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/ccjGK59d.s GNU F95 (GCC) version 4.3.0 20070903 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070903 (experimental), GMP version 4.2.1, MPFR version 2.3.0-rc1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cc53anSf.o /tmp/ccjGK59d.s GNU assembler version 2.17.90 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.17.90.20070812 /usr/snp/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2 -m elf_x86_64 -static /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbeginT.o -L/usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0 -L/usr/snp/bin/../lib/gcc -L/usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../.. /tmp/cc53anSf.o -lgfortranbegin -lgfortran -lm --start-group -lgcc -lgcc_eh -lc --end-group /usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o /usr/lib/../lib64/crtn.o Debian's testing gfortran-4.2 gave me another bunch of nonsense: -4.5149084E-10 4.5916347E-41 -4.5151327E-10 4.5916347E-41 -4.5151283E-10 4.5916347E-41 Trying to print the SPREAD expression directly gave me a segmentation fault using the above gfortran 4.2 and an empty line using 4.3. -- Summary: Wrong code for SPREAD on dummy arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl 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=33298
[Bug tree-optimization/32975] [4.3 Regression] ICE segfault (verify_cgraph failure after ipa-cp) with -finline-functions -fipa-cp
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-04 07:30 --- This got fixed by the PR30564 fix, http://gcc.gnu.org/viewcvs?root=gccview=revrev=127638 Do we want to commit this testcase as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32975
[Bug fortran/33298] Wrong code for SPREAD on dummy arguments
--- Comment #1 from jpr at csc dot fi 2007-09-04 07:49 --- The code is invalid without explicit interface to SUB(). Modified code: REAL X(2,3), Y(2) Y=[1.,2.] CALL SUB(X,Y) DO I = 1, 3 PRINT*,X(:,I) ENDDO CONTAINS SUBROUTINE SUB(A,B) REAL A(:,:), B(:) A(:,:) = SPREAD(B(:),2,SIZE(A,2)) END SUBROUTINE SUB END works just fine. Alternatively REAL X(2,3), Y(2) Y=[1.,2.] CALL SUB(X,Y,size(y,1),size(y,2)) DO I = 1, 3 PRINT*,X(:,I) ENDDO END SUBROUTINE SUB(A,B,n,m) INTEGER n,m REAL A(n,m), B(n) A(:,:) = SPREAD(B(:),2,SIZE(A,2)) END also works as expected. If the main program and SUB are compiled together, the compiler could of course diagnose this, as e.g. pathscale does: SUBROUTINE SUB(A,B) ^ pathf95-1277 pathf90: ERROR SUB, File = t.f90, Line = 9, Column = 18 Procedure SUB is referenced at line 3 (t.f90). It must have an explicit interface specified. Regards, Juha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug fortran/33298] Wrong code for SPREAD on dummy arguments
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-04 07:57 --- CLOSE as invalid as subroutines with assumed-shaped dummy arguments require an explicit interface. The whole-file checking - which would diagnose this as error - is planned for GCC 4.4.0. See http://gcc.gnu.org/wiki/GFortran43 and, e.g., PR 26227. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug libstdc++/33293] inlining std::inner_product()
--- Comment #4 from simon dot marshall at misys dot com 2007-09-04 08:01 --- Many thanks for the quick response. Any chance it could make it into 4.2.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33293
[Bug fortran/33298] Wrong code for SPREAD on dummy arguments
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2007-09-04 08:11 --- Yeah, I have to come up with a better example. In the original code that I reduced, the interface came from a module file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug tree-optimization/32772] [4.3 Regression] error: found real variable when subvariables should have appeared
--- Comment #13 from jakub at gcc dot gnu dot org 2007-09-04 08:22 --- The testcases got fixed already by the http://gcc.gnu.org/viewcvs?root=gccview=revrev=127491 commit, which is why Daniel wrote http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772#c11 Guess checking in the testcase is desirable anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
[Bug tree-optimization/33291] [4.3 Regression] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-04 08:39 --- Subject: Bug 33291 Author: rguenth Date: Tue Sep 4 08:38:56 2007 New Revision: 128068 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128068 Log: 2007-09-04 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/33291 * tree-pretty-print.c (dump_generic_node): Dump all qualifiers for pointer types, not only first. Dump qualifiers for aggregate types as well. * tree-ssa-ccp.c (maybe_fold_offset_to_array_ref): Always use the canonical type for building ARRAY_REFs. * gimplify.c (canonicalize_addr_expr): Clean up. The correct validness check is compatibility of the pointer types. Always use the canonical type for building ARRAY_REFs and ADDR_EXPRs. * tree-ssa-forwprop.c (forward_propagate_addr_expr): Revert change that disabled propagation of ADDR_EXPRs into statements with volatile ops. * gcc.dg/volatile2.c: New testcase. * gcc.dg/pr32721.c: Adjust volatile reference pattern. * gcc.dg/tree-ssa/forwprop-1.c: Remove xfail. * gcc.dg/tree-ssa/forwprop-2.c: Likewise. * gcc.dg/tree-ssa/pr17141-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/volatile2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr32721.c trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr17141-1.c trunk/gcc/tree-pretty-print.c trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug tree-optimization/33291] [4.3 Regression] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-04 08:41 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug libstdc++/33293] inlining std::inner_product()
--- Comment #5 from pcarlini at suse dot de 2007-09-04 08:41 --- The patch itself is trivial but in our experience changing the inlining patterns can have far reaching and unpredictable fall-outs. Thus, better not touching the release branches, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33293
[Bug libstdc++/33293] inlining std::inner_product()
--- Comment #6 from simon dot marshall at misys dot com 2007-09-04 08:43 --- OK, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33293
[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
--- Comment #12 from rask at gcc dot gnu dot org 2007-09-04 08:52 --- Closing as suggested off-line by Andreas Jaeger. -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
[Bug tree-optimization/32975] [4.3 Regression] ICE segfault (verify_cgraph failure after ipa-cp) with -finline-functions -fipa-cp
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2007-09-04 08:53 --- (In reply to comment #4) This got fixed by the PR30564 fix, http://gcc.gnu.org/viewcvs?root=gccview=revrev=127638 Do we want to commit this testcase as well? I think yes, please do. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32975
[Bug web/32965] missing documentation for -ftree-dse
--- Comment #2 from patchapp at dberlin dot org 2007-09-04 09:45 --- Subject: Bug number PR 32965 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/2007-09/msg00190.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
[Bug tree-optimization/33299] New: miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
The following gets miscompiled with gcc 4.3, works with 4.2.0 4.2.1 at least. PROGRAM test REAL(8) :: f,dist(2) dist = [1.0_8, 0.5_8] PRINT*,f(1.0_8, dist), ' should be: ', MINVAL(dist) END PROGRAM test FUNCTION f( x, dist ) RESULT(s) REAL(8) :: dist(2), x, s s = MINVAL(dist) IF( x 0 ) s = -s END FUNCTION f gfortran -v -O2 -ffast-math -ftree-vectorize -o test test.f90 Driving: gfortran -v -O2 -ffast-math -ftree-vectorize -o test test.f90 -lgfortranbegin -lgfortra n -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /projects/tob/gcc/configure --enable-languages=c,fortran --prefix=/projects/tob /gcc-trunk Thread model: posix gcc version 4.3.0 20070904 (experimental) [trunk revision 128067] (GCC) COLLECT_GCC_OPTIONS='-v' '-O2' '-ffast-math' '-ftree-vectorize' '-o' 'test' '-shared-libgcc' '-m tune=generic' /wrk/jpr/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 test.f90 -quiet -dump base test.f90 -mtune=generic -auxbase test -O2 -version -ffast-math -ftree-vectorize -fintrinsic -modules-path /wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/ jpr/ccEvFIMX.s GNU F95 (GCC) version 4.3.0 20070904 (experimental) [trunk revision 128067] (x86_64-unknown-linu x-gnu) compiled by GNU C version 4.3.0 20070904 (experimental) [trunk revision 128067], GMP ver sion 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-v' '-O2' '-ffast-math' '-ftree-vectorize' '-o' 'test' '-shared-libgcc' '-m tune=generic' as -V -Qy -o /tmp/jpr/ccJEvzPa.o /tmp/jpr/ccEvFIMX.s GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version 2.15.92.0.2 20040927 COMPILER_PATH=/wrk/jpr/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/wrk/jpr/gcc -trunk/bin/../libexec/gcc/ LIBRARY_PATH=/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/wrk/jpr/gcc-trun k/bin/../lib/gcc/:/v/linux26_x86_64/opt/papi/3.5.0/lib64/../lib64/:/wrk/jpr/gcc-trunk/bin/../lib /gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/v/linu x26_x86_64/opt/papi/3.5.0/lib64/:/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3. 0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-O2' '-ffast-math' '-ftree-vectorize' '-o' 'test' '-shared-libgcc' '-m tune=generic' /wrk/jpr/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /usr/lib/../lib64/crt1.o /usr/li b/../lib64/crti.o /wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o -L /wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0 -L/wrk/jpr/gcc-trunk/bin/../lib /gcc -L/v/linux26_x86_64/opt/papi/3.5.0/lib64/../lib64 -L/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_6 4-unknown-linux-gnu/4.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/v/linux26_x86 _64/opt/papi/3.5.0/lib64 -L/wrk/jpr/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../. ./.. /tmp/jpr/ccJEvzPa.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /wrk/jpr /gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtfastmath.o /wrk/jpr/gcc-trunk/bin/.. /lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o /usr/lib/../lib64/crtn.o ./test 1.00 should be: 0.500 Regrads, Juha -- Summary: miscompilation with gfortran -O2 -ffast-math -ftree- vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jpr at csc dot fi GCC host triplet: x86_64 linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug testsuite/33300] New: [libstdc++-v3] 27_io/ios_base/storage/2.cc with -m64 kills Darwin
I have posted the following on http://gcc.gnu.org/ml/libstdc++/2007-08/msg00051.html: The test libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc passes on PPC Darwin 8.10, but when run with -m64 it grabs all the disk space until the system freezes and needs a reboot. Is this known? Since I did not get any answer so far, let see if I am luckier on this list!-) Running the gfortran testsuite, I have noticed that the number of cases run is not the same for 32 and 64 modes. Is there a dg directive to prevent a test to be run in either of these modes? -- Summary: [libstdc++-v3] 27_io/ios_base/storage/2.cc with -m64 kills Darwin Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33300
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #10 from rsandifo at gcc dot gnu dot org 2007-09-04 09:54 --- Created an attachment (id=14155) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14155action=view) Proposed patch David, thanks for the analysis and reduced testcase. Re comment #7: I agree that we can't drop the offset_within_block_p check entirely. However (re comment #9) adjust_address_1 is actually making a legitimate optimisation here. It is given a memory that is known to be 8-byte-aligned, so it knows that adding 4 to the LO_SUM will not induce a carry. The problem is that the mips_classify_address has no access to that information; all it sees is the narrowed MEM. This PR is related to: http://thread.gmane.org/gmane.comp.gcc.patches/139565/focus=140004 I still think the final fix in that thread: http://gcc.gnu.org/viewcvs/trunk/gcc/config/mips/mips.c?r1=124833r2=124832pathrev=124833 was the right one for that bug because we always have access to a TLS's decl, so we can apply suitably small offsets to HIGHs as well as LO_SUMs. However, although we do have access to decl in the testcase for this PR, we won't for all (non-TLS) %hi/%los, so a similar fix won't work here. I think we have to trust the creator of the LO_SUM to do something vaguely sane. Target-independent code that creates a LO_SUM should also create and verify the associated HIGH, which must use the same symbol as the LO_SUM. Target-independent code that adds an offset to a LO_SUM should prove that the offset will not induce a carry. Failure to do either of these things would be a bug. And the MIPS backend should only create LO_SUMs for valid symbolic constants, with the high part being either a HIGH or a copy of _gp. So I'm wondering about the attached patch. Note that the lo_sum mips.md patterns are already OK, because they use immediate_operand. Richard -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug tree-optimization/33299] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-04 09:55 --- Confirmed. It looks like the vectorizer forgets to update the PHI node for stmp_var: bb 5: # vect_var_.32_31 = PHI vect_var_.32_29(3) # s_4 = PHI s_2(3) # s_10 = PHI s_2(3) stmp_var_.34_32 = BIT_FIELD_REF vect_var_.32_31, 64, 0; stmp_var_.34_33 = BIT_FIELD_REF vect_var_.32_31, 64, 64; stmp_var_.34_34 = MIN_EXPR stmp_var_.34_33, stmp_var_.34_32; D.1396_15 = *x_14(D); if (D.1396_15 0.0) goto bb 6; else goto bb 7; bb 6: s_16 = -stmp_var_.34_34; bb 7: # s_1 = PHI s_4(5), s_16(6) return s_1; s_4 should be stmp_var_.34_34 instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dorit at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-04 09:55:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to work||4.2.1 Summary|miscompilation with gfortran|[4.3 Regression] |-O2 -ffast-math -ftree- |miscompilation with gfortran |vectorize |-O2 -ffast-math -ftree- ||vectorize Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug middle-end/33187] Missed cmove opportunity
--- Comment #4 from uros at gcc dot gnu dot org 2007-09-04 10:07 --- Subject: Bug 33187 Author: uros Date: Tue Sep 4 10:07:19 2007 New Revision: 128072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128072 Log: PR middle-end/33187 * combine.c (subst): Do not try to simplify X if it represents load of FP constant from the constant pool via float extension. testsuite/ChangeLog: PR middle-end/33187 * gcc.target/i386/cmov7.c: New file. Added: trunk/gcc/testsuite/gcc.target/i386/cmov7.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33187
[Bug middle-end/33187] Missed cmove opportunity
--- Comment #5 from ubizjak at gmail dot com 2007-09-04 10:10 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33187
[Bug fortran/33298] Wrong code for SPREAD on zero sized dummy arguments
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2007-09-04 10:15 --- Second try, now with interface and using zero sized arrays: $ cat spread.f INTERFACE SUB SUBROUTINE SUB(P,Q) REAL, INTENT(OUT) :: P(:,:) REAL, INTENT(IN) :: Q(:) END SUBROUTINE END INTERFACE REAL, ALLOCATABLE :: X(:,:), Y(:) ALLOCATE(X(0,3)) ALLOCATE(Y(0)) ! Y=[1.,2.] CALL SUB(X,Y) DO I = 1, 3 PRINT*,X(:,I) ENDDO END SUBROUTINE SUB(A,B) REAL, INTENT(OUT) :: A(:,:) REAL, INTENT(IN) :: B(:) A(:,:) = SPREAD(B(:),2,SIZE(A,2)) END $ /usr/snp/bin/gfortran -g -O2 -static -fbacktrace spread.f $ ./a.out Program received signal 11 (SIGSEGV): Segmentation fault. Backtrace for this error: + function __restore_rt (0x4185D0) from file libgcc2.c + function memcpy (0x432D85) + function spread_internal (0x40A50F) at line 145 of file spread_generic.c + function sub_ (0x400404) at line 16 of file spread.f + in the main program at line 11 of file spread.f + function __libc_start_main (0x4138E7) -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|Wrong code for SPREAD on|Wrong code for SPREAD on |dummy arguments |zero sized dummy arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2007-09-04 10:22 --- This one can be considered FIXED, I think. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug fortran/33297] SIZE intrinsic crashes gfortran on invalid usage
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33297
[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-04 10:26 --- I think it's the expected behaviour. Other compilers emit warnings (or nothing) for this situation or related ones (like x = 2*huge() below), we chose to emit hard errors that can be bypassed by using -fno-range-check. real x x = nearest(huge(1.0),1.0) x = 2 * huge(1.0) print *, x end -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED GCC target triplet|powerpc-apple-darwin8 | Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-04 10:39 --- (In reply to comment #2) Confirmed on x86_64 (-O0), RECORD_TYPE is entering fold_convert() I've also started seeing this while working on my create only one decl per procedure patch. I wasn't aware that it can also be triggered on mainline. In my case, we come there because two different decls are created for one given type. Uros, do you think we could, in the fold_convert() switch on TREE_CODE(type), add a case for RECORD_TYPE similar to VECTOR_TYPE: assert that both RECORD_TYPEs have the same size, and that their fields correspond one-to-one, and then create a VIEW_CONVERT_EXPR? Do you think it would be worth having or would that hurt the middle-end in any way? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33297] SIZE intrinsic crashes gfortran on invalid usage
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-04 10:42 --- Confirmed: integer array(5), i1, i2 print *, size(array,(/i1,i2/)) end #0 fancy_abort (file=0xb1b960 ../../../trunk2/gcc/fortran/trans-expr.c, line=2857, function=0xb1c1e0 gfc_conv_array_constructor_expr) at ../../../trunk2/gcc/diagnostic.c:654 #1 0x00494610 in gfc_conv_expr (se=0x7fffe7913840, expr=0xea5c60) at ../../../trunk2/gcc/fortran/trans-expr.c:2857 #2 0x00495a68 in gfc_conv_expr_val (se=0x7fffe7913840, expr=0xb29) at ../../../trunk2/gcc/fortran/trans-expr.c:3361 #3 0x00495b19 in gfc_conv_expr_type (se=0xb1b960, expr=0xb29, type=0xb1c1e0) at ../../../trunk2/gcc/fortran/trans-expr.c:3375 #4 0x0049c7e4 in gfc_conv_intrinsic_size (se=0x7fffe7913cb0, expr=0xea5540) at ../../../trunk2/gcc/fortran/trans-intrinsic.c:2833 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|2.6.20-16-generic | GCC target triplet|x86_64-linux-gnu| Keywords||ice-on-invalid-code Known to fail||4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-09-04 10:42:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33297
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-04 10:51 --- Reduced testcase: real :: x(0,3), y(0) x = spread(y,2,3) end Backtrace: #0 0x00431600 in memcpy () #1 0x0040400f in spread_internal (ret=value optimized out, source=value optimized out, along=value optimized out, pncopies=value optimized out, size=4) at ../../../../trunk2/libgfortran/intrinsics/spread_generic.c:148 #2 0x00400342 in MAIN__ () at a.f90:2 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||wrong-code Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-09-04 10:51:29 date|| Summary|Wrong code for SPREAD on|Wrong code for SPREAD on |zero sized dummy arguments |zero-sized arrays Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug c++/18608] Configuration documentation mentions wrong flag
--- Comment #2 from paolo at gcc dot gnu dot org 2007-09-04 11:08 --- Subject: Bug 18608 Author: paolo Date: Tue Sep 4 11:07:52 2007 New Revision: 128074 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128074 Log: 2007-09-04 Paolo Carlini [EMAIL PROTECTED] PR c++/18608 * doc/install.texi (--enable-__cxa_atexit): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18608
[Bug c++/18608] Configuration documentation mentions wrong flag
--- Comment #3 from pcarlini at suse dot de 2007-09-04 11:10 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18608
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-04 11:44 --- (In reply to comment #1) Confirmed. It looks like the vectorizer forgets to update the PHI node for stmp_var: yes. I suspect I didn't expect at the time that there would be two loop-closed-ssa-form phi-nodes at the loop exit for s_3, so I probably update just one of them (s_10) and not the other (s_4). This is how it looks before vectorization: bb 7: # s_4 = PHI s_3(3) # s_10 = PHI s_3(3) D.1368_15 = *x_14(D); if (D.1368_15 0.0) goto bb 8; else goto bb 9; bb 8: s_16 = -s_10; bb 9: # s_1 = PHI s_4(7), s_16(8) return s_1; I'll prepare a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
-- dorit at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error
--- Comment #2 from dominiq at lps dot ens dot fr 2007-09-04 12:05 --- I don't think the PR is invalid: (1) at least it should go the enhancement with the addition of This check can be disabled with the option -fno-range-check as in print *, huge(0), -2147483648 1 Error: Integer too big for its kind at (1). This check can be disabled with the option -fno-range-check (2) I think the two cases are totally different: huge(0)+1 cannot be represented in the integer model, thus the overflow; as soon as the compiler knows INF/NAN (and gfortran does), I think nearest(huge(1.0),1.0)==+Inf is part of the floating point model and should not throw even a warning (even with -std=xx -pedantic). I don't want to start a flame war of this issue, but look at the number of mails, answers, noise, ..., generated by -2147483648 (note that I did not write -(2147483648)!-). -- dominiq at lps dot ens dot fr changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug tree-optimization/33291] [4.3 Regression] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #7 from wouter dot vermaelen at scarlet dot be 2007-09-04 12:11 --- Thanks for looking into this so quickly! I confirm the problem is solved for the reduced testcase. However in my original code the dead-store is not eliminated. Do you want me to file a separate bug report for that? mov(%rbx),%edx movzbl %cl,%edi lea0x3(%rdx),%r8d add$0x5,%edx mov%r8d,(%rbx) movzbl (%rsi,%rdi,1),%eax mov%edx,(%rbx) -- wouter dot vermaelen at scarlet dot be changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug tree-optimization/33291] [4.3 Regression] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-04 12:13 --- Yes please. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #11 from eres at il dot ibm dot com 2007-09-04 12:18 --- The patch was committed to r128075. Revital -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #18 from jason at gcc dot gnu dot org 2007-09-04 12:27 --- Subject: Bug 14032 Author: jason Date: Tue Sep 4 12:27:21 2007 New Revision: 128076 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128076 Log: PR c++/14032 * pt.c (most_specialized_class): Substitute outer template arguments into the arguments of a member template partial specialization. (strip_innermost_template_args): New fn. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #19 from jason at gcc dot gnu dot org 2007-09-04 12:28 --- Subject: Bug 14032 Author: jason Date: Tue Sep 4 12:27:38 2007 New Revision: 128077 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128077 Log: PR c++/14032 * pt.c (most_specialized_class): Substitute outer template arguments into the arguments of a member template partial specialization. (strip_innermost_template_args): New fn. Added: trunk/gcc/testsuite/g++.dg/template/mem-partial1.C trunk/gcc/testsuite/g++.dg/template/mem-partial2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-04 12:34 --- (In reply to comment #2) (1) at least it should go the enhancement with the addition of This check can be disabled with the option -fno-range-check We can do that, indeed. Reopening and marking enhancement. (2) I think the two cases are totally different: as soon as the compiler knows INF/NAN (and gfortran does), I think nearest(huge(1.0),1.0)==+Inf is part of the floating point model and should not throw even a warning (even with -std=xx -pedantic). I think the standard is very clear on that. Quoting F2003 13.7: A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters, unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible and there is support for an infinite or a NaN result, as appropriate. Unless we have IEEE_ARITHMETIC, we should stick to an error. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-04 12:34:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug c++/31411] [4.1/4.2/4.3 Regression] ICE in gimplify_expr with throw/special copy constructor with initializer with a deconstructor
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:08:14 |2007-09-04 12:39:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31411
[Bug tree-optimization/33301] New: wrong vectorization factor due to an invariant type-promotion in the loop
This testcase: gfortran.dg/g77/990115-1.f
ICEs when compiled with vectorization enabled:
gfortran 990115-1.f -O -pedantic-errors -S -O2 -ftree-vectorize -msse2
-fdump-tree-vect-details -g -o 990115-1.s
990115-1.f: In function 'zgelsx':^M
990115-1.f:3: internal compiler error: in vectorizable_type_promotion, at
tree-vect-transform.c:3959
This is because of this assumption in
tree-vect-analyze.c:vect_determine_vectorization_factor:
/* We set the vectype according to the type of the result (lhs).
For stmts whose result-type is different than the type of the
arguments (e.g. demotion, promotion), vectype will be reset
appropriately (later). Note that we have to visit the smallest
datatype in this function, because that determines the VF.
If the smallest datatype in the loop is present only as the
rhs of a promotion operation - we'd miss it here.
However, in such a case, that a variable of this datatype
does not appear in the lhs anywhere in the loop, it shouldn't
affect the vectorization factor. */
It so happens that we can have a situation in which the smallest type in the
loop nevers appears in the lhs: in the above testcase we have an invariant
type-promotion stmts that is not taken out of the loop before vectorization:
bb 4:
# i_1 = PHI 1(3), i_17(5)
D.1363_9 = (real8) s2_8(D);//--- HERE
D.1361_11 = ismax_5(D) + -2;
D.1362_12 = D.1361_11 + i_1;
CR.22_27 = REALPART_EXPR (*work_13(D))[D.1362_12];
CI.23_28 = IMAGPART_EXPR (*work_13(D))[D.1362_12];
CR.24_29 = D.1363_9 * CR.22_27;
CI.25_30 = D.1363_9 * CI.23_28;
REALPART_EXPR (*work_13(D))[D.1362_12] = CR.24_29;
IMAGPART_EXPR (*work_13(D))[D.1362_12] = CI.25_30;
i_17 = i_1 + 1;
if (i_1 == D.1355_3)
goto bb 6;
else
goto bb 5;
(Indeed when compiling also with --param lim-expensive=1, the invariant stmt is
taken out of the loop and the testcase passes).
I am testing the following patch:
Index: tree-vect-analyze.c
===
*** tree-vect-analyze.c (revision 128037)
--- tree-vect-analyze.c (working copy)
*** vect_determine_vectorization_factor (loo
*** 216,236
}
else
{
gcc_assert (! STMT_VINFO_DATA_REF (stmt_info)
!is_pattern_stmt_p (stmt_info));
! /* We set the vectype according to the type of the result (lhs).
For stmts whose result-type is different than the type of the
arguments (e.g. demotion, promotion), vectype will be reset
appropriately (later). Note that we have to visit the
smallest
datatype in this function, because that determines the VF.
If the smallest datatype in the loop is present only as the
rhs of a promotion operation - we'd miss it here.
!However, in such a case, that a variable of this datatype
!does not appear in the lhs anywhere in the loop, it shouldn't
!affect the vectorization factor. */
scalar_type = TREE_TYPE (GIMPLE_STMT_OPERAND (stmt, 0));
if (vect_print_dump_info (REPORT_DETAILS))
{
fprintf (vect_dump, get vectype for scalar type: );
--- 216,253
}
else
{
+ tree operation;
+
gcc_assert (! STMT_VINFO_DATA_REF (stmt_info)
!is_pattern_stmt_p (stmt_info));
! /* We generally set the vectype according to the type of the
!result (lhs).
For stmts whose result-type is different than the type of the
arguments (e.g. demotion, promotion), vectype will be reset
appropriately (later). Note that we have to visit the
smallest
datatype in this function, because that determines the VF.
If the smallest datatype in the loop is present only as the
rhs of a promotion operation - we'd miss it here.
!Such a case, where a variable of this datatype does not appear
!in the lhs anywhere in the loop, can only occur if it's an
!invariant: e.g.: 'int_x = (int) short_inv', which we'd expect
!to have been optimized away by invariant motion. However, we
!cannot rely on invariant motion to always take invariants out
!of the loop, and so in the case of promotion we also have to
!check the rhs. */
scalar_type = TREE_TYPE (GIMPLE_STMT_OPERAND (stmt, 0));
+ operation = GIMPLE_STMT_OPERAND (stmt, 1);
+ if (TREE_CODE (operation) == NOP_EXPR
+ || TREE_CODE (operation) == CONVERT_EXPR
+ || TREE_CODE (operation) == WIDEN_MULT_EXPR)
+ {
+ tree rhs_type = TREE_TYPE (TREE_OPERAND
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2007-09-04
13:04 ---
Quoting spread_generic.c:
145 for (n = 0; n ncopies; n++)
146{
147 memcpy (dest, sptr, size);
148 dest += rdelta;
149}
The C 99 Standard has the following to say about the mem* functions (7.21.2.1
ff):
Where an argument declared as size_t n specifies the length of the array for a
function, n can have the value zero on a call to that function. Unless
explicitly stated otherwise in the description of a particular function in this
subclause, pointer arguments on such a call shall still have valid values, as
described in 7.1.4.
So size can be zero, *but the the pointer arguments on such a call shall
still have valid values.*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #16 from aph at gcc dot gnu dot org 2007-09-04 14:00 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 14:00:06 2007
New Revision: 128082
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128082
Log:
2007-09-04 Andrew Haley [EMAIL PROTECTED]
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
Modified:
branches/gcj/gcj-eabi-branch/libjava/ChangeLog
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/PR27908.jar
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/PR27908.java
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug c++/31419] [4.1/4.2/4.3 regression] template user defined conversion operator instantiated for conversion to self
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-09 15:35:38 |2007-09-04 14:06:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug tree-optimization/33302] New: follow-up on bug 33291 dead-store not eliminated
This is a follow-up on bug 33291. It uses the same testcase (repeated here) but
with some additional optimization flags.
---
struct Clock {
void f();
void add(unsigned n) { a += n; }
int a;
};
struct CPU : Clock {
virtual ~CPU();
unsigned char readSlow();
void execute();
void delay() { add(2); }
unsigned char readFast() {
if (unsigned char* p = ptrs[addr 8]) {
// fast-path
delay();
delay();
return p[addr 255];
} else {
// slow-path
return readSlow();
}
}
typedef void (CPU::*FuncPtr)();
static FuncPtr tab[256];
unsigned char* ptrs[256];
unsigned addr;
};
void CPU::execute() {
f();
while (true) {
unsigned char b = readFast();
delay();
(this-*tab[b])();
}
}
When compiled with SVN revision 128074 on a linux x86_64 machine:
g++ -O3 -fforce-addr -ftracer -S CPU.ii
cat CPU.s
...
movl(%rbx), %eax
leal4(%rax), %edx
addl$6, %eax
movl%edx, (%rbx) dead store
movzbl (%r12), %edx
movzbl (%rcx,%rdx), %edx
movl%eax, (%rbx)
...
--
Summary: follow-up on bug 33291 dead-store not eliminated
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug c++/14178] doc bug: -fabi-version=2 is now default (not 1)
--- Comment #11 from paolo at gcc dot gnu dot org 2007-09-04 14:27 --- Subject: Bug 14178 Author: paolo Date: Tue Sep 4 14:27:05 2007 New Revision: 128085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128085 Log: 2007-09-04 Emmanuel Thome [EMAIL PROTECTED] PR c++/14178 * common.opt: Mention ABI version 2 in comment. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14178
[Bug c++/14178] doc bug: -fabi-version=2 is now default (not 1)
--- Comment #12 from pcarlini at suse dot de 2007-09-04 14:28 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14178
[Bug c++/14622] type mismatch in explicit template instantiation not detected
--- Comment #5 from pcarlini at suse dot de 2007-09-04 15:01 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14622
[Bug fortran/33303] New: Document __GFORTRAN__
I think __GFORTRAN__ is undocumented - at least I could not find any .texi where it is documented. I think it should be documented in doc/cpp.texi, possibly also in fortran/*texi. -- Summary: Document __GFORTRAN__ Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33303
[Bug fortran/33297] SIZE intrinsic crashes gfortran on invalid usage
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-04 15:25 --- integer array(5), i1, i2 print *, size(array,(/i1,i2/)) 13.7.112 SIZE (ARRAY [, DIM, KIND]) ARRAY may be of any type. It shall not be scalar. DIM (optional) shall be scalar and of type integer KIND (optional) shall be a scalar integer initialization expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33297
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #20 from jason at gcc dot gnu dot org 2007-09-04 15:43 --- Subject: Bug 14032 Author: jason Date: Tue Sep 4 15:43:00 2007 New Revision: 128090 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128090 Log: PR c++/14032 * pt.c (most_specialized_class): Substitute outer template arguments into the arguments of a member template partial specialization. (strip_innermost_template_args): New fn. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/mem-partial1.C - copied unchanged from r128077, trunk/gcc/testsuite/g++.dg/template/mem-partial1.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/mem-partial2.C - copied unchanged from r128077, trunk/gcc/testsuite/g++.dg/template/mem-partial2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug fortran/33303] Document __GFORTRAN__
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-04 16:02:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33303
[Bug bootstrap/33304] New: Bootstrap failure on solaris2 using cc due to empty macro arguments
I'm getting bootstrap failure with mainline on sparc-sun-solaris2.10 using cc for stage1. The failure occurs due to empty macro arguments. They occur in two places, one of which I've posted a patch for: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01131.html The second occurance is in c-common.c on line 2249 where it says: C_COMMON_FIXED_TYPES (, fract); Other instances occur below that in the same file. In another thread, I fixed an empty macro argument problem encountered when using gcc-2.8.1 for stage1 here: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01119.html According to Joseph later in that thread, empty macro arguments are undefined in ISO C90. Since we claim to only require ISO C90 to bootstrap, and because we want to ensure older versions of GCC continue to be usable to bootstrap, IMHO we should not allow empty macro arguments in the sources. -- Summary: Bootstrap failure on solaris2 using cc due to empty macro arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC host triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33304
[Bug preprocessor/33305] New: We should warn about empty macro arguments
As noted in PR33304, empty macro arguments can cause problems for ISO C90 compilers (solaris cc) as well as for older gcc versions like 2.8.1. Therefore I'd like to see cpp warn about these constructs either with -pedantic in C90 more and/or its own flag. We should use this warning during bootstrap to keep the sources bootstrappable when using compilers that have this issue. We have to fix the existing cases before we do that though. -- Summary: We should warn about empty macro arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org BugsThisDependsOn: 33304 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305
[Bug c++/29018] empty enum accepted
--- Comment #7 from pcarlini at suse dot de 2007-09-04 16:51 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug bootstrap/33306] New: [4.3 regression] Bootstrap failure on Tru64 UNIX V5.1B: ICE in convert_move, at expr.c:369
Bootstrapping current mainline as of 20070903 fails on alpha-dec-osf5.1b building the stage 1 libgcc: /vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/xgcc -B/vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/ -B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem /vol/gcc/alpha-dec-osf5.1b/include -isystem /vol/gcc/alpha-dec-osf5.1b/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -mieee -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/vol/gcc/src/gcc-dist/libgcc -I/vol/gcc/src/gcc-dist/libgcc/. -I/vol/gcc/src/gcc-dist/libgcc/../gcc -I/vol/gcc/src/gcc-dist/libgcc/../include -DHAVE_CC_TLS -o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c \ /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__powitf2': /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:1742: internal compiler error: in convert_move, at expr.c:369 The same problem happens at -O, while -O0 is ok. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap mainline as described above. -- Summary: [4.3 regression] Bootstrap failure on Tru64 UNIX V5.1B: ICE in convert_move, at expr.c:369 Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug c++/29018] empty enum accepted
--- Comment #8 from pcarlini at suse dot de 2007-09-04 17:47 ---
Hummm, with reference to the patch in Comment #9: I don't think 'enum { };' is
flagged in the standard as ill-formed because of the empty enumerator-list
(that possibility is explicitly discussed in 7.2/5), but because the enum
doesn't have a name. In other terms, the example is ill-formed for the very
same reason anonymous structs are a GNU extension. In yet other terms, it seems
to me we have got an anonymous enum extension, which probably we want to
diagnose when pedantic.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug c++/29018] empty enum accepted
--- Comment #9 from pcarlini at suse dot de 2007-09-04 17:53 --- Humm, no, anonymous enums are clearly legal, sorry about the stupid mistake. Still, it's not completely clear to me the discussion in 7.2/5 of empty enumerator-lists, evidently, we must assume those are illegal *only* when the enum is simultaneously anonymous (and the patch in Comment #2 is therefore incomplete, not completely wrong, sorry about the misunderstanding). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #17 from aph at gcc dot gnu dot org 2007-09-04 17:55 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 17:54:56 2007
New Revision: 128094
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128094
Log:
2007-09-04 Andrew Haley [EMAIL PROTECTED]
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
Added:
trunk/libjava/testsuite/libjava.lang/Foo.class
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/Foo.class
trunk/libjava/testsuite/libjava.lang/WalkerTest.jar
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.jar
trunk/libjava/testsuite/libjava.lang/WalkerTest.java
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.java
trunk/libjava/testsuite/libjava.lang/WalkerTest.out
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.out
Modified:
trunk/libjava/testsuite/libjava.lang/PR27908.jar
trunk/libjava/testsuite/libjava.lang/PR27908.java
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #18 from aph at gcc dot gnu dot org 2007-09-04 17:58 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 17:57:52 2007
New Revision: 128097
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128097
Log:
2007-09-04 Andrew Haley [EMAIL PROTECTED]
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
2007-08-29 Andrew Haley [EMAIL PROTECTED]
* gnu/classpath/natVMStackWalker.cc (VMStackWalker::getCallingClass):
Make sure we're not sibcalled.
(GET_CALLING_CLASS): Define for ARM EABI.
2007-08-22 Andrew Haley [EMAIL PROTECTED]
* configure.host (BACKTRACESPEC): Add arm*-linux*.
2007-08-22 Andrew Haley [EMAIL PROTECTED]
* configure.ac (LIBSTDCXXSPEC): New.
* configure.host: Add arm*-linux* to pthread test.
* configure.ac (LIBGCJTESTSPEC): Add path to libstdc++ for ARM
EABI.
* testsuite/libjava.jni/jni.exp (gcj_jni_compile_c_to_so): Use
-fexceptions for ARM EABI.
* testsuite/lib/libjava.exp (libjava_arguments): Add libgcj-test.spec.
(libjava_invoke): Log the invocation.
2007-08-15 Andrew Haley [EMAIL PROTECTED]
* configure.ac (extra_ldflags): Define.
* Makefile.am: Use extra_ldflags for all executables.
2007-08-14 Andrew Haley [EMAIL PROTECTED]
* sysdep/arm/backtrace.h: Remove stubs for _Unwind_GetIPInfo,
_Unwind_GetRegionStart, and _Unwind_Backtrace.
2007-07-27 Andrew Haley [EMAIL PROTECTED]
* gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): Stub for
ARM EABI.
* exception.cc (get_exception_header_from_ue): New.
(get_ttype_entry): ARM EABI version.
(PERSONALITY_FUNCTION): Add ARM EABI code.
* sysdep/arm/backtrace.h: New file.
* stacktrace.cc (_URC_NORMAL_STOP): New.
* configure.ac (extra_ldflags_libjava): Add libsupc++.la for ARM
EABI.
* configure.host (BACKTRACESPEC): Add arm/backtrace.h.
Modified:
trunk/libjava/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #19 from aph at gcc dot gnu dot org 2007-09-04 18:00 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 18:00:31 2007
New Revision: 128098
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128098
Log:
2007-09-04 Andrew Haley [EMAIL PROTECTED]
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
2007-08-29 Andrew Haley [EMAIL PROTECTED]
* gnu/classpath/natVMStackWalker.cc (VMStackWalker::getCallingClass):
Make sure we're not sibcalled.
(GET_CALLING_CLASS): Define for ARM EABI.
2007-08-22 Andrew Haley [EMAIL PROTECTED]
* configure.host (BACKTRACESPEC): Add arm*-linux*.
2007-08-22 Andrew Haley [EMAIL PROTECTED]
* configure.ac (LIBSTDCXXSPEC): New.
* configure.host: Add arm*-linux* to pthread test.
* configure.ac (LIBGCJTESTSPEC): Add path to libstdc++ for ARM
EABI.
* testsuite/libjava.jni/jni.exp (gcj_jni_compile_c_to_so): Use
-fexceptions for ARM EABI.
* testsuite/lib/libjava.exp (libjava_arguments): Add libgcj-test.spec.
(libjava_invoke): Log the invocation.
2007-08-15 Andrew Haley [EMAIL PROTECTED]
* configure.ac (extra_ldflags): Define.
* Makefile.am: Use extra_ldflags for all executables.
2007-08-14 Andrew Haley [EMAIL PROTECTED]
* sysdep/arm/backtrace.h: Remove stubs for _Unwind_GetIPInfo,
_Unwind_GetRegionStart, and _Unwind_Backtrace.
2007-07-27 Andrew Haley [EMAIL PROTECTED]
* gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): Stub for
ARM EABI.
* exception.cc (get_exception_header_from_ue): New.
(get_ttype_entry): ARM EABI version.
(PERSONALITY_FUNCTION): Add ARM EABI code.
* sysdep/arm/backtrace.h: New file.
* stacktrace.cc (_URC_NORMAL_STOP): New.
* configure.ac (extra_ldflags_libjava): Add libsupc++.la for ARM
EABI.
* configure.host (BACKTRACESPEC): Add arm/backtrace.h.
Added:
trunk/libjava/sysdep/arm/backtrace.h
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/sysdep/arm/backtrace.h
Modified:
trunk/libjava/Makefile.am
trunk/libjava/Makefile.in
trunk/libjava/configure
trunk/libjava/configure.ac
trunk/libjava/configure.host
trunk/libjava/exception.cc
trunk/libjava/gcj/Makefile.in
trunk/libjava/gnu/classpath/natVMStackWalker.cc
trunk/libjava/include/Makefile.in
trunk/libjava/libgcj.spec.in
trunk/libjava/stacktrace.cc
trunk/libjava/testsuite/Makefile.in
trunk/libjava/testsuite/lib/libjava.exp
trunk/libjava/testsuite/libjava.jni/jni.exp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug bootstrap/33100] [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #1 from ro at gcc dot gnu dot org 2007-09-04 18:10 --- Confirmed on i386-pc-solaris2.10. This is a mainline regression. A reghunt revealed that this patch 2007-08-06 H.J. Lu [EMAIL PROTECTED] Daniel Jacobowitz [EMAIL PROTECTED] PR target/31868 * config.gcc (x86_64-*-freebsd*): Add i386/t-crtstuff to tmake_file. (x86_64-*-netbsd*): Likewise. (x86_64-*-linux*): Likewise. (x86_64-*-kfreebsd*-gnu): Likewise. (x86_64-*-knetbsd*-gnu): Likewise. (i[34567]86-*-solaris2.1[0-9]*): Likewise. is the culprit: running elfdump on the amd64 crtend.o before and after the patch, I find (before): Unwind Section: .eh_frame CIE: [0x] length: 0x00 cieid: 0 version: 0 augstring: `' codealign: 0x0 dataalign: 0 retaddr: 0 vs. (after): Unwind Section: .eh_frame FDE: [0x] length: 0x00 cieptr: 0x18 initloc: 0x addrrange: 0x Auxiliary vals: CIE: [0x0004] length: 0x18 cieid: 0 version: 1 augstring: `zR' codealign: 0x1 dataalign: -8 retaddr: 16 So the linker seems to be right to complain about this. Rainer -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-04 18:10:17 date|| Summary|on bootstrap getting section|[4.3 regression] on |.eh_frame: bad cie version |bootstrap getting section |0: offset 0x0 |.eh_frame: bad cie version ||0: offset 0x0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #7 from pault at gcc dot gnu dot org 2007-09-04 18:16 --- To my surprise, I have a fix for this one. I'll post it to the list in the next 48 hours. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-22 18:49:14 |2007-09-04 18:16:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #5 from pault at gcc dot gnu dot org 2007-09-04 18:17 --- A fix for this one is coming with that for PR31564 - within 48 hours. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-30 13:40:52 |2007-09-04 18:17:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug c++/31411] [4.1/4.2/4.3 Regression] ICE in gimplify_expr with throw/special copy constructor with initializer with a deconstructor
--- Comment #8 from jason at gcc dot gnu dot org 2007-09-04 18:37 --- Subject: Bug 31411 Author: jason Date: Tue Sep 4 18:37:33 2007 New Revision: 128100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128100 Log: PR c++/31411 * except.c (initialize_handler_parm): Put a CLEANUP_POINT_EXPR inside the MUST_NOT_THROW_EXPR. Added: trunk/gcc/testsuite/g++.dg/eh/catch5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31411
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #4 from ubizjak at gmail dot com 2007-09-04 19:03 --- (In reply to comment #3) Uros, do you think we could, in the fold_convert() switch on TREE_CODE(type), add a case for RECORD_TYPE similar to VECTOR_TYPE: assert that both RECORD_TYPEs have the same size, and that their fields correspond one-to-one, and then create a VIEW_CONVERT_EXPR? Do you think it would be worth having or would that hurt the middle-end in any way? This is not exactly the part of gcc I'm familiar with (and c never generates RECORD_TYPEs), but I think that this problem should be fixed in fortran/trans-expr.c. At least according to the comment above fold_convert(), this conversion should be handled in front-end convert function. The patch below (similar to your proposal, with minimal checking) works in the sense that the compilation doesn't break, and generated code doesn't create a black hole at runtime, but I have no idea if it is correct (fortran) transformation. Also, we will break here if sizes are not equal. Index: fold-const.c === --- fold-const.c(revision 128092) +++ fold-const.c(working copy) @@ -2616,6 +2616,10 @@ || TREE_CODE (orig) == VECTOR_TYPE); return fold_build1 (VIEW_CONVERT_EXPR, type, arg); +case RECORD_TYPE: + gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig))); + return fold_build1 (VIEW_CONVERT_EXPR, type, arg); + case VOID_TYPE: tem = fold_ignored_result (arg); if (TREE_CODE (tem) == GIMPLE_MODIFY_STMT) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #5 from pinskia at gmail dot com 2007-09-04 19:08 --- Subject: Re: ICE in fold_const.c (fold_convert) when reordering USE statements On 4 Sep 2007 19:03:39 -, ubizjak at gmail dot com [EMAIL PROTECTED] wrote: and c never generates RECORD_TYPEs Yes it does. Structs in C are done as RECORD_TYPEs. This code is just plainly wrong really. fold_convert should not handle RECORD_TYPEs. And if does, it is not going to help with optimizations anyways. The Fortran front-end has to better keep track of modules and types inside modules to get this correct. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #9 from dje at gcc dot gnu dot org 2007-09-04 19:11 --- By the way, nint_2.f90 also fails at -O0 on AIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-04 19:11 ---
I'm testing this patch:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 128037)
--- tree-vect-transform.c (working copy)
*** vect_create_epilog_for_reduction (tree v
*** 1964,1969
--- 1964,1971
tree operation = GIMPLE_STMT_OPERAND (stmt, 1);
bool nested_in_vect_loop = false;
int op_type;
+ VEC(tree,heap) *phis = NULL;
+ int i;
if (nested_in_vect_loop_p (loop, stmt))
{
*** vect_finalize_reduction:
*** 2260,2270
epilog_stmt = build_gimple_modify_stmt (new_dest, expr);
new_temp = make_ssa_name (new_dest, epilog_stmt);
GIMPLE_STMT_OPERAND (epilog_stmt, 0) = new_temp;
- #if 0
- bsi_insert_after (exit_bsi, epilog_stmt, BSI_NEW_STMT);
- #else
bsi_insert_before (exit_bsi, epilog_stmt, BSI_SAME_STMT);
- #endif
}
--- 2262,2268
*** vect_finalize_reduction:
*** 2274,2318
Find the loop-closed-use at the loop exit of the original scalar result.
(The reduction result is expected to have two immediate uses - one at
the
latch block, and one at the loop exit). */
! exit_phi = NULL;
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, scalar_dest)
{
if (!flow_bb_inside_loop_p (loop, bb_for_stmt (USE_STMT (use_p
{
exit_phi = USE_STMT (use_p);
! break;
}
}
/* We expect to have found an exit_phi because of loop-closed-ssa form. */
! gcc_assert (exit_phi);
! if (nested_in_vect_loop)
{
! stmt_vec_info stmt_vinfo = vinfo_for_stmt (exit_phi);
! /* FORNOW. Currently not supporting the case that an inner-loop
reduction
!is not used in the outer-loop (but only outside the outer-loop). */
! gcc_assert (STMT_VINFO_RELEVANT_P (stmt_vinfo)
! !STMT_VINFO_LIVE_P (stmt_vinfo));
!
! epilog_stmt = adjustment_def ? epilog_stmt : new_phi;
! STMT_VINFO_VEC_STMT (stmt_vinfo) = epilog_stmt;
! set_stmt_info (get_stmt_ann (epilog_stmt),
! new_stmt_vec_info (epilog_stmt, loop_vinfo));
! if (vect_print_dump_info (REPORT_DETAILS))
! {
! fprintf (vect_dump, vector of partial results after inner-loop:);
! print_generic_expr (vect_dump, epilog_stmt, TDF_SLIM);
! }
! return;
}
-
- /* Replace the uses: */
- orig_name = PHI_RESULT (exit_phi);
- FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, orig_name)
- FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
- SET_USE (use_p, new_temp);
}
--- 2272,2313
Find the loop-closed-use at the loop exit of the original scalar result.
(The reduction result is expected to have two immediate uses - one at
the
latch block, and one at the loop exit). */
! phis = VEC_alloc (tree, heap, 10);
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, scalar_dest)
{
if (!flow_bb_inside_loop_p (loop, bb_for_stmt (USE_STMT (use_p
{
exit_phi = USE_STMT (use_p);
! VEC_quick_push (tree, phis, exit_phi);
}
}
/* We expect to have found an exit_phi because of loop-closed-ssa form. */
! gcc_assert (!VEC_empty (tree, phis));
! for (i = 0; VEC_iterate (tree, phis, i, exit_phi); i++)
{
! if (nested_in_vect_loop)
! {
! stmt_vec_info stmt_vinfo = vinfo_for_stmt (exit_phi);
! /* FORNOW. Currently not supporting the case that an inner-loop
reduction
!is not used in the outer-loop (but only outside the outer-loop).
*/
! gcc_assert (STMT_VINFO_RELEVANT_P (stmt_vinfo)
! !STMT_VINFO_LIVE_P (stmt_vinfo));
!
! epilog_stmt = adjustment_def ? epilog_stmt : new_phi;
! STMT_VINFO_VEC_STMT (stmt_vinfo) = epilog_stmt;
! set_stmt_info (get_stmt_ann (epilog_stmt),
! new_stmt_vec_info (epilog_stmt, loop_vinfo));
! continue;
! }
! /* Replace the uses: */
! orig_name = PHI_RESULT (exit_phi);
! FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, orig_name)
! FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
! SET_USE (use_p, new_temp);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
--- Comment #4 from dorit at gcc dot gnu dot org 2007-09-04 19:14 --- (by the way, fast-math should not be required here, but that's a different bug... will fix that soonish) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug target/31325] gcj support for ARM EABI
--- Comment #22 from aph at gcc dot gnu dot org 2007-09-04 19:14 --- Done. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug fortran/33307] New: I/O read/positioning problem
The attached program exhibits a strange problem with gfortran when repeatedly trying to position within an input file, and which I have been hunting for a long time. The program is supposed to work as follows: - open input file - do - rewind - repeatedly search for lines containing a special text - end do The program always succeeds in finding the occurence of the first text, but fails to find the second text if the first text does *not* occur on the first text line. Example 1: % cat gfcbug69.nml ! ***Remove this line*** FOOfile='foo' / BARfile='bar' / % gfc -g -Wall -std=f2003 gfcbug69.f90 % ./a.out inquire: after OPEN: position = ASIS nextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: FOO position_nml: SUCCESS! line= FOOfile='foo' / inquire: after position_nml: position = ASIS nextrec = 0 *** Found: FOOfile='foo' / position_nml: Scanning for: FOO position_nml: FAIL: ios= -1 inquire: after position_nml: position = APPENDnextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: BAR position_nml: FAIL: ios= -1 inquire: after position_nml: position = REWINDnextrec = 0 -- Removing the indicated line from the text file leads to: % ./a.out inquire: after OPEN: position = ASIS nextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: FOO position_nml: SUCCESS! line= FOOfile='foo' / inquire: after position_nml: position = REWINDnextrec = 0 *** Found: FOOfile='foo' / position_nml: Scanning for: FOO position_nml: FAIL: ios= -1 inquire: after position_nml: position = APPENDnextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: BAR position_nml: SUCCESS! line= BARfile='bar' / inquire: after position_nml: position = ASIS nextrec = 0 *** Found: BARfile='bar' / position_nml: Scanning for: BAR position_nml: FAIL: ios= -1 inquire: after position_nml: position = ASIS nextrec = 0 -- Comparing the two results shows: % diff -u out.fail out.success --- out.fail2007-09-04 21:31:22.0 +0200 +++ out.success 2007-09-04 21:31:14.0 +0200 @@ -4,7 +4,7 @@ position_nml: Scanning for: FOO position_nml: SUCCESS! line= FOOfile='foo' / -inquire: after position_nml: position = ASIS nextrec = 0 +inquire: after position_nml: position = REWINDnextrec = 0 *** Found: FOOfile='foo' / @@ -15,6 +15,12 @@ inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: BAR +position_nml: SUCCESS! line= BARfile='bar' / +inquire: after position_nml: position = ASIS nextrec = 0 + + *** Found: BARfile='bar' / + +position_nml: Scanning for: BAR position_nml: FAIL: ios= -1 -inquire: after position_nml: position = REWINDnextrec = 0 +inquire: after position_nml: position = ASIS nextrec = 0 -- For some reason the file position after attempting to find the second text is still REWIND. This may only be a cosmetic problem, but it could be a hint towards the source of the problem. -- Summary: I/O read/positioning problem Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
[Bug fortran/33307] I/O read/positioning problem
--- Comment #1 from anlauf at gmx dot de 2007-09-04 20:00 --- Created an attachment (id=14156) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14156action=view) Demo code Use with the file gfcbug69.nml from the bug description (3 lines), and compare with a run with the first line of gfcbug69.nml removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
[Bug c++/31419] [4.1/4.2/4.3 regression] template user defined conversion operator instantiated for conversion to self
--- Comment #6 from jason at gcc dot gnu dot org 2007-09-04 20:18 --- Subject: Bug 31419 Author: jason Date: Tue Sep 4 20:18:05 2007 New Revision: 128102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128102 Log: PR c++/31419 * call.c (reference_binding): Don't look for user-defined conversions to the same type. Added: trunk/gcc/testsuite/g++.dg/conversion/self1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-09-04 21:03 --- This one should be fairly straightforward. Mine :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-04 10:51:29 |2007-09-04 21:03:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug libgcj/33278] [4.3 Regression] libjava fails to compile if configure argument contains version
--- Comment #3 from doko at gcc dot gnu dot org 2007-09-04 21:32 --- Subject: Bug 33278 Author: doko Date: Tue Sep 4 21:32:41 2007 New Revision: 128104 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128104 Log: 2007-09-05 Matthias Klose [EMAIL PROTECTED] PR libgcj/33278 * configure.ac: Robustify extraction of gcj version. * configure: Regenerate. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug fortran/33308] New: gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
I got ICE on i686-pc-linux-gnu, x86_64-unknown-linux-gnu and ia64-unknown-linux-gnu with gfortran 4.2.1. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.1 $ cat reshapetest.f90 ! reshapetest.f90 -*-f90-*- !! function f() implicit none real*8 :: f(3,3) f(:,:) = 1.0d0 end function f program reshapetest implicit none real*8, allocatable :: c(:,:) real*8, parameter :: one(3,3) = reshape((/1.0d0, 0.0d0, 0.0d0, 0.0d0, 1.0d0, 0.0d0, 0.0d0, 0.0d0, 1.0d0/),(/3,3/)) interface function f() implicit none real*8 :: f(3,3) end function f end interface allocate(c(3,3)) c(:,:) = one(:,:) + f() ! internal compiler error write(6,'(3f4.1)') c(:,:) end program reshapetest $ gfortran reshapetest.f90 reshapetest.f90: In function 'MAIN__': reshapetest.f90:21: internal compiler error: in gfc_trans_array_constructor, at fortran/trans-array.c:1467 : $ g95 reshapetest.f90 $ ./a.out 2.0 1.0 1.0 1.0 2.0 1.0 1.0 1.0 2.0 -- Summary: gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t_nissie at yahoo dot co dot jp GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug fortran/33308] gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
--- Comment #1 from t_nissie at yahoo dot co dot jp 2007-09-04 21:54 --- Created an attachment (id=14157) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14157action=view) compile: gfortran reshapetest.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug fortran/33308] gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-04 22:00 --- This works on the trunk (which is 4.3.0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug tree-optimization/33017] [4.3 Regression] tree check fail for legal code
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-04 23:30 --- Subject: Bug 33017 Author: jakub Date: Tue Sep 4 23:29:58 2007 New Revision: 128107 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128107 Log: PR tree-optimization/33017 * tree-data-ref.c (split_constant_offset) case SSA_NAME: Don't recurse for pure or const function calls. * gcc.dg/pr33017.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr33017.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #11 from jakub at gcc dot gnu dot org 2007-09-04 23:31 --- Subject: Bug 32300 Author: jakub Date: Tue Sep 4 23:31:11 2007 New Revision: 128108 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128108 Log: PR rtl-optimization/32300 * see.c (see_copy_insn): New function. (see_def_extension_not_merged, see_merge_one_use_extension, see_merge_one_def_extension): Use it. Avoid changing PREV_INSN/NEXT_INSN chains directly, insted emit insns into sequences. Call df_insn_delete on temporary insns that won't be emitted into the insn stream. (rest_of_handle_see): Turn off DF_DEFER_INSN_RESCAN and run df_process_deferred_rescans () before run_fast_dce. Modified: trunk/gcc/ChangeLog trunk/gcc/see.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug tree-optimization/33017] [4.3 Regression] tree check fail for legal code
--- Comment #5 from jakub at gcc dot gnu dot org 2007-09-04 23:35 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #12 from jakub at gcc dot gnu dot org 2007-09-04 23:37 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug fortran/33307] I/O read/positioning problem
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-09-05 00:11 --- I have been waiting for this to emerge. We knew there was a problem somewhere. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-05 00:11:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
[Bug tree-optimization/32544] [4.2 Regression] miscompiles Mesa's r300 DRI driver with -ftree-vrp
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
[Bug middle-end/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2007-09-05 00:51 --- Subject: Bug 33225 Author: jvdelisle Date: Wed Sep 5 00:51:18 2007 New Revision: 128114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128114 Log: 2007-03-04 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/33225 * io/write.c (stdbool.h): Add include. (sign_t): Move typedef to new file write_float.def. Include write_float.def. (extract_real): Delete. (calculate_sign): Delete. (calculate_exp): Delete. (calculate_G_format): Delete. (output_float): Delete. (write_float): Delete. * io/write_float.def (calculate_sign): Added. (output_float): Refactored to be independent of kind and added to this file for inclusion. (write_infnan): New function to write Infinite or NaN depending on flags passed, independent of kind. (CALCULATE_EXP): New macro to build kind specific functions. Use it. (OUTPUT_FLOAT_FMT_G): New macro, likewise. Use it. (DTOA, DTOAL): Macros to implement decimal to ascii. (WRITE_FLOAT): New macro for kind specific write_float functions. (write_float): Revised function to determine kind and use WRITE_FLOAT to implement kind specific output. Added: trunk/libgfortran/io/write_float.def Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #13 from mmitchel at gcc dot gnu dot org 2007-09-05 00:58 --- Do we have any way to work out whether this is still a problem? Richard seems to think the bug has been fixed, but Pascal is still seeing the problem, apparently. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-09-05 01:00 --- Ian, I know that we talked about this on the mailing list at one point. Did this get resolved? Does changing the assert to check DECL_EXTERNAL_LINKAGE_P instead of DECL_EXTERNAL help? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug bootstrap/33309] New: gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualif iers from pointer target type
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -g -O2 -DIN_GCC -W
-Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common
-DHAV
E_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/gnu64/gcc/gcc-4.3.0/include
-I../../gc
c/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
\
-DSTANDARD_STARTFILE_PREFIX=\../../../\
-DSTANDARD_EXEC_PREFIX=\/opt/gnu64/
gcc/gcc-4.3.0/lib/gcc/\
-DSTANDARD_LIBEXEC_PREFIX=\/opt/gnu64/gcc/gcc-4.3.0/li
bexec/gcc/\ -DDEFAULT_TARGET_VERSION=\4.3.0\
-DDEFAULT_TARGET_MACHINE=\hppa6
4-hp-hpux11.11\ -DSTANDARD_BINDIR_PREFIX=\/opt/gnu64/gcc/gcc-4.3.0/bin/\
-DTO
OLDIR_BASE_PREFIX=\../../../../\ `test X${SHLIB_LINK} = X || test yes
!
= yes || echo -DENABLE_SHARED_LIBGCC` \
-c ../../gcc/gcc/gcc.c -o gcc.o)
cc1: warnings being treated as errors
../../gcc/gcc/gcc.c: In function 'main':
../../gcc/gcc/gcc.c:6236: error: passing argument 1 of 'xputenv' discards
qualif
iers from pointer target type
Ugh.
--
Summary: gcc.c:6236: error: passing argument 1 of 'xputenv'
discards qualif
iers from pointer target type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa64-hp-hpux11*
GCC host triplet: hppa64-hp-hpux11*
GCC target triplet: hppa64-hp-hpux11*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #25 from mmitchel at gcc dot gnu dot org 2007-09-05 01:08 --- It's not clear to me what's going on in this PR. At one point, Jakub seems to be saying that 4.2 does a better job than 4.1, which would suggest that this is just a 4.1.x PR? Can we split this into one PR for 4.1-only issues, and another one or two, for 4.2 and/or 4.3 issues? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug middle-end/33195] [4.2 Regression] ICE: calc_dfs_tree, at dominance.c:374
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33195
