60 Jahre Befreiung: Wer feiert mit?
http://www.unserforum.com/aff/include.php?path=content/content.php&contentid=149 http://www.unserforum.com/aff/include.php?path=content/content.php&contentid=54 http://www.unserforum.com/aff/include.php?path=content/content.php&contentid=55 http://www.unserforum.com/aff/include.php?path=content/content.php&contentid=56
Armenian Genocide Plagues Ankara 90 Years On
Full Article: http://service.spiegel.de/cache/international/0,1518,353274,00.html
Auslaender bevorzugt
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0305-14.html Jetzt weiss man auch, wie es dazu kommt, dass Drogen, Waffen & Handy's in die Haende der Knacki's gelangen!
Auslaenderpolitik
Lese selbst: http://www.mjoelnirsseite.de/2100.htm
Trotz Stellenabbau
Lese selbst: http://www.spiegel.de/wirtschaft/0,1518,338652,00.html
S.O.S. Kiez! Polizei schlaegt Alarm
Lese selbst: http://bz.berlin1.de/archiv/041115_pdf/BZ041115_004_GB2IG556.1.htm
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-15
03:55 ---
(In reply to comment #20)
I think, I have isolated the bug:
BUG #1:
During bootstrap, libgfortran/Makefile tries to generate selected_int_kind.inc:
selected_int_kind.inc: $(srcdir)/mk-sik-inc.sh
$(SHELL) $(srcdir)/mk-sik-inc.sh '$(FCCOMPILE)' > $@
This fails due to a segfault in f951, but the Makefile does not halt on this
segfault and continues, leaving a corrupted selected_int_kind.inc behind.
The actual command that fails of part of running mk-sik-inc.sh is:
/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/f951
bla.f90 -quiet -dumpbase bla.f90 -auxbase bla -Wall -version -fno-repack-arrays
-fno-underscoring -o /tmp/cc6taI72.s
with this bla.f90 (The first code fragment being generated by mk-sik-inc.sh):
integer (kind=1) :: x
end
BUG #2
Debugging
f951 bla.f90 -quiet -dumpbase bla.f90 -auxbase bla -Wall -version
-fno-repack-arrays -fno-underscoring -o /tmp/cc6taI72.s
reveals this:
During its initialization, f951 calls gfc_init_kinds().
This succeeds to initialize all int types, but fails to find a mode for
kind=8/DIMode.
Near to its end it enters:
gfc_validate_kind (type=BT_REAL, kind=8, may_fail=0 '\0') at
../../gcc-4.0.0/gcc/fortran/trans-types.c:332
This fails (kind=8 N/A), therefore
gfc_internal_error("gfc_validate_kind(): Got bad kind")
is being entered, which calls
show_loci (&gfc_current_locus, NULL);
At this point, gfc_current_locus is
gdb) print gfc_current_locus
$24 = {nextc = 0x0, lb = 0x0}
With this value, show_loci dereferences a NULL pointer during computation of c1
at error.c:208:
198 show_loci (locus * l1, locus * l2)
199 {
200 int offset, flag, i, m, c1, c2, cmax;
201
202 if (l1 == NULL)
203 {
204 error_printf ("\n");
205 return;
206 }
207
208 c1 = l1->nextc - l1->lb->line;
209 c2 = 0;
(gdb) print *l1
$26 = {nextc = 0x0, lb = 0x0}
I.e. the origin of the segfault is show_loci's expectations not matching with
the actual contents of gfc_current_locus.
BUG #3:
libgfortran's configure should refuse to be compiled for setups not being
supported by it or silently degrade gracefully. IMO, simply not
compiling/disabling building libgfortran for such setups would be the simpliest
solutions
Note: I am not talking about disabing building fortran or libgfortran for whole
targets. For multilib'ed toolchains, libgfortran could be compilable/usable for
some multilib variants but not for all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
Failed mail (msg.aa20233)
Your message could not be delivered to '[EMAIL PROTECTED] (host: sonic.net) (queue: smtp)' for the following reason: ' 5.7.1 The message you have sent generated an excessive number of complaints from our users.' Your message follows: Received: from [205.158.141.195] ([205.158.141.195]) by raisinbran.srv.cs.cmu.edu id aa20233; 14 May 2005 21:41 EDT From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 15 May 2005 01:38:56 GMT Subject: Schily ueber Deutschland Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Message-ID: <[EMAIL PROTECTED]> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Lese selbst: http://www.heise.de/newsticker/meldung/59427
S.O.S. Kiez! Polizei schlaegt Alarm
Lese selbst: http://bz.berlin1.de/archiv/041115_pdf/BZ041115_004_GB2IG556.1.htm
[Bug fortran/17423] gfortran segfault when compiling FM509.f from NIST testsuite
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 03:25 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 17423, which changed state. Bug 17423 Summary: gfortran segfault when compiling FM509.f from NIST testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
-- Bug 13082 depends on bug 17423, which changed state. Bug 17423 Summary: gfortran segfault when compiling FM509.f from NIST testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug c/17432] Possible gcc bug when compiling f2c generated C-code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-15 03:07 --- Subject: Bug 17432 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-15 03:07:43 Modified files: gcc/testsuite : ChangeLog gcc/fortran: ChangeLog trans-io.c trans-stmt.c Added files: gcc/testsuite/gfortran.dg: assign_4.f Log message: 2005-05-15 Feng Wang <[EMAIL PROTECTED]> Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/17432 * trans-stmt.c (gfc_trans_label_assign): fix pointer type, to resolve ICE on assign of format label. * trans-io.c (set_string): add fold-convert to properly handle assigned format label in write. 2005-05-15 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/17432 * gfortran.dg/assign_4.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.176&r2=1.5084.2.177 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_4.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.48&r2=1.335.2.49 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.33.2.1&r2=1.33.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.24.6.2&r2=1.24.6.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17432
Deutsche Buerger trauen sich nicht ...
Auslaenderbanden terrorisieren Wahlkampf - deutsche Buerger trauen sich nicht ihre Meinung zu sagen! Weiter auf: http://www.npd-nrw.net/aktuelles/03_2005/ak_presse_nrw_1603.htm Auslaender ueberfallen nationale Aktivisten: http://www.npd.de/npd_info/meldungen/2005/m0505-13.html http://www.npd.de/npd_info/meldungen/2005/m0505-14.html
[Bug c/17432] Possible gcc bug when compiling f2c generated C-code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-15 02:45 --- Subject: Bug 17432 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-15 02:45:30 Modified files: gcc/testsuite : ChangeLog gcc/fortran: ChangeLog trans-io.c trans-stmt.c Added files: gcc/testsuite/gfortran.dg: assign_4.f Log message: 2005-05-15 Feng Wang <[EMAIL PROTECTED]> Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/17432 * trans-stmt.c (gfc_trans_label_assign): fix pointer type, to resolve ICE on assign of format label. * trans-io.c (set_string): add fold-convert to properly handle assigned format label in write. 2005-05-15 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/17432 * gfortran.dg/assign_4.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5473&r2=1.5474 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_4.f.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.424&r2=1.425 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-io.c.diff?cvsroot=gcc&r1=1.35&r2=1.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&r1=1.29&r2=1.30 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17432
Auslaender bevorzugt
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0305-14.html Jetzt weiss man auch, wie es dazu kommt, dass Drogen, Waffen & Handy's in die Haende der Knacki's gelangen!
[Bug bootstrap/21556] [4.0/4.1 Regression] ia64-hpux bootstrap fails on mainline, TLS failures on 4.0 branch
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-15 02:02 --- C testsuite failures with the stage1 compiler introduced by this patch on mainline are the same as the new failures on 4.0 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
[Bug tree-optimization/21493] [4.1 Regression] internal compiler error: Segmentation fault
--- Additional Comments From mmalater at nycap dot rr dot com 2005-05-15 01:41 --- Just for fun I was running valgrind on g++ and the bug seems pretty straigforward to fix once you have a g++ compile with Debug. Here is the output: valgrind --trace-children=yes /usr/lib/gcc-snapshot/bin/g++ --save-temps -O2 -ftrapv -c cmDependsFortranParser.cxx ==6594== Invalid read of size 4 ==6594==at 0x8457F06: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x845A713: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x845B4D3: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x81FC974: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x81FD02F: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x845D2CC: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x8182D6C: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x8182DFF: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x81830EA: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x81113A6: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x847DD6A: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x847EB2A: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x80C19BD: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x815E9A8: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x8429F31: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594==by 0x1B920E35: __libc_start_main (libc-start.c:242) ==6594==by 0x80499A0: (within /usr/lib/gcc-snapshot/libexec/gcc/i486-linux/4.1.0/cc1plus) ==6594== Address 0x4 is not stack'd, malloc'd or (recently) free'd cmDependsFortranParser.cxx: In function 'int cmDependsFortran_yyparse(void*)': cmDependsFortranParser.cxx:900: 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=21493
Verbrechen der deutschen Frau
Lese selbst: http://www.jn-bw.de/texte/zeitgeschichte/verbrechen_der_frau.htm
Bugzilla Error
ActiveState Bugzilla Bugzilla found the following warnings (not critical): Priority has been set to the default (3-Medium). Bug severity has been set to the default value (4-normal). Hardware has been set to the default value (Unknown). Operating System has been set to the default value (Unknown). Bugzilla did not process this email because there were some errors with this submission. Please correct the following errors, or use our online interface at http://bugs.activestate.com. For more information on submitting bugs by email please see http://bugs.activestate.com/help.cgi. Bugzilla found the following errors (critical): Your email did not contain a required key: @product. Your email did not contain a required key: @version. Your email did not contain a required key: @component. Your email did not contain the required key: @product. Your email contained an invalid component: "Unknown".
[Bug bootstrap/16787] NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc
-- What|Removed |Added Keywords||documentation Last reconfirmed|2004-12-09 00:22:13 |2005-05-15 01:06:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16787
[Bug tree-optimization/1046] gcc less efficient than jdk for recursion!
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2005-01-05 02:24:56 |2005-05-15 01:05:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046
[Bug target/21551] [4.0 Regression] bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 01:03 --- FYI, I was comparing the assembly outputs from the SAME source with and without the patch mentioned. I will try to come up with a small testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug target/21551] [4.0 Regression] bootstrap failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 00:59 --- I would not doubt that CODE_FOR_insv changed also after his patch so that might not be it. -- What|Removed |Added CC||rth at gcc dot gnu dot org Keywords||build, ice-on-valid-code Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
Auslaender bevorzugt
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0305-14.html Jetzt weiss man auch, wie es dazu kommt, dass Drogen, Waffen & Handy's in die Haende der Knacki's gelangen!
[Bug libstdc++/21577] [3.4 Regression] libstdc++ testsuite broken
-- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Component|testsuite |libstdc++ Summary|libstdc++ testsuite broken |[3.4 Regression] libstdc++ ||testsuite broken Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21577
[Bug target/21551] [4.0 Regression] bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 00:12 --- This patch http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01151.html seems the cause. expmed.c compiled with the after compiler has .mii nop 0 (p6) addl r48 = @ltoffx(insn_data#+32768), r1 ;; nop 0 .mfb (p6) ld8.mov r48 = [r48], insn_data#+32768 .loc 1 638 0 nop 0 ... .loc 1 742 0 .mmi ld8 r14 = [r48] mov r54 = r38 mov r55 = r44 ;; .mmi adds r14 = 72, r14 ;; ld8 r8 = [r14] nop 0 ;; .mmi ld8 r14 = [r8], 8 ;; ld8 r1 = [r8] mov b6 = r14 .bbb nop 0 nop 0 br.call.sptk.many b0 = b6 for 740 /* If this machine's insv insists on a register, 741 get VALUE1 into a register. */ 742 if (! ((*insn_data[(int) CODE_FOR_insv].operand[3].predicate) 743 (value1, maxmode))) 744 value1 = force_reg (maxmode, value1) while the before compiler generates: .mmb addl r49 = @ltoffx(insn_data#+16384), r1 .loc 1 630 0 ld4 r39 = [r37] .loc 1 638 0 nop 0 .mmb cmp.ne p6, p7 = 39, r14 .loc 1 632 0 st4 [r37] = r15 .loc 1 638 0 (p7) br.cond.dpnt .L1908 ;; .mii ld8.mov r49 = [r49], insn_data#+16384 nop 0 ;; ... .loc 1 742 0 .mmi ld8 r14 = [r49] mov r54 = r38 mov r55 = r44 ;; .mmi adds r14 = 72, r14 ;; ld8 r8 = [r14] nop 0 ;; .mmi ld8 r14 = [r8], 8 ;; ld8 r1 = [r8] mov b6 = r14 .bbb nop 0 nop 0 br.call.sptk.many b0 = b6 The difference is "insn_data#+32768" vs. "insn_data#+16384". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug testsuite/21577] New: libstdc++ testsuite broken
Please see here for the details: http://gcc.gnu.org/ml/gcc/2005-05/msg00679.html Essentially, libstdc++ testsuite results are being lost because the `libstdc++.log' is being overwritten by `check-abi'. The regression is caused by this patch: 2005-05-12 Mark Mitchell <[EMAIL PROTECTED]> 2005-04-04 Mark Mitchell <[EMAIL PROTECTED]> * testsuite/Makefile.am (check-local): Remove. (curent_symbols.txt): Likewise. (check-abi): Do not depend on current_symbols.txt. * testsuite/Makefile.in: Regenerated. * testsuite/libstdc++-abi/abi.exp: Build current_symbols.txt. 2005-04-01 Mark Mitchell <[EMAIL PROTECTED]> * testsuite/Makefile.am (noinst_PROGRAMS): Remove. (site.exp): Write out the path to the baseline file. (check-abi): Use DejaGNU. (check-abi-verbose): Remove. * testsuite/Makefile.in: Regenerated. * testsuite/abi_check.cc (main): Check the return value from compare_symbols. * testsuite/testsuite_abi.cc (compare_symbols): Return a value. * testsuite/testsuite_abi.h (compare_symbols): Adjust prototype. * testsuite/libstdc++-abi/abi.exp: New file. 2004-03-19 Phil Edwards <[EMAIL PROTECTED]> * testsuite/Makefile.am (site.exp): New target, based on that created by automake. Also set libiconv. I'm not sure what the right fix is. Will try to investigate. -- Summary: libstdc++ testsuite broken Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gschafer at zip dot com dot au CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21577
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 23:05 --- *** Bug 21570 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||blime at cox dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug fortran/21570] Unformatted sequential read/write
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 23:05 --- This is a dup of bug 19303, see also: http://gcc.gnu.org/wiki/GfortranUnformattedSequentialIo *** This bug has been marked as a duplicate of 19303 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21570
[Bug tree-optimization/21576] FRE does not eliminate a redundant builtin call.
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-14
21:39 ---
Subject: Re: FRE does not eliminate a
redundant builtin call.
On Sat, 2005-05-14 at 21:30 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
> 21:30 ---
> Confirmed, here is another testcase (for -ffast-math):
> double cos (double);
> void link_error();
> void f(double a)
> {
> double b = cos (a);
> double c = cos (a);
> if (b!=c)
> link_error();
> }
>
Yes, we should make the result of a CONST call available, but don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
[Bug c++/19957] Exception with Tornado C++ on PowerPC target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 21:33 --- No feedback about a new compiler in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19957
[Bug c++/19947] __attribute__ ((__always_inline__)) fails for no apparent reason
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 21:32 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19947
[Bug tree-optimization/21576] FRE does not eliminate a redundant builtin call.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
21:30 ---
Confirmed, here is another testcase (for -ffast-math):
double cos (double);
void link_error();
void f(double a)
{
double b = cos (a);
double c = cos (a);
if (b!=c)
link_error();
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-14 21:30:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
[Bug c++/21575] definition member function of template class with nested class as return type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
21:24 ---
Invalid, you need the typename keyword, like so:
template
class foo {
public:
typedef T foo2;
foo2 bar();
};
template
typename foo::foo2 foo::bar() {
return foo2();
}
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21575
[Bug tree-optimization/21576] New: FRE does not eliminate a redundant builtin call.
Consider:
int
foo (unsigned long a)
{
int b = __builtin_clzl (a);
int c = __builtin_clzl (a);
if (b == c)
return 1;
return 0;
}
Here is what I get after FRE.
foo (a)
{
int c;
int b;
int D.1235;
:
b_3 = __builtin_clzl (a_2);
c_4 = __builtin_clzl (a_2);
if (b_3 == c_4) goto ; else goto ;
:;
D.1235_7 = 1;
goto ();
:;
D.1235_6 = 0;
# D.1235_1 = PHI <1(1), 0(2)>;
:;
return D.1235_1;
}
DOM catches this later.
--
Summary: FRE does not eliminate a redundant builtin call.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
[Bug c++/21575] New: definition member function of template class with nested class as return type
The following code generates a compiler error on the function definition.
Tested with
3.4.1 release
3.4.3 release
4.0.0 release
---
template
class foo {
public:
typedef T foo2;
foo2 bar();
};
template
foo::foo2 foo::bar() {
return foo2();
}
--
Summary: definition member function of template class with nested
class as return type
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wich at stack dot nl
CC: gcc-bugs at gcc dot gnu 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=21575
[Bug tree-optimization/21574] store_ccp doesn't see through a store.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 21:21 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-14 21:21:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21574
[Bug tree-optimization/21574] New: store_ccp doesn't see through a store.
Consider:
int
foo (int *p)
{
*p = 0;
return *p;
}
Here is what I get after store_ccp (with -fno-tree-dominator-opts)
foo (p)
{
int D.1233;
:
# TMT.0_5 = V_MAY_DEF ;
*p_1 = 0;
# VUSE ;
D.1233_2 = *p_1;
return D.1233_2;
}
Note that the return statement isn't changed to "return 0;".
--
Summary: store_ccp doesn't see through a store.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21574
[Bug libfortran/20930] [4.0 Regression] gfortran.dg/backspace.f execution test
--- Additional Comments From danglin at gcc dot gnu dot org 2005-05-14 20:58 --- See comment #9. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20930
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 20:58 --- *** Bug 20925 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug fortran/20925] "Possible frontend bug: array constructor not expanded"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 20:58 --- *** This bug has been marked as a duplicate of 19925 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20925
[Bug bootstrap/21556] [4.0/4.1 Regression] ia64-hpux bootstrap fails on mainline, TLS failures on 4.0 branch
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-14 20:53
---
I'm now running the C testsuite with the before-and-after stage1 compilers to
see if that shows up any problems.
On 4.0 branch the patch doesn't cause bootstrap failure but there are a number
of new testsuite failures, all -milp32 only, which might show up with a
cross-compiler and indicate the source of this or a related problem. All these
appeared between 20050512 and 20050514, and seem likely to be related to this
patch.
FAIL: g++.dg/tls/init-1.C (test for excess errors)
FAIL: gcc.dg/tls/nonpic-1.c (test for excess errors)
FAIL: gcc.dg/tls/opt-3.c (test for excess errors)
FAIL: gcc.dg/tls/opt-6.c (test for excess errors)
FAIL: gcc.dg/tls/opt-8.c (test for excess errors)
FAIL: gcc.dg/tls/pic-1.c (test for excess errors)
FAIL: gcc.dg/tls/struct-1.c (test for excess errors)
(Also note that gcc.dg/tls/opt-9.c still fails for -milp32 although it now
passes for -mlp64.)
4.0 branch failures:
/home/gcc/nightlies/src-4.0-2005-05-14/gcc-4.0-2005-05-14/gcc/testsuite/gcc.dg/tls/nonpic-1.c:
In function 'ae1':
/home/gcc/nightlies/src-4.0-2005-05-14/gcc-4.0-2005-05-14/gcc/testsuite/gcc.dg/tls/nonpic-1.c:12:
error: unrecognizable insn:
(insn 10 9 11 0 (set (reg:DI 341)
(unspec:DI [
(symbol_ref:SI ("e1") [flags 0x58] )
] 4)) -1 (nil)
(nil))
/home/gcc/nightlies/src-4.0-2005-05-14/gcc-4.0-2005-05-14/gcc/testsuite/gcc.dg/tls/nonpic-1.c:12:
internal compiler error: in extract_insn, at recog.c:2020
/home/gcc/nightlies/src-4.0-2005-05-14/gcc-4.0-2005-05-14/gcc/testsuite/gcc.dg/tls/opt-3.c:
In function 'foo':
/home/gcc/nightlies/src-4.0-2005-05-14/gcc-4.0-2005-05-14/gcc/testsuite/gcc.dg/tls/opt-3.c:10:
error: unrecognizable insn:
(insn 11 9 12 0 (set (reg:DI 340)
(unspec:DI [
(symbol_ref:SI ("i") [flags 0x48] )
] 5)) -1 (nil)
(nil))
/home/gcc/nightlies/src-4.0-2005-05-14/gcc-4.0-2005-05-14/gcc/testsuite/gcc.dg/tls/opt-3.c:10:
internal compiler error: in extract_insn, at recog.c:2020
and several more following the same pattern.
--
What|Removed |Added
Summary|[4.1 Regression] ia64-hpux |[4.0/4.1 Regression] ia64-
|bootstrap fails |hpux bootstrap fails on
||mainline, TLS failures on
||4.0 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 20:36 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug tree-optimization/21563] A trivial VRP opportunity missed
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 20:33 --- Just checked in a patch. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg01346.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21563
[Bug tree-optimization/21563] A trivial VRP opportunity missed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-14 20:33 --- Subject: Bug 21563 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-14 20:32:59 Modified files: gcc: ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr21563.c Log message: gcc/ PR tree-optimization/21563 * tree-vrp.c (compare_value): Return boolean_false_node when SSA_NAME in "if (SSA_NAME == CST)" is strictly smaller than or strictly larger than CST. testsuite/ PR tree-optimization/21563 * gcc.dg/tree-ssa/pr21563.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8786&r2=2.8787 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.17&r2=2.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5472&r2=1.5473 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21563.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21563
[Bug tree-optimization/21563] A trivial VRP opportunity missed
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-05-14 20:08 --- (In reply to comment #4) > (In reply to comment #3) > > > I will test and submit this patch after Diego submits his VRP revamp > > unless Diego heavily modifieis this part of VRP. > > > This is already in my current VRP changes, but go ahead and commit if it > passes > testing. > BTW, you don't need -fno-tree-dominator-opts in dg-options. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21563
[Bug middle-end/21566] trampolines + goto are broken
--- Additional Comments From oyvind dot harboe at zylin dot com 2005-05-14 20:07 --- I see. The goto acts like a longjmp in this context. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21566
[Bug tree-optimization/21563] A trivial VRP opportunity missed
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-05-14 20:06 --- (In reply to comment #3) > I will test and submit this patch after Diego submits his VRP revamp > unless Diego heavily modifieis this part of VRP. > This is already in my current VRP changes, but go ahead and commit if it passes testing. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21563
[Bug tree-optimization/21289] A numeric range is spoiled by a symblic one in VRP
--- Additional Comments From dnovillo at redhat dot com 2005-05-14 20:00 --- Subject: Re: A numeric range is spoiled by a symblic one in VRP On Sat, May 14, 2005 at 07:40:04PM -, kazu at cs dot umass dot edu wrote: > > --- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 > 19:40 --- > Another case of a numeric value range spoiled by a symbolic one: > Fixed with my current changes to VRP. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21289
[Bug tree-optimization/21289] A numeric range is spoiled by a symblic one in VRP
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 19:40
---
Another case of a numeric value range spoiled by a symbolic one:
int
foo (int a, int b)
{
if (a == 0)
return 0;
if (a == b)
if (a == 0)
return 123;
return 456;
}
Reduced from c-common.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21289
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Additional Comments From fw at deneb dot enyo dot de 2005-05-14 19:35
---
Subject: Re: 'Valid attribute on enumeration types with holes
* pinskia at gcc dot gnu dot org:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
> 19:09 ---
> It works for me on powerpc-darwin with "4.0.0 20050222".
I've looked at the trees generated by the following three-file test
case (in particular the tree dumps for bug2_p.adb), and they look
fine. Maybe it's an i386 back end issue.
-- Run through gnatchop
with Ada.Unchecked_Conversion;
with Ada.Text_IO; use Ada.Text_IO;
with Bug2_P; use Bug2_P;
procedure Bug2 is
function Convert is new Ada.Unchecked_Conversion (N, T);
begin
if V (Convert (0)) then
Put_Line ("FAIL");
else
Put_Line ("SUCCESS");
end if;
end Bug2;
package Bug2_P is
type T is (A, B, C, D);
for T'Size use 8;
for T use (A => 2, B => 3, C => 5, D => 7);
type N is mod 2**8;
function V (X : T) return Boolean;
end Bug2_P;
package body Bug2_P is
function V (X : T) return Boolean is
begin
return X'Valid;
end V;
end Bug2_P;
-- End
The i386 assembly code looks like this:
.type bug2_p__tRP, @function
bug2_p__tRP:
.LFB4:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$8, %esp
.LCFI2:
movb8(%ebp), %al
movb12(%ebp), %dl
cmpb$3, %al
je .L4
jb .L3
cmpb$5, %al
je .L5
cmpb$7, %al
je .L13
testb %dl, %dl
jne .L8
movl$-1, %eax
leave
ret
.p2align 4,,15
.L3:
xorl%eax, %eax
leave
ret
[...]
I'm not very good at reading AT&T syntax, but it appears that for a
first argument of 0, the branch to .L3 is taken, which returns 0
(instead of the expected -1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 19:09 --- It works for me on powerpc-darwin with "4.0.0 20050222". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Additional Comments From fw at deneb dot enyo dot de 2005-05-14 19:09 --- I should have mentioned that the N'Value business is solely designed to force a call to the Rep_To_Pos function for T (instead of evaluation of 'Valid at compile time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug ada/21573] New: 'Valid attribute on enumeration types with holes
The program below is expected to print "SUCCESS" (because 0 is not a valid value
of type T). However, at optimization level -O2 (on i686-pc-linux-gnu), it
prints "FAIL".
with Ada.Unchecked_Conversion;
with Ada.Text_IO; use Ada.Text_IO;
procedure Valid_Enumeration_Holes is
type T is (A, B, C, D);
for T'Size use 8;
for T use (A => 2, B => 3, C => 5, D => 7);
type N is mod 2**8;
function Convert is new Ada.Unchecked_Conversion (N, T);
begin
if Convert (N'Value ("0"))'Valid then
Put_Line ("FAIL");
else
Put_Line ("SUCCESS");
end if;
end Valid_Enumeration_Holes;
--
Summary: 'Valid attribute on enumeration types with holes
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs at gcc dot gnu 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=21573
[Bug middle-end/21566] trampolines + goto are broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 18:52 --- (In reply to comment #3) > Does this mean that you agree that an unexpected crash has been observed? No, it means I cannot reproduce what you got. My testcase works. Your testcase will always call abort. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21566
[Bug middle-end/21566] trampolines + goto are broken
--- Additional Comments From oyvind dot harboe at zylin dot com 2005-05-14 18:50 --- >This testcase will abort no matter what and and if change it to >something which will not abort all the time, it does not crash for me with - >march=i386. Does this mean that you agree that an unexpected crash has been observed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21566
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-14
18:28 ---
gimplify_expr calls fold_indirect_ref on *(char *)&ao.ch which happily folds
away the cast. Disabling fold_indirect_ref leaves the stripping to
STRIP_USELESS_TYPE_CONVERSION, so we end up with
const char * D.1237;
D.1237 = &ao.ch;
*D.1237 = 1;
resulting from gimplify_expr (
unit size
align 8 symtab 0 alias set -1 precision 8 min max
pointer_to_this >
unsigned SI
size
unit size
align 32 symtab 0 alias set -1>
readonly constant invariant
arg 0
unsigned SI size unit size
align 32 symtab 0 alias set -1
pointer_to_this >
readonly constant invariant
arg 0
readonly arg 0 arg 1 >>>
)
and tree_ssa_useless_type_conversion_1 tells us that the conversion from
unit size
align 8 symtab 0 alias set -1 precision 8 min max
pointer_to_this >
unsigned SI
size
constant invariant 32>
unit size constant invariant 4>
align 32 symtab 0 alias set -1
pointer_to_this >
to
unit size
align 8 symtab 0 alias set -1 precision 8 min max
pointer_to_this >
unsigned SI
size
constant invariant 32>
unit size constant invariant 4>
align 32 symtab 0 alias set -1>
is useless because c_types_compatible_p in turn thinks "char" and "const char"
are compatible because they share the same TYPE_MAIN_VARIANT "char".
So we finally strip the NOP_EXPR doing the cast to char* from const char*.
If we disable that part of tree_ssa_useless_type_conversion_1, we don't ICE
any longer, but alias1 still does not insert V_MAY_DEFs here and dce1 finally
deletes the store. Which may be a valid optimization; .t17.alias1:
test1 ()
{
char * D.1237;
:
D.1237_1 = (char *) &ao.ch;
# VUSE ;
*D.1237_1 = 1;
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 18:14 --- *** Bug 21572 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ismail at kde dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
[Bug middle-end/21572] STL warnings/errors are impossible to understand
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 18:14 --- This is a warning about dead code really, the problem comes from -fno-exceptions and try/catch being defined as "if (true)" and "else if (false)". *** This bug has been marked as a duplicate of 19699 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|libstdc++ |middle-end Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21572
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-14
17:51 ---
A little more simplification:
typedef struct { char ch; } pstr;
const pstr ao = { 'O' };
void test1(void)
{
*((char *)&ao.ch) = 1;
}
.02.original:
*(char *) &ao.ch = 1;
.02.gimple:
ao.ch = 1;
which doesn't have the PLUS_EXPR but ends up with a modify expr
that has a const lhs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug libstdc++/21572] New: STL warnings/errors are impossible to understand
STL warnings/errors in gcc was always a mess but with gcc4 I see they are now really impossible to understand. Here is an excerpt : 90% compiling /opt/development/kde/KDE/kdepim/certmanager/lib/kleo/multideletejob.cpp /usr/lib/gcc/x86_64-linux/4.0.1/../../../../include/c++/4.0.1/bits/vector.tcc: In member function ‘std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = GpgME::Key, _Alloc = std::allocator]’: /usr/lib/gcc/x86_64-linux/4.0.1/../../../../include/c++/4.0.1/bits/vector.tcc:141: warning: control may reach end of non-void function ‘typename _Alloc::pointer std::vector<_Tp, _Alloc>::_M_allocate_and_copy(size_t, _ForwardIterator, _ForwardIterator) [with _ForwardIterator = __gnu_cxx::__normal_iterator > >, _Tp = GpgME::Key, _Alloc = std::allocator]’ being inlined /usr/lib/gcc/x86_64-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_uninitialized.h:113: warning: control may reach end of non-void function ‘_ForwardIterator std::__uninitialized_copy_aux(_InputIterator, _InputIterator, _ForwardIterator, __false_type) [with _InputIterator = __gnu_cxx::__normal_iterator > >, _ForwardIterator = GpgME::Key*]’ being inlined As you can see in the warning I can't see which function is problematic. I only see references to STL headers installed by gcc which is useless. -- Summary: STL warnings/errors are impossible to understand Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at kde dot org dot tr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21572
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
17:06 ---
I don't think full specializations are not allowed in side classes but I don't
have my copy of the standard
in front of me.
Also note ICC also rejects this code:
t.cc(28): error: class "container::iterator" cannot be
specialized in the current scope
template<> struct iterator: wrapper {};
^
t.cc(31): error: argument list for class template "heap" is missing
heap::iterator p;
^
t.cc(31): error: incomplete type is not allowed
heap::iterator p;
^
compilation aborted for t.cc (code 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug middle-end/21566] trampolines + goto are broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
17:02 ---
This testcase will abort no matter what and and if change it to something which
will not abort all the
time, it does not crash for me with -march=i386.
Here is the testcase I used:
extern void abort (void);
extern void exit (int);
#ifndef NO_TRAMPOLINES
void test(void (*t)(void))
{
int i;
for (i=0; i<10; i++)
{
t();
}
}
static void recursive (int n, void (*proc) (void))
{
__label__ l1;
int skip=0xdeadbeef;
void do_goto (void)
{
goto l1;
}
test(do_goto);
skip=0;
if (n == 3)
recursive (n - 1, do_goto);
else if (n > 0)
recursive (n - 1, proc);
else
(*proc) ();
return;
l1:
if (skip==0xdeadbeef)
{
if (n == 3)
exit (0);
else
abort ();
}
}
int main ()
{
recursive (3, abort);
abort ();
}
#else
int main () { return 0; }
#endif
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21566
[Bug target/21571] New: ICE in rs6000.c with -msdata=default.
[EMAIL PROTECTED] cat test.cc
double zero;
void foo() { zero = 0; }
[EMAIL PROTECTED] ppc-eabi-gcc -c test.cc
[EMAIL PROTECTED] ppc-eabi-gcc -v -msdata=default -c test.cc
Using built-in specs.
Target: ppc-eabi
Configured with: ../../gcc/configure --prefix=/home/osv/try/ppc-rtems/tools
--target=ppc-eabi --disable-haifa --disable-newlib-hw-fp --with-gnu-as
--with-gnu-ld -with-newlib --with-cpu=505
Thread model: single
gcc version 4.0.1 20050513 (prerelease)
/home/osv/try/ppc-rtems/tools/libexec/gcc/ppc-eabi/4.0.1/cc1plus -quiet -v
test.cc -quiet -dumpbase test.cc -msdata=default -mcpu=505 -auxbase test
-version -o /tmp/cc4MGHes.s
ignoring nonexistent directory
"/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.0.1/../../../../ppc-eabi/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.0.1/../../../../include/c++/4.0.1
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.0.1/../../../../include/c++/4.0.1/ppc-eabi
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.0.1/../../../../include/c++/4.0.1/backward
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.0.1/include
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.0.1/../../../../ppc-eabi/include
End of search list.
GNU C++ version 4.0.1 20050513 (prerelease) (ppc-eabi)
compiled by GNU C version 2.95.4 20011002 (Debian prerelease).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64501
test.cc: In function 'void foo()':
test.cc:2: internal compiler error: in find_addr_reg, at
config/rs6000/rs6000.c:17603
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED]
--
Summary: ICE in rs6000.c with -msdata=default.
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: osv at javad dot ru
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-14 16:48 --- actually trees look like 3845 ret = gimplify_modify_expr (expr_p, pre_p, post_p, Value returned is $3 = GS_ALL_DONE (gdb) call debug_tree(*expr_p) unit size align 8 symtab 0 alias set -1 precision 8 min max pointer_to_this > unsigned SI size unit size align 32 symtab 0 alias set -1> side-effects arg 0 used unsigned ignored SI file 20031215-1.c line 12 size unit size align 32 context > arg 1 constant invariant arg 0 constant invariant arg 0 arg 0 readonly arg 0 arg 1 > arg 1 arg 2 arg 3 >> arg 1 > 20031215-1.c:12> which is mismatched types for the PLUS_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug middle-end/21538] [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 16:46 --- (In reply to comment #5) > It looks like fold_indirect_ref is not supposed to be used as a generic > folder, > but explicitly to strip these const casts. So the bug I tried to fix with > this > has to be fixed elsewhere!? Note I don't believe that is true, but this is why having no real type system and just making it up as we go is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-14
16:45 ---
Reduced testcase:
typedef struct { char ch[3]; } pstr;
const pstr ao = { "OK" };
const pstr * const a = &ao;
void test1(void)
{
((char *)a->ch)[2] = 0;
}
aliasing chokes on gimplification stripping 02.original
*((char *) (const char *) &ao.ch + 2B) = 0;
down to 03.gimple
char * D.1238;
D.1238 = &ao.ch[0] + 2B;
*D.1238 = 0;
which has "confused" types for the rhs of
D.1238 = &ao.ch[0] + 2B;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug tree-optimization/21569] write to const variable ignored at -O[12]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 16:43 --- This is undefined, as shown by this would fail at runtime. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21569
[Bug fortran/21570] Unformatted sequential read/write
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 16:34 --- Is this with a 64bit target? I don't think we should consider this a bug because binary files are never portable between targets. -- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21570
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 16:32 --- This is undefined, see the full discussion on the gcc list: http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html -- What|Removed |Added Summary|[3.4 regression] Casts in |[4.0/4.1 regression] Casts |folding *& omitted |in folding *& omitted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug translation/21567] Segmentation fault of the compiler when compiling
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 16:30 --- I want to say this is a translation bug. -- What|Removed |Added Component|tree-optimization |translation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21567
[Bug other/18508] [3.4/4.0 Regression] "basename: too few arguments" when building without bootstrap
--- Additional Comments From dank at kegel dot com 2005-05-14 16:30 --- On Cygwin, the symptoms may be slightly different. Here's a snippet of a build log from Petr Cvachoucek: basename: missing operand Try `basename --help' for more information. mv: `libgcc_s_nof.so.1' and `libgcc_s_nof.so.1.' are the same file make[2]: *** [nof/libgcc_s_nof.so] Error 1 (Yep, Cygwin considers foo and foo. to be the same file.) I only mention this for completeness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18508
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-05-14 16:06 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On Sat, May 14, 2005 at 08:14:48AM -, corsepiu at gcc dot gnu dot org wrote: > > Free free to hang on closely to standards ... to me, this sounds as being > stubborn and non-helpful to the fortran community, nor to GCC nor to embedded > systems. I'd prefer GCC to hang on to practical demands and implications > stemming from practice instead of being religious about standards ignoring > practical implications. > Dealing with vendor extensions are one of the top topic on comp.lang.fortran. gfortran currently implements about 90-95% of the standardize language. Those of us who actively work on gfortran will probably use our time to implement Fortran not some vendor extension that less than 0.01% of gfortran users need. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21570] New: Unformatted sequential read/write
A binary file (created with a program compiled with g77) being read by a program compiled using 4.0.0 gfortran produces the following: "Fortran runtime error: Corrupt unformatted sequential file" -- Summary: Unformatted sequential read/write Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P1 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: blime at cox dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21570
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-05-14 15:57 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On Sat, May 14, 2005 at 03:25:17PM -, Tobias dot Schlueter at physik dot uni-muenchen dot de wrote: > > Fortran requires that there be a floating point type (DOUBLE PRECISION) which > takes twice the space of the usual REAL variables. It should probably be > possible to use gfortran on platforms which don't have this, but given the > amount of Fortran code that is tied to this assumption, I don't think this > would be worthwhile. E.g. COMMON block layout depends crucially on this. > Yep. We can't forget about our friend EQUIVALENCE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug middle-end/21538] [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-14 15:42 --- It looks like fold_indirect_ref is not supposed to be used as a generic folder, but explicitly to strip these const casts. So the bug I tried to fix with this has to be fixed elsewhere!? Reverted from mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-14 15:25 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 Quoting corsepiu at gcc dot gnu dot org <[EMAIL PROTECTED]>: > As I tried to express before, I think this PR actually trips several bugs at > once. > > * A bug in error f95's handling, which probably causes the seg fault. The > compiler simply must not seg fault. Exactly, I assume this has to do with the fact that we're trying to initialize a zero-length parameter array, which is somewhat unusual, and thus probably not well-tested and buggy. I won't have access to my box, but if someone has a few spare minutes, I'd suggest he tries this code: INTEGER, PARAMETER :: i(0) = (/ /) or, if this doesn't break, TYPE a INTEGER i END TYPE a TYPE(a), PARAMETER :: i(0) = (/ /) I'm fairly sure that this will give the same segfault Ralf is seeing. > * A configuration problem: The configure scripts should be able to detect if > a > target doesn't meet its expectations. While this is true, this is not necessarily a compile-time problem. the mapping between the compiler's internal types and Fortran types is made at execution time of the compiler. > * f95 disqualifies ifselves from several embedded targets, if it can not be > built/used on targets not supporting REAL8. IIRC, there even exist variants > of > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > IMO, this is a design flaw, which should be in your interest to be > circumvented. Fortran requires that there be a floating point type (DOUBLE PRECISION) which takes twice the space of the usual REAL variables. It should probably be possible to use gfortran on platforms which don't have this, but given the amount of Fortran code that is tied to this assumption, I don't think this would be worthwhile. E.g. COMMON block layout depends crucially on this. But the bug we're dealing with has to do with INTEGER kinds, once we've cleared the issues WRT those, we can have this discussion again. Unless everything unxepectedly works out of the box :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug tree-optimization/21569] New: write to const variable ignored at -O[12]
const int i=0;
int foo(void)
{
*(int *)&i = 1;
return i;
}
with -O0 gcc returns 1, with -O1 and up it returns 0.
Is this a valid store to i? If not, why doesn't gcc warn
even at -Wall?
--
Summary: write to const variable ignored at -O[12]
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21569
[Bug tree-optimization/21568] New: [3.4 regression] Casts in folding *& omitted
For the testcase
int x;
int foo(void)
{
x = 0;
return *(volatile int *)&x;
}
the tree-optimizers omit the volatile cast and cprop 0 to the
return statement which is invalid. This is a regression from
3.4 where we produced (with -O)
foo:
pushl %ebp
movl%esp, %ebp
movl$0, x
movlx, %eax
popl%ebp
ret
and now
foo:
pushl %ebp
movl%esp, %ebp
movl$0, x
movl$0, %eax
popl%ebp
ret
--
Summary: [3.4 regression] Casts in folding *& omitted
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug c++/21312] [3.4/4.0/4.1 Regression] Access violation diagnostic given twice
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-14 12:00 --- Patch for 4.1 submitted: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01322.html It requires another patch from me: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01320.html Won't fix in 3.4. A stripped down version is possible for 4.0 (adding ACCESS tree node, only used in enforce_access and not in semantics.c and parser.c). -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
[Bug tree-optimization/21567] Segmentation fault of the compiler when compiling
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-05-14 11:46 --- Please attach preprocessed testcase, see http://gcc.gnu.org/bugs.html#need for details. Also please try recent snapshot of 4.0 ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050507/ -- What|Removed |Added Component|c |tree-optimization GCC build triplet|i686-pc-linux | GCC host triplet|i686-pc-linux | Keywords||ice-on-valid-code Summary|Segmentation fault of the |Segmentation fault of the |compiler when compiling |compiler when compiling http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21567
[Bug c/21567] New: Segmentation fault of the compiler when compiling
The compiler get's a segmentation fault on this one :)
The compiler 4.0.0 was configurated with --enable-languages=c,c++,java
--enable-shared --enable-threads=posix --with-cpu=i686 and built with make
CFLAGS='-O' LIBCFLAGS='-g -O2' \
LIBCXXFLAGS='-g -O2 -fno-implicit-templates' profiledbootstrap
aie_sql_meta.c: In Funktion aie_sql_meta_create_indexซ:
aie_sql_meta.c:23: interner Compiler-Fehler: Segmentation fault
#include
#include
#include
// reduced Testcase
// compiled with
// gcc -Wall -O3 aie_sql_meta.c
// Alexander J. Herrmann 13.05.2005 [EMAIL PROTECTED]
typedef int bool;
bool aie_sql_meta_create_index(void);
void aie_sql_meta_get_index_def_from_id(int indexid, int *tableid,
int *index_typ);
int main(void)
{
aie_sql_meta_create_index();
return(0);
}
bool aie_sql_meta_create_index(void)
{
bool rc = 1;
int tableid; // Never gets initialized
int index_typ = 1;
int indexid = 0;
aie_sql_meta_get_index_def_from_id(indexid, &tableid, &index_typ);
if (__builtin_expect(((index_typ) || (tableid <= 0)),0))
{
// error variables not set but also not used
rc = 0;
}
else
{
// tableid was never initialized
printf("%d %d\n", tableid, index_typ);
}
return(rc);
}
void aie_sql_meta_get_index_def_from_id(int indexid, int *tableid,
int *index_typ)
{
if (indexid == 1)
{
// the Good case
*tableid = 1;
*index_typ = 0;
}
else
{
*index_typ = 0;
}
}
--
Summary: Segmentation fault of the compiler when compiling
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexander_herrmann at yahoo dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21567
[Bug c/21566] trampolines + goto are broken
--- Additional Comments From oyvind dot harboe at zylin dot com 2005-05-14 10:03 --- Created an attachment (id=8889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8889&action=view) Testcase that crashes w/GCC 4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21566
[Bug c/21566] New: trampolines + goto are broken
Attached is a slight variation of the nestedfunc-5.c testecase that crashes w/GCC i386 4.0 -- Summary: trampolines + goto are broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oyvind dot harboe at zylin dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21566
[Bug fortran/21565] New: namelist in block data is illegal
gfortran falsely accepts a namelist in a block data: $ cat block_d.f block data common /foo/ a namelist /foo_n/ a data a /1.0/ end $ gfortran -S block_d.f $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050508 (experimental) g77 correctly rejects it, although with a confusing error message: $ g77 -S block_d.f block_d.f: In block-data unit `_BLOCK_DATA__': block_d.f:2: common /foo/ a 1 block_d.f:3: (continued): namelist /foo_n/ a 2 Statement at (2) invalid in context established by statement at (1) -- Summary: namelist in block data is illegal Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21565
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-14 08:37 --- After reflection I changed the subject. While template declaration and partial specialization is possible inside a class, the full specialzation is not. -- What|Removed |Added Summary|Templates and sub types are |Full specialization of |not inherited in g++|templates not supported in ||classes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 08:33 --- (In reply to comment #16) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > > On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > > > * f95 disqualifies ifselves from several embedded targets, if it can > > not be > > built/used on targets not supporting REAL8. IIRC, there even exist > > variants of > > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > > IMO, this is a design flaw, which should be in your interest to be > > circumvented. > > Huh, PPC soft float supports REAL 8 still. Joel, do you recall the target in RTEMS which has 4-byte floats only? (We recently had an issue with it floating point context sizes related to it? IIRC, it had been a powerpc variant and we were forced to drop it because GCC doesn't support it. BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't have 8byte floats. RTEMS doesn't support them, so I've never tried to build fortran for then. -- What|Removed |Added CC||joel at oarcorp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 08:14 --- (In reply to comment #17) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > > On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > > > * f95 disqualifies ifselves from several embedded targets, if it can > > not be > > built/used on targets not supporting REAL8. IIRC, there even exist > > variants of > > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > > IMO, this is a design flaw, which should be in your interest to be > > circumvented. > > > Also this is fortran requirement so technically it is not a design flaw > in gfortran but in the standard, I would complain to them instead of to > GCC about this. Yes we could circumvent this but that would be an extension. Free free to hang on closely to standards ... to me, this sounds as being stubborn and non-helpful to the fortran community, nor to GCC nor to embedded systems. I'd prefer GCC to hang on to practical demands and implications stemming from practice instead of being religious about standards ignoring practical implications. > And who would be using fortran for embedded targets anyways. Consider numerical applications on embedded systems using fortran libraries (image processing, control applications etc.) IMO, this is a hen-and-egg problem. Hardly anybody is using fortran on embedded targets because the language is not available for many targets, and it is not available for many targets, because the language is not able to support them/is too non-portable. In this particular case, I fail to understand why REAL8 must be available and I fail to understand why this type can't be made conditionally available. > g77 had the same issue until at least a 3.3 (or so) was released so having it > not fixed for a long time which was about 4 releases after the first official > GCC with g77 support (2.95). Well, you know, gcc-4.0.0 is a major GCC release, gfortran is new ... All this had caused me to have a look at known weeknesses in GCC. The result (not limited to fortran) esp. wrt. embedded targets, is pretty disillusioning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug bootstrap/21481] [4.1 Regression] Bootstrap is broken of FreeBSD by changes to crtstuff.c
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21481
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-14 07:08 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > * f95 disqualifies ifselves from several embedded targets, if it can > not be > built/used on targets not supporting REAL8. IIRC, there even exist > variants of > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > IMO, this is a design flaw, which should be in your interest to be > circumvented. Also this is fortran requirement so technically it is not a design flaw in gfortran but in the standard, I would complain to them instead of to GCC about this. Yes we could circumvent this but that would be an extension. And who would be using fortran for embedded targets anyways. g77 had the same issue until at least a 3.3 (or so) was released so having it not fixed for a long time which was about 4 releases after the first official GCC with g77 support (2.95). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
Re: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: * f95 disqualifies ifselves from several embedded targets, if it can not be built/used on targets not supporting REAL8. IIRC, there even exist variants of major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. IMO, this is a design flaw, which should be in your interest to be circumvented. Also this is fortran requirement so technically it is not a design flaw in gfortran but in the standard, I would complain to them instead of to GCC about this. Yes we could circumvent this but that would be an extension. And who would be using fortran for embedded targets anyways. g77 had the same issue until at least a 3.3 (or so) was released so having it not fixed for a long time which was about 4 releases after the first official GCC with g77 support (2.95). -- Pinski
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-14 07:04 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > * f95 disqualifies ifselves from several embedded targets, if it can > not be > built/used on targets not supporting REAL8. IIRC, there even exist > variants of > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > IMO, this is a design flaw, which should be in your interest to be > circumvented. Huh, PPC soft float supports REAL 8 still. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
Re: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: * f95 disqualifies ifselves from several embedded targets, if it can not be built/used on targets not supporting REAL8. IIRC, there even exist variants of major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. IMO, this is a design flaw, which should be in your interest to be circumvented. Huh, PPC soft float supports REAL 8 still. -- Pinski
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 07:00 --- (In reply to comment #13) > I'll try again this weekend with the version of GMP on the laptop > and update GMP if it still fails. If you go to the GMP home page > there is a VERY big warning about problems with gcc 4.0. > > In looking over the history of this PR, comment #2 through me off > track because Fortran cannot be installed on a system with only a > single REAL kind. As I tried to express before, I think this PR actually trips several bugs at once. * A bug in error f95's handling, which probably causes the seg fault. The compiler simply must not seg fault. * A configuration problem: The configure scripts should be able to detect if a target doesn't meet its expectations. * f95 disqualifies ifselves from several embedded targets, if it can not be built/used on targets not supporting REAL8. IIRC, there even exist variants of major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. IMO, this is a design flaw, which should be in your interest to be circumvented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
