[Bug fortran/30625] Array pointers to components of derived type arrays do not work
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-11 09:52 ---
(In reply to comment #6)
> Paul, I take it you are aware of PR21881 ("Array descriptors limit derived
> type
> sizes")... I don't fully grasp the way array descriptor work for derived
> types,
> but I wanted to mention that PR to you... just in case.
>
FX, I was aware of the problem but not of the PR; I'll be honest if I say tha I
am not sure that the size limit on derived types is an issue. After all,
pointers or allocatable components can be used to keep the size of the derived
type down.
I think that I need to sketch out a design and post it on the list; it'll have
to be CC'd to Paul Brooks and Steven Bosscher because they are responsible for
the present layout of descriptors. They maybe have opinions about how to
proceed.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug fortran/30660] [4.2 and 4.1 only] Allocatable components of a derived type "require" the SAVE attribute.
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-11 09:56 --- Toon, This is the next job on my list - I have an opportunity to work on it tonight. I have a patch that mostly works but does something very peculiar for a couple of the testcase - the compiler just stops; no errors; no ICE; nothing; niente Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug rtl-optimization/30761] New: [4.3 regression] Error: unsupported relocation against sfp
This is caused by the lower-subreg patch (adding -fno-split-wide-types is a workaround): $ ../../xgcc -B../../ -c -O2 -fno-common -gnatpg -gnata -I- -I../rts -I. -I ../../../../gcc/ada ../../../../gcc/ada/make.adb -c /tmp/ccXcjvZm.s: Assembler messages: /tmp/ccXcjvZm.s:6958: Error: unsupported relocation against sfp $ grep sfp make.s mr 21,sfp -- Summary: [4.3 regression] Error: unsupported relocation against sfp Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code, build Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: powerpc-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug c/30762] New: inlining destroys type information
$ gcc-4.2.orig-HEAD -Os -c double-int.i tree-ssa-loop-niter.i -o libbackend.o -combine tree-ssa-loop-niter.i: In function 'derive_constant_upper_bound': tree-ssa-loop-niter.i:28: error: incompatible type for argument 1 of 'double_int_negative_p' where gcc-4.2.orig-HEAD is a pristine checkout from: gcc version 4.2.0 20070204 (prerelease) Turning off inlining via -fno-inline makes it work again. -- Summary: inlining destroys type information Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: rejects-valid, diagnostic, build Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] inlining destroys type information
--- Comment #1 from aldot at gcc dot gnu dot org 2007-02-11 10:24 --- Created an attachment (id=13031) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13031&action=view) reduced from gcc/double-int.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] inlining destroys type information
--- Comment #2 from aldot at gcc dot gnu dot org 2007-02-11 10:24 --- Created an attachment (id=13032) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13032&action=view) reduced from tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] inlining destroys type information
--- Comment #3 from aldot at gcc dot gnu dot org 2007-02-11 10:26 --- May be related to 29478 according to apinski. This one blocks compilation rather than just generating an unpleasant warning, tough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] [4.2 Regression] inlining destroys type information
--- Comment #4 from aldot at gcc dot gnu dot org 2007-02-11 10:28 --- Works with gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.1.2 Summary|inlining destroys type |[4.2 Regression] inlining |information |destroys type information http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug rtl-optimization/30761] [4.1/4.2/4.3 regression] Error: unsupported relocation against sfp
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-11 10:31 --- Actually this has nothing to do with -fsplit-wide-types, This shows up in some cases without that, There is a reload patch floating about which fixes this. The problem is that reload does not elimate the soft frame pointer. In fact this is really a regression in 4.1.0 exposed by: 2005-06-30 Jakub Jelinek <[EMAIL PROTECTED]> * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTER): Increment. (DWARF_FRAME_REGISTERS, DWARF_REG_TO_UNWIND_COLUMN): Adjust, so that addition of sfp doesn't change these. (FIXED_REGISTERS, CALL_USED_REGISTERS, CALL_REALLY_USED_REGISTERS, I actually saw it in a modified version of 4.1.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc-suse-linux |powerpc*-*-* Summary|[4.3 regression] Error: |[4.1/4.2/4.3 regression] |unsupported relocation |Error: unsupported |against sfp |relocation against sfp Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug rtl-optimization/30761] [4.1/4.2/4.3 regression] Error: unsupported relocation against sfp
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-11 10:47 --- (In reply to comment #1) > I actually saw it in a modified version of 4.1.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||28690 nThis|| Keywords||link-failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug libfortran/15516] assembly snippets for nano second resolution wall clock time
--- Comment #2 from jv244 at cam dot ac dot uk 2007-02-11 10:55 --- (In reply to comment #0) > If you extract the object > file get_clockfreq.o from /usr/lib/librt.a then you can call the function > __get_clockfreq() to determine clock frequency. To extract the routine, try: > > ar xv /usr/lib/librt.a get_clockfreq.o > > To use the routines as timers, you can use the following routine. Call it > before > and after the section of code you want to time and the difference will be the > elapsed time. Be sure to include the appropriate routine from above. is this comment about get_clockfreq.o actually correct ? I find it returns different values depending on the load of the machine (I guess this is frequency rescaling at work, i.e.): 46799775 159600 0.029323167293233084 46703250 159600 0.029262687969924813 40773807 159600 0.02554749812030075 34589439 239400 0.014448387218045113 33201315 159600 0.020802828947368422 34758144 239400 0.014518857142857142 33325110 159600 0.020880394736842105 34576236 239400 0.014442872180451127 where the first number is the ticks as returned by differences of nanotime_ia32, and the second the number returned by get_clockfreq, the third is the estimated time if seconds (quite random, since it is allways the same matrix multiply). (an unrelated issue is that it wraps pretty quicky...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15516
[Bug c/30762] [4.2 Regression] inlining destroys type information
--- Comment #5 from aldot at gcc dot gnu dot org 2007-02-11 11:05 --- Created an attachment (id=13033) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13033&action=view) smaller testcase for the tree-ssa-loop-niter part -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #13032|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c++/30534] [4.3 regression] ICE with invalid template argument
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-02-11 11:39 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30534
[Bug c/30762] [4.2 Regression] inlining destroys type information
--- Comment #6 from aldot at gcc dot gnu dot org 2007-02-11 11:57 --- Created an attachment (id=13034) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13034&action=view) minimal testcase file 1 -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #13031|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] [4.2 Regression] inlining destroys type information
--- Comment #7 from aldot at gcc dot gnu dot org 2007-02-11 11:58 --- Created an attachment (id=13035) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13035&action=view) minimal testcase file 2 -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #13033|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] [4.2/4.3 Regression] inlining destroys type information
--- Comment #8 from aldot at gcc dot gnu dot org 2007-02-11 11:59 --- Fails to merge type information from different TUs? -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 |4.2.0 4.3.0 Summary|[4.2 Regression] inlining |[4.2/4.3 Regression] |destroys type information |inlining destroys type ||information http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c++/30763] New: problem with bit-fields assignment
Test case:
#include
#define INT_INVALID -1
class Test
{
int b : 16;
int a;
int c : 16;
public:
Test()
{
b = a = c = INT_INVALID;
//a = b = c = INT_INVALID;
}
void dump()const
{
printf("a: %d\tb: %d\tc: %d\n",a,b,c);
}
};
int main()
{
Test a;
a.dump();
return 0;
}
g++-4.1 main.cpp
./a.out
a: 65535b: -1 c: -1
g++-4.0 main.cpp
a: -1 b: -1 c: -1
It seems like regression in GCC-4.1.1 and 4.1.2(on GCC-4.1.0 and earlier
I've got correct results)
--
Summary: problem with bit-fields assignment
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vovanec at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30763
[Bug c++/30763] problem with bit-fields assignment
--- Comment #1 from vovanec at gmail dot com 2007-02-11 13:20 --- When order of assignment has changed (a = b = c = INT_INVALID;) test case returns correct values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30763
[Bug fortran/30764] New: GFortran ICE if real constants in module
GFortran on Fedora Core 6 (gcc-gfortran-4.1.1-51.fc6) can't compile module
files that contain real constants ("parameter" attribute).
Example: Module file "const.f90":
module const
real, parameter :: a=3.5
end module const
Compile command "gfortran -c const.f90" leads to ICE:
const.f90:0: internal compiler error: Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: GFortran ICE if real constants in module
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: engel at itp1 dot uni-stuttgart dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30764
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-11 14:46 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) > A patch for this bug has been added to the patch tracker. > The mailing list url for the patch is > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00933.html Works for me: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00430.html Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-11 14:49 --- Subject: Re: [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type > > > With the above patch, the problem still exists but it's moved to a > > > different file: > > > > > > /usr/ccs/bin/ld: CODE_ONE_SYM fixup to non-code subspace in file > > > gnu/javax/swing > > > /text/html/parser/.libs/HTML_401F.o - shared library must be position > > > independen > > > t. Use +z or +Z to recompile. > > > > > > > Please try with revision 121506 or later. That may fix this problem. The above problem is a target bug (incorrect code is being generated for long indirect and millicode calls). The library now contains some modules that need long calls. Working on a patch to fix this. David Daney's patch fixed the original problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug fortran/30764] GFortran ICE if real constants in module
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-02-11 16:52 --- This works OK on gfortran 4.3. and on my FC6 install: $ gfortran -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) $ gfortran -c hang.f90 Maybe a problem on i686? installation problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30764
[Bug middle-end/30751] [4.3 Regression] internal compiler error: in extract_insn, at recog.c:2108
--- Comment #1 from ian at airs dot com 2007-02-11 16:55 --- This works for me on sparc-sun-solaris2.10 at svn revision 121803. I don't have access to a SPARC GNU/Linux system. Which exact sources are you building? Do you have any local patches? How did you run configure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30751
[Bug fortran/30764] GFortran ICE if real constants in module
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-11 17:42 --- We don't support binaries from redhat. You might as well report this bug to them instead. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30764
[Bug fortran/30764] GFortran ICE if real constants in module
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-11 17:43 --- Works for me with these compilers: GNU Fortran 95 (GCC) 4.3.0 20070130 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. troutmask:sgk[209] gfc42 --version GNU Fortran 95 (GCC) 4.2.0 20070126 (prerelease) Copyright (C) 2006 Free Software Foundation, Inc. troutmask:sgk[210] gfc41 --version GNU Fortran 95 (GCC) 4.1.2 20070127 (prerelease) Install the binary version of gfortran from the wiki, and contact your vendor to update its copy of gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30764
[Bug fortran/30764] GFortran ICE if real constants in module
--- Comment #2 from engel at itp1 dot uni-stuttgart dot de 2007-02-11 17:40 --- (In reply to comment #1) > This works OK on gfortran 4.3. > > and on my FC6 install: > > $ gfortran -v > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-libgcj-multifile > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk > --disable-dssi --enable-plugin > --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic > --host=x86_64-redhat-linux > Thread model: posix > gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) > $ gfortran -c hang.f90 > > Maybe a problem on i686? installation problem? > Maybe. I have tested the gfortran problem on 24 computers (all 32 bit): I get an ICE on all AMD and Pentium III processors, but gfortran is compiling correctly on the Pentium 4 and Pentium D processor machines. The funny thing is, that the P4 compiled code is running on the AMD and PIII processors very well. gfortran -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) -- engel at itp1 dot uni-stuttgart dot de changed: What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30764
[Bug c++/30763] problem with bit-fields assignment
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-11 18:20 --- Confirmed, but I remember seeing this elsewhere so it must be a dup. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-11 18:20:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30763
[Bug c++/30763] problem with bit-fields assignment
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|linux-i386 | Keywords||wrong-code Known to work||4.1.0 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30763
[Bug c++/30763] problem with bit-fields assignment
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-11 18:27 --- This works for me in 4.3.0: .[pinskia-laptop:gcc/objdir-noboot/gcc] pinskia% ./a.out a: -1 b: -1 c: -1 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.0 |4.3.0 Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30763
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #44 from mmitchel at gcc dot gnu dot org 2007-02-11 18:58 --- Subject: Bug 29487 Author: mmitchel Date: Sun Feb 11 18:58:05 2007 New Revision: 121819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121819 Log: PR target/29487 * tree.h (DECL_REPLACEABLE_P): New macro. * except.c (set_nothrow_function_flags): Likewise. PR target/29487 * decl.c (finish_function): Use DECL_REPLACEABLE. * tree.c (cp_cannot_inline_tree_fn): Likewise. PR c++/29487 * g++.dg/eh/weak1-C: New test. * g++.dg/eh/weak1-a.cc: Likewise. * g++.dg/eh/comdat1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/eh/comdat1.C trunk/gcc/testsuite/g++.dg/eh/weak1-a.cc trunk/gcc/testsuite/g++.dg/eh/weak1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/tree.c trunk/gcc/except.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug middle-end/30761] [4.1/4.2/4.3 regression] Error: unsupported relocation against sfp
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-11 19:12 --- > This is caused by the lower-subreg patch Exposed by, not caused by in this case. It exposed an issue with reload and register elimination which was originally exposed by Jakub's patch. I was able to reproduce the problem on a heavely modified version of 4.1.1 so I know the bug is there also. See the patch at: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00992.html Which should fix the problem. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|rtl-optimization|middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-11 19:12:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #45 from mmitchel at gcc dot gnu dot org 2007-02-11 19:20 --- Fixed in 4.2.0, mainline. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/27500] iWMMXT bootstrap failure with recent binutils
--- Comment #3 from s_j_newbury at yahoo dot co dot uk 2007-02-11 19:34 --- The problem is resolved in current binutils/gcc so marking as FIXED. -- s_j_newbury at yahoo dot co dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27500
[Bug fortran/30372] kill intrinsic doesn't diagnose invalid argument kinds
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-11 19:39 --- Contrary to this, the docs of g77-3.4.6 [1] state: Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Also, the comment at the beginning of libgfortran/intrinsics/kill.c [2] states: /* SUBROUTINE KILL(PID, SIGNAL, STATUS) INTEGER, INTENT(IN) :: PID, SIGNAL INTEGER(KIND=1), INTENT(OUT), OPTIONAL :: STATUS INTEGER(KIND=1) FUNCTION KILL(PID, SIGNAL) INTEGER, INTENT(IN) :: PID, SIGNAL */ Thus, maybe libgfortran should provide `_gfortran_kill_i1_sub'? [1] http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Kill-Intrinsic-_0028subroutine_0029.html [2] http://gcc.gnu.org/viewcvs/trunk/libgfortran/intrinsics/kill.c?view=markup -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
[Bug libfortran/30765] New: generating files from m4
There is something mighty strange going on with the dependencies for the files generated with m4 with --enable-maintainer-mode. In http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00353.html , I committed a change to Makefile.am which removed $(srcdir) from a lot of targets. This is required to get touch m4/* to correctly regenerate the targets. OTOH, the $(srcdir) is needed to get "rm generated/* && make" to work. Yuck. -- Summary: generating files from m4 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30765
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-02-11 19:42 --- Created an attachment (id=13036) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13036&action=view) patch This fixes the missing intrinsics, and removes type conversion from minloc. This also reverses http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00353.html (PR 30765). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #12990|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug c++/30766] New: Template functions now use declaration scope instead of call scope
-
int overridable (int v) { return (v); }
template
int call_override (const T& v) { return (overridable (v)); }
int overridable (float) { return (1); }
int main (void)
{
return (call_override (0.0f));
}
-
The above code compiles fine with 4.0.2, but does not work with 4.2.0 20070207,
where call_override does not see the float version of overridable even though
it is available at the time of instantiation.
I use this method in my library to allow overriding a function for
user-specific types.
--
Summary: Template functions now use declaration scope instead of
call scope
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 9ugsa9j02 at sneakemail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30766
[Bug c++/30766] Template functions now use declaration scope instead of call scope
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-11 20:07 --- And this is the correct behavior as described by the C++ standard. I have to find the specific section but basically the overloaded set for depedent functions happen like the following: 1) find all functions declared already during definition time (and not instantiation time) 2) Later during instantiation look at the inner most namespace of the arguments for the overloaded function Since fundumental types don't have an associated namespace to it, Part 2 does not apply. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30766
[Bug c++/26988] [4.0/4.1/4.2/4.3 Regression] template constructor in template class derived from virtual base can not be specialized
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-02-11 20:15 --- Subject: Bug 26988 Author: mmitchel Date: Sun Feb 11 20:15:13 2007 New Revision: 121822 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121822 Log: PR c++/26988 * pt.c (determine_specialization): Use skip_artificial_parms_for. (fn_type_unificiation): Likewise. (get_bindings): Likewise. PR c++/26988 * g++.dg/template/spec34.C: New test Added: trunk/gcc/testsuite/g++.dg/template/spec34.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26988
[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-11 20:17:10 date|| Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931
[Bug middle-end/30151] [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE"
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Keywords||build, link-failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug libgcj/30419] [4.3 Regression] libjava failed to build
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-11 20:22 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30419
[Bug testsuite/30649] [4.1.x] possible bogus checkin of g++.dg/debug/debug9.C
--- Comment #1 from mmitchel at gcc dot gnu dot org 2007-02-11 20:33 --- Subject: Bug 30649 Author: mmitchel Date: Sun Feb 11 20:33:36 2007 New Revision: 121823 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121823 Log: PR gcc/30649 * g++.dg/debug/debug9.C: Remove Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/debug/debug9.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30649
[Bug testsuite/30649] [4.1.x] possible bogus checkin of g++.dg/debug/debug9.C
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-02-11 20:34 --- I have removed debug9.C from the 4.1 branch. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30649
[Bug fortran/30372] kill intrinsic doesn't diagnose invalid argument kinds
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-11 20:43 --- (In reply to comment #2) > Contrary to this, the docs of g77-3.4.6 [1] state: > Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). > INTEGER(KIND=1) in g77 is the default integer kind, which is INTEGER(KIND=4) in gfortran. What needs to be done is either fix check.c to disable non-default integer kinds or fix iresolve.c to force type conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
[Bug fortran/30319] internal error in gfc_resolve_expr() for character parameter
--- Comment #5 from pault at gcc dot gnu dot org 2007-02-11 20:59 --- Subject: Bug 30319 Author: pault Date: Sun Feb 11 20:58:48 2007 New Revision: 121824 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121824 Log: 2007-02-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * module.c (find_symtree_for_symbol): New function to return a symtree that is not a "unique symtree" given a symbol. (read_module): Do not automatically set pointer_info to referenced because this inhibits the generation of a unique symtree. Recycle the existing symtree if possible by calling find_symtree_for_symbol. PR fortran/30319 * decl.c (add_init_expr_to_sym): Make new charlen for an array constructor initializer. 2007-02-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * gfortran.dg/used_dummy_types_6.f90: Add the "privatized" versions of the modules. PR fortran/30617 * gfortran.dg/intrinsic_actual_2.f90: Make this legal fortran by getting rid of recursive I/O and providing functions with results. PR fortran/30319 * gfortran.dg/char_array_constructor_2.f90 Added: trunk/gcc/testsuite/gfortran.dg/char_array_constructor_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90 trunk/gcc/testsuite/gfortran.dg/used_dummy_types_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30319
[Bug fortran/30554] [4.2 and 4.1 only] ICE in mio_pointer_ref at module.c:1945
--- Comment #13 from pault at gcc dot gnu dot org 2007-02-11 20:59 --- Subject: Bug 30554 Author: pault Date: Sun Feb 11 20:58:48 2007 New Revision: 121824 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121824 Log: 2007-02-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * module.c (find_symtree_for_symbol): New function to return a symtree that is not a "unique symtree" given a symbol. (read_module): Do not automatically set pointer_info to referenced because this inhibits the generation of a unique symtree. Recycle the existing symtree if possible by calling find_symtree_for_symbol. PR fortran/30319 * decl.c (add_init_expr_to_sym): Make new charlen for an array constructor initializer. 2007-02-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * gfortran.dg/used_dummy_types_6.f90: Add the "privatized" versions of the modules. PR fortran/30617 * gfortran.dg/intrinsic_actual_2.f90: Make this legal fortran by getting rid of recursive I/O and providing functions with results. PR fortran/30319 * gfortran.dg/char_array_constructor_2.f90 Added: trunk/gcc/testsuite/gfortran.dg/char_array_constructor_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90 trunk/gcc/testsuite/gfortran.dg/used_dummy_types_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #21 from pault at gcc dot gnu dot org 2007-02-11 20:59 --- Subject: Bug 30617 Author: pault Date: Sun Feb 11 20:58:48 2007 New Revision: 121824 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121824 Log: 2007-02-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * module.c (find_symtree_for_symbol): New function to return a symtree that is not a "unique symtree" given a symbol. (read_module): Do not automatically set pointer_info to referenced because this inhibits the generation of a unique symtree. Recycle the existing symtree if possible by calling find_symtree_for_symbol. PR fortran/30319 * decl.c (add_init_expr_to_sym): Make new charlen for an array constructor initializer. 2007-02-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30554 * gfortran.dg/used_dummy_types_6.f90: Add the "privatized" versions of the modules. PR fortran/30617 * gfortran.dg/intrinsic_actual_2.f90: Make this legal fortran by getting rid of recursive I/O and providing functions with results. PR fortran/30319 * gfortran.dg/char_array_constructor_2.f90 Added: trunk/gcc/testsuite/gfortran.dg/char_array_constructor_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90 trunk/gcc/testsuite/gfortran.dg/used_dummy_types_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30765] generating files from m4
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-02-11 21:00 --- I have a fix. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-11 21:00:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30765
[Bug fortran/30733] VOLATILE: Missed optimization - attribute not restricted to scope
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-02-11 21:02 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-11 21:02:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
[Bug fortran/30372] kill intrinsic doesn't diagnose invalid argument kinds
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-02-11 21:02 --- Ouch. Thanks for clarification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
[Bug bootstrap/30767] New: [4.3 regression]: compare is no longer enabled by default
"make bootstrap" used to compare stage2 and stage3 after gcc was bootstrapped. "make bootstrap" would abort if comparison was failed. Now, compare stage2 and stage3 is not longer done for "make bootstrap". Is that intentional? I think it is a very bad idea. -- Summary: [4.3 regression]: compare is no longer enabled by default Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767
[Bug middle-end/30151] [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE"
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-11 21:08 --- Subject: Re: [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global destructors keyed to _ZNSt3tr112_GLOBAL__N_16i > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > >Severity|normal |blocker >Keywords||build, link-failure This doesn't cause a build error. It causes 9 fails in the libstdc++ testsuite. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug bootstrap/30767] [4.3 regression]: compare is no longer enabled by default
--- Comment #1 from drow at gcc dot gnu dot org 2007-02-11 21:21 --- What evidence do you have that comparison was not done? bootstrap calls stage3-bubble which calls make compare. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767
[Bug bootstrap/30767] [4.3 regression]: compare is no longer enabled by default
--- Comment #2 from hjl at lucon dot org 2007-02-11 21:38 --- I saw it now. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767
[Bug c++/26988] [4.0/4.1/4.2/4.3 Regression] template constructor in template class derived from virtual base can not be specialized
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-02-11 21:41 --- Subject: Bug 26988 Author: mmitchel Date: Sun Feb 11 21:40:56 2007 New Revision: 121826 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121826 Log: PR c++/26988 * pt.c (determine_specialization): Use skip_artificial_parms_for. (fn_type_unificiation): Likewise. (get_bindings): Likewise. PR c++/26988 * g++.dg/template/spec34.C: New test Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/spec34.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26988
[Bug c++/26988] [4.0/4.1 Regression] template constructor in template class derived from virtual base can not be specialized
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-02-11 21:41 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1 Regression] |template constructor in |template constructor in |template class derived from |template class derived from |virtual base can not be |virtual base can not be |specialized |specialized http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26988
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-02-11 21:51 --- Also affected: chmod, exit, getcwd, hostnm, link, rename, sleep, system_clock, unlink, umask (maybe others). SYSTEM_CLOCK accepts INTEGER(1) if exactly one or all of its optional arguments are of that type. UMASK(NEW[,OLD]) also accepts INTEGER(1) in its NEW argument if OLD is not present. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Summary|kill intrinsic doesn't |various intrinsics do not |diagnose invalid argument |diagnose invalid argument |kinds |kinds http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
--- Comment #6 from kargl at gcc dot gnu dot org 2007-02-11 22:26 ---
daniel,
It's just an inconsistency in implementations. First, note that
FX and myself implemented a lot of the g77 intrinsics procedures
as our first foray into gfortran, so we may have missed some of the
finer details. For example, EXIT() actually accepts any integer
kind. I don't know if it's documented or not. I'll note
laptop:kargl[210] cat > e.f90
program e
integer(1) i1
integer(2) i2
integer(4) i4
integer(8) i8
call exit(i1)
call exit(i2)
call exit(i3)
call exit(i8)
end program e
laptop:kargl[211] gfc4x -o z -fdump-tree-original e.f90
/usr/tmp/ccA5UbZ9.o(.text+0x1e): In function `MAIN__':
: undefined reference to `_gfortran_exit_i1'
collect2: ld returned 1 exit status
laptop:kargl[212] more e.f90.003t.original
MAIN__ ()
{
int2 i2;
int1 i1;
int8 i8;
int4 i3;
_gfortran_set_std (70, 127, 0, 0);
_gfortran_exit_i1 (&i1);
_gfortran_exit_i2 (&i2);
_gfortran_exit_i4 (&i3);
_gfortran_exit_i8 (&i8);
}
So, I think we need to audit the intrinsics to see were we need to
fix up the inconsistencies and documentation.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC||kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #25 from tobi at gcc dot gnu dot org 2007-02-11 22:36 --- Subject: Bug 30478 Author: tobi Date: Sun Feb 11 22:35:56 2007 New Revision: 121830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121830 Log: 2007-02-11 Tobias Schlueter <[EMAIL PROTECTED]> PR fortran/30478 fortran/ * decl.c (add_init_expr_to_sym): Remove ENUM specific code. (variable_decl): Likewise. Rewrap comment. (match_attr_spec): Remove ENUM specific code. (gfc_match_enum): Fix typo in error message. (enumerator_decl): New function. (gfc_match_enumerator_def): Use enumerator_decl instead of variable_decl. Adapt code accordingly. testsuite/ * gfortran.dg/enum_4.f90: Update error message checks. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/enum_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug middle-end/30751] [4.3 Regression] internal compiler error: in extract_insn, at recog.c:2108
--- Comment #2 from jim at amarooas dot com dot au 2007-02-11 22:53 --- I configure like this in ~/gcc/build ../configure --prefix=/usr/local/4.3 --enable-java-awt=gtk,xlib The error was seen with no local patches. I updated and rebuilt several times over the past 2 weeks before reporting, but the last version was < 121792. I just updated to 121828 and will try again now. There will be small delays as it usually takes a couple of days to get to the error on my sunblade100, and longer for a fresh build. Also my timezone is UTC+11. I will report again when some results, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30751
[Bug middle-end/30751] [4.3 Regression] internal compiler error: in extract_insn, at recog.c:2108
--- Comment #3 from jim at amarooas dot com dot au 2007-02-11 22:56 --- The souces was checked out as follows: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30751
[Bug c++/30768] New: [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
For 121818 this test passed. For 121819 (author of named revision CC:ed), I see: Running /tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... ... FAIL: ext/pb_ds/regression/list_update_data_map_rand.cc (test for excess errors) with the message in libstdc++.log being: /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/insert_fn_imps.hpp: In member function 'typename pb_ds::detail::lu_map_data_::entry_pointer pb_ds::detail::lu_map_data_::allocate_new_entry(typename pb_ds::detail::types_traits::const_reference, pb_ds::detail::false_type) [with Key = pb_ds::test::basic_type, Mapped = pb_ds::test::basic_type, Eq_Fn = std::equal_to, Allocator = __gnu_cxx::throw_allocator, Update_Policy = pb_ds::test::counter_lu_policy_t_<__gnu_cxx::throw_allocator, 5u>]':^M /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/insert_fn_imps.hpp:75: internal compiler error: in calc_dfs_tree, at dominance.c:374^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M Preprocessed code coming up. -- Summary: [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug c++/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #1 from mmitchel at gcc dot gnu dot org 2007-02-11 23:54 --- I didn't see the bug in my native testing. (I've just rechecked my test logs to confirm that.) Please post preprocessed source and command-line. This is probably going to be a latent bug in the middle end, since my changes did not directly impact the code that's crashing, but it's certainly plausible that I tickled it, by adjusting what set of functions are marked TREE_NOTHROW. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-12 00:00 --- /* This aborts e.g. when there is _no_ path from ENTRY to EXIT at all. */ gcc_assert (di->nodes == (unsigned int) n_basic_blocks - 1); Sounds like inlining is messing up the CFG with slightly different NOTHROW. Wll know once I see the preprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #7 from bangerth at dealii dot org 2007-02-12 00:02 --- (In reply to comment #6) > I immediately believe that Andrew's and Wolfgang's findings are accurate, but > I > never claimed that the mainline has a problem. I never even tried it. I didn't want to imply that there was no problem. It just appeared as if neither Andrew nor I had a recent 4.2.x build around. The person who has the infrastructure for finding regressions is Janis. Janis, are you in a position of confirming this PR and finding where on the branch the problem was introduced? (The PR gives pretty specific dates already.) W. > > My interest it to make sure that our code works with any new gcc release, > since > that's what the OS makers pick up, and then we are stuck with the remaining > bugs for 5+ years. > > It looks like a gcc 4.2 release is imminent, therefore I'm testing with the > corresponding branch. > > From other bug reports I know that you have a "regression hunt" procedure. Is > there any way I can submit my reproducer to the hunter? We have a fairly small > time bracket already, given by Andrew's 4.2 test and the day this bug was > opened. Therefore it would seem straightforward to find the checkin which > caused the problem. > > I'll repeat my test with the current 4.2 branch and post my results here. > -- bangerth at dealii dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #3 from hp at gcc dot gnu dot org 2007-02-12 00:22 --- Created an attachment (id=13037) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13037&action=view) Preprocessed and bzip2-compressed (3MeB uncompressed) code. "cc1plus -O2" is sufficient. Though -quit is recommended too. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #4 from hp at gcc dot gnu dot org 2007-02-12 00:23 --- s/-quit/-quiet/ in last comment. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-12 00:23:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #26 from tobi at gcc dot gnu dot org 2007-02-12 00:51 --- Subject: Bug 30478 Author: tobi Date: Mon Feb 12 00:51:43 2007 New Revision: 121837 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121837 Log: 2007-02-10 Tobias Schlueter <[EMAIL PROTECTED]> PR fortran/30478 fortran/ * decl.c (create_enum_history, gfc_free_enum_history): Formatting fixes. (add_init_expr_to_sym): Remove ENUM-specific code-path. (variable_decl): Likewise. Formatting fix. (match_attr_spec): Remove ENUM-specific codepath. (gfc_match_enum): Fix typo in error message. (enumerator_decl): New. (gfc_match_enumerator_def): Strip down to code necessary for ENUMs, use enumerator_decl. testsuite/ * gfortran.dg/enum_4.f90: Update expected error message. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/enum_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-12 00:54 --- I can reproduce this on powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- (In reply to comment #6) > Fortran is not release-critical and this bug appears to be purely within the > Fortran front end. Should I commit the patch for the next release candidate once the branch is unfrozen? Personally, I don't believe this a sufficiently important bug (being an ICE on weird invalid code designed deliberately to break the compiler), but if you don't want this regression in the release, I'll happily commit it in time for the next release candidate. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC|Tobias dot Schlueter at | |physik dot uni-muenchen dot | |de | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #28 from mark at codesourcery dot com 2007-02-12 01:11 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) tobi at gcc dot gnu dot org wrote: > --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- > (In reply to comment #6) >> Fortran is not release-critical and this bug appears to be purely within the >> Fortran front end. > > Should I commit the patch for the next release candidate once the branch is > unfrozen? Personally, I don't believe this a sufficiently important bug > (being > an ICE on weird invalid code designed deliberately to break the compiler), but > if you don't want this regression in the release, I'll happily commit it in > time for the next release candidate. No, please leave any non-critical issues until after 4.1.2 is released. Then, when the 4.1 branch is reopened, you may check in the the patch for a possible future 4.1.3 release. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-12 01:15 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) > --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- > (In reply to comment #6) > > Fortran is not release-critical and this bug appears to be purely within the > > Fortran front end. > > Should I commit the patch for the next release candidate once the branch is > unfrozen? Personally, I don't believe this a sufficiently important bug > (being > an ICE on weird invalid code designed deliberately to break the compiler), but > if you don't want this regression in the release, I'll happily commit it in > time for the next release candidate. Mark always says that if it's not c++ ;) Since it's a regression, I believe it's your call. The test could be xfail'd if you decide the benefits aren't worth the risk. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #30 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-12 01:21 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-12 > 01:15 --- > Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) > >> --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 >> --- >> (In reply to comment #6) >>> Fortran is not release-critical and this bug appears to be purely within the >>> Fortran front end. >> Should I commit the patch for the next release candidate once the branch is >> unfrozen? Personally, I don't believe this a sufficiently important bug >> (being >> an ICE on weird invalid code designed deliberately to break the compiler), >> but >> if you don't want this regression in the release, I'll happily commit it in >> time for the next release candidate. > > Mark always says that if it's not c++ ;) > > Since it's a regression, I believe it's your call. The test could > be xfail'd if you decide the benefits aren't worth the risk. User-visibility of the bug is probably zero, so I don't think this is important enough :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug c/30769] New: compile error / segmentation fault / 64bit compiler
during compile of Template::Toolkit::Stash::XS (perl module) gcc -v -save-temps -c -fno-strict-aliasing -pipe -Wdeclaration-after-statement -mcpu=v9 -m64 -Wa,-xarch=v9 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\"2.18\" -DXS_VERSION=\"2.18\" -fPIC "-I/opsc_srb/local/lib/perl5/5.8.8/sun4-solaris-64/CORE" Stash.c gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: sparcv9-sun-solaris2.9 Configured with: ../gcc-4.1.1/configure --prefix=/opsc_srb/local --enable-languages=c,c++ --enable-shared sparcv9-sun-solaris2.9 Thread model: posix gcc version 4.1.1 /opsc_srb/local/libexec/gcc/sparcv9-sun-solaris2.9/4.1.1/cc1 -E -quiet -v -I/opsc_srb/local/lib/perl5/5.8.8/sun4-solaris-64/CORE -D__arch64__ -D__sparcv9 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DVERSION="2.18" -DXS_VERSION="2.18" Stash.c -mcpu=v9 -m64 -Wdeclaration-after-statement -fno-strict-aliasing -fPIC -O -fpch-preprocess -o Stash.i ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opsc_srb/local/lib/gcc/sparcv9-sun-solaris2.9/4.1.1/../../../../sparcv9-sun-solaris2.9/include" #include "..." search starts here: #include <...> search starts here: /opsc_srb/local/lib/perl5/5.8.8/sun4-solaris-64/CORE /opsc_srb/local/include /opsc_srb/local/lib/gcc/sparcv9-sun-solaris2.9/4.1.1/include /usr/include End of search list. :0: 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. -- Summary: compile error / segmentation fault / 64bit compiler Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: armin at xos dot net GCC build triplet: sparcv9-sun-solaris2.9 GCC host triplet: sparcv9-sun-solaris2.9 GCC target triplet: sparcv9-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug target/30770] New: BOOT_CFLAGS="-O2 -g -mtune=nocona" miscompiled thes stage 3 compiler
When I built gcc 4.3 revision 121818 with
# make bootstrap BOOT_CFLAGS="-O2 -g -pipe"
thes stage 3 compiler was miscompiled:
checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.
make[4]: *** [configure-stage3-target-libgcc] Error 1
make[4]: Leaving directory `/export/build/gnu/gcc-test/build-x86_64-linux'
make[3]: *** [stage3-bubble] Error 2
make[3]: Leaving directory `/export/build/gnu/gcc-test/build-x86_64-linux'
make[2]: *** [bootstrap] Error 2
bash-3.1$ cat x.i
int
main ()
{
return 0;
}
bash-3.1$ ./xgcc -B./ -S x.i -m32
x.i: In function main:
x.i:5: error: unrecognizable insn:
(insn 26 25 27 (parallel [
(set (reg/f:SI 7 sp)
(and:SI (reg/f:SI 7 sp)
(const_int -16 [0xfff0])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
x.i:5: internal compiler error: in insn_default_length, at insn-attrtab.c:1238
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: BOOT_CFLAGS="-O2 -g -mtune=nocona" miscompiled thes
stage 3 compiler
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug target/30770] BOOT_CFLAGS="-O2 -g -mtune=nocona" miscompiled thes stage 3 compiler
--- Comment #1 from hjl at lucon dot org 2007-02-12 05:21 --- I also saw bash-3.1$ make compare Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./tree-vrp.o differs ./tree-ssa-operands.o differs ./build/genpreds.o differs ./build/gengtype-yacc.o differs ./build/genattrtab.o differs ./tree-ssa-alias.o differs ./tree-eh.o differs ./tree-tailcall.o differs ./ipa-reference.o differs ./c-common.o differs ./sched-rgn.o differs ./dominance.o differs ./reload1.o differs ./tree-cfg.o differs ./flow.o differs ./fold-const.o differs ./gcc.o differs ./c-decl.o differs ./tree-ssa-dce.o differs ./bt-load.o differs ./tree-ssa-ter.o differs ./function.o differs ./ddg.o differs ./tree.o differs ./tree-ssa.o differs ./loop-unroll.o differs ./expmed.o differs ./df-scan.o differs ./tree-sra.o differs ./resource.o differs ./except.o differs ./predict.o differs ./tree-ssa-dse.o differs ./df-core.o differs ./cfgloopmanip.o differs ./calls.o differs ./real.o differs ./gcse.o differs ./bitmap.o differs ./c-pragma.o differs ./explow.o differs ./loop-invariant.o differs ./tree-object-size.o differs ./tree-ssa-structalias.o differs ./sched-deps.o differs ./tree-ssa-threadupdate.o differs ./pretty-print.o differs ./tree-pretty-print.o differs ./tree-ssa-sink.o differs ./df-problems.o differs ./tree-into-ssa.o differs ./lower-subreg.o differs ./caller-save.o differs ./loop-iv.o differs ./tree-nested.o differs ./combine.o differs ./tree-ssa-loop-ivopts.o differs ./c-parser.o differs ./cfgrtl.o differs ./tree-scalar-evolution.o differs ./tree-ssa-live.o differs ./ifcvt.o differs ./expr.o differs ./ipa-type-escape.o differs ./i386.o differs ./local-alloc.o differs ./tree-ssa-dom.o differs ./c-typeck.o differs ./bb-reorder.o differs ./tree-ssa-pre.o differs ./global.o differs ./see.o differs ./tree-ssa-loop-manip.o differs ./cfgcleanup.o differs ./cfgexpand.o differs ./tree-ssa-coalesce.o differs ./stor-layout.o differs make: *** [compare] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #8 from rwgk at yahoo dot com 2007-02-12 05:23 --- I'm in the process of narrowing down the revision bracket the really hard way (make bootstrap; make; make install for each revision, using a binary search). Currently my best bracket is: 119819 fails 119788 works I should have it nailed down to the exact revision in the next 12 hours or so. BTW: I checked the most current revision (yesterday) and it still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30583] [ODR] Non-static inline functions cause bugs when defined more than once in different files
--- Comment #3 from Ivan dot Scherbakov at acronis dot com 2007-02-12 06:03 --- The way of declaring inline functions as static is evident, but in fact, when building large projects containing several libraries the case when the same inline function is defined more than once in different libraries and those libraries fail in a very strange way when linked together is *very hard* to diagnose. The proposal was to include a warning/error message when the ODR rule is violated, as when multiple definitions of an ordinary function are encountered. -- Ivan dot Scherbakov at acronis dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30583
[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-02-12 07:05 --- What compiler did you use to build this one? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug fortran/30284] [4.2 and 4.1 only] ICE in gfc_add_modify with internal reads
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-12 07:35 --- Subject: Bug 30284 Author: pault Date: Mon Feb 12 07:34:51 2007 New Revision: 121841 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121841 Log: 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> BACKPORTS FROM TRUNK PR fortran/30284 PR fortran/30626 * trans-expr.c (gfc_conv_aliased_arg): Remove static attribute from function and make sure that substring lengths are translated. (is_aliased_array): Remove static attribute. * trans.c : Add prototypes for gfc_conv_aliased_arg and is_aliased_array. * trans-io.c (set_internal_unit): Add the post block to the arguments of the function. Use is_aliased_array to check if temporary is needed; if so call gfc_conv_aliased_arg. (build_dt): Pass the post block to set_internal_unit and add to the block after all io activiy is done. PR fortran/30407 * trans-expr.c (gfc_conv_operator_assign): New function. * trans.h : Add prototype for gfc_conv_operator_assign. * trans-stmt.c (gfc_trans_where_assign): Add a gfc_symbol for a potential operator assignment subroutine. If it is non-NULL call gfc_conv_operator_assign instead of the first assignment. ( gfc_trans_where_2): In the case of an operator assignment, extract the argument expressions from the code for the subroutine call and pass the symbol to gfc_trans_where_assign. resolve.c (resolve_where, gfc_resolve_where_code_in_forall, gfc_resolve_forall_body): Resolve the subroutine call for operator assignments. PR fortran/30514 * array.c (match_array_element_spec): If the length of an array is negative, adjust the upper limit to make it zero length. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 * gfortran.dg/arrayio_11.f90: New test. PR fortran/30626 * gfortran.dg/arrayio_12.f90: New test. PR fortran/30407 * gfortran.dg/where_operator_assign_1.f90: New test. * gfortran.dg/where_operator_assign_2.f90: New test. * gfortran.dg/where_operator_assign_3.f90: New test. PR fortran/30514 * gfortran.dg/zero_sized_2.f90: New test. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 PR fortran/30626 * io/transfer.c (init_loop_spec, next_array_record): Change to lbound rather than unity base. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_11.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_12.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/fortran/trans-io.c branches/gcc-4_2-branch/gcc/fortran/trans-stmt.c branches/gcc-4_2-branch/gcc/fortran/trans.h branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30284
[Bug fortran/30514] [4.2 and 4. only] zero-sized array wrongly rejected: integer :: i(1:-1)
--- Comment #8 from pault at gcc dot gnu dot org 2007-02-12 07:35 --- Subject: Bug 30514 Author: pault Date: Mon Feb 12 07:34:51 2007 New Revision: 121841 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121841 Log: 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> BACKPORTS FROM TRUNK PR fortran/30284 PR fortran/30626 * trans-expr.c (gfc_conv_aliased_arg): Remove static attribute from function and make sure that substring lengths are translated. (is_aliased_array): Remove static attribute. * trans.c : Add prototypes for gfc_conv_aliased_arg and is_aliased_array. * trans-io.c (set_internal_unit): Add the post block to the arguments of the function. Use is_aliased_array to check if temporary is needed; if so call gfc_conv_aliased_arg. (build_dt): Pass the post block to set_internal_unit and add to the block after all io activiy is done. PR fortran/30407 * trans-expr.c (gfc_conv_operator_assign): New function. * trans.h : Add prototype for gfc_conv_operator_assign. * trans-stmt.c (gfc_trans_where_assign): Add a gfc_symbol for a potential operator assignment subroutine. If it is non-NULL call gfc_conv_operator_assign instead of the first assignment. ( gfc_trans_where_2): In the case of an operator assignment, extract the argument expressions from the code for the subroutine call and pass the symbol to gfc_trans_where_assign. resolve.c (resolve_where, gfc_resolve_where_code_in_forall, gfc_resolve_forall_body): Resolve the subroutine call for operator assignments. PR fortran/30514 * array.c (match_array_element_spec): If the length of an array is negative, adjust the upper limit to make it zero length. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 * gfortran.dg/arrayio_11.f90: New test. PR fortran/30626 * gfortran.dg/arrayio_12.f90: New test. PR fortran/30407 * gfortran.dg/where_operator_assign_1.f90: New test. * gfortran.dg/where_operator_assign_2.f90: New test. * gfortran.dg/where_operator_assign_3.f90: New test. PR fortran/30514 * gfortran.dg/zero_sized_2.f90: New test. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 PR fortran/30626 * io/transfer.c (init_loop_spec, next_array_record): Change to lbound rather than unity base. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_11.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_12.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/fortran/trans-io.c branches/gcc-4_2-branch/gcc/fortran/trans-stmt.c branches/gcc-4_2-branch/gcc/fortran/trans.h branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30514
[Bug fortran/30626] [4.2 and 4.1 only] Wrong-code for internal read
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-12 07:35 --- Subject: Bug 30626 Author: pault Date: Mon Feb 12 07:34:51 2007 New Revision: 121841 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121841 Log: 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> BACKPORTS FROM TRUNK PR fortran/30284 PR fortran/30626 * trans-expr.c (gfc_conv_aliased_arg): Remove static attribute from function and make sure that substring lengths are translated. (is_aliased_array): Remove static attribute. * trans.c : Add prototypes for gfc_conv_aliased_arg and is_aliased_array. * trans-io.c (set_internal_unit): Add the post block to the arguments of the function. Use is_aliased_array to check if temporary is needed; if so call gfc_conv_aliased_arg. (build_dt): Pass the post block to set_internal_unit and add to the block after all io activiy is done. PR fortran/30407 * trans-expr.c (gfc_conv_operator_assign): New function. * trans.h : Add prototype for gfc_conv_operator_assign. * trans-stmt.c (gfc_trans_where_assign): Add a gfc_symbol for a potential operator assignment subroutine. If it is non-NULL call gfc_conv_operator_assign instead of the first assignment. ( gfc_trans_where_2): In the case of an operator assignment, extract the argument expressions from the code for the subroutine call and pass the symbol to gfc_trans_where_assign. resolve.c (resolve_where, gfc_resolve_where_code_in_forall, gfc_resolve_forall_body): Resolve the subroutine call for operator assignments. PR fortran/30514 * array.c (match_array_element_spec): If the length of an array is negative, adjust the upper limit to make it zero length. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 * gfortran.dg/arrayio_11.f90: New test. PR fortran/30626 * gfortran.dg/arrayio_12.f90: New test. PR fortran/30407 * gfortran.dg/where_operator_assign_1.f90: New test. * gfortran.dg/where_operator_assign_2.f90: New test. * gfortran.dg/where_operator_assign_3.f90: New test. PR fortran/30514 * gfortran.dg/zero_sized_2.f90: New test. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 PR fortran/30626 * io/transfer.c (init_loop_spec, next_array_record): Change to lbound rather than unity base. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_11.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_12.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/fortran/trans-io.c branches/gcc-4_2-branch/gcc/fortran/trans-stmt.c branches/gcc-4_2-branch/gcc/fortran/trans.h branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30626
[Bug fortran/30407] [4.2 and 4.1 only] Elemental functions in WHERE assignments wrongly rejected
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-12 07:35 --- Subject: Bug 30407 Author: pault Date: Mon Feb 12 07:34:51 2007 New Revision: 121841 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121841 Log: 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> BACKPORTS FROM TRUNK PR fortran/30284 PR fortran/30626 * trans-expr.c (gfc_conv_aliased_arg): Remove static attribute from function and make sure that substring lengths are translated. (is_aliased_array): Remove static attribute. * trans.c : Add prototypes for gfc_conv_aliased_arg and is_aliased_array. * trans-io.c (set_internal_unit): Add the post block to the arguments of the function. Use is_aliased_array to check if temporary is needed; if so call gfc_conv_aliased_arg. (build_dt): Pass the post block to set_internal_unit and add to the block after all io activiy is done. PR fortran/30407 * trans-expr.c (gfc_conv_operator_assign): New function. * trans.h : Add prototype for gfc_conv_operator_assign. * trans-stmt.c (gfc_trans_where_assign): Add a gfc_symbol for a potential operator assignment subroutine. If it is non-NULL call gfc_conv_operator_assign instead of the first assignment. ( gfc_trans_where_2): In the case of an operator assignment, extract the argument expressions from the code for the subroutine call and pass the symbol to gfc_trans_where_assign. resolve.c (resolve_where, gfc_resolve_where_code_in_forall, gfc_resolve_forall_body): Resolve the subroutine call for operator assignments. PR fortran/30514 * array.c (match_array_element_spec): If the length of an array is negative, adjust the upper limit to make it zero length. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 * gfortran.dg/arrayio_11.f90: New test. PR fortran/30626 * gfortran.dg/arrayio_12.f90: New test. PR fortran/30407 * gfortran.dg/where_operator_assign_1.f90: New test. * gfortran.dg/where_operator_assign_2.f90: New test. * gfortran.dg/where_operator_assign_3.f90: New test. PR fortran/30514 * gfortran.dg/zero_sized_2.f90: New test. 2007-02-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30284 PR fortran/30626 * io/transfer.c (init_loop_spec, next_array_record): Change to lbound rather than unity base. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_11.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/arrayio_12.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/fortran/trans-io.c branches/gcc-4_2-branch/gcc/fortran/trans-stmt.c branches/gcc-4_2-branch/gcc/fortran/trans.h branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30407
[Bug fortran/30284] [4.1 only] ICE in gfc_add_modify with internal reads
--- Comment #8 from pault at gcc dot gnu dot org 2007-02-12 07:36 --- Fixed on trunk and 4.2. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 and 4.1 only] ICE in |[4.1 only] ICE in |gfc_add_modify with internal|gfc_add_modify with internal |reads |reads http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30284
[Bug fortran/30626] [4.1 only] Wrong-code for internal read
--- Comment #8 from pault at gcc dot gnu dot org 2007-02-12 07:36 --- Fixed on trunk and 4.2. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 and 4.1 only] Wrong- |[4.1 only] Wrong-code for |code for internal read |internal read http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30626
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #22 from dominiq at lps dot ens dot fr 2007-02-12 07:37 --- Subject: Re: recursive I/O hangs under OSX > PR fortran/30319 Thanks Paul ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug fortran/30407] [4.1 only] Elemental functions in WHERE assignments wrongly rejected
--- Comment #8 from pault at gcc dot gnu dot org 2007-02-12 07:37 --- Fixed on trunk and 4.2. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 and 4.1 only] Elemental|[4.1 only] Elemental |functions in WHERE |functions in WHERE |assignments wrongly rejected|assignments wrongly rejected http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30407
[Bug fortran/30514] [4.1 only] zero-sized array wrongly rejected: integer :: i(1:-1)
--- Comment #9 from pault at gcc dot gnu dot org 2007-02-12 07:37 --- Fixed on trunk and 4.2. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 and 4. only] zero-sized|[4.1 only] zero-sized array |array wrongly rejected: |wrongly rejected: integer :: |integer :: i(1:-1) |i(1:-1) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30514
[Bug c/30769] compile error / segmentation fault / 64bit compiler
--- Comment #2 from armin at xos dot net 2007-02-12 07:51 --- Subject: Re: compile error / segmentation fault / 64bit compiler hi! the c compiler of gcc version 4.1.1 > --- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-02-12 07:05 > --- > What compiler did you use to build this one? > > > -- > > ebotcazou at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||ebotcazou at gcc dot gnu dot >||org > Status|UNCONFIRMED |WAITING > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. Ciao, Armin -- [EMAIL PROTECTED]pgp public key on requestCU -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
