--- 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 o
--- 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 go
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/
--- 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/benchmar
--- 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 p
--- 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):
--- 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 2
--- 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
--- 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
--- 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: Cha
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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_bu
--- 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.
--- 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 +38
--- 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/
--- 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
--- 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 proce
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
--- 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
--- 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:
--- 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
-
--- 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/sh
--- 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- 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 fort
--- 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
--- 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 co
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 ||
--- 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 su
--- 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 compi
--- 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]>
--- 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
--- 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
-
--- 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
--- 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 cap
--- 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 **
--- 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
--- 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 submi
--
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
--- 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
--- 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
Stat
--- 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_
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/i
--- 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 fig
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 --
--- 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
--
--- 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
--- 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, th
l-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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
--- 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-unknow
PASS: 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.
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 ...
> R
--- 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 tha
> /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
--- 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 <
--- 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 compil
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
--- 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
--- 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:
--- 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
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
--- 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
--- 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
--- 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/
--- 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
---
--- 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
--- 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/
--- 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
--- 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
--- 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
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Target Milestone|--- |4.2.2
ht
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33205
--- 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 proble
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 gfortr
--- 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/
--- 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/
--- 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/
--- 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
--- 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/
--- 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
---
--- 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
--
--- 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
---
--- 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 no
--- 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 200
--- 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
--- 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
--- 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
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 t
--- 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
--- 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
--- 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
--- 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
--- 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
1 - 100 of 129 matches
Mail list logo