Dave Korn | 1 Feb 2010 01:38

Re: Ping: Ping: [Patch][RFA] Warn if pointer is initialized to 'false'

On 31/01/2010 21:18, Mark Mitchell wrote:
> Simon Baldwin wrote:
> 
>>>> Confirmed C++ dejagnu testsuite parity with the unpatched gcc, and verified
>>>> bootstrap of C/C++ on x86_64.
>>>>
>>>> Okay for trunk?  Would pedwarn be preferable to warning?
> 
> This patch is OK.
> 
>>>>        * call.c (conversion_null_warnings): Warn if 'false' is used in
>>>>        pointer assignment or initialization.
> 
> No, I don't think so.  IIUC, false is a valid null pointer constant, so
> there's no reason for a pedwarn; even when pedantic, this code is legal,
> if odd.
> 
> The reason is that [pointer conversions] says that a null pointer
> constant "is an integral constant expression with integer type that
> evaluates to zero".  false is of type bool, which is an integral type,
> and [fundamental types] defines "integer type" as a synonym for
> "integral type" (with the consequence that the set of integer types is
> not the union of the set of signed integer types and the set of unsigned
> integer types).

  Yeah, but it's a bit of a nuisance when you accidentally "return false;"
from something that returns a std::string (-> calls ctor string::string((const
char *)0), which is illegal and generally segfaults), and you can't get a
warning about it.

(Continue reading)

Mark Mitchell | 1 Feb 2010 01:28

Re: Ping: Ping: [Patch][RFA] Warn if pointer is initialized to 'false'

Dave Korn wrote:

>> The reason is that [pointer conversions] says that a null pointer
>> constant "is an integral constant expression with integer type that
>> evaluates to zero".  false is of type bool, which is an integral type,
>> and [fundamental types] defines "integer type" as a synonym for
>> "integral type" (with the consequence that the set of integer types is
>> not the union of the set of signed integer types and the set of unsigned
>> integer types).
> 
>   Yeah, but it's a bit of a nuisance when you accidentally "return false;"
> from something that returns a std::string (-> calls ctor string::string((const
> char *)0), which is illegal and generally segfaults), and you can't get a
> warning about it.

We're talking about whether to issue a pedwarn or a warning, not whether
to warn at all.  We certainly want to warn.

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713

Dave Korn | 1 Feb 2010 02:10

Re: Ping: Ping: [Patch][RFA] Warn if pointer is initialized to 'false'

On 01/02/2010 00:28, Mark Mitchell wrote:
>
> We're talking about whether to issue a pedwarn or a warning, not whether
> to warn at all.  We certainly want to warn.

  Beg pardon, I must have misread the thread.

    cheers,
      DaveK

H.J. Lu | 1 Feb 2010 01:53
Picon

Re: [PATCH] Fix PR42898

On Sun, Jan 31, 2010 at 11:48 AM, Richard Guenther <rguenther <at> suse.de> wrote:
> On Sun, 31 Jan 2010, Richard Guenther wrote:
>
>> On Sun, 31 Jan 2010, Eric Botcazou wrote:
>>
>> > > Ah, indeed - the issue is the looping and the compound-expr.
>> > > Would you mind backporting your patch to the 4.4 and 4.3
>> > > branch together with that testcase?
>> >
>> > Will do.  Your testcase doens't seem to pass on the 4.3 branch at -O0.
>>
>> Ah, we dont' have an optimized dump there.  I'll fix that.
>
> Fixed as follows.
>
> Richard.
>
> 2010-01-31  Richard Guenther  <rguenther <at> suse.de>
>
>        * gcc.dg/torture/pr42898.c: Skip -O0.
>
> Index: gcc/testsuite/gcc.dg/torture/pr42898.c
> ===================================================================
> --- gcc/testsuite/gcc.dg/torture/pr42898.c      (revision 156410)
> +++ gcc/testsuite/gcc.dg/torture/pr42898.c      (working copy)
>  <at>  <at>  -1,4 +1,5  <at>  <at> 
>  /* { dg-do compile } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
>  /* { dg-options "-fdump-tree-optimized" } */
>
(Continue reading)

Michael Matz | 1 Feb 2010 04:12
Picon

Re: [PATCH] Fix PR42898

Hi,

On Sun, 31 Jan 2010, H.J. Lu wrote:

> > 2010-01-31  Richard Guenther  <rguenther <at> suse.de>
> >
> >        * gcc.dg/torture/pr42898.c: Skip -O0.
> 
> On Linux/x86, I got
> 
> FAIL: gcc.dg/torture/pr42898.c  -O1  scan-tree-dump-times optimized "\*ptr" 1

From the initial mail:

> I'll install it everywhere once 4.3 finished (even though the testcase
> will fail on the trunk for now).

SRA is broken.

Ciao,
Michael.
Arnaud Charlet | 1 Feb 2010 08:23
Favicon

Re: [PATCH] PR ada/42254, avoid providing multiple copies of object files to link of GNAT tools

> Anyway, in the interests of at least being able to build the compiler, I've tested 
> on x86_64-apple-darwin10, i686-apple-darwin10, x86_64-unknown-linux-gnu 
> [Debian 5] and powerpc-wrs-vxworks hosted on i686-apple-darwin10.

You've broken this line:

-TEXI2PDF = texi2pdf
+EXI2PDF = texi2pdf

Also, you've duplicated the same comment in two places, which is not
desirable.

And you mention that the dummy setting of TOOLS_GNATLIBC and TOOLS_NOSTDLIB
is for darwin only. Would be better to document in a general way how/when
these variables should be set.

> 2010-01-31  Simon Wright  <simon <at> pushface.org>
> 	PR ada/42554
> 	* gcc-interface/Makefile.in (TOOLS_LIBS, GNATLINK_OBJS, 
> 	GNATMAKE_OBJS, common-tools, ../../gnatmake$(exeext), 
> 	../../gnatlink$(exeext), gnatmake-re, gnatlink-re): on 
> 	Darwin, ensure that the linker only sees each object file 
> 	once.

Arno

Alan Modra | 1 Feb 2010 12:44
Picon

Re: Fix PR 32344, cgraph rtl flags outdated

On Sat, Jan 30, 2010 at 01:17:06PM +0100, Jan Hubicka wrote:
> Please fix also the visibility pass in ipa.c.

This patch should do that too.  I noticed that some other backends
test SYMBOL_REF_WEAK and that make_decl_rtl does not update that
particular rtl flag and was unsure whether it should, so put all the
flag twiddling into a function.

Bootstrapped and regression tested powerpc-linux and i686-linux.

	PR middle-end/42344
	* cgraph.h (cgraph_make_decl_local): Declare.
	* cgraph.c (cgraph_make_decl_local): New function.
	(cgraph_make_node_local): Use it.
	* cgraphunit.c (cgraph_function_versioning): Likewise.
	* ipa.c (function_and_variable_visibility): Likewise.

Index: gcc/cgraph.c
===================================================================
--- gcc/cgraph.c	(revision 156365)
+++ gcc/cgraph.c	(working copy)
 <at>  <at>  -86,6 +86,7  <at>  <at>  The callgraph:
 #include "value-prof.h"
 #include "except.h"
 #include "diagnostic.h"
+#include "rtl.h"

 static void cgraph_node_remove_callers (struct cgraph_node *node);
 static inline void cgraph_edge_remove_caller (struct cgraph_edge *e);
 <at>  <at>  -2190,6 +2191,42  <at>  <at>  cgraph_node_can_be_local_p (struct cgrap
(Continue reading)

Simon Baldwin | 1 Feb 2010 13:41
Picon
Favicon

Re: Ping Ping Ping: [PATCH] RFA: Add a small indication to warnings that are promoted to errors

On 29 January 2010 19:20, Mark Mitchell <mark <at> codesourcery.com> wrote:
>
> Simon Baldwin wrote:
>
> >>> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01101.html
> >>> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01197.html
>
> I'm not convinced that there's a real problem here.  If you say -Werror,
> you're telling the compiler to treat warnings as errors, and the fact
> that it then presents warnings as errors doesn't seem like that bad of
> an idea to me.

I have not suggested that -Werror no longer present warnings as
errors.  The patch does not affect this any way.

The problem's one of usability.  It's most visible when you have a
build tool or environment that enforces (or strongly defaults)
-Werror.

For developers using such a system, there is no visible difference in
gcc diagnostics for code which has defined behaviour but which gcc
considers suspicious, and for code which has undefined behaviour.
Both appear as errors, yet when working to make them go away, a
developer would benefit from knowing that the second really needs
fixing, and that the first is work to appease the draconian build
system (so perhaps they can lobby for a less draconian one).

Gcc does note at the start of diagnostics that warnings are errors,
but if there are also genuine errors present then there's no way to
guarantee a visible distinction between these and the promoted
(Continue reading)

Rainer Orth | 1 Feb 2010 14:35
Picon
Picon
Favicon

Re: PATCH: Document assembler requirements for Solaris 10/SPARC (PR libgomp/29986)

Gerald Pfeifer <gerald <at> pfeifer.com> writes:

> On Fri, 29 Jan 2010, Rainer Orth wrote:
>> Ok for mainline?  (I know I could commit it by myself, but especially
>> for doc patches, I prefer another set of eyes.)
>
> Looks good.  Perhaps say "There is" instead of "There's".

Good point: fixed and installed.

	Rainer

--

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Richard Earnshaw | 1 Feb 2010 14:40
Favicon

Re: [PATCH: PR target/42671] Use Thumb1 GOT address loading sequence for Thumb2


On Wed, 2010-01-27 at 15:03 +0000, Richard Earnshaw wrote:
> I haven't had time to do anything but light testing of this and my
> test-environment is well configured for covering this either -- so if
> you could run the attached through your test environment and let me know
> of any problems I'd be grateful.
> 
> R.
> 
> 	* arm.c (FL_FOR_ARCH7A): Include v6k extensions.
> 	(arm_override_options): Allow use of the TLS register if thumb2.
> 	(legitimize_pic_address): Improve code sequences for thumb2.
> 	(arm_load_pic_register): Likewise.
> 	(arm_call_tls_get_addr): Likewise.
> 	(legitimize_tls_address): Likewise.
> 	* arm.md (pic_load_addr_32bit): New pattern, merged from thumb variant and ...
> 	(pic_load_addr_arm): ... this.  Delete.
> 	(pic_add_dot_plus_four): Allow any thumb.
> 	* thumb2.md (pic_load_addr_thumb2): Delete.
> 	(pic_load_dot_plus_four): Delete.
> 	(tls_load_dot_plus_four): New pattern.

Having done a native regression run on a Cortex-a9 board running linux,
I've now committed this code.

R.


Gmane