headers
Gabriel Dos Reis | 1 May 2006 01:22

Re: [C PATCH] New -Woverflow option, pass OPT_Woverflow to warning.

Roger Sayle <roger <at> eyesopen.com> writes:

| Hi Gaby,
| 
| Thanks for the review.
| 
| 
| On 1 May 2006, Gabriel Dos Reis wrote:
| > The patch is welcome in principle.  However, since we are supposed to
| > be in stage 3, my natural question is: does it fix a regression?  If
| > the answer is not, then please hold it for stage 1.
| 
| There are a number of TREE_OVERFLOW releated regressions, including
| some bad constant folding interactions in the Ada front-end, that
| Mark and I are hoping to fix for 4.2, by cleaning up TREE_OVERFLOW.
| It's because we're in stage3 that I'm trying to split this reorganization
| into a number of very safe incremental improvements.
| 
| See http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00889.html
| and http://gcc.gnu.org/ml/gcc/2006-04/msg00008.html where it
| was agreed this is reasonable for stage3 provided I'm careful.

Thanks for showing those evidence -- obviously, I'm way behind GCC mails.

| > Is -Woverflow supposed to be actived by default, or part of -Wall?
| 
| The intention is for there to be no change of behaviour with this
| patch.  Currently we generate warnings unconditionally, so this
| patch preserves this functionality, and enables Woverflow by default.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Mitchell | 1 May 2006 01:28

C++ PATCH: PR27904


This patch fixes PR c++/27904, which, as Jakub deduced, is a case
where we care collecting garbage with unmarked, but live, variables on
the stack.  Because we are not inside a function, we do not expect to
have such local variables -- but we are in a default-argument
expression, and in that context we do have to evaluate expressions.

Tested on x86_64-unknown-linux-gnu, applied on the mainline and on the
4.1 branch.

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

2006-04-30  Mark Mitchell  <mark <at> codesourcery.com>

	PR c++/27094
	* pt.c (tsubst_default_argument): Increment function_depth around
	call to tsubst_expr.
	* parser.c (cp_parser_parameter_declaration): Likewise.
	* decl2.c (mark_used): Tidy.

2006-04-30  Mark Mitchell  <mark <at> codesourcery.com>

	PR c++/27094
	* g++.dg/template/defarg8.C: New test.

Index: gcc/cp/pt.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 May 2006 03:08
Picon

[patch, libgfortran] Fix PR24459 Namelist problem

:ADDPATCH fortran:

Hi All!

This patch finalizes the fix for this PR.  Paul Thomas gave me a hint on this in 
  realizing the mechanism to process more data than needed was in place.  The 
patch simply leaves the loop spec index end value at their default and only 
updates the start and step values when parsing array qualifiers.

Its very simple, but took me a while to spot this!

This allows the original test case in the PR to pass as well as handling all 
original test cases.

The test case and namelist provided is to allow everyone to see the results 
easily.  I will turn this test case into a dg-run acceptable form before 
committing the patch.

Comments would be appreciated.  If anyone has some other test cases you can 
think of please try and see if it works correctly.

Regression tested and NIST tested on i686.

OK for trunk and then 4.1 branch in about a week?

Regards,

Jerry

2006-04-30  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Mitchell | 1 May 2006 04:18

C++ PATCH: PR 26534 for 4.1


I've applied this patch for 26534 to the 4.1 branch.  It's simpler and
safer than the mainline version -- but will result in inferior code
since the middle end is not informed as to the actual range of the
bitfield.

Tested on x86_64-unknown-linux-gnu, applied on the 4.1 branch.

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

2006-04-30  Mark Mitchell  <mark <at> codesourcery.com>

	PR c++/26534
	* cp-tree.h (adjust_bitfield_initializer): Declare.
	* typeck.c (build_modify_expr): Use it.
	* typeck2.c (adjust_bitfield_initializer): Define.
	(process_init_constructor_record): Use it.

2006-04-30  Mark Mitchell  <mark <at> codesourcery.com>

	PR c++/26534
	* g++.dg/opt/bitfield1.C: New test.

Index: gcc/cp/typeck.c
===================================================================
--- gcc/cp/typeck.c	(revision 113399)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roger Sayle | 1 May 2006 04:44
Favicon

[Fortran] Fix gfortran.df/module_equivalence_1.f90 on HPUX


The following patch addresses the failure of module_equivalence_1.f90
on PA/HPUX, but the underlying problem is present on all platforms,
though harmlessly latent on Linux (and others?).

The failure on PA/HPUX is caused by the assembler complaining about
duplicate .comm lines for the symbol test_equiv.eq.1.  This failure
may be reproduced on other platforms by compiling module_equivalence_1.f90
and noticing that the symbol test_equiv.eq.1 is indeed emitted multiple
times in the assembly language output.  On x86/Linux, we see

        .comm   my_common_,32,32
        .comm   test_equiv.eq.1_,16,16
        .comm   test_equiv.eq.1_,16,16
        .comm   test_equiv.eq.1_,16,16

Presumably gas on HPUX is stricter than gas on Linux.

After some investigation and much head scratching it appeared that the
reason was that trans-common.c:build_common_decl was creating multiple
DECLs for the same symbol.  This was baffling because the logic in
that function uses a global "gfc_common_ns" namespace to keep track
of it's common block symbols, which looks like it should be resusing
a single gfc_symbol, and thereby avoiding any possibility of duplicates.

Eventually, I discovered that the gfortran front-end uses a commit or
rollback mechanism for symbol creation, and that recently created
gfc_symbols may be destroyed/revoked if they aren't explicitly committed.
This then pointed to the logic error, corrected below, where in the
function gfc_trans_common, it calls gfc_commit_symbols before calling
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Pinski | 1 May 2006 05:33
Picon

Re: [Fortran] Fix gfortran.df/module_equivalence_1.f90 on HPUX


On Apr 30, 2006, at 7:44 PM, Roger Sayle wrote:

>
> The following patch addresses the failure of module_equivalence_1.f90
> on PA/HPUX, but the underlying problem is present on all platforms,
> though harmlessly latent on Linux (and others?).

This was considered a bug in gas.
See http://gcc.gnu.org/bugzilla//show_bug.cgi?id=25172
And
http://sourceware.org/ml/binutils/2005-12/msg00030.html
And
http://sourceware.org/bugzilla//show_bug.cgi?id=1948

-- Pinski
Permalink | Reply | 0 comments |
headers
Roger Sayle | 1 May 2006 05:26
Favicon

Re: Fix gfortran.df/module_equivalence_1.f90 on HPUX


On Sun, 30 Apr 2006, Andrew Pinski wrote:
> On Apr 30, 2006, at 7:44 PM, Roger Sayle wrote:
> > The following patch addresses the failure of module_equivalence_1.f90
> > on PA/HPUX, but the underlying problem is present on all platforms,
> > though harmlessly latent on Linux (and others?).
>
> This was considered a bug in gas.
> See http://gcc.gnu.org/bugzilla//show_bug.cgi?id=25172

Many thanks to Andrew for pointing out that my patch is a more
appropriate fix to PR fortran/25172.  Stopping "gas" complaining
about duplicate symbols just papers over the logic flaw in
gfc_trans_common that we shouldn't be creating multiple global
DECLs with the same name.

Of course, it'll be harder to spot this kind of problem in
future, now that gas has been fixed.  :-(  Perhaps gas should
have the equivalent of -pedantic to assist identifying potential
compiler problems?

Roger
--
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 May 2006 06:18

Re: better default SYSTEM_HEADER_DIR when cross-compiling gcc

On Sun, Apr 30, 2006 at 04:04:48AM -0400, Mike Frysinger wrote:
> the attached patch changes the default SYSTEM_HEADER_DIR setting from 
> NATIVE_SYSTEM_HEADER_DIR to CROSS_SYSTEM_HEADER_DIR when host != build

I have the feeling this will break --with-sysroot and
--with-build-sysroot configurations.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Roger Sayle | 1 May 2006 05:44
Favicon

[C PATCH] Make unsigned_conversion_warning static


As part of the TREE_OVERFLOW clean-up, I'll shortly be rewriting/deleting
c-common.c's unsigned_conversion_warning.  To limit the impact of that
change, this patch removes the one use of unsigned_conversion_warning
outside of c-common.c, and allows it to be made a local "static" function.

The single external use is in parser_build_binary_op, where in 1993
RMS added two calls to check that the operands of a binary function
didn't overflow when converted to the result_type of a binary operator.
I'm not sure this could ever happen with C's promotion/common_type
rules.  However, a better way to achieve this same checking is to
instead use convert_and_check, rather than just convert, in the
function build_binary_op.  Conceptually, any overflow/truncation occurs
when the operands are converted to the type of the binary operator.
It makes sense to check for overflow then, using the API for that
purpose, rather than check for a subset (unsigned truncation) after
the fact.

The following patch has been tested on i686-pc-linux-gnu with a full
"make bootstrap", all default languages, and regression tested with a
top-level "make -k check" with no new failures.

Ok for mainline, as part of the continuing TREE_OVERFLOW reorg?

2006-04-30  Roger Sayle  <roger <at> eyesopen.com>

	* c-typeck.c (parser_build_binary_op): Don't call the function
	unsigned_conversion_warning to spot operand/result type overflow.
	(build_binary_op): Instead, call convert_and_check instead of
	convert to report the problem when the operands are promoted.
(Continue reading)

Permalink | Reply | 2 comments |
headers
tobias.schlueter | 1 May 2006 11:34
Picon
Favicon

Re: [Fortran] Fix gfortran.df/module_equivalence_1.f90 on HPUX

Quoting Roger Sayle <roger <at> eyesopen.com>:
> The following patch addresses the failure of module_equivalence_1.f90
> on PA/HPUX, but the underlying problem is present on all platforms,
> though harmlessly latent on Linux (and others?).

Not completely harmless, see Paul Thomas' patch and description in  
<http://gcc.gnu.org/ml/fortran/2006-04/msg00340.html> :-)

Thanks,
- Tobi

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Permalink | Reply | 0 comments |

Gmane