[Bug target/17390] missing floating point compare optimization
--- Comment #10 from pluto at agmk dot net 2006-05-01 08:05 ---
(In reply to comment #9)
> Created an attachment (id=10666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10666&action=view) [edit]
> patch to SVN GCC: (GNU) 4.2.0 20060117 (experimental)
this patch ICEs recent x86-64 gcc:
$ ./xgcc -B. -v
Reading specs from ./specs
Target: x86_64-pld-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info
--mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-shared
--enable-threads=posix --enable-languages=c,c++ --enable-c99 --enable-long-long
--enable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld
--with-demangler-in-ld --with-system-zlib --with-slibdir=/lib64
--without-system-libunwind --without-x --with-long-double-128
--with-gxx-include-dir=/usr/include/c++/4.2.0 --disable-libstdcxx-pch
--enable-__cxa_atexit --enable-libstdcxx-allocator=new x86_64-pld-linux
Thread model: posix
gcc version 4.2.0 20060428 (experimental) (PLD-Linux)
$ cat T1.c
void test(double x) { if (x > 0.0); }
$ ./xgcc -B. T1.c -m32
T1.c: In function ‘test’:
T1.c:1: internal compiler error: in bsi_last, at tree-flow-inline.h:683
$ cat T2.cpp
struct S { ~S(); };
void bar();
void foo()
{
S s;
bar();
}
$ ./xgcc -B. T2.cpp -m32
T2.cpp: In function ‘void foo()’:
T2.cpp:7: internal compiler error: in bsi_last, at tree-flow-inline.h:683
--
pluto at agmk dot net changed:
What|Removed |Added
CC||pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #6 from baldrick at free dot fr 2006-05-01 10:09 --- Re comment #5: > so we have [1,1] UNION [2, +INF] and we just get ~[0,0] bogus > and it also means this is PR 23744. This is more than PR 23744: with the fix for PR 23744 applied, __builtin_abort () is still not eliminated due to VRP failing to eliminate the i > n comparison (symbolic range). -- baldrick at free dot fr changed: What|Removed |Added CC||baldrick at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Comment #7 from pluto at agmk dot net 2006-05-01 10:31 --- 4.1.1-20060501 (rev. 113407) fails again. [ i686 ] ./c-format.o differs ./combine.o differs ./global.o differs ./i386.o differs ./ipa-cp.o differs ./loop.o differs ./modulo-sched.o differs ./reg-stack.o differs ./regclass.o differs ./reload1.o differs ./simplify-rtx.o differs ./toplev.o differs ./tree-data-ref.o differs ./tree-into-ssa.o differs ./tree-outof-ssa.o differs ada/erroutc.o differs ada/restrict.o differs ada/s-casuti.o differs ada/sem_maps.o differs cp/call.o differs cp/pt.o differs fortran/symbol.o differs java/class.o differs build/genautomata.o differs [ ppc ] ./builtins.o differs ./caller-save.o differs ./ddg.o differs ./flow.o differs ./global.o differs ./modulo-sched.o differs ./real.o differs ./recog.o differs ./regrename.o differs ./reload.o differs ./reload1.o differs ./sched-deps.o differs ./simplify-rtx.o differs ./tree-into-ssa.o differs ada/exp_dbug.o differs ada/osint.o differs ada/treepr.o differs java/jcf-write.o differs build/genrecog.o differs [ x86-64 ] ./c-format.o differs ./i386.o differs ./reg-stack.o differs ./reload1.o differs ./simplify-rtx.o differs ./stmt.o differs ada/bcheck.o differs cp/search.o differs e.g.: -reg-stack-stage2.o: file format elf64-x86-64 +reg-stack-stage3.o: file format elf64-x86-64 Disassembly of section .text: @@ -4111,8 +4111,8 @@ 38ac: bf 00 00 00 00 mov$0x0,%edi 38b1: e8 00 00 00 00 callq 38b6 38b6: 41 8d 7f ff lea0x(%r15),%edi -38ba: 4c 8d 56 ff lea0x(%rsi),%r10 -38be: 4d 8d 48 ff lea0x(%r8),%r9 +38ba: 4c 8d 4e ff lea0x(%rsi),%r9 +38be: 4d 8d 50 ff lea0x(%r8),%r10 38c2: 48 63 cfmovslq %edi,%rcx 38c5: 48 8b 3c 24 mov(%rsp),%rdi 38c9: 49 8d 2c 08 lea(%r8,%rcx,1),%rbp @@ -4121,10 +4121,10 @@ 38d4: 44 0f b6 24 2f movzbl (%rdi,%rbp,1),%r12d 38d9: 46 38 24 2f cmp%r12b,(%rdi,%r13,1) 38dd: 75 c3 jne38a2 -38df: 4d 8d 24 09 lea(%r9,%rcx,1),%r12 -38e3: 49 8d 04 0a lea(%r10,%rcx,1),%rax -38e7: 4c 8d 4e fe lea0xfffe(%rsi),%r9 -38eb: 4d 8d 50 fe lea0xfffe(%r8),%r10 +38df: 4d 8d 24 0a lea(%r10,%rcx,1),%r12 +38e3: 49 8d 04 09 lea(%r9,%rcx,1),%rax +38e7: 4d 8d 50 fe lea0xfffe(%r8),%r10 +38eb: 4c 8d 4e fe lea0xfffe(%rsi),%r9 38ef: 42 0f b6 14 27 movzbl (%rdi,%r12,1),%edx 38f4: 38 14 07cmp%dl,(%rdi,%rax,1) 38f7: 75 a9 jne38a2 -- pluto at agmk dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Version|4.1.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
[Bug target/26915] missed optimization / returning -1.0
--- Comment #2 from pluto at agmk dot net 2006-05-01 10:41 --- (In reply to comment #1) > ...and the current 4.2.0 ICEs on this testcase: > > $ ./xgcc -B. 26915.c -m32 -march=i686 > 26915.c: In function ‘minus1’: > 26915.c:1: error: bb_for_stmt (stmt) is set to a wrong basic block > 26915.c:1: error: bb_for_stmt (stmt) is set to a wrong basic block > 26915.c:1: internal compiler error: verify_stmts failed > please ignore this ICE. it's related to other patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390#c10 current 4.1 and 4.2 don't optimize original testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26915
[Bug middle-end/26565] [4.0/4.1 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-01 11:36 --- Subject: Bug 26565 Author: rguenth Date: Mon May 1 11:36:27 2006 New Revision: 113410 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113410 Log: 2006-05-01 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26565 * builtins.c (get_pointer_alignment): Handle component references for field alignment. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug middle-end/26565] [4.0/4.1 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-05-01 12:04 --- Subject: Bug 26565 Author: rguenth Date: Mon May 1 12:04:13 2006 New Revision: 113411 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113411 Log: 2006-05-01 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26565 * builtins.c (get_pointer_alignment): Handle component references for field alignment. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug middle-end/26565] [4.0/4.1 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-05-01 12:04 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-01 12:39:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug libgcj/27368] New: [Xlib peer] Font.canDisplayUpTo throws UnsupportedOperationException
Until/unless bug 25375 is fixed, I'd like to use the Xlib AWT peer. But I can't yet, because it doesn't implement the peer method for java.awt.Font.canDisplayUpTo - it throws an UnsupportedOperationException. (Incidentally, the gtk peer doesn't implement it either - it just returns a dummy answer.) I don't think that core Xlib provides a convenient API for this info, so maybe the Xlib peer should use Xft for font stuff instead of core Xlib. -- Summary: [Xlib peer] Font.canDisplayUpTo throws UnsupportedOperationException Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greenrd at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27368
[Bug c++/27369] New: tree check ICE when attribute externally_visible used
When compiling a C++ program (for the AVR target) that defines interrupt vectors using the externally_visible attribute, I get this ICE message: avrlib/bits/atmega128_usart.cpp:20: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'omp_atomic' in eq_node, at cgraph.c:175 Environment: System: Darwin Neds-Mini.local 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc host: powerpc-apple-darwin8.6.0 build: powerpc-apple-darwin8.6.0 target: avr-unknown-none configured with: /opt/local/var/db/dports/build/_Users_ned_src_darwinports_dports_cross_avr-gcc/work/gcc-4.2-20060429/configure --prefix=/opt/local --infodir=/opt/local/share/info --mandir=/opt/local/share/man --target=avr --program-prefix=avr- --with-included-gettext --enable-obsolete --with-gxx-include-dir=/opt/local/avr/include/c++/4.2-20060429/ --disable-libssp --enable-languages=c,c++ How-To-Repeat: Compile the attached hw.ii file with: avr-g++ -fno-exceptions -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -ggdb -O2 -Wall -Wextra -Wshadow -mmcu=atmega128 -xc++ -c -o hw.o hw.ii --- Comment #1 from ned at bike-nomad dot com 2006-05-01 14:38 --- Fix: Remove the externally_visible attributes on the vector definitions (lines 1998 to 2020) in attached file hw.ii and recompile: sed -e '1998,2020s/, externally_visible//' hw.ii > hwgood.cpp avr-g++ -fno-exceptions -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -ggdb -O2 -Wall -Wextra -Wshadow -mmcu=atmega128 -xc++ -c -o hwgood.o hwgood.cpp -- Summary: tree check ICE when attribute externally_visible used Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ned at bike-nomad dot com GCC build triplet: powerpc-apple-darwin8.6.0 GCC host triplet: powerpc-apple-darwin8.6.0 GCC target triplet: avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug c++/27369] tree check ICE when attribute externally_visible used
--- Comment #2 from ned at bike-nomad dot com 2006-05-01 14:40 --- Created an attachment (id=11353) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11353&action=view) precompiled file that causes ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug target/26882] ICE when using template function with memory attributes
--- Comment #2 from ned at bike-nomad dot com 2006-05-01 15:01 --- Still present in 4.2-20060429 snapshot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26882
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-05-01 15:07 --- Subject: Bug 26726 Author: rguenth Date: Mon May 1 15:07:25 2006 New Revision: 113414 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113414 Log: 2006-05-01 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/26726 * tree-ssa-loop-ivopts.c (idx_find_step): Mark source of the problem ... (find_interesting_uses_address): ... we work around here by folding INDIRECT_REFs in the substituted base. * g++.dg/tree-ssa/ivopts-1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/ivopts-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-01 15:09 --- This is now a target specific problem, on i?86 and x86_64 we are left with an offset of -4B and so referencing &a[5] in the exit condition. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target GCC target triplet||i?86-*-* x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)
--- Comment #5 from rth at gcc dot gnu dot org 2006-05-01 15:11 --- We went through three iterations of this on the branch. The variable identification step cannot be done before gimplification, because it requires that we also mark some variables that are created by the gimplification process. The step is complex enough that writing three different versions of the pass to generate error messages from the front end proved to be intractable. I, for one, am not going to change this. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751
[Bug c++/26912] [4.0/4.1 Regression] friend const member function specialization fails to compile
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-05-01 15:11 --- Subject: Bug 26912 Author: mmitchel Date: Mon May 1 15:11:34 2006 New Revision: 113415 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113415 Log: PR c++/26912 * decl.c (grokdeclarator): Qualify "this" pointer when forming member function types. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/friend41.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26912
[Bug c++/26912] [4.0/4.1 Regression] friend const member function specialization fails to compile
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-05-01 15:12 --- Subject: Bug 26912 Author: mmitchel Date: Mon May 1 15:12:11 2006 New Revision: 113416 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113416 Log: PR c++/26912 * g++.dg/template/friend41.C: New test. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26912
[Bug c++/26912] [4.0 Regression] friend const member function specialization fails to compile
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-05-01 15:13 --- Fixed in 4.1.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression] friend |[4.0 Regression] friend |const member function |const member function |specialization fails to |specialization fails to |compile |compile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26912
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #4 from dnovillo at gcc dot gnu dot org 2006-05-01 15:15 --- (In reply to comment #2) > without this we don't remap privatized global vars except directly in the > omp context that privatized them. > But this is as it should be. We are only required to privatize variables in the direct context that privatized them. We currently aren't, but if 'n' was accessed inside a separate function, the global 'n' should be accessed. > With the above patch, we still create wrong code, with 2 different bugs: > 1) there is no barrier to separate firstprivate assignments from lastprivate > Barrier? We don't need a barrier. We just need to make sure that only the thread handling the very last iteration of the loop or the thread executing the last omp section is the only one executing the copy-out operation. > 2) on the sender side, we store the global var n into > .omp_data_o.4D.1945.nD.1938, but on the receiver side we access either the > remapped private n (assuming the above patch is in) or, when accessing the > outside n we use the global variable n rather than .omp_data_iD.1937.nD.1938 > We should not need to access via .omp_data_o/.omp_data_i. So, if n.1591 is the privatized version of n.1567, we should emit something like: #pragma omp parallel firstprivate(n.1567) lastprivate(n.1567) n.1591 = n.1567 #pragma omp for for (i.1587 = 0; i.1587 <= 15; i.1587 = i.1587 + 1) < ... use and set n.1591 ...> OMP_CONTIUNE if (i.1587 == 16) n.1567 = n.1591 OMP_RETURN [nowait] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug c++/27370] New: Bogus warning about ignoring function return value (__attribute__ ((warn_unused_result)))
class QByteArray {
public:
QByteArray(const QByteArray &);
};
class QString {
QByteArray toLocal8Bit() const __attribute__ ((warn_unused_result));
inline QByteArray local8Bit() const{ return toLocal8Bit(); }
};
Produces with g++ -S -Wall:
test.1.1.min.ii: In member function 'QByteArray QString::local8Bit() const':
test.1.1.min.ii:7: warning: ignoring return value of 'QByteArray
QString::toLocal8Bit() const', declared with attribute warn_unused_result
--
Summary: Bogus warning about ignoring function return value
(__attribute__ ((warn_unused_result)))
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27370
[Bug c++/27370] [4.0 Regression] Bogus warning about ignoring function return value (__attribute__ ((warn_unused_result)))
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-01 15:19 --- A regression from 3.4.6. Works in 4.1.0 - Janis, can you hunt this down? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 Known to work||3.4.6 4.1.0 Summary|Bogus warning about ignoring|[4.0 Regression] Bogus |function return value |warning about ignoring |(__attribute__ |function return value |((warn_unused_result))) |(__attribute__ ||((warn_unused_result))) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27370
[Bug c++/27370] [4.0 Regression] Bogus warning about ignoring function return value (__attribute__ ((warn_unused_result)))
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-01 15:24 ---
Though 4.1.0 seems to not warn at all:
class QByteArray {
public:
QByteArray(const QByteArray &);
};
class QString {
QByteArray toLocal8Bit() const __attribute__ ((warn_unused_result));
inline QByteArray local8Bit() const{ return toLocal8Bit(); }
void fooWarnHere() const { toLocal8Bit(); }
};
should warn for fooWarnHere, but doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27370
[Bug c++/27370] [4.0 Regression] Bogus warning about ignoring function return value (__attribute__ ((warn_unused_result)))
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Known to work|3.4.6 4.1.0 |3.4.6 4.1.0 4.2.0 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27370
[Bug c++/27369] tree check ICE when attribute externally_visible used
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-01 15:38 --- This is more likely a GC issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||GC, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug c++/27371] New: [4.1/4.2 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))
class QByteArray {
public:
QByteArray(const QByteArray &);
};
class QString {
QByteArray toLocal8Bit() const __attribute__ ((warn_unused_result));
void fooWarnHere() const { toLocal8Bit(); }
};
Does not complain about fooWarnHere(). 4.0.3 did this.
--
Summary: [4.1/4.2 Regression] Does not warn about unused function
result (__attribute__((warn_unused_result)))
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
[Bug c/27358] ICE with invalid variable after #pragma omp parallel
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-30 04:06:12 |2006-05-01 15:59:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27358
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-01 16:07 --- We do need a barrier (well, in some cases with extra code we can avoid it in some cases), in order to honor 2.8.3.4: "If a list item appears in both firstprivate and lastprivate clauses, the update required for lastprivate occurs after all the initializations for firstprivate." Now, as e.g. Richard's testcase shows, without a barrier somewhere between the firstprivate initializations and lastprivate copying it is possible that some thread is initialized for the first time after the thread handling the last case executed the lastprivate copying. That can happen either because some constructor in firstprivate initialization slept intentionally, or just the thread was not being scheduled to run for sufficiently long. The patch I'll post RSN will just add the barrier for any firstprivate+lastprivate, correctness first, then we can optimize. Cases which can be optimized: 1) if we prove the structured block has at least one barrier in between the firstprivate and lastprivate code chunks (doesn't matter if explicit #pragma omp barrier or some other OMP stuff that acts similarly) 2) if the variable is not passed by reference (i.e. scalar put directly into .omp_data_*) and we use 2 fields for it rather than one - sender initializes first field and firstprivate uses that, then lastprivate sets the second field and sender copies from the second field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #6 from dnovillo at redhat dot com 2006-05-01 16:11 --- Subject: Re: [gomp] firstprivate not working properly with non-POD -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 jakub at gcc dot gnu dot org wrote: > --- Comment #5 from jakub at gcc dot gnu dot org 2006-05-01 16:07 --- > We do need a barrier (well, in some cases with extra code we can avoid > it in some cases), in order to honor 2.8.3.4: > "If a list item appears in both firstprivate and lastprivate clauses, the > update > required for lastprivate occurs after all the initializations for > firstprivate." > Ah, yes, of course. Sorry about that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEVjMVUTa2oAUaiwQRAkViAJ4s5n62EohuFxCUWVQGZ1owtoSTcACfZR7i NgLf43AMmOQ0xLmnl89ZkYQ= =cjzg -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug tree-optimization/27364] [4.1/4.2 Regression] VRP miscompiles some unsigned math
--- Comment #13 from law at redhat dot com 2006-05-01 16:36 --- The overflow check for multiplication is totally bogus. The right way to check for overflow of an integer multiplication is to use division. ie, given res = a * b; Divide res by a, if the result is less than b, then the multiplication overlowed. [ Note, assumes a != 0. ] In fact, any result other than "b" is bad. Anyway, once we muck up the overflow status of the multiplication we lose. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug c/27358] ICE with invalid variable after #pragma omp parallel
--- Comment #2 from rth at gcc dot gnu dot org 2006-05-01 17:46 --- Subject: Bug 27358 Author: rth Date: Mon May 1 17:46:32 2006 New Revision: 113421 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113421 Log: PR c/27358 * c-parser.c (c_parser_skip_to_end_of_block_or_statement): Move after c_parser_skip_to_pragma_eol. Convert to switch statement. Handle CPP_PRAGMA. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr27358.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27358
[Bug c/27358] ICE with invalid variable after #pragma omp parallel
--- Comment #3 from rth at gcc dot gnu dot org 2006-05-01 17:50 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27358
[Bug libgcj/26593] libgcjawt should be built even if the gtk peers aren't
--- Comment #3 from bero at arklinux dot org 2006-05-01 17:50 --- Agreed, should be built in any case (which is apparently done correctly in current trunk). trunk still has the problem that the classpath_jawt_* functions are defined for the gtk peer only; an implementation for the qt and xlib peers is needed to make libgcjawt useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26593
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #7 from rth at gcc dot gnu dot org 2006-05-01 17:58 --- (In reply to comment #5) > 1) if we prove the structured block has at least one barrier in between the > firstprivate and lastprivate code chunks (doesn't matter if explicit #pragma > omp barrier or some other OMP stuff that acts similarly) > 2) if the variable is not passed by reference (i.e. scalar put directly into > .omp_data_*) and we use 2 fields for it rather than one - sender initializes > first field and firstprivate uses that, then lastprivate sets the second field > and sender copies from the second field. Both of these are fairly valuable. But for when optimization fails, I think adding a specialized construct for this in libgomp would also be helpful. Something akin to a semaphore initialized to -thread_count, such that a wait on the semaphore before the lastprivate is assured that all the firstprivates are done. One would expect that the common case is that they will be done, and the semaphore will take the unlocked fast-path. I'll look into adding this. Since we've already shipped this library in fc5, do you think it's worthwhile adding it to a new version tag? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug middle-end/27373] New: ICE: add_virtual_operand, at tree-ssa-operands.c:1284
gcc version 4.2.0 20060501 (experimental) > gfortran -c -O2 bug.f90 bug.f90: In function âreset_to_next_rng_substreamâ: bug.f90:11: internal compiler error: in add_virtual_operand, at tree-ssa-operands.c:1284 for : > cat bug.f90 MODULE parallel_rng_types INTEGER, PARAMETER :: dp=KIND(0.0D0) TYPE rng_stream_type REAL(KIND=dp), DIMENSION(3,2) :: bg,cg,ig LOGICAL :: antithetic,extended_precision END TYPE rng_stream_type TYPE cp_error_type INTEGER :: dum END TYPE CONTAINS SUBROUTINE reset_to_next_rng_substream(rng_stream,error) TYPE(rng_stream_type), POINTER :: rng_stream LOGICAL :: failure REAL(KIND=dp), DIMENSION(3, 2) :: u CALL cp_assert(ASSOCIATED(rng_stream),2,routineP,error,failure) IF (.NOT.failure) THEN rng_stream%bg = u rng_stream%cg = u END IF END SUBROUTINE reset_to_next_rng_substream END MODULE -- Summary: ICE: add_virtual_operand, at tree-ssa-operands.c:1284 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27373
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #31 from gdr at integrable-solutions dot net 2006-05-01 18:55 --- Subject: Re: hidden declarations klobber STL "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | Well, two comments: first, I cannot reproduce with current mainline. Second, | frankly, if the implication of the issue is that in the entire implementation | of we cannot use operator, only to allow the user to write | unrestricted operator, templates in the face of the ADL trickeries, then, well, | I don't think we are going to buy that. Before closing this I'm only curious to | know why mainline is fine, maybe, simply, ADL was too zelant here? Any language | lawyer kicking in? Why is operator, essential to libstdc++? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #32 from gdr at integrable-solutions dot net 2006-05-01 18:59 --- Subject: Re: hidden declarations klobber STL "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 --- | (In reply to comment #12) | > I don't think that the problem is in the STL. The STL can be as tricky as it | > wants, including use of operator,(). It should not be possible for the actual | > operator,()s I declared to hijack the STL the way that happened, because 1) my | > declarations were out of scope for the STL code and 2) their signatures did not | > match the STL call site. This suggests a compiler bug to me, not an STL | > mis-design. | | Actually, I'm not at all sure, given: 1- our vector<>::iterator not being a | built-in type; 2- ADL rules. 3- The nature of fill_n (templated on *both* _Size | and _OutputIterator). Again, I'm not a language lawyer, but I think that, | strictly speaking, the compiler may legally find and match your operator, Yes. | I can certainly patch fill_n to avoid the operator, no big deal, my question is | more general, whether, given our class-type vector<>::iterator, given the | "unrestrictedness" of many templates, given current ADL rules, | whether it makes sense for us to go that route trying piecewise to "improve" | now the library, in the current C++03 framework. I believe it makes sense to do so the extent we can -- we (e.g. *you*) did patch the library so that qualified call where OK, e.g. std::copy, where we did so only for implementation details. The use of operator, in this case is no different. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #33 from gdr at integrable-solutions dot net 2006-05-01 19:02 --- Subject: Re: hidden declarations klobber STL "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes: | I mean, it's a miracle your code actually does what you expect. :-)) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27336] "this" pointer is not assumed to be not null
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-01 19:17 --- Re. comment #2 and comment #3, yes you are expecting too much of the nonnull attribute. The attribute only applies to function arguments, not to function results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
[Bug c++/27336] "this" pointer is not assumed to be not null
--- Comment #5 from steven at gcc dot gnu dot org 2006-05-01 19:19 ---
Ehm, right, ignore comment #4.
Yes it is possible.
No, it's not very practical. Your code looks like,
bool f(A *a) {
g(a);
return a;
}
to the middle end. It would take a significant amount of extra work to walk
through all formal and actual argument lists in a CALL_EXPR to find "attribute
nonnull"-arguments in the callee argument list. I'm not sure that's worth the
cost.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
[Bug c++/27336] "this" pointer is not assumed to be not null
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-01 19:21 --- Though it's also not hard to teach VRP to do this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-01 19:42 --- Subject: Bug 27144 Author: rakdver Date: Mon May 1 19:42:01 2006 New Revision: 113425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113425 Log: PR tree-optimization/27144 * tree-ssa-loop-niter.c (derive_constant_upper_bound): New function. (record_estimate): Only record constant upper bound. (infer_loop_bounds_from_undefined): Call compute_estimated_nb_iterations just once. (proved_non_wrapping_p): Renamed to ... (n_of_executions_at_most): ... this. Expect bound to be a constant. (convert_step_widening, scev_probably_wraps_p): Call n_of_executions_at_most instead of proved_non_wrapping_p. (substitute_in_loop_info): Do not replace values in bounds. * cfgloop.h (struct nb_iter_bound): Remove "additional" field. Update comments. * gcc.dg/tree-ssa/loop-16.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-01 20:06 --- Subject: Bug 27283 Author: rakdver Date: Mon May 1 20:05:57 2006 New Revision: 113427 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113427 Log: PR tree-optimization/27283 * tree-ssa-loop-ivopts.c (struct nfe_cache_elt): Store just trees, not whole # of iteration descriptions. (niter_for_exit): Return just # of iterations. Fail if # of iterations uses abnormal ssa name. (niter_for_single_dom_exit): Ditto. (find_induction_variables, may_eliminate_iv): Expect niter_for_exit to return just the number of iterations. * g++.dg/tree-ssa/pr27283.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr27283.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #12 from gdr at integrable-solutions dot net 2006-05-01 20:45 --- Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <[EMAIL PROTECTED]> writes: | I think this is a valid request. While random language extensions aren't | useful, | compatibility with C99 is. Maybe somebody else can comment on this... You have to be more precise about what you mean by C99 compatibility. My take on this goto stuff, if it is not valid C++, it is valid C++. Period. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-05-01 20:46 --- Subject: Bug 27291 Author: rakdver Date: Mon May 1 20:46:22 2006 New Revision: 113430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113430 Log: PR rtl-optimization/27291 * loop-doloop.c (add_test, doloop_modify): Handle the case condition is folded to a constant. * g++.dg/tree-ssa/pr27291.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr27291.C Modified: trunk/gcc/ChangeLog trunk/gcc/loop-doloop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27291
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #13 from gdr at integrable-solutions dot net 2006-05-01 20:47 --- Subject: Re: goto crossing P.O.D. initialization "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | PR 27252 (aka PR 9278) is another example where C and C++ diff and in fact was | just fixed for 4.2.0 for a bug report. These are just some examples of where C | and C++ differ. I fully agree. People have to be extra careful when they talk about compatibility with C99 where the C committee has carefully chosen to depart from C++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #14 from gdr at integrable-solutions dot net 2006-05-01 20:48 --- Subject: Re: goto crossing P.O.D. initialization "acahalan at gmail dot com" <[EMAIL PROTECTED]> writes: | I only ask that C compatibility be provided for code that would otherwise fail | to compile as C++. This makes code reuse much easier. Given prior existence in C++, I think logic would require that you ask gcc to be compatibile with g++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #15 from falk at debian dot org 2006-05-01 20:55 --- (In reply to comment #12) > Subject: Re: goto crossing P.O.D. initialization > > "falk at debian dot org" <[EMAIL PROTECTED]> writes: > > | I think this is a valid request. While random language extensions aren't > | useful, > | compatibility with C99 is. Maybe somebody else can comment on this... > > You have to be more precise about what you mean by C99 compatibility. I have trouble seeing what might be unclear about this term. I mean that code that is valid C99 is accepted in C++ unless there is a good reason not to. just like most of C89 is accepted in C++ unless there is a good reason not to. > My take on this goto stuff, if it is not valid C++, it is valid C++. That logically implies that everything valid C++, which might be overdoing it a bit ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #29 from rguenth at gcc dot gnu dot org 2006-05-01 21:12 --- ca11011 looks like a spurious failure (do I hate that...). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug target/27374] New: *arm_movdi_vfp in config/arm/vfp.md has wrong output templates
fmdrr and fmrrd each take three arguments. However, the output templates are giving only two arguments. I've got a patch. -- Summary: *arm_movdi_vfp in config/arm/vfp.md has wrong output templates Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: kazu at gcc dot gnu dot org ReportedBy: kazu at gcc dot gnu dot org GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27374
[Bug target/27374] *arm_movdi_vfp in config/arm/vfp.md has wrong output templates
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-01 21:55 --- Subject: Bug 27374 Author: kazu Date: Mon May 1 21:55:02 2006 New Revision: 113436 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113436 Log: PR target/27374 * config/arm/vfp.md (*arm_movdi_vfp): Correct the output templates for case 3 and 4. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/vfp.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27374
[Bug target/27374] *arm_movdi_vfp in config/arm/vfp.md has wrong output templates
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-01 21:56 --- Subject: Bug 27374 Author: kazu Date: Mon May 1 21:56:47 2006 New Revision: 113437 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113437 Log: PR target/27374 * config/arm/vfp.md (*arm_movdi_vfp): Correct the output templates for case 3 and 4. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/arm/vfp.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27374
[Bug target/27374] *arm_movdi_vfp in config/arm/vfp.md has wrong output templates
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-01 21:58 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27374
[Bug tree-optimization/27373] [4.2 Regression] ICE: add_virtual_operand, at tree-ssa-operands.c:1284
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |tree-optimization GCC target triplet| x86_64-unknown-linux-gnu |x86_64-unknown-linux-gnu Keywords||ice-on-valid-code Summary|ICE: add_virtual_operand, at|[4.2 Regression] ICE: |tree-ssa-operands.c:1284|add_virtual_operand, at ||tree-ssa-operands.c:1284 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27373
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #16 from gdr at integrable-solutions dot net 2006-05-01 23:30 --- Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <[EMAIL PROTECTED]> writes: | --- Comment #15 from falk at debian dot org 2006-05-01 20:55 --- | (In reply to comment #12) | > Subject: Re: goto crossing P.O.D. initialization | > | > "falk at debian dot org" <[EMAIL PROTECTED]> writes: | > | > | I think this is a valid request. While random language extensions aren't | > | useful, | > | compatibility with C99 is. Maybe somebody else can comment on this... | > | > You have to be more precise about what you mean by C99 compatibility. | | I have trouble seeing what might be unclear about this term. I suspect part of the problem is that everybody believes that his/her uses of the term are so clear that they he/she has trouble seeing anybody disagree with him/her. | I mean that code | that is valid C99 is accepted in C++ unless there is a good reason not to. And why not the other way around? I mean, codes that is valid C++ is accepted in C99 unless there is good reason not to. As far as I can see, that also is compatibility. | just like most of C89 is accepted in C++ unless there is a good reason not to. I suspect this is might be one the places things needs to be explained. If * only a subset of C89 is valid C++ and has same meaning as in C++, * C99 has carefully departed from both C89 and C++ why is it that "code that is valid C99 is accepted C++ unless there is a good reason not to"? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- Comment #7 from gdr at integrable-solutions dot net 2006-05-01 23:39 --- Subject: Re: valarray uses __cos which may conflict with libm functions "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #4) | > Should all those private classes and functions be declared in some | > specific namespace std::glibcxx_private to have a single point of failure? | | Oups, I just noticed that was one of the roles of __gnu_cxx (although I don't | understand why this namespace is not a subnamespace of std:: as tr1 (or at | least contains a using namespace std;), Why shall it? Before people suggest more tricky playing with libstdc++ name spaces, I would recommand people understand that namespaces are not silver bullet against machivelic playing with names. | which would at the same time fix things | like getenv not being prefixed by std:: in ext/mt_allocator.h). That is a separate problem that does not require namespace nesting. Nesting namespaces does not come for free. You really need to understand its consequences (name lookp, overload resolution, etc.) before proposing it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug libfortran/24459] gfortran namelist problem
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-05-02 00:02 --- Patch here: http://gcc.gnu.org/ml/fortran/2006-05/msg0.html Waiting for approval -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug c++/27370] [4.0 Regression] Bogus warning about ignoring function return value (__attribute__ ((warn_unused_result)))
--- Comment #3 from janis at gcc dot gnu dot org 2006-05-02 00:09 --- The warning for the original testcase went away with this patch: r81764 | dnovillo | 2004-05-13 06:41:07 + (Thu, 13 May 2004) | 3 lines Merge tree-ssa-20020619-branch into mainline. http://gcc.gnu.org/viewcvs?view=rev&rev=81764 Ouch! I've got another reghunt going to find out when the warning started being issued again between 4.0 and 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27370
FireFox - Goole Toolbar - Browser
Google Browser - Firefire with Toolbar Click on the Link Below - IT IS FREE http://services.google.com/toolbar/firefox_install?hl=en&ai=BwZGf00c4RM3yA7SQLoKGhYMI6ZnSFOeo_M8BxY23AQAQASCltJQGSKI5UIPj0QKgAbWVyP0DyAECgAIBlQInfgsK&gclid=CMT20ri8noQCFU6JCwodYwHAhQ
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #14 from ian at airs dot com 2006-05-02 03:40 --- Created an attachment (id=11354) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11354&action=view) Possible patch I've attached a possible patch for this issue. It adds a new attribute "preserve_stack" which tells the compiler that the stack should be preserved. For example, __attribute__ ((preserve_stack, regparm (0))). It seems to work with pinskia's small test case. Could somebody see whether it works with the original test case? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug ada/27366] ada build fails as cygwin does not have clearenv
--- Comment #1 from billingd at gcc dot gnu dot org 2006-05-02 03:46 --- Here is the patch I tested. acats results below aren't a total disaster. 2006-01-05 David Billinghurst ([EMAIL PROTECTED]) PR ada/27366 * ada/env.c (__gnat_clearenv): Use unsetenv() to clear environment on Cygwin. Index: env.c === --- env.c (revision 113408) +++ env.c (working copy) @@ -288,7 +288,7 @@ index++; } #elif defined (__MINGW32__) || defined (__FreeBSD__) || defined (__APPLE__) \ - || (defined (__vxworks) && defined (__RTP__)) + || (defined (__vxworks) && defined (__RTP__)) || defined (__CYGWIN__) /* On Windows, FreeBSD and MacOS there is no function to clean all the environment but there is a "clean" way to unset a variable. So go through the environ table and call __gnat_unsetenv on all entries */ === acats Summary === # of expected passes1924 # of unexpected failures37 # of unsupported tests 356 *** FAILURES: c23003b c23003g c23003i c35507m c62003a c62003b c64103e c64103f c6 4104i c64104j c64104k c64104l c64104m c64104n c96005d cb4001a cc3017c cc3120a cd 2a23e cdd2a02 cxg2002 cxg2003 cxg2004 cxg2006 cxg2007 cxg2010 cxg2011 cxg2012 cx g2013 cxg2014 cxg2015 cxg2016 cxg2017 cxg2018 cxg2019 cxg2020 cxg2021 -- billingd at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-02 03:46:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27366
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-02 04:44 --- 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=27291
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-02 04:51 --- 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=27283
[Bug target/27277] standard i387 constant loading insns (fldz, fld1) are not generated anymore
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-02 04:54 --- It worked with "4.2.0 20060409" with a cross compiler from x86_64-linux-gnu to i686-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27277
[Bug target/27277] standard i387 constant loading insns (fldz, fld1) are not generated anymore
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-02 04:59 --- (In reply to comment #1) > PR26915 seems to be related to this bug. Not really as this one was working in 4.1.0 and that is about doing an extra instruction for smaller size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27277
[Bug rtl-optimization/17088] poor fortran optimisation at -O2/3
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-05-02 05:01 --- With: $ gfc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../main/configure --prefix=/home/jerry/gcc/usr --enable-languages=c,fortran --disable-libmudflap Thread model: posix gcc version 4.2.0 20060424 (experimental) $ gfc -O2 -march=pentium4 test-optimize.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17088
[Bug target/27277] [4.2 Regression] standard i387 constant loading insns (fldz, fld1) are not generated anymore
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-02 05:41 --- Confirmed. I want to say this was caused by: 2006-04-03 Paolo Bonzini <[EMAIL PROTECTED]> Dale Johannesen <[EMAIL PROTECTED]> PR target/19653 * regclass.c (struct reg_pref): Update documentation. (regclass): Set prefclass to NO_REGS if memory is the best option. (record_reg_classes): Cope with a prefclass set to NO_REGS. * reload.c (find_reloads): Take PREFERRED_OUTPUT_RELOAD_CLASS into account. For non-registers, equate an empty preferred reload class to a `!' in the constraint; move the if clause to do so after those that reject the insn. (push_reload): Allow PREFERRED_*_RELOAD_CLASS to liberally return NO_REGS. (find_dummy_reload): Likewise. * doc/tm.texi (Register Classes): Document what it means if PREFERRED_*_RELOAD_CLASS return NO_REGS. * config/i386/i386.c (ix86_preferred_reload_class): Force using SSE registers (and return NO_REGS for floating-point constants) if math is done with SSE. (ix86_preferred_output_reload_class): New. * config/i386/i386-protos.h (ix86_preferred_output_reload_class): New. * config/i386/i386.h (PREFERRED_OUTPUT_RELOAD_CLASS): New. * config/i386/i386.md: Remove # register preferences. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-05-02 05:41:52 date|| Summary|standard i387 constant |[4.2 Regression] standard |loading insns (fldz, fld1) |i387 constant loading insns |are not generated anymore |(fldz, fld1) are not ||generated anymore Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27277
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-05-02 05:55 --- The code which I replaced here is changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-05-02 06:14 --- This still fails even after the code change. CCing the person who changed the code: http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00024.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug testsuite/27376] New: treelang testsuite fails on cygwin
treelang testsuite fails on cygwin with
ERROR: tcl error sourcing
/usr/local/src/gcc/gcc/testsuite/treelang/output/output.exp.
ERROR: rm: cannot remove `treelang/output-1': No such file or directory
while executing
"exec rm $testname"
(procedure "test_treelang_output" line 31)
invoked from within
"test_treelang_output "treelang/$bname" $srcfiles $inpfile $x """
("foreach" body line 15)
invoked from within
"foreach x $outfiles {
regsub "\\.out$" $x "" prefix
set bname [file tail $prefix]
if [file exists ${prefix}.inp] {
set inpfile ${prefix}..."
(file "/usr/local/src/gcc/gcc/testsuite/treelang/output/output.exp" line
39)
invoked from within
"source /usr/local/src/gcc/gcc/testsuite/treelang/output/output.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /usr/local/src/gcc/gcc/testsuite/treelang/output/output.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
treelang/output-1 doesn't exist but treelang/output-1.exe does.
I'll work up a patch.
--
Summary: treelang testsuite fails on cygwin
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: billingd at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27376
[Bug testsuite/27376] treelang testsuite fails on cygwin
-- billingd at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |billingd at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-02 06:22:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27376
[Bug testsuite/27376] treelang testsuite fails on cygwin
-- billingd at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27376
[Bug objc/27377] New: false compiler warnings generated in Objective-C code
The following macro #define GS_INITIALIZED_LOCK(OBJ,CLS) \ (OBJ ? (CLS *) OBJ : (CLS *) [CLS newLockAt: (CLS **)&OBJ]) generates these compiler warnings. Unicode.m:253: warning: pointer type mismatch in conditional expression Unicode.m:253: warning: invalid receiver type 'void *' when called as [GS_INITIALIZED_LOCK(local_lock, GSLazyLock) lock]; local_lock here is declared as a static *GSLazyLock; As far as we can tell this code should not generate the warnings it does, which seems to suggest a fault in he objective-c frontend/backend code. -- Summary: false compiler warnings generated in Objective-C code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: caelian at gmail dot com GCC host triplet: amd64-unknown-freebsd7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug objc/27377] false compiler warnings generated in Objective-C code
--- Comment #1 from caelian at gmail dot com 2006-05-02 06:42 --- Created an attachment (id=11356) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11356&action=view) Unicode.mi file this is the output generated by compiling the file with -save-temps it should contain the code that generates the warnings -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug c++/27369] tree check ICE when attribute externally_visible used
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-02 06:56 ---
Reduced testcase:
void __vector_18(void) __attribute__ ((externally_visible));
void __vector_18(void) __attribute__ ((externally_visible));
void __vector_18 (void) { }
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|powerpc-apple-darwin8.6.0 |
GCC host triplet|powerpc-apple-darwin8.6.0 |
GCC target triplet|avr-unknown-none|
Last reconfirmed|-00-00 00:00:00 |2006-05-02 06:56:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug c++/27369] [4.2 Regression] tree check ICE when attribute externally_visible used
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-02 06:58 --- A regression from 4.1.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.1.1 Summary|tree check ICE when |[4.2 Regression] tree check |attribute externally_visible|ICE when attribute |used|externally_visible used Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
