[Bug fortran/31494] spurious error: PROCEDURE attribute conflicts with DIMENSION attribute
--- Comment #2 from pault at gcc dot gnu dot org 2007-05-22 09:07 --- (In reply to comment #1) I have been thinking about how best to fix pr30746 and will add this one to my reflections. I fixed 30746 but this PR remains. It is, if anything, a bit more difficult because there is at least one further error behind the one that you report. *sigh* Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31494
[Bug middle-end/32026] [4.3 Regression] misc.c:899: error: 'const struct real_format' has no member named 'log2_b'
--- Comment #1 from krebbel at gcc dot gnu dot org 2007-05-22 09:16 --- Fixed by: http://gcc.gnu.org/viewcvs?view=revrevision=124938 -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32026
[Bug fortran/30964] optional arguments to random_seed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-22 09:23 --- There's more to it. When generate wrong-code for optional arguments, as shown by the following code: $ cat b.f90 program trs implicit none integer :: size, ierr integer, allocatable, dimension(:) :: seed call random_seed(size) allocate(seed(size), stat=ierr) if (ierr /= 0) stop call test_random_seed() contains subroutine test_random_seed(get) integer, dimension(:), optional :: get call random_seed(get=get) end subroutine test_random_seed end program trs $ gfortran b.f90 ./a.out Segmentation fault -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug testsuite/32031] New: The 'status' of using the LAST_UPDATED file is unclear or inconsistent
I obtained the gcc 4.3 trunk as per the instructions on the web site
(http://gcc.gnu.org/svn.html) using SVN. After all the files arrive and the
checkout is completed it would _seem_ that the file LAST_UPDATED is missing.
One (old) changelog says that the file is .cvsignore (don't get it) and
another (newer) changelog says the file is used. Various scripts use it.
The script file gcc-4_3-trunk/contrib/test_summary uses the file
gcc-4_3-trunk/LAST_UPDATED and if that file is missing it e-mails test
results with an incorrect (or peculiar, but possibly correct?) line that says
LAST_UPDATED: (BLANK INFO):.
After using grep to search for files that require (or mention) this file I came
up with confusing or inconsistent information.
If the file does not exist (on the user's system, not the svn server) then the
test_summary script e-mails a line with LAST_UPDATED: (BLANK INFO):
and that seems to have little purpose.
It seems that one way you could have the file is to run the script
gcc-4_3-trunk/maintainer-scripts/gcc_release or
gcc-4_3-trunk/contrib/gcc_update but most people probably don't run those
scripts (judging from the various test reports).
When I run gcc-4_3-trunk/contrib/gcc_update on my system (Debian) I end up
with a double date (lucky me). Just UTC would be better.
# cat LAST_UPDATED
Tue May 22 01:38:20 PDT 2007
Tue May 22 08:38:20 UTC 2007 (revision 124939)
# date --version
date (GNU coreutils) 5.97
_I_ prefer the test_summary reports to have the info it provides at the top of
the report. It is useful to know the date, time, and revision number.
What is unclear (or inconsistent) is that if we should have it then why don't
we. If we should NOT have it then why is it in the script test_summary and
the _newest_ changelogs? To have or not to have.
# grep -r LAST_UPDATED /root/downloads/gcc-4_3-trunk/*
File: gcc-4_3-trunk/contrib/test_summary
printf LAST_UPDATED: ;
system(tail -1 srcdir /LAST_UPDATED);
File: gcc-4_3-trunk/ChangeLog
2001-07-27 Richard Henderson [EMAIL PROTECTED]
* .cvsignore: Add LAST_UPDATED.
File: gcc-4_3-trunk/maintainer-scripts/ChangeLog
2005-11-06 Joseph S. Myers [EMAIL PROTECTED]
* gcc_release: Further update for SVN. Don't set EXPORTTAG or
EXPORTDATE; always determine SVNREV the same way. Correct message
about what sources are being retrived. Include branch information
in LAST_UPDATED.
2003-08-24 Gerald Pfeifer [EMAIL PROTECTED]
* gcc_release (build_sources): Create/update the LAST_UPDATED file
in the source directory with information how sources were obtained.
File: /root/downloads/gcc-4_3-trunk/maintainer-scripts/gcc_release
# Run gcc_update on them to set up the timestamps nicely, and (re)write
# the LAST_UPDATED file containing the SVN tag/revision used.
changedir gcc-${RELEASE}
contrib/gcc_update --touch
echo Obtained from SVN: ${SVNBRANCH} revision ${SVNREV} LAST_UPDATED
File: gcc-4_3-trunk/contrib/.svn/text-base/ChangeLog.svn-base
2005-11-01 Joseph S. Myers [EMAIL PROTECTED]
* gcc_update: Include revision number in LAST_UPDATED.
2001-07-27 Richard Henderson [EMAIL PROTECTED]
* test_summary: Copy LAST_UPDATED UTC time to head of summary.
2001-07-27 Richard Henderson [EMAIL PROTECTED]
* gcc_update: Dump timestamp in LAST_UPDATED.
Just a comment in File: gcc-4_3-trunk/gcc/config/cris/cris.h
/* Same, but with swapped arguments (no canonical \
ordering between e.g. REG and MEM as of LAST_UPDATED \
Thu May 12 03:59:11 UTC 2005). */ \
--
Summary: The 'status' of using the LAST_UPDATED file is unclear
or inconsistent
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
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=32031
[Bug target/10768] ICEs on compilation of ada support library for avr
--- Comment #19 from charlet at gcc dot gnu dot org 2007-05-22 09:51 --- Just to clarify: the patch posted is only a workaround/kludge, not a real fix. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
[Bug tree-optimization/32032] New: [4.3 Regression] ICE in compute_antic, at tree-ssa-pre.c:1968 at -O3
I'm getting the following ICE at -O3 with 4.3. This was introduced between 0070422 and 20070515. (sid)24741:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3 dash-options.i /home/tbm/src/b/dash-0.5.3/build-tmp/../src/options.c: In function 'setparam': /home/tbm/src/b/dash-0.5.3/build-tmp/../src/options.c:287: internal compiler error: in compute_antic, at tree-ssa-pre.c:1968 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] ICE in compute_antic, at tree-ssa- pre.c:1968 at -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-22 09:53 --- bootstrap with fold-checking is known to be broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug middle-end/32033] New: [4.3 Regression] ICE in fold_comparison, at fold-const.c:8531 at -O3
I'm getting the following ICE at -O3 with 4.3. This was introduced between 0070422 and 20070515. (sid)24742:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O3 crawl-beam.ii beam.cc: In function 'void explosion(bolt, bool)': beam.cc:4055: internal compiler error: in fold_comparison, at fold-const.c:8531 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.3 Regression] ICE in fold_comparison, at fold- const.c:8531 at -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32033
[Bug libgcj/32034] New: Use of deprecated classes in gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools
On the i686-pc-linux-gnu target libjava compiles clean, except here: make[4]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/scripts' Making all in tools make[4]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools' mkdir -p classes/gnu/classpath/tools/giop/grmic/templates mkdir -p classes/gnu/classpath/tools/rmi/rmic/templates mkdir -p classes/gnu/classpath/tools/appletviewer mkdir -p classes/gnu/classpath/tools/jarsigner mkdir -p classes/gnu/classpath/tools/keytool cp /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/rmic/templates/*.jav classes/gnu/classpath/tools/rmi/rmic/templates cp /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/giop/grmic/templates/*.jav classes/gnu/classpath/tools/giop/grmic/templates cp /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/*.txt classes/gnu/classpath/tools/rmi/ cp /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/giop/*.txt classes/gnu/classpath/tools/giop/ /opt/gcc-4_2-build/gcc/gcj -B/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/ -B/opt/gcc-4_2-build/gcc/ -encoding UTF-8 --bootclasspath '../lib':'../lib/glibj.zip' --classpath . -C -d classes /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/*.java /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/*/*.java /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/*/*/*.java /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:49: warning: The class 'java.rmi.server.SkeletonMismatchException' has been deprecated. import java.rmi.server.SkeletonMismatchException; ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:57: warning: The class 'java.rmi.server.Skeleton' has been deprecated. implements java.rmi.server.Skeleton ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:71: warning: The class 'java.rmi.server.Operation' has been deprecated. private static final Operation[] operations = ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:80: warning: The class 'java.rmi.server.Operation' has been deprecated. public Operation[] getOperations() ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:85: warning: The class 'java.rmi.server.RemoteCall' has been deprecated. public void dispatch(Remote obj, RemoteCall call, ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java: In class 'gnu.classpath.tools.rmi.registry.RegistryImpl_Skel': /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java: In method 'gnu.classpath.tools.rmi.registry.RegistryImpl_Skel.getOperations()': /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:82: warning: The class 'java.rmi.server.Operation' has been deprecated. return ((Operation[]) operations.clone()); ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java: In method 'gnu.classpath.tools.rmi.registry.RegistryImpl_Skel.dispatch(java.rmi.Remote,java.rmi.server.RemoteCall,int,long)': /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:101: warning: The class 'java.rmi.server.SkeletonMismatchException' has been deprecated. throw new SkeletonMismatchException(interface hash mismatch); ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:104: warning: The class 'java.rmi.server.SkeletonMismatchException' has been deprecated. throw new SkeletonMismatchException(interface hash mismatch); ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java: In method 'clinit()': /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:73: warning: The class 'java.rmi.server.Operation' has been deprecated. new Operation(void bind(java.lang.String, Remote), ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:74: warning: The class 'java.rmi.server.Operation' has been deprecated. new Operation(java.lang.String[] list(), ^
[Bug tree-optimization/32032] [4.3 Regression] ICE in compute_antic, at tree-ssa-pre.c:1968 at -O3
--- Comment #1 from tbm at cyrius dot com 2007-05-22 10:06 ---
Reduced testcase:
struct shparam
{
char **p;
};
freeparam (volatile struct shparam *param)
{
char **ap;
for (ap = param-p; *ap; ap++)
free ((void *) (param-p));
}
struct shparam shellparam;
setparam (void)
{
freeparam (shellparam);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug fortran/32035] New: 'anonymous' may be used uninitialized in this function
Hi! This a very minor thing, but it turns out to be a bit annoying: gfortran now and then (rather randomly in my opinion) throws this compilation diagnostic, of which I don't seem to make head or tail: warning: 'anonymous' may be used uninitialized in this function This warning looks quite meaningless to me (at best). Cheers! Philippe PS: gfortran -O1 -g -Wall -c Source.f90 Source.f90: In function 'test': Source.f90:35: warning: 'anonymous' may be used uninitialized in this function PPS: don't look for much sense, I just tried to cut down some valid sources while keeping this behaviour... ! SUBROUTINE Test ! IMPLICIT NONE ! LOGICAL :: Logical_1 ! INTEGER :: Integer_1 INTEGER :: Integer_2 INTEGER :: Integer_3 INTEGER :: Integer_4 INTEGER, PARAMETER :: Dft = 4 INTEGER, PARAMETER :: Parameter_1 = 1, Parameter_2 = 2 ! CHARACTER ( LEN = 30 ) :: String_1 ! READ ( 5, * ) String_1 ! Integer_3 = Parameter_1 Integer_4 = 666 ! SELECT CASE ( TRIM(String_1) ) CASE ( A ) Integer_3 = Parameter_1 CASE ( B ) Integer_3 = Parameter_2 CASE DEFAULT STOP END SELECT ! IF ( Integer_3 .EQ. Parameter_2 ) THEN ! READ ( 5, * ) Integer_1 ! Integer_2 = 0 DO Integer_4 = 1, Integer_1 ! READ ( 5, * ) String_1 SELECT CASE ( TRIM(String_1) ) CASE ( C ) Logical_1 = .TRUE. CASE ( D ) Logical_1 = .FALSE. CASE DEFAULT STOP END SELECT ! ENDDO ENDIF ! RETURN END SUBROUTINE Test ! PPPS: gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /USER/philippe/Irix/Gcc_Sources/configure --prefix=/usr1/MICRESS/Philippe/Tools/Gcc --enable-languages=c,fortran --disable-maintainer-mode --disable-shared --with-mpfr=/usr1/MICRESS/Philippe/Tools/Mpfr --with-gmp=/usr1/MICRESS/Philippe/Tools/Gmp --with-htmldir Thread model: posix gcc version 4.3.0 20070522 (experimental) -- Summary: 'anonymous' may be used uninitialized in this function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug fortran/31627] -bounds-check doesn't check lower bound of assumed-sized array
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-22 10:27 --- Subject: Bug 31627 Author: fxcoudert Date: Tue May 22 09:27:15 2007 New Revision: 124940 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124940 Log: PR fortran/31627 * trans-array.c (gfc_trans_array_bound_check): Take extra argument to indicate whether we should check the upper bound in that dimension. (gfc_conv_array_index_offset): Check only the lower bound of the last dimension for assumed-size arrays. (gfc_conv_array_ref): Likewise. (gfc_conv_ss_startstride): Likewise. * gfortran.dg/bounds_check_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31627
[Bug fortran/31627] [4.1/4.2 only] -bounds-check doesn't check lower bound of assumed-sized array
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-22 10:28 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.0 4.2.0 4.1.3 |4.2.0 4.1.3 Known to work||4.3.0 Resolution||FIXED Summary|-bounds-check doesn't check |[4.1/4.2 only] -bounds-check |lower bound of assumed-sized|doesn't check lower bound of |array |assumed-sized array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31627
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #6 from bonzini at gnu dot org 2007-05-22 10:33 --- Please try this patch on top of the previous one. Its purpose is just to validate the logic of the previous one, it's not meant to be committed. Index: libgcc/configure.ac === --- libgcc/configure.ac (revision 124764) +++ libgcc/configure.ac (working copy) @@ -100,6 +100,8 @@ GCC_NO_EXECUTABLES AC_PROG_CC AC_PROG_CPP_WERROR +CFLAGS=$LIBCFLAGS + # Check for decimal float support. AC_CACHE_CHECK([whether decimal floating point is supported], [libgcc_cv_dfp], [AC_COMPILE_IFELSE([_Decimal32 x;], [libgcc_cv_dfp=yes], -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug fortran/32036] New: Multiple evaluation of array index with bounds checking
The following testcase is extracted from gfortran.dg/pr19928-2.f90. It shows that the array index is evaluated multiple times. $ cat u.f90 type t integer, dimension (5) :: field end type t type (t), dimension (2) :: a integer :: calls a(1)%field = 0 a(2)%field = 0 calls = 0 if (sum(a(foo(calls))%field) /= 0) call abort if (calls .ne. 1) print *, bar, calls contains function foo (calls) integer :: calls, foo calls = calls + 1 foo = 2 end function foo end $ gfortran u.f90 ./a.out $ gfortran u.f90 -fbounds-check ./a.out bar 3 -- Summary: Multiple evaluation of array index with bounds checking Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: fxcoudert at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32036
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #105 from rguenth at gcc dot gnu dot org 2007-05-22 10:50 --- Let me again do a step back and look at the problem from another view ;) -- C++ aliasing imposes additional restrictions on transformations we are allowed to do to memory references compared to C type-based aliasing rules. Consider two memory references A and B which we need to know whether we can exchange them. - If we can prove that both memory references are to non-overlapping memory regions we always can exchange them (PTA can provide this knowledge). - We can always re-order two loads. TBAA gives us another source of information to disambiguate the two references. So, if TBAA says the two references do not conflict then - we can hoist loads across stores. *double = 1.0; x = *int; if *int aliases *double the program is invalid. - we can sink stores across loads. (this is just the opposite view of the above) - we _cannot_ re-order stores. - we _cannot_ sink loads across stores. x = *int; *double = 1.0; the store to double may change the dynamic type of what *int points to. - we _cannot_ hoist stores across loads. (opposite view of the above) Note that all the interesting stuff (hoisting loads and sinking stores) is not affected by the stricter C++ aliasing rules. The caveat is, that these rules do not map to our representation of aliasing (VOPs) nor to type-based queries of the alias oracle. -- So the proposal is to impose these additional restrictions ontop of our alias representation and fixup passes that do not honour them. One of them is loop load/store motion which messes up store ordering, another is scheduling. If anyone can come up with a clever way to encode the extra restrictions into our IL be my guest (I wrapped my brain around this for some days now, and only a may_reorder_accesses (A, B) style oracle can handle this, but not VOPs in SSA form or something similar - we'd need a DU chain and another set of VOPs but that looks way too costly) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/32033] [4.3 Regression] ICE in fold_comparison, at fold-const.c:8531 at -O3
--- Comment #1 from tbm at cyrius dot com 2007-05-22 11:11 ---
Reduced testcase:
static int spready[] = {
};
void explosion_map (int y)
{
for (int i = 0; i 4; i++)
if (y * spready[i] 0)
break;
}
void explosion (void)
{
explosion_map (0);
for (int i = 0; i 2; i++)
continue;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32033
[Bug middle-end/32035] 'anonymous' may be used uninitialized in this function
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-22 11:15 --- The error message comes from the middle-end and the variable name is Integer_1, line 33 is: READ ( 5, * ) Integer_1 There are two problems: First, why has the variable no name for the middle end; secondly, why does the middle end print this warning for the following call: _gfortran_st_read (dt_parm.5); _gfortran_transfer_integer (dt_parm.5, integer_1, 4); _gfortran_st_read_done (dt_parm.5); -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-22 11:15:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug libobjc/32037] New: --enable-objc-gc on OS X won't build
[I submitted this to the mailing list before realizing nobody would notice it. So, if anyone did, apologies for the duplication!] So, I've been trying to build gcc with --enable-objc-gc. At first I thought the failure to build was simply due to random bitrot; searching the list archives doesn't show anybody using this in quite some time. But I finally realized that the build process is looking for libobjc_gc.la but it's been built as libobjc_gc-gnu.la because the Mac has its own (incompatible) libobjc installed so the -gnu is there to avoid a conflict. So it's entirely possible that if I had another system to test this on, it would work fine, which would also explain the lack of anyone pointing out that it doesn't work. I tried to patch around this myself, but my changes to libobjc/configure.in and libobjc/Makefile.in don't seem to be getting noticed. (Yes, I re-ran autoconf.) At this point I'm probably done trying, but if other people want to have a look at this, here's how it fails... This is with 4.2.0. I also tried with the latest out of svn from a couple hours ago and got the same problem. I also tried last week with 4.1.2. [ megs and megs snipped...] /Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/xgcc -B/Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/ -B/usr/local/i386-apple-darwin8.9.1/bin/ -B/usr/local/i386-apple-darwin8.9.1/lib/ -isystem /usr/local/i386-apple-darwin8.9.1/include -isystem /usr/local/i386-apple-darwin8.9.1/sys-include -c -I. -I/Users/dankna/Installed/gcc-4.2.0/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/Users/dankna/Installed/gcc-4.2.0/libobjc/objc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc/config -I../../host-i386-apple-darwin8.9.1/gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../include -I../.././libobjc/../boehm-gc/include -I../boehm-gc/include /Users/dankna/Installed/gcc-4.2.0/libobjc/thr.c -fno-common -DPIC -o .libs/thr.o /Users/dankna/Installed/gcc-4.2.0/libobjc/thr.c: In function '__objc_thread_detach_function': /Users/dankna/Installed/gcc-4.2.0/libobjc/thr.c:117: warning: 'noreturn' function does return /Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/xgcc -B/Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/ -B/usr/local/i386-apple-darwin8.9.1/bin/ -B/usr/local/i386-apple-darwin8.9.1/lib/ -isystem /usr/local/i386-apple-darwin8.9.1/include -isystem /usr/local/i386-apple-darwin8.9.1/sys-include -c -I. -I/Users/dankna/Installed/gcc-4.2.0/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/Users/dankna/Installed/gcc-4.2.0/libobjc/objc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc/config -I../../host-i386-apple-darwin8.9.1/gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../include -I../.././libobjc/../boehm-gc/include -I../boehm-gc/include /Users/dankna/Installed/gcc-4.2.0/libobjc/thr.c -o thr.o /dev/null 21 /bin/sh ./libtool --mode=compile /Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/xgcc -B/Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/ -B/usr/local/i386-apple-darwin8.9.1/bin/ -B/usr/local/i386-apple-darwin8.9.1/lib/ -isystem /usr/local/i386-apple-darwin8.9.1/include -isystem /usr/local/i386-apple-darwin8.9.1/sys-include -c -I. -I/Users/dankna/Installed/gcc-4.2.0/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/Users/dankna/Installed/gcc-4.2.0/libobjc/objc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc/config -I../../host-i386-apple-darwin8.9.1/gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../include -I../.././libobjc/../boehm-gc/include -I../boehm-gc/include /Users/dankna/Installed/gcc-4.2.0/libobjc/thr-objc.c /Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/xgcc -B/Users/dankna/Installed/gcc-4.2.0/host-i386-apple-darwin8.9.1/gcc/ -B/usr/local/i386-apple-darwin8.9.1/bin/ -B/usr/local/i386-apple-darwin8.9.1/lib/ -isystem /usr/local/i386-apple-darwin8.9.1/include -isystem /usr/local/i386-apple-darwin8.9.1/sys-include -c -I. -I/Users/dankna/Installed/gcc-4.2.0/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/Users/dankna/Installed/gcc-4.2.0/libobjc/objc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../gcc/config -I../../host-i386-apple-darwin8.9.1/gcc -I/Users/dankna/Installed/gcc-4.2.0/libobjc/../include -I../.././libobjc/../boehm-gc/include -I../boehm-gc/include /Users/dankna/Installed/gcc-4.2.0/libobjc/thr-objc.c -fno-common -DPIC -o .libs/thr-objc.o
[Bug testsuite/32038] New: gfortran.dg/pr25603.f is invalid code
The testcase gfortran.dg/pr25603.f is invalid code. The following variables are not initialized: lhelpa lhelp lcn lbn lan ldcdy ldcdx lkm ltm lvg lug lvm lum lhvar lzet ldep lvdep ltstr lustr lobuk ltavr lsteph lhmix lz0 lelevy lelevx lelev ldkzh ldkzm lq lpstep lpi lwz lvstep lvy lustep lux ltstep lpot lcstep lc They should be initialized with a value (like 1) if the test is to be run, otherwise we access array elements out of range. I suggest the following patch be applied: Index: gcc/testsuite/gfortran.dg/pr25603.f === --- gcc/testsuite/gfortran.dg/pr25603.f (revision 124903) +++ gcc/testsuite/gfortran.dg/pr25603.f (working copy) @@ -44,6 +44,48 @@ C call abort endif + LHELPA = 1 + LHELP = 1 + LCN = 1 + LBN = 1 + LAN = 1 + LDCDY = 1 + LDCDX = 1 + LKM = 1 + LTM = 1 + LVG = 1 + LUG = 1 + LVM = 1 + LUM = 1 + LHVAR = 1 + LZET = 1 + LDEP = 1 + LVDEP = 1 + LTSTR = 1 + LUSTR = 1 + LOBUK = 1 + LTAVR = 1 + LSTEPH = 1 + LHMIX = 1 + LZ0 = 1 + LELEVY = 1 + LELEVX = 1 + LELEV = 1 + LDKZH = 1 + LDKZM = 1 + LQ = 1 + LPSTEP = 1 + LPI = 1 + LWZ = 1 + LVSTEP = 1 + LVY = 1 + LUSTEP = 1 + LUX = 1 + LTSTEP = 1 + LPOT = 1 + LCSTEP = 1 + LC = 1 + CALL BAR2(NX,NY,NZ,NT,NTIME,NWINDX,NWINDY,NSINKS,NFILT,XSTART, * YSTART,ZSTART,TSTART,DELTAX,DELTAY,DELTAZ,DELTAT,PHI,DL, * DX,DY,DZ,IB,IK,ITY,NCOUNT,NPRINT,NGRAPH,NPSTEP,NGSTEP,LAST, The initial reason I catched this is that I sometimes run the testsuite with -fbounds-check, which fails in this case. -- Summary: gfortran.dg/pr25603.f is invalid code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32038
[Bug fortran/32036] Multiple evaluation of array index with bounds checking
-- fxcoudert 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-05-22 12:25:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32036
[Bug fortran/32021] Fix,document,remove GFORTRAN_* environment variables
-- fxcoudert 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-05-22 12:25:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
[Bug fortran/31971] Simple Fortran code fails with ICE
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-22 12:36
---
(In reply to comment #2)
The OS is Fedora 6.
No ICE for me on i686 with Fedora Core 6. I suspect this will be hard to
reproduce. Could you provide us with a backtrace, by doing the following:
1. run gfortran with -v: gfortran-43 -v -save-temps -c test.for
2. in the output generated, look at the line right after the version line
(ie, the line after gcc version 4.3.0 20070517 (experimental)). This is a
long line, that runs an executable called f951 and located in
${installdir}/libexec/gcc/i686-pc-linux-gnu/4.3.0
3. Run this executable, with all the arguments, prefixed with gdb -args.
That will give something like:
gdb -args
/tmpdir/opt/gfortran/gfortran-20070522/bin/../libexec/gcc/i386-pc-linux-gnu/4.3.0/f951
a.for -ffixed-form -quiet -dumpbase a.for -mtune=i386 -auxbase a -version
-fintrinsic-modules-path
/tmpdir/opt/gfortran/gfortran-20070522/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/finclude
-o /tmp/ccUoun2p.s
4. When the illegal instruction error happens in gdb, type (at the gdb
prompt) where. Post the output of that command here.
Thanks for your help!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31971
[Bug fortran/31971] Simple Fortran code fails with ICE
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-22 12:40 --- (In reply to comment #3) I have Fedora 6 on x86-64. Works OK here. However, we have a leak. Well, the leak is also triggered by the simple following two lines: SUBROUTINE XYZ END ==10212== 1,012 (860 direct, 152 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 7 ==10212==at 0x4005400: malloc (vg_replace_malloc.c:149) ==10212==by 0x847685A: xmalloc (xmalloc.c:147) ==10212==by 0xBEC3F66F: ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31971
[Bug fortran/32036] Multiple evaluation of array index with bounds checking
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-22 13:01 --- Another testcase (from gfortran.fortran-torture/execute/der_io.f90), probably the same bug: $ cat der_io.f90 type xyz_type integer :: x end type xyz_type type (xyz_type), dimension(3) :: xyz xyz(1)%x = 1 xyz(2)%x = 0 xyz(3)%x = 0 write (*, *) xyz(bar()) contains integer function bar() integer, save :: i = 1 bar = i i = i + 1 end function end $ gfortran der_io.f90 ./a.out 1 $ gfortran der_io.f90 -fbounds-check ./a.out 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32036
[Bug bootstrap/25502] Werror problem in build
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-22 13:06 --- (In reply to comment #7) I plan to follow up in stage 1 of 4.3 ping? There was a patch for %I64 proposed here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00767.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug c++/32039] New: Using declaration accepts non-visible members from base classes
The following code should not compile:
struct A
{
int foo(int);
};
struct B : public A
{
int foo(long);
// using A::foo; // This would make it visible
};
struct C : public B
{
using A::foo; // A::foo should not be visible
};
The problem should be that B::foo hides A::foo from class C. Clause 7.3.3/14 of
the C++ standard says the using declaration should not work, in this case -
class A is not a direct base class of class C. However, GCC 4.1.1 accepts it
with no diagnostic.
--
Summary: Using declaration accepts non-visible members from base
classes
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039
[Bug testsuite/32038] gfortran.dg/pr25603.f is invalid code
-- fxcoudert 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-05-22 13:09:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32038
[Bug c/32040] New: Including a header file inside a function block results compilation error
Hi,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problems while executing the following testcase-
--
TESTCASE
function()
{
#includestdio.h
printf(\nHELLO WORLD);
}
main()
{
function();
}
-
PROBLEM
The above testcase gets compiled with '-O0' optimization successfully,
but on compilation with '-O2' optimization option it gives the following
error:-
In file included from
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/stdio.h:833,
from testcase.c:6:
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h: In
function 'function':
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:35:
error: nested function 'vprintf' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:35:
error: static declaration of 'vprintf' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:42:
error: nested function 'getchar' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:42:
error: static declaration of 'getchar' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/stdio.h:446:
error: previous declaration of 'getchar' was here
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:51:
error: nested function 'getc_unlocked' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:51:
error: static declaration of 'getc_unlocked' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/stdio.h:458:
error: previous declaration of 'getc_unlocked' was here
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:58:
error: nested function 'getchar_unlocked' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:58:
error: static declaration of 'getchar_unlocked' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/stdio.h:459:
error: previous declaration of 'getchar_unlocked' was here
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:67:
error: nested function 'putchar' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:67:
error: static declaration of 'putchar' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:76:
error: nested function 'fputc_unlocked' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:76:
error: static declaration of 'fputc_unlocked' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:86:
error: nested function 'putc_unlocked' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:86:
error: static declaration of 'putc_unlocked' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:93:
error: nested function 'putchar_unlocked' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:93:
error: static declaration of 'putchar_unlocked' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:113:
error: nested function 'feof_unlocked' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:113:
error: static declaration of 'feof_unlocked' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/stdio.h:735:
error: previous declaration of 'feof_unlocked' was here
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:120:
error: nested function 'ferror_unlocked' declared 'extern'
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/bits/stdio.h:120:
error: static declaration of 'ferror_unlocked' follows non-static declaration
/usr/share/gnush4_linux_v0701-1/sh4-linux/sys-root/usr/include/stdio.h:736:
error: previous declaration of 'ferror_unlocked' was here
OBSERVATIONS
1. When stdio.h is included outside the function, it compiles with '-O0' as
well as '-O2' optimization options
2. When compiled with '-O0' but enabling all '-O2' flags, it compiles
successfully
(Command Line)
gcc -O0 testcase.c -fthread-jumps -fcrossjumping -foptimize-sibling-calls
-fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm
-fexpensive-optimizations -fstrength-reduce -frerun-cse-after-loop
-frerun-loop-opt -fcaller-saves -fpeephole2 -fschedule-insns
-fschedule-insns2 -fsched-interblock -fsched-spec -fregmove
[Bug middle-end/32033] [4.3 Regression] ICE in fold_comparison, at fold-const.c:8531 at -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-22 13:26 --- Confirmed. We enter with the unfolded tree D.2472_4 * 00 which is propagated from D.2473_6 = D.2472_4 * 0 during forwprop. inlining is not properly folding its trees during inlining of explosion_map (0). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-22 13:26:45 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32033
[Bug c/32040] Including a header file inside a function block results compilation error
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-22 13:29 --- This works as designed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32040
[Bug fortran/31298] Uninitialized variable in f951 (in read_module)
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-22 13:31 --- Tobias, what is the current status on that bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug tree-optimization/32032] [4.3 Regression] ICE in compute_antic, at tree-ssa-pre.c:1968 at -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-22 13:33 --- Confirmed. Possibly another missing has_volatile_ops. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-22 13:33:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- Comment #26 from kazssym at nifty dot com 2007-05-22 13:37 --- (In reply to comment #25) This patch (mh-interix.diff) and the previous one (interix-winnt.diff) let me successfully make bootstrap gcc-4.2-20061212 on Win2K/Interix3.5, without manual intervention, with the following configuration and no environment variables such as CFLAGS set: Is it more better to add -D_ALL_SOURCE to STAGE1_CFLAGS too? It can be defined in the toplevel configure script. -- kazssym at nifty dot com changed: What|Removed |Added CC||kazssym at nifty dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug fortran/31298] Uninitialized variable in f951 (in read_module)
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-22 13:45 --- (In reply to comment #6) Tobias, what is the current status on that bug? The attached patch is ok, except it fixes only part of the problem. I got stuck at: operator(+) = operator(.op.) That is: importing an user operator as intrinsic operator. I have several versions of patches here, which all don't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug target/10768] ICEs on compilation of ada support library for avr
--- Comment #20 from eweddington at cso dot atmel dot com 2007-05-22 14:24 --- Subject: RE: ICEs on compilation of ada support library for avr -Original Message- From: charlet at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 2:51 AM To: [EMAIL PROTECTED] Subject: [Bug target/10768] ICEs on compilation of ada support library for avr --- Comment #19 from charlet at gcc dot gnu dot org 2007-05-22 09:51 --- Just to clarify: the patch posted is only a workaround/kludge, not a real fix. Arno Then what would be a real fix that could actually be approved and committed? Eric Weddington -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
[Bug c/32040] Including a header file inside a function block results compilation error
--- Comment #2 from suma dot sharma at kpitcummins dot com 2007-05-22 14:35 --- (In reply to comment #1) This works as designed. Thank you for your reply. Please confirm whether it is expected behaviour (that means it is not a bug). But it was also observed that 1. there is a difference in result when compiled with -O0 option(with all -O2 flags enabled) and compiled with -O2 ? 2. there is a difference in result when compiled with -O2 option(with all -O2 flags disabled) and compiled with -O0 ? Please clarify... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32040
[Bug target/10768] ICEs on compilation of ada support library for avr
--- Comment #21 from charlet at adacore dot com 2007-05-22 14:26 --- Subject: Re: ICEs on compilation of ada support library for avr Then what would be a real fix that could actually be approved and committed? Fix support for long (or long long ?) in the avr back-end. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
[Bug libfortran/30690] [4.2, 4.1 only] Clean up m4 files
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-22 14:56 --- (In reply to comment #4) Waiting for 4.2 to thaw before a backport. If you think it should be backported to 4.2 (regression, serious bug), you now may backport it. Otherwise, you can close this PR. Mark Mitchell: GCC 4.2 branch open for regression fixes http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01018.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30690
[Bug c/32041] New: offsetof buglet
GCC seems to have taken the view that compound expressions are permitted as the
2nd argument to offsetof. However the implementor of the grammar forgot that
- could be used.
#include stddef.h
struct s
{
struct { float f; } sa[2];
};
enum { e = offsetof (struct s, sa-f) };
--
Summary: offsetof buglet
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug fortran/31559] [4.1 and 4.2 only] Assigning to an EXTERNAL leads to ICE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-22 15:10 --- Subject: Bug 31559 Author: burnus Date: Tue May 22 14:09:42 2007 New Revision: 124943 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124943 Log: fortran/ 2007-05-22 Tobias Burnus [EMAIL PROTECTED] PR fortran/31559 Backport from mainline. * primary.c (match_variable): External functions are no variables. testsuite/ 2007-05-22 Tobias Burnus [EMAIL PROTECTED] PR fortran/31559 Backport from mainline. * func_assign.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/func_assign.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/primary.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31559
[Bug fortran/31559] [4.1 only] Assigning to an EXTERNAL leads to ICE
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 15:14 --- Fixed in 4.2.1. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.1 and 4.2 only] Assigning|[4.1 only] Assigning to an |to an EXTERNAL leads to ICE |EXTERNAL leads to ICE Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31559
[Bug fortran/31051] [4.2 Only] gfortran bug with x and t format descriptors.
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 15:15 --- If you think it should be backported to 4.2 (regression, serious bug), you now may backport it. Otherwise, you can close this PR. Mark Mitchell: GCC 4.2 branch open for regression fixes http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01018.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31051
[Bug fortran/31540] [Regression 4.2 only] character((constant expression)) for external function
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-22 15:16 --- If you think it should be backported to 4.2 (regression, serious bug), you now may backport it. Otherwise, you can close this PR. Mark Mitchell: GCC 4.2 branch open for regression fixes http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01018.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31540
[Bug libfortran/31915] [4.2 only] Failure with unf_io_convert_3.f90
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-22 15:28 --- Subject: Bug 31915 Author: burnus Date: Tue May 22 14:27:53 2007 New Revision: 124944 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124944 Log: libgfortran/ 2007-05-22 Tobias Burnus [EMAIL PROTECTED] PR libfortran/31915 Backport from trunk. * io/transfer.c (unformatted_read): Use proper size for real(10). (unformatted_write): Ditto. testsuite/ 2007-05-22 Dominique d'Humieres [EMAIL PROTECTED] * gfortran.dg/unf_io_convert_3.f90: Fix dg directive. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/unf_io_convert_3.f90 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=31915
[Bug libfortran/31915] Failure with unf_io_convert_3.f90
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 15:28 --- Fixed for 4.2.1. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 only] Failure with |Failure with |unf_io_convert_3.f90|unf_io_convert_3.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31915
[Bug tree-optimization/31769] ICE with OpenMP and exceptions
--- Comment #2 from jakub at gcc dot gnu dot org 2007-05-22 15:30 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-22 15:30:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31769
[Bug fortran/31483] [4.1/4.2 only] ICE on fortran Code
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 15:32 --- Paul, the 4.2 branch is open again, if you want you could backport this; it seems to be a regession wrt g77. Mark Mitchell: GCC 4.2 branch open for regression fixes http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01018.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug c++/32042] New: linkage confused with scope?
The following code defines the same external function twice, once with C++
linkage, and once with C linkage. GCC 4.1.1 does not complain.
void
foo ()
{
extern int f(int);
}
extern C int f(int i); // conflict
However, the following example is properly rejected:
extern int f(int);
extern C int f(int i); // conflict
EDG rejects both examples.
It would appear that the only difference is that the C++ function is not
visible in the scope when the C function is defined, but they can't both have
external linkage.
--
Summary: linkage confused with scope?
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32042
[Bug c/32041] offsetof buglet
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-22 15:59 --- Confirmed. Same for C++. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2007-05-22 15:59:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #5 from rob1weld at aol dot com 2007-05-22 16:02 --- Thanks for confirming, Richard. It works on 4.2.0/1 and I've enclosed notes in the prior message that _probably_ explain why it is failing. In addition I just did a build (one day newer version) _without_ fold and it still halted the make and trigger a GNAT BUG in verify_flow_info. If the bootstrap is that touchy then we won't be getting many good compiles finishing (and test results submitted, and bugs fixed). Yesterday it worked, today I added --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree and it broke. --- I'm placing this here because I am reasonably certain that it is related to the problems with the fold-const.c after examining the code. Here is the output: make profiledbootstrap 21 | tee make_1_log.txt ...(Many Many lines) ranlib libdecnumber.a make[3]: Leaving directory `/opt/gcc-4_3-build/libdecnumber' make[3]: Entering directory `/opt/gcc-4_3-build/gcc' test -d po || mkdir po /usr/bin/msgfmt --statistics -o po/be.gmo /root/downloads/gcc-4_3-trunk/gcc/po/be.po 114 translated messages, 1159 fuzzy translations, 4632 untranslated messages. ...(Many lines) build/genrecog /root/downloads/gcc-4_3-trunk/gcc/config/i386/i386.md \ insn-conditions.md tmp-recog.c /root/downloads/gcc-4_3-trunk/gcc/config/i386/i386.md:18884: warning: operand 1 missing mode? /bin/sh /root/downloads/gcc-4_3-trunk/gcc/../move-if-change tmp-recog.c insn-recog.c echo timestamp s-recog ...(Many lines) ranlib libbackend.a ...(Few lines) build/genchecksum cc1-dummy cc1-checksum.c ...(Some lines) /opt/gcc-4_3-build/./prev-gcc/xgcc -B/opt/gcc-4_3-build/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -fprofile-generate -gnatpg -gnata -I- -I. -Iada -I/root/downloads/gcc-4_3-trunk/gcc/ada /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb -o ada/ali.o /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb: In function 'ALI.SCAN_ALI': /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 +===GNAT BUG DETECTED==+ | 4.3.0 20070522 (experimental) (i686-pc-linux-gnu) verify_flow_info failed| | Error detected around /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ (blank line) Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. (blank line) /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb /root/downloads/gcc-4_3-trunk/gcc/ada/ali.ads /root/downloads/gcc-4_3-trunk/gcc/ada/casing.ads /root/downloads/gcc-4_3-trunk/gcc/ada/types.ads /root/downloads/gcc-4_3-trunk/gcc/ada/gnatvsn.ads /root/downloads/gcc-4_3-trunk/gcc/ada/rident.ads /root/downloads/gcc-4_3-trunk/gcc/ada/table.ads /root/downloads/gcc-4_3-trunk/gcc/ada/butil.ads /root/downloads/gcc-4_3-trunk/gcc/ada/debug.ads /root/downloads/gcc-4_3-trunk/gcc/ada/fname.ads /root/downloads/gcc-4_3-trunk/gcc/ada/namet.ads /root/downloads/gcc-4_3-trunk/gcc/ada/alloc.ads /root/downloads/gcc-4_3-trunk/gcc/ada/hostparm.ads /root/downloads/gcc-4_3-trunk/gcc/ada/opt.ads /root/downloads/gcc-4_3-trunk/gcc/ada/osint.ads /root/downloads/gcc-4_3-trunk/gcc/ada/output.ads /root/downloads/gcc-4_3-trunk/gcc/ada/table.adb /root/downloads/gcc-4_3-trunk/gcc/ada/tree_io.ads (blank line) (blank line) raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 make[3]: *** [ada/ali.o] Error 1 make[3
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #106 from mark at codesourcery dot com 2007-05-22 16:04 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenth at gcc dot gnu dot org wrote: - we _cannot_ sink loads across stores. x = *int; *double = 1.0; the store to double may change the dynamic type of what *int points to. To be clear, you mean something like this, right: int i; int *ip = i; double *dp = (double *)i; int x; x = *ip; *dp = 1.0; ? I think that considering this code valid, and, therefore, forbidding the interchange of the last two statements, requires a perverse reading of the standard. Placement new allows you to change the dynamic type of storage; I don't think that just writing through a pointer does. A key goal of C++ relative to C was better type-safety. The placement new operator provides a facility for explicitly controlling object lifetime, for programmers that need this. Before we do anything to support the case above, we should have a crystal-clear ruling from the committee that says this is valid. Otherwise, this is exactly the kind of optimization that TBAA was designed to perform. For history, the reason I implemented TBAA in GCC was that the SGI MIPSPro C/C++ compiler did these kinds of optimizations ten years ago, and I was trying to catch us up when looking at POOMA performance on IRIX. G++ has had the freedom to interchange those stores for a long time, and I believe it should continue to have that choice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/28484] system_clock with real-type count_rate does not compile
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-22 16:16 --- Won't work on it for a while. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-10-28 22:13:07 |2007-05-22 16:16:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug fortran/28484] system_clock with real-type count_rate does not compile
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #107 from rguenther at suse dot de 2007-05-22 16:20 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Tue, 22 May 2007, mark at codesourcery dot com wrote: rguenth at gcc dot gnu dot org wrote: - we _cannot_ sink loads across stores. x = *int; *double = 1.0; the store to double may change the dynamic type of what *int points to. To be clear, you mean something like this, right: int i; int *ip = i; double *dp = (double *)i; int x; x = *ip; *dp = 1.0; ? I think that considering this code valid, and, therefore, forbidding the interchange of the last two statements, requires a perverse reading of the standard. Placement new allows you to change the dynamic type of storage; I don't think that just writing through a pointer does. A key goal of C++ relative to C was better type-safety. The placement new operator provides a facility for explicitly controlling object lifetime, for programmers that need this. I just wanted to point out that even with a perverse reading of the C++ standard we don't loose the most interesting memory operations (respectively load hoisting and store sinking). Before we do anything to support the case above, we should have a crystal-clear ruling from the committee that says this is valid. Otherwise, this is exactly the kind of optimization that TBAA was designed to perform. TBAA still performs the useful cases of load hoisting and store sinking. The perverse reading of the standard is not making programs invalid that are valid as of the strict TBAA interpretation - it just implements (IMHO) a cheap way of making placement new work. For history, the reason I implemented TBAA in GCC was that the SGI MIPSPro C/C++ compiler did these kinds of optimizations ten years ago, and I was trying to catch us up when looking at POOMA performance on IRIX. G++ has had the freedom to interchange those stores for a long time, and I believe it should continue to have that choice. So, what kind of useful transformations rely on hoisting stores or sinking loads? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #10 from daney at gcc dot gnu dot org 2007-05-22 16:21 --- This bug was triggered on the trunk by: $ svn log -r 124258 r124258 | hubicka | 2007-04-28 01:20:08 -0700 (Sat, 28 Apr 2007) | 50 lines * config/alpha/alpha.c (alpha_output_mi_thunk_osf): Use insn_locators_alloc instead of insn_locators_initialize; call reset_block_changes. * config/sparc/sparc.c (sparc_output_mi_thunk): Likewise. * config/sh/sh.c (sparc_output_mi_thunk): Likewise. * config/is64/ia64.c (ia64_output_mi_thunk): Likewise. * config/rs6000/rs6000.c (rs6000_output_mi_thunk): Likewise. * config/score/score.c (th_output_mi_thunk): Likewise. * config/mips/mips.c (mips_output_mi_thunk): Likewise. * cfglyaout.c (set_curr_insn_source_location, set_curr_insn_block): tolerate uninitialized locator info. Re-apply: * function.c (init_function_start): Don't init line number info. (expand_function_end): Update. (reset_block_changes, record_block_change, finalize_block_changes, check_block_change, free_block_changes): Kill. * function.h (reset_block_changes, record_block_change, finalize_block_changes, check_block_change, free_block_changes): Remove prototypes. (struct function): Remove ib_boundaries_block. * emit-rtl.c (make_insn_raw, make_jump_insn_raw, make_call_insn_raw): Use curr_insn_locator to initialize locator. (emit_line_note): Remove. * cfgexpand.c (expand_gimple_cond_expr): Update. (construct_exit_block): Likewise. (tree_expand_cfg): Initialize/finalize locators. * expr.c (expand_expr_real): Update. * cfglayout.c (line_locators_locs, line_locators_lines, file_locators_locs, file_locators_files): Remove. (set_block_levels): Move to cfgexpand.c. (insn_locators_initialize): Remove. (pass_insn_locators_initialize): Remove. (locations_locators_locs, locations_locators_vals): New static vars. (curr_location, last_location, curr_block, last_block, curr_rtl_loc): Likewise. (insn_locators_alloc, insn_locators_finalize, set_curr_insn_source_location, set_curr_insn_block, curr_insn_locator): New functions. (locator_location): New. (locator_line, locator_file): Rewrite. * rtl.h (emit_line_note): Kill. (insn_locators_alloc, insn_locators_finalize, set_curr_insn_source_location, set_curr_insn_block, curr_insn_locator): Declare. * tree-inline.c (initialize_cfun): Do not initialize ib_boundaries_block. * passes.c (pass_insn_locators_initialize): Remove. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug fortran/32035] 'anonymous' may be used uninitialized in this function
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-22 16:31 --- why has the variable no name for the middle end; that is a front issue for now, it might not be complaining about Integer_1 but a different variable. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug testsuite/32031] The 'status' of using the LAST_UPDATED file is unclear or inconsistent
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 16:32 --- Use gcc_update to get LAST_UPDATED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32031
[Bug tree-optimization/32032] [4.3 Regression] ICE in compute_antic, at tree-ssa-pre.c:1968 at -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug fortran/31971] Simple Fortran code fails with ICE
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-05-22 16:46 --- (In reply to comment #6) I've reproduced the problem on the official 2007-05-18 snapshot. Can you reproduce it with the binaries available from the following link? http://quatramaran.ens.fr/~coudert/gfortran/gfortran-i686-linux-20070518.tar.gz Program received signal SIGILL, Illegal instruction. 0x086b7d19 in mpfr_ceil_double () (gdb) where #0 0x086b7d19 in mpfr_ceil_double () #1 0x086b7dd2 in mpfr_get_str_compute_g () #2 0x086b8160 in mpfr_get_str () #3 0x0829cb6e in real_from_mpfr (r=0xbf9a8af0, m=0x9c1dc4c, type=0xb7c81b64, rndmode=GMP_RNDN) at ../../gcc-4.3-20070518/gcc/real.c:5045 It looks pretty much like a MPFR miscompilation to me. Do you use the GMP/MPFR libraries provided by the Fedora project, or do you use custom-made? In the later case, did you run make check after compiling them? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31971
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
| new does not change the dynamic type as it should
|
| rguenth at gcc dot gnu dot org wrote:
|
| - we _cannot_ sink loads across stores.
|
| x = *int;
| *double = 1.0;
|
| the store to double may change the dynamic type of what *int
| points to.
|
| To be clear, you mean something like this, right:
|
| int i;
| int *ip = i;
| double *dp = (double *)i;
| int x;
| x = *ip;
| *dp = 1.0;
|
| ?
|
| I think that considering this code valid, and, therefore, forbidding the
| interchange of the last two statements, requires a perverse reading of
| the standard.
I'm not sure Richard is suggesting that -- I believe, we all agree
that the above is invalid. It introduces an assumption that was not
present in Richard's previous message (Richard might want to make
explicit his assumptions). Namely, that we do know the definition of
of the object
int i;
therefore we know that we can not possibly change its dynamic type.
Consider the following instead
// tu-1.C
void f(int* p) {
*p = 90;
// ...
*(double *) p = 8.3748;
};
Is the above code invalid, independent of context? I don't think
you can find a wording in the standard that says it is invalid.
Indeed, consider this:
// tu-2.C
void f(int*);
void g() {
union {
int i;
double d;
} t;
t.i = 42;
f(t);
cout t.d endl;
}
I believe we can all agree the definition of g is valid.
-- Gaby
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #108 from gdr at cs dot tamu dot edu 2007-05-22 16:55 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
| new does not change the dynamic type as it should
|
| rguenth at gcc dot gnu dot org wrote:
|
| - we _cannot_ sink loads across stores.
|
| x = *int;
| *double = 1.0;
|
| the store to double may change the dynamic type of what *int
| points to.
|
| To be clear, you mean something like this, right:
|
| int i;
| int *ip = i;
| double *dp = (double *)i;
| int x;
| x = *ip;
| *dp = 1.0;
|
| ?
|
| I think that considering this code valid, and, therefore, forbidding the
| interchange of the last two statements, requires a perverse reading of
| the standard.
I'm not sure Richard is suggesting that -- I believe, we all agree
that the above is invalid. It introduces an assumption that was not
present in Richard's previous message (Richard might want to make
explicit his assumptions). Namely, that we do know the definition of
of the object
int i;
therefore we know that we can not possibly change its dynamic type.
Consider the following instead
// tu-1.C
void f(int* p) {
*p = 90;
// ...
*(double *) p = 8.3748;
};
Is the above code invalid, independent of context? I don't think
you can find a wording in the standard that says it is invalid.
Indeed, consider this:
// tu-2.C
void f(int*);
void g() {
union {
int i;
double d;
} t;
t.i = 42;
f(t);
cout t.d endl;
}
I believe we can all agree the definition of g is valid.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #7 from dominiq at lps dot ens dot fr 2007-05-22 16:55 --- Please try this patch on top of the previous one. Sorry, bad news again: I got the same failure (still have -mdynamic-no-pic). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug fortran/31971] Simple Fortran code fails with ICE
--- Comment #6 from magnus_os at yahoo dot se 2007-05-22 16:38 --- I've reproduced the problem on the official 2007-05-18 snapshot. This backtrace is from that: Program received signal SIGILL, Illegal instruction. 0x086b7d19 in mpfr_ceil_double () (gdb) where #0 0x086b7d19 in mpfr_ceil_double () #1 0x086b7dd2 in mpfr_get_str_compute_g () #2 0x086b8160 in mpfr_get_str () #3 0x0829cb6e in real_from_mpfr (r=0xbf9a8af0, m=0x9c1dc4c, type=0xb7c81b64, rndmode=GMP_RNDN) at ../../gcc-4.3-20070518/gcc/real.c:5045 #4 0x080c2c36 in gfc_conv_mpfr_to_tree (f=0x9c1dc4c, kind=8) at ../../gcc-4.3-20070518/gcc/fortran/trans-const.c:186 #5 0x080c30c5 in gfc_conv_constant_to_tree (expr=0x9c1dc18) at ../../gcc-4.3-20070518/gcc/fortran/trans-const.c:233 #6 0x080c315a in gfc_conv_constant (se=0xbf9a8cfc, expr=0x9c1dc18) at ../../gcc-4.3-20070518/gcc/fortran/trans-const.c:295 #7 0x080d0a1c in gfc_conv_expr (se=0xbf9a8cfc, expr=0x9c1dc18) at ../../gcc-4.3-20070518/gcc/fortran/trans-expr.c:3157 #8 0x080d0cbb in gfc_conv_expr (se=0xbf9a8da8, expr=0x9c1dc70) at ../../gcc-4.3-20070518/gcc/fortran/trans-expr.c:1142 #9 0x080d3003 in gfc_conv_expr_val (se=0xbf9a8da8, expr=0x402a) at ../../gcc-4.3-20070518/gcc/fortran/trans-expr.c:3206 #10 0x080ea997 in gfc_trans_if_1 (code=0x9c1daa0) at ../../gcc-4.3-20070518/gcc/fortran/trans-stmt.c:588 #11 0x080b44c5 in gfc_trans_code (code=0x9c1dcc8) at ../../gcc-4.3-20070518/gcc/fortran/trans.c:614 #12 0x080ec3d0 in gfc_trans_do (code=0x9c1d770) at ../../gcc-4.3-20070518/gcc/fortran/trans-stmt.c:750 #13 0x080b44a3 in gfc_trans_code (code=0x9c1d770) at ../../gcc-4.3-20070518/gcc/fortran/trans.c:622 #14 0x080ca013 in gfc_generate_function_code (ns=0x9be2940) at ../../gcc-4.3-20070518/gcc/fortran/trans-decl.c:3183 #15 0x0808d6cf in gfc_parse_file () at ../../gcc-4.3-20070518/gcc/fortran/parse.c:3264 #16 0x080ae52d in gfc_be_parse_file (set_yydebug=0) at ../../gcc-4.3-20070518/gcc/fortran/f95-lang.c:303 #17 0x08300148 in toplev_main (argc=14, argv=0xbf9a90e4) at ../../gcc-4.3-20070518/gcc/toplev.c:1051 #18 0x080f20df in main (argc=Cannot access memory at address 0x1 ) at ../../gcc-4.3-20070518/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31971
[Bug libfortran/31295] Uninitialized variable in libgfortran's _gfortran_eoshift0_4
--- Comment #3 from patchapp at dberlin dot org 2007-05-22 17:05 --- Subject: Bug number PR31295 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-05/msg01461.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31295
[Bug c/32043] New: Basic block reordering creates two images of bb2,
gcc -O2 -v reord-bb.c
Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --program-suffix=-4.1
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=default32 --enable-secureplt --with-long-double-128
--host=powerpc64-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
/usr/lib/gcc/powerpc64-suse-linux/4.1.2/cc1 -quiet -v -D__unix__
-D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux
-Asystem=unix -Asystem=posix reord-bb.c -msecure-plt -quiet -dumpbase
reord-bb.c -auxbase reord-bb -O2 -version -o /tmp/ccZm74jA.s
ignoring nonexistent directory
/usr/lib/gcc/powerpc64-suse-linux/4.1.2/../../../../powerpc64-suse-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/powerpc64-suse-linux/4.1.2/include
/usr/include
End of search list.
GNU C version 4.1.2 20061115 (prerelease) (SUSE Linux) (powerpc64-suse-linux)
compiled by GNU C version 4.1.2 20061115 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 10feb4c411697eb9e5410a2cff730e44
as -a32 -mppc -many -V -Qy -o /tmp/ccmtEC9j.o /tmp/ccZm74jA.s
GNU assembler version 2.17.50.0.5 (powerpc-suse-linux) using BFD version
2.17.50.0.5 20060927 (SUSE Linux)
/tmp/ccZm74jA.s: Assembler messages:
/tmp/ccZm74jA.s:28: Error: symbol `pushAndEnd' is already defined
==
void foo (void);
unsigned long bar (void);
static void blah (void);
int main (void)
{
blah ();
return 0;
}
static void blah (void)
{
if (bar() == (1))
{
foo();
}
__asm__ (.globl pushAndEnd);
__asm__ (pushAndEnd:);
}
;; Function main (main)
try_optimize_cfg iteration 1
try_optimize_cfg iteration 1
STC - round 1
Getting bb 0
Basic block 0 was visited in trace 0
Block 2 can't be copied because its size = 28.
Possible start of next round: 1 (key: -2622)
Basic block 2 was visited in trace 0
STC - round 2
Getting bb 1
Basic block 1 was visited in trace 1
STC - round 3
STC - round 4
Trace 1 (round 1): 0 [1] 2 [1]
Trace 2 (round 2): 1 [2622]
Connection: 1 2 exit
Fallthru edge 1-3 redirected to 3
Duplicated bb 2 (created bb 3)
Final order:
0 2 1 3
4 basic blocks, 6 edges.
Basic block 0 prev -1, next 1, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: ENTRY [100.0%] (fallthru)
Successors: 2 [73.8%] (can_fallthru) 1 [26.2%] (fallthru,can_fallthru)
Registers live at start: 1 [1] 65 [lr]
Registers live at end: 1 [1]
Basic block 1 prev 0, next 2, loop_depth 0, count 0, freq 2622, maybe hot.
Predecessors: 0 [26.2%] (fallthru,can_fallthru)
Successors: 3 [100.0%] (fallthru,can_fallthru)
Registers live at start: 1 [1]
Registers live at end: 1 [1]
Basic block 2 prev 1, next 3, loop_depth 0, count 0, freq 7378, maybe hot.
Predecessors: 0 [73.8%] (can_fallthru)
Successors: EXIT [100.0%]
Registers live at start: 1 [1]
Registers live at end: 1 [1] 3 [3] 65 [lr]
Basic block 3 prev 2, next -2, loop_depth 0, count 0, freq 2622, maybe hot.
Predecessors: 1 [100.0%] (fallthru,can_fallthru)
Successors: EXIT [100.0%]
Registers live at start: 1 [1]
Registers live at end: 1 [1] 3 [3] 65 [lr]
Emitting label for block 1
Reordered sequence:
0 bb 0 [1]
1 bb 2 [7378]
2 bb 1 [2622]
3 duplicate of 2 [2622]
try_optimize_cfg iteration 1
Deleted label in block 1.
Merged 2 and 3 without moving.
try_optimize_cfg iteration 2
(note:HI 2 0 6 NOTE_INSN_DELETED)
(note:HI 6 2 9 NOTE_INSN_FUNCTION_BEG)
;; Start of basic block 0, registers live: 1 [1] 65 [lr]
(note:HI 9 6 49 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn/f 49 9 50 0 (parallel [
(set (mem:SI (plus:SI (reg/f:SI 1 1)
(const_int -16 [0xfff0])) [0 S4 A8])
(reg/f:SI 1 1))
(set (reg/f:SI 1 1)
(plus:SI (reg/f:SI 1 1)
(const_int -16 [0xfff0])))
]) 340 {movsi_update} (nil)
(expr_list:REG_FRAME_RELATED_EXPR (set (reg/f:SI 1 1)
(plus:SI (reg/f:SI 1 1)
(const_int -16 [0xfff0])))
(nil)))
(insn/f 50 49 51 0 (set (reg:SI 0 0)
(reg:SI 65 lr)) 290 {*movsi_internal1} (nil)
(expr_list:REG_DEAD (reg:SI 65 lr)
(nil)))
(insn/f 51 50 52 0 (set (mem:SI (plus:SI (reg/f:SI 1 1)
(const_int 20 [0x14])) [0 S4 A8])
(reg:SI 0 0)) 290 {*movsi_internal1} (nil)
[Bug c/32043] Basic block reordering creates two images of bb2,
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 17:12 --- No, what GCC is doing is correct, it is ok to duplicate Basic blocks. What you are doing with the inline-asm is incorrect as you cannot jump into an inline-asm without many troubles. -- 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=32043
[Bug libfortran/31295] Uninitialized variable in libgfortran's _gfortran_eoshift0_4
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 17:19 --- Subject: Bug 31295 Author: burnus Date: Tue May 22 16:19:09 2007 New Revision: 124948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124948 Log: 2007-05-22 Tobias Burnus [EMAIL PROTECTED] PR libgfortran/31295 * intrinsics/eoshift0.c (eoshift0): Silence uninitialized warning. * intrinsics/eoshift2.c (eoshift2): Ditto. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/eoshift0.c trunk/libgfortran/intrinsics/eoshift2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31295
[Bug libfortran/31295] Uninitialized variable in libgfortran's _gfortran_eoshift0_4
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 17:19 --- Subject: Bug 31295 Author: burnus Date: Tue May 22 16:19:09 2007 New Revision: 124948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124948 Log: 2007-05-22 Tobias Burnus [EMAIL PROTECTED] PR libgfortran/31295 * intrinsics/eoshift0.c (eoshift0): Silence uninitialized warning. * intrinsics/eoshift2.c (eoshift2): Ditto. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/eoshift0.c trunk/libgfortran/intrinsics/eoshift2.c --- Comment #5 from burnus at gcc dot gnu dot org 2007-05-22 17:19 --- Fixed -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31295
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #109 from mark at codesourcery dot com 2007-05-22 17:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
Consider the following instead
// tu-1.C
void f(int* p) {
*p = 90;
// ...
*(double *) p = 8.3748;
};
Is the above code invalid, independent of context? I don't think
you can find a wording in the standard that says it is invalid.
IMO, the standard is just not clear with respect to aliasing. We cannot
rely upon it, except as a guide. As I've said throughout this thread,
it doesn't make sense to try to do close reading of the standard for
aliasing issues because it just wasn't written with those issues in
mind, just as there are all of the famous memory model issues in C.
In any case, I consider the code above invalid.
Indeed, consider this:
// tu-2.C
void f(int*);
void g() {
union {
int i;
double d;
} t;
t.i = 42;
f(t);
cout t.d endl;
}
I believe we can all agree the definition of g is valid.
No, I do not. And GCC historically has not; you are only allowed to use
the union for type-punning if the accesses are through the union
directly. That was the decision we made a long time ago regarding TBAA,
and it even appears in the manual; the -fstrict-aliasing documentation says:
The practice of reading from a different union member than the one most
recently written to (called ``type-punning'') is common. Even with
@option{-fstrict-aliasing}, type-punning is allowed, provided the memory
is accessed through the union type. So, the code above will work as
expected. However, this code might not:
@smallexample
int f() @{
a_union t;
int* ip;
t.d = 3.0;
ip = t.i;
return *ip;
@}
@end smallexample
The point here is that the compiler is allowed to decide that t.d does
not alias *ip because the latter is not a direct access through the union.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/32044] New: udivdi3 counterproductive, unwarranted use
First I am herewith re-afirming my formal request for Mr. Pinsk to refrain from
having anything to do with my submissions.
Now to the heart of the matter:
According to my (admittedly second hand (Fifth Edition of C A Reference
Manual
by Samuel P. Harbison III Guy L. Stelle Jr) reading; GCC, by not providing a
means to disable the use of libgcc (including udivdi3) is not in strict
conformance with the C standard for free-standing use through C99. __udivdi3 is
a reserved identifier
and hence non-conforming.
The irony is that, besides, being non-conforming and prejudicing free standing
applications that aim for maximum portability, it is highly counterproductive
in its own right.
Also, the forced and silent use of libgcc (lld does not show it being used)
violates one of the fundamental principles of both UNIX and C. Namely that
the user (certainly root) is to be in full and absolute command of the system
without hidden reinterpretation of his commands or MS type questions. As a
practical matter the use of __builtin_expect could be taken as signal to
allow only reordering of instructions (to avoid pipeline stalls and
reloading of caches) are to be avoided in the marked unlikely cases. Any
fundamental changes like exchanging a while and a subtraction for a
non-hardware
divide should no occur
If anybody at GCC wants to know what others (including L. Torvalds and A.
Morton) think; checking Google on udivdi3 might be instructive.
What follows are the result of tests using current versions of gcc-4.3 and
4.2.1.
I believe the results speak for themselves. Besides the data for x86 I also
have quite similar data for powerpc G4, which I will make available as a
follow on.
Program
#define NSEC_PER_SEC 10UL
int rmg(void);
int main(void)
{
/* int sec; */
return rmg();
}
int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec 1 ) {
nsec++;
while (__builtin_expect(nsec = NSEC_PER_SEC, 0)) {
nsec -= NSEC_PER_SEC;
++sec;
}
}
return sec;
}
gcc_43 -O0
-rwxr-xr-x 1 root root 8478 2007-05-22 08:23 rmgg_O0
-rw-r--r-- 1 root root 1238 2007-05-22 08:18 rmgg_O0.s
real0m27.613s
user0m27.607s
sys 0m0.003s
gcc_43 -O1
-rwxr-xr-x 1 root root 12586 2007-05-22 08:25 rmgg_O1
-rw-r--r-- 1 root root 1572 2007-05-22 08:25 rmgg_O1.s
real0m12.776s
user0m12.775s
sys 0m0.003s
gcc_43 -O2
-rwxr-xr-x 1 root root 12586 2007-05-22 08:27 rmgg_O2
-rw-r--r-- 1 root root 1874 2007-05-22 08:27 rmgg_O2.s
real0m16.415s
user0m16.414s
sys 0m0.004s
gcc_43 -Os
-rwxr-xr-x 1 root root 12586 2007-05-22 08:29 rmgg_Os
-rw-r--r-- 1 root root 1925 2007-05-22 08:29 rmgg_Os.s
real2m8.817s
user2m8.831s
sys 0m0.003s
Program
#define NSEC_PER_SEC 10UL
int rmg(void);
int main(void)
{
/* int sec; */
return rmg();
}
int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec 1 ) {
nsec++;
while (__builtin_expect(nsec = NSEC_PER_SEC, 0)) {
nsec -= NSEC_PER_SEC;
++sec;
}
}
return sec;
}
gcc_42 -O0
-rwxr-xr-x 1 root root 8471 2007-05-21 16:46 rmgg_O0
-rw-r--r-- 1 root root 1236 2007-05-21 16:41 rmgg_O0.s
time ./rmgg_O0
real0m27.678s
user0m27.680s
sys 0m0.002s
Script done on Mon 21 May 2007 04:53:29 PM EDT
gcc_42 -O1
-rwxr-xr-x 1 root root 8471 2007-05-21 16:41 rmgg_O1
-rw-r--r-- 1 root root 1572 2007-05-22 09:39 rmgg_O1.s
Script started on Mon 21 May 2007 04:56:20 PM EDT
time ./rmgg_O1
real0m12.771s
user0m12.767s
sys 0m0.003s
Script done on Mon 21 May 2007 04:56:55 PM EDT
gcc_42 -O2
-rwxr-xr-x 1 root root 8471 2007-05-21 16:41 rmgg_O2
-rw-r--r-- 1 root root 1262 2007-05-21 17:41 rmgg_O2.s
Script started on Mon 21 May 2007 04:57:14 PM EDT
time ./rmgg_O2
real0m12.532s
user0m12.531s
sys 0m0.003s
Script done on Mon 21 May 2007 04:58:18 PM EDT
gcc -Os
-rwxr-xr-x 1 root root 8471 2007-05-21 16:41 rmgg_Os
-rw-r--r-- 1 root root 1017 2007-05-21 16:40 rmgg_Os.s
Script started on Mon 21 May 2007 04:58:30 PM EDT
time ./rmgg_O2
real0m12.571s
user0m12.562s
sys 0m0.004s
Script done on Mon 21 May 2007 04:59:11 PM EDT
--
Summary: udivdi3 counterproductive, unwarranted use
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
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=32044
[Bug fortran/31971] Simple Fortran code fails with ICE
--- Comment #8 from magnus_os at yahoo dot se 2007-05-22 17:22 --- I downloaded the binaries, and no problems with those. gfortran -v Using built-in specs. Target: i386-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070518 --enable-languages=c,fortran --disable-decimal-float --build=i386-pc-linux-gnu --enable-checking=release --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20070518 (experimental) I use the GMP/MPFR libraries from Fedora 6. No other installation of MPFR has been done. cksum /usr/lib/libmpfr.a 1197190056 378788 /usr/lib/libmpfr.a Compiling the test code with the Fedora gfortran 4.1.1 compiler also works without problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31971
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Indeed, consider this:
|
| // tu-2.C
| void f(int*);
| void g() {
|union {
| int i;
| double d;
|} t;
|
| t.i = 42;
| f(t);
| cout t.d endl;
| }
|
| I believe we can all agree the definition of g is valid.
|
| No, I do not. And GCC historically has not; you are only allowed to use
| the union for type-punning if the accesses are through the union
| directly.
I am not talking of the GCC's historical behaviour here, but what the
standard actually says. For the object t, above the last write was
to the double field, therefore the read is well-defined.
-- Gaby
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #110 from gdr at cs dot tamu dot edu 2007-05-22 17:25 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Indeed, consider this:
|
| // tu-2.C
| void f(int*);
| void g() {
|union {
| int i;
| double d;
|} t;
|
| t.i = 42;
| f(t);
| cout t.d endl;
| }
|
| I believe we can all agree the definition of g is valid.
|
| No, I do not. And GCC historically has not; you are only allowed to use
| the union for type-punning if the accesses are through the union
| directly.
I am not talking of the GCC's historical behaviour here, but what the
standard actually says. For the object t, above the last write was
to the double field, therefore the read is well-defined.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/32044] udivdi3 counterproductive, unwarranted use
--- Comment #1 from malitzke at metronets dot com 2007-05-22 17:27 --- Created an attachment (id=13601) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13601action=view) *.s files I believe that the *.s files in this case a superior to the *.i files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug fortran/31971] Simple Fortran code fails with ICE
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-05-22 17:33 --- (In reply to comment #8) I use the GMP/MPFR libraries from Fedora 6. No other installation of MPFR has been done. Hum, that's more than probably it: FC6 has a GMP which contained an older version of MPFR. The Prerequisites for GCC webpage (http://gcc.gnu.org/install/prerequisites.html) says: MPFR Library version 2.2.1 (or later). Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. The version of MPFR that is bundled with GMP 4.1.x contains numerous bugs. I strongly suggest that you compile a newer MPFR, like 2.2.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31971
[Bug c/32044] udivdi3 counterproductive, unwarranted use
--- Comment #2 from malitzke at metronets dot com 2007-05-22 17:37 --- Created an attachment (id=13602) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13602action=view) *.s files for gcc-4.2 *.s files generated by gcc-4.2.1 as more responsive to the intent and superior in performance according to the selected option. -march=pentium3 make no difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #111 from mark at codesourcery dot com 2007-05-22 17:37 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should gdr at cs dot tamu dot edu wrote: | No, I do not. And GCC historically has not; you are only allowed to use | the union for type-punning if the accesses are through the union | directly. I am not talking of the GCC's historical behaviour here, but what the standard actually says. For the object t, above the last write was to the double field, therefore the read is well-defined. Suffice it to say that I disagree. I'm not debating that you can read the standard that way. But, I don't think the standard contemplated these issues in sufficient detail to make it useful in this respect. Pragmatically, I don't think that we should change GCC, after years of people using it with the current rules, to make it generate inferior code -- without clear guidance from the standards committee. IMO, that needs to go beyond a reading of the current standard; there needs to be a clear expression from the committee that, indeed, the compiler cannot use TBAA in the way that GCC has historically used it. I'm all for bringing G++ into better conformance with the standard, and agree that correctness is more important than optimization, but I don't believe that the standard was written with these considerations in mind, so I don't think it can be relied upon in this respect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/32007] [4.3 Regression] bootstrap broken on ARM v3
--- Comment #4 from tbm at cyrius dot com 2007-05-22 17:39 --- Fixed. -- tbm at cyrius dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32007
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
--- Comment #3 from tbm at cyrius dot com 2007-05-22 17:43 --- Adding Honza to cc: in the hope he can help since he fixed PR30509. -- tbm at cyrius dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug c/32043] Basic block reordering creates two images of bb2,
--- Comment #2 from yakov at emc dot com 2007-05-22 17:44 ---
Subject: Re: Basic block reordering creates two images of bb2,
What do you mean jump into an inline-asm without many troubles.?
Many troubles during execution or run-time?
Please, look at *.bbro file made by:
===
gcc -O2 -v -dB -c reord-bb.c
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --program-suffix=-4.1
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
/usr/lib/gcc/i586-suse-linux/4.1.2/cc1 -quiet -v reord-bb.c -quiet
-dumpbase reord-bb.c -dB -mtune=generic -auxbase reord-bb -O2 -version
-o /tmp/ccp5g56g.s
;; Function main (main)
try_optimize_cfg iteration 1
try_optimize_cfg iteration 1
STC - round 1
Getting bb 0
Basic block 0 was visited in trace 0
Block 2 can't be copied because its size = 267.
Possible start of next round: 1 (key: -2622)
Basic block 2 was visited in trace 0
STC - round 2
Getting bb 1
Basic block 1 was visited in trace 1
STC - round 3
STC - round 4
Trace 1 (round 1): 0 [1] 2 [1]
Trace 2 (round 2): 1 [2622]
Block 2 can't be copied because its size = 267.
Final order:
0 2 1
3 basic blocks, 5 edges.
Basic block 0 prev -1, next 1, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: ENTRY [100.0%] (fallthru)
Successors: 2 [73.8%] (can_fallthru) 1 [26.2%] (fallthru,can_fallthru)
Registers live at start: 6 [bp] 7 [sp] 20 [frame]
Registers live at end: 6 [bp] 7 [sp] 20 [frame]
Basic block 1 prev 0, next 2, loop_depth 0, count 0, freq 2622, maybe hot.
Predecessors: 0 [26.2%] (fallthru,can_fallthru)
Successors: 2 [100.0%] (fallthru,can_fallthru)
Registers live at start: 6 [bp] 7 [sp] 20 [frame]
Registers live at end: 6 [bp] 7 [sp] 20 [frame]
Basic block 2 prev 1, next -2, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: 0 [73.8%] (can_fallthru) 1 [100.0%] (fallthru,can_fallthru)
Successors: EXIT [100.0%]
Registers live at start: 6 [bp] 7 [sp] 20 [frame]
Registers live at end: 0 [ax] 6 [bp] 7 [sp] 20 [frame]
Emitting label for block 1
Reordered sequence:
0 bb 0 [1]
1 bb 2 [1]
2 bb 1 [2622]
try_optimize_cfg iteration 1
(note:HI 2 0 7 NOTE_INSN_DELETED)
(note:HI 7 2 10 NOTE_INSN_FUNCTION_BEG)
;; Start of basic block 0, registers live: 6 [bp] 7 [sp] 20 [frame]
(note:HI 10 7 44 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn/f 44 10 45 0 (set (reg:SI 2 cx)
(plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4]))) 144 {*lea_1} (nil)
(expr_list:REG_FRAME_RELATED_EXPR (parallel [
(set/f (reg:SI 2 cx)
(unspec [
(const_int 0 [0x0])
] 15))
(set/f (reg:SI 2 cx)
(unspec [
(reg/f:SI 7 sp)
] 14))
])
(nil)))
(insn 45 44 46 0 (parallel [
(set (reg/f:SI 7 sp)
(and:SI (reg/f:SI 7 sp)
(const_int -16 [0xfff0])))
(clobber (reg:CC 17 flags))
]) 208 {*andsi_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn/f 46 45 47 0 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(mem/c:SI (plus:SI (reg:SI 2 cx)
(const_int -4 [0xfffc])) [2 S4 A8])) 28 {*pushsi2} (nil)
(expr_list:REG_FRAME_RELATED_EXPR (set (reg/f:SI 7 sp)
(unspec [
(const_int 4 [0x4])
] 15))
(nil)))
(insn/f 47 46 48 0 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp)) 28 {*pushsi2} (nil)
(nil))
(insn/f 48 47 49 0 (set (reg/f:SI 6 bp)
(reg/f:SI 7 sp)) 34 {*movsi_1} (nil)
(nil))
(insn/f 49 48 50 0 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 2 cx)) 28 {*pushsi2} (nil)
(expr_list:REG_DEAD (reg:SI 2 cx)
(nil)))
(insn/f 50 49 51 0 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -4 [0xfffc])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) 542 {pro_epilogue_adjust_stack_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(note 51 50 12 0 NOTE_INSN_PROLOGUE_END)
(call_insn:HI 12 51 60 0 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI (bar) [flags 0x41] function_decl
0xb7d13180 bar) [0 S1
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes: | But, I don't think the standard contemplated | these issues in sufficient detail to make it useful in this respect. The issues has been raised on the -core reflector. -- Gaby
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | But, I don't think the standard contemplated | these issues in sufficient detail to make it useful in this respect. The issues has been raised on the -core reflector. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #113 from mark at codesourcery dot com 2007-05-22 17:54 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should gdr at cs dot tamu dot edu wrote: --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | But, I don't think the standard contemplated | these issues in sufficient detail to make it useful in this respect. The issues has been raised on the -core reflector. So that I understand, do you mean that they have been raised in the past, and settled, or that you've just raised them now? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31560] improve error message for using specification expr. of later decl.
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 17:58 ---
Created an attachment (id=13364)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13364action=view) [edit]
This is only standard conform after changing dfloat() to real(..., kind(0d0))
and after changing
call getrelval('sib', 'mea', 'test', 4, 1, MISS, work, 0)
into
call getrelval('sib', 'mea', 'test ', 4, 1, MISS, work, 0)
With these changes it is Fortran 2003 standard conform and also compiles with
NAG f95
If line 251 is commented out and line 256 uncommented, only g95 compiles it
successfully.
Since dataset, nobs and relid are all subroutine arguments, it seems
plausible to me that the order of declaration should be irrelevant, even
though it require more work by the compiler. I haven't looked at the Fortran
Standard (and probably couldn't work out what it was saying anyway ;)) to see
if there is a defined behaviour.
integer, dimension(dataset%maxsiz) :: nobs
integer, dimension(dataset%maxsiz, MAXREC) :: relid
type (ped_data) :: dataset
I think gfortran rightly rejects the file though the error message should be
improved.
NAG f95 writes:
Error: z.f90, line 253: Implicit type for DATASET
detected at [EMAIL PROTECTED]
Error: z.f90, line 253: DATASET is not of derived type
detected at [EMAIL PROTECTED]
Error: z.f90, line 256: Symbol DATASET has already been implicitly typed
detected at ::@DATASET
ifort is also better:
fortcom: Error: z.f90, line 253: The structure-name is invalid or is missing.
integer, dimension(dataset%maxsiz) :: nobs
gfortran:
Error: Expected another dimension in array declaration at (1)
and later:
Error: Symbol 'nobs' at (1) has no IMPLICIT type
If I'm not mistaken, the relevant part of the standard is:
A variable within a specification expression shall have its type
and type parameters, if any, specified by a previous declaration
in the same scoping unit, by the implicit typing rules in effect
for the scoping unit, or by host or use association. If a variable
in a specification expression is typed by the implicit typing rules,
its appearance in any subsequent type declaration statement shall
confirm the implied type and type parameters.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2007-05-22 17:58:49
date||
Summary|Array size declaration |improve error message for
|depended on order of|using specification expr. of
|declaration of variable |later decl.
|containing size |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
[Bug fortran/31560] improve error message for using components of later decl. variables in specification expressions
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 GCC host triplet|linux | GCC target triplet|i386| Last reconfirmed|2007-05-22 17:58:49 |2007-05-22 18:01:33 date|| Summary|improve error message for |improve error message for |using specification expr. of|using components of later |later decl. |decl. variables in ||specification expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement | new does not change the dynamic type as it should | | gdr at cs dot tamu dot edu wrote: | --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 --- | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the | dynamic type as it should | | mark at codesourcery dot com [EMAIL PROTECTED] writes: | | | But, I don't think the standard contemplated | | these issues in sufficient detail to make it useful in this respect. | | The issues has been raised on the -core reflector. | | So that I understand, do you mean that they have been raised in the | past, and settled, or that you've just raised them now? I just raised it, mainly because I do not believe your conclusions are right. The type information you can get from write and read are not just those appearing lexically in a scope. In fact, the semantics is defined in terms of the run time read and write access. That is what makes C a strongly typed and weakly check language (DMR). This whole issue does not mean you have to abandon TBAA. It means you have be careful in how you use the information gained from TBAA. In particular, many conclusions are OK when you have the definition of the objects at hand. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31515] internal compiler segmentation fault
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-22 18:05 --- Close as works for me as it works with the released gfortran 4.2 and with the current 4.3 developer version. You can your Linux vendor for a GCC/gfortran 4.2 (some already have optionally 4.2). Prebuild version can be found at http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux or you could build gfortran yourself. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31515
[Bug fortran/27698] subroutine _foo draws unclassifiable statement instead of a useful error.
--- Comment #15 from aldot at gcc dot gnu dot org 2007-05-22 18:10 --- (In reply to comment #14) Can this be considered fixed? The initial issue is IMO fixed, the other questions raised in this PR are not dealt with, AFAIK. See comments #8 to #10. Due to these, i did not close the report yet, please do so if you think it's sufficiently fixed. thanks, -- aldot at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-05-21 11:53:24 |2007-05-22 18:10:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #115 from dberlin at gcc dot gnu dot org 2007-05-22 18:10 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 22 May 2007 16:54:24 -, mark at codesourcery dot com [EMAIL PROTECTED] wrote: --- Comment #113 from mark at codesourcery dot com 2007-05-22 17:54 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should gdr at cs dot tamu dot edu wrote: --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | But, I don't think the standard contemplated | these issues in sufficient detail to make it useful in this respect. The issues has been raised on the -core reflector. So that I understand, do you mean that they have been raised in the past, and settled, or that you've just raised them now? And if you've raised them now, can you please try to ensure that the discussion covers what to do if the union'ing happens outside the current translation unit? IE What to do about cases where 1. One union member is written 2. We are being passed the address of a union member at the same offset 3. It then it is casted to a pointer to the type of the union member from 1. 4. It is stored/loaded It is literally impossible to know whether the pointers being passed into a function are from unions or not, since the union'ing may occur outside of our translation unit. This is true unless it is a static function whose callers do not pass in pointers that are ever acquired externally. If you take a strict reading of the standard that union'ing makes everything okay, even when you can't see their may have been a union, then you simply cannot perform TBAA except for completely local variables, or when you are dealing with static function arguments that meet the parameters above, or when you can get a guarantee you have the whole program. The ideal resolution here would be that all accesses through a union must be must be visibly accessing through a union type. This is one of the proposed resolutions to the similar problem in C (there were also proposals that said something about TBAA changing at function boundaries, but these are ridiculous given the fact that it does not specify what happens if you inline, etc, so that the function boundaries aren't where they were originally). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug java/32045] New: unknown option -e for test command in gen-classlist.sh
The shell script libjava/classpath/lib/gen-classlist.sh uses test -e which is not supported in a regular Solaris /bin/sh. Work-around: - comment out lines 58 and 66 in gen-classlist.sh - substitute option -e with -f at line 98 in gen-classlist.sh -- Summary: unknown option -e for test command in gen-classlist.sh Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Andre dot Schneider at eas dot iis dot fraunhofer dot de GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32045
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #116 from dberlin at gcc dot gnu dot org 2007-05-22 18:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 22 May 2007 17:01:40 -, gdr at cs dot tamu dot edu [EMAIL PROTECTED] wrote: --- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement | new does not change the dynamic type as it should | | gdr at cs dot tamu dot edu wrote: | --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 --- | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the | dynamic type as it should | | mark at codesourcery dot com [EMAIL PROTECTED] writes: | | | But, I don't think the standard contemplated | | these issues in sufficient detail to make it useful in this respect. | | The issues has been raised on the -core reflector. | | So that I understand, do you mean that they have been raised in the | past, and settled, or that you've just raised them now? I just raised it, mainly because I do not believe your conclusions are right. The type information you can get from write and read are not just those appearing lexically in a scope. In fact, the semantics is defined in terms of the run time read and write access. That is what makes C a strongly typed and weakly check language (DMR). This whole issue does not mean you have to abandon TBAA. It means you have be careful in how you use the information gained from TBAA. In particular, many conclusions are OK when you have the definition of the objects at hand. Uh, you do more or less have to abandon TBAA for pointer arguments unless you can account for every single caller of your function, and ensure that none of them are passing you pointers external to what your compiler can see. This case is *extremely rare* outside of the user giving us a whole program guarantee. TBAA's main use is in fact, in disambiguating pointer arguments. If you take that away, it becomes pretty much useless. It's guarantees about local objects were never interesting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/32023] No casts in lvalue error message
--- Comment #2 from nshmyrev at yandex dot ru 2007-05-22 18:16 --- Ok, I understand it. Gcc dropped support for cast in lvalues. But can the message be more specific about the problem itself. It's really hard to understand the reason from the current one. -- nshmyrev at yandex dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|Invalid lvalue in void* |No casts in lvalue error |increment error inconsitensy|message http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #117 from gdr at cs dot tamu dot edu 2007-05-22 18:19 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should dberlin at dberlin dot org [EMAIL PROTECTED] writes: [...] | And if you've raised them now, can you please try to ensure that the | discussion covers what to do if the union'ing happens outside the | current translation unit? | | IE What to do about cases where | 1. One union member is written | 2. We are being passed the address of a union member at the same offset | 3. It then it is casted to a pointer to the type of the union member from 1. | 4. It is stored/loaded Thanks for reminding all those points. I'll ensure that I make those points stand in subsequence messages. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/32023] No casts in lvalue error message
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 18:27 --- t.c:9: error: lvalue required as increment operand I don't see what the problem is, the error message is clear, a lvalue is required for the increment operand. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug fortran/32035] 'anonymous' may be used uninitialized in this function
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-22 18:29 --- why has the variable no name for the middle end; that is a front issue for now Hmm, why did this trick to get rid of PRs not work? ;-) Reduced test case: subroutine Test implicit none integer,volatile :: Integer_1 integer :: Integer_4 character(len=3) :: String_1 String_1 = '124' select case(String_1) case default stop end select Integer_1 = 3 do Integer_4 = 1, Integer_1 String_1 = '098' select case(String_1) case default stop end select end do end subroutine Test Gives two bogus warnings: warning: 'integer_4' may be used uninitialized in this function warning: 'anonymous' may be used uninitialized in this function The integer_4 warning is completely surprising: int4 integer_4; [...] integer_4 = 1; if (integer_4 = D.1366) [...] D.1373 = integer_4 == D.1366; integer_4 = integer_4 + 1; I fail to see why it could be seen as undefined. For anonymous I don't see what goes wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug fortran/32035] 'anonymous' may be used uninitialized in this function
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-22 18:32 --- It might have to do with stop not being marked as noreturn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug c/32023] No casts in lvalue error message
--- Comment #4 from nshmyrev at yandex dot ru 2007-05-22 18:33 --- gcc can explain why ((void **)a) is not lvalue, it's really not that clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #118 from mark at codesourcery dot com 2007-05-22 18:34 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should gdr at cs dot tamu dot edu wrote: Thanks for reminding all those points. I'll ensure that I make those points stand in subsequence messages. I think it's also worth pointing out to the committee that the more aggressive aliasing rules (in which only access directly through a union is allowed) have been GNU C/C++ practice for a long time. I would guess that we made this change around the year 2000. So, there's a large body of code that conforms to the requirements of the aggressive interpretation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug java/32045] unknown option -e for test command in gen-classlist.sh
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 18:36 --- You did not follow the instructions on installation (http://gcc.gnu.org/install/): The Solaris 2 /bin/sh will often fail to configure libstdc++-v3, boehm-gc or libjava. We therefore recommend using the following initial sequence of commands % CONFIG_SHELL=/bin/ksh % export CONFIG_SHELL and proceed as described in the configure instructions. In addition we strongly recommend specifying an absolute path to invoke srcdir/configure. test -e is part of POSIX already, just solaris's /bin/sh's builtin for test does not support it (read the man page for test further information). -- 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=32045
