[Bug target/25920] after compiled with -pg for profiling, all the spec2kfp cases failed at runtime
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:02 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25920
[Bug target/27767] Problem: gcc 4.0.3 on Unix_SV
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-13 06:05 --- This is nothing we can really do for very very old versions of GCC really, they are no longer supported. By the way when building 3.3.4, you should use make bootstrap and not just make, it will most likely pass at that point. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27767
[Bug c++/20599] variadic template support
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-09-13 06:19 --- For the record, I'm strongly in favor of variadic templates. Key parts of TR1 (tuple, functional) necessitate some kind of compiler support in order to have full implementations: the current limits on tuple size are an embarrasment. The current implementation strategies for these library elements are highly complex and far too pre-processor slap-happy for my comfort or taste. As these parts of TR1 are already (as of Berlin) part of C++0X, I think it behooves the C++ community to get real about robust solutions. I think starting -std=c++0x is a great idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug other/29049] possible problem: building gcc = 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
--- Comment #27 from WISD00M at GMX dot NET 2006-09-13 06:19 --- (In reply to comment #26) # uname -a as previously mentioned (comment #9), it's: Linux syssiphus 2.6.17.4 #1 SMP PREEMPT Mon Sep 11 14:42:28 CEST 2006 i686 unknown # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 901.73 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 900.09 processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 901.13 processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 902.21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
[Bug middle-end/28964] [4.0/4.1/4.2 Regression] partition_stack_vars uses unstable sort
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 06:21 --- Confirmed, this is a regression as partition_stack_vars is new in 4.0.x. I am thinking about either creating a meta-bug or a keyword about all the problems with unstable sorts/hashing with memory addresses problems. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 06:21:02 date|| Summary|partition_stack_vars uses |[4.0/4.1/4.2 Regression] |unstable sort |partition_stack_vars uses ||unstable sort Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug bootstrap/28962] building a cross compiler with --disable-multilib fails
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-13 06:23 --- (In reply to comment #7) Is there a good reason why gcc can't officially support being built without a libc by either figuring out that there's no libc itself or by offering some kind of --i-do-not-have-a-libc option to configure? Yes because you are configuring wrong in the first place. Try looking at what crosstool does for how to build a cross compiler. http://kegel.com/crosstool/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-09-13 06:26 --- Janis, this is how to set timeout on the make check command line: time make check RUNTESTFLAGS=-v -v -v -v --tool_opts timeout=300 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug c++/29028] No warning about unused names introduced with using declarations
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028
[Bug other/28994] host-darwin.c not 64bit clean
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 06:29 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 06:29:13 date|| Summary|64-bit problem in host- |host-darwin.c not 64bit |darwin.c|clean http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
[Bug rtl-optimization/28982] Incorrect reloading of automodification expressions
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-09-13 06:31 --- Subject: Bug 28982 Author: rsandifo Date: Wed Sep 13 06:30:59 2006 New Revision: 116919 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116919 Log: gcc/ PR rtl-optimization/28982 * reload.c (find_reloads_address_1): Use RELOAD_OTHER for the index of a PRE_MODIFY or POST_MODIFY address. * reload1.c (inc_for_reload): Use find_replacement on the original base and index registers. gcc/testsuite/ PR rtl-optimization/28982 * gcc.c-torture/execute/pr28982a.c: New test. * gcc.c-torture/execute/pr28982b.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr28982a.c trunk/gcc/testsuite/gcc.c-torture/execute/pr28982b.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28982
[Bug rtl-optimization/28982] Incorrect reloading of automodification expressions
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-09-13 06:32 --- Patch applied -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28982
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #3 from ian at airs dot com 2006-09-13 06:36 --- When I run the demangler on _ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE I get void jmain::main(JArrayjava::lang::String**) The relevant patch went in on 2005-12-10 to libiberty/cp-demangle.c. Can you confirm that you have that patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-13 06:39 --- (In reply to comment #3) When I run the demangler on _ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE I get void jmain::main(JArrayjava::lang::String**) What happens when running it in Java mode (note the -s java)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug rtl-optimization/28622] [4.1 regression] ICE in extract_insn, at recog.c:2084 (unecognizable insn) [m68k]
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-13 06:46 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-07 23:00:26 |2006-09-13 06:46:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
[Bug c++/29016] [4.2 Regression] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:56 ---
This one works for me but I doubt it is correct:
Index: ../../gcc/ipa-utils.c
===
--- ../../gcc/ipa-utils.c (revision 116919)
+++ ../../gcc/ipa-utils.c (working copy)
@@ -212,6 +212,7 @@ ipa_utils_reduced_inorder (struct cgraph
tree
get_base_var (tree t)
{
+ tree temp;
if ((TREE_CODE (t) == EXC_PTR_EXPR) || (TREE_CODE (t) == FILTER_EXPR))
return t;
@@ -221,7 +222,11 @@ get_base_var (tree t)
TREE_CODE (t) != FUNCTION_DECL
TREE_CODE (t) != CONST_DECL)
{
- t = TREE_OPERAND (t, 0);
+ temp = staticp (t);
+ if (temp)
+t = temp;
+ else
+t = TREE_OPERAND (t, 0);
}
return t;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #5 from ian at airs dot com 2006-09-13 07:23 --- OK, with -s java I get jmain.main(java.lang.String[])void I misunderstood Daniel's report. Sorry about that. The fact that the function's return type is printed at the end is deliberate. This is because -s java sets DMGL_RET_POSTFIX. This was added as part of the patch for PR 9861. I've added Terry to the CC list for this PR; perhaps he can explain why it works that way. -- ian at airs dot com changed: What|Removed |Added CC||tj at laurenzo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug target/28622] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 07:57
---
The removed comment says:
- /* If will do cse, generate all results into pseudo registers
- since 1) that allows cse to find more things
- and 2) otherwise cse could produce an insn the machine
- cannot support. An exception is a CONSTRUCTOR into a multi-word
- MEM: that's much more likely to be most efficient into the MEM.
- Another is a CALL_EXPR which must return in memory. */
So it looks like point 2 is true.
Except that CSE has not been run yet. :-)
The problem is that the ashrdi3 expander is not matched by existing insns in
the (MEM, MEM, CONST_INT) case. Either the predicates need to be tightened
or one of the operands needs to be forced to a register in the preparation
statements.
While you're at it, please delete the 3 bogus comments added by Jeff as part
of revision 24814:
(define_expand ashrdi3
[(set (match_operand:DI 0 nonimmediate_operand )
(ashiftrt:DI (match_operand:DI 1 general_operand )
(match_operand 2 const_int_operand )))]
!TARGET_COLDFIRE
{
/* ??? This is a named pattern like this is not allowed to FAIL based
on its operands. */
if (GET_CODE (operands[2]) != CONST_INT
|| ((INTVAL (operands[2]) 1 || INTVAL (operands[2]) 3)
INTVAL (operands[2]) != 8 INTVAL (operands[2]) != 16
(INTVAL (operands[2]) 31 || INTVAL (operands[2]) 63)))
FAIL;
} )
Of course expanders are allowed to fail in the preparation statements based
on their operands, that's precisely why FAIL exists! See the example in the
13.15 section of the internals manual.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
Component|rtl-optimization|target
GCC host triplet|m68k-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
[Bug bootstrap/29058] New: Unable to build under Irix 6.5
Hi!
I don't seem to be able to build the development sources (4.2.0 20060911) under
SGI ('uname -a': IRIX64 fuel3 6.5 01100304 IP35).
I've tried several things, but I keep getting the following error when
'bootstraping':
config.status: executing default commands
if [ x != x ] [ ! -d pic ]; then \
mkdir pic; \
else true; fi
touch stamp-picdir
UX:make: ERROR: don't know how to make regex.c (bu42).
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
This is most likely related to our local set-up (...), but I have absolutely no
idea of what else I can do, or where else to look for help...
Can anyone suggest anything?
Thanks!
Philippe
PS: the way I'm getting about to it: setenv CC gcc ;
/USER/philippe/Irix/Gcc_Sources/configure
--prefix=/USER/philippe/Irix/Gcc --enable-languages=c,fortran
--disable-maintainer-mode --disable-shared
--with-mpfr=/USER/philippe/Irix/Mpfr --with-gmp=/USER/philippe/Irix/Gmp
--with-htmldir ; make
--
Summary: Unable to build under Irix 6.5
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29058
[Bug rtl-optimization/28618] The scheduler extends the lifetime of CLASS_LIKELY_SPILLED registers
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:18 --- There might be problems if no matching set can be found in the current basic block. I'll have to think about how to best check for this. I'm currently leaning to add a field in struct deps for the head of the current basic block, and setting that field in sched_analyze. Why not use reg_last-sets? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 08:18:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28618
[Bug fortran/29051] segfault when too few values are in data statement of character array
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-13 08:21 --- Bud, Quite by chance, I had noticed the cause of this a couple of days ago; if you look at the Doxygen documentation for gfc_data, you will see that the only reference to the locus field 'where' is in resolve.c(resolve_data), where the error is emitted. I was mulling over where the locus was being set and why the documentation might miss it, when I saw your PR and realised that it isn't set at all! An Occam's Razor moment. The patch is going to the list in a few minutes. 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|2006-09-13 04:27:37 |2006-09-13 08:21:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29051
[Bug c++/29059] New: [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
Compiling as C works, C++ fails. This worked with 20060823.
(sid)118:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O re-ru32un.c
re-ru32un.c: In function 'void LoadUserAlph(char*)':
re-ru32un.c:4: error: invalid operand to unary operator
[0];
re-ru32un.c:4: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
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.1/README.Bugs.
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c -O re-ru32un.c
(sid)119:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c re-ru32un.c
(sid)120:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O re-ru32un.c
(sid)121:[EMAIL PROTECTED]: ~] cat re-ru32un.c
extern char *strcpy (char *__restrict __dest, __const char *__restrict __src);
char wrkstr_un[270];
extern void
LoadUserAlph (char *s)
{
s = wrkstr_un;
strcpy (s, );
};
--
Summary: [4.2 regression] ICE: verify_stmts failed (invalid
operand to unary operator [0];)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug rtl-optimization/28173] [4.0/4.1 regression] misses constant folding
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:24 --- Roger, could you comment on Ramana's proposition? Thanks in advance. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot ||org, ebotcazou at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28173
[Bug rtl-optimization/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:32 --- Please indicate whether it's a regression from earlier versions of GCC. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Comment #7 from irar at il dot ibm dot com 2006-09-13 08:32 --- I think, the problem here is that we only check SMT and not NMT. I am preparing a patch to fix this. NMT is stored in ptr_info_def of data-ref, and only if it does not exist, SMT will be checked. -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com, ||dnovillo at redhat dot com AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-21 01:04:59 |2006-09-13 08:32:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug fortran/29051] segfault when too few values are in data statement of character array
--- Comment #5 from patchapp at dberlin dot org 2006-09-13 08:35 --- Subject: Bug number PR29051 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00496.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29051
[Bug rtl-optimization/28062] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:37 --- If the ICE has disappeared on both branches, the testcase should be added to the testsuite and the PR closed. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Summary|[latent] ICE in |ICE in simplify_subreg, at |simplify_subreg, at |simplify-rtx.c:4466 |simplify-rtx.c:4466 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:44 --- Please indicate the version(s) of the compiler, whether it's a regression, etc. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #6 from aph at gcc dot gnu dot org 2006-09-13 09:01 --- I don't understand why this bug has been reported. Are you using an up-to-date libiberty to do the demangling? When I try c++filt --format java, I get Hello.main(java.lang.String[])void which is correct. The exact form of the demangled string was discussed at greeat length in the thread http://gcc.gnu.org/ml/java-patches/2005-q3/msg00414.html. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug c++/29043] Constructor for POD type with const member without member initializer accepted
--- Comment #2 from andrew dot stubbs at st dot com 2006-09-13 09:23
---
(In reply to comment #1)
As you've written it, class C doesn't have any non-static members. Struct
C::s
hasn't been declared as a member object of C. const int i is a member of
C::s,
not C, so C() without member initializers should be acceptable.
How about this example:
struct S {
const int i;
};
class C
{
public:
C() { }
S s;
};
void f()
{
C c;
S s;
}
This fails at the line `S s;' in f(), but the `C c;' line is accepted silently.
The standard says the requirement applies to data-members *containing* a member
of const-qualified type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-13
10:10 ---
(In reply to comment #5)
This is not DLL-related, the following code doesn't have the expected
behaviour
(although it works fine on i686-linux, even in the static case):
$ cat ctesti.c
#include stdio.h
void print_from_gcc(char* txt) {
printf(%s\n,txt);
}
int main(int argc, char** argv) {
print_from_gcc (c);
print_from_gfortran_(f);
print_from_gcc (c);
print_from_gfortran_(f);
return 0;
}
Changing main() in ctesti.c to start with:
int main(int argc, char** argv) {
setvbuf(stdout, NULL, _IOLBF, 0);
fixes the redirection problem.
If you stll think that this is a libgfortran bug (I don't)
you could add
setvbuf(stdout, NULL, _IOLBF, 0);
to unix.c:output_stream() so that stdout always is line-buffered even when
!isatty(fileno(stdout))
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug java/28090] incorrect implementation of expand_java_arraystore
--- Comment #4 from bonzini at gnu dot org 2006-09-13 10:10 --- PR19505 is fixed, is the patch still bad? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28090
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression]|[4.1/4.2 regression] |procedure doesn't modify In |procedure doesn't modify In |Out parameter |Out parameter Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #1 from bonzini at gnu dot org 2006-09-13 10:43 --- A somewhat disconnected comment on the ecj-branch build process... Are you planning to distribute ecj as a JAR file too? If so, there should be no changes to the documentation for building out of tarballs. If you don't want to put the JAR in svn, To build from svn, a pre-existing GCJ would be necessary that can build ecj. The build process should go like this: - the gcc directory builds the bytecode-native compiler - if there is a JAR, the ecj directory looks for ../gcc/gcj and uses that one to build the native compiler - if not, the toplevel configury should pass the path to a GCJ somewhere and the ecj directory will use it to build the JAR. I think the JAR should be built in the build directory, unless --enable-generated-files-in-srcdir. more on the third bullet: find the GCJ in the toplevel, as we do for C++ (grep for CXX= in the toplevel configure -- there is room for improvement but I don't think it's important). In the Makefile.tpl, add somewhere [EMAIL PROTECTED]@ and pass it down to ecj via HOST_FLAGS_TO_PASS. Later on, ecj could even be bootstrapped using POSTSTAGE1_FLAGS_TO_PASS to point to the just build gcj and ecj. (How does gcj find the ecj to use? Might this require spec hacking?) -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
[Bug c++/29054] [4.0/4.1 Regression] ICE on friend template specialization
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-13 11:39 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.3 4.1.1 Known to work|4.2.0 |3.4.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-13 11:39:13 date|| Summary|ICE on friend template |[4.0/4.1 Regression] ICE on |specialization |friend template ||specialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
[Bug c++/29054] [4.0/4.1 Regression] ICE on friend template specialization
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-13 11:41 --- (gdb) run Starting program: /abuild/rguenther/gcc41-g/gcc/cc1plus -quiet t.ii Program received signal SIGSEGV, Segmentation fault. 0x080f565b in instantiate_decl (d=0xb7d9cf00, defer_ok=0, expl_inst_class_mem_p=0 '\0') at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:11957 11957 spec_parm = TREE_CHAIN (spec_parm); both tmpl_parm and spec_parm are zero. (gdb) bt #0 0x080f565b in instantiate_decl (d=0xb7d9cf00, defer_ok=0, expl_inst_class_mem_p=0 '\0') at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:11957 #1 0x080f5e1a in instantiate_pending_templates (retries=0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:12065 #2 0x0813fa19 in cp_finish_file () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/decl2.c:2857 #3 0x08049d18 in finish_file () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/cp-lang.c:144 #4 0x0826bac4 in c_common_parse_file (set_yydebug=0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/c-opts.c:1144 #5 0x086d9d84 in compile_file () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/toplev.c:991 #6 0x086db68f in do_compile () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/toplev.c:1949 #7 0x086db6f1 in toplev_main (argc=3, argv=0xbf939b04) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/toplev.c:1981 #8 0x0827e022 in main (argc=Cannot access memory at address 0x0 ) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
[Bug fortran/29060] New: spread causes ICE in gfc_trans_array_constructor
Hi, I got AN ICE trying to compile -- module bcc implicit none private type md_field real,dimension(:,:),pointer :: position end type md_field real,dimension(1:3,1:2),parameter :: unitcell = reshape((/ 0.25,0.25,0.25, 0.75,0.75,0.75 /),(/3,2/)) contains subroutine createBccLattice(x,counts) integer,dimension(1:3),intent(in) :: counts type(md_field),pointer :: x integer :: i,j,k do i=1,counts(1) do j=1,counts(2) do k=1,counts(3) x % position(:,1:2) = unitcell + spread((/ i,j,k/),2,size(unitcell,2)) end do end do end do return end subroutine createBccLattice end module bcc -- maybe it is related to some other spread related errors, I encountered in an older gfortran debian package, which seemed to occure only after several spread calls. Unfortunately at that time it was too difficult to get a nice code snippet for the report. For your information: [EMAIL PROTECTED]:~/bugs/gfortran$ LANG=C gfortran -v -c ICE5.f90 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) /usr/lib/gcc/x86_64-linux-gnu/4.1.2/f951 ICE5.f90 -quiet -dumpbase ICE5.f90 -mtune=k8 -auxbase ICE5 -version -o /tmp/ccsURLG7.s GNU F95 version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) (x86_64-linux-gnu) compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128471 ICE5.f90: In function 'createbcclattice': ICE5.f90:11: internal compiler error: in gfc_trans_array_constructor, at fortran/trans-array.c:1317 Please submit a full bug report, with preprocessed source if appropriate. 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.1/README.Bugs. [EMAIL PROTECTED]:~/bugs/gfortran$ -- Summary: spread causes ICE in gfc_trans_array_constructor Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: keinstein_junior at gmx dot net 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=29060
[Bug target/29030] gcc.dg/array-9.c produces internal compiler error on Darwin at -m64
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2006-09-13 12:20 --- Andrew, The proposed patch doesn't work. It converts the internal compiler error into a compiler time error of... gcc-4 -O3 -g -m64 array-9.c array-9.c:7: error: declaration of 'x' as array of voids -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
mcfv4e flag to gas
Hi
I am using gcc 20060906 snapshot to compile a 2.6.10 kernel for a
Coldfire MCF5484 (and uclibc 0.9.28).
The question is that I was getting some errors like this:
{standard input}: Assembler messages:
{standard input}:22: Error: invalid instruction for this architecture;
needs ColdFire ISA_B (5407 [5470, 5471, 5472, 5473, 5474, 5475], 547x
[5475, 5474, 5473, 5472, 5471, 5470, 5480, 5481, 5482, 5483, 5484,
5485], 548x [5485, 5484, 5483, 5482, 5481, 5480]) -- statement `mov3q.l
#1,%d0' ignored
So it seems that although the flag -mcfv4e was being used for gcc, it
was not passed into the assembler. I checked this with -v option, and I
check that.
No -mcfv4e flag was being passed into gas.
I am solving this setting -Xassembler -mcfv4e flags, but I suppose this
is not the best way to solve this.
Any ideas?
Thanks
Miguel Ángel Álvarez
- PLEASE NOTE
---
This message, along with any attachments, may be confidential or legally privileged.
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and
notify the sender immediately.
Thank you for your help.
µSysCom uses virus scanning software but excludes any liability for viruses
contained in any attachment.
ROGAMOS LEA ESTE TEXTO
---
Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal.
Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.
µSysCom utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #7 from drow at gcc dot gnu dot org 2006-09-13 12:31 --- Subject: Re: Libiberty demangler can not handle new Java mangling. I don't understand why this bug has been reported. The bug was reported because the combination of the mangling change and the demangler postfix behavior messes up GDB. You used to be able to say break 'jmain.main(java.lang.String[])' but now that's not found; you'd have to add the trailing void manually. As per your message: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00434.html Several affected tests in the GDB testsuite broke. Of course they're somewhat provisional tests because there are earlier tests in the same file which use much more user-friendly forms, that are still not supported by GDB. The Java debug support has not gotten much love lately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #8 from drow at gcc dot gnu dot org 2006-09-13 12:31 --- Not a bug then. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug c++/29046] Failure to define friend functions for all template instatiations
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-09-13 13:46 --- (In reply to comment #4) (In reply to comment #3) Now we don't do that either but that is a different bug. Actually we do reject it with -pedantic so that is not a different bug after all but a change, a delerate change in fact. Are you sure that is a change at all? I tested using -pedantic . The compiler version I've used won't give a diagnostic without -pedantic, either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29046
[Bug testsuite/29055] gcc.target/powerpc/darwin-bool-1.c fails on powerpc-apple-darwin8 at -m64
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-13
13:52 ---
So I assume I just need to create a patch that adds...
* { dg-skip-if { powerpc*-*-darwin* } { -m64 } { } } */
to the darwin-bool-1.c testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29055
[Bug java/29061] New: nternal compiler error: in make_class_data, at java/class.c:1774
testserver.java in Jessie 1.0.1. cmmand : gcj -v -c -o testserver.o testserver.java Using built-in specs. Reading specs from /usr/lib/gcc/i586-suse-linux/4.1.0/../../../libgcj.spec rename spec lib to liborig Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.0 (SUSE Linux) /usr/lib/gcc/i586-suse-linux/4.1.0/jc1 testserver.java -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase testserver.java -mtune=generic -auxbase-strip testserver.o -g1 -version -o /tmp/ccZeNZmX.s GNU Java version 4.1.0 (SUSE Linux) (i586-suse-linux) compiled by GNU C version 4.1.0 (SUSE Linux). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64554 Class path starts here: /usr/local/classpath/share/classpath/glibj.zip/ (zip) /usr/share/java/libgcj-4.1.0.jar/ (system) (zip) testserver.java:9: internal compiler error: in make_class_data, at java/class.c:1774 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: nternal compiler error: in make_class_data, at java/class.c:1774 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linh at mytum dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #1 from linh at mytum dot de 2006-09-13 14:16 --- Created an attachment (id=12251) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12251action=view) this testserver in jesssie-1.0.1 is compiled under classpath-0.92. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug other/29049] possible problem: building gcc = 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
--- Comment #28 from hjl at lucon dot org 2006-09-13 15:03 --- Apparently, your target_flags sets MASK_64BIT. You need to run gdb on cc1 and set hardware watchpoint on target_flags to see where it sets MASK_64BIT: [EMAIL PROTECTED] gcc]$ touch x.i [EMAIL PROTECTED] gcc]$ gdb cc1 GNU gdb 6.4.50.20060406-cvs Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/tls/libthread_db.so.1. Breakpoint 1 at 0x8138b96: file ../../gcc/diagnostic.c, line 602. Breakpoint 2 at 0x8138b43: file ../../gcc/diagnostic.c, line 547. Function exit not defined. Function abort not defined. (gdb) watch target_flags Hardware watchpoint 3: target_flags (gdb) r -fpreprocessed x.i -quiet -dumpbase x.i -mtune=pentiumpro -auxbase x -version -o x.s Starting program: /export/gnu/import/gcc-4.1.0/build/gcc/cc1 -fpreprocessed x.i -quiet -dumpbase x.i -mtune=pentiumpro -auxbase x -version -o x.s Hardware watchpoint 3: target_flags Hardware watchpoint 3: target_flags Hardware watchpoint 3: target_flags Old value = 0 New value = 8388808 decode_options (argc=12, argv=0xbff24ef4) at ../../gcc/opts.c:634 634 flag_unwind_tables = targetm.unwind_tables_default; (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. Hardware watchpoint 3: target_flags Old value = 8388808 New value = 8405192 override_options () at ../../gcc/config/i386/i386.c:1614 1614 if (TARGET_SSEREGPARM (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. Hardware watchpoint 3: target_flags Old value = 8405192 New value = 8405208 override_options () at ../../gcc/config/i386/i386.c:1667 1667 if ((flag_unwind_tables || flag_asynchronous_unwind_tables (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. GNU C version 4.1.0 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-3). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2547d670e9349240a4187f725ff2e074 Program exited normally. (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
[Bug c/29062] New: Parse error after label and variable declaration
Consider following code:
//
1 int main(int argc, char** argv) {
2if (argc 1) {
3 goto finish;
4}
5 finish:
6int ret = 1;
7return ret;
8 }
//
Though I tested different versions of GCC (3.3.5, 3.4.4, 4.1.1), I was not able
to compile the code above. This is the error message on a debian sarge with GCC
3.3.5:
//
[EMAIL PROTECTED]:~/src gcc label.c
label.c: In function `main':
label.c:8: error: syntax error before int
label.c:9: error: `ret' undeclared (first use in this function)
label.c:9: error: (Each undeclared identifier is reported only once
label.c:9: error: for each function it appears in.)
//
I am not sure, whether my code violates the standard, or this is a bug.
However, if I enclose the code after the finish label with curly brackets
(lines 6 and 7), the error disappears.
--
Summary: Parse error after label and variable declaration
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tdalman at project-psi dot org
GCC host triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug libstdc++/29063] New: valarray does not undefine all temp macros
valarray should undefine all temp macros, but it does not
$ cat test.cpp
#include valarray
$ g++-4.0 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.1 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.2 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.0 -E -dM test.cpp | grep _DEFINE_
#define _DEFINE_ARRAY_FUNCTION(_Op,_Name) templatetypename _Tp inline void
_Array_augmented_ ##_Name(_Array_Tp __a, size_t __n, const _Tp __t) { for
(_Tp* __p = __a._M_data; __p __a._M_data + __n; ++__p) *__p _Op ##= __t; }
templatetypename _Tp inline void _Array_augmented_ ##_Name(_Array_Tp __a,
size_t __n, _Array_Tp __b) { _Tp* __p = __a._M_data; for (_Tp* __q =
__b._M_data; __q __b._M_data + __n; ++__p, ++__q) *__p _Op ##= *__q; }
templatetypename _Tp, class _Dom void _Array_augmented_ ##_Name(_Array_Tp
__a, const _Expr_Dom, _Tp __e, size_t __n) { _Tp* __p(__a._M_data); for
(size_t __i = 0; __i __n; ++__i, ++__p) *__p _Op ##= __e[__i]; }
templatetypename _Tp inline void _Array_augmented_ ##_Name(_Array_Tp __a,
size_t __n, size_t __s, _Array_Tp __b) { _Tp* __q(__b._M_data); for (_Tp* __p
= __a._M_data; __p __a._M_data + __s * __n; __p += __s, ++__q) *__p _Op ##=
*__q; } templatetypename _Tp inline void _Array_augmented_
##_Name(_Array_Tp __a, _Array_Tp __b, size_t __n, size_t __s) { _Tp*
__q(__b._M_data); for (_Tp* __p = __a._M_data; __p __a._M_data + __n; ++__p,
__q += __s) *__p _Op ##= *__q; } templatetypename _Tp, class _Dom void
_Array_augmented_ ##_Name(_Array_Tp __a, size_t __s, const _Expr_Dom, _Tp
__e, size_t __n) { _Tp* __p(__a._M_data); for (size_t __i = 0; __i __n;
++__i, __p += __s) *__p _Op ##= __e[__i]; } templatetypename _Tp inline void
_Array_augmented_ ##_Name(_Array_Tp __a, _Arraysize_t __i, _Array_Tp __b,
size_t __n) { _Tp* __q(__b._M_data); for (size_t* __j = __i._M_data; __j
__i._M_data + __n; ++__j, ++__q) __a._M_data[*__j] _Op ##= *__q; }
templatetypename _Tp inline void _Array_augmented_ ##_Name(_Array_Tp __a,
size_t __n, _Array_Tp __b, _Arraysize_t __i) { _Tp* __p(__a._M_data); for
(size_t* __j = __i._M_data; __j__i._M_data + __n; ++__j, ++__p) *__p _Op ##=
__b._M_data[*__j]; } templatetypename _Tp, class _Dom void _Array_augmented_
##_Name(_Array_Tp __a, _Arraysize_t __i, const _Expr_Dom, _Tp __e,
size_t __n) { size_t* __j(__i._M_data); for (size_t __k = 0; __k__n; ++__k,
++__j) __a._M_data[*__j] _Op ##= __e[__k]; } templatetypename _Tp void
_Array_augmented_ ##_Name(_Array_Tp __a, _Arraybool __m, _Array_Tp __b,
size_t __n) { bool* __ok(__m._M_data); _Tp* __p(__a._M_data); for (_Tp* __q =
__b._M_data; __q __b._M_data + __n; ++__q, ++__ok, ++__p) { while (! *__ok) {
++__ok; ++__p; } *__p _Op ##= *__q; } } templatetypename _Tp void
_Array_augmented_ ##_Name(_Array_Tp __a, size_t __n, _Array_Tp __b,
_Arraybool __m) { bool* __ok(__m._M_data); _Tp* __q(__b._M_data); for (_Tp*
__p = __a._M_data; __p __a._M_data + __n; ++__p, ++__ok, ++__q) { while (!
*__ok) { ++__ok; ++__q; } *__p _Op ##= *__q; } } templatetypename _Tp, class
_Dom void _Array_augmented_ ##_Name(_Array_Tp __a, _Arraybool __m, const
_Expr_Dom, _Tp __e, size_t __n) { bool* __ok(__m._M_data); _Tp*
__p(__a._M_data); for (size_t __i = 0; __i __n; ++__i, ++__ok, ++__p) { while
(! *__ok) { ++__ok; ++__p; } *__p _Op ##= __e[__i]; } }
#define _DEFINE_BINARY_OPERATOR(_Op,_Name) templatetypename _Tp inline
_Expr_BinClos_Name, _ValArray, _ValArray, _Tp, _Tp, typename __fun_Name,
_Tp::result_type operator _Op(const valarray_Tp __v, const valarray_Tp
__w) { _GLIBCXX_DEBUG_ASSERT(__v.size() == __w.size()); typedef _BinClos_Name,
_ValArray, _ValArray, _Tp, _Tp _Closure; typedef typename __fun_Name,
_Tp::result_type _Rt; return _Expr_Closure, _Rt(_Closure(__v, __w)); }
templatetypename _Tp inline _Expr_BinClos_Name, _ValArray,_Constant, _Tp,
_Tp, typename __fun_Name, _Tp::result_type operator _Op(const
valarray_Tp __v, const _Tp __t) { typedef _BinClos_Name, _ValArray,
_Constant, _Tp, _Tp _Closure; typedef typename __fun_Name, _Tp::result_type
_Rt; return _Expr_Closure, _Rt(_Closure(__v, __t)); } templatetypename _Tp
inline _Expr_BinClos_Name, _Constant, _ValArray, _Tp, _Tp, typename
__fun_Name, _Tp::result_type operator _Op(const _Tp __t, const
valarray_Tp __v) { typedef _BinClos_Name, _Constant, _ValArray, _Tp, _Tp
_Closure; typedef typename __fun_Name, _Tp::result_type _Rt; return
_Expr_Closure, _Tp(_Closure(__t, __v)); }
$ g++-4.0 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java
--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-clocale=gnu
--enable-libstdcxx-debug --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-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.0.4 20060904 (prerelease) (Debian
[Bug c/29062] Parse error after label and variable declaration
--- Comment #1 from schwab at suse dot de 2006-09-13 15:32 --- A label can only be part of a statement. A declaration is not a statement. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Parse error after label and |Parse error after label and |variable declaration|variable declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug fortran/28526] 'end' is recognized as a variable incorrectly
--- Comment #3 from tobi at gcc dot gnu dot org 2006-09-13 16:06 --- This is intriguing. Why would 'end' be treated any different from 'xxx'? -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:06:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28526
[Bug c++/29043] Constructor for POD type with const member without member initializer accepted
--- Comment #3 from bangerth at dealii dot org 2006-09-13 16:10 --- Confirmed with the testcase from attachment #2. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:10:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
[Bug fortran/28443] gfortran does not implement the present intrinsic procedure correctly for optional character strings
--- Comment #8 from tobi at gcc dot gnu dot org 2006-09-13 16:11 --- This is another variation of the theme in 26227 *** This bug has been marked as a duplicate of 26227 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28443
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #6 from tobi at gcc dot gnu dot org 2006-09-13 16:11 --- *** Bug 28443 has been marked as a duplicate of this bug. *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||cyan+gcc at compsoc dot ||nuigalway dot ie http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug fortran/28809] No diagnostic for missing interface for same file procedure
--- Comment #4 from tobi at gcc dot gnu dot org 2006-09-13 16:12 --- Again, the same theme as 26227. *** This bug has been marked as a duplicate of 26227 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28809
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #7 from tobi at gcc dot gnu dot org 2006-09-13 16:12 --- *** Bug 28809 has been marked as a duplicate of this bug. *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||jchodera at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug c++/29059] [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:17 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-checking, ice-on-valid- ||code Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:17:26 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug rtl-optimization/28062] [latent] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-13 16:20 --- (In reply to comment #13) If the ICE has disappeared on both branches, the testcase should be added to the testsuite and the PR closed. But the bug still exists, just was covered up by my tree-inline patches for PR 28075. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in simplify_subreg, at |[latent] ICE in |simplify-rtx.c:4466 |simplify_subreg, at ||simplify-rtx.c:4466 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug target/29030] gcc.dg/array-9.c produces internal compiler error on Darwin at -m64
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-13 16:22 ---
(In reply to comment #5)
Andrew,
The proposed patch doesn't work. It converts the internal
compiler error into a compiler time error of...
Yes the patch does work as this is invalid code to begin with :).
Look at the testcase:
struct A
{
int i;
void x[1]; /* { dg-error array of voids } */
};
void foo(struct A a) {}
See how there is a dg-error there, that error is expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
[Bug libstdc++/29063] valarray does not undefine all temp macros
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:27 --- _D is in the reserved identifier space IIRC so I think this is a non bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29063
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-13 16:45 --- I tried this with 4.1 (failed due to missing imports), the RH 4.1 (worked) and svn head (worked). So, I think we would need more information to proceed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 16:49 --- I am thinking SUSE created their 4.1.0 before 4.1.0 was release, I think this is the same as PR 25366. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug libstdc++/29063] valarray does not undefine all temp macros
--- Comment #2 from pcarlini at suse dot de 2006-09-13 16:51 --- As a matter of fact valarray *always* undefines the macros, besides in those two specific cases (and the first one is even undefined weren't for a typo ;) So, we can as well do the two-lines change... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:51:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29063
[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite
--- Comment #6 from janis at gcc dot gnu dot org 2006-09-13 16:54 --- Benjamin, I had tried that, but it adds timeout=300 to the options passed to the compiler. Does it really work for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug bootstrap/29058] Unable to build under Irix 6.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:56 --- UX:make: ERROR: don't know how to make regex.c (bu42). This sounds like you are not using GNU make which is required. Can you try again this time using GNU make? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|Unable to build under Irix |Unable to build under Irix |6.5 |6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29058
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #4 from linh at mytum dot de 2006-09-13 16:59 --- (In reply to comment #2) I tried this with 4.1 (failed due to missing imports), the RH 4.1 (worked) and svn head (worked). So, I think we would need more information to proceed. I compiled this with 4.1, Suse 10.1. Now I try this with jikes 1.22. Then It works well. I think it is a bug with gcj in Suse 10.1. Thanks for help -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #5 from tromey at gcc dot gnu dot org 2006-09-13 17:17 --- Fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug rtl-optimization/28062] [latent] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-13 17:37 --- But the bug still exists, just was covered up by my tree-inline patches for PR 28075. Your patch may simply be the fix. If we have no testcase, we have no bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
--- Comment #4 from mbo dot massimo at tiscali dot it 2006-09-13 18:03 --- I have installed the fix and the problem is now resolved. I have tested it on a large program and it is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug c++/29065] New: obscure error for attempt to use destructor declarator syntax for destructor call
This code snippet:
class X
{
~X() {}
void f ()
{
X::~X ();
}
};
violates clause 12.4 ; 12 (explicit destructor calls must use a member
access operator) . However, the diagnostic given is somewhat confusing:
dstr.c: In member function void X::f():
dstr.c:6: error: no matching function for call to X::~X()
dstr.c:3: note: candidates are: X::~X()
--
Summary: obscure error for attempt to use destructor declarator
syntax for destructor call
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29065
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:09 --- I have installed the fix and the problem is now resolved. I have tested it on a large program and it is OK. Great, thanks for the feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug c++/29059] [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
--- Comment #2 from janis at gcc dot gnu dot org 2006-09-13 18:13 --- A regression hunt on powerpc-linux identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=116656 r116656 | jakub | 2006-09-02 06:55:09 + (Sat, 02 Sep 2006) Interestingly enough, I've been looking into runtime failures in FreePOOMA that started with the same patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug c++/29066] New: ARM C++ ABI mishap
Given the test case below, it appears that while a pointer to a member function
(PTMF) is initialized properly, the check against a NULL pointer still fails.
The same case passes properly on x86 and SH4 - it appears to be an ARM ABI
detail which causing the heartburn.
In most platforms, the member pointer (being __pfn and __delta) the __pfn uses
the LSB to determine if the PTMF is pointing to a virtual or static function,
and then uses the __delta as needed. In the ARM case, since Thumb ISA needs
that LSB, the ARM C++ ABI designates the LSB of the __delta to make that
designation (and the __delta is also twice the actual adjustment needed).
Debugging the testcase shows the __pfn as 0, and the __delta as 1, which tells
me that it's offset 0 into the vtable to call the proper member function.
Alas, the check against NULL seems to show that the logic to determine NULL
isn't checking both the __pfn and the LSB of the __delta (NULL is __pfn=0 and
LSB of __delta is 0).
Am I missing something, or is this a bug (I did a search on ARM,C++,ABI and
didn't turn up anything)? Thanks in advance for any ideas/feedback.
Here is the testcase:
#include iostream
using namespace std;
class X {
public:
virtual void a(void)=0;
virtual void b(void)=0;
X(void);
virtual ~X(void);
protected:
private:
/* none */
};
X::X(void) {
;
}
X::~X(void) {
;
}
class Z : public X {
public:
void a(void);
void b(void);
Z(void);
~Z(void);
protected:
private:
};
Z::Z(void) {
;
}
Z::~Z(void) {
;
}
void Z::a(void) {
cout Doing Z::a endl;
}
void Z::b(void) {
cout Doing Z::b endl;
}
static int doit = 1;
static int donot = 0;
void f(X *obj) {
void (X::*xp)(void) = 0;
if (doit) {
xp = X::a;
} else if (donot) {
xp = X::b;
}
if(xp!=0) {
(obj-*xp)();
} else {
cout Failed! XP is still Zero endl;
}
}
int main(int argc, char* argv[]) {
Z myobj;
f(myobj);
return 0;
}
--
Summary: ARM C++ ABI mishap
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amallory at qnx dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug c++/29066] ARM C++ ABI mishap
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 18:25 --- Is this really the arm eabi C++ ABI and not really the arm C++ ABI? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug ada/21952] [4.1/4.2 regression] Annoying attribute directive ignored warnings
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:27 --- Subject: Bug 21952 Author: ebotcazou Date: Wed Sep 13 18:27:24 2006 New Revision: 116926 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116926 Log: PR ada/21952 * gigi.h (gnat_internal_attribute_table): Declare. * misc.c (LANG_HOOKS_ATTRIBUTE_TABLE): Define to above. * utils.c (gnat_internal_attribute_table): New global variable. (builtin_function): Always call decl_attributes on the builtin. (handle_const_attribute): New static function. (handle_nothrow_attribute): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gigi.h trunk/gcc/ada/misc.c trunk/gcc/ada/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug ada/21952] [4.1/4.2 regression] Annoying attribute directive ignored warnings
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:27 --- Subject: Bug 21952 Author: ebotcazou Date: Wed Sep 13 18:27:46 2006 New Revision: 116927 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116927 Log: PR ada/21952 * gigi.h (gnat_internal_attribute_table): Declare. * misc.c (LANG_HOOKS_ATTRIBUTE_TABLE): Define to above. * utils.c (gnat_internal_attribute_table): New global variable. (builtin_function): Always call decl_attributes on the builtin. (handle_const_attribute): New static function. (handle_nothrow_attribute): Likewise. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/gigi.h branches/gcc-4_1-branch/gcc/ada/misc.c branches/gcc-4_1-branch/gcc/ada/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug ada/21952] [4.1/4.2 regression] Annoying attribute directive ignored warnings
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:29 --- Fixed in upcoming 4.1.2 release. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00512.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug c++/29065] obscure error for attempt to use destructor declarator syntax for destructor call
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 18:29 --- Actually that is incorrect and this code is really valid by DR 272. This is a dup of bug 12333 which is about rejecting this code. *** This bug has been marked as a duplicate of 12333 *** -- 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=29065
[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-13 18:29 --- *** Bug 29065 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333
[Bug c++/29066] ARM C++ ABI mishap
--- Comment #2 from amallory at qnx dot com 2006-09-13 18:30 --- (In reply to comment #1) Is this really the arm eabi C++ ABI and not really the arm C++ ABI? ARM eabi is an alias for the ABI for the ARM Architecture. Do you have anything on point to help clairify the issue? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug c++/29059] [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 18:34 --- (In reply to comment #2) A regression hunt on powerpc-linux identified the following patch: This is what I was expecting actually, I might look at this later, we might just need a fold (read from constant string) so we can fold [0] correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug c++/29033] %s substituted with left/right can't be properly translated
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29033
[Bug ada/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:40 --- Subject: Bug 28591 Author: ebotcazou Date: Wed Sep 13 18:40:26 2006 New Revision: 116928 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116928 Log: PR ada/28591 * decl.c (components_to_record): Defer emitting debug info for the record type associated with the variant until after we are sure to actually use it. Added: trunk/gcc/testsuite/gnat.dg/specs/unchecked_union.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
[Bug target/29030] gcc.dg/array-9.c produces internal compiler error on Darwin at -m64
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2006-09-13 18:41 --- Okay. I'll run a complete make check tonight to verify that the patch introduces no regressions in at least the c, c++ and fortran language build. Assuming no regressions, do you want to submit the patch or should I (assuming Geoff has no objections to it)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
[Bug ada/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:42 --- Fixed on mainline. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00514.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:48 --- Subject: Bug 29025 Author: ebotcazou Date: Wed Sep 13 18:48:21 2006 New Revision: 116929 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116929 Log: PR ada/29025 * trans.c (gnat_gimplify_expr) ADDR_EXPR: When taking the address of a SAVE_EXPR, just make the operand addressable/not-readonly and let the common gimplifier code make and propagate a temporary copy. (call_to_gnu): Clarify the use of SAVE_EXPR for not addressable out/in-out actuals and defer setting the addressable/readonly bits to the gimplifier. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:48 --- Subject: Bug 29025 Author: ebotcazou Date: Wed Sep 13 18:48:46 2006 New Revision: 116930 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116930 Log: PR ada/29025 * trans.c (gnat_gimplify_expr) ADDR_EXPR: When taking the address of a SAVE_EXPR, just make the operand addressable/not-readonly and let the common gimplifier code make and propagate a temporary copy. (call_to_gnu): Clarify the use of SAVE_EXPR for not addressable out/in-out actuals and defer setting the addressable/readonly bits to the gimplifier. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:50 --- Fixed in upcoming 4.1.2 release. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00515.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug target/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]
--- Comment #5 from pbrook at gcc dot gnu dot org 2006-09-13 19:00 --- This is looking like a latent reload bug. I don't see anything in r105121 that could cause this bug. I can reproduce it on non-linux and non-eabi arm targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug fortran/29067] New: Internal Error: gfc_resolve_expr(): Bad expression type
gfortran fails on the attached subroutine.
gfortran -v -save-temps -c ircmva.f
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
/usr/lib/gcc/i486-linux-gnu/4.1.2/f951 ircmva.f -ffixed-form -quiet -dumpbase
ircmva.f -mtune=i686 -auxbase ircmva -version -o ircmva.s
GNU F95 version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20060901 (prerelease) (Debian
4.1.1-13).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129579
In file ircmva.f:91
END
1
Internal Error at (1):
gfc_resolve_expr(): Bad expression type
Source code :
SUBROUTINE IRCMVA ( NUMCMP, NCMPVE, NCMPRF,
NVALEC, NBPG, NBSP, NOLOPG,
ADSV, ADSD, ADSL,
TYMAST, MODNUM, NUANOM,
VAL, PROFAS, IDEB, IFIN )
IMPLICIT NONE
INTEGER NTYMAX
PARAMETER (NTYMAX = 48)
INTEGER NCMPVE, NCMPRF, NVALEC, NBPG, NBSP
INTEGER NUMCMP(NCMPRF)
INTEGER ADSV, ADSD, ADSL
INTEGER TYMAST
INTEGER MODNUM(NTYMAX), NUANOM(NTYMAX,*)
INTEGER PROFAS(*)
INTEGER IDEB, IFIN
REAL*8 VAL(NCMPVE,NBSP,NBPG,NVALEC)
CHARACTER*32 NOLOPG
REAL*8 ZR
LOGICAL ZL
COMMON /RVARJE/ZR(1)
COMMON /LVARJE/ZL(1)
CHARACTER*6 NOMPRO
PARAMETER ( NOMPRO = 'IRCMVA' )
CHARACTER*32 EDELGA
PARAMETER ( EDELGA='ELNO' )
INTEGER IAUX, JAUX, KAUX
INTEGER ADSVXX
INTEGER INO, IMA, NRCMP, NRCMPR, NRPG, NRSP
INTEGER IFM, NIVINF
LOGICAL LOGAUX
CALL INFNIV ( IFM, NIVINF )
IF ( NIVINF.GT.1 ) THEN
CALL UTMESS ( 'I', NOMPRO,
'CREATION DES TABLEAUX DE VALEURS A ECRIRE AVEC :')
WRITE (IFM,13001) NVALEC, NCMPVE, NBPG, NBSP
ENDIF
13001 FORMAT(' NVALEC =',I8,', NCMPVE =',I8,
', NBPG =',I8,', NBSP =',I8,/)
IF ( TYMAST.EQ.0 ) THEN
DO 21 , NRCMP = 1 , NCMPVE
ADSVXX = ADSV-1+NUMCMP(NRCMP)-NCMPRF
JAUX = 0
DO 211 , IAUX = IDEB, IFIN
INO = PROFAS(IAUX)
JAUX = JAUX + 1
KAUX = INO*NCMPRF
VAL(NRCMP,1,1,JAUX) = ZR(ADSVXX+KAUX)
211 CONTINUE
21 CONTINUE
ELSE
LOGAUX = .FALSE.
IF ( NOLOPG(9:16).EQ.EDELGA(9:16) ) THEN
IF ( MODNUM(TYMAST).EQ.1 ) THEN
LOGAUX = .TRUE.
ENDIF
ENDIF
IF ( LOGAUX ) THEN
IF ( NBSP.GT.1 ) THEN
WRITE (IFM,13001) NVALEC, NCMPVE, NBPG, NBSP
CALL UTMESS ( 'F', NOMPRO,
'RENUMEROTATION IMPOSSIBLE AVEC PLUS D''UN SOUS-POINT')
ENDIF
ENDIF
DO 22 , NRCMP = 1 , NCMPVE
NRCMPR = NUMCMP(NRCMP)
JAUX = 0
IF ( LOGAUX ) THEN
NRSP = 1
DO 221 , IAUX = IDEB, IFIN
IMA = PROFAS(IAUX)
JAUX = JAUX + 1
DO 2211 , NRPG = 1 , NBPG
CALL CESEXI ('C',ADSD,ADSL,IMA,NRPG,NRSP,NRCMPR,KAUX)
VAL(NRCMP,NRSP,NUANOM(TYMAST,NRPG),JAUX)=ZR(ADSV-1+KAUX)
2211 CONTINUE
221 CONTINUE
ELSE
DO 222 , IAUX = IDEB, IFIN
IMA = PROFAS(IAUX)
JAUX = JAUX + 1
DO 2221 , NRPG = 1 , NBPG
DO , NRSP = 1 , NBSP
CALL CESEXI ('C',ADSD,ADSL,IMA,NRPG,NRSP,NRCMPR,KAUX)
VAL(NRCMP,NRSP,NRPG,JAUX) = ZR(ADSV-1+KAUX)
CONTINUE
2221 CONTINUE
222 CONTINUE
ENDIF
22 CONTINUE
ENDIF
END
--
Summary: Internal Error: gfc_resolve_expr(): Bad expression type
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mathieu dot courtois at free dot fr
GCC host triplet: debian testing
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug fortran/29060] spread causes ICE in gfc_trans_array_constructor
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 20:11 --- Yes, it appears to be related to spread. If you comment out the spread() in the subroutine the compiles. Additionally, if you change x%position(:,1:2) to x%position(1:3,1:2), then the code compiles. So, it looks like gfortran isn't interpreting the index ranges from spread correctly if the lefthand side doesn't have explicit ranges of indicies. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 20:11:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29060
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 20:17 --- This compiles with gfortran 4.2, so you may want to update to a newer compiler. Does this file contain any TAB characters? -- 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=29067
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #2 from mathieu dot courtois at free dot fr 2006-09-13 20:18 --- Created an attachment (id=12252) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12252action=view) source code add source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug boehm-gc/29068] New: Bootstrap fails building in libjava directory on sparc-sun-solaris2.10
On mainline I'm getting a bootstrap failure building in the libjava directory on sparc-sun-solaris2.10: Undefined first referenced symbol in file GC_get_thread_stack_base./.libs/libgcj.so ld: fatal: Symbol referencing errors. No output written to .libs/jv-convert collect2: ld returned 1 exit status make[3]: *** [jv-convert] Error 1 I most recently was able to get a successful bootstrap on Aug 18th: http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg00798.html It was probably triggered by this change because that's where GC_get_thread_stack_base was introduced: 2006-08-21 Bryce McKinlay [EMAIL PROTECTED] PR libgcj/13212: * configure.ac: Check for pthread_getattr_np(). Remove GC_PTHREAD_SYM_VERSION detection. * include/gc.h (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New declarations. * pthread_support.c (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New functions. (GC_delete_thread): Don't try to free the first_thread. * misc.c (GC_init_inner): Use GC_get_thread_stack_base() if possible. (pthread_create_, constr): Removed. (pthread_create): Don't rename. * include/gc_ext_config.h.in: Rebuilt. * include/gc_pthread_redirects.h (pthread_create): Define unconditionally. * include/gc_config.h.in: Rebuilt. * configure: Rebuilt. -- Summary: Bootstrap fails building in libjava directory on sparc- sun-solaris2.10 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29068
[Bug boehm-gc/29068] Bootstrap fails building in libjava directory on sparc-sun-solaris2.10
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-09-13 20:28 --- Same on SPARC/Solaris 8 and 9. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 20:28:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29068
[Bug target/28821] Unable to build Python
--- Comment #1 from sje at cup dot hp dot com 2006-09-13 20:32 --- I had someone try to use 64 bit PA GCC code with HP Java and they ran into two unsats, __cxa_finalize and _Jv_RegisterClasses. In GCC 4.0.3 there is a weak definition of __cxa_finalize in libstdc++.sl, but in GCC 4.1.1 there is just an undef. GCC 4.2 also seems to just have an undef. David, does this sound familiar to you at all? -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com, ||danglin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 20:32:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28821
[Bug boehm-gc/29068] [4.2 Regression] Bootstrap fails building in libjava directory on sparc-sun-solaris2.10
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-13 20:36 --- This is why I mentioned Java people should not be committing new features this late. See also: http://gcc.gnu.org/ml/java/2006-09/msg00021.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|blocker GCC build triplet|sparc-sun-solaris2.*|sparc-sun-solaris2.10 GCC host triplet|sparc-sun-solaris2.*|sparc-sun-solaris2.10 GCC target triplet|sparc-sun-solaris2.*|sparc-sun-solaris2.10 Keywords||build Summary|[4.2 regression] Bootstrap |[4.2 Regression] Bootstrap |fails building libjava on |fails building in libjava |SPARC/Solaris |directory on sparc-sun- ||solaris2.10 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29068
[Bug target/28821] Unable to build Python
--- Comment #2 from sje at cup dot hp dot com 2006-09-13 20:37 --- Well, I guess I should have read comment 1 before adding comment 2, sorry for the extra mail David. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28821
[Bug boehm-gc/29068] [4.2 Regression] Bootstrap fails building libjava on SPARC/Solaris
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-13 20:40 --- Please, Andrew, stop overwriting my changes. Thanks. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|sparc-sun-solaris2.10 |sparc-sun-solaris2.* GCC host triplet|sparc-sun-solaris2.10 |sparc-sun-solaris2.* GCC target triplet|sparc-sun-solaris2.10 |sparc-sun-solaris2.* Summary|[4.2 Regression] Bootstrap |[4.2 Regression] Bootstrap |fails building in libjava |fails building libjava on |directory on sparc-sun- |SPARC/Solaris |solaris2.10 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29068
[Bug other/29069] New: Machine parsable error and warning display
When gcc, g++, etc ouputs errors they are in a form designed to help people read the command line. With many people wanting to use IDEs, such as Eclips CDT, trying to write code to parse this output is not easy. For this reason to have a mode where the compiler and other gcc tools can output results that are easy to parse would be of help. What format this should take I am not sure, maybe: [tool name]:[file path]:[line number]:[error type]:[error message] -- Summary: Machine parsable error and warning display Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andrejohn dot mas at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29069
[Bug boehm-gc/29068] [4.2 Regression] Bootstrap fails building libjava on SPARC/Solaris
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-13 20:45 --- (In reply to comment #3) Please, Andrew, stop overwriting my changes. Thanks. If the bugzilla would allow me to merge the changes, it would be better but it does not. Also I loaded the page right before you changed stuff and I had changed the summary to include [4.2 Regression] but right after you committed your changes, I committed mine and just pressed continue committing since bugzilla does not allow me to pick and chose whos changes gets included. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29068
[Bug boehm-gc/29068] [4.2 Regression] Bootstrap fails building libjava on SPARC/Solaris
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 20:48 --- If the bugzilla would allow me to merge the changes, it would be better but it does not. Also I loaded the page right before you changed stuff and I had changed the summary to include [4.2 Regression] but right after you committed your changes, I committed mine and just pressed continue committing since bugzilla does not allow me to pick and chose whos changes gets included. Simply do not press continue, the warning displayed by Bugzilla is pretty clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29068
