Richard Kenner wrote:
But even for documentation written by hand, often I find that I'd like to
start out with some comment or example from the actual code. The GPL / GFDL
dichotomy doesn't allow me to do that, so some documentation just won't get
written.
Taking an example from actual code
Jeff Law wrote:
Isn't one of the specific instances of this issue the desire to copy
some of the constraints information from the source, which would need to
go into the user manual rather than internals documentation?
And in some cases a function index with documentation may be precisely
Mark Mitchell wrote:
Yes, that is part of his thinking. And, yes, we can split our manuals
up into GPL and GFDL pieces, and in some cases that will work fine.
But, documentation of constraints (important to users for writing inline
assembly), or documentation of command-line options (important
#the_weec
#Le_secr_taire
WEEC’s Corner for Environmental Education Publications
The WEEC (World Environmental Education Cngress) Permanent
Secretariat is trying to turn the website into a window for world-wide
publications, review and events on environmental education.
If an organization
Robert Dewar wrote:
I don't think it is making this impossible, my advice is simply to
consider this fair use and steam ahead, then worry if someone objects.
Despite the copyright holder (well, RMS, but he certainly can be
interpreted as speaking for the FSF) saying plainly and clearly that he
Quoting Mark Mitchell m...@codesourcery.com:
Robert Dewar wrote:
I don't think it is making this impossible, my advice is simply to
consider this fair use and steam ahead, then worry if someone objects.
Despite the copyright holder (well, RMS, but he certainly can be
interpreted as speaking
Richard Kenner wrote:
But even for documentation written by hand, often I find that I'd like to
start out with some comment or example from the actual code. The GPL / GFDL
dichotomy doesn't allow me to do that, so some documentation just won't get
written.
Taking an example from actual code
Mark Mitchell wrote:
Robert Dewar wrote:
I don't think it is making this impossible, my advice is simply to
consider this fair use and steam ahead, then worry if someone objects.
Despite the copyright holder (well, RMS, but he certainly can be
interpreted as speaking for the FSF) saying
Robert Dewar wrote:
Whether something is fair use has to be judged on the very specific
instance in question, not clear to me that RMS has opined on a very
specific issue, if so, I missed it.
We don't want to ask RMS every time we want to do this. RMS has opined
on some of the specific
Quoting Robert Dewar de...@adacore.com:
Joern Rennecke wrote:
Actually, the legal definition of fair use / fair dealing that
might or might
not apply depends on the country of residence of the contributer
Not true in the US for sure.
Are you saying that the USA is a solipsist nation
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-30 07:02 ---
(In reply to comment #2)
it prints the following output:
ifc: ( 1.000, 0.000) ( 2.000, 0.000) (
3.000, 0.000)
ap
Segmentation fault
If one changes
r162396 OK
r162497 KO
/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
-B/n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/bin/
-B/n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/bin/
-B/n/57/guerby/install-t\
Hopefully this isn't standard defined behavior, because it doesn't make much
sense.
// trying to have some overloaded functions to share some private data:
class A {
private:
// some static stuff
// ...
public:
A(int a, int b = 0) {}
// more versions of A(...)
// ...
};
int
--- Comment #5 from rguenther at suse dot de 2010-07-30 08:41 ---
Subject: Re: No prefetch for the vectorized
loop
On Thu, 29 Jul 2010, changpeng dot fang at amd dot com wrote:
--- Comment #4 from changpeng dot fang at amd dot com 2010-07-29 19:14
---
(In reply to
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-30 08:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-30 09:03 ---
Remove assignment. I think I won't work on this in the next weeks and New is
better in allowing others to pick it up. If not, I will look at it again later.
The patch of attachment 20714 plus the fix in comment 15
$ valgrind ~/gcc-build/gcc/f951 -O -std=f2003 typebound_proc_15.f03
==22333== Memcheck, a memory error detector
==22333== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==22333== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==22333== Command:
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-30 09:22 ---
It can't be the same bug, please open a new one. Thx.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-30 09:32
---
It is, and it's well known.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-30 09:32 ---
I see the same with -m32 on x86_64. Interestingly I see it with -O0
and libgfortran from 4.5 as well, so it looks like a frontend problem, not
a library problem to me.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-30 09:37 ---
*** This bug has been marked as a duplicate of 45067 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-30 09:37 ---
*** Bug 45138 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from janus at gcc dot gnu dot org 2010-07-30 09:38 ---
*** Bug 45140 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-30 09:38 ---
*** This bug has been marked as a duplicate of 44584 ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-30 09:40 ---
Confirmed, this seems to be sched1 fault.
In bb5 we have 2 normal insns, followed by (-g only) a debug_insn, followed by
two NOTE_INSN_DELETED created by combine (do we ever remove these from the
IL?),
followed again
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-30 09:48 ---
This is likely dup of PR45136. Again, NOTE_INSN_DELETED moved just with -g and
kept where it was with -g0.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dominiq at lps dot ens dot fr 2010-07-30 09:58 ---
Revision 162697 fixes this pr on powerpc-apple-darwin9. If there is no
objection in the coming 12 hours from other ppc platforms, I'll close the pr as
fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
--- Comment #13 from mikael at gcc dot gnu dot org 2010-07-30 10:23 ---
I have a patch.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
Current gcc trunk (but not gcc 4.5.1) ICEs when linking cns_solve using -O2
-fwhopr -fwholeprogram. The reduced test case is attached and crashes as...
[MacPro:~/badlinkdir2] howarth% more README
[MacPro:~/badlinkdir2] howarth% gfortran -c -fdefault-integer-8 -w -O2 -fwhopr
-fwhole-program
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-07-30
10:43 ---
Created an attachment (id=21358)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21358action=view)
reduced testcase of lto1 crash when linking cns_solve.
--
t.c:24:1: error: could not split insn
(insn:TI 20 47 43 (set (mem/c:V4SI (reg/f:DI 7 sp) [3 %sfp+-64 S16 A128])
(vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 0 ax))
(mem/c:V4SI (reg/f:DI 7 sp) [3 %sfp+-64 S16 A128])
(const_int 1 [0x1]))) t.c:16 1424
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-07-30
10:47 ---
The ICE in lto1 backtraces as...
gdb /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto1
(gdb) r -fPIC -feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase
--- Comment #14 from mikael at gcc dot gnu dot org 2010-07-30 11:00 ---
(In reply to comment #13)
I have a patch.
No, I don't.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-30 11:01 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-30 11:01 ---
Subject: Bug 45141
Author: rguenth
Date: Fri Jul 30 11:01:22 2010
New Revision: 162709
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162709
Log:
2010-07-30 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-30 11:57 ---
Created an attachment (id=21359)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21359action=view)
gcc46-pr45055.patch
So far untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-30 11:59 ---
I agree, and after all, we had one of those two functions already, just private
to combine.c.
See the patch in PR45055.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
--- Comment #15 from mikael at gcc dot gnu dot org 2010-07-30 12:05 ---
The symtree allocated at decl.c:7811
/* Insert it and set attributes. */
if (!stree)
{
stree = gfc_new_symtree (ns-tb_sym_root, name);
gcc_assert (stree);
}
has to
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-07-30 12:54 ---
I've confirmed that gcc46-pr45055.patch solves this PR too.
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
The following is valid according to the F2008 FDIS, but it does not make sense
and is invalid according the the first rounds of interpretation for F08/0030.
gfortran currently ends in an endless loop for the example:
print 20
20 format ( *('a') )
end
As it is a constraint, one needs to
--- Comment #6 from aleksazr at gmail dot com 2010-07-30 13:56 ---
Anyway, the files can be used to generate poor listings,
and that is also a bug. See method2.lss
--
aleksazr at gmail dot com changed:
What|Removed |Added
--- Comment #7 from aleksazr at gmail dot com 2010-07-30 14:00 ---
Poor listings = listings without debug info.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
--- Comment #15 from johnfb at mail dot utexas dot edu 2010-07-30 14:00
---
We have also had some trouble with this issue. We found that in general if we
where running on a machine with hardware threads (i.e., Intel's
Hyper-Threading) then performance was poor. Most of our runs where
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-30 14:06
---
#7 confirms my suspicions. I will try to have a look into this in the next few
days. If anyone else has time, please do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-07-30 14:10
---
Mine
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rth at gcc dot gnu dot org 2010-07-30 14:17 ---
Test case?
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-30 14:24 ---
Created an attachment (id=21360)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21360action=view)
required patch
Together with attached patch (from the vector-enhancement GSoC project).
#define vector(elcount,
--- Comment #7 from bergner at gcc dot gnu dot org 2010-07-30 14:24 ---
Trunk is fixed for powerpc64-linux too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-30 14:30 ---
(In reply to comment #0)
I would assume the result of doing a get() when !valid() is undefined,
No need to assume, it's stated explicitly in the FCD.
so
throwing an exception when someone does this would be
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-30 14:37 ---
Subject: Bug 45055
Author: jakub
Date: Fri Jul 30 14:36:56 2010
New Revision: 162714
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162714
Log:
PR debug/45055
PR rtl-optimization/45137
*
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-30 14:37 ---
Subject: Bug 45137
Author: jakub
Date: Fri Jul 30 14:36:56 2010
New Revision: 162714
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162714
Log:
PR debug/45055
PR rtl-optimization/45137
*
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-30 14:39 ---
On second thoughts, concurrent calls to future::get are also undefined, so
simply asserting valid() would be better. I'll do that asap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-30 14:48 ---
In fact, revision 162688 gave:
FAIL: c-c++-common/uninit-17.c (test for warnings, line 12)
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c (test for excess errors)
FAIL:
--- Comment #53 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-30
15:09 ---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On Thu, 29 Jul 2010, bernds at gcc dot gnu dot org wrote:
--- Comment #51 from bernds at gcc dot gnu dot org 2010-07-29
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-30 15:11 ---
I can also reproduce it with -m32 and x86-64. The dump looks OK; if one uses a
debugger, one sees that in inquire_via_unit:
u-last_record == 0 - instead of the expect 5.
but u-flags.access == ACCESS_DIRECT as
For the following code:
void baz (unsigned);
extern unsigned buf[];
struct A
{
unsigned a1:10;
unsigned a2:3;
unsigned:19;
};
union TMP
{
struct A a;
unsigned int b;
};
static unsigned
foo (struct A *p)
{
union TMP t;
struct A x;
x = *p;
t.a = x;
return t.b;
}
void
bar
--- Comment #54 from bernds at gcc dot gnu dot org 2010-07-30 15:12 ---
Yeah, that's what I did. I if (0)ed the newly added code block to produce
comparisons, but I haven't found anything yet that looks wrong in the dumps
(and I can't read PA assembly very well). So it would be useful
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-30 15:29 ---
One observation: In case one does not have PRIVATE, one initializes seemingly
the global variable
__polynomial_MOD_vtab
while with PRIVATE and failing, one uses the variables vtab$polynomD which is
local in
--- Comment #2 from uweigand at gcc dot gnu dot org 2010-07-30 15:50
---
Subject: Bug 45112
Author: uweigand
Date: Fri Jul 30 15:49:34 2010
New Revision: 162716
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162716
Log:
gcc/
PR c++/45112
* cp/decl.c
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-30 15:57 ---
Fixed on the trunk, will backport to 4.5.2 once 4.5.1 is released.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from uweigand at gcc dot gnu dot org 2010-07-30 16:19
---
Fixed in mainline. Will check in to 4.5 after 4.5.1 release.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #18 from janus at gcc dot gnu dot org 2010-07-30 17:50 ---
Subject: Bug 44929
Author: janus
Date: Fri Jul 30 17:50:28 2010
New Revision: 162724
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162724
Log:
2010-07-30 Janus Weil ja...@gcc.gnu.org
Steven G.
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-30 17:23 ---
Seems -Os specific -- also reproducible on x86. With -O2, the result is
expected.
David
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-30 17:54 ---
4.2.1 is no logner supported, and bugs for Apple builds should be reported to
Apple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45145
--- Comment #19 from janus at gcc dot gnu dot org 2010-07-30 17:55 ---
Fixed with r162724. I am planning to backport this to 4.5 in about a week,
provided it does not introduce any more regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
This should print 100 numbers separated by tabs, then 100 x's separated by
spaces, then 100 x's separated by tabs, then 100 0's (int not char) separated
by tabs. But the last two print fewer than 100--only one line of them.
g++ -v -O0 -Wall --save-temps bug.cc
Using built-in specs.
Target:
--- Comment #1 from allcock at math dot utexas dot edu 2010-07-30 17:33
---
Created an attachment (id=21361)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21361action=view)
preprocessed version of 20-line c++ file exhibiting bug
--
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-30 17:09 ---
The solution IMNSHO is to detect adjacent bitfield operations that can be
handled together and lower bitfield ops still at the tree level, though soon
before expansion, rather than disabling SRA for bitfields.
--
--- Comment #16 from sje at cup dot hp dot com 2010-07-30 18:33 ---
I just tried the patch in comment #15 and successfully bootstrapped GCC on my
32 bit PA system (including building matmul_i1.c). This was on ToT (r162716).
--
sje at cup dot hp dot com changed:
What
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-30 18:39 ---
(In reply to comment #4)
admittedly, I do not fully understand the code which sets
the TBP to the vtable - shouldn't this be done when the vtable for a type is
created rather than every time before it is used?
--- Comment #6 from janus at gcc dot gnu dot org 2010-07-30 18:46 ---
(In reply to comment #4)
One observation: In case one does not have PRIVATE, one initializes seemingly
the global variable
__polynomial_MOD_vtab
while with PRIVATE and failing, one uses the variables
--- Comment #7 from janus at gcc dot gnu dot org 2010-07-30 18:54 ---
(In reply to comment #6)
Good point. Actually the test case is fixed by making the vtab public:
Of course this does not fix the actual problem, but it limits the set of
affected cases (and I guess it's a good idea
--- Comment #6 from hjl dot tools at gmail dot com 2010-07-30 18:54 ---
Fixed by revision 162720.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from binocs38149 at mypacks dot net 2010-07-30 19:01 ---
(In reply to comment #5)
Apple seems to have fixed it a different way:
http://www.opensource.apple.com/source/gcc/gcc-5659/gcc/cp/decl2.c
{
tree underlying_type = TREE_TYPE (DECL_NAME (decl));
int
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-30
19:20 ---
Subject: Re: [4.6 Regression] ICE: Segmentation fault (cc1) compiling
matmul_i1.c
I just tried the patch in comment #15 and successfully bootstrapped GCC on my
32 bit PA system (including building
tr...@162541 does not bootstrap with BOOT_CFLAGS=-g -O3.
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/dbxout.o differs
--
Summary: Bootstrap broken at -O3
Product: gcc
--- Comment #8 from janus at gcc dot gnu dot org 2010-07-30 20:56 ---
(In reply to comment #7)
The test case still fails when adding an 'only' clause in the use statement:
use polynomial, only: polynom
This case can be fixed by the following patchlet:
Index: module.c
--- Comment #17 from ramana at gcc dot gnu dot org 2010-07-30 22:36 ---
Subject: Bug 43698
Author: ramana
Date: Fri Jul 30 22:35:40 2010
New Revision: 162725
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162725
Log:
Backport fix for PR target/43698.
2010-07-30 Ramana
--- Comment #18 from ramana at gcc dot gnu dot org 2010-07-30 22:38 ---
And hence fixed. Thanks for allowing the backport.
Ramana
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dominiq at lps dot ens dot fr 2010-07-30 22:49 ---
Closing.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Status|NEW
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-07-30 23:13
---
Someone might want to try this again after the fix for PR 38582.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
Standard installation of FreeBSD 8.1 on 64 but AMD processor, building package
net-mgmt/net-snmp from /usr/ports, command line is make install with the
options MFD_REWRITES, PERL, PERL_EMBEDDED, and DUMMY selected.
cc (GCC) 4.2.1 20070719 [FreeBSD]
libtool: compile: cc -I../include -I.
This is a meta-tracker for g++ issues with constexpr. It tracks the git branch
of a href=http://gcc.gnu.org/wiki/Constexpr;contexpr/a. There is another
bug for the libstdc++ component.
As of 2010-07-30, x86_64/linux see:
FAIL: abi_check
Running
This is a meta-tracker for libstdc++ issues with constexpr. It tracks the git
branch
of a href=http://gcc.gnu.org/wiki/Constexpr;contexpr/a. There is another
bug for the g++ component (http://gcc.gnu.org/PR45148)
Right now some of the static members of random have been made non-static.
atomic is
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at redhat dot com, gdr
|
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-07-31 01:36 ---
Created an attachment (id=21362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21362action=view)
FAIL 01: 20_util/duration/arithmetic/dr934-1.cc
Pre-processed source
--
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-07-31 01:41 ---
As of 2010-07-30, x86_64/linux see:
FAIL: abi_check
Running
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 20_util/duration/arithmetic/dr934-1.cc (test for excess
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-07-31 01:46 ---
That dr-934-1 ICE is the only thing I see. On g++ testing, I see:
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c (test for excess errors)
=== g++ Summary
--- Comment #17 from damian at rouson dot net 2010-07-31 02:30 ---
Tobias,
Thanks for your continued efforts on this. It will ultimately have a huge
impact on the usability of gfortran for my purposes. I look forward to
hearing more when you get back to it or when others do.
--- Comment #6 from kkojima at gcc dot gnu dot org 2010-07-31 04:45 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-07-31 04:46 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
94 matches
Mail list logo
