* Robert Dewar:
Duplication is how other GNU projects handle this. For instance, many
Emacs Lisp functions are documented twice: once as a docstring in the
source code (which is roughly equivalent to the comment-in-spec
approach), and once in the Elisp reference (which is GFDLed).
Well
I think there is a difference between a novel you can hold and
read, and computer documentation. My question was not whether
anyone reads books any more, it was whether people read computer
manuals in this form any more.
To me, it depends on the type of manual and whether it's for something
Florian Weimer wrote:
I was still referring to computer documentation, but admittedly not
reference manuals, rather works like introductory texts which have got
some sort of narrative strucuture which guides the reader.
For reference manuals, it takes a huge amount of effort to make the
Florian Weimer wrote:
* Robert Dewar:
In the case of interfaces to library routines, what we do
is to have fully commented Ada package specs that act as
both the documentation of the implementation interface and
as the user documentation (for an example, look at g-spipat.ads).
I can't see any
* Robert Dewar:
Does *anyone* print documentation out as a book, this seems to me
to be a completely obsolete concept.
People still buy books which are available freely in electronic form.
This means that some printing still goes on.
It might also be necessary to consider what it means when a
* Robert Dewar:
People still buy books which are available freely in electronic form.
This means that some printing still goes on.
I think there is a difference between a novel you can hold and
read, and computer documentation. My question was not whether
anyone reads books any more, it was
This approach is far less useful for languages which haven't got
separate spec files
But there aren't many of those! In C, a .h file can easily be viewed as
a separate spec file and interface documentation can and should be placed
there, though I understand that few coding conventions call for
Florian Weimer wrote:
* Robert Dewar:
Does *anyone* print documentation out as a book, this seems to me
to be a completely obsolete concept.
People still buy books which are available freely in electronic form.
This means that some printing still goes on.
I think there is a difference
* Robert Dewar:
In the case of interfaces to library routines, what we do
is to have fully commented Ada package specs that act as
both the documentation of the implementation interface and
as the user documentation (for an example, look at g-spipat.ads).
I can't see any value in duplicating
On 08/15/2010 04:09 AM, Florian Weimer wrote:
* Robert Dewar:
Duplication is how other GNU projects handle this. For instance, many
Emacs Lisp functions are documented twice: once as a docstring in the
source code (which is roughly equivalent to the comment-in-spec
approach), and once in
* Joel Sherrill:
This approach is far less useful for languages which haven't got
separate spec files because it encourages programmers of client code
to look at the implementation, potentially picking up implementation
details. It encourages the documentation writer to accidentally refer
Snapshot gcc-4.3-20100815 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100815/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Sun, 15 Aug 2010, gccad...@gcc.gnu.org wrote:
gcc-4.3-20100815.tar.bz2 Complete GCC (includes all of below)
SHA1=4fa7230c4535f91521bda26cc225508fe0b4e626
In case anyone wonders, given the weakness of md5 I added sha1 as an
additional hash¹. md5 is just missing due
Hi Rick (and others),
On Thu, 12 Aug 2010, Rick C. Hodgin wrote:
This question would have been more appropriate on the gcc-help mailing
list. -Ian Lance Taylor
My apologies to everyone. I did not know such a list existed.
all of our web pages have a footer which refers to gcc-help, but
On Sun, Aug 15, 2010 at 2:44 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
Hi Rick (and others),
On Thu, 12 Aug 2010, Rick C. Hodgin wrote:
This question would have been more appropriate on the gcc-help mailing
list. -Ian Lance Taylor
My apologies to everyone. I did not know such a list
Florian Weimer f...@deneb.enyo.de writes:
Duplication is how other GNU projects handle this. For instance, many
Emacs Lisp functions are documented twice: once as a docstring in the
source code (which is roughly equivalent to the comment-in-spec
approach), and once in the Elisp reference
Building gcc 4.5.1:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common
--- Comment #2 from domob at gcc dot gnu dot org 2010-08-15 15:28 ---
Subject: Bug 45197
Author: domob
Date: Sun Aug 15 15:28:10 2010
New Revision: 163261
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163261
Log:
2010-08-15 Daniel Kraft d...@domob.eu
PR fortran/45197
--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-15 16:21 ---
Subject: Bug 45211
Author: burnus
Date: Sun Aug 15 16:20:56 2010
New Revision: 163264
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163264
Log:
2010-08-15 Tobias Burnus bur...@net-b.de
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-15 16:23 ---
FIXED on the trunk (4.6). Thanks for the bug report!
(I do not intent to backport the patch to the 4.4/4.5 branch; tell me if you
think it should be applied there as well.)
--
burnus at gcc dot gnu dot org
--- Comment #3 from domob at gcc dot gnu dot org 2010-08-15 16:26 ---
Fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-15 16:26 ---
FIXED on the 4.6 trunk.
I have missed to include the PR when writing, submitting, and committing the
patch. It can be found at:
Patch: http://gcc.gnu.org/ml/fortran/2010-08/msg00174.html
Committal:
--- Comment #4 from paul dot richard dot thomas at gmail dot com
2010-08-15 16:32 ---
Subject: Re: Segmentation fault with -fwhole-file for subref_array_pointer
Dear Jerry,
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-08-09 17:18
---
Paul, can you send me
The following program (pasted in the #fortran IRC channel) is accepted by
gfortran -- unless -std=f2008 is used.
Expected: By default a warning (or error) is printed - if two different values
are used. Maybe one should reject the program altogether - or allow it only
with -std=legacy. -- The
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-08-15
17:36 ---
These still appear to be present on i386-apple-darwin10 but not
x86_64-apple-darwin10. Odd.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-15 18:46 ---
A patch to do the parsing and some error checking has
been posted at
http://gcc.gnu.org/ml/fortran/2010-08/msg00181.html
It is not a complete implementation of the feature
and requires much additional work.
--
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:47 ---
Created an attachment (id=21480)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21480action=view)
compressed preprocessed source for 20_util/auto_ptr/6.cc on
-i386-apple-darwin10
--
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:48 ---
Created an attachment (id=21481)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21481action=view)
compressed assembly file for 20_util/auto_ptr/6.cc on -i386-apple-darwin10
--
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:48 ---
Created an attachment (id=21482)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21482action=view)
compressed object file for 20_util/auto_ptr/6.cc on -i386-apple-darwin10
--
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:52 ---
Files created with...
/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/g++ -shared-libgcc
-B/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc -nostdinc++
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target |middle-end
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-15 19:05 ---
Is this still a problem for you? I can try to help you here, but I need to know
what patch I should apply and to what revision, to reproduce the problem.
--
steven at gcc dot gnu dot org changed:
What
As originally reported at
http://lists.opensuse.org/opensuse-packaging/2010-08/msg00038.html POSIX 2008
says
(http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_12_03):
2.12.3 Pointer Types
All function pointer types shall have the same representation as the type
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-15 19:31 ---
*(void **)(comp_compress) = dlsym(handle, comp_compress);
That is not alias safe. Try instead:
comp_compress = (__typeof__(comp_compress)) dlsym(handle, comp_compress);
Which is alias safe. In fact reading what
--- Comment #2 from artyom dot shinkaroff at gmail dot com 2010-08-15
19:35 ---
Created an attachment (id=21483)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21483action=view)
Recent version of the patch for the revision 163240
Recent version of the patch for the revision 163240
--- Comment #3 from artyom dot shinkaroff at gmail dot com 2010-08-15
19:38 ---
Yes, I still would like to solve the problem.
I just uploaded the patch for the revision 163240 (2010-08-14). The bug is
still there. The problem happens when you compile the following code with -On
-g.
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-15 19:38 ---
I don't think adding -std=posix is the right solution, since dlsym needs to be
usable if users choose other options such as -std=c++0x or -std=gnu99
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289
John Reid, The new features of Fortran 2008, chapter 5.5:
A pointer may be initially associated with a target:
type (entry), target :: bottom
type (entry), pointer :: top = bottom
*
Currently gfortran responds with:
type (entry), pointer :: top = bottom
1
--- Comment #6 from domob at gcc dot gnu dot org 2010-08-15 19:46 ---
Subject: Bug 38936
Author: domob
Date: Sun Aug 15 19:46:21 2010
New Revision: 163268
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163268
Log:
2010-08-15 Daniel Kraft d...@domob.eu
PR fortran/38936
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-15 19:47 ---
Yes, POSIX adds additional requirements about pointer representation and
conversion, but AFAIK all targets GCC support and have POSIXish runtime satisfy
that. The conversion between pointer types is not the problem
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-15 20:01 ---
(In reply to comment #4)
Possible solutions:
1) Make sure we use the right symbol from the right module.
2) Do the vtab initialization inside the module that defines the class, i.e.
add a module procedure like
Opening caveats: This comes from a day of digging into why the Arduino
environment wasn't working correctly on my Fedora 13 system with avr-gcc-4.5.
I'm not a GCC hacker and not intending to become one, so forgive sloppy
terminology and if the right fix is one of the larger things I mention below,
--- Comment #4 from reddwarf at opensuse dot org 2010-08-15 20:21 ---
Yes, POSIX adds additional requirements about pointer representation and
conversion, but AFAIK all targets GCC support and have POSIXish runtime
satisfy
that. The conversion between pointer types is not the
--- Comment #7 from domob at gcc dot gnu dot org 2010-08-15 20:25 ---
This extended the support to array-expressions -- the original example works
now. Next will be a rework to do the association in the trans phase, which is
probably necessary to get full array support and association
--- Comment #1 from otaylor at redhat dot com 2010-08-15 20:27 ---
Created an attachment (id=21484)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21484action=view)
Patch removing the frame pointer from general regs
Here's the patch described; I don't have any sort of extensive
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-15 20:36 ---
It works for me:
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /export/home/hjl/bugs/gcc/pr45286/foo
Breakpoint 1, sigvtalarm (foo=0) at
--- Comment #8 from vapier at gentoo dot org 2010-08-15 20:40 ---
yes, we did. take the .i files we already posted and compile them with the
quoted pic/pie flags and look at the disassembled code.
the hardened gentoo variant builds all of glibc with pic/pie support (including
static
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-08-15 20:41 ---
Hello Paul,
I think the patch you committed to 4.5 causes a regression for normal
loops, which are now handled as overlapping.
I think I fixed that in
http://gcc.gnu.org/viewcvs?view=revisionrevision=162829
on
--- Comment #9 from hjl dot tools at gmail dot com 2010-08-15 20:45 ---
You have to show me exact CFLAGS used to compile sigaction.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
--- Comment #4 from steven at gcc dot gnu dot org 2010-08-15 20:48 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from vapier at gentoo dot org 2010-08-15 21:01 ---
from the glibc-2.11.2/signal/ subdir:
$ gcc -Wall -Winline -Wwrite-strings -Wstrict-prototypes -std=gnu99 -O2
-fgnu89-inline -fmerge-all-constants -fno-strict-aliasing -fno-unwind-tables -g
-pipe
--- Comment #5 from matz at gcc dot gnu dot org 2010-08-15 21:07 ---
First, yes, the work-around from the official POSIX man-pages is alias-unsafe.
They added this example because ISO C doesn't allow conversion of void*
pointers to function pointer, but dlsym returns a void* pointer.
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-15 21:15
---
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got
movq__restore...@gotpcrel(%rip), %rax
movq%rax, 56(%rsp)
in assembly output. It is correct. Please make sure that
you
--- Comment #12 from zorry at ume dot nu 2010-08-15 21:31 ---
(In reply to comment #11)
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got
movq__restore...@gotpcrel(%rip), %rax
movq%rax, 56(%rsp)
in assembly output. It is correct.
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-15 21:33 ---
There are more possibilities, like:
3) void (*fnptr) (void); void *p = dlsym (...); memcpy (fnptr, p, sizeof
(p)); fnptr ();
The POSIX standard wording doesn't talk about void * and function pointers
being compatible
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-15 21:36
---
(In reply to comment #12)
(In reply to comment #11)
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got
movq__restore...@gotpcrel(%rip), %rax
movq%rax, 56(%rsp)
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-15 21:38 ---
Note that this is a common mistake anyways and for example with LTO we
unify all pointer alias-sets to that of void *. In fact I proposed that
for all languages anyway (look at the hack the C++ FE has for
--- Comment #14 from vapier at gentoo dot org 2010-08-15 21:59 ---
we are using current GNU binutils (2.20.1). we dont use Linux binutils anymore
in Gentoo by default due to the instability and random patches that never get
mainlined into the GNU binutils. however, even with
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-08-15 22:11
---
(In reply to comment #14)
we are using current GNU binutils (2.20.1). we dont use Linux binutils
anymore
in Gentoo by default due to the instability and random patches that never get
mainlined into the GNU
When configured for i586-linux, there are extra
libgomp test failures:
FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/pr39591-1.c execution test
FAIL: libgomp.c/pr39591-2.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c/task-2.c execution test
FAIL:
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail||4.5.3 4.6.0
Known to work||4.4.4
--- Comment #1 from zsojka at seznam dot cz 2010-08-15 23:09 ---
Created an attachment (id=21485)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21485action=view)
reduced testcase
Testcase crashes at x86_64-linux as well.
Valgrind output (r163261):
$ valgrind --trace-children=yes
--- Comment #2 from zsojka at seznam dot cz 2010-08-15 23:23 ---
Created an attachment (id=21486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21486action=view)
reduced testcase
Crashes at x86_64-linu as well.
Valgrind output (r163261):
$ valgrind --trace-children=yes -q
--- Comment #8 from matz at gcc dot gnu dot org 2010-08-16 00:55 ---
Well, okay, (3) indeed is valid ISO C (no warning) and works on POSIX 2008.
I'd find it very awkward to write such work-around for (1) just so the
warning in strict ISO C mode is silenced. I find this case different
with g++-4.5.1 (powerpc-apple-darwin8):
internal compiler error: in iterative_hash_template_arg, at cp/pt.c:1589
with the attached unreduced test case, which I'm delta-reducing at the
moment...
never tested against 4.5.0.
This code compiled with 4.4.x and earlier, which leads me to believe that
--- Comment #1 from fang at csl dot cornell dot edu 2010-08-16 01:07
---
Created an attachment (id=21487)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21487action=view)
unreduced test case triggering ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-16 01:13 ---
It is caused by revision 145825:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00448.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-16 01:18 ---
libgomp is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-16 02:29 ---
task.o is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-16 02:52 ---
gomp_barrier_handle_tasks is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
This is a friendly reminder there's still no way to enjoy pextrw without undue
zero/sign extension unless inline asm is used; there's even a gradient of
ignominy from intrinsic to builtins, as exemplified by:
$ cat pextrw.cc
#include smmintrin.h
long unsigned int foo1(__m128i x) { return
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-16 05:04 ---
Disable
+(define_expand cmpcc
+ [(set (reg:CC FLAGS_REG)
+(compare:CC (match_operand 0 flags_reg_operand )
+(match_operand 1 general_operand )))]
+
+{
+ ix86_compare_op0 =
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-16 05:18 ---
-mtune=i586 miscompiled gomp_barrier_handle_tasks which
has a loop and calls:
static inline void gomp_mutex_lock (gomp_mutex_t *mutex)
{
if (!__sync_bool_compare_and_swap (mutex, 0, 1))
gomp_mutex_lock_slow
73 matches
Mail list logo
