headers
Gerald Pfeifer | 1 Feb 2011 01:54

[listdc++ doc] Refer to GDB instead of gdb and fix link

A small documentation change.  I committed this to mainline and
plan on backporting later...

Gerald

2011-02-01  Gerald Pfeifer  <gerald <at> pfeifer.com>

	* doc/xml/manual/debug.xml: Use GDB instead of gdb.
	Adjust link to GDB manual.

Index: doc/xml/manual/debug.xml
===================================================================
--- doc/xml/manual/debug.xml	(revision 169462)
+++ doc/xml/manual/debug.xml	(revision 169463)
 <at>  <at>  -46,7 +46,7  <at>  <at> 
   communicate information about source constructs can be changed via
   <code>-gdwarf-2</code> or <code>-gstabs</code> flags: some debugging
   formats permit more expressive type and scope information to be
-  shown in gdb. Expressiveness can be enhanced by flags like
+  shown in GDB. Expressiveness can be enhanced by flags like
   <code>-g3</code>. The default debug information for a particular
   platform can be identified via the value set by the
   PREFERRED_DEBUGGING_TYPE macro in the gcc sources.
 <at>  <at>  -246,13 +246,13  <at>  <at> 
   </para>

 <para>
-  Many options are available for gdb itself: please see <link
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://sources.redhat.com/gdb/current/onlinedocs/gdb_13.html#SEC125">
-  "GDB features for C++" </link> in the gdb documentation. Also
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joseph S. Myers | 1 Feb 2011 02:15

Add Cygwin/MinGW -posix option from specs to i386/cygming.opt

In preparation for the driver only accepting options listed in .opt
files, and not other options that simply happen to match some spec,
this patch adds the -posix option from specs in i386/cygwin.h,
i386/mingw-w64.h and i386/mingw32.h to i386/cygming.opt.

Tested building cc1 and xgcc for crosses to: i686-cygwin i686-mingw32
x86_64-mingw32.  OK to commit?

2011-01-31  Joseph Myers  <joseph <at> codesourcery.com>

	* config/i386/cygming.opt (posix): New Driver option.

Index: gcc/config/i386/cygming.opt
===================================================================
--- gcc/config/i386/cygming.opt	(revision 169317)
+++ gcc/config/i386/cygming.opt	(working copy)
 <at>  <at>  -1,6 +1,6  <at>  <at> 
 ; Cygwin- and MinGW-specific options.

-; Copyright (C) 2005, 2007, 2009, 2010 Free Software Foundation, Inc.
+; Copyright (C) 2005, 2007, 2009, 2010, 2011 Free Software Foundation, Inc.
 ;
 ; This file is part of GCC.
 ;
 <at>  <at>  -49,3 +49,6  <at>  <at>  Use the GNU extension to the PE format f
 muse-libstdc-wrappers
 Target Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)})
 Compile code that relies on Cygwin DLL wrappers to support C++ operator new/delete replacement
+
+posix
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benjamin Kosnik | 1 Feb 2011 02:34
Picon
Favicon

[v3] doxygen vs. pdf


With PDF_HYPERLINKS requires doxygen-1.7.0. Details in 

https://bugzilla.gnome.org/show_bug.cgi?id=641083

Last pass for include vs. headername alias.

tested x86/linux

-benjamin
Attachment (20110131-4.patch): text/x-patch, 7553 bytes
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Feb 2011 03:31
Favicon

Re: [patch, libquadmath] PR47293 NAN not correctly read

On 01/29/2011 11:13 AM, Jerry DeLisle wrote:
> On 01/27/2011 11:42 AM, Jakub Jelinek wrote:
>> On Wed, Jan 26, 2011 at 07:43:51PM -0800, Jerry DeLisle wrote:
>>> This patch is simple. The bit pattern for NAN was mixed up.
>>
>> 1) It should be 0x7fff8000 instead of 0xffff8000
>> 2) the code will handle endianess incorrectly
>> case STRTOG_NaN:
>> L[0] = ld_QNAN0;
>> L[1] = ld_QNAN1;
>> L[2] = ld_QNAN2;
>> L[3] = ld_QNAN3;
>> should be
>> L[_3] = ld_QNAN0;
>> L[_2] = ld_QNAN1;
>> L[_1] = ld_QNAN2;
>> L[_0] = ld_QNAN3;
>>
>
> Here is an updated patch. I will submit a change to the testsuite separately.
>
> OK for trunk?

Sending        ChangeLog
Sending        gdtoa/gd_qnan.h
Sending        gdtoa/strtopQ.c
Transmitting file data ...
Committed revision 169466.

Committed under obvious rule.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Pop | 1 Feb 2011 05:50
Picon
Gravatar

[PATCH] Fix PR47561: print the Graphite flags.

Hi,

when GCC is not configured with Graphite, it prints an error message
whenever a flag depending on Graphite is used.

This patch improves the printed message by listing all the flags that
cannot be used.  The patch also adds a missing flag -floop-flatten to
the list.

Regstrap in progress on amd64-linux.  Ok for trunk?

Thanks,
Sebastian

2011-01-31  Sebastian Pop  <sebastian.pop <at> amd.com>

	PR tree-optimization/47561
	* toplev.c (process_options): Print the Graphite flags.  Add
	flag_loop_flatten to the list of options requiring Graphite.
---
 gcc/ChangeLog |    6 ++++++
 gcc/toplev.c  |    8 ++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a17a9a3..d674043 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
 <at>  <at>  -1,5 +1,11  <at>  <at> 
 2011-01-31  Sebastian Pop  <sebastian.pop <at> amd.com>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Korn | 1 Feb 2011 07:06
Picon

Re: Add Cygwin/MinGW -posix option from specs to i386/cygming.opt

On 01/02/2011 01:15, Joseph S. Myers wrote:
> In preparation for the driver only accepting options listed in .opt
> files, and not other options that simply happen to match some spec,
> this patch adds the -posix option from specs in i386/cygwin.h,
> i386/mingw-w64.h and i386/mingw32.h to i386/cygming.opt.
> 
> Tested building cc1 and xgcc for crosses to: i686-cygwin i686-mingw32
> x86_64-mingw32.  OK to commit?

  Sure is, thank you.

    cheers,
      DaveK
Permalink | Reply | 0 comments |
headers
Dave Korn | 1 Feb 2011 07:14
Picon

Re: PATCH: PR driver/47547: WHOPR, can't use /dev/null as an output file

On 31/01/2011 19:30, H.J. Lu wrote:
> On Mon, Jan 31, 2011 at 11:09 AM, Diego Novillo <dnovillo <at> google.com> wrote:
>> On Mon, Jan 31, 2011 at 14:03, H.J. Lu <hongjiu.lu <at> intel.com> wrote:
>>
>>>  <at>  <at>  -392,6 +392,7  <at>  <at>  run_gcc (unsigned argc, char *argv[])
>>>   if (linker_output)
>>>     {
>>>       char *output_dir, *base, *name;
>>> +      bool bit_bucket = !strcmp (linker_output, HOST_BIT_BUCKET);
>> strcmp != 0, please.
> 
> Will do.

  You mean "strcmp == 0" not "!=", in this instance.  (Just in case you didn't
already spot it.)

    cheers,
      DaveK
Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 1 Feb 2011 07:40
Picon
Picon

Re: [libgo, build] Use convenience libraries to create .gox files

[ adding libtool-patches ]

* Rainer Orth wrote on Mon, Jan 31, 2011 at 03:54:29PM CET:
> GNU ld testing failed initially for the 64-bit multilib:
> 
> libtool: link: /vol/gcc/obj/gcc-4.6.0-20110128/11-gcc-gas-gld-go/./gcc/collect-ld -r -o
crypto/libsubtle.o    --whole-archive crypto/.libs/libsubtle.a --no-whole-archive
> /vol/gcc/bin/gld-2.21: Relocatable linking with relocations from format elf64-x86-64-sol2
(sort/.libs/libsort.a(libsort.a.o)) to format elf32-i386-sol2 (sort/libsort.o) is not supported
> make[7]: *** [sort/libsort.lo] Error 1
> 
> Ultimately, this turned out to be a libtool issue: it doesn't handle
> Solaris 2/x86 at all, and Solaris 2/SPARC with GNU ld is incomplete in
> that it doesn't account for the new *_sol2 emulations in gld 2.21.  All
> this second-guessing the compiler suggests to me that it's a bad idea to
> call the linker directly if gcc is in use.

I know libtool bashing is hitting an easy target, but IIRC we still had
user reports last year of (probably older) GCC installations where
partial linking did not work when using the gcc driver, as opposed to
using ld directly (note! for partial linking).

Anyway, I'm applying your patch to upstream Libtool, as below.

Thanks,
Ralf

2011-02-01  Rainer Orth  <ro <at> ...>  (tiny change)

	Fix LD setting for 64-bit Solaris 2/x86.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nathan Sidwell | 1 Feb 2011 08:28

Re: Add ARM VxWorks options from specs to new arm/vxworks.opt

On 01/31/11 23:56, Joseph S. Myers wrote:
> In preparation for the driver only accepting options listed in .opt
> files, and not other options that simply happen to match some spec,
> this patch adds options from specs in arm/vxworks.h to a new
> arm/vxworks.opt.
>
> This sort of -t option - handled only in specs, and used in multilib
> selection - is the sort that critically needs to go in .opt files for
> multilib selection to be based on the gcc_options structure.  (These
> options will also need in due course to set something in that
> structure, for which adding Var entries will be the simplest
> approach.)  There are other such cases for some other targets as well,
> while the various options that are not used in multilib selection are
> being added to .opt files not because that is directly needed for
> multilib selection changes but because it allows driver errors for
> options not in .opt files and so helps avoid accidental future
> addition of multilib-relevant options (in forward-ported patches, say)
> in specs only.  (Having all options in .opt files is potentially
> useful in other ways as well.)
>
> Tested building cc1 and xgcc for cross to arm-wrs-vxworks.  OK to
> commit?

ok

--

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
Permalink | Reply | 0 comments |
headers
Janne Blomqvist | 1 Feb 2011 09:28
Picon

Re: [Patch, libfortran] Use high resolution clock if available, timing cleanup

On Tue, Feb 1, 2011 at 04:38, Hans-Peter Nilsson <hp <at> bitrange.com> wrote:
> On Mon, 31 Jan 2011, Janne Blomqvist wrote:
>> the attached patch
>>
>> 1) Does some cleanup for CPU timing functions.
>>
>> 2) Uses clock_gettime() if available, and if so in particular:
>>       2a) enables up to nanosecond resolution for system_clock_8.
>>       2b) SYSTEM_CLOCK uses the monotonic clock, if available, which
>> is a better choice for a wallclock timing function.
>
> 3) Uses errno without including errno.h (or the equivalent
> action), breaking build on some targets.

Thanks for the report. Committed r169467 as obvious.

--

-- 
Janne Blomqvist
Permalink | Reply | 0 comments |

Gmane