[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #6 from uros at kss-loka dot si 2005-11-15 08:13 ---
Perhaps a runtime check should be added to target-supports.exp
( check_effective_target_tls-runtime perhaps) that would check if the system is
capable of running tls enabled binaries. Alternatively, my proposed patch
(http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00963.html) could try to run the
tls testcase, instead of just compiling it.
However, addind { dg-require-effective-target tls-runtime }, runtime tests will
also be skipped on the system that is otherwise able to compile testcases.
The job of compiler is IMO to compile sources correctly, and the purpose of
runtime test is to check if the system is able to run testcases. Runtime
failure, reported here, just says that the tested system is not able to run the
testcase and that the system should be upgraded/fixed.
--
uros at kss-loka dot si changed:
What|Removed |Added
CC||uros at kss-loka dot si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug other/24870] New: make check fails for fixincl
Running make check in fixincludes on x86_64-gnu-linux I get the following failure: Fixed: Xm/Traversal.h cmp: EOF on string.h *** string.h2005-11-10 12:25:31.0 +0100 --- /cvs/gcc-svn/trunk/fixincludes/tests/base/string.h 2005-11-10 12:23:56.0 +0100 *** *** 10,13 #ifndef _STRING_INCLUDED #define _STRING_INCLUDED #include strings.h ! #endif /* _STRING_INCLUDED */ \ No newline at end of file --- 10,13 #ifndef _STRING_INCLUDED #define _STRING_INCLUDED #include strings.h ! #endif /* _STRING_INCLUDED */ -- Summary: make check fails for fixincl Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aj at gcc dot gnu dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24870
[Bug other/24870] make check fails for fixincl
--- Comment #1 from aj at gcc dot gnu dot org 2005-11-15 08:14 --- Jim Wilson commented in http://gcc.gnu.org/ml/gcc/2005-11/msg00619.html: Just grepping for _STRING_INCLUDED it is easy to see the input rule in inclhack.def that defines this transformation, and the output rule in fixincl.x that actually does the transformation. This seems to be a generic problem. Anything using the replace = shell input type rule is ending up with a missing newline on the last line. Looking at gcc-3.3.4, I see that the trailing newline is there in the fixincl.x file, but it isn't there in mainline. Offhand, I don't know what changed here. It could be that autogen changed, it could be that something in fixincluded changed, or it could even be that someone checked in the result of a broken autogen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24870
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #21 from debian-gcc at lists dot debian dot org 2005-11-15 08:28 --- (In reply to comment #20) Could people check if the problem was indeed fixed where reported? bootstrap ok on alpha-linux Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug c++/24849] [gomp] ICE in expand_expr_real_1
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-15 08:59 --- The problem here is a mismatch between determine_parallel_type in gimplify.c and omp-low.c. During gimplification, it is not considered to be a combined parallel loop, because OMP_PARALLEL's body contains a DECL_EXPR (for m variable) before OMP_FOR. But during omp lowering, that DECL_EXPR is already gone and therefore the loop is handled as a combined loop. But there are statements before the FOR_STMT inside of OMP_FOR, and those are moved into a wrong context when doing a parallel loop. Maybe we should ignore (some?) DECL_EXPRs in determine_parallel_type, maybe we need to note the combined parallel status in OMP_PARALLEL's flags. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24849
[Bug c++/24849] [gomp] ICE in expand_expr_real_1
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 09:07
---
Some more information:
- I didn't encounter the bug about a week ago
- on x86_64 with checking disabled, I get
[EMAIL PROTECTED]:~/martin g++ -c -v -fopenmp test.cc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/guest/martin/gompcc/configure --quiet
--prefix=/home/guest/martin/ugccgomp --disable-checking
--enable-languages=c++,fortran --with-gmp=/home/guest/martin/mygmp
Thread model: posix
gcc version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged
20051109)
/home/guest/martin/ugccgomp/libexec/gcc/x86_64-unknown-linux-gnu/4.1.0-gomp-20050608-branch/cc1plus
-quiet -v -D_GNU_SOURCE test.cc -quiet -dumpbase test.cc -mtune=k8 -auxbase
test -version -fopenmp -o /tmp/ccH4pPJ3.s
ignoring nonexistent directory
/home/guest/martin/ugccgomp/lib/gcc/x86_64-unknown-linux-gnu/4.1.0-gomp-20050608-branch/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/guest/martin/ugccgomp/lib/gcc/x86_64-unknown-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-gomp-20050608-branch
/home/guest/martin/ugccgomp/lib/gcc/x86_64-unknown-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-gomp-20050608-branch/x86_64-unknown-linux-gnu
/home/guest/martin/ugccgomp/lib/gcc/x86_64-unknown-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-gomp-20050608-branch/backward
/usr/local/include
/home/guest/martin/ugccgomp/include
/home/guest/martin/ugccgomp/lib/gcc/x86_64-unknown-linux-gnu/4.1.0-gomp-20050608-branch/include
/usr/include
End of search list.
GNU C++ version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged
20051109) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.1.0-gomp-20050608-branch 20051109
(experimental) (merged 20051109).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 77b131b8a7d189e4ba7ca911c1f9b018
test.cc: In member function รข:
test.cc:10: error: insn does not satisfy its constraints:
(insn 14 13 38 (set (reg:DI 0 ax [orig:58 D.2187 ] [58])
(sign_extend:DI (reg:SI 77 [ D.2153 ]))) 115 {extendsidi2_rex64} (nil)
(nil))
test.cc:10: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24849
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #7 from joseph at codesourcery dot com 2005-11-15 09:23 --- Subject: Re: gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32 On Tue, 15 Nov 2005, uros at kss-loka dot si wrote: The job of compiler is IMO to compile sources correctly, and the purpose of runtime test is to check if the system is able to run testcases. Runtime No, it is to check if the compiler generated correct code for the testcases. If this fact cannot be tested because of system limitations the result should be UNSUPPORTED, whereas if it can be tested and the code was incorrect it should be FAIL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions
-- pcarlini at suse dot de changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/24645] Commonize arithmetic inserters/extractors bodies
-- 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 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24645
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #3 from debian-gcc at lists dot debian dot org 2005-11-15 10:50 --- (In reply to comment #2) I'll take care of it. Arno can this be updated before the branch is created? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug target/24869] [4.1 regression] testsuite failure: gfortran.dg/func_derived_1.f90 -O3 unroll-loops
--- Comment #1 from hp at gcc dot gnu dot org 2005-11-15 10:52 --- Subject: Bug 24869 Author: hp Date: Tue Nov 15 10:52:06 2005 New Revision: 106946 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106946 Log: PR target/24869 * config/cris/cris.md (*mov_sidesisf_mem): Do not match special register for operand 3. Reindent constraints to align them vertically. Modified: trunk/gcc/ChangeLog trunk/gcc/config/cris/cris.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24869
[Bug target/24869] [4.1 regression] testsuite failure: gfortran.dg/func_derived_1.f90 -O3 unroll-loops
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-15 10:56 --- Fixed: URL:http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01055.html. -- hp at gcc dot gnu 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=24869
[Bug bootstrap/24873] New: gcc 4.0.2 bootstrap report compare fail
i bootstrap gcc 4.0.2 on AIX 5.2,i got the error message as follows: - Bootstrap comparison failure! ./fold-const.o differs make[1]: *** [slowcompare] Error 1 make[1]: Leaving directory `/swtdata/emv_emu/emu1/jbgao/objdir/gcc' make: *** [bootstrap] Error 2 -- i used gnu make already. is this a bug or anything else? -- Summary: gcc 4.0.2 bootstrap report compare fail Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gaojianbin at 263 dot net GCC host triplet: gcc 4.0.2 bootstrap report compare fail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24873
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #4 from charlet at adacore dot com 2005-11-15 11:04 --- Subject: Re: [ada] Library_Version still at 4.0 ? can this be updated before the branch is created? Will commit the patch later today or tomorrow. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #5 from pluto at agmk dot net 2005-11-15 11:16 --- what about soext in gcc41/gcc/ada/Makefile.in? there is still soext = .so is ada abi compatible in gcc 3.3 ... 4.1 ? -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #6 from charlet at adacore dot com 2005-11-15 11:22 --- Subject: Re: [ada] Library_Version still at 4.0 ? what about soext in gcc41/gcc/ada/Makefile.in? there is still soext = .so is ada abi compatible in gcc 3.3 ... 4.1 ? You seem to be confused: soext is about the extension not about soname which is already handled by Library_Version. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #7 from debian-gcc at lists dot debian dot org 2005-11-15 11:42 --- PR23750 is related -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug libstdc++/24469] Possible race condition in mt_allocator causing SIGSEGV
--- Comment #3 from pcarlini at suse dot de 2005-11-15 12:02 --- 2- Otherwise, a lock in _M_reclaim_block only when __block-_M_thread_id != __thread_id. At the same time has to be changed _M_reserve_block too, however, and it's tricky to do that without locking at every single allocation: maybe, changing slightly the algorithm, an entire pool of blocks can be marked as used when obtained from operator new or the global list (at the beginning of _M_reserve_block). Hi again. I mean to draft a version of this fix. Can you test it together with the application which leads to SIGSEGVs? I don't think I have ready at hand a testcase really stressing the allocator for this issue... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24469
[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-11-15 12:14 --- (In reply to comment #7) We should bump the library file's version number. Could we get a gcc-admin script to change the library's version everyday with version numbers like 0.0.20051115 and so on? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
[Bug objc/24867] many N^2 loops in objc frontend
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:20 --- It would be useful to to either have separate bugs for these issues, or to list them all in the audit trail of this bug. Without more information, this bug does not contain much information, it's more like an FYI instead of a problem report to track one (set of) specific issue(s). -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24867
[Bug libstdc++/24469] Possible race condition in mt_allocator causing SIGSEGV
--- Comment #4 from l_heldt at poczta dot onet dot pl 2005-11-15 12:26 --- Unfortunately I cannot perform such test because it would require changing stdlibc++ on many machines. My solution to this problem is setting GLIBCXX_FORCE_NEW variable before starting application. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24469
[Bug libstdc++/24469] Possible race condition in mt_allocator causing SIGSEGV
--- Comment #5 from pcarlini at suse dot de 2005-11-15 12:31 --- (In reply to comment #4) Unfortunately I cannot perform such test because it would require changing stdlibc++ on many machines. Out of curiosity: why many and not just one (and optionally, of course, along the existing compiler/library). If you want I can give details about how to do that in a safe way. My solution to this problem is setting GLIBCXX_FORCE_NEW variable before starting application. Too bad that the distro that you are using configures mt_allocator by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24469
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-15 12:31 --- (In reply to comment #6) The two attached files will change the behavior so that included files are processed as described in comment #2. I have not checked the results extensively. You should really attach patches and not the files themselves. Now, I don't know exactly what you changed in those files. And I'm really wondering what you could possible change in Makefile.in :) I'm assigning this bug to myself, as I intend to look into it in the next few days. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-07 13:31:38 |2005-11-15 12:31:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug c++/24874] New: ICE: in add_AT_specification, at dwarf2out.c:4903
g++ -g ManuProcEntity.ii ManuProcEntity.cc:35: internal compiler error: in add_AT_specification, at dwarf2out.c:4903 omitting -g makes the compilation work. -- Summary: ICE: in add_AT_specification, at dwarf2out.c:4903 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christof at petig-baender dot de GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
[Bug libmudflap/24865] compiling 64-bit gfortran
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-15 12:51 --- As a work-around, configure with --disable-libmudflap, you don't need that library anyway, it is an instrumentation library for memory access violations for C and C++, so you don't need it for gfortran. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24865
[Bug libmudflap/24865] libmudflap build problem
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:53 --- Note that we would still like to know what target you are configuring for. If you can copy-and-paste the first, say, 10 lines of output from your configure, that would be most helpful. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|compiling 64-bit gfortran |libmudflap build problem http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24865
[Bug c++/24874] ICE: in add_AT_specification, at dwarf2out.c:4903
--- Comment #1 from christof at petig-baender dot de 2005-11-15 12:53 --- Created an attachment (id=10243) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10243action=view) the failing program (ManuProcEntity.ii.gz) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
[Bug fortran/24875] New: [gfortran] Arithmetic overflow during compilation
The current mainline gfortran aborts compilation with an error for the code below: module mod1 implicit none integer, parameter :: gndp = kind(1.0d0) real(kind = gndp), parameter :: GNDP_MAX = huge(0.0_gndp) end module mod1 module mod2 use mod1 implicit none contains subroutine foo() real(kind = GNDP) :: val val = -GNDP_MAX end subroutine end module mod2 ~/tmpgfortran -c -v huge.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,fortran --with-gmp=/afs/mpa/data/martin/mygmp Thread model: posix gcc version 4.1.0 20051115 (experimental) /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 huge.f90 -quiet -dumpbase huge.f90 -mtune=pentiumpro -auxbase huge -version -o /tmp/ccjkyE0d.s GNU F95 version 4.1.0 20051115 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20051115 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 In file huge.f90:15 val = -GNDP_MAX 1 Error: Arithmetic overflow at (1) I'm not entirely sure that this is a bug, since it could be the case that -GNDP_MAX cannot be represented as a real(gndp). But, on the other hand, the following code compiles without problems: module mod1 implicit none integer, parameter :: gndp = kind(1.0d0) real(kind = gndp), parameter :: GNDP_MAX = huge(0.0_gndp) contains subroutine foo() real(kind = GNDP) :: val val = -GNDP_MAX end subroutine end module mod1 -- Summary: [gfortran] Arithmetic overflow during compilation Product: gcc Version: 4.1.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: 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=24875
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
-- uros at kss-loka dot si changed: What|Removed |Added CC|uros at kss-loka dot si | AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01059.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-11-15 13:43:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #22 from charlet at gcc dot gnu dot org 2005-11-15 13:51 --- Subject: Bug 18434 Author: charlet Date: Tue Nov 15 13:51:09 2005 New Revision: 106950 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106950 Log: 2005-11-14 Robert Dewar [EMAIL PROTECTED] Ed Schonberg [EMAIL PROTECTED] PR ada/18434 * types.ads: Include All_Checks in Suppress_Array * checks.adb (Check_Needed): Remove kludge for a/=b rewritten as not(a=b), since we no longer do this rewriting, and hence it is not needed. (Elaboration_Checks_Suppressed): Add special casing to deal with different cases of static and dynamic elaboration checks (all checks does not count in the first case, but does in the second). (Expr_Known_Valid): Do not assume that the result of any arbitrary function call is valid, since this is not the case. (Ensure_Valid): Do not apply validity check to a real literal in a universal or fixed context * exp_ch4.adb (Expand_N_Op_Ne): Don't expand a/=b to not(a=b) for elementary types using the operator in standard. It is cleaner not to modify the programmers intent, especially in the case of floating-point. (Rewrite_Comparison): Fix handling of /= (this was always wrong, but it did not matter because we always rewrote a/=b to not(a=b). (Expand_Allocator_Expression): For an allocator expression whose nominal subtype is an unconstrained packed type, convert the expression to its actual constrained subtype. Implement warning for = or = where or not possible Fix to Vax_Float tests (too early in many routines, causing premature Vax_Float expansions. * sem_prag.adb (Analyze_Pragma, case Obsolescent): Allow this pragma to be used with packages and generic packages as well as with subprograms. (Suppress): Set All_Checks, but not Elaboration_Check, for case of pragma Suppress (All_Checks) (Analyze_Pragma, case Warnings): Implement first argument allowed to be a string literal for precise control over warnings. Avoid raise of pragma in case of unrecognized pragma and just return instead. * sem_prag.ads: Minor reformatting * switch-c.adb (Scan_Front_End_Switches): Replace raise Bad_Switch; with call to new procedure Bad_Switch. Call Scan_Pos with new parameter Switch. Do not handle any exception. Include -gnatwx as part of -gnatg (warn on redundant parens) Allow optional = after -gnatm (Scan_Front_End_Switches): The -gnatp switch sets All_Checks, but no longer sets Elaboration_Checks. Code to set warning mode moved to Sem_Warn so that it can be shared by pragma processing. * s-mastop-tru64.adb (Pop_Frame): Remove redundant parentheses in if statement. * s-taprop-solaris.adb: Change some = to =, to avoid new warning * a-exexda.adb, prj-proc.adb: Fix obvious typo (Num_Tracebacks compared = 0 instead of 0) Fix obvious typo (Total_Errors_Detected = 0 should be = 0) Modified: trunk/gcc/ada/a-exexda.adb trunk/gcc/ada/checks.adb trunk/gcc/ada/exp_ch4.adb trunk/gcc/ada/prj-proc.adb trunk/gcc/ada/s-mastop-tru64.adb trunk/gcc/ada/s-taprop-solaris.adb trunk/gcc/ada/sem_prag.adb trunk/gcc/ada/sem_prag.ads trunk/gcc/ada/switch-c.adb trunk/gcc/ada/types.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #8 from charlet at gcc dot gnu dot org 2005-11-15 13:59 --- Subject: Bug 23732 Author: charlet Date: Tue Nov 15 13:59:02 2005 New Revision: 106980 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106980 Log: PR ada/23732 * gnatvsn.ads (Library_Version): Bump to 4.1 Modified: trunk/gcc/ada/gnatvsn.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug ada/15604] Ambiguous aggregate -- Accepts invalid
--- Comment #3 from charlet at gcc dot gnu dot org 2005-11-15 14:04 --- Subject: Bug 15604 Author: charlet Date: Tue Nov 15 14:03:56 2005 New Revision: 107006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107006 Log: 2005-11-14 Ed Schonberg [EMAIL PROTECTED] Javier Miranda [EMAIL PROTECTED] PR ada/15604 * sem_type.adb (Covers): In an inlined body, a composite type matches a private type whose full view is a composite type. (Interface_Present_In_Ancestor): Protect the frontend against previously detected errors to ensure that its compilation with assertions enabled gives the same output that its compilation without assertions. (Interface_Present_In_Ancestor): Add support for private types. Change name In_Actual to In_Generic_Actual (clean up) (Disambiguate): New predicate In_Actual, to recognize expressions that appear in the renaming declaration generated for generic actuals, and which must be resolved in the outer context. Modified: trunk/gcc/ada/sem_type.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15604
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #23 from charlet at gcc dot gnu dot org 2005-11-15 14:08 --- Fixed. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|4.1.0 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #9 from charlet at gcc dot gnu dot org 2005-11-15 14:09 --- Fixed. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug ada/15604] Ambiguous aggregate -- Accepts invalid
--- Comment #4 from charlet at gcc dot gnu dot org 2005-11-15 14:10 --- Fixed. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15604
[Bug rtl-optimization/24762] [killloop-branch] code motion of non-invariant expressions with hard registers.
--- Comment #15 from rakdver at gcc dot gnu dot org 2005-11-15 14:27 --- Subject: Bug 24762 Author: rakdver Date: Tue Nov 15 14:27:48 2005 New Revision: 107017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107017 Log: PR rtl-optimization/24762 * except.c (dw2_build_landing_pads): Always emit clobbers for eh registers. Modified: branches/killloop-branch/gcc/ChangeLog.killloop branches/killloop-branch/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
[Bug other/24870] make check fails for fixincl
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 15:15 --- *** This bug has been marked as a duplicate of 23400 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24870
[Bug testsuite/23400] [4.1 Regression] make check fixinclude failure
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-15 15:15 --- *** Bug 24870 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23400
[Bug c++/24874] ICE: in add_AT_specification, at dwarf2out.c:4903
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 15:22 --- I think this is a dup of bug 24569 which was fixed for 4.0.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
[Bug target/24856] call to setlocale doesn't return expected value
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-15 15:38 --- (In reply to comment #12) specify --with-local-prefix=/opt/OPSWbuildtools/1.0.1 Am I missing something? Yes it sounds like it is picking up the wrong header otherwise. -- 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=24856
[Bug target/24856] call to setlocale doesn't return expected value
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-15 15:38 --- (In reply to comment #13) (In reply to comment #12) specify --with-local-prefix=/opt/OPSWbuildtools/1.0.1 Am I missing something? Yes it sounds like it is picking up the wrong header otherwise. s/header/library/. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug c/17534] gcc fails to diagnose suspect expressions that have incompatible bit masks
--- Comment #5 from trt at acm dot org 2005-11-15 15:43 --- Since fold() is increasingly used for internal speculative computations, I think it should avoid issuing warnings as false positives are too likely. So perhaps this warning belongs in parser_build_binary_op() in c-typeck.c Similarly for bug 16302 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17534
[Bug middle-end/11492] Unsigned char promoted to signed int in for loop test for gpp but not gcc
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-15 16:19 --- (In reply to comment #1) 1000 is a signed integer constant, so b*1000 is a signed integer too. I guess the warning is ok, then. That is only true for unsigned multiplication and signed when overflow is undefined (-fno-wrapv which is default for C and C++). The reason why this is middle-end and not C is because tree_expr_nonnegative_p is part of the middle-end and not part of the C front-end. Fixing tree_expr_nonnegative_p will also provide some optimization opertunites also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11492
[Bug middle-end/16315] Strange variable names for temporaries in warnings
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-15 16:24 --- The orginal testcase was fixed for 4.0.0 by: 2005-01-23 Steven Bosscher [EMAIL PROTECTED] PR rtl-optimization/19464 * tree-optimize.c (init_tree_optimization_passes): Add one more copyrename pass just before out-of-ssa. I don't know if there could ever be exposed again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16315
[Bug libstdc++/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-15 16:31 --- Hold on, in C99, complex is a scaler type so libstdc++ is using a GCC extension over what C99 requires which causes this. And my comment in #6 still holds for this bug. I think libstdc++ should rethink about this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #11 from pcarlini at suse dot de 2005-11-15 16:39 --- (In reply to comment #10) And my comment in #6 still holds for this bug. I think libstdc++ should rethink about this. libstdc++ can rething anything, in principle, but if you change the component to libstdc++, nobody will look into the example in #1, which, as Mark also confirmed, has nothing to do with the library. -- pcarlini at suse dot de changed: What|Removed |Added Component|libstdc++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-15 16:47 --- (In reply to comment #9) Certainly, the test-case in Comment #1 does depend on libstdc++ at all. Let's fix this. The testcase in comment #1 shows the issue with what libstdc++ is doing. Since complex is scalers they cannot be (with defined behavior) constructed by parts. So the testcase in comment #1 is in fact invalid with respect of the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug rtl-optimization/24823] [4.1 Regression] ICE
--- Comment #5 from krebbel at gcc dot gnu dot org 2005-11-15 16:47 --- The only difference my patch brought is different behaviour of mark_set_1 if it is called under wrong! conditions. Will say that only in case somebody calls mark_set_1 clobbering a reg which is live afterwards - we would usually consider this a bug. But because the different liveness analyzers used by global alloc and flow we may have such a situation for uninitialized quantities. But this didn't happen here. So the question is why somebody calls mark_set_1 to clobber a reg which seem to be needed afterwards? The problematic mark_set_1 call comes from flow.c:1876 where mark_set_1 is used to end the live ranges of all call clobbered registers by pretending to have found a clobber for them. For the testcase this is done for a 3dnow register xmm1 although that register is live afterwards (at the end of the bb). Due to my patch no REG_DEAD note is emitted because it is assumed that xmm1 holds the value of an uninitialized variable. So why xmm1 is live at bb end? I think the problem here is that mark_used_regs doesn't handle PARALLELs as destination of a SET properly. It shouldn't mark the destination reg USED by the call. For single SETs this works well (flow.c:3972) but for a non BLKmode PARALLEL we fall through to line 4099 which calls mark_used_regs recursively for all parts of the PARALLEL and therefore lets the regs in the following insn be live before that insn up to the entry bb: (call_insn:HI 361 360 362 32 (set (parallel:DC [ (expr_list:REG_DEP_TRUE (reg:DF 21 xmm0) (const_int 0 [0x0])) (expr_list:REG_DEP_TRUE (reg:DF 22 xmm1) (const_int 8 [0x8])) ]) (call (mem:QI (symbol_ref:DI (zlatm2_) [flags 0x41] function_decl 0xb7b43200 zlatm2) [0 S1 A8]) Btw. it is completely unclear to me what this kind of destination shall mean. Any explanations are welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2005-11-15 16:55 --- It's nice to see that PR bouncing between you all. Although I don't know anything about C++, I want to add my non-constructive comment to this discussion: I don't understand how a bug which has a C-only testcase (in comment #1) can be classified with libstdc++ as component. Please also note that this exact invalid warning happens during the libgfortran build process, preventing it to be done with -Werror. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #24 from olle at cb dot uu dot se 2005-11-15 17:27 --- (In reply to comment #20) Could people check if the problem was indeed fixed where reported? I did try the new suggested fix on tru64 5.1B on an Alpha. It gets past the previous error pointb ut it fails later on while linking Somehow an extra -L is generated that disables the default library search paths. configured with ../gcc-4.0.2/configure alpha-dec-osf5.1 --enable-languages=c,ada exactly the same config bootstrapped OK with the preliminary fix below is an excerpt of the output from make bootstrap make[4]: Entering directory `/usr/users/olle/xyz/objdir/gcc/ada/tools' rm -f tools/* rm -rf tools mkdir -p tools (cd tools; ln -s ../sdefault.adb .) rm -f tools/mlib-tgt.adb; ln -s /usr/users/olle/xyz/gcc-4.0.2/gcc/ada/mlib-tgt-tru64.adb tools/mlib-tgt.adb; touch ../stamp-tools ../../gnatmake -c -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada gnatchop --GCC=../../xgcc -B../../ -O2 -g -O2 -mieee -gnatpg -gnata ../../xgcc -c -I./ -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada -B../../ -O2 -g -O2 -mieee -gnatpg -gnata -I- /usr/users/olle/xyz/gcc-4.0.2/gcc/ada/gnatchop.adb ../../gnatbind -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada -static -x gnatchop ../../gnatlink -v gnatchop -o ../../gnatchop --GCC=../../xgcc -B../../ -static-libgcc -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada ../rts/libgnat.a ../../prefix.o ../../version.o link.o ../../../libiberty/libiberty.a -lexc GNATLINK 4.0.2 Copyright 1995-2005 Free Software Foundation, Inc xgcc -c -gnatA -gnatWb -gnatiw -B../../ -static-libgcc -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada -gnatws b~gnatchop.adb ../../xgcc b~gnatchop.o ../../prefix.o ../../version.o link.o ../rts/ada.o ../rts/a-charac.o ../rts/a-chlat1.o ../rts/gnat.o ../rts/g-string.o interfac.o system.o ../rts/s-addope.o s-casuti.o ../rts/g-casuti.o s-htable.o ../rts/s-parame.o ../rts/s-crtl.o ../rts/i-cstrea.o s-purexc.o ../rts/s-restri.o s-stoele.o ../rts/s-carun8.o ../rts/s-imgint.o ../rts/a-comlin.o ../rts/s-stache.o ../rts/s-strops.o ../rts/s-sopco3.o ../rts/s-sopco4.o ../rts/s-sopco5.o ../rts/s-traent.o ../rts/a-elchha.o ../rts/s-except.o ../rts/s-traceb.o ../rts/s-soflin.o s-secsta.o s-exctab.o ../rts/a-ioexce.o ../rts/a-string.o ../rts/a-tags.o ../rts/a-stream.o ../rts/g-os_lib.o ../rts/s-assert.o ../rts/s-finroo.o ../rts/s-memory.o ../rts/s-mastop.o s-stalib.o ../rts/s-unstyp.o a-except.o ../rts/s-bitops.o ../rts/a-strmap.o ../rts/a-stmaco.o ../rts/a-chahan.o ../rts/a-strsea.o ../rts/a-strfix.o ../rts/s-stratt.o ../rts/s-finimp.o ../rts/a-finali.o ../rts/a-filico.o ../rts/g-dirope.o ../rts/g-regexp.o ../rts/g-comlin.o ../rts/s-ficobl.o ../rts/s-fileio.o ../rts/a-textio.o ../rts/s-valuti.o ../rts/s-valuns.o ../rts/s-valint.o gnatvsn.o hostparm.o gnatchop.o -o ../../gnatchop ../rts/libgnat.a ../../../libiberty/libiberty.a -lexc -L -L../rts/ -L./ -L/usr/users/olle/xyz/gcc-4.0.2/gcc/ada/ -L/usr/local/lib/gcc/alpha-dec-osf5.1/4.0.2/adalib/ ../rts/libgnat.a -lexc -B../../ -static-libgcc -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada /bin/ld: Can't locate file for: -lc collect2: ld returned 1 exit status gnatlink: cannot call ../../xgcc make[4]: *** [../../gnatchop] Error 4 make[4]: Leaving directory `/usr/users/olle/xyz/objdir/gcc/ada/tools' make[3]: *** [gnattools2] Error 2 make[3]: Leaving directory `/usr/users/olle/xyz/objdir/gcc/ada' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/usr/users/olle/xyz/objdir/alpha-dec-osf5.1/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/usr/users/olle/xyz/objdir' make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-11-15 17:44 --- Subject: Bug 24687 Author: mmitchel Date: Tue Nov 15 17:44:28 2005 New Revision: 107030 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107030 Log: PR c++/24687 * g++.dg/template/crash43.C: Remove duplicate copy of test. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/crash43.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug c++/24667] [4.0/4.1 Regression] -Wcast-qual fails to warn about offending cast for a old style cast
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-11-15 17:50 --- Subject: Bug 24667 Author: mmitchel Date: Tue Nov 15 17:50:43 2005 New Revision: 107031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107031 Log: PR c++/24667 * typeck.c (check_for_casting_away_constness): Use the diag_fn. (build_const_cast_1): Call it, for C-style casts. PR c++/24667 * g++.dg/warn/Wcast-qual1.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/Wcast-qual1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/typeck.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
[Bug c++/24667] [4.0/4.1 Regression] -Wcast-qual fails to warn about offending cast for a old style cast
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-15 17:52 --- Subject: Bug 24667 Author: mmitchel Date: Tue Nov 15 17:52:34 2005 New Revision: 107032 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107032 Log: PR c++/24667 * typeck.c (check_for_casting_away_constness): Use the diag_fn. (build_const_cast_1): Call it, for C-style casts. PR c++/24667 * g++.dg/warn/Wcast-qual1.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wcast-qual1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
[Bug c++/24667] [4.0/4.1 Regression] -Wcast-qual fails to warn about offending cast for a old style cast
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-15 17:57 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
[Bug ada/22533] [4.1 regression] Ada ICE during bootstrap on many platforms
--- Comment #28 from uweigand at gcc dot gnu dot org 2005-11-15 18:31 --- Just one additional comment: the patch from comment #10 was rejected, maybe because it required changes to the core gimplifier. However, I've tested just the Ada front-end pieces from that patch, and this *already* fixed the problem for me. The reason appears to be that -in general- occurrences of ADDR_EXPR (CONSTRUCTOR) do not constitute a problem. The problem only comes when such constructs occur in turn as part of another (outer) CONSTRUCTOR. The middle-end never generates that case, only the Ada front-end does -- thus it suffices to fix those cases in the Ada front-end itself. So I guess it would be possible right now to fix the bootstrap issue by a pure front-end patch. (This doesn't address the more general question of whether or not the gimplifier has a bug that can be exposed by other front-ends too, of course ...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug fortran/24878] New: subroutine getting called illegally as a function
This test is taken from, http://ftp.cac.psu.edu/pub/ger/fortran/test/test10.for $ cat test.f90 INTEGER X, Y, SUBA EXTERNAL SUBA X=-1 Y=-2 CALL ANY(SUBA,X,Y) WRITE(*,*)'Did NOT catch this error' PAUSE STOP END SUBROUTINE ANY(FNC,X,Y) INTEGER Y,X, FNC !---FNC is not a Function subprogram so calling it ! as a function is an error. Y=FNC(X) RETURN END SUBROUTINE SUBA(X) INTEGER X X=12345 RETURN END $ gfrotran test.f90 $ ./a.out in suba Did NOT catch this error PAUSE To resume execution, type go. Other input will terminate the job. go RESUMED In this test case, a subroutine SUBA is getting called as a function which should have been caught at runtime. -- Summary: subroutine getting called illegally as a function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()
--- Comment #9 from daney at gcc dot gnu dot org 2005-11-15 19:11 --- Subject: Bug 15430 Author: daney Date: Tue Nov 15 19:11:53 2005 New Revision: 107036 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107036 Log: PR libgcj/15430 * gnu/java/net/natPlainSocketImplPosix.cc (throw_on_sock_closed): New function. (accept): Call it. (close): Call shutdown before closing. (read()): Call read_helper with proper parameters. (read(buffer, int, int)): Likewise. (read_helper): Pass pointer to the PlainSocketImpl, remove native_fd and timeout parameters. Make prototype to match. Use pointer to PlainSocketImpl to access members. Call throw_on_sock_closed in two places. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/java/net/natPlainSocketImplPosix.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430
[Bug target/24879] New: SSE3 intrinsic bug
It seems that SSE3 _mm_monitor instrinsic doesn't work too well with
64bit.
[EMAIL PROTECTED] function]$ cat x.c
#include stdio.h
#include pmmintrin.h
static void
foo (char *p)
{
_mm_monitor(p, 0, 0);
}
main()
{
char *p = (char *)foo;
int fail = 1;
int i;
for (i = 0; i 20; i++) {
if (p[i] == 0x0f) {
fail = 0;
break;
}
}
printf (failed: %d\n, fail);
return 0;
}
[EMAIL PROTECTED] function]$ make
/usr/gcc-4.1/bin/gcc -O2 -msse3x.c -o x
x.c: In function \u\u\ufoo\u\u\u:
x.c:8: error: unrecognizable insn:
(insn 11 10 12 1 (unspec_volatile [
(reg/v/f:DI 58 [ p ])
(reg:SI 59)
(reg:SI 60)
] 8) -1 (nil)
(nil))
x.c:8: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make: *** [x] Error 1
[EMAIL PROTECTED] function]$ /usr/gcc-4.1/bin/gcc -O2 -msse3x.c -o x -m32
[EMAIL PROTECTED] function]$ ./x
failed: 0
--
Summary: SSE3 intrinsic bug
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24879
[Bug c++/22172] [3.4 Regression] Internal compiler error, seg fault.
--- Comment #17 from reichelt at gcc dot gnu dot org 2005-11-15 19:14 --- Subject: Bug 22172 Author: reichelt Date: Tue Nov 15 19:14:21 2005 New Revision: 107037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107037 Log: PR c++/19253 PR c++/22172 Backport from mainline: 2005-11-02 Mark Mitchell [EMAIL PROTECTED] * parser.c (cp_parser_postfix_expression): Use cp_parser_elaborated_type_specifier to handle typename-types in functional casts. (cp_parser_enclosed_argument_list): Skip ahead to the end of the template argument list if the closing is not found. Backport from mainline: 2005-11-02 Mark Mitchell [EMAIL PROTECTED] PR c++/19253 * g++.dg/parse/typename10.C: New test. Backport from mainline: 2005-10-08 James A. Morrison [EMAIL PROTECTED] PR c++/22172 * g++.dg/parse/crash30.C: New test. Added: branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/crash30.C branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/typename10.C Modified: branches/gcc-3_4-branch/gcc/cp/ChangeLog branches/gcc-3_4-branch/gcc/cp/parser.c branches/gcc-3_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug c++/19253] [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter
--- Comment #15 from reichelt at gcc dot gnu dot org 2005-11-15 19:14 --- Subject: Bug 19253 Author: reichelt Date: Tue Nov 15 19:14:21 2005 New Revision: 107037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107037 Log: PR c++/19253 PR c++/22172 Backport from mainline: 2005-11-02 Mark Mitchell [EMAIL PROTECTED] * parser.c (cp_parser_postfix_expression): Use cp_parser_elaborated_type_specifier to handle typename-types in functional casts. (cp_parser_enclosed_argument_list): Skip ahead to the end of the template argument list if the closing is not found. Backport from mainline: 2005-11-02 Mark Mitchell [EMAIL PROTECTED] PR c++/19253 * g++.dg/parse/typename10.C: New test. Backport from mainline: 2005-10-08 James A. Morrison [EMAIL PROTECTED] PR c++/22172 * g++.dg/parse/crash30.C: New test. Added: branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/crash30.C branches/gcc-3_4-branch/gcc/testsuite/g++.dg/parse/typename10.C Modified: branches/gcc-3_4-branch/gcc/cp/ChangeLog branches/gcc-3_4-branch/gcc/cp/parser.c branches/gcc-3_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()
--- Comment #10 from daney at gcc dot gnu dot org 2005-11-15 19:16 --- Fixed by committed patch. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430
[Bug target/24879] SSE3 intrinsic bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-15 19:17 --- Confirmed and not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|x86_64-unknown-linux-gnu|x86_64-*-linux-gnu Keywords||ice-on-valid-code Known to fail||3.4.5 4.0.3 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-11-15 19:17:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24879
[Bug c++/22172] [3.4 Regression] Internal compiler error, seg fault.
--- Comment #18 from reichelt at gcc dot gnu dot org 2005-11-15 19:18 --- Now also fixed on the 3.4 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug c++/19253] [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-15 19:19 --- Now also fixed on the 3.4 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-11-15 19:23 --- There is nothing wrong with the code in Comment #1; __imag__ is an lvalue-yielding operator. If, for some reason, we wanted to make __imag__ yield an rvalue, then this code would be rejected with an error; under no circumstances should it yield a warning about the complex value being uninitialized upon initialization of its imaginary component. It would be reasonable to warn about a subsequent use of the complex value, as the real part remains uninitialized. Andrew's comments about the fact that __complex__ is a scalar are irrelevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug target/24879] SSE3 intrinsic bug
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 19:24 --- (define_insn sse3_mwait [(unspec_volatile [(match_operand:SI 0 register_operand a) (match_operand:SI 1 register_operand c)] UNSPECV_MWAIT)] TARGET_SSE3 mwait\t%0, %1 [(set_attr length 3)]) (define_insn sse3_monitor [(unspec_volatile [(match_operand:SI 0 register_operand a) (match_operand:SI 1 register_operand c) (match_operand:SI 2 register_operand d)] UNSPECV_MONITOR)] TARGET_SSE3 monitor\t%0, %1, %2 [(set_attr length 3)]) These targets don't have any of the 64bit stuff. This has been an issue since the patterns were added... So you caused the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24879
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #25 from olle at cb dot uu dot se 2005-11-15 19:27 --- (In reply to comment #24) Seems that the basic difference between the working case (the preliminary work around) and the final fix is that in the working case there are two occasions of -L./ in the linking command in the nonworking case there are one -L and one -L./ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug fortran/24862] [4.1 Regression] Internal Error: Derived type I/O should have been handled via the frontend.
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-15 19:34 --- A regression hunt identified the following patch from Janne Blomqvist: http://gcc.gnu.org/viewcvs?view=revrev=104662 r104662 | bdavis | 2005-09-26 20:24:45 + (Mon, 26 Sep 2005) | 28 lines -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||jblomqvi at cc dot hut dot ||fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
[Bug fortran/24878] subroutine getting called illegally as a function
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-15 19:45 --- Confirmed, but minor since a lot of the other fortran implemenations don't detect it either. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-15 19:45:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
[Bug ada/24880] New: (Ada) Conversion of user-defined integer type with Size fixed causes crashes
Explicit conversion from a numeric integer Type to Integer causes a crash of gcc when the type is defined with a Size representation clause. The bug disappears if the representation clause is removed or if the range begins with 0. Environment: System: Linux simone 2.6.12.051101 #1 Tue Nov 1 17:19:34 CET 2005 i686 GNU/Linux Debian testing gnat-4.0 Version: 4.0.2-2 Architecture: i686 host: i486-pc-linux-gnu build: i486-pc-linux-gnu target: i486-pc-linux-gnu configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu How-To-Repeat: File demo2.adb procedure Demo2 is S : constant := Integer'Size; type Regoff_T is range -1 .. 2 ** (S-1); for Regoff_T'Size use S; B : Integer; C : Regoff_T; begin B := Integer (C); end Demo2; - The crash message ~ gnatmake demo2 gcc-4.0 -c demo2.adb gcc-4.0: Internal error: Erreur de segmentation (program gnat1) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. gnatmake: demo2.adb compilation error with gnat version 3.4 ~ gnatmake demo2 gcc-3.4 -c demo2.adb demo2.adb:6:04: warning: C is never assigned a value gnatbind -x demo2.ali gnatlink demo2.ali -- --- Comment #1 from nicolas dot boulenguez at free dot fr 2005-11-15 19:55 --- Fix: none -- Summary: (Ada) Conversion of user-defined integer type with Size fixed causes crashes Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nicolas dot boulenguez at free dot fr GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24880
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-15 20:11 --- The code works for me on amd64-*-freebsd. Can you compile the failing code with -fdump-parse-tree and post both mod1.mod and the parse-tree? -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-15 20:16 --- It fails on powerpc64-linux with both -m32 and -m64 for current trunk, 4.0 branch, and GCC 4.0.0. Since it's Fortran 90 code it's not really a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug ada/24880] [4.0/4.1 regression] (Ada) Conversion of user-defined integer type with Size fixed causes crashes
--- Comment #2 from laurent at guerby dot net 2005-11-15 20:22 --- Confirmed on x86_64-linux and x86-linux. On x86 svn 4.0.3 and 4.1 gnat1 grows memory above 1GB and I had to kill the processes. 3.3.5 does not have the issue. On x86_64 gnat1 segfault immediately. -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i486-pc-linux-gnu | GCC host triplet|i486-pc-linux-gnu | GCC target triplet|i486-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2005-11-15 20:22:08 date|| Summary|(Ada) Conversion of user- |[4.0/4.1 regression] (Ada) |defined integer type with |Conversion of user-defined |Size fixed causes crashes |integer type with Size fixed ||causes crashes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24880
[Bug fortran/24096] huge() returns infinity for long doubles
--- Comment #2 from amodra at gcc dot gnu dot org 2005-11-15 20:33 --- Subject: Bug 24096 Author: amodra Date: Tue Nov 15 20:33:48 2005 New Revision: 107041 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107041 Log: PR fortran/24096 * trans-types.c (gfc_init_kinds): Use one less for max_exponent of IBM extended double format. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24096
[Bug fortran/24096] huge() returns infinity for long doubles
--- Comment #3 from amodra at bigpond dot net dot au 2005-11-15 20:35 --- Fixed mainline. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24096
[Bug libstdc++/24881] New: Lazy facet instantiation
This is to track this proposal for enhancement: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00184.html -- Summary: Lazy facet instantiation Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24881
[Bug debug/24444] [4.1 regression] invalid register in debug info
--- Comment #9 from drow at gcc dot gnu dot org 2005-11-15 20:58 --- Subject: Re: [4.1 regression] invalid register in debug info On Thu, Oct 20, 2005 at 08:35:59AM -, rth at gcc dot gnu dot org wrote: Well, the ideal fix is to make use of the dwarf3 DW_OP_call_frame_cfa directive, and let the debugger get the CFA information from the ia64 unwind info. Similarly for the arm eabi unwind info. Note that this may be a good solution for ia64, but it really is not for ARM. ARM unwind information is only usable by the debugger in very few cases, because everything interesting is handled by a personality routine; it's only if you use one of the standard table formats (which GCC does) that the debugger can decode it. But we do still emit .debug_frame for ARM, and the debugger does use that. So presumably that's plenty to use DW_OP_call_frame_cfa. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug libstdc++/24882] New: [meta-bug] Non-refcounted, moveable basic_string
This meta-bug tracks work on a new, ABI-breaking, basic_string implementation. Currently, we have refactored code in v7-branch which includes two alternative base classes: one doesn't use reference counting, is optimized for short strings and includes (simulated) move constructor and assignment operator (is rather similar to Design D in Effective STL. A few recent threads about this topic: - Alternative tradeoffs: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00013.html - Special mini-string for stdexcept: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00166.html -- Summary: [meta-bug] Non-refcounted, moveable basic_string Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de OtherBugsDependingO 16612,19495,21334,24196 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string
-- pcarlini at suse dot de changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
[Bug libstdc++/4455] [HP-UX] libstdc++.sl depends on libgcc.a
--- Comment #5 from pcarlini at suse dot de 2005-11-15 21:07 --- This PR can now be closed, basing on up to date comments from John David Anglin ([EMAIL PROTECTED]), which indicate that now shared versions of libgcc are built on both 32 and 64-bit ports. He also remarks that it's technically wrong to link the shared version of libstdc++ with libgcc.a and libgcc_eh.a as this could lead to duplicate symbols. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4455
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09 --- (In reply to comment #2) It fails on powerpc64-linux with both -m32 and -m64 for current trunk, 4.0 branch, and GCC 4.0.0. Since it's Fortran 90 code it's not really a regression. Well, it worked for me with the current gcc 4.0 branch, so I thought it might be one. But it seems this is a quite intermittent problem ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #4 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09 --- The code works for me on amd64-*-freebsd. Can you compile the failing code with -fdump-parse-tree and post both mod1.mod and the parse-tree? Will do tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #5 from martin at mpa-garching dot mpg dot de 2005-11-15 21:16
---
~/tmpgfortran -c -fdump-parse-tree huge.f90
Namespace: A-Z: (UNKNOWN 0)
procedure name = mod1
symtree: gndp_max Ambig 0
symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC)
value: 1.79769313486232e308_8
symtree: gndp Ambig 0
symbol gndp (INTEGER 4)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC)
value: 8
symtree: mod1 Ambig 0
symbol mod1 (UNKNOWN 0)(MODULE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC)
symtree: huge Ambig 0
symbol huge (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC FUNCTION)
result: huge
symtree: kind Ambig 0
symbol kind (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC FUNCTION)
result: kind
In file huge.f90:15
val = -GNDP_MAX
1
Error: Arithmetic overflow at (1)
Namespace: A-Z: (UNKNOWN 0)
procedure name = mod2
symtree: gndp_max Ambig 0
symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC USE-ASSOC)
value: 1.79769313486232e308_8
symtree: gndp Ambig 0
symbol gndp (INTEGER 4)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC USE-ASSOC)
value: 8
symtree: foo Ambig 0
symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS
MODULE-PROC SUBROUTINE)
symtree: mod2 Ambig 0
symbol mod2 (UNKNOWN 0)(MODULE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC)
symtree: kind Ambig 0
symbol kind (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC USE-ASSOC FUNCTION)
result: kind
symtree: huge Ambig 0
symbol huge (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC USE-ASSOC FUNCTION)
result: huge
symtree: mod1 Ambig 0
symbol mod1 (UNKNOWN 0)(MODULE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC USE-ASSOC)
CONTAINS
Namespace: A-Z: (UNKNOWN 0)
procedure name = foo
symtree: foo Ambig 0 from namespace mod2
symtree: val Ambig 0
symbol val (REAL 8)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC)
~/tmp
~/tmpcat mod1.mod
GFORTRAN module created from huge.f90 on Tue Nov 15 22:14:38 2005
If you edit this, you'll get what you deserve.
(() () () () () () () () () () () () () () () () () () () ())
()
()
()
()
(2 'gndp' 'mod1' 1 ((PARAMETER UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (
INTEGER 4 ()) 0 0 () (CONSTANT (INTEGER 4 ()) 0 '8') () 0 () ())
3 'kind' '(intrinsic)' 1 ((PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN
FUNCTION) (UNKNOWN 0 ()) 0 0 () () 3 () ())
4 'huge' '(intrinsic)' 1 ((PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN
FUNCTION) (UNKNOWN 0 ()) 0 0 () () 4 () ())
5 'mod1' 'mod1' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (
UNKNOWN 0 ()) 0 0 () () 0 () ())
6 'gndp_max' 'mod1' 1 ((PARAMETER UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (
REAL 8 ()) 0 0 () (CONSTANT (REAL 8 ()) 0 '[EMAIL PROTECTED]') () 0 ()
())
)
('gndp_max' 0 6 'gndp' 0 2 'mod1' 0 5 'huge' 0 4 'kind' 0 3)
~/tmp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug target/24856] call to setlocale doesn't return expected value
--- Comment #15 from tedoc2000 at gmail dot com 2005-11-15 21:27 --- Okay so it wasn't the --with-local-prefix. It was the fact that I used --prefix=/opt/OPSWbuildtools/1.0.1. If I use a directory that doesn't already exist then I get my desired results. So that makes us ask. Well what do you have in /opt/OPSWbuildtools/1.0.1? I will attach a list of the contents. Basically it is an install of libiconv-1.9.1 gawk-3.1.4 coreutils-5.1.2 make-3.8.0 The most suspicious of the above(IMHO) is the libiconv.. But even though I am specifying --with-iconv-prefix=/opt/OPSWbuildtools/1.0.1, I don't see that being used when linking in gcc/ I just see -liconv. The only other visible difference I see is when collect2 runs I see a -L/opt/OPSWbuildtools/1.0.1/lib. But as my test program doesn't use iconv in anyway I don't see how that could make a difference. I'm testing to see if just the existance of the directory but without contents also causes the same problem. Back when I have definitive results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-15 21:42 --- (In reply to comment #14) There is nothing wrong with the code in Comment #1; __imag__ is an lvalue-yielding operator. If, for some reason, we wanted to make __imag__ yield an rvalue, then this code would be rejected with an error; under no circumstances should it yield a warning about the complex value being uninitialized upon initialization of its imaginary component. It would be reasonable to warn about a subsequent use of the complex value, as the real part remains uninitialized. I think we should make this based on one part being uninitialized as we are currently because that is just crazy otherwise. Again this is just like: a=(a0x)|(b0x000) which is what the gimplifier does currently where b is the real part of a is the full part. There is no difference between that and doing __imag___ a = b; I don't see why the warning here is bogus as it is loading by parts the a and is uninitialized when comming in. Scaler types are defined this way so you can do optimizations like this. __imag__ a = b is really defined as a = COMPLEXREAL_PARTa, b which is the same as doing what I did for an integer type. I don't understand why there is a reluntant to fixing libstdc++ so that you get better optimizable code. I would not doubt this could cause wrong code due to how libstdc++ does the initialization of complex. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2005-11-15 21:49 --- Subject: Re: [gfortran, 4.1.0 regression] Arithmetic overflow during compilation Comment #5 from martin ~/tmpgfortran -c -fdump-parse-tree huge.f90 Namespace: A-Z: (UNKNOWN 0) procedure name = mod1 symtree: gndp_max Ambig 0 symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) value: 1.79769313486232e308_8 On amd64-*-freebsd. Namespace: A-Z: (UNKNOWN 0) procedure name = mod1 symtree: gndp_max Ambig 0 symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) value: 1.7976931348623157e308_8 procedure name = mod2 symtree: gndp_max Ambig 0 symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC USE-ASSOC) value: 1.79769313486232e308_8 Good, you're reading in what was written to the module. 6 'gndp_max' 'mod1' 1 ((PARAMETER UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) ( REAL 8 ()) 0 0 () (CONSTANT (REAL 8 ()) 0 '[EMAIL PROTECTED]') () 0 () ()) 6 'gndp_max' 'mod1' 1 ((PARAMETER UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) ( REAL 8 ()) 0 0 () (CONSTANT (REAL 8 ()) 0 '[EMAIL PROTECTED]') () 0 () Hmmm, this doesn't look good. You're getting 1 fewer digits than I. I'll check what happens on i386-*-freebsd. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug fortran/23201] [4.1 Regression] internal compiler error: verify_ssa failed
--- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-15 21:50 --- (In reply to comment #8) Will take a look shortly. I stand by my analysis in #5. The Fortran FE is lying to the middle end. There is no field 'ktbuf' in this structure. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC|dnovillo at gcc dot gnu dot | |org | AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23201
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-15 21:51
---
Here is the current patch so for libstdc++ (I did not test it yet):
Index: include/std/std_complex.h
===
--- include/std/std_complex.h (revision 106892)
+++ include/std/std_complex.h (working copy)
@@ -1061,29 +1061,27 @@ namespace std
inline
complexfloat::complex(float r, float i)
{
-__real__ _M_value = r;
-__imag__ _M_value = i;
+_M_value = r + i * 1.0fi;
}
inline complexfloat
complexfloat::operator=(float __f)
{
-__real__ _M_value = __f;
-__imag__ _M_value = 0.0f;
+_M_value = __f;
return *this;
}
inline complexfloat
complexfloat::operator+=(float __f)
{
-__real__ _M_value += __f;
+_M_value += __f;
return *this;
}
inline complexfloat
complexfloat::operator-=(float __f)
{
-__real__ _M_value -= __f;
+_M_value -= __f;
return *this;
}
@@ -1105,8 +1103,7 @@ namespace std
inline complexfloat
complexfloat::operator=(const complex_Tp __z)
{
-__real__ _M_value = __z.real();
-__imag__ _M_value = __z.imag();
+_M_value = __z.real() + __z.imag() * 1.0fi;
return *this;
}
@@ -1114,8 +,7 @@ namespace std
inline complexfloat
complexfloat::operator+=(const complex_Tp __z)
{
-__real__ _M_value += __z.real();
-__imag__ _M_value += __z.imag();
+_M_value += __z.real() + __z.imag() * 1.0fi;
return *this;
}
@@ -1123,8 +1119,7 @@ namespace std
inline complexfloat
complexfloat::operator-=(const complex_Tp __z)
{
- __real__ _M_value -= __z.real();
- __imag__ _M_value -= __z.imag();
+ _M_value -= __z.real() + __z.imag() * 1.0fi;
return *this;
}
@@ -1132,9 +1127,7 @@ namespace std
inline complexfloat
complexfloat::operator*=(const complex_Tp __z)
{
- _ComplexT __t;
- __real__ __t = __z.real();
- __imag__ __t = __z.imag();
+ _ComplexT __t = __z.real() + __z.imag() * 1.0fi;
_M_value *= __t;
return *this;
}
@@ -1143,9 +1136,7 @@ namespace std
inline complexfloat
complexfloat::operator/=(const complex_Tp __z)
{
- _ComplexT __t;
- __real__ __t = __z.real();
- __imag__ __t = __z.imag();
+ _ComplexT __t = __z.real() + __z.imag() * 1.0fi;
_M_value /= __t;
return *this;
}
This also makes more and more optimization opertinutes for complex in
libstdc++. This also makes this code a little more readible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-15 21:57 --- (In reply to comment #13) It's nice to see that PR bouncing between you all. Although I don't know anything about C++, I want to add my non-constructive comment to this discussion: I don't understand how a bug which has a C-only testcase (in comment #1) can be classified with libstdc++ as component. Please also note that this exact invalid warning happens during the libgfortran build process, preventing it to be done with -Werror. The C example is just as invalid as what libstdc++ does. Now libgfortran must likely needs to be changed also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #18 from pcarlini at suse dot de 2005-11-15 22:00 --- (In reply to comment #16) Here is the current patch so for libstdc++ (I did not test it yet): Before patching this and that in the runtime library, don't you believe that: 1- If, as Mark said, (__imag__ t) is an lvalue, doesn't make any sense to emit warnings at that line? 2- If the user can write that kind of code anyway, the middle end had better being able to optimize it? -- pcarlini at suse dot de changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug rtl-optimization/24883] New: [4.1 Regression] fatal error: internal consistency failure building xorg-x11
/usr/lib/gcc/s390-suse-linux/4.1.0/cc1 -fpreprocessed reo.i -quiet -dumpbase reo.i -m31 -mesa -march=g5 -ansi -auxbase reo -O2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -ansi -version -fomit-frame-pointer -fno-strict-aliasing -o /tmp/ccC1ZDOL.s reo.c: In function ?orec_alt?: reo.c:199: fatal error: internal consistency failure compilation terminated. -- Summary: [4.1 Regression] fatal error: internal consistency failure building xorg-x11 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: s390-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
[Bug rtl-optimization/24883] [4.1 Regression] fatal error: internal consistency failure building xorg-x11
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-15 22:03 --- Created an attachment (id=10245) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10245action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-11-15 22:10 --- There are only two choices: either __imag__ is an lvalue, and the code in Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should issue an error. Nobody wants to see a warning about an uninitialized variable use on: __complex__ double t; __imag__ t = 0.0; __real__ t = 0.0; If Andrew doesn't like the fact that __imag__ is an lvalue, then Andrew should complain to the C front-end maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug libstdc++/21251] Placement into shared memory
--- Comment #9 from et at ihear dot com 2005-11-15 22:10 --- This cripples virtual inheritance for fine-grain parallel processing. There should at least be a compiler option for process-independent referencing, because admittedly, this would slow down dereferencing. Or maybe a operator new placement variant that specifies process-independent referencing. I can see that either way, it would cause major ripple effects. Maybe that's why I don't see any action on this item since May. I am making this comment because I think it is a very important enhancement to make as soon as possible, as processors go multi-core. I have also read that the other signicifant c++ compiler uses process independent referencing. -- et at ihear dot com changed: What|Removed |Added CC||et at ihear dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug fortran/24884] New: compiles invalid-code
This test is taken from http://ftp.cac.psu.edu/pub/ger/fortran/test/ $ cat test.f90 MODULE all_sub PRIVATE PUBLIC :: test1,test2 CONTAINS SUBROUTINE test1(a,n) IMPLICIT NONE INTEGER,INTENT(in) :: n REAL,INTENT(out), DIMENSION(n) :: a REAL :: b WRITE(*,*) 'Problem with intent(out) checkable at compile time' !---Elements of array, a, have not yet been defined within Subroutine ! test1. The following line violates Fortran 90 Standard 5.1.2.3 ! Intent Attribute. b=a(2) WRITE(*,*) b a(:)=4. END SUBROUTINE test1 SUBROUTINE test2(a,n,code) IMPLICIT NONE INTEGER,INTENT(in) :: n REAL, INTENT(out), DIMENSION(n) :: a LOGICAL, INTENT(in) :: code REAL :: b IF (code) THEN WRITE(*,*) 'Problem with intent(out) checkable at run time' !---Elements of array, a, have not yet been defined within Subroutine ! test1. The following line violates Fortran 90 Standard 5.1.2.3 ! Intent Attribute. b=a(2) WRITE(*,*) b END IF a(:)=4. END SUBROUTINE test2 END MODULE all_sub PROGRAM tintent2 USE all_sub, ONLY : test1, test2 IMPLICIT NONE INTEGER, PARAMETER :: n=7 REAL, DIMENSION(n) :: a a(:)=10. CALL test1(a,n) CALL test2(a,n,.TRUE.) pause END PROGRAM tintent2 $ gfortran test.f90 $ ./a.out Problem with intent(out) checkable at compile time 10.0 Problem with intent(out) checkable at run time 4.00 PAUSE To resume execution, type go. Other input will terminate the job. go RESUMED This should have given following error (compile time) The variable (a(2)) has an undefined value. -- Summary: compiles invalid-code Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24884
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Comment #20 from pcarlini at suse dot de 2005-11-15 22:16 --- About the optimization issue, maybe we should file a separate enhancement PR, if there isn't already one. Really, we should be able to optimize well any variant of this kind of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug target/24772] Lots of ICEs in vrsave_operation_1 while running the testsuite on powerpc
--- Comment #4 from dje at gcc dot gnu dot org 2005-11-15 22:27 --- Patch -- dje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01176.html Status|NEW |ASSIGNED Last reconfirmed|2005-11-10 09:34:09 |2005-11-15 22:27:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24772
[Bug libstdc++/21251] Placement into shared memory
--- Comment #10 from pcarlini at suse dot de 2005-11-15 22:38 --- To be sure we don't confuse two issues here (see also my #7), all the containers are already able to use shared memory allocators such as libmm: http://www.ossp.org/pkg/lib/mm/ (via a very lightweight wrapper). This is even true for basic_string if config with --fully-dynamic-string, and certainly for ext/vstring (or basic_string in v7-branch). Another thing is the first issue in this PR, i.e., using a placement new in shared memory, the last comment #9 if I understand well, things like that. Maybe it would be better separate the two issues in separate PRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug fortran/24884] compiles invalid-code
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-15 23:15 --- Show me one compiler that catches this. HP doesn't, and Intel doesn't. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24884
[Bug fortran/24885] New: fails to report runtime error
Following code fails to report the runtime error. The program goes into infinite loop. $ cat test.f90 program modify_by_include implicit none integer i do i = 1, 10 call dangerous_inclusion write(*,'(a,i0)') ' i = ', i end do contains subroutine dangerous_inclusion i = i+2 end subroutine dangerous_inclusion end program modify_by_include $ gfortran test.f90 $ ./a.out i = 3 i = 6 i = 9 i = 12 i = 15 i = 18 i = 21 i = 24 i = 27 i = 30 i = 33 i = 36 i = 39 i = 42 i = 45 i = 48 i = 51 i = 54 i = 57 i = 60 ... Infinite loop -- Summary: fails to report runtime error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24885
