[Bug libfortran/25577] gfortran routine mvbits returns wrong answer.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-02-04 08:34 --- (In reply to comment #4) > Opps, I think that the change suggested in Comment #1 actually does fix the > problem on the LINUX version. Dale, can you submit this one-line patch on the [EMAIL PROTECTED] mailing-list for approval? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||patch Last reconfirmed|2006-01-11 14:26:36 |2006-02-04 08:34:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25577
[Bug libfortran/25340] Runtime error: "Read past ENDFILE record"
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-02-04 08:36 --- Well, I'm closing this one as invalid. Steve, if you disagree, feel free to reopen it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25340
[Bug ada/26096] Ada bootstrap fail in g-alleve.adb
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-02-04 08:38 --- Confirmed with a cross. -- 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-02-04 08:38:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26096
[Bug ada/26096] Ada bootstrap fail in g-alleve.adb
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-02-04 08:44 --- > Is this supposed to work this way? No, of course, the tree is broken from the very beginning. The problem shows up only on s390x because it features a low BIGGEST_ALIGNMENT for a 64-bit target. Could you try the following fix? Index: decl.c === --- decl.c (revision 110584) +++ decl.c (working copy) @@ -1058,7 +1058,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit gnu_new_var = create_var_decl (create_concat_name (gnat_entity, "ALIGN"), -NULL_TREE, gnu_new_type, gnu_expr, false, +NULL_TREE, gnu_new_type, NULL_TREE, false, false, false, false, NULL, gnat_entity); if (gnu_expr) -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-04 08:38:33 |2006-02-04 08:44:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26096
[Bug target/25372] Aligned args on IA64
--- Comment #5 from olivier dot aumage at labri dot fr 2006-02-04 10:17 --- (In reply to comment #2) > It looks like we have an interaction between the alignment attribute and the > IA64 calling conventions. In this example GCC is treating my_t type as an > aligned pointer and not as a pointer to aligned data. Is that what you > intend? Well, I did not really intend anything since I first stumbled on this "behaviour" with a buggy code which _unintentionnaly_ presented this pattern. Since this behaviour was a bit surprising, I derived a minimal example code from my buggy code and reported it here, as it might be a sign of internal GCC bug. I'm only stating that this behaviour is surprising. It is not necessarily wrong (if it is not triggered by an internal bug, of course). By reading the various comments posted here, I have now the feeling that it might be something similar to "*(char *)NULL=1;", that is, compiled correctly, but potentially not "valid" in a given execution environment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25372
[Bug c++/25979] [4.0 Regression] incorrect codegen for conditional [SVO issue]
--- Comment #9 from steven at gcc dot gnu dot org 2006-02-04 10:34 --- No longer a 4.1/4.2 regression. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0 Regression] incorrect |incorrect codegen for |codegen for conditional [SVO |conditional [SVO issue] |issue] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25979
[Bug c++/26084] [gomp-branch] ICE (segfault) on C++ OpenMP coce
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-02-04 11:31
---
Reduced testcase:
template struct arr {
long s;
T *d;
arr(long sz) : s(sz), d (s>0 ? new T[s] : 0) {}
~arr() { delete[] d; }
T &operator[] (int n) {return d[n];}
};
void map2alm (const double *map) {
#pragma omp parallel
{
arr Ylm(1), alm_tmp(1);
Ylm[1] +=2;
}
}
~/tmp>g++ -I ~/data/planck/LevelS/linux_gcc/include bug.cc -fopenmp -c -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/gompcc/configure --quiet --prefix=/scratch/ugccgomp
--enable-languages=c++,fortran --with-gmp=/usr/local/appl/gmp-4.1.4
--enable-checking=release
Thread model: posix
gcc version 4.2.0-gomp-20050608-branch 20060202 (experimental) (merged
20060202)
/scratch/ugccgomp/libexec/gcc/i686-pc-linux-gnu/4.2.0-gomp-20050608-branch/cc1plus
-quiet -v -I /afs/mpa/home/martin/data/planck/LevelS/linux_gcc/include
-D_GNU_SOURCE -D_REENTRANT bug.cc -quiet -dumpbase bug.cc -mtune=generic
-auxbase bug -version -fopenmp -o /tmp/ccYgPhms.s
ignoring nonexistent directory
"/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.2.0-gomp-20050608-branch/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/afs/mpa/home/martin/data/planck/LevelS/linux_gcc/include
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.2.0-gomp-20050608-branch/../../../../include/c++/4.2.0-gomp-20050608-branch
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.2.0-gomp-20050608-branch/../../../../include/c++/4.2.0-gomp-20050608-branch/i686-pc-linux-gnu
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.2.0-gomp-20050608-branch/../../../../include/c++/4.2.0-gomp-20050608-branch/backward
/usr/local/include
/scratch/ugccgomp/include
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.2.0-gomp-20050608-branch/include
/usr/include
End of search list.
GNU C++ version 4.2.0-gomp-20050608-branch 20060202 (experimental) (merged
20060202) (i686-pc-linux-gnu)
compiled by GNU C version 4.2.0-gomp-20050608-branch 20060202
(experimental) (merged 20060202).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c854429a5b3be01718b61b454f3d31d6
bug.cc: In function 'void _Z7map2almPKd.omp_fn.0(void*)':
bug.cc:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug libstdc++/22634] partial_sum is too constrained
--- Comment #17 from squell at alumina dot nl 2006-02-04 12:45 --- Out of curiosity, I was checking the LWG website; I couldn't find these issues (but then, I don't have inside access). I'm more than willing write a DR for both points mentioned, but I'd hate to duplicate any effort. Comments? -- squell at alumina dot nl changed: What|Removed |Added CC||squell at alumina dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug rtl-optimization/19580] [3.4/4.0/4.1/4.2 Regression] missed load/store motion
--- Comment #25 from rguenth at gcc dot gnu dot org 2006-02-04 13:52 --- On the mainline now even g() regresses, probably because of the reassoc pass rewrite. Of course on the mainline this is also "fixed" by --param salias-max-array-elements=6, which makes load/store motion work on the tree level. It looks like expand only with :; r[0] = r[0] + r[1]; r[1] = r[1] + r[2]; r[2] = r[2] + r[3]; r[3] = r[3] + r[4]; r[4] = r[4] + r[5]; r[5] = r[5] + r[0]; ivtmp.63 = ivtmp.63 + 1; if (ivtmp.63 != (unsigned int) n.68) goto ; else goto ; produces RTL that we can optimize to .L13: addl%edi, %esi incl%ebp addl%ebx, %edi addl%ecx, %ebx addl%edx, %ecx addl%eax, %edx addl%esi, %eax cmpl(%esp), %ebp jne .L13 but not for (mainline) :; D.1544 = r[1] + r[0]; r[0] = D.1544; r[1] = r[2] + r[1]; r[2] = r[3] + r[2]; r[3] = r[4] + r[3]; r[4] = r[5] + r[4]; r[5] = D.1544 + r[5]; n.61 = n.61 - 1; if (n.61 != 0) goto ; else goto ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-02-04 17:11 --- If I compile the original testcase with current mainline (revision 110561), the binary dies on execution with *** glibc detected *** double free or corruption (out): 0xbfc9d020 *** Aborted If I remove the line print*,x(5) the program runs and outputs 0.00 0.00 0.00 0.00 0.00 This trivial patch fixes the latter problem: - Index: trans-expr.c === --- trans-expr.c(revision 110590) +++ trans-expr.c(working copy) @@ -2912,6 +2912,9 @@ gfc_trans_arrayfunc_assign (gfc_expr * e if (gfc_ref_needs_temporary_p (expr1->ref)) return NULL; + if (expr2->symtree->n.sym->attr.pointer) +return NULL; + /* Check that no LHS component references appear during an array reference. This is needed because we do not have the means to span any arbitrary stride with an array descriptor. This check I'll try to see if I can fix the other problem too. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug libgcj/26097] New: [4.2 regression]: Libjava failed to build
With revision 110590, I got gnu/CORBA/NamingService/NamingServiceTransient.java: In method 'gnu.CORBA.NamingService.NamingServiceTransient.main(java.lang.String[])': gnu/CORBA/NamingService/NamingServiceTransient.java:100: error: stack underflow gnu/CORBA/NamingService/NamingServiceTransient.java:101: error: stack underflow gnu/CORBA/NamingService/NamingServiceTransient.java:105: error: stack underflow - dup* operation gnu/CORBA/NamingService/NamingServiceTransient.java:105: error: expected type 'gnu.CORBA.OrbFunctional' but stack contains 'null' gnu/CORBA/NamingService/NamingServiceTransient.java:105: error: stack underflow gnu/CORBA/NamingService/NamingServiceTransient.java:107: error: stack underflow -- Summary: [4.2 regression]: Libjava failed to build Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org 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=26097
[Bug libstdc++/26094] Segmentation fault in Linux 7.1 GCC 3.1 Kernel 2.4.9-45lxset34smp
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 18:49 --- "Linux 7.1" that is a new one. Also 3.1 came out almost 4 years ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26094
[Bug ada/26096] [4.2 Regression] Ada bootstrap fails in g-alleve.adb
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-02-04 19:11 --- (In reply to comment #2) > Could you try the following fix? Yes, this fixes the problem. Bootstrap and regression test passes on s390x-ibm-linux (and s390-ibm-linux) with this fix. The following test case failures remain: s390-ibm-linux: FAIL: c32001e FAIL: c64105b FAIL: c95086b FAIL: ce3107b FAIL: ce3810b s390x-ibm-linux: FAIL: c32001e FAIL: c64105b FAIL: c95086b FAIL: cdd2a01 FAIL: cdd2a02 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26096
[Bug middle-end/19543] fortran LOGICAL*8 not consistently distinguished from 32 bit integers
--- Comment #10 from tobi at gcc dot gnu dot org 2006-02-04 19:27 --- I'm changing the summary, and pushing this to component middle-end. See comments #3 and #5 for an analysis of what's going wrong. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |middle-end Summary|formated output for |fortran LOGICAL*8 not |logical(8) variables fails |consistently distinguished ||from 32 bit integers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19543
[Bug libgcj/26097] [4.2 regression]: Libjava failed to build
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 19:35 --- One of the following patches caused: +2006-02-03 Jason Merrill <[EMAIL PROTECTED]> + + PR c++/25979 + * gimplify.c (gimplify_modify_expr_rhs): Disable *& optimization for now. + + PR middle-end/25977 + * gimplify.c (gimplify_modify_expr_rhs): It's not always safe to do RVO + on the return slot if it's an NRV. + +2006-02-03 Zdenek Dvorak <[EMAIL PROTECTED]> + + * tree-ssa-loop-ivopts.c (enum use_type): Remove USE_OUTER. + (dump_use, add_derived_ivs_candidates, determine_use_iv_cost, + rewrite_use): Do not handle USE_OUTER. + (find_interesting_uses_outer_or_nonlin, find_interesting_uses_outer, + add_iv_outer_candidates, may_replace_final_value, + determine_use_iv_cost_outer, rewrite_use_outer): Removed. + (find_interesting_uses_op): Functionality of + find_interesting_uses_outer_or_nonlin moved here. + (find_interesting_uses_outside): Use find_interesting_uses_op. --- trunk.prev/gcc/java/ChangeLog 2006-02-03 03:01:49.0 -0500 +++ trunk/gcc/java/ChangeLog2006-02-04 00:03:32.0 -0500 @@ -1,3 +1,24 @@ +2006-02-04 Andreas Tobler <[EMAIL PROTECTED]> + + * expr.c (java_stack_swap): Revert gcc_assert patch. + +2006-02-03 Ben Elliston <[EMAIL PROTECTED]> + + * java-gimplify.c: Use gcc_assert and gcc_unreachable throughout. + * typeck.c: Likewise. + * verify-impl.c: Likewise. + * class.c: Likewise. + * decl.c: Likewise. + * jcf-parse.c: Likewise. + * constants.c: Likewise. + * check-init.c: Likewise. + * jcf-write.c: Likewise. + * verify-glue.c: Likewise. + * mangle.c: Likewise. + * expr.c: Likewise. + * lang.c: Likewise. + * boehm.c: Likewise. --- trunk.prev/libjava/ChangeLog2006-02-03 03:18:35.0 -0500 +++ trunk/libjava/ChangeLog 2006-02-04 00:51:03.0 -0500 @@ -1,3 +1,22 @@ +2006-02-03 Thomas Fitzsimmons <[EMAIL PROTECTED]> + + * Makefile.am (src.zip): Update src.zip file search to look in + classpath directory. + * Makefile.in: Regenerate. + +2006-02-03 Robert Schuster <[EMAIL PROTECTED]> + + * link.cc: + (_Jv_Linker::create_error_method): Added missing (void *) cast. + +2006-02-03 Robert Schuster <[EMAIL PROTECTED]> + + * include/jvm.h: + (_Jv_Linker::create_error_method): New method declaration. + * link.cc: + (_Jv_Linker::create_error_method): New method. + (_Jv_Linker::link_symbol_table): Use new method above. + -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-04 19:36 --- I am going to put this into the java component as this is reproducible on i686, x86_64 and powerpc64. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Component|libgcj |java 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=26097
[Bug ada/26096] [4.2 Regression] Ada bootstrap fails in g-alleve.adb
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-02-04 19:42 --- > Yes, this fixes the problem. Bootstrap and regression test passes > on s390x-ibm-linux (and s390-ibm-linux) with this fix. Great. I've successfully tested it on x86_64-suse-linux. > The following test case failures remain: > s390-ibm-linux: > FAIL: c32001e > FAIL: c64105b > FAIL: c95086b > FAIL: ce3107b > FAIL: ce3810b > > s390x-ibm-linux: > FAIL: c32001e > FAIL: c64105b > FAIL: c95086b > FAIL: cdd2a01 > FAIL: cdd2a02 Thanks. ce3107b is new to me but all the others are fully understood. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26096
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-04 19:47 --- Quick question, what options did you use to bootstrap (Please say --disable-checking)? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code, ||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug rtl-optimization/26098] New: ICE in multiplication of 16-byte longlong vector on x86_64
This code causes ICE on gcc 4.0.3 on x86_64.
typedef long long vec __attribute__ ((vector_size(16)));
vec vecsqr(vec a) { return a*a; }
Commandline:
gcc -O1 -S -o - tmp.c
Resulting output:
.file "tmp.c"
tmp.c: In function 'vecsqr':
tmp.c:2: error: unrecognizable insn:
(insn 13 12 15 0 (set (reg:DI 58 [ D.1470 ])
(vec_select:DI (reg/v:V2DI 61 [ a ])
(parallel [
(const_int 1 [0x1])
]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:V2DI 61 [ a ])
(nil)))
tmp.c:2: internal compiler error: in extract_insn, at recog.c:2020
It goes ICE on when -O option >= 1. -O0 does not trigger it.
Option -mno-sse also disables the ICE, but then it gives "error: SSE register
return with SSE disabled". -mno-sse2 doesn't disable it.
Unsigned/signed type has no effect to result. Without
__attribute__((vector_size)), it does not ICE.
GCC version (gcc -v):
Using built-in specs.
Target: x86_64-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-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-mpfr
--disable-werror --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
--
Summary: ICE in multiplication of 16-byte longlong vector on
x86_64
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot fi
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=26098
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-04 20:01 --- Reproduces with --disable-checking but not without on x86_64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #5 from hjl at lucon dot org 2006-02-04 20:05 --- Yes, I used --disable-checking. I saw it on i686, x86-64 and ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug target/26098] [4.0 Regression] ICE in multiplication of 16-byte longlong vector on x86_64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 20:11 --- Confirmed, just a 4.0 regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.3 4.0.2 Known to work||3.4.6 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-02-04 20:11:01 date|| Summary|ICE in multiplication of 16-|[4.0 Regression] ICE in |byte longlong vector on |multiplication of 16-byte |x86_64 |longlong vector on x86_64 Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26098
[Bug ada/26096] [4.2 Regression] Ada bootstrap fails in g-alleve.adb
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-04 20:16 --- (In reply to comment #4) > Thanks. ce3107b is new to me but all the others are fully understood. It looks like ce3107b is one of those spurious failures I'm getting from time to time -- I've never quite understood what's going on here, but it looks like a test suite issue: CE3107A PASSED . PASS: ce3107a splitting /home/uweigand/fsf/gcc-head-build/gcc/testsuite/ada/acats/tests/ce/ce3107b.ada into: ce3107b.adb BUILD FAIL: ce3107b splitting /home/uweigand/fsf/gcc-head-build/gcc/testsuite/ada/acats/tests/ce/ce3108a.ada into: ce3108a.adb BUILD ce3108a.adb gnatmake --GCC="/home/uweigand/fsf/gcc-head-build/gcc/xgcc -B/home/uweigand/fsf/gcc-head-build/gcc/" -gnatws -O2 -I/home/uweigand/fsf/gcc-head-build/gcc/testsuite/ada/acats/support ce3108a.adb -largs --GCC="/home/uweigand/fsf/gcc-head-build/gcc/xgcc -B/home/uweigand/fsf/gcc-head-build/gcc/" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26096
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-04 20:21 --- CCing Ben as I think his abort -> gcc_assert patch caused this. I suspect one of the conversion caused a side effect to be removed when doing --disable-checking (which disables also the asserts). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug ada/26096] [4.2 Regression] Ada bootstrap fails in g-alleve.adb
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-02-04 20:27 --- > It looks like ce3107b is one of those spurious failures I'm getting from > time to time -- I've never quite understood what's going on here, but it > looks like a test suite issue: Indeed, I run into that from time to time too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26096
[Bug ada/26096] [4.2 Regression] Ada bootstrap fails in g-alleve.adb
--- Comment #7 from laurent at guerby dot net 2006-02-04 20:34 --- I dont't remember having seen this one (ce3107b) fail. I see some random test failing with run not finding the exe after gnatmake exits successfully, I've always assumed this was a timing problem within the Linux kernel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26096
[Bug libstdc++/26094] Segmentation fault in Linux 7.1 GCC 3.1 Kernel 2.4.9-45lxset34smp
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-04 20:51 --- Please try with Linux and gcc that are still supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26094
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-02-04 20:52 --- Created an attachment (id=10777) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10777&action=view) Patch to fix the bug. We also get into trouble if we try to pass the result of a pointer-to-array returning funtion as an argument to another procedure (e.g. call a_suborutine (x(5)) ) The problem, both for this case and print *, x(5) is that we try to free the temporary used to hold the result. This we mustn't do, since the temporary will be just a shallow copy of the resulting array. The attached patch fixes these problems, but is not yet well tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug libstdc++/22634] partial_sum is too constrained
--- Comment #18 from pcarlini at suse dot de 2006-02-04 20:53 --- (In reply to comment #17) > Out of curiosity, I was checking the LWG website; I couldn't find these issues > (but then, I don't have inside access). I'm more than willing write a DR for > both points mentioned, but I'd hate to duplicate any effort. Comments? Hi. As far as I know, nobody is actively working on the text of an actual DR and your help would be really appreciated. Thanks in advance! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug rtl-optimization/26087] [4.2 Regression] ICE in df_find_use
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-02-04 21:30 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00333.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg00333.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26087
[Bug rtl-optimization/19580] [3.4/4.0/4.1/4.2 Regression] missed load/store motion
--- Comment #26 from dberlin at gcc dot gnu dot org 2006-02-04 21:30 --- Buzz, thanks for playing. The reassoc rewrite has nothing to do with this. It won't actually touch those operations because they are memory loads and stores. If you look at the reassoc dumps, the most it will do here is Transforming D.1551_26 + D.1542_27 into D.1542_27 + D.1551_26; (IE just swap the operands so they are in sorted order) This has no effect on anything, it used to be done automatically, and is now done manually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #7 from tromey at gcc dot gnu dot org 2006-02-04 21:49 --- At least the change in push_type is wrong. Perhaps others too, I'm looking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #8 from tromey at gcc dot gnu dot org 2006-02-04 21:53 --- Created an attachment (id=10778) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10778&action=view) proposed patch Please try this patch. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug fortran/25046] MASK and ARRAY arguments of PRODUCT must have conformant shapes
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-02-04 22:04 --- This is now caught on trunk, since revision 110453 (I had overlooked this PR when fixing this). Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25046
[Bug java/26097] [4.2 regression]: Libjava failed to build
-- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-04 22:05:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug fortran/25046] MASK and ARRAY arguments of PRODUCT must have conformant shapes
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-04 22:06 --- Just for the record the error message is: In file t.f90:5 write(6,*) PRODUCT(A,B) 1 Error: Incompatible ranks in arguments 'array' and 'mask' for intrinsic product at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25046
[Bug debug/24444] [4.1/4.2 regression] invalid register in debug info
--- Comment #12 from aoliva at gcc dot gnu dot org 2006-02-04 22:08 --- Subject: Bug 2 Author: aoliva Date: Sat Feb 4 22:08:04 2006 New Revision: 110594 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110594 Log: PR debug/2 * config/ia64/ia64.c: Include debug.h. (MAX_ARTIFICIAL_LABEL_BYTES): New. (ia64_label_after_insn, ia64_dwarf2out_def_steady_cfa): New. (IA64_CHANGE_CFA_IN_EPILOGUE): Define to 0. (process_epilogue, process_set, process_for_unwind_directive): Output unwind info only if requested. Add CFA info if requested. Add new arguments as needed. Adjust callers. * config/ia64/ia64.h (ARG_POINTER_CFA_OFFSET): Override incorrect default. (DWARF2_FRAME_INFO): Define to zero. * config/ia64/unwind-ia64.c: Remove code that compensated for the CFA offset error fixed above. * config/ia64/t-ia64 (ia64.o): Depend on debug.h. * dwarf2out.c (DWARF2_FRAME_INFO): Define default. (dwarf2out_do_frame): Require nonzero DWARF2_UNWIND_INFO for -funwind-tables and -fexceptions to enable frame info. (dwarf2out_frame_init): Define initial CFA even if DWARF2_UNWIND_INFO is disabled. Call initial_return_save if DWARF2_UNWIND_INFO is nonzero, not just defined. (dwarf2out_frame_finish): Output non-EH call frame info only if DWARF2_FRAME_INFO is nonzero. (convert_cfa_to_loc_list, compute_frame_pointer_to_cfa_displacement): Define even if unwind info is not supported. (gen_subprogram_die): Use the above unconditionally. Remove legacy alternate code. * toplev.c (compile_file): Compile in call to dwarf2out_frame_finish if DWARF2_DEBUGGING_INFO is defined. (lang_dependent_init): Ditto for dwarf2out_frame_init. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c trunk/gcc/config/ia64/ia64.h trunk/gcc/config/ia64/t-ia64 trunk/gcc/config/ia64/unwind-ia64.c trunk/gcc/dwarf2out.c trunk/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug c++/26099] New: support for type traits is not available
currently, in , code exists like:
template
struct has_trivial_destructor
: public integral_constant::value> { };
It would be nice to have compiler support to detect non-pod types that have a
trivial destructor. (this would provide support for certain optimizations)
--
Summary: support for type traits is not available
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefaan dot deroeck at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug fortran/25075] array size mismatch in DOT_PRODUCT
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-02-04 22:12 --- Subject: Bug 25075 Author: tkoenig Date: Sat Feb 4 22:11:57 2006 New Revision: 110596 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110596 Log: 2006-02-04 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25075 check.c (identical_dimen_shape): New function. (check_dot_product): Use identical_dimen_shape() to check sizes for dot_product. (gfc_check_matmul): Likewise. (gfc_check_merge): Check conformance between tsource and fsource and between tsource and mask. (gfc_check_pack): Check conformance between array and mask. 2006-02-04 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25075 intrinsic_argument_conformance_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25075
[Bug debug/24444] [4.1/4.2 regression] invalid register in debug info
--- Comment #13 from aoliva at gcc dot gnu dot org 2006-02-04 22:13 --- Subject: Bug 2 Author: aoliva Date: Sat Feb 4 22:13:20 2006 New Revision: 110597 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110597 Log: PR debug/2 * config/ia64/ia64.c: Include debug.h. (MAX_ARTIFICIAL_LABEL_BYTES): New. (ia64_label_after_insn, ia64_dwarf2out_def_steady_cfa): New. (IA64_CHANGE_CFA_IN_EPILOGUE): Define to 0. (process_epilogue, process_set, process_for_unwind_directive): Output unwind info only if requested. Add CFA info if requested. Add new arguments as needed. Adjust callers. * config/ia64/ia64.h (ARG_POINTER_CFA_OFFSET): Override incorrect default. (DWARF2_FRAME_INFO): Define to zero. * config/ia64/unwind-ia64.c: Remove code that compensated for the CFA offset error fixed above. * config/ia64/t-ia64 (ia64.o): Depend on debug.h. * dwarf2out.c (DWARF2_FRAME_INFO): Define default. (dwarf2out_do_frame): Require nonzero DWARF2_UNWIND_INFO for -funwind-tables and -fexceptions to enable frame info. (dwarf2out_frame_init): Define initial CFA even if DWARF2_UNWIND_INFO is disabled. Call initial_return_save if DWARF2_UNWIND_INFO is nonzero, not just defined. (dwarf2out_frame_finish): Output non-EH call frame info only if DWARF2_FRAME_INFO is nonzero. (convert_cfa_to_loc_list, compute_frame_pointer_to_cfa_displacement): Define even if unwind info is not supported. (gen_subprogram_die): Use the above unconditionally. Remove legacy alternate code. * toplev.c (compile_file): Compile in call to dwarf2out_frame_finish if DWARF2_DEBUGGING_INFO is defined. (lang_dependent_init): Ditto for dwarf2out_frame_init. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/ia64/ia64.c branches/gcc-4_1-branch/gcc/config/ia64/ia64.h branches/gcc-4_1-branch/gcc/config/ia64/t-ia64 branches/gcc-4_1-branch/gcc/config/ia64/unwind-ia64.c branches/gcc-4_1-branch/gcc/dwarf2out.c branches/gcc-4_1-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug c++/26099] support for type traits is not available
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 22:17 --- Wouldn't it be better to ask the standards committee to add support than asking GCC to add an extension? Also what kind of optimizations can you do with a trival destructor? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug debug/24444] [4.1/4.2 regression] invalid register in debug info
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-04 22:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #9 from andreast at gcc dot gnu dot org 2006-02-04 22:26 --- build completes with the patch from Tom. (#8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug libgcj/17978] Binary Compatibility: use _Jv_AllocBytes to allocate interface dispatch tables
--- Comment #2 from tromey at gcc dot gnu dot org 2006-02-04 22:29 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-18 01:34:51 |2006-02-04 22:29:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17978
[Bug libgcj/16902] GIJ: Garbage collection related failure with interpreter
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-04 22:29 --- I played with this a bit today and I'm not able to reproduce. Do you need special arguments to the test program? I tried with my current 4.0.x and 4.1 builds. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16902
[Bug java/25676] Use of MIN_EXPR/MAX_EXPR is wrong for java
--- Comment #1 from tromey at gcc dot gnu dot org 2006-02-04 22:36 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-06 19:17:30 |2006-02-04 22:36:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25676
[Bug c++/26099] support for type traits is not available
--- Comment #2 from stefaan dot deroeck at gmail dot com 2006-02-04 23:13 --- When I saw "tr1" in the path, I assumed this referred to the technical report of the standards committee. I recognize a technical report is not a standard, thus I am simply inquiring if there is interest in adding this feature. I see code in , function _Destroy, that allows for optimizations when this support is available. A second example, I am myself writing a container class that allows allocation+construction of chunks of variable size at a time (aiming for lower computational cost). When erasing a single element from that container, its destruction would have to be done immediately, while its memory chunk would remain allocated. Some (expensive) bookkeeping has to be done to later facilitate correct destruction and deallocation of remaining elements when the container itself is destroyed. If has_trivial_destructor would be true_type, all this bookkeeping could be omitted, and on destruction of the container just the deallocation of all the used memory would be sufficient. I am no expert on the implementation details of existing containers, but I guess similar optimizations throughout libstdc++ are possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-04 23:22 --- (In reply to comment #2) > When I saw "tr1" in the path, I assumed this referred to the technical report > of the standards committee. I recognize a technical report is not a standard, > thus I am simply inquiring if there is interest in adding this feature. Yes TR1 refers to the technical report which is really just the library part. The interest should really go to the committe than one implementation. Now GCC can add this as an extensions and that can help the discussion/decision to add it to the standard. But GCC's view of extensions have changed over the years and right now it is that extensions are bad and should be avoided. I am not saying this is not useful after your description of how to speed up some containers. Now the book keeping is not that expensive as it is just an extra bool for each slot and you can hide most of the book keeping in a secondary class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #10 from tromey at gcc dot gnu dot org 2006-02-04 23:30 --- Subject: Bug 26097 Author: tromey Date: Sat Feb 4 23:30:01 2006 New Revision: 110598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110598 Log: PR java/26097: * expr.c (push_type): Avoid side effect in gcc_assert. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug java/26097] [4.2 regression]: Libjava failed to build
--- Comment #11 from tromey at gcc dot gnu dot org 2006-02-04 23:30 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
[Bug java/25676] Use of MIN_EXPR/MAX_EXPR is wrong for java
--- Comment #2 from tromey at gcc dot gnu dot org 2006-02-04 23:34 --- Subject: Bug 25676 Author: tromey Date: Sat Feb 4 23:34:06 2006 New Revision: 110599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110599 Log: gcc/java PR java/25676: * builtins.c (max_builtin): Skip floating point 'max'. (min_builtin): Skip floating point 'min'. (check_for_builtin): Never return NULL_TREE. libjava PR java/25676: * testsuite/libjava.lang/pr25676.out: New file. * testsuite/libjava.lang/pr25676.java: New file. Added: trunk/libjava/testsuite/libjava.lang/pr25676.java trunk/libjava/testsuite/libjava.lang/pr25676.out Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/builtins.c trunk/libjava/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25676
[Bug java/25676] Use of MIN_EXPR/MAX_EXPR is wrong for java
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-04 23:35 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25676
[Bug java/25676] Use of MIN_EXPR/MAX_EXPR is wrong for java
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-04 23:36 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25676
[Bug c++/26099] support for type traits is not available
--- Comment #4 from stefaan dot deroeck at gmail dot com 2006-02-04 23:41 --- > Yes TR1 refers to the technical report which is really just the library part. For the library to provide this functionality, it has to exist in the compiler, as a whole, or by a clever combination of language constructs. Currently, it doesn't seem to me that this proposal could be implemented using gcc. If it is the desire of the gcc developers to adhere to the iso standard and no more, I don't intend to argue on that, as I currently don't have the means (free time nor adequate gcc code knowledge) to contribute code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #5 from pcarlini at suse dot de 2006-02-04 23:41 --- Really, what Stefaan is saying is trivially correct and totally sensible. The only doubt I have is which *specific* shape the compiler support must take. In fact, I find TR1, 4.9 too vague about that. Then the point would be (I think Andrew will agree): let's suppose some sort of ""reflection"" becomes part of the next C++ standard, then the whole core C++ + type_traits becomes absolutely natural and neat. I think many people would like standardization in this area, but if C++0x will not include it (a huge number of new features is already scheduled!), we have to accept ""extensions"" if we want performance and QoI in the library. This is already happening today in many areas, consider, e.g., thread safe locales, math builtins, lots of examples, really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug middle-end/25912] Problem compiling Asterisk 1.2.2 with Debian 3.1 (Sarge) gcc (3.3.5 (Debian 1:3.3.5-13))
--- Comment #3 from julius at zgod dot cjb dot net 2006-02-04 23:50 --- I just tried: env LANG=C gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i586 -fomit-frame-pointer-c -o channel.o channel.c and then make which seems to get further now, but stops again with: gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i586 -fomit-frame-pointer-c -o rtp.o rtp.c rtp.c: In function `ast_rtp_bridge': rtp.c:1741: internal compiler error: Segmentatie fout Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make: *** [rtp.o] Fout 1 which the env LANG=C gcc trick, it again seems to get further. Then I again got an error for ast_expr2.c. Same trick allowed it to go further. With channels/chan_sip.c, I got the error too, but env LANG=C gcc gave me: [EMAIL PROTECTED]:~/asterisk-1.2.2/channels$ env LANG=C gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i586 -fomit-frame-pointer -Wno-missing-prototypes -Wno-missing-declarations -DZAPATA_PRI -DCRYPTO -fPIC-c -o chan_sip.o chan_sip.c chan_sip.c: In function `get_destination': chan_sip.c:6497: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . I hope am I doing the correct thing with your suggestion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25912
[Bug classpath/25948] Unaccountable ArrayIndexOutOfBoundsException when using GZIPInputStream
--- Comment #2 from tromey at gcc dot gnu dot org 2006-02-04 23:51 --- *** This bug has been marked as a duplicate of 24461 *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25948
[Bug libgcj/24461] array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-04 23:51 --- *** Bug 25948 has been marked as a duplicate of this bug. *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||GCC at Stolsvik dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
[Bug fortran/25046] MASK and ARRAY arguments of PRODUCT must have conformant shapes
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-02-05 00:14 --- Subject: Bug 25046 Author: tkoenig Date: Sun Feb 5 00:14:37 2006 New Revision: 110600 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110600 Log: 2006-02-04 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/26039 PR fortran/25046 * expr.c (gfc_check_conformance): Reorder error message to avoid plural. * check.c(gfc_check_minloc_maxloc): Call gfc_check_conformance for checking arguments array and mask. (check_reduction): Likewise. 2006-02-04 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/26039 PR fortran/25046 * maxval_maxloc_conformance_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxval_maxloc_conformance_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25046
[Bug fortran/26039] ICE with maxval
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-02-05 00:14 --- Subject: Bug 26039 Author: tkoenig Date: Sun Feb 5 00:14:37 2006 New Revision: 110600 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110600 Log: 2006-02-04 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/26039 PR fortran/25046 * expr.c (gfc_check_conformance): Reorder error message to avoid plural. * check.c(gfc_check_minloc_maxloc): Call gfc_check_conformance for checking arguments array and mask. (check_reduction): Likewise. 2006-02-04 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/26039 PR fortran/25046 * maxval_maxloc_conformance_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxval_maxloc_conformance_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26039
[Bug fortran/25046] MASK and ARRAY arguments of PRODUCT must have conformant shapes
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-02-05 00:16 --- Fixed on trunk and 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25046
[Bug fortran/26039] ICE with maxval
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-02-05 00:19 --- Fixed on trunk and 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26039
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #20 from ian at airs dot com 2006-02-05 00:19 --- In many common cases, the two constructors are identical. It should not be hard to simply emit both appropriate symbols before the function. That does not require any change to the ABI, but it eliminates the problem in the common case. I don't feel that this PR should be suspended, at least not until we have fixed the common case. -- ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
Re: [Bug c++/3187] gcc lays down two copies of constructors
On Feb 4, 2006, at 7:20 PM, ian at airs dot com wrote: --- Comment #20 from ian at airs dot com 2006-02-05 00:19 --- In many common cases, the two constructors are identical. It should not be hard to simply emit both appropriate symbols before the function. That does not require any change to the ABI, but it eliminates the problem in the common case. But that does not work for some assemblers/file formats (like Darwin) as Darwin's as finds subsections via labels. There has been some discussion on why this suggestion would not work on the mailing list (but I cannot find it right now). Thanks, Andrew Pinski
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-02-05 00:27 --- Subject: Re: gcc lays down two copies of constructors On Feb 4, 2006, at 7:20 PM, ian at airs dot com wrote: > > > --- Comment #20 from ian at airs dot com 2006-02-05 00:19 --- > In many common cases, the two constructors are identical. It should > not be > hard to simply emit both appropriate symbols before the function. > That does > not require any change to the ABI, but it eliminates the problem in > the common > case. But that does not work for some assemblers/file formats (like Darwin) as Darwin's as finds subsections via labels. There has been some discussion on why this suggestion would not work on the mailing list (but I cannot find it right now). Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #22 from ian at airs dot com 2006-02-05 00:42 --- The fact that it does not work everywhere is not a valid reason that it should not be implemented where it can work, particularly since the places where it can work are, as it happens, most places. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-02-05 00:55 --- For future reference: a patch which would fix this: http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00354.html Previous discussions about this issue: http://gcc.gnu.org/ml/gcc/2002-12/msg00474.html More about the patch: http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00689.html There is more like other threads too which I cannot find right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug middle-end/25251] NIST Failure - FM013.f at -O2
--- Comment #3 from kargl at gcc dot gnu dot org 2006-02-05 03:10 --- Created an attachment (id=10779) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10779&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug tree-optimization/25251] NIST Failure - FM013.f at -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-05 03:25 --- I am going to take this one over. Final_cleanup is removing the labels for some reason. Will look more into why it is removing them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug tree-optimization/25251] NIST Failure - FM013.f at -O2
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-05 03:30 --- In cleanup_dead_labels, we forget to check if the label's address has been taken. The reason why this works with a C example is because the labels are not marked as artificial. Fixing it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug tree-optimization/25251] NIST Failure - FM013.f at -O2
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-05 03:55 ---
The patch I am testing right now:
Index: tree-cfg.c
===
--- tree-cfg.c (revision 110536)
+++ tree-cfg.c (working copy)
@@ -1108,7 +1108,8 @@ cleanup_dead_labels (void)
for_each_eh_region (update_eh_label);
/* Finally, purge dead labels. All user-defined labels and labels that
- can be the target of non-local gotos are preserved. */
+ can be the target of non-local gotos and labels which have their
+ address taken are preserved. */
FOR_EACH_BB (bb)
{
block_stmt_iterator i;
@@ -1128,7 +1129,8 @@ cleanup_dead_labels (void)
if (label == label_for_this_bb
|| ! DECL_ARTIFICIAL (label)
- || DECL_NONLOCAL (label))
+ || DECL_NONLOCAL (label)
+ || FORCED_LABEL (label))
bsi_next (&i);
else
bsi_remove (&i, true);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug c++/26099] support for type traits is not available
--- Comment #6 from gdr at integrable-solutions dot net 2006-02-05 03:56 --- Subject: Re: support for type traits is not available "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The interest should really go to the committe than one | implementation. Now GCC can add this as an extensions and that can | help the discussion/decision to add it to the standard. I have no doubt many (all?) of of the tr1 traits will be part of C++0x. I think the PR is a valid request for enhancement, with priority higher than most requests for enhancements I've seen. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #24 from gdr at integrable-solutions dot net 2006-02-05 03:58 --- Subject: Re: gcc lays down two copies of constructors "ian at airs dot com" <[EMAIL PROTECTED]> writes: | I don't feel that this PR should be suspended, at least not until we | have fixed the common case. I think I agree with Ian. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #25 from gdr at integrable-solutions dot net 2006-02-05 04:00 --- Subject: Re: gcc lays down two copies of constructors "pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes: | But that does not work for some assemblers/file formats (like Darwin) as | Darwin's as finds subsections via labels. then we would just have not to implement what Ian proposes for Darwin. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug c++/26100] New: Destructor called twice
The attached code does various things with a type ("inv") that increments a
count on constructor calls and decrements on destructor calls. As there are no
declarations of this type, only temporaries, the net should be zero at the end
of each statement. Unfortunately, the count goes negative.
Ivan
--
Summary: Destructor called twice
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26100
[Bug c++/26100] Destructor called twice
--- Comment #1 from igodard at pacbell dot net 2006-02-05 06:21 --- Created an attachment (id=10780) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10780&action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26100
