[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output
--- Comment #7 from dominiq at lps dot ens dot fr 2007-08-30 07:03 --- Subject: Re: [4.3 regression] Missing last digit is some formatted output > gives the output > > 1.797693134862316E+30^@ 2.225073858507201E-30^@ ^@ is binary 0 and is not display on my terminal. If I send the output to a file and look at it with vi, I do see the [EMAIL PROTECTED] Could people using 64 bit system pass the test(s) with -m32? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.
--- Comment #13 from andreagrassi at sogeasoft dot com 2007-08-30 07:54
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Ok, Ken, I understood. Thank you again for your detailed explanation.
Your good manner of answering has been useful for me, unlike the 2 your
colleagues...
A last thing if you can explain me:
Why the compiler report an error in my code, whereas if a modify my invalid
code splitting the "main()" and the "a()" functions into different sources
and the I compile even no warnings !! Why the compiler is so strict (1
error ) and the linker so permissive (0 warnings) ?
If the signature was different even the linker should report an error .
If the linker (that is the merger of the functions) is able to use this code
merging the 2 functions with different signatures, I don't understand why
the compiler should reject my code.
Friendly, according to me, this remains not a real error, the compiler could
be able to handle this case, don't you ?
However, good work to you and all the gcc staff. Bye.
Andrea
Le informazioni contenute in questo messaggio di posta elettronica sono di
natura confidenziale; qualsiasi pubblicazione, utilizzo o diffusione anche
parziale dello stesso non può essere effettuata senza autorizzazione e
potrebbe costituire un illecito penale ai sensi del Decreto Legs.vo N°
196/2003 sulla Protezione dei Dati Personali e del Codice Penale, Art.
617-621-635 bis oltre che della legge 547/93. Qualora non siate tra i
legittimi destinatari di questa e-mail Vi preghiamo cortesemente di
cancellarla dal Vostro sistema dopo aver notificato al mittente, rispondendo
alla comunicazione, l'errore da questi commesso.
> -Messaggio originale-
> Da: raeburn at raeburn dot org [mailto:[EMAIL PROTECTED]
> Inviato: mercoledì 29 agosto 2007 23.51
> A: [EMAIL PROTECTED]
> Oggetto: [Bug c/33219] Error in compiling when there is a
> function with
> a char parameter called before its declaration with inline parameters.
>
>
>
>
> --- Comment #12 from raeburn at raeburn dot org
> 2007-08-29 21:51 ---
> Subject: Re: Error in compiling when there is a function
> with a char parameter
> called before its declaration with inline parameters.
>
> On Aug 29, 2007, at 13:39, andreagrassi at sogeasoft dot com wrote:
> > I accept the answer to gave me but then also the definition of
> >
> > a(a)
> >char a;
> > {
> > ...
> >
> > should be invalid. I don't understand why if I define
> >
> > a(char a)
> > {
> > ...
> >
> > the compiler take a as "char" and don't match with promoted type
> > giving me
> > an error whereas the other way the compiler promotes the "char a"
> > to "int"
> > ALSO IN THE DEFINITION of the function !!
>
> It would seem to make sense, wouldn't it? But that's not how the C
> standard was defined. It does cause confusion, but I guess the
> benefit of letting "new-style" code be optimized better (e.g., you
> can read a byte from memory and stuff it in the argument list,
> without having to do the signed or unsigned widening to full "int",
> or pass a "float" using 4 bytes on the stack instead of widening it
> to an 8-byte "double") while leaving the meaning of "old-style" code
> unchanged (old 1970s and 1980s compilers would always do the
> "default
> promotions", even if it slowed down the code a little) was deemed to
> be worth it. I wasn't there, and can't read the minds of the people
> on the committee, but it's a fait accompli at this point.
>
> Note too that in the 1999 version of the standard, the ability to
> write the "old-style" code is described an "obsolescent
> feature", and
> the general direction the standards are moving in seems to suggest
> that you should (1) always include a prototype declaration before
> calling a function (or include the relevant header for standard C
> functions), and (2) always use the prototype-style function
> definitions instead of the older style. Having a prototype
> declaration in scope before using a function is good practice,
> anyways, because it lets the compiler do better type-checking
> of your
> function call, even if the function definition isn't in the same file.
>
> > Why in summary
> >
> > a(a)
> >char a;// => promoted to int
> > {
> > ...
> >
> > whereas
> >
> > a(char a)// =>remains char
> > {
> > ...
> >
> > The two manner defines the SAME THING (even if in 2 different
> > forms) and
> > MUST be treated identically
>
> The C language specification says no, they're actually not
> the same.
> It causes some confusion when converting old C code to use prototype
> declarations and definitions, because you might think you could just
> move the argument declaration up without changing the semantics, but
> it does change them subtly.
>
> > Then, finishing, I don't understand because you must promote a
> > parameter
> > EXPLICITLY rapresented by a cha
[Bug libstdc++/33247] New: [4.3 regression] libstdc++ testsuite_abi.cc build failure
seen with 4.3 20070829, configured with --enable-targets=all, binutils-2.18
the libstdc++ testsuite (32bit) fails, 64bit works:
Executing on host: /home/doko/gcc/snap/gcc-snapshot-20070829/build/./gcc/g++
-shared-libgcc -B/home/doko/gcc/snap/gcc-snapsh
ot-20070829/build/./gcc -nostdinc++
-L/home/doko/gcc/snap/gcc-snapshot-20070829/build/powerpc-linux-gnu/libstdc++-v3/src
-L/
home/doko/gcc/snap/gcc-snapshot-20070829/build/powerpc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/lib/gcc-snapshot/powerpc-linu
x-gnu/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT
-ffunction-sections -fdata-sections -fmessage-l
ength=0 -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/doko/gcc/snap/gcc-snapshot-20070829/build/powerpc-linux-gnu
/libstdc++-v3/include/powerpc-linux-gnu
-I/home/doko/gcc/snap/gcc-snapshot-20070829/build/powerpc-linux-gnu/libstdc++-v3/inc
lude -I/home/doko/gcc/snap/gcc-snapshot-20070829/src/libstdc++-v3/libsupc++
-I/home/doko/gcc/snap/gcc-snapshot-20070829/src/
libstdc++-v3/include/backward
-I/home/doko/gcc/snap/gcc-snapshot-20070829/src/libstdc++-v3/testsuite/util
-I/home/doko/gcc/
snap/gcc-snapshot-20070829/src/libstdc++-v3/testsuite -w -c -o testsuite_abi.o
/home/doko/gcc/snap/gcc-snapshot-20070829/sr
c/libstdc++-v3/testsuite/util/testsuite_abi.cc(timeout = 600)
/tmp/ccOIM2tb.s: Assembler messages:
/tmp/ccOIM2tb.s:25154: Warning: setting incorrect section attributes for
.rodata._ZN9__gnu_cxxL16__stl_prime_listE
output is:
/tmp/ccOIM2tb.s: Assembler messages:
/tmp/ccOIM2tb.s:25154: Warning: setting incorrect section attributes for
.rodata._ZN9__gnu_cxxL16__stl_prime_listE
ERROR: tcl error sourcing
/home/doko/gcc/snap/gcc-snapshot-20070829/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not compile testsuite_abi.cc
while executing
"error "could not compile $f""
(procedure "v3-build_support" line 57)
invoked from within
"v3-build_support"
(file
"/home/doko/gcc/snap/gcc-snapshot-20070829/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
line 22)
invoked from within
"source
/home/doko/gcc/snap/gcc-snapshot-20070829/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/home/doko/gcc/snap/gcc-snapshot-20070829/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
testcase
/home/doko/gcc/snap/gcc-snapshot-20070829/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
completed in 35 seconds
--
Summary: [4.3 regression] libstdc++ testsuite_abi.cc build
failure
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33247
[Bug tree-optimization/33246] Missed opportunities for vectorization due to data ref analysis
--- Comment #2 from steven at gcc dot gnu dot org 2007-08-30 08:07 --- Having this case vectorized might help us look better compared to other compilers. gfortran produces a 65% slower "fatigue" binary than the faster compiler (Sun f95, see http://www.eleves.ens.fr/home/coudert/benchmark.pdf) -- steven 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-08-30 08:07:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33246
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 --- (In reply to comment #2) > I suspect this might be due to not updating the rd information after > unrolling. > Can you check if > analyze_insns_in_loop() (which calls df_analyze()) is being called just before > the problematic unrolling ? it looks like it's called just before the unroller actually transforms somthing, but not before the (failing) analysis. But when I add a call to it in decide_peel_completely the analysis still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug middle-end/32758] [4.3 Regression] ecj1 hangs
--- Comment #32 from jakub at gcc dot gnu dot org 2007-08-30 08:27 --- Subject: Bug 32758 Author: jakub Date: Thu Aug 30 08:27:33 2007 New Revision: 127923 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127923 Log: PR middle-end/32758 * dce.c (dce_process_block): Don't delete setters of artificially used registers. * gcc.dg/cleanup-12.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cleanup-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 08:41 --- Please attach such long examples the next time. This makes the bug report easier to read and saves one from removing all the line breaks that get added. I tried your example with NAG f95 and it reports: Error: line 278: Array constructor values have differing CHARACTER lengths (21 and 32) If I fix this error, it compiles with NAG f95 without errors. Independent of this fix, it creashes with gfortran; minimal test case: PROGRAM fptest IMPLICIT NONE CHARACTER (LEN=*), DIMENSION(1), PARAMETER :: var = 'a' CALL parsef (var) contains SUBROUTINE parsef (Var) IMPLICIT NONE CHARACTER (LEN=*), DIMENSION(:), INTENT(in) :: Var END SUBROUTINE parsef END PROGRAM fptest -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org OtherBugsDependingO||32834 nThis|| GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||ice-on-valid-code Known to fail||4.1.3 4.2.2 4.3.0 Summary|ICE when compilation|ICE with parameter string ||arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug middle-end/32758] [4.3 Regression] ecj1 hangs
--- Comment #33 from jakub at gcc dot gnu dot org 2007-08-30 08:43 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
[Bug libstdc++/33247] [4.3 regression] libstdc++ testsuite_abi.cc build failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-30 09:03 --- I see the same thing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33247
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-30 09:04 --- Forgot to mention that gfortran gives the same error as NAG f95 but only when using -std=f95 or f2003: Error: The CHARACTER elements of the array constructor at (1) must have the same length (24/32) Work around: Change CHARACTER (LEN=*), DIMENSION(nvar), PARAMETER :: var = 'a' into CHARACTER (LEN=20), DIMENSION(nvar), PARAMETER :: var = 'a' and the ICE is gone. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19276 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-30 09:07 --- Created an attachment (id=14138) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14138&action=view) Testcase of comment 0 as file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-08-30 09:07 --- I don't think the patch fixes anything. Can you elaborate on "D.8892_26 is a non-pointer variable, eliminating edges." but D.8892 _is_ a pointer. Or is it just that D.8892_26 is ultimately copied from a pointer that doesn't have a constraint? (because it is initialized from a call, this is what the patch would "fix" - it creates a lot more NMTs and (by luck?) sees that now, even if with and without the patch D.8895_29 and __tmp_27 point to anything, they may point to the same thing) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199
[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT
--- Comment #7 from cyberflex at mail dot ru 2007-08-30 09:34 --- Problem is reproducible, but it likely should be posted to other list. It looks that behaviour of particular utility "rfcomm" is such specific that it not only ignores some signals but also forks one more child in detached state. Here how I do reproduce it: As root do 1. attach my USB bluetooth dondle and bring it up "hciconfig hci0 up" 2. run "./test" 3. run "ps ax | grep rfcomm" Very soon I see that the only instance of rfcomm is running (PID is not changed) and instances of rfcomm started later are exiting because interface hci0 is busy. Some processes still need SIGINT due to notify their children before exiting or be killed with other signal such as -9 The bug, posted here looks like needs resolution as INVALID. Oh, I terribly sorry What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT
--- Comment #8 from cyberflex at mail dot ru 2007-08-30 09:34 --- Created an attachment (id=14139) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14139&action=view) test.java test.java to run with bt_connect.bash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT
--- Comment #9 from cyberflex at mail dot ru 2007-08-30 09:35 --- Created an attachment (id=14140) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14140&action=view) script bt_connect.bash script to use with 14139: test.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT
--- Comment #10 from cyberflex at mail dot ru 2007-08-30 09:36 --- Created an attachment (id=14141) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14141&action=view) one more helper script bt_param.bash helper script for 14139: test.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT
--- Comment #11 from cyberflex at mail dot ru 2007-08-30 09:41 --- It looks that the fact that, rfcomm in some situations are killed when shell script called with Proces.destroy() and in some situations don't misleded me. Also the strace shows that rfcomm sleep inside accept system call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-08-30 09:49
---
Note that even with the proposed patch we generate different code dependent on
if -g is enabled or not. Starting with the first alias pass there are
differences
in the has_volatile_ops annotations!
@@ -3818,9 +3823,9 @@ int test01() ()
D.8890_24 = (struct _Sp_counted_base_impl *) D.8889_23;
__d = __d.79;
D.8891_25 = &D.8890_24->D.8307;
- D.8891_25->_vptr._Sp_counted_base ={v}
&_ZTVNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EEE[2];
- D.8891_25->_M_use_count ={v} 1;
- D.8891_25->_M_weak_count ={v} 1;
+ D.8891_25->_vptr._Sp_counted_base =
&_ZTVNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EEE[2];
+ D.8891_25->_M_use_count = 1;
+ D.8891_25->_M_weak_count = 1;
D.8890_24->D.8307._vptr._Sp_counted_base =
&_ZTVNSt3tr121_Sp_counted_base_implIP1BNS_11_Sp_deleterIS1_EELN9__gnu_cxx12_Lock_policyE1EEE[2];
D.8890_24->_M_ptr = D.8855_22;
D.8890_24->_M_del = __d;
@@ -3840,7 +3845,7 @@ int test01() ()
goto ;
:
- D.8895_29 ={v} &__tmp_27->_M_use_count;
+ D.8895_29 = &__tmp_27->_M_use_count;
if (__gthrw_pthread_cancel != 0B)
goto ;
else
...
etc.
I'm trying to reduce the testcase further based on such differences.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199
[Bug c/33238] [4.1/4.2/4.3 Regression] ICE on statement expression using variable-sized structure in tree_low_cst, at tree.c:4502
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-30 10:06 --- 4.1 ICEs during expansion of stack vars while 4.2 and 4.3 ICE in force_constant_size, at gimplify.c:718. 4.1 backtrace: #1 0x00808124 in tree_low_cst (t=0x2ad57f2a61c0, pos=1) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree.c:4399 #2 0x0082c662 in expand_one_stack_var (var=0x2ad57f7a9840) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/cfgexpand.c:583 #3 0x0082c9ce in expand_one_var (var=0x2ad57f7a9840, toplevel=1 '\001') at /space//rguenther/src/svn/gcc-4_1-branch/gcc/cfgexpand.c:737 #4 0x0082cfd2 in expand_used_vars () at /space//rguenther/src/svn/gcc-4_1-branch/gcc/cfgexpand.c:992 #5 0x0082ebd7 in tree_expand_cfg () at /space//rguenther/src/svn/gcc-4_1-branch/gcc/cfgexpand.c:1593 trunk backtrace: #1 0x0070bcbc in force_constant_size (var=0x2ac3445f1420) at /space/rguenther/src/svn/pointer_plus/gcc/gimplify.c:718 #2 0x0070bfc4 in gimple_add_tmp_var (tmp=0x2ac3445f1420) at /space/rguenther/src/svn/pointer_plus/gcc/gimplify.c:735 #3 0x00726a78 in gimplify_target_expr (expr_p=0x2ac344f3a1d0, pre_p=0x7fff665d2fc8, post_p=0x7fff665d2fc0) at /space/rguenther/src/svn/pointer_plus/gcc/gimplify.c:4377 #4 0x007311a3 in gimplify_expr (expr_p=0x2ac344f3a1d0, pre_p=0x7fff665d2fc8, post_p=0x7fff665d2fc0, gimple_test_f=0x8b6bc3 , fallback=fb_none) at /space/rguenther/src/svn/pointer_plus/gcc/gimplify.c:5876 #5 0x0072702d in gimplify_stmt (stmt_p=0x2ac344f3a1d0) at /space/rguenther/src/svn/pointer_plus/gcc/gimplify.c:4425 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.0.0 4.1.2 4.2.1 4.3.0 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2007-08-30 10:06:47 date|| Summary|[4.2.1 regression] ICE on |[4.1/4.2/4.3 Regression] ICE |statement expression using |on statement expression |variable-sized structure in |using variable-sized |tree_low_cst, at tree.c:4502|structure in tree_low_cst, ||at tree.c:4502 Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33238
[Bug tree-optimization/33243] Missed opportunities for vectorization due to unhandled real_type
--- Comment #2 from dorit at gcc dot gnu dot org 2007-08-30 10:12 --- > There are two time consuming routines in air.f90 of the Polyhedron > benchmark that are not vectorized: lines 1328 and 1354. These appear > in the top counting of execution time with oprofile: > > SUBROUTINE DERIVY(D,U,Uy,Al,Np,Nd,M) > IMPLICIT REAL*8(A-H,O-Z) > PARAMETER (NX=150,NY=150) > DIMENSION D(NY,33) , U(NX,NY) , Uy(NX,NY) , Al(30) , Np(30) > DO jm = 1 , M > jmax = 0 > jmin = 1 > DO i = 1 , Nd > jmax = jmax + Np(i) + 1 > DO j = jmin , jmax >uyt = 0. >DO k = 0 , Np(i) > uyt = uyt + D(j,k+1)*U(jm,jmin+k) >ENDDO >Uy(jm,j) = uyt*Al(i) > ENDDO > jmin = jmin + Np(i) + 1 > ENDDO > ENDDO > CONTINUE > END > > ./poly_air_1354.f90:12: note: def_stmt: uyt_1 = PHI <0.0(9), uyt_42(11)> > ./poly_air_1354.f90:12: note: Unsupported pattern. > ./poly_air_1354.f90:12: note: not vectorized: unsupported use in stmt. > ./poly_air_1354.f90:12: note: unexpected pattern. > ./poly_air_1354.f90:1: note: vectorized 0 loops in function. > > This is due to an unsupported type, real_type, for the reduction variable uyt: > (this is on an i686-linux machine) There is no "unhandled real_type" problem, you just need to use -ffast-math to allow vectorization of summation of fp types (or the new reassociation flag): pr33243b.f90:12: note: Analyze phi: uyt_1 = PHI <0.0(9), uyt_42(11)> pr33243b.f90:12: note: reduction: unsafe fp math optimization: D.1386_41 + uyt_1 pr33243b.f90:12: note: Unknown def-use cycle pattern. If you use -ffast-math the reduction is detected: pr33243b.f90:12: note: Analyze phi: uyt_1 = PHI <0.0(9), uyt_42(11)> pr33243b.f90:12: note: detected reduction:D.1386_41 + uyt_1 pr33243b.f90:12: note: Detected reduction. However, the loop will still not get vectorized because there is a non-consecutive access in the loop: pr33243b.f90:12: note: === vect_analyze_data_ref_accesses === pr33243b.f90:12: note: not consecutive access pr33243b.f90:12: note: not vectorized: complicated access pattern. This is because the stride of the accesses to D(j,k+1) and U(jm,jmin+k) in the inner-loop (k-loop) between inner-loop iterations is 1200B: DO j = jmin , jmax uyt = 0. DO k = 0 , NP(i) uyt = uyt + D(j,k+1)*U(jm,jmin+k) ENDDO Uy(jm,j) = uyt*Al(i) ENDDO In the outer-loop (j-loop) these accesses are consecutive, and also you don't need to use the -ffast-math flag. However there are other problems: 1) the compiler creates a guard to control whether to enter the inner-loop or not (cause it may execute 0 times). This creates a more involved control-flow than the outer-loop vectorizer is willing to work with. A solution would be to create this guard outside the outer-loop (in case it is invariant, as is the case here), which is like versioning the loop (or unswichting the loop). 2) if you change the loop count to something constant (just to bypass the above problem), then indeed no guard code is generated, but there is a computation (advancing an iv) in the latch block of the outer-loop (so it is not empty, and we are not willing to work with such loops). We need to clean that away. 3) After these problems are solved, we still need to deal with a non-consecutive access in the outer-loop - the store to Uy(jm,j). AFAICS, this requires either transposing the Uy array in advance, or teaching the vectorizer to "scatter" the results to the non-adjacent locations (which would be quite expensive, but we could give it a try). Alternatively, vectorizing the inner-loop would require transposing the D and U matrices. Another option is to interchange the jm loop with the j loop - I think this way all accesses would be consecutive, and we could vectorize the jm loop (which would now be a doubly-nested loop that the outer-loop vectorizer could handle). So, the PR for this testcase would be better classified under one of the above problems/missed-optimizations rather than "unhandled real_type". > > Another similar routine that also appears in the top ranked and not > vectorized due to the same unsupported real_type reasons is in air.f90:1181 > > > SUBROUTINE FVSPLTX2 > IMPLICIT REAL*8(A-H,O-Z) > PARAMETER (NX=150,NY=150) > DIMENSION DX(NX,33) , ALX(30) , NPX(30) > DIMENSION FP1(NX,NY) , FM1(NX,NY) , FP1x(30,NX) , FM1x(30,NX) > DIMENSION FP2(NX,NY) , FM2(NX,NY) , FP2x(30,NX) , FM2x(30,NX) > DIMENSION FP3(NX,NY) , FM3(NX,NY) , FP3x(30,NX) , FM3x(30,NX) > DIMENSION FP4(NX,NY) , FM4(NX,NY) , FP4x(30,NX) , FM4x(30,NX) > DIMENSION FV2(NX,NY) , DXP2(30,NX) , DXM2(30,NX) > DIMENSION FV3(NX,NY) , DXP3(30,NX) , DXM3(30,NX) > DIMENSION FV4(NX,NY) , DXP4(30,NX) , DXM4(30,NX) > COMMON /
[Bug fortran/33228] Accepts use-associated functions in MODULE PROCEDURE
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 11:44 --- I have a patch -> accept. The standard says: "C1208 (R1206) If MODULE appears in a procedure-stmt, each procedure-name in that statement shall be accessible in the current scope as a module procedure." "module procedure (2.2.3.2) : A procedure that is defined by a module subprogram." This means the following is correct: module b contains subroutine foo(a) real :: a end subroutine foo end module b module a use b implicit none interface gen module procedure foo end interface gen end module a -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-30 11:44:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33228
[Bug c/33248] New: The execution gives wrong results when compiled with mingw32-gcc 3.4.2
source file :
/*
* The execution gives wrong results when compiled with mingw32-gcc 3.4.2
* (MinGW-5.1.3)
* (no problem with previous mingw32-gcc 3.2.3 / MinGW-3.1.0)
*
* KO when REAL = float
* OK when REAL = double
*
* Expected results are : tab[0] = 123 and tab[1] = -123
*
* If instead of
*
* *p++ = (REAL) floor((double) *p + 0.5);
* *p++ = (REAL) floor((double) *p + 0.5);
*
* code is
*
* *p = (REAL) floor((double) *p + 0.5);
* p++;
* *p = (REAL) floor((double) *p + 0.5);
* p++;
*
* the execution is OK.
*/
#include
#include
#include
#define REAL float /* comment for use 'double' */
#ifndef REAL
#define REAL double
#endif
int main()
{
REAL tab[2],*p;
tab[0] = 123.456;
tab[1] = -123.456;
p = &tab[0];
*p++ = (REAL) floor((double) *p + 0.5);
*p++ = (REAL) floor((double) *p + 0.5);
fprintf(stdout,">>> tab[0] = %f, tab[1] = %f\n",
(double) tab[0],(double) tab[1]);
return 0;
}
--
Summary: The execution gives wrong results when compiled with
mingw32-gcc 3.4.2
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alduc1 at free dot fr
GCC build triplet: mingw32-gcc 3.4.2 / MinGW-5.1.3
GCC host triplet: xp sp1
GCC target triplet: win32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33248
[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-08-30 12:14 --- Created an attachment (id=14142) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14142&action=view) reduced testcase for the volatile diffs against same svn revision + the proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199
[Bug c/33248] The execution gives wrong results when compiled with mingw32-gcc 3.4.2
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-30 12:33 --- There is no sequence point between *p++ and *p. So you hit #2 of the most frequently reported (non-)bugs. *** This bug has been marked as a duplicate of 11751 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33248
[Bug c/11751] wrong evaluation order of an expression
--- Comment #79 from rguenth at gcc dot gnu dot org 2007-08-30 12:33 --- *** Bug 33248 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||alduc1 at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug fortran/33228] Accepts use-associated functions in MODULE PROCEDURE
--- Comment #2 from patchapp at dberlin dot org 2007-08-30 13:05 --- Subject: Bug number PR33228 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-08/msg02178.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33228
[Bug fortran/23261] [meta-bug] [mingw32] gfortran testsuite bugs
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-30 13:30 --- Not much use any more, closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23261
[Bug fortran/33241] ICE with parameter string arrays
-- 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-08-30 13:40:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug fortran/33228] Accepts use-associated functions in MODULE PROCEDURE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-30 13:45 --- Subject: Bug 33228 Author: burnus Date: Thu Aug 30 13:44:47 2007 New Revision: 127925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127925 Log: 2007-08-30 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33228 * interface.c (check_interface0): Improve error for external procs. (check_sym_interfaces): Fix checking of module procedures. 2007-08-30 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/33228 * gfortran.dg/generic_9.f90: Update error message. * gfortran.dg/generic_14.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/generic_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/generic_9.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33228
[Bug fortran/33228] Accepts use-associated functions in MODULE PROCEDURE
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-30 13:47 --- 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=33228
[Bug tree-optimization/33243] Missed opportunities for vectorization due to unhandled real_type
--- Comment #3 from spop at gcc dot gnu dot org 2007-08-30 14:19 --- Subject: Re: Missed opportunities for vectorization due to unhandled real_type Thanks for the detailed comments and further investigation. On 30 Aug 2007 10:12:26 -, dorit at gcc dot gnu dot org > > I couldn't compile the rest of the kernels because of the "USE kinds" - I get: > Fatal Error: Can't open module file 'kinds.mod' for reading > How do I get around that? > You can try to install the gfortran compiler, and then just build with gfortran and not with the f951 driver: ~/usr/bin/gfortran-4.3 -c -O2 -msse2 -ftree-vectorize -fdump-tree-vect-all test_fpu.f90 works fine for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33243
[Bug c++/33249] New: -O3 and -O2 give wrong results with gcc 4.1.2 on solaris sparc
The following code gives different results with -O3 (or -O2) and no
optimization.The -O3 output is wrong.
try:
$g++ -O3 test.cpp
$cat test.cpp
#include
class foo
{
int _type;
public:
foo( int t ) : _type(t) {};
bool is_1() { return _type == 1; }
bool is_23() { return _type == 2 || _type == 3; }
};
void testit( foo& e1, foo& e2 )
{
if ( e1.is_1() && e2.is_1() )
std::cout << "If - 1.1\n";
else if ( e1.is_23() && e2.is_23() )
std::cout << "If - 23.23\n";
else if ( e1.is_1() && e2.is_23() )
std::cout << "If - 1.23\n";
else if ( e1.is_23() && e2.is_1() )
std::cout << "If - 23.1\n";
else
std::cout << "If - bad\n";
}
int main()
{
for ( int i = 1; i < 4; ++i )
for ( int j = 1; j < 4; ++j )
{
foo e1(i);
foo e2(j);
testit( e1, e2 );
}
return 0;
}
result with -O3 :
$./a.out
If - 1.1
If - 1.23
If - 1.23
If - 23.1
If - 23.23
If - 23.23
If - bad
If - 23.23
If - 23.23
result without optimization :
$./a.out
If - 1.1
If - 1.23
If - 1.23
If - 23.1
If - 23.23
If - 23.23
If - 23.1
If - 23.23
If - 23.23
satya
--
Summary: -O3 and -O2 give wrong results with gcc 4.1.2 on solaris
sparc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33249
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #4 from zadeck at naturalbridge dot com 2007-08-30 14:43
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
dorit at gcc dot gnu dot org wrote:
> --- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 ---
> (In reply to comment #2)
>
>> I suspect this might be due to not updating the rd information after
>> unrolling.
>> Can you check if
>> analyze_insns_in_loop() (which calls df_analyze()) is being called just
>> before
>> the problematic unrolling ?
>>
>
> it looks like it's called just before the unroller actually transforms
> somthing, but not before the (failing) analysis. But when I add a call to it
> in
> decide_peel_completely the analysis still fails.
>
>
>
dorit,
i am having trouble exactly reproducing this example because you did not
give the svn revision and so all of the numbers are a little bit
different.
However, I am going to submit a patch which improves the dump
information a lot for these passes and we should talk about it after we
can get on the same page.
However, from looking at your posting, there are some issues that you
may want to look at before we talk:
The reaching defs problem makes a scan for all of the defs in the blocks
in the region. Once all of the defs are found, they are sorted where
the primary key is the regno.
The id's (DF_REF_ID) are then assigned based on this sorting. The
reaching defs problem actually depends on all of the defs for a regno to
be contigious.
The DF_REF_IDs are not stable between calls to df_set_blocks and any def
outside of the region has an undefined DF_REF_ID.
In your posting you have:
> Below is the output of df_ref_debug for adef in each iteration of the loop in
> latch_dominating_def:
> d40 reg 187 bb 3 insn 255 flag 0x0 type 0x0 loc 0xf7da4608(0xf7d9a4e0) chain
> { }
> d93 reg 187 bb 2 insn 40 flag 0x0 type 0x0 loc 0xf7d89cc8(0xf7d9a4e0) chain {
> }
The number after the first "d" is the DF_REF_ID. Note that they are not
contiguous.
Given the sorting that occurred, they must be contiguous. I assume from this
that
someone is holding on to old id's. This is not correct.
If you are going to play the game with df_set_blocks, you are allowed to hold
onto a
def, but not the DF_REF_ID, you cannot look at the DF_REF_ID for a def
that is not in the blocks set by df_set_blocks.
Kenny
Index: df-core.c
===
--- df-core.c (revision 127917)
+++ df-core.c (working copy)
@@ -1761,6 +1761,7 @@ df_print_regset (FILE *file, bitmap r)
/* Dump dataflow info. */
+
void
df_dump (FILE *file)
{
@@ -1778,6 +1779,33 @@ df_dump (FILE *file)
}
+/* Dump dataflow info for df->blocks_to_analyze. */
+
+void
+df_dump_region (FILE *file)
+{
+ if (df->blocks_to_analyze)
+{
+ bitmap_iterator bi;
+ unsigned int bb_index;
+
+ fprintf (file, "\n\nstarting region dump\n");
+ df_dump_start (file);
+
+ EXECUTE_IF_SET_IN_BITMAP (df->blocks_to_analyze, 0, bb_index, bi)
+ {
+ basic_block bb = BASIC_BLOCK (bb_index);
+
+ df_print_bb_index (bb, file);
+ df_dump_top (bb, file);
+ df_dump_bottom (bb, file);
+ }
+ fprintf (file, "\n");
+}
+ else df_dump (file);
+}
+
+
/* Dump the introductory information for each problem defined. */
void
Index: df.h
===
--- df.h(revision 127917)
+++ df.h(working copy)
@@ -836,6 +836,7 @@ extern bool df_reg_used (rtx, rtx);
extern void df_worklist_dataflow (struct dataflow *,bitmap, int *, int);
extern void df_print_regset (FILE *file, bitmap r);
extern void df_dump (FILE *);
+extern void df_dump_region (FILE *);
extern void df_dump_start (FILE *);
extern void df_dump_top (basic_block, FILE *);
extern void df_dump_bottom (basic_block, FILE *);
Index: loop-invariant.c
===
--- loop-invariant.c(revision 127917)
+++ loop-invariant.c(working copy)
@@ -644,6 +644,7 @@ find_defs (struct loop *loop, basic_bloc
if (dump_file)
{
+ df_dump_region (dump_file);
fprintf (dump_file, "*starting processing of loop **\n");
print_rtl_with_bb (dump_file, get_insns ());
fprintf (dump_file, "*ending processing of loop **\n");
Index: loop-iv.c
===
--- loop-iv.c (revision 127917)
+++ loop-iv.c (working copy)
@@ -280,7 +280,7 @@ iv_analysis_loop_init (struct loop *loop
df_set_blocks (blocks);
df_analyze ();
if (dump_file)
-df_dump (dump_file);
+df_dump_region (dump_file);
check_iv_ref_table_size ();
BITMAP_FREE (blocks);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug rtl-optimization/33249] -O3 and -O2 give wrong results with gcc 4.1.2 on solaris sparc
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-30 14:43 --- This works for me on x86_64 and i686. Possibly a rtl-optimization or target bug. As there were loop fixes after 4.1.2 went out can you try with the trunk of the gcc-4_1-branch or give the exact version of your compiler (gcc --version will tell)? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |rtl-optimization GCC target triplet||sparc-sun-solaris Version|unknown |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33249
[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-08-30 14:52 --- Subject: Bug 33199 Author: rguenth Date: Thu Aug 30 14:52:28 2007 New Revision: 127927 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127927 Log: 2007-08-30 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/33199 * tree-ssa-structalias.c (handle_lhs_call): New function. (find_func_aliases): In non-IPA mode make sure that for calls that return a pointer we add a constraint for the result to point to anything. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199
[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-08-30 14:56 --- (In reply to comment #23) > I don't think the patch fixes anything. Uh, sure it does. Before we were ignoring the pointer results from calls. They should point to anything. > Can you elaborate on > > "D.8892_26 is a non-pointer variable, eliminating edges." > This really means that it was never used. The only variables that are unused must come from things are not really pointers (IE don't point to anything). I can change the wording :) > but D.8892 _is_ a pointer. Or is it just that D.8892_26 is ultimately copied > from a pointer that doesn't have a constraint? Right. > (because it is initialized > from a call, this is what the patch would "fix" - it creates a lot more NMTs > and (by luck?) sees that now, even if with and without the patch D.8895_29 > and __tmp_27 point to anything, they may point to the same thing) For sure the patch is the right thing to do. Whether it fixes this bug, is the real cause of this bug, etc, i can't say. I can only say that we should be assigning &ANYTHING to the LHS of a call in !in_ipa_mode, and not doing so was a dumb oversight on my part when i fixed the call handling for !in_ipa_mode. I actually thought we were already doing this, which is why i approved this so quickly. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199
[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output (on 32bit targets)
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-30 15:03 --- Can reproduce the problems with x86-64/Linux. -m64 works, but -m32 fails. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org GCC target triplet|powerpc-apple-darwin8 | Keywords||wrong-code Summary|[4.3 regression] Missing|[4.3 regression] Missing |last digit is some formatted|last digit is some formatted |output |output (on 32bit targets) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug c/33248] The execution gives wrong results when compiled with mingw32-gcc 3.4.2
--- Comment #2 from alduc1 at free dot fr 2007-08-30 15:22 --- I do not think it is the same bug 11751. For example: *p++ = *p + 1.0; *p++ = *p + 1.0; works. But *p++ = (float) floor((double) *p + 0.5); *p++ = (float) floor((double) *p + 0.5); does not work (with float). It is not only the ++ operator that cause the problem. Why when it is compiled with gcc 3.2.3 there is no problem ? Why the equivalent code *p = (float) floor((double) *p + 0.5); p++; *p = (float) floor((double) *p + 0.5); p++; works ? I do not understand "no sequence point between *p++ and *p" ? -- alduc1 at free dot fr changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33248
[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-08-30 15:24 ---
Subject: Re: New: Missed opportunities for vectorization due to PRE
On 30 Aug 2007 02:55:17 -, spop at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The following loop showing up in the top time users in capacita.f90 is
> not vectorized because the loop latch block is non empty:
>
> ./capacita.f90:51: note: = analyze_loop_nest =
> ./capacita.f90:51: note: === vect_analyze_loop_form ===
> ./capacita.f90:51: note: not vectorized: unexpected loop form.
> ./capacita.f90:51: note: bad loop form.
> ./capacita.f90:9: note: vectorized 0 loops in function.
>
> This block contains the following code that comes from the
> partial redundancy elimination pass:
>
> bb_14 (preds = {bb_13 }, succs = {bb_13 })
> {
> :
> # VUSE { SFT.109 }
> pretmp.166_821 = g.dim[1].stride;
> goto ;
>
> }
>
PRE is just invariant hoisting. If we didn't, something else would (LIM).
> Now, if I disable the PRE with -fno-tree-pre, I get another problem on
> the data dependence analysis:
>
> base_address: &d1
> offset from base address: 0
> constant offset from base address: 0
> step: 0
> aligned to: 128
> base_object: d1
> symbol tag: d1
> FAILED as dr address is invariant
>
> /home/seb/ex/capacita.f90:46: note: not vectorized: unhandled data-ref
> /home/seb/ex/capacita.f90:46: note: bad data references.
> /home/seb/ex/capacita.f90:4: note: vectorized 0 loops in function.
>
> This fail corresponds to the following code in tree-data-ref.c
>
> /* FIXME -- data dependence analysis does not work correctly for objects
> with
> invariant addresses. Let us fail here until the problem is fixed.
> */
> if (dr_address_invariant_p (dr))
> {
> free_data_ref (dr);
> if (dump_file && (dump_flags & TDF_DETAILS))
> fprintf (dump_file, "\tFAILED as dr address is invariant\n");
> ret = false;
> break;
> }
>
> Due to the following statement:
>
> # VUSE { d1 }
> d1.33_86 = d1;
>
> So here the data reference is for d1 that is a read with the following tree:
>
> arg 1
> addressable used public static SF file /home/seb/ex/capacita.f90 line
> 11 size unit size
> align 32
> chain
> addressable used public static SF file /home/seb/ex/capacita.f90
> line 11 size unit size
> align 32 chain >>
>
> I don't really know how this could be handled as a data reference,
> because that statement has a VUSE but the type of d1 is scalar.
Yes, but it is a global, and should be looked at as any other load is.
:)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33244
[Bug c/33248] The execution gives wrong results when compiled with mingw32-gcc 3.4.2
--- Comment #3 from schwab at suse dot de 2007-08-30 16:10 --- It invokes undefined behaviour, if it breaks you get to keep the pieces. There is no requirement that you get any useful result. http://c-faq.com/expr/evalorder1.html *** This bug has been marked as a duplicate of 11751 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33248
[Bug c/11751] wrong evaluation order of an expression
--- Comment #80 from schwab at suse dot de 2007-08-30 16:10 --- *** Bug 33248 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-30 16:29 ---
> dorit,
> i am having trouble exactly reproducing this example because you did not
> give the svn revision and so all of the numbers are a little bit
> different.
it's revision 127623
> However, I am going to submit a patch which improves the dump
> information a lot for these passes and we should talk about it after we
> can get on the same page.
I applied your patch, and I'll send you the dump shorlty.
> However, from looking at your posting, there are some issues that you
> may want to look at before we talk:
> The reaching defs problem makes a scan for all of the defs in the blocks
> in the region. Once all of the defs are found, they are sorted where
> the primary key is the regno.
> The id's (DF_REF_ID) are then assigned based on this sorting. The
> reaching defs problem actually depends on all of the defs for a regno to
> be contigious.
> The DF_REF_IDs are not stable between calls to df_set_blocks and any def
> outside of the region has an undefined DF_REF_ID.
> In your posting you have:
> > Below is the output of df_ref_debug for adef in each iteration of the loop
> > in
> > latch_dominating_def:
> > d40 reg 187 bb 3 insn 255 flag 0x0 type 0x0 loc 0xf7da4608(0xf7d9a4e0)
> > chain { }
> > d93 reg 187 bb 2 insn 40 flag 0x0 type 0x0 loc 0xf7d89cc8(0xf7d9a4e0) chain
> > { }
> The number after the first "d" is the DF_REF_ID. Note that they are not
> contiguous.
> Given the sorting that occurred, they must be contiguous. I assume from this
> that
> someone is holding on to old id's. This is not correct.
> If you are going to play the game with df_set_blocks, you are allowed to hold
> onto a
> def, but not the DF_REF_ID, you cannot look at the DF_REF_ID for a def
> that is not in the blocks set by df_set_blocks.
are you saying it's safer not to call df_set_blocks in iv_analysis_loop_init?
(iv-analysis still fails when I do that, but maybe that in turn requires other
changes?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug c++/29000] [4.2 regression] ICE on invalid use of template in statement-expr
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:49:16 |2007-08-30 16:29:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug c++/29000] [4.2 regression] ICE on invalid use of template in statement-expr
--- Comment #5 from jason at gcc dot gnu dot org 2007-08-30 16:30 --- Fixed for 4.3, IMO not enough evident interest in the bug to bother backporting. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug c++/30917] [4.1 Regression] ICE with friend in local class (to a function)
--- Comment #9 from jason at gcc dot gnu dot org 2007-08-30 16:33 --- Fixed by Simon Martin. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.1.2 4.3.0 |4.1.2 Known to work|4.1.1 4.0.4 |4.1.1 4.0.4 4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30917
[Bug target/33168] [4.3 Regression] GCC Boot failure, building libstc++
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-30 16:43 --- Subject: Bug 33168 Author: jakub Date: Thu Aug 30 16:43:19 2007 New Revision: 127928 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127928 Log: PR target/33168 * config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Return true if any of the compare_section_name calls returned true, rather than if any returned false. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug fortran/33250] New: bus error compiling dqelg.f in scipy on intel mac
During gfortran compilation of the integration subpack of scipy-0.5.2.1, gfortran fails with an "internal compiler error: Bus error" when trying to compile dqelg.f. Command line and error info: gfortran:f77: Lib/integrate/quadpack/dqelg.f Lib/integrate/quadpack/dqelg.f: In function 'dqelg': Lib/integrate/quadpack/dqelg.f:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Lib/integrate/quadpack/dqelg.f: In function 'dqelg': Lib/integrate/quadpack/dqelg.f:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. error: Command "/usr/local/bin/gfortran -Wall -ffixed-form -fno-second-underscore -fPIC -O3 -funroll-loops -c -c Lib/integrate/quadpack/dqelg.f -o build/temp.macosx-10.4-i386-2.5/Lib/integrate/quadpack/dqelg.o" failed with exit status 1 vpn1-client-a35:/usr/local/src/scipy-0.5.2.1 claumann$ indqelggfortran -v -bash: indqelggfortran: command not found vpn1-client-a35:/usr/local/src/scipy-0.5.2.1 claumann$ gfortran -v Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: ../gcc-4.3-20070810/configure --enable-threads=posix --enable-languages=fortran Thread model: posix gcc version 4.3.0 20070810 (experimental) Fortran code (dqelg.f): subroutine dqelg(n,epstab,result,abserr,res3la,nres) c***begin prologue dqelg c***refer to dqagie,dqagoe,dqagpe,dqagse c***routines called d1mach c***revision date 830518 (yymmdd) c***keywords epsilon algorithm, convergence acceleration, c extrapolation c***author piessens,robert,appl. math. & progr. div. - k.u.leuven c de doncker,elise,appl. math & progr. div. - k.u.leuven c***purpose the routine determines the limit of a given sequence of capproximations, by means of the epsilon algorithm of cp.wynn. an estimate of the absolute error is also given. cthe condensed epsilon table is computed. only those celements needed for the computation of the next diagonal care preserved. c***description c c epsilon algorithm c standard fortran subroutine c double precision version c c parameters c n - integer c epstab(n) contains the new element in the c first column of the epsilon table. c c epstab - double precision c vector of dimension 52 containing the elements c of the two lower diagonals of the triangular c epsilon table. the elements are numbered c starting at the right-hand corner of the c triangle. c c result - double precision c resulting approximation to the integral c c abserr - double precision c estimate of the absolute error computed from c result and the 3 previous results c c res3la - double precision c vector of dimension 3 containing the last 3 c results c c nres - integer c number of calls to the routine c (should be zero at first call) c c***end prologue dqelg c double precision abserr,dabs,delta1,delta2,delta3,dmax1,d1mach, * epmach,epsinf,epstab,error,err1,err2,err3,e0,e1,e1abs,e2,e3, * oflow,res,result,res3la,ss,tol1,tol2,tol3 integer i,ib,ib2,ie,indx,k1,k2,k3,limexp,n,newelm,nres,num dimension epstab(52),res3la(3) c c list of major variables c --- c c e0 - the 4 elements on which the computation of a new c e1 element in the epsilon table is based c e2 c e3 e0 ce3e1new c e2 c newelm - number of elements to be computed in the new cdiagonal c error - error = abs(e1-e0)+abs(e2-e1)+abs(new-e2) c result - the element in the new diagonal with least value cof error c c machine dependent constants c --- c c epmach is the largest relative spacing. c oflow is the largest positive magnitude. c limexp is the maximum number of elements the epsilon c table can contain. if this number is reached, the upper c diagonal of the epsilon table is deleted. c c***first executable statement dqelg epmach = d1mach(4) oflow = d1mach(2) nres = nres+1 abserr = oflow result = epstab(n) if(n.lt.3) go to 100 limexp = 50 epstab(n+2) = epstab(n) newelm = (n-1)/2 epstab(n) = oflow num = n k1 = n do 40 i = 1,
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #4 from victor dot prosolin at gmail dot com 2007-08-30 17:09 --- I am sorry for posting such a long example, but the code was not written by me so I didn't want to make stupid changes. It's my first time reporting a bug via bugzilla so don't be too critical about me not figuring out how to create an attachment instead of posting it as a message. Additional info: Intel Fortran, Sun Fortran, openf95 and g95 pass this code with no problem, though g95 segfaults on execution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug fortran/33251] New: f77 reads one field into two variables in list directed i/o
The problem is that the I/O system reads one (admittedly malformed) field into two variables in list directed input. Take this one line and put it in a file named 'the_test_file' - cut - cut - cut - cut 13.5-1420.83 10.350E+00 -0.181E+19 - cut - cut - cut - cut In the same directory, save the following code, compile and run... - cut - cut - cut - cut program showbug real*4 press,atemp,zalt,junk,therest integer readstat open (10, file='the_test_file',status='old') read(10,*,end=223,err=555,iostat=readstat) & zalt,atemp,junk,press, therest 223 continue 555 if (readstat.gt.0) then print *,'Error!' stop endif print *,'No Error' print *,'zalt=',zalt,',atemp=',atemp,',junk=',junk print *,'press=',press,',therest=',therest end - cut - cut - cut - cut I used g77 -o showbug showbug.f When I ran this I got the following output. - cut - cut - cut - cut % ./showbug No Error zalt= 0.,atemp= 0.82983,junk= 1. press= 0.34994,therest= -1.8096E+18 - cut - cut - cut - cut The problem is that the I/O library reads that first string of characters into *two* fields. Notice the value of 'atemp'. It's 0.83, the last bit of that first malformed field. It is impossible in my testing to make this line throw an I/O error. I understand that the first field in my test case is malformed, that it's really two numbers run together. What I'd hoped for was for the i/o subsystem to throw an error so that I would be able to catch it in my processing software. But since g77 doesn't see this field as malformed, I can't. This is at odds with the f77 standard, in my opinion (and also the opinion of Van Snyder here at JPL) According to the F77 standard at http://www.fortran.com/fortran/F77_std/rjcnf0001-sh-13.html#sh-13.6 legitimate value separators are 1. A comma optionally preceded by one or more contiguous blanks and optionally followed by one or more contiguous blanks 2. A slash optionally preceded by one or more contiguous blanks and optionally followed by one or more contiguous blanks 3. One or more contiguous blanks between two constants or following the last constant My reading of that says that at the very least it should not have read that one field into two values. The particulars of my system are... % g77 -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-8) % uname -a Linux iguana.jpl.nasa.gov 2.6.9-55.0.2.plus.c4smp #1 SMP Fri Jul 6 05:25:07 EDT 2007 i686 i686 i386 GNU/Linux William Daffer -- Summary: f77 reads one field into two variables in list directed i/o Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: William dot Daffer at jpl dot nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33251
[Bug fortran/33250] bus error compiling dqelg.f in scipy on intel mac
--- Comment #1 from claumann at princeton dot edu 2007-08-30 17:25 --- Compiles with no errors using gfortran 4.2.1 for i686-apple-darwin8. -- claumann at princeton dot edu changed: What|Removed |Added CC||claumann at princeton dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT
--- Comment #12 from daney at gcc dot gnu dot org 2007-08-30 17:44 --- Does GCJ's behavior differ from Sun's in this test? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30 18:09 --- Subject: Re: failing rtl iv analysis (maybe due to df) > The only thing that you are allowed to do with the DF_REF_ID is to get > it from a df_def > AFTER YOU ARE SURE THAT THE DEF IS IN THE REGION OK, this might be the problem; the code takes the defs from the reg->def lists, and checks whether the defs are set in the reaching def bitmaps. Naturally, it assumes that when the region is set by df_set_blocks, the reaching def bitmaps will only contain the defs that belong to the region (which used to be true before your changes). Anyway, it would be nice to have some documentation for df (there is only a short notice in http://gcc.gnu.org/onlinedocs/gccint/Liveness-information.html#Liveness-information, which appears wrong given the importance of this api), in particular pointing out such non-obvious traps would be great. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug fortran/33252] New: GCC-4.3.0 Bootstrap testsuite error increase
Attached will be an unaltered log of : nice --adjustment=18 make -j2 -i check 2>&1 |tee .Check done on : 127924 svn://gcc.gnu.org/svn/gcc/trunk svn://gcc.gnu.org/svn/gcc Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-clocale=gnu --enable-bootstrap --enable-languages=c,fortran,c++ --enable-altivec --disable-libssp --disable-decimal-float --disable-libmudflap --disable-nls --disable-werror --disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu --with-system-zlib Thread model: posix gcc version 4.3.0 20070830 (experimental) (GCC) The significant increase concerns gfortran; but, others appear high. This ist to amplify the result reported in PR33247. -- Summary: GCC-4.3.0 Bootstrap testsuite error increase Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michelin60 at gmail dot com GCC build triplet: powerpc GCC host triplet: powerpc GCC target triplet: powerpc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33250] bus error compiling dqelg.f in scipy on intel mac
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
[Bug fortran/33250] [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-30 18:12 --- (gfortran bugs are by definition not critical or major for GCC as a whole; still the gfortran team tries to fix regressions as soon as possible.) I cannot reproduce this problem with today's gfortran on x86_64-unknown-linux-gnu - neither with -m32 nor with -m64. Does it also crash if you simply run gfortran -c dqelg.f without -fPIC -O3 -funroll-loops ? If you have valgrind, could you run gfortran's f951 through valgrind. (To find the arguments of f951, run gfortran as normal, but pass the "-v" argument; in the output there is a line which contains a pathname to f951; copy that line.) If you don't, can you run f951 in gdb and post a backtrace? Not that it will necessarily help, but it might do so: Could you try a newer version of gfortran? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Summary|bus error compiling dqelg.f |[Regression 4.3] bus error |in scipy on intel mac |compiling dqelg.f in scipy ||on intel mac http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
-156/./gcc/collect-ld"
"RANLIB=/usr/powerpc-unknown-linux-gnu/bin/ranlib"
"NM=/var/tmp/43/build-156/./gcc/nm" "NM_FOR_BUILD="
"NM_FOR_TARGET=/usr/powerpc-unknown-linux-gnu/bin/nm" "DESTDIR=" "WERROR="
DO=all multi-do # make
make[3]: Leaving directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3'
make[2]: Leaving directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3'
test -d testsuite || mkdir testsuite
test -d testsuite/g++ || mkdir testsuite/g++
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.3.0/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite/g++; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/g++|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ;
\
export TCL_LIBRARY ; fi ; \
GCC_EXEC_PREFIX="/usr/lib/gcc/" ; export GCC_EXEC_PREFIX ; \
runtest --tool g++ )
WARNING: Couldn't find the global config file.
Test Run By root on Thu Aug 30 10:14:52 2007
Native configuration is powerpc-unknown-linux-gnu
=== g++ tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /var/tmp/43/gcc-4.3.0/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/bprob/bprob.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/charset/charset.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/compat/compat.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/compat/struct-layout-1.exp
...
WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/debug/debug.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/dg.exp ...
FAIL: g++.dg/conversion/simd1.C (test for warnings, line 8)
FAIL: g++.dg/eh/simd-3.C execution test
FAIL: g++.dg/ext/attribute-test-1.C (test for warnings, line 10)
FAIL: g++.dg/ext/attribute-test-2.C (test for warnings, line 14)
FAIL: g++.dg/ext/attribute-test-3.C (test for warnings, line 26)
FAIL: g++.dg/ext/attribute-test-4.C (test for warnings, line 26)
XPASS: g++.dg/tree-ssa/copyprop-1.C scan-tree-dump-not .* = [^>;]*;
FAIL: g++.dg/warn/Wall-write-strings.C (test for warnings, line 5)
FAIL: g++.dg/warn/write-strings-default.C (test for warnings, line 6)
FAIL: g++.dg/warn/write-strings.C (test for warnings, line 6)
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/gcov/gcov.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/gomp/gomp.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/pch/pch.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/special/ecos.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/tls/tls.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/torture/dg-torture.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/tree-prof/tree-prof.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/vect/vect.exp ...
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.old-deja/old-deja.exp ...
=== g++ Summary ===
# of expected passes16394
# of unexpected failures9
# of unexpected successes 1
# of expected failures 87
# of unsupported tests 114
/var/tmp/43/build-156/gcc/testsuite/g++/../../g++ version 4.3.0 20070830
(experimental) (GCC)
make[2]: [check-g++] Error 1 (ignored)
make[2]: Entering directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libgfortran'
make check-am
make[3]: Entering directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libgfortran'
true DO=all multi-do # make
make[3]: Leaving directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libgfortran'
make[2]: Leaving directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libgfortran'
test -d testsuite || mkdir testsuite
test -d testsuite/gfortran || mkdir testsuite/gfortran
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.3.0/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite/gfortran; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/gfortran|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdi
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3/testsuite'
> make[3]: Leaving directory
> `/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3/testsuite'
> make[3]: Entering directory
> `/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3'
> true "AR_FLAGS=rc" "CC_FOR_BUILD=powerpc-unknown-linux-gnu-gcc"
> "CC_FOR_TARGET=/var/tmp/43/build-156/./gcc/xgcc -B/var/tmp/43/build-156/./gcc/
> -B/usr/powerpc-unknown-linux-gnu/bin/ -B/usr/powerpc-unknown-linux-gnu/lib/
> -isystem /usr/powerpc-unknown-linux-gnu/include -isystem
> /usr/powerpc-unknown-linux-gnu/sys-include" "CFLAGS=-O2 -g -O2 " "CXXFLAGS=-g
> -O2 -D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-O2 -g -O2
> "
> "INSTALL=/usr/bin/ginstall -c" "INSTALL_DATA=/usr/bin/ginstall -c -m 644"
> "INSTALL_PROGRAM=/usr/bin/ginstall -c" "INSTALL_SCRIPT=/usr/bin/ginstall -c"
> "LDFLAGS=" "LIBCFLAGS=-O2 -g -O2 " "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 "
> "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 "
> "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS="
> "exec_prefix=/usr" "infodir=/usr/share/info" "libdir=/usr/lib"
> "includedir=/usr/include" "prefix=/usr"
> "tooldir=/usr/powerpc-unknown-linux-gnu"
> "gxx_include_dir=/usr/include/c++/4.3.0"
> "AR=/usr/powerpc-unknown-linux-gnu/bin/ar" "AS=/var/tmp/43/build-156/./gcc/as"
> "LD=/var/tmp/43/build-156/./gcc/collect-ld"
> "RANLIB=/usr/powerpc-unknown-linux-gnu/bin/ranlib"
> "NM=/var/tmp/43/build-156/./gcc/nm" "NM_FOR_BUILD="
> "NM_FOR_TARGET=/usr/powerpc-unknown-linux-gnu/bin/nm" "DESTDIR=" "WERROR="
> DO=all multi-do # make
> make[3]: Leaving directory
> `/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3'
> make[2]: Leaving directory
> `/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3'
> test -d testsuite || mkdir testsuite
> test -d testsuite/g++ || mkdir testsuite/g++
> (rootme=`${PWDCMD-pwd}`; export rootme; \
> srcdir=`cd ../../gcc-4.3.0/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
> cd testsuite/g++; \
> rm -f tmp-site.exp; \
> sed '/set tmpdir/ s|testsuite|testsuite/g++|' \
> < ../../site.exp > tmp-site.exp; \
> /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
> EXPECT=expect ; export EXPECT ; \
> if [ -f ${rootme}/../expect/expect ] ; then \
>TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ;
> \
> export TCL_LIBRARY ; fi ; \
> GCC_EXEC_PREFIX="/usr/lib/gcc/" ; export GCC_EXEC_PREFIX ; \
> runtest --tool g++ )
> WARNING: Couldn't find the global config file.
> Test Run By root on Thu Aug 30 10:14:52 2007
> Native configuration is powerpc-unknown-linux-gnu
>
> === g++ tests ===
>
> Schedule of variations:
> unix
>
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> Using /var/tmp/43/gcc-4.3.0/gcc/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/bprob/bprob.exp ...
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/charset/charset.exp ...
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/compat/compat.exp ...
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/compat/struct-layout-1.exp
> ...
> WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/debug/debug.exp ...
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp ...
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/dg.exp ...
> FAIL: g++.dg/conversion/simd1.C (test for warnings, line 8)
> FAIL: g++.dg/eh/simd-3.C execution test
> FAIL: g++.dg/ext/attribute-test-1.C (test for warnings, line 10)
> FAIL: g++.dg/ext/attribute-test-2.C (test for warnings, line 14)
> FAIL: g++.dg/ext/attribute-test-3.C (test for warnings, line 26)
> FAIL: g++.dg/ext/attribute-test-4.C (test for warnings, line 26)
> XPASS: g++.dg/tree-ssa/copyprop-1.C scan-tree-dump-not .* = [^>;]*;
> FAIL: g++.dg/warn/Wall-write-strings.C (test for warnings, line 5)
> FAIL: g++.dg/warn/write-strings-default.C (test for warnings, line 6)
> FAIL: g++.dg/warn/write-
[Bug fortran/33251] f77 reads one field into two variables in list directed i/o
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 18:26 --- I tried you example with g77 and it shows "No Error". However, using all other compilers I have (ifort, sunf95, openf95, g95, gfortran, NAG f95) it shows "Error!". ... Ok, after re-reading your bug report, I see that you report a bug against g77 and not against gfortran (which is not affected). g77 was part of GCC 3.4.x and is no longer supported. gfortran is part of GCC since 4.0.0, supports Fortran 90/95 (and thus also FORTRAN 77); it also supports Cray pointers and other legacy extensions and it should support 99% of the extensions of g77. Plus it has better diagnostic capabilities. You should be able to get gfortran binaries (please use gfortran 4.1.x or later) from your vendor (RedHat) or from: http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux Closed as WONTFIX (with regards to g77), I could have also used WORKSFORME as gfortran behaves properly. Please use the fortrangcc.gnu.org mailing list if you have further questions. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33251
Re: [Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
> /var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp. > ERROR: could not compile testsuite_abi.cc This was fixed by: 2007-08-30 Jakub Jelinek <[EMAIL PROTECTED]> PR target/33168 * config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Return true if any of the compare_section_name calls returned true, rather than if any returned false. Try again after that patch. Thanks, Andrew Pinski
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #3 from pinskia at gmail dot com 2007-08-30 18:35 --- Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase > /var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp. > ERROR: could not compile testsuite_abi.cc This was fixed by: 2007-08-30 Jakub Jelinek <[EMAIL PROTECTED]> PR target/33168 * config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Return true if any of the compare_section_name calls returned true, rather than if any returned false. Try again after that patch. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33250] [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac
--- Comment #3 from claumann at princeton dot edu 2007-08-30 18:40 --- Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac Howdy- Thanks for looking into it! It compiles just fine with gfortran -c dqelg.f I'm not especially excited about trying to compile a newer version of gfortran at the moment. Do OS X compiles go smoothly? I don't believe that valgrind is available for OS X. This gfortran is available as a binary. I actually downgraded teh binary to 4.2 and managed to compile the code. I suppose I could've just turned off optimizations as well.. I ran f951 in gdb for you with a backtrace. Don't know if it's helpful but here's the output: penguin:~/gcc-bug claumann$ gdb /opt/usr/local/libexec/gcc/i386-apple- darwin8.10.1/4.3.0/f951 GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006)Copyright 2004 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries done (gdb) r dqelg.f -ffixed-form -fPIC -quiet -dumpbase dqelg.f -mmacosx- version-min=10.4 -mtune=generic -auxbase dqelg -O3 -version - fintrinsic-modules-path /opt/usr/local/bin/../lib/gcc/i386-apple- darwin8.10.1/4.3.0/finclude -o /var/tmp//cc3A8yuy.sStarting program: / opt/usr/local/libexec/gcc/i386-apple-darwin8.10.1/4.3.0/f951 dqelg.f - ffixed-form -fPIC -quiet -dumpbase dqelg.f -mmacosx-version-min=10.4 - mtune=generic -auxbase dqelg -O3 -version -fintrinsic-modules-path / opt/usr/local/bin/../lib/gcc/i386-apple-darwin8.10.1/4.3.0/finclude - o /var/tmp//cc3A8yuy.s Reading symbols for shared libraries .+ done GNU F95 version 4.3.0 20070810 (experimental) (i386-apple-darwin8.10.1) compiled by GNU C version 4.3.0 20070810 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000c build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a=0x0, ddr_b=0x434af898, dist_v=0x7b4d8c, init_b=0x434e9bd0 "A", index_carry=0x7) at ../../gcc-4.3-20070810/gcc/tree-data-ref.c:2719 2719../../gcc-4.3-20070810/gcc/tree-data-ref.c: No such file or directory. in ../../gcc-4.3-20070810/gcc/tree-data-ref.c (gdb) bt #0 build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a=0x0, ddr_b=0x434af898, dist_v=0x7b4d8c, init_b=0x434e9bd0 "A", index_carry=0x7) at ../../gcc-4.3-20070810/gcc/tree-data-ref.c:2719 #1 0xbfffef44 in ?? () Previous frame inner to this frame (corrupt stack?) (gdb) On Aug 30, 2007, at 12:12 PM, burnus at gcc dot gnu dot org wrote: > > > --- Comment #2 from burnus at gcc dot gnu dot org 2007-08-30 > 18:12 --- > (gfortran bugs are by definition not critical or major for GCC as a > whole; > still the gfortran team tries to fix regressions as soon as possible.) > > I cannot reproduce this problem with today's gfortran on > x86_64-unknown-linux-gnu - neither with -m32 nor with -m64. > > Does it also crash if you simply run > >gfortran -c dqelg.f > > without -fPIC -O3 -funroll-loops ? > > If you have valgrind, could you run gfortran's f951 through > valgrind. (To find > the arguments of f951, run gfortran as normal, but pass the "-v" > argument; in > the output there is a line which contains a pathname to f951; copy > that line.) > > If you don't, can you run f951 in gdb and post a backtrace? > > Not that it will necessarily help, but it might do so: Could you > try a newer > version of gfortran? > > > -- > > burnus at gcc dot gnu dot org changed: > >What|Removed |Added > -- > -- > CC||burnus at gcc dot > gnu dot >||org > Summary|bus error compiling dqelg.f |[Regression 4.3] > bus error >|in scipy on intel mac |compiling dqelg.f > in scipy >||on intel mac > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
Re: [Bug fortran/33250] [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac
On 30 Aug 2007 18:40:51 -, claumann at princeton dot edu <[EMAIL PROTECTED]> wrote: > build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a=0x0, > ddr_b=0x434af898, dist_v=0x7b4d8c, init_b=0x434e9bd0 "A", > index_carry=0x7) at ../../gcc-4.3-20070810/gcc/tree-data-ref.c:2719 > 2719../../gcc-4.3-20070810/gcc/tree-data-ref.c: No such file or > directory. This was PR 32946/32573 and was fixed by: 2007-08-24 Jakub Jelinek <[EMAIL PROTECTED]> PR tree-optimization/32573 PR middle-end/32946 * tree-data-ref.c (initialize_data_dependence_relation): Clear DDR_SUBSCRIPTS, DDR_DIR_VECTS and DDR_DIST_VECTS at the beginning. (finalize_ddr_dependent): Clear DDR_SUBSCRIPTS after freeing it. (build_classic_dist_vector): Return false rather than true if DDR_ARE_DEPENDENT is non-NULL at the beginning. Return false if either subscript_dependence_tester_1 or build_classic_dist_vector_1 returned false. Don't call save_dist_v before calling build_classic_dist_vector_1. (free_dependence_relation): Don't guard freeing DDR_SUBSCRIPTS with NULL DDR_ARE_DEPENDENT. Also free DDR_DIST_VECTS and/or DDR_DIR_VECTS vectors. So can you please try a newer version? Thanks, Andrew Pinski
[Bug fortran/33250] [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac
--- Comment #4 from pinskia at gmail dot com 2007-08-30 18:44 --- Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac On 30 Aug 2007 18:40:51 -, claumann at princeton dot edu <[EMAIL PROTECTED]> wrote: > build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a=0x0, > ddr_b=0x434af898, dist_v=0x7b4d8c, init_b=0x434e9bd0 "A", > index_carry=0x7) at ../../gcc-4.3-20070810/gcc/tree-data-ref.c:2719 > 2719../../gcc-4.3-20070810/gcc/tree-data-ref.c: No such file or > directory. This was PR 32946/32573 and was fixed by: 2007-08-24 Jakub Jelinek <[EMAIL PROTECTED]> PR tree-optimization/32573 PR middle-end/32946 * tree-data-ref.c (initialize_data_dependence_relation): Clear DDR_SUBSCRIPTS, DDR_DIR_VECTS and DDR_DIST_VECTS at the beginning. (finalize_ddr_dependent): Clear DDR_SUBSCRIPTS after freeing it. (build_classic_dist_vector): Return false rather than true if DDR_ARE_DEPENDENT is non-NULL at the beginning. Return false if either subscript_dependence_tester_1 or build_classic_dist_vector_1 returned false. Don't call save_dist_v before calling build_classic_dist_vector_1. (free_dependence_relation): Don't guard freeing DDR_SUBSCRIPTS with NULL DDR_ARE_DEPENDENT. Also free DDR_DIST_VECTS and/or DDR_DIR_VECTS vectors. So can you please try a newer version? Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #8 from zadeck at naturalbridge dot com 2007-08-30 18:51 --- Subject: Re: failing rtl iv analysis (maybe due to df) rakdver at kam dot mff dot cuni dot cz wrote: > --- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30 > 18:09 --- > Subject: Re: failing rtl iv analysis (maybe due to df) > > >> The only thing that you are allowed to do with the DF_REF_ID is to get >> it from a df_def >> AFTER YOU ARE SURE THAT THE DEF IS IN THE REGION >> > > OK, this might be the problem; the code takes the defs from the reg->def > lists, and checks whether the defs are set in the reaching def bitmaps. > Naturally, it assumes that when the region is set by df_set_blocks, the > reaching def bitmaps will only contain the defs that belong to the > region (which used to be true before your changes). > > And it is still true now. The set of bits in the bitmaps are EXACTLY the set of defs inside the region. The thing that has changed is that the location (slot) in the bitmap is only defined after the calls to df_set_blocks and df_analyze, i.e. the slots in the bitvectors are moved around by these calls. In your example, you asked about 2 defs. One of those defs is in the region and one of them is outside the region. It is not that the bits are zero for a def outside of the region, there is no slot in the bitvectors that corresponds to that def in the bitvectors. You are not allowed to look in the bitmap for the def outside of the region as ask any questions at all if they involve the DF_REF_ID. For the def that is in the region, you can ask but you cannot use the DF_REF_ID that it had before the call to set_blocks. That old one is trash. What has changed, and this was a very old change, from the time that danny still worked at ibm, was that the DF_REF_ID's are not stable and the slots change after setting the blocks in the region. One of the first df patches that was committed by us was to reorganize the bits so that all of the refs for a single reg were contiguous. This gave a factor of 7 speedup over the old code because it allowed for the use of new bitmap operations that worked over dense range indexes. I assume that this code has not really worked since then. > Anyway, it would be nice to have some documentation for df (there > is only a short notice in > http://gcc.gnu.org/onlinedocs/gccint/Liveness-information.html#Liveness-information, > which appears wrong given the importance of this api), in particular > pointing out such non-obvious traps would be great. > > > This is only an issue if you use df_set_blocks and the only passes that use it are these zdenek's loop passes. If I had my way (and infinite free time) I would get rid of df_set_blocks anyway. The information that it provides is generally wrong since it ignores information that enters a block from the outside, but if you are very careful to only ask a very limited range of questions, as Zdenek did, it can give you what you want relatively inexpensively. Furthermore, it has been a real pain to keep it correct as the rest of df has evolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug fortran/33250] [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac
--- Comment #5 from claumann at princeton dot edu 2007-08-30 18:51 --- Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel mac Great! Will do. Sorry to take your time. Chris On Aug 30, 2007, at 12:44 PM, pinskia at gmail dot com wrote: > > > --- Comment #4 from pinskia at gmail dot com 2007-08-30 18:44 > --- > Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy > on intel > mac > > On 30 Aug 2007 18:40:51 -, claumann at princeton dot edu > <[EMAIL PROTECTED]> wrote: >> build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a=0x0, >> ddr_b=0x434af898, dist_v=0x7b4d8c, init_b=0x434e9bd0 "A", >> index_carry=0x7) at ../../gcc-4.3-20070810/gcc/tree-data-ref.c:2719 >> 2719../../gcc-4.3-20070810/gcc/tree-data-ref.c: No such file or >> directory. > > This was PR 32946/32573 and was fixed by: > 2007-08-24 Jakub Jelinek <[EMAIL PROTECTED]> > > PR tree-optimization/32573 > PR middle-end/32946 > * tree-data-ref.c (initialize_data_dependence_relation): Clear > DDR_SUBSCRIPTS, DDR_DIR_VECTS and DDR_DIST_VECTS at the > beginning. > (finalize_ddr_dependent): Clear DDR_SUBSCRIPTS after > freeing it. > (build_classic_dist_vector): Return false rather than true if > DDR_ARE_DEPENDENT is non-NULL at the beginning. Return false > if either subscript_dependence_tester_1 or > build_classic_dist_vector_1 > returned false. Don't call save_dist_v before calling > build_classic_dist_vector_1. > (free_dependence_relation): Don't guard freeing DDR_SUBSCRIPTS > with NULL DDR_ARE_DEPENDENT. Also free DDR_DIST_VECTS and/or > DDR_DIR_VECTS vectors. > > So can you please try a newer version? > > Thanks, > Andrew Pinski > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
[Bug libfortran/33253] New: namelist: reading back a string with apostrophe
Reading back a namelist string which contains an apostrophe doesn't work. I am marking this as an enhancement because reading back what we wrote with a namelist isn't guaranteed to work (see note 10.37 in the working draft). It does work with ifort, for example. $ cat namelist.f90 program main implicit none character(len=3) :: a namelist /foo/ a open(10,status="scratch") a = "a'a" write(10,foo) write (*,foo) rewind 10 read (10,foo) end program main $ gfortran namelist.f90 $ ./a.out &FOO A=a'a, / At line 10 of file namelist.f90 (unit = 10, file = '/tmp/gfortrantmpy3HLPb') Fortran runtime error: Cannot match namelist object name a'a, -- Summary: namelist: reading back a string with apostrophe Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #9 from zadeck at naturalbridge dot com 2007-08-30 18:57 --- Subject: Re: failing rtl iv analysis (maybe due to df) zadeck at naturalbridge dot com wrote: > --- Comment #8 from zadeck at naturalbridge dot com 2007-08-30 18:51 > --- > Subject: Re: failing rtl iv analysis (maybe due > to df) > > rakdver at kam dot mff dot cuni dot cz wrote: > >> --- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30 >> 18:09 --- >> Subject: Re: failing rtl iv analysis (maybe due to df) >> >> >> >>> The only thing that you are allowed to do with the DF_REF_ID is to get >>> it from a df_def >>> AFTER YOU ARE SURE THAT THE DEF IS IN THE REGION >>> >>> >> OK, this might be the problem; the code takes the defs from the reg->def >> lists, and checks whether the defs are set in the reaching def bitmaps. >> Naturally, it assumes that when the region is set by df_set_blocks, the >> reaching def bitmaps will only contain the defs that belong to the >> region (which used to be true before your changes). >> >> >> > And it is still true now. The set of bits in the bitmaps are EXACTLY > the set of defs inside the region. The thing that has changed is that > the location (slot) in the bitmap is only defined after the calls to > df_set_blocks and df_analyze, i.e. the slots in the bitvectors are moved > around by these calls. > > In your example, you asked about 2 defs. One of those defs is in the > region and one of them is outside the region. It is not that the bits > are zero for a def outside of the region, there is no slot in the > bitvectors that corresponds to that def in the bitvectors. You are not > allowed to look in the bitmap for the def outside of the region as ask > any questions at all if they involve the DF_REF_ID. For the def that is > in the region, you can ask but you cannot use the DF_REF_ID that it had > before the call to set_blocks. That old one is trash. > > What has changed, and this was a very old change, from the time that > danny still worked at ibm, was that the DF_REF_ID's are not stable and > the slots change after setting the blocks in the region. One of the > first df patches that was committed by us was to reorganize the bits so > that all of the refs for a single reg were contiguous. This gave a > factor of 7 speedup over the old code because it allowed for the use of > new bitmap operations that worked over dense range indexes. I assume > that this code has not really worked since then. > > >> Anyway, it would be nice to have some documentation for df (there >> is only a short notice in >> http://gcc.gnu.org/onlinedocs/gccint/Liveness-information.html#Liveness-information, >> which appears wrong given the importance of this api), in particular >> pointing out such non-obvious traps would be great. >> >> >> >> > This is only an issue if you use df_set_blocks and the only passes that > use it are these zdenek's loop passes. If I had my way (and infinite > free time) I would get rid of df_set_blocks anyway. The information > that it provides is generally wrong since it ignores information that > enters a block from the outside, but if you are very careful to only ask > a very limited range of questions, as Zdenek did, it can give you what > you want relatively inexpensively. > > Furthermore, it has been a real pain to keep it correct as the rest of > df has evolved. > > > > sorry zdenek, i misread who this was from, i would not have referred to you in the third person if i had read it correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug fortran/33251] f77 reads one field into two variables in list directed i/o
--- Comment #2 from William dot H dot Daffer at jpl dot nasa dot gov 2007-08-30 19:33 --- Subject: Re: f77 reads one field into two variables in list directed i/o On Thu, 2007-08-30 at 18:26 +, burnus at gcc dot gnu dot org wrote: > > --- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 18:26 > --- > I tried you example with g77 and it shows "No Error". However, using all other > compilers I have (ifort, sunf95, openf95, g95, gfortran, NAG f95) it shows > "Error!". Yes, that's what happened when we tried lahey and nag. > > ... > > Ok, after re-reading your bug report, I see that you report a bug against g77 > and not against gfortran (which is not affected). > > g77 was part of GCC 3.4.x and is no longer supported. > Okay. > gfortran is part of GCC since 4.0.0, supports Fortran 90/95 (and thus also > FORTRAN 77); it also supports Cray pointers and other legacy extensions and it > should support 99% of the extensions of g77. Plus it has better diagnostic > capabilities. Okay. I'll see whether we can use that. thanks for the quick response! William > > You should be able to get gfortran binaries (please use gfortran 4.1.x or > later) from your vendor (RedHat) or from: > http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux > > Closed as WONTFIX (with regards to g77), I could have also used WORKSFORME as > gfortran behaves properly. > > Please use the fortrangcc.gnu.org mailing list if you have further > questions. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33251
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #14 from patchapp at dberlin dot org 2007-08-30 19:45 --- Subject: Bug number PR 30315 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-08/msg02217.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-08-30 20:05 --- I know how to fix the problem, now. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|seongbae dot park at gmail |rakdver at gcc dot gnu dot |dot com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug libstdc++/33247] [4.3 regression] libstdc++ testsuite_abi.cc build failure
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-30 20:15 --- Should be fixed now, see http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127928 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33247
[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output (on 32bit targets)
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-30 21:04 --- The following code: real x x = 1.0 print '(3E20.2e2)', x, x/10.0, x/100.0 print '(3E20.2e3)', x, x/10.0, x/100.0 print '(3E20.2e4)', x, x/10.0, x/100.0 print '(3E20.2e5)', x, x/10.0, x/100.0 print '(3E20.2e6)', x, x/10.0, x/100.0 print '(3E20.2e7)', x, x/10.0, x/100.0 print '(3E20.3e2)', x, x/10.0, x/100.0 print '(3E20.3e3)', x, x/10.0, x/100.0 print '(3E20.3e4)', x, x/10.0, x/100.0 print '(3E20.3e5)', x, x/10.0, x/100.0 print '(3E20.3e6)', x, x/10.0, x/100.0 print '(3E20.3e7)', x, x/10.0, x/100.0 print '(3E20.4e2)', x, x/10.0, x/100.0 print '(3E20.4e3)', x, x/10.0, x/100.0 print '(3E20.4e4)', x, x/10.0, x/100.0 print '(3E20.4e5)', x, x/10.0, x/100.0 print '(3E20.4e6)', x, x/10.0, x/100.0 print '(3E20.4e7)', x, x/10.0, x/100.0 end gives on Darwin without options: 0.10E+010.10E+000.10E-01 0.10E+00^@ 0.10E+00^@ 0.10E-00^@ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 0.100E+01 0.100E+00 0.100E-01 0.100E+00^@ 0.100E+00^@ 0.100E-00^@ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 0.1000E+01 0.1000E+00 0.1000E-01 0.1000E+00^@ 0.1000E+00^@ 0.1000E-00^@ [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] with -m64: 0.10E+010.10E+000.10E-01 0.10E+001 0.10E+000 0.10E-001 0.10E+0001 0.10E+ 0.10E-0001 0.10E+1 0.10E+0 0.10E-1 0.10E+010.10E+000.10E-01 0.10E+00^@ 0.10E+00^@ 0.10E-00^@ 0.100E+01 0.100E+00 0.100E-01 0.100E+001 0.100E+000 0.100E-001 0.100E+0001 0.100E+ 0.100E-0001 0.100E+10.100E+00.100E-1 0.100E+01 0.100E+00 0.100E-01 0.100E+00^@ 0.100E+00^@ 0.100E-00^@ 0.1000E+01 0.1000E+00 0.1000E-01 0.1000E+001 0.1000E+000 0.1000E-001 0.1000E+00010.1000E+0.1000E-0001 0.1000E+1 0.1000E+0 0.1000E-1 0.1000E+01 0.1000E+00 0.1000E-01 0.1000E+00^@ 0.1000E+00^@ 0.1000E-00^@ instead of (xlg, g95): 0.10E+010.10E+000.10E-01 0.10E+001 0.10E+000 0.10E-001 0.10E+0001 0.10E+ 0.10E-0001 0.10E+1 0.10E+0 0.10E-1 0.10E+010.10E+000.10E-01 0.10E+001 0.10E+000 0.10E-001 0.100E+01 0.100E+00 0.100E-01 0.100E+001 0.100E+000 0.100E-001 0.100E+0001 0.100E+ 0.100E-0001 0.100E+10.100E+00.100E-1 0.100E+01 0.100E+00 0.100E-01 0.100E+001 0.100E+000 0.100E-001 0.1000E+01 0.1000E+00 0.1000E-01 0.1000E+001 0.1000E+000 0.1000E-001 0.1000E+00010.1000E+0.1000E-0001 0.1000E+1 0.1000E+0 0.1000E-1 0.1000E+01 0.1000E+00 0.1000E-01 0.1000E+001 0.1000E+000 0.1000E-001 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug target/33168] [4.3 Regression] GCC Boot failure, building libstc++
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-30 21:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug bootstrap/33191] Install failure,recent CVS
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-30 21:09 --- Not a GCC bug so closing. -- 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=33191
[Bug target/33151] Invalid insn with pre_inc
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-30 21:09 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33151
[Bug target/33236] -minimal-toc register should be psedu-register
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-30 21:15 --- I have a patch which needs testing for the trunk. I am thinking about adding to my normal testing -mminimal-toc with -m64. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-30 21:15:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33236
[Bug middle-end/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug rtl-optimization/33148] [4.2 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-30 21:19 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148
[Bug target/33205] optimization bug: unsigned bitfield expands with non-zero padding bits
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33205
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #11 from zadeck at naturalbridge dot com 2007-08-30 21:46 --- Subject: Re: failing rtl iv analysis (maybe due to df) rakdver at gcc dot gnu dot org wrote: > --- Comment #10 from rakdver at gcc dot gnu dot org 2007-08-30 20:05 > --- > I know how to fix the problem, now. > > > thanks kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug fortran/33254] New: Diagnose different string lengths in array constructors at run time
The following program is invalid Fortran 95/2003, but this cannot be diagnosed at compile time: program array_char implicit none character (len=2) :: x, y x = "a " y = "cd" print*,[trim(x),trim(y)] ! [ "a", "cd" ] ->INVALID: different string lengths end program array_char While behavior of gfortran is ok (ifort, sunf95 and openf95 do the same), it would be great if using, e.g., -fbounds-check an error would be printed: NAG f95 prints for that program (at run time): Unequal character lengths (2 and 1) in array constructor and g95: Fortran runtime error: Inconsistent string size in array constructor -- Summary: Diagnose different string lengths in array constructors at run time Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #12 from fago at caltech dot edu 2007-08-30 21:52 --- A stupid question: why cannot gfortran detect this invalid code at compile time? I was quite surprised by a runtime error. BTW, I was compiling some legacy code with 4.2.1 and just hit this ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/32703] ICE with [trim(character_variable)]
--- Comment #3 from pault at gcc dot gnu dot org 2007-08-30 22:11 --- Subject: Bug 32703 Author: pault Date: Thu Aug 30 22:10:55 2007 New Revision: 127939 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939 Log: 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 PR fortran/31197 PR fortran/31258 PR fortran/32703 * gfortran.h : Add prototype for gfc_resolve_substring_charlen. * resolve.c (gfc_resolve_substring_charlen): New function. (resolve_ref): Call gfc_resolve_substring_charlen. (gfc_resolve_character_operator): New function. (gfc_resolve_expr): Call the new functions in cases where the character length is missing. * iresolve.c (cshift, eoshift, merge, pack, reshape, spread, transpose, unpack): Call gfc_resolve_substring_charlen for source expressions that are character and have a reference. * trans.h (gfc_trans_init_string_length) Change name to gfc_conv_string_length; modify references in trans-expr.c, trans-array.c and trans-decl.c. * trans-expr.c (gfc_trans_string_length): Handle case of no backend_decl. (gfc_conv_aliased_arg): Remove code for treating substrings and replace with call to gfc_trans_string_length. * trans-array.c (gfc_conv_expr_descriptor): Remove code for treating strings and call gfc_trans_string_length instead. 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 * gfortran.dg/char_length_7.f90: New test. * gfortran.dg/char_length_9.f90: New test. * gfortran.dg/char_assign_1.f90: Add extra warning. PR fortran/31197 PR fortran/31258 * gfortran.dg/char_length_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_7.f90 trunk/gcc/testsuite/gfortran.dg/char_length_8.f90 trunk/gcc/testsuite/gfortran.dg/char_length_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_assign_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug fortran/31258] segfault with transpose(reshape(char))
--- Comment #7 from pault at gcc dot gnu dot org 2007-08-30 22:11 --- Subject: Bug 31258 Author: pault Date: Thu Aug 30 22:10:55 2007 New Revision: 127939 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939 Log: 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 PR fortran/31197 PR fortran/31258 PR fortran/32703 * gfortran.h : Add prototype for gfc_resolve_substring_charlen. * resolve.c (gfc_resolve_substring_charlen): New function. (resolve_ref): Call gfc_resolve_substring_charlen. (gfc_resolve_character_operator): New function. (gfc_resolve_expr): Call the new functions in cases where the character length is missing. * iresolve.c (cshift, eoshift, merge, pack, reshape, spread, transpose, unpack): Call gfc_resolve_substring_charlen for source expressions that are character and have a reference. * trans.h (gfc_trans_init_string_length) Change name to gfc_conv_string_length; modify references in trans-expr.c, trans-array.c and trans-decl.c. * trans-expr.c (gfc_trans_string_length): Handle case of no backend_decl. (gfc_conv_aliased_arg): Remove code for treating substrings and replace with call to gfc_trans_string_length. * trans-array.c (gfc_conv_expr_descriptor): Remove code for treating strings and call gfc_trans_string_length instead. 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 * gfortran.dg/char_length_7.f90: New test. * gfortran.dg/char_length_9.f90: New test. * gfortran.dg/char_assign_1.f90: Add extra warning. PR fortran/31197 PR fortran/31258 * gfortran.dg/char_length_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_7.f90 trunk/gcc/testsuite/gfortran.dg/char_length_8.f90 trunk/gcc/testsuite/gfortran.dg/char_length_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_assign_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31258
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #22 from pault at gcc dot gnu dot org 2007-08-30 22:11 --- Subject: Bug 31197 Author: pault Date: Thu Aug 30 22:10:55 2007 New Revision: 127939 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939 Log: 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 PR fortran/31197 PR fortran/31258 PR fortran/32703 * gfortran.h : Add prototype for gfc_resolve_substring_charlen. * resolve.c (gfc_resolve_substring_charlen): New function. (resolve_ref): Call gfc_resolve_substring_charlen. (gfc_resolve_character_operator): New function. (gfc_resolve_expr): Call the new functions in cases where the character length is missing. * iresolve.c (cshift, eoshift, merge, pack, reshape, spread, transpose, unpack): Call gfc_resolve_substring_charlen for source expressions that are character and have a reference. * trans.h (gfc_trans_init_string_length) Change name to gfc_conv_string_length; modify references in trans-expr.c, trans-array.c and trans-decl.c. * trans-expr.c (gfc_trans_string_length): Handle case of no backend_decl. (gfc_conv_aliased_arg): Remove code for treating substrings and replace with call to gfc_trans_string_length. * trans-array.c (gfc_conv_expr_descriptor): Remove code for treating strings and call gfc_trans_string_length instead. 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 * gfortran.dg/char_length_7.f90: New test. * gfortran.dg/char_length_9.f90: New test. * gfortran.dg/char_assign_1.f90: Add extra warning. PR fortran/31197 PR fortran/31258 * gfortran.dg/char_length_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_7.f90 trunk/gcc/testsuite/gfortran.dg/char_length_8.f90 trunk/gcc/testsuite/gfortran.dg/char_length_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_assign_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31879] ICE with function having array of character variables argument
--- Comment #6 from pault at gcc dot gnu dot org 2007-08-30 22:11 --- Subject: Bug 31879 Author: pault Date: Thu Aug 30 22:10:55 2007 New Revision: 127939 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939 Log: 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 PR fortran/31197 PR fortran/31258 PR fortran/32703 * gfortran.h : Add prototype for gfc_resolve_substring_charlen. * resolve.c (gfc_resolve_substring_charlen): New function. (resolve_ref): Call gfc_resolve_substring_charlen. (gfc_resolve_character_operator): New function. (gfc_resolve_expr): Call the new functions in cases where the character length is missing. * iresolve.c (cshift, eoshift, merge, pack, reshape, spread, transpose, unpack): Call gfc_resolve_substring_charlen for source expressions that are character and have a reference. * trans.h (gfc_trans_init_string_length) Change name to gfc_conv_string_length; modify references in trans-expr.c, trans-array.c and trans-decl.c. * trans-expr.c (gfc_trans_string_length): Handle case of no backend_decl. (gfc_conv_aliased_arg): Remove code for treating substrings and replace with call to gfc_trans_string_length. * trans-array.c (gfc_conv_expr_descriptor): Remove code for treating strings and call gfc_trans_string_length instead. 2007-08-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31879 * gfortran.dg/char_length_7.f90: New test. * gfortran.dg/char_length_9.f90: New test. * gfortran.dg/char_assign_1.f90: Add extra warning. PR fortran/31197 PR fortran/31258 * gfortran.dg/char_length_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_7.f90 trunk/gcc/testsuite/gfortran.dg/char_length_8.f90 trunk/gcc/testsuite/gfortran.dg/char_length_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_assign_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31879
[Bug fortran/31879] ICE with function having array of character variables argument
--- Comment #7 from pault at gcc dot gnu dot org 2007-08-30 22:12 --- Fixed on trunk. Thanks for the report! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31879
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #23 from pault at gcc dot gnu dot org 2007-08-30 22:13 --- Fixed on trunk. Thanks for the report! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31258] segfault with transpose(reshape(char))
--- Comment #8 from pault at gcc dot gnu dot org 2007-08-30 22:13 --- Fixed on trunk. Thanks for the report! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31258
[Bug fortran/32703] ICE with [trim(character_variable)]
--- Comment #4 from pault at gcc dot gnu dot org 2007-08-30 22:18 --- This no longer segfaults and it generates correct code for valid fortran. However, program array_char implicit none character (len=2) :: x, y x = "a " y = "cd" print*,[trim(x),trim(y)] end program array_char does not generate the runtime error that it should, so I am leaving this PR open. I have unassigned myself for now but might well return to this soon. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pault at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Keywords|ice-on-valid-code |accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2007-08-30 22:24 --- Subject: Re: TAB in FORMAT: accept extension, warn with -std=f* On Thu, Aug 30, 2007 at 09:52:56PM -, fago at caltech dot edu wrote: > > --- Comment #12 from fago at caltech dot edu 2007-08-30 21:52 --- > A stupid question: why cannot gfortran detect this invalid code at compile > time? I was quite surprised by a runtime error. > See comment #9 in bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug libstdc++/33247] [4.3 regression] libstdc++ testsuite_abi.cc build failure
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-08-30 23:15 --- thanks! -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33247
[Bug c++/33255] A warning for "unused" typedefs?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-30 23:30 --- I think it is wrong to warn for unused typedefs, they are all over headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] A warning for "unused" typedefs?
--- Comment #2 from pcarlini at suse dot de 2007-08-30 23:33 --- Careful, only *in function bodies*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] New: A warning for "unused" typedefs?
Just a wild idea, motivated by libstdc++/33084: in that case we had a function with this body: typedef _BinClos<_Name, _Constant, _ValArray, _Tp, _Tp> _Closure; typedef typename __fun<_Name, _Tp>::result_type _Rt; return _Expr<_Closure, _Tp>(_Closure(__t, __v)); where the fact that _Rt was completely pointless clearly hinted to a bug, a typo _Tp -> _Rt in the last line. Would it make sense to add an option to the front-end to warn in such cases? -- Summary: A warning for "unused" typedefs? Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] A warning for "unused" typedefs?
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-30 23:43 --- Subject: Re: A warning for "unused" typedefs? On Thu, 30 Aug 2007, pinskia at gcc dot gnu dot org wrote: | I think it is wrong to warn for unused typedefs, they are all over headers. In general, I tend to agree with Andrew Pinski on this. Maybe the original idea could be refined to *local* typedef declarations. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] A warning for "unused" typedefs?
--- Comment #4 from pcarlini at suse dot de 2007-08-30 23:46 --- (In reply to comment #3) > Maybe the original idea could be refined to *local* typedef > declarations. Of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] A warning for "unused" typedefs?
--- Comment #5 from gdr at cs dot tamu dot edu 2007-08-30 23:51 --- Subject: Re: A warning for "unused" typedefs? On Thu, 30 Aug 2007, pcarlini at suse dot de wrote: | | | --- Comment #4 from pcarlini at suse dot de 2007-08-30 23:46 --- | (In reply to comment #3) | > Maybe the original idea could be refined to *local* typedef | > declarations. | | Of course. The tricky part is how to determine that a typedef is used. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] A warning for "unused" typedefs?
--- Comment #6 from pcarlini at suse dot de 2007-08-30 23:59 --- Well, assuming there are no "no-go" theorems about that problem ;) I would be certainly interested in studying the problem in better detail... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] A warning for "unused" typedefs?
--- Comment #7 from gdr at cs dot tamu dot edu 2007-08-31 00:05 --- Subject: Re: A warning for "unused" typedefs? On Thu, 30 Aug 2007, pcarlini at suse dot de wrote: | Well, assuming there are no "no-go" theorems about that problem ;) I would be | certainly interested in studying the problem in better detail... I did not mean to imply that the problem is unsolvable or NP-complete or something like that. I just pointed out that usually we rely on (1) data flow insfrastructure, (2) uniqueness of entities refered to by variable and functions to warn about unused declarations. Typedefs on the other hand can be "folded" in very early on. So, one needs to track that folding... -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
