Re: [wwwdocs] fortran/index.html - remove local styles
Dear Gerald, The style changes are fine. OK to commit. Thanks Paul On 30 January 2016 at 05:04, Gerald Pfeifer wrote: > These local styles feel a bit odd to begin with, and if we skip > the ... within ..., the originally perceived/ > addresses issue should go away. > > Unless there are objections from the Fortran side, I plan on > committing this in a couple of days. > > Gerald > > Index: fortran/index.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/fortran/index.html,v > retrieving revision 1.34 > diff -u -r1.34 index.html > --- fortran/index.html 29 Jun 2014 11:31:33 - 1.34 > +++ fortran/index.html 30 Jan 2016 04:02:12 - > @@ -91,52 +91,51 @@ > people: > > > -Paul Brook > -Steven Bosscher > -Bud Davis > -Jerry DeLisle > -Toon Moene > -Tobias Schlueter > -Janne Blomqvist > -Steve Kargl > -Thomas Koenig > -Paul Thomas > -Janus Weil > -Daniel Kraft > -Daniel Franke > +Paul Brook > +Steven Bosscher > +Bud Davis > +Jerry DeLisle > +Toon Moene > +Tobias Schlueter > +Janne Blomqvist > +Steve Kargl > +Thomas Koenig > +Paul Thomas > +Janus Weil > +Daniel Kraft > +Daniel Franke > > > Under the rules specified below: > > > -All normal > +All normal > requirements for patch submission (assignment of copyright to > the FSF, testing, ChangeLog entries, etc) still apply, and > reviewers should ensure that these have been met before approving > -changes. > -Approval should be necessary for > +changes. > +Approval should be necessary for > patches which don't fall under the obvious rule. So, with the approver list > put in place, everybody (except maintainers) should still seek approval for > his/her patches. We have found the mutual peer review process really > -works well. > -Patches should only be reviewed by > +works well. > +Patches should only be reviewed by > people who know the affected parts of the compiler. (i.e. the > reviewer has to be sure he/she knows stuff well enough to make a > -good judgment.) > -Large/complicated patches should > -still go by one of our maintainers, or team consensus. > -We are all reasonable people, and nobody is working under > +good judgment.) > +Large/complicated patches should > +still go by one of our maintainers, or team consensus. > +We are all reasonable people, and nobody is working under > employer pressure or needs an ego-boost badly, so in general we > -assume that no-one deliberately does anything stupid :-) > +assume that no-one deliberately does anything stupid :-) > > > The directories involved are: > > -gcc/gcc/fortran/ > -gcc/gcc/testsuite/gfortran.dg/ > -gcc/gcc/testsuite/gfortran.fortran-torture/ > - > -gcc/libgfortran/ > +gcc/gcc/fortran/ > +gcc/gcc/testsuite/gfortran.dg/ > +gcc/gcc/testsuite/gfortran.fortran-torture/ > +gcc/libgfortran/ > > > Documentation -- The difference between genius and stupidity is; genius has its limits. Albert Einstein
Re: [PATCH] Fix up _Pragma GCC diagnostics regressions (PR preprocessor/69543, PR c/69558)
On Sat, Jan 30, 2016 at 06:57:48AM +0100, David Malcolm wrote: > On Fri, 2016-01-29 at 20:50 +0100, Jakub Jelinek wrote: > > Hi! > > > > This patch reverts one tiny change from r228049 changes (which hasn't > > been > > mentioned in the ChangeLog or patch description). We definitely need > > to > > revisit this for GCC 7, but stage4 is probably not the right time for > > that, > > and the patch fixes e.g. tons of warnings (or with -Werror errors on > > including pretty much all glib2 headers). > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > 2016-01-29 Jakub Jelinek > > > > PR preprocessor/69543 > > PR c/69558 > > * c-pragma.c (handle_pragma_diagnostic): Pass input_location > > instead of loc to control_warning_option. > > > > * gcc.dg/pr69543.c: New test. > > * gcc.dg/pr69558.c: New test. > > This touches c-family; shouldn't the new tests be in c-c++-common, > rather than gcc.dg? (presumably we need to ensure that the glib2 > headers are sane from C++ also) Ideally yes. But they don't really work. pr69558.c in C++ (i.e. glib2) doesn't look to be a regression, at least those pragmas are supported in 4.6+ (and used in glib2 only for 4.6+) and 4.6 (don't have 4.7 around), 4.8, 4.9 and 5.3 all print two! warnings about deprecated foo, and so does trunk g++, unpatched and patched. So we actually have two bugs there, one is that we emit two warnings instead of one (one is from mark_used called from somewhere, another build_over_call), and another that we don't suppress the warning in C++, but neither of them is a regression. pr69543.c also fails in C++, and that is a regression. > I've been attempting to fix these by fixing linemap_compare_locations, > but I don't have that approach working, so fwiw I don't object to this > patch. Jakub
Re: [RS6000] ABI_V4 init of toc section
On Fri, Jan 29, 2016 at 01:20:08PM -0500, David Edelsohn wrote: > On Fri, Jan 29, 2016 at 11:38 AM, Alan Modra wrote: > > PR target/68662 > > * config/rs6000/rs6000.c (need_toc_init): New var, set it > > whenever toc_label_name used. > > (rs6000_file_start): Don't set up toc section here, > > (rs6000_output_function_epilogue): do so here instead, > > (rs6000_xcoff_file_start): and here. > > * config/rs6000/rs6000.md (load_toc_aix_si): Set need_toc_init. > > (load_toc_aix_di): Likewise. > > I'm worried about how this is going to interact with AIX. AIX > assembler is single pass and this patch moves the initialization from > the beginning of the file to the end of the file, which means there > will be references to a label whose definition is delayed until the > end. AIX toc init is still done at the start of the file. The code to emit .toc or set .LCTOC..1 has moved from rs6000_file_start to rs6000_xcoff_file_start. -- Alan Modra Australia Development Lab, IBM
Re: [Patch, MIPS] Fix PR target/68273, passing args in wrong regs
I'm not sure this patch is safe. The received wisdom used to be that
ABIs should be defined in terms of types, not modes, since types
represent the source code while modes are an internal GCC concept
that could change over time (although in practice the barrier for
that is pretty high).
The patch that introduced the line being patched was part of a series
that fixed ABI incompatibilities with MIPSpro, and IIRC some of the
incompatibilties really were due to us looking at modes when we should
have been looking at types.
So...
"Steve Ellcey " writes:
> This is a patch for PR 68273, where MIPS is passing arguments in the wrong
> registers. The problem is that when passing an argument by value,
> mips_function_arg_boundary was looking at the type of the argument (and
> not just the mode), and if that argument was a variable with extra alignment
> info (say an integer variable with 8 byte alignment), MIPS was aligning the
> argument on an 8 byte boundary instead of a 4 byte boundary the way it should.
>
> Since we are passing values (not variables), the alignment of the variable
> that the value is copied from should not affect the alignment of the value
> being passed.
...to me this suggests we might have a middle-end bug. The argument
seems to be that the alignment of the type being passed in cannot
reasonably be used to determine the ABI for semantic reasons
(rvalues don't have meaningful alignment). Doesn't that mean that
we're passing the wrong type to the hook? The point of the hook
is to say how an ABI handles a particular type, so if we have a type
variant that the ABI can't reasonably handle directly for language
reasons, shouldn't we be passing the main variant instead?
> This patch fixes the problem and it could change what registers arguments
> are passed in, which means it could affect backwards compatibility with
> older programs. But since the current behaviour is not compliant with the
> MIPS ABI and does not match what LLVM does, I think we have to make this
> change. For the most part this will only affect arguments which are copied
> from variables that have non-standard alignments set by the aligned attribute,
> however the SRA optimization pass can create aligned variables as it splits
> aggregates apart and that was what triggered this bug report.
>
> This is basically the same bug as the ARM bug PR 65956 and the fix is
> pretty much the same too.
>
> Rather than create MIPS specific tests that check the use of specific
> registers I created two tests to put in gcc.c-torture/execute that
> were failing before because GCC on MIPS was not consistent in where
> arguments were passed and which now work with this patch.
>
> Tested with mips-mti-linux-gnu and no regressions. OK to checkin?
Given the argument about LLVM, I think it would also be worth running
the compat testsuite with clang as the alt compiler both before and
after the patch to see whether we regress.
> 2016-01-29 Steve Ellcey
>
> PR target/68273
> * config/mips/mips.c (mips_function_arg_boundary): Fix argument
> alignment.
>
>
>
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index dd54d6a..ecce3cd 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -5643,8 +5643,9 @@ static unsigned int
> mips_function_arg_boundary (machine_mode mode, const_tree type)
> {
>unsigned int alignment;
> -
> - alignment = type ? TYPE_ALIGN (type) : GET_MODE_ALIGNMENT (mode);
> + alignment = type && mode == BLKmode
> + ? TYPE_ALIGN (TYPE_MAIN_VARIANT (type))
> + : GET_MODE_ALIGNMENT (mode);
>if (alignment < PARM_BOUNDARY)
> alignment = PARM_BOUNDARY;
>if (alignment > STACK_BOUNDARY)
We need to be careful of examples like:
struct __attribute__ ((aligned (8))) s { _Complex float x; };
void foo (struct s *ptr, struct s val) { *ptr = val; }
"x" gets SCmode, which has an alignment of 4. And it's OK for TYPE_MODE
to have a smaller alignment than the type -- it's just not allowed to
have a larger alignment (and even that restriction only applies because
this is a STRICT_ALIGNMENT target). So the structure itself inherits
this SCmode.
The patch therefore changes how we handle foo() for -mabi=32 -msoft-float.
Before the patch "val" is passed in $6 and $7. After the patch it's
passed in $5 and $6. clang behaves like the unpatched GCC.
If instead we use:
struct __attribute__ ((aligned (8))) s { float x; float y; };
void foo (struct s *ptr, struct s val) { *ptr = val; }
then the structure has BLKmode and the alignment is honoured both before
and after the patch.
There's no real ABI reason for handling the two cases differently.
The fact that one gets BLKmode and the other doesn't is down
to GCC internals.
We also have to be careful about the STRICT_ALIGNMENT thing.
At the moment that's hard-coded to 1 for MIPS, but it's possible that
it could become configurable in future, like it is for aarch64 and
rs6000. !STRICT_ALIGNMENT a
Re: [PATCH] Fix wide_int unsigned division (PR tree-optimization/69546)
Jakub Jelinek writes:
> As the testcase shows, wide_int unsigned division is broken for > 64bit
> precision division of unsigned dividend which have 63rd bit set, and all
> higher bits cleared (thus is normalized as 2 HWIs, first with MSB set,
> the second 0) and divisor of 1, we return just a single HWI, which is
> equivalent to all higher bits set too. If the divisor is > 1, there is
> no such problem, as the MSB will not be set after the division.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-01-29 Jakub Jelinek
>
> PR tree-optimization/69546
> * wide-int.cc (wi::divmod_internal): For unsigned division
> where both operands fit into uhwi, if o1 is 1 and o0 has
> msb set, if divident_prec is larger than bits per hwi,
> clear another quotient word and return 2 instead of 1.
>
> * gcc.dg/torture/pr69546.c: New test.
>
> --- gcc/wide-int.cc.jj2016-01-26 11:46:39.0 +0100
> +++ gcc/wide-int.cc 2016-01-29 11:59:33.348852003 +0100
> @@ -1788,15 +1788,25 @@ wi::divmod_internal (HOST_WIDE_INT *quot
> {
>unsigned HOST_WIDE_INT o0 = dividend.to_uhwi ();
>unsigned HOST_WIDE_INT o1 = divisor.to_uhwi ();
> + unsigned int quotient_len = 1;
>
>if (quotient)
> - quotient[0] = o0 / o1;
> + {
> + quotient[0] = o0 / o1;
> + if (o1 == 1
> + && (HOST_WIDE_INT) o0 < 0
> + && dividend_prec > HOST_BITS_PER_WIDE_INT)
> + {
> + quotient[1] = 0;
> + quotient_len = 2;
> + }
> + }
>if (remainder)
> {
> remainder[0] = o0 % o1;
> *remainder_len = 1;
> }
> - return 1;
> + return quotient_len;
> }
Might be wrong, but couldn't the same thing happen for the remainder,
e.g. for 0xfffe % 0x ? Maybe we should have a helper
function to handle storing uhwis in an array and returning the length.
Certainly seems like this function has had its fair share of bugs.
Thanks for fixing another.
Richard
[PATCH] Fix wide_int unsigned division (PR tree-optimization/69546, take 2)
On Sat, Jan 30, 2016 at 12:31:05PM +, Richard Sandiford wrote:
> Might be wrong, but couldn't the same thing happen for the remainder,
> e.g. for 0xfffe % 0x ?
You're right, that is broken too. Adjusted patch below.
> Maybe we should have a helper
> function to handle storing uhwis in an array and returning the length.
Any suggestion how to call it, whether to put it in wi namespace, somewhere
else etc.? Can that be done as a follow-up? Certainly it would need
to take the uhwi to store, pointer to the array of hwis, and precision.
2016-01-30 Jakub Jelinek
PR tree-optimization/69546
* wide-int.cc (wi::divmod_internal): For unsigned division
where both operands fit into uhwi, if o1 is 1 and o0 has
msb set, if divident_prec is larger than bits per hwi,
clear another quotient word and return 2 instead of 1.
Similarly for remainder with msb in HWI set, if dividend_prec
is larger than bits per hwi.
* gcc.dg/torture/pr69546.c: New test.
--- gcc/wide-int.cc.jj 2016-01-29 12:12:43.486930641 +0100
+++ gcc/wide-int.cc 2016-01-30 14:08:18.293537813 +0100
@@ -1788,15 +1788,32 @@ wi::divmod_internal (HOST_WIDE_INT *quot
{
unsigned HOST_WIDE_INT o0 = dividend.to_uhwi ();
unsigned HOST_WIDE_INT o1 = divisor.to_uhwi ();
+ unsigned int quotient_len = 1;
if (quotient)
- quotient[0] = o0 / o1;
+ {
+ quotient[0] = o0 / o1;
+ if (o1 == 1
+ && (HOST_WIDE_INT) o0 < 0
+ && dividend_prec > HOST_BITS_PER_WIDE_INT)
+ {
+ quotient[1] = 0;
+ quotient_len = 2;
+ }
+ }
if (remainder)
{
remainder[0] = o0 % o1;
- *remainder_len = 1;
+ if ((HOST_WIDE_INT) remainder[0] < 0
+ && dividend_prec > HOST_BITS_PER_WIDE_INT)
+ {
+ remainder[1] = 0;
+ *remainder_len = 2;
+ }
+ else
+ *remainder_len = 1;
}
- return 1;
+ return quotient_len;
}
/* Make the divisor and dividend positive and remember what we
--- gcc/testsuite/gcc.dg/torture/pr69546-1.c.jj 2016-01-30 13:58:25.925056607
+0100
+++ gcc/testsuite/gcc.dg/torture/pr69546-1.c2016-01-30 13:58:25.925056607
+0100
@@ -0,0 +1,26 @@
+/* PR tree-optimization/69546 */
+/* { dg-do run { target int128 } } */
+
+unsigned __int128 __attribute__ ((noinline, noclone))
+foo (unsigned long long x)
+{
+ unsigned __int128 y = ~0ULL;
+ x >>= 63;
+ return y / (x | 1);
+}
+
+unsigned __int128 __attribute__ ((noinline, noclone))
+bar (unsigned long long x)
+{
+ unsigned __int128 y = ~33ULL;
+ x >>= 63;
+ return y / (x | 1);
+}
+
+int
+main ()
+{
+ if (foo (1) != ~0ULL || bar (17) != ~33ULL)
+__builtin_abort ();
+ return 0;
+}
--- gcc/testsuite/gcc.dg/torture/pr69546-2.c.jj 2016-01-30 14:09:40.403364637
+0100
+++ gcc/testsuite/gcc.dg/torture/pr69546-2.c2016-01-30 14:10:15.591861868
+0100
@@ -0,0 +1,18 @@
+/* PR tree-optimization/69546 */
+/* { dg-do run { target int128 } } */
+
+unsigned __int128
+foo (void)
+{
+ unsigned __int128 a = 0xfffeULL;
+ unsigned __int128 b = 0xULL;
+ return a % b;
+}
+
+int
+main ()
+{
+ if (foo () != 0xfffeULL)
+__builtin_abort ();
+ return 0;
+}
Jakub
[PATCH] Fix Bug 17896: The expression (a>0 & b>0) should give clearer warning message (-Wparentheses)
Hi! This is my first proposed patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896. I was willing to do it using "APPEARS_TO_BE_BOOLEAN_EXPR_P(CODE, ARG)" to check booleans but gcc doesn't allow (bootstraping fails). Hence I am using "TREE_CODE_CLASS (CODE) == tcc_comparison" -- Thanks and Regards, Prasad Ghangal Index: gcc/c-family/c-common.c === --- gcc/c-family/c-common.c (revision 232768) +++ gcc/c-family/c-common.c (working copy) @@ -11596,6 +11596,11 @@ || code_right == PLUS_EXPR || code_right == MINUS_EXPR) warning_at (EXPR_LOC_OR_LOC (arg_right, loc), OPT_Wparentheses, "suggest parentheses around arithmetic in operand of %<|%>"); + /* Check cases like (x instead of %<|%> when joining booleans"); /* Check cases like x|y==z */ else if (TREE_CODE_CLASS (code_left) == tcc_comparison) warning_at (EXPR_LOC_OR_LOC (arg_left, loc), OPT_Wparentheses, @@ -11642,6 +11647,11 @@ else if (code_right == MINUS_EXPR) warning_at (EXPR_LOC_OR_LOC (arg_right, loc), OPT_Wparentheses, "suggest parentheses around %<-%> in operand of %<&%>"); + /* Check cases like (x instead of %<&%> when joining booleans"); /* Check cases like x&y==z */ else if (TREE_CODE_CLASS (code_left) == tcc_comparison) warning_at (EXPR_LOC_OR_LOC (arg_left, loc), OPT_Wparentheses,
Re: [Patch, MIPS] Patch for PR 68400, a mips16 bug
"Steve Ellcey " writes:
> Here is a patch for PR6400. The problem is that and_operands_ok was checking
> one operand to see if it was a memory_operand but MIPS16 addressing is more
> restrictive than what the general memory_operand allows. The fix was to
> call mips_classify_address if TARGET_MIPS16 is set because it will do a
> more complete mips16 addressing check and reject operands that do not meet
> the more restrictive requirements.
>
> I ran the GCC testsuite with no regressions and have included a test case as
> part of this patch.
>
> OK to checkin?
>
> Steve Ellcey
> sell...@imgtec.com
>
>
> 2016-01-26 Steve Ellcey
>
> PR target/68400
> * config/mips/mips.c (and_operands_ok): Add MIPS16 check.
>
>
>
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index dd54d6a..adeafa3 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -8006,9 +8006,18 @@ mask_low_and_shift_p (machine_mode mode, rtx mask, rtx
> shift, int maxlen)
> bool
> and_operands_ok (machine_mode mode, rtx op1, rtx op2)
> {
> - return (memory_operand (op1, mode)
> - ? and_load_operand (op2, mode)
> - : and_reg_operand (op2, mode));
> +
> + if (memory_operand (op1, mode))
> +{
> + if (TARGET_MIPS16) {
> + struct mips_address_info addr;
> + if (!mips_classify_address (&addr, op1, mode, false))
> + return false;
> + }
Nit: brace formatting.
It looks like the patch only works by accident. The code above
is passing the MEM, rather than the address inside the MEM, to
mips_classify_address. Since (mem (mem ...)) is never valid on MIPS,
the effect is to disable the memory alternatives of *and3_mips16
unconditionally.
The addresses that occur in the testcase are valid as far as
mips_classify_address is concerned. FWIW, there shouldn't be any
difference between the addresses that memory_operand accepts and the
addresses that mips_classify_address accepts.
In theory, the "W" constraints in *and3_mips16 are supposed to
tell the target-independent code that this instruction cannot handle
constant addresses or stack-based addresses. That seems to be working
correctly during RA for the testcase. The problem comes in regcprop,
which ends up creating a second stack pointer rtx distinct from
stack_pointer_rtx:
(reg/f:SI 29 $sp [375])
(Note the ORIGINAL_REGNO of 375.) This then defeats the test in
mips_stack_address_p:
bool
mips_stack_address_p (rtx x, machine_mode mode)
{
struct mips_address_info addr;
return (mips_classify_address (&addr, x, mode, false)
&& addr.type == ADDRESS_REG
&& addr.reg == stack_pointer_rtx);
}
Change the == to rtx_equal_p and the test passes. I don't think that's
the correct fix though -- the fix is to stop a second stack pointer rtx
from being created.
Thanks,
Richard
Re: [PATCH] Fix wide_int unsigned division (PR tree-optimization/69546, take 2)
Jakub Jelinek writes:
> On Sat, Jan 30, 2016 at 12:31:05PM +, Richard Sandiford wrote:
>> Might be wrong, but couldn't the same thing happen for the remainder,
>> e.g. for 0xfffe % 0x ?
>
> You're right, that is broken too. Adjusted patch below.
>
>> Maybe we should have a helper
>> function to handle storing uhwis in an array and returning the length.
>
> Any suggestion how to call it, whether to put it in wi namespace, somewhere
> else etc.?
I think it should be local to wide-int.cc rather than in wi::. Users of
the public interface should always be using wi::uhwi (...). We only get
into this mess because we're trying to operate on the arrays directly,
rather than using the abstractions in the public interface.
Not sure what to call it. Maybe canonize_uhwi? Like canonize, except
that it takes a uhwi instead of a length.
> Can that be done as a follow-up? Certainly it would need
> to take the uhwi to store, pointer to the array of hwis, and precision.
Yeah, guess it can wait.
> 2016-01-30 Jakub Jelinek
>
> PR tree-optimization/69546
> * wide-int.cc (wi::divmod_internal): For unsigned division
> where both operands fit into uhwi, if o1 is 1 and o0 has
> msb set, if divident_prec is larger than bits per hwi,
> clear another quotient word and return 2 instead of 1.
> Similarly for remainder with msb in HWI set, if dividend_prec
> is larger than bits per hwi.
>
> * gcc.dg/torture/pr69546.c: New test.
>
> --- gcc/wide-int.cc.jj2016-01-29 12:12:43.486930641 +0100
> +++ gcc/wide-int.cc 2016-01-30 14:08:18.293537813 +0100
> @@ -1788,15 +1788,32 @@ wi::divmod_internal (HOST_WIDE_INT *quot
> {
>unsigned HOST_WIDE_INT o0 = dividend.to_uhwi ();
>unsigned HOST_WIDE_INT o1 = divisor.to_uhwi ();
> + unsigned int quotient_len = 1;
>
>if (quotient)
> - quotient[0] = o0 / o1;
> + {
> + quotient[0] = o0 / o1;
> + if (o1 == 1
> + && (HOST_WIDE_INT) o0 < 0
> + && dividend_prec > HOST_BITS_PER_WIDE_INT)
> + {
> + quotient[1] = 0;
> + quotient_len = 2;
> + }
> + }
>if (remainder)
> {
> remainder[0] = o0 % o1;
> - *remainder_len = 1;
> + if ((HOST_WIDE_INT) remainder[0] < 0
> + && dividend_prec > HOST_BITS_PER_WIDE_INT)
> + {
> + remainder[1] = 0;
> + *remainder_len = 2;
> + }
> + else
> + *remainder_len = 1;
> }
> - return 1;
> + return quotient_len;
> }
LGTM, thanks.
Richard
[Committed] New test for PR 66707 - Endless compilation on wrong usage of common
AFAICT PR 66707 has been fixed/ prevented/hidden by revision r226732. I have
committed the following as obvious
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 233007)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2016-01-30 Dominique d'Humieres
+
+ PR fortran/66707
+ gfortran.dg/common_23.f90: New test.
+
2016-01-29 Bill Schmidt
PR target/65546
Index: gcc/testsuite/gfortran.dg/common_23.f90
===
--- gcc/testsuite/gfortran.dg/common_23.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/common_23.f90 (working copy)
@@ -0,0 +1,10 @@
+! { dg-do compile }
+!
+! PR fortran/66707
+! Check the compilation on wrong usage of common
+! Contributed by Gerhard Steinmetz
+program p
+ integer, pointer :: a
+ common a, a ! { dg-error "is already in a COMMON block" }
+ common a
+end
I have tested (on x86_64-apple-darwin15) that revision r226732 can be trivially
back ported to the gcc5 branch. Is it OK to do this back port?
TIA
Dominique
Re: [Committed] New test for PR 66707 - Endless compilation on wrong usage of common
Hi Dominique,
Thanks for doing this. Yes, it's OK for 5-branch as well.
Cheers
Paul
On 30 January 2016 at 15:16, Dominique d'Humières wrote:
> AFAICT PR 66707 has been fixed/ prevented/hidden by revision r226732. I have
> committed the following as obvious
>
> Index: gcc/testsuite/ChangeLog
> ===
> --- gcc/testsuite/ChangeLog (revision 233007)
> +++ gcc/testsuite/ChangeLog (working copy)
> @@ -1,3 +1,8 @@
> +2016-01-30 Dominique d'Humieres
> +
> + PR fortran/66707
> + gfortran.dg/common_23.f90: New test.
> +
> 2016-01-29 Bill Schmidt
>
> PR target/65546
> Index: gcc/testsuite/gfortran.dg/common_23.f90
> ===
> --- gcc/testsuite/gfortran.dg/common_23.f90 (nonexistent)
> +++ gcc/testsuite/gfortran.dg/common_23.f90 (working copy)
> @@ -0,0 +1,10 @@
> +! { dg-do compile }
> +!
> +! PR fortran/66707
> +! Check the compilation on wrong usage of common
> +! Contributed by Gerhard Steinmetz
> +program p
> + integer, pointer :: a
> + common a, a ! { dg-error "is already in a COMMON block" }
> + common a
> +end
>
> I have tested (on x86_64-apple-darwin15) that revision r226732 can be
> trivially back ported to the gcc5 branch. Is it OK to do this back port?
>
> TIA
>
> Dominique
>
--
The difference between genius and stupidity is; genius has its limits.
Albert Einstein
RE: [Patch, MIPS] Patch for PR 68400, a mips16 bug
Richard Sandiford writes:
> "Steve Ellcey " writes:
> > Here is a patch for PR6400. The problem is that and_operands_ok was
> > checking
> > one operand to see if it was a memory_operand but MIPS16 addressing is more
> > restrictive than what the general memory_operand allows. The fix was to
> > call mips_classify_address if TARGET_MIPS16 is set because it will do a
> > more complete mips16 addressing check and reject operands that do not meet
> > the more restrictive requirements.
> >
> > I ran the GCC testsuite with no regressions and have included a test case as
> > part of this patch.
> >
> > OK to checkin?
> >
> > Steve Ellcey
> > sell...@imgtec.com
> >
> >
> > 2016-01-26 Steve Ellcey
> >
> > PR target/68400
> > * config/mips/mips.c (and_operands_ok): Add MIPS16 check.
> >
> >
> >
> > diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> > index dd54d6a..adeafa3 100644
> > --- a/gcc/config/mips/mips.c
> > +++ b/gcc/config/mips/mips.c
> > @@ -8006,9 +8006,18 @@ mask_low_and_shift_p (machine_mode mode, rtx mask,
> > rtx shift, int
> maxlen)
> > bool
> > and_operands_ok (machine_mode mode, rtx op1, rtx op2)
> > {
> > - return (memory_operand (op1, mode)
> > - ? and_load_operand (op2, mode)
> > - : and_reg_operand (op2, mode));
> > +
> > + if (memory_operand (op1, mode))
> > +{
> > + if (TARGET_MIPS16) {
> > + struct mips_address_info addr;
> > + if (!mips_classify_address (&addr, op1, mode, false))
> > + return false;
> > + }
>
> Nit: brace formatting.
>
> It looks like the patch only works by accident. The code above
> is passing the MEM, rather than the address inside the MEM, to
> mips_classify_address. Since (mem (mem ...)) is never valid on MIPS,
> the effect is to disable the memory alternatives of *and3_mips16
> unconditionally.
>
> The addresses that occur in the testcase are valid as far as
> mips_classify_address is concerned. FWIW, there shouldn't be any
> difference between the addresses that memory_operand accepts and the
> addresses that mips_classify_address accepts.
>
> In theory, the "W" constraints in *and3_mips16 are supposed to
> tell the target-independent code that this instruction cannot handle
> constant addresses or stack-based addresses. That seems to be working
> correctly during RA for the testcase. The problem comes in regcprop,
> which ends up creating a second stack pointer rtx distinct from
> stack_pointer_rtx:
>
> (reg/f:SI 29 $sp [375])
>
> (Note the ORIGINAL_REGNO of 375.) This then defeats the test in
> mips_stack_address_p:
>
> bool
> mips_stack_address_p (rtx x, machine_mode mode)
> {
> struct mips_address_info addr;
>
> return (mips_classify_address (&addr, x, mode, false)
> && addr.type == ADDRESS_REG
> && addr.reg == stack_pointer_rtx);
> }
>
> Change the == to rtx_equal_p and the test passes. I don't think that's
> the correct fix though -- the fix is to stop a second stack pointer rtx
> from being created.
Agreed, though I'm inclined to say do both. We actually hit this
same issue while testing some 4.9.2 based tools recently but I hadn't
got confirmation from Andrew (cc'd) whether it was definitely the same
issue. Andrew fixed this by updating all tests against stack_pointer_rtx
to compare register numbers instead (but rtx_equal_p is better still).
I think it is worthwhile looking in more detail why a new stack pointer
rtx appears. Andrew did look briefly at the time but I don't recall his
conclusions...
Matthew
Re: [Committed] New test for PR 66707 - Endless compilation on wrong usage of common
Done as r233009 Thanks for the review, Dominique > Le 30 janv. 2016 à 16:45, Paul Richard Thomas > a écrit : > > Hi Dominique, > > Thanks for doing this. Yes, it's OK for 5-branch as well. > > Cheers > > Paul
[PATCH] c/69540 - update documentation on -l
* doc/invoke.texi: update documentation WRT .so libraries in -l
---
gcc/ChangeLog | 4
gcc/doc/invoke.texi | 8 +---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1d60690..0a6acdb 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2016-01-30 Arkadiusz Drabczyk
+
+ * doc/invoke.texi: update documentation WRT .so libraries in -l
+
2016-01-29 Martin Jambor
* hsa-gen.c (get_memory_order_name): Mask with MEMMODEL_BASE_MASK.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ba0b4b2..8b1b329 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10440,9 +10440,11 @@ whose members are object files. The linker handles an
archive file by
scanning through it for members which define symbols that have so far
been referenced but not defined. But if the file that is found is an
ordinary object file, it is linked in the usual fashion. The only
-difference between using an @option{-l} option and specifying a file name
-is that @option{-l} surrounds @var{library} with @samp{lib} and @samp{.a}
-and searches several directories.
+difference between using an @option{-l} option and specifying a file
+name is that @option{-l} surrounds @var{library} with @samp{lib} and
+@samp{.so} on systems with shared libraries support or with @samp{.a} if
+@var{library} with @samp{.so} is not found and on all other systems and
+searches several directories.
@item -lobjc
@opindex lobjc
--
1.8.4
--
Arkadiusz Drabczyk
[Patch, fortran] PR69566 - [6 Regression] ICE with unlimited polymorphic array pointer function
2016-01-27 Paul Thomas PR fortran/69385 * trans-expr.c (is_scalar_reallocatable_lhs): Remove the check for allocatable components, whilst checking if the symbol is a derived or class entity.. 2015-01-27 Paul Thomas PR fortran/69385 * gfortran.dg/alloc_comp_assign_15.f03: New test. Committed as obvious in revision 233011. Unfortunately, the fix uncovers another bug and so I will leave the PR open and change the title accordingly. Cheers Paul
Contents of PO file 'cpplib-5.2.0.fi.po'
cpplib-5.2.0.fi.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
New Finnish PO file for 'cpplib' (version 5.2.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Finnish team of translators. The file is available at: http://translationproject.org/latest/cpplib/fi.po (This file, 'cpplib-5.2.0.fi.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[PATCH] fix #69573 - FAIL: gcc.dg/pr61053.c
While doing some research into the aligned attribute I came across
c/61053 that had been reopened after the regression test added with
the fix had started to fail on a couple of targets. Since the bug
is fixed and the test failure is due to the added test I resolved
it as fixed and opened a new one for the test failure (to avoid
giving the impression there's still a problem with _Alignas).
The attached patch should fix these outstanding test failures on
the two targets (x86_64-apple-darwin15.3.0 and x86_64-w64-mingw32).
I don't have access to either but I verified it on x86_64 by
running the test with the following:
RUNTESTFLAGS='--target_board=unix/-m32/-m128bit-long-double
dg.exp=pr61053.c'
Martin
PR testsuite/69573 - FAIL: gcc.dg/pr61053.c (test for excess errors)
gcc/testsuite/ChangeLog:
2016-01-30 Martin Sebor
PR testsuite/69573
* gcc.dg/pr61053.c: Tweaked test to avoid bogus failures.
diff --git a/gcc/testsuite/gcc.dg/pr61053.c b/gcc/testsuite/gcc.dg/pr61053.c
index e270420..1c090e0 100644
--- a/gcc/testsuite/gcc.dg/pr61053.c
+++ b/gcc/testsuite/gcc.dg/pr61053.c
@@ -67,9 +67,19 @@ _Alignas (long double) double dld;
_Alignas (char) long double ldc; /* { dg-error "cannot reduce alignment" } */
_Alignas (short int) long double lds; /* { dg-error "cannot reduce alignment" } */
-_Alignas (int) long double ldi; /* { dg-error "cannot reduce alignment" "" { target { ! { ia32 } } } } */
-_Alignas (long int) long double ldl; /* { dg-error "cannot reduce alignment" "" { target { ! { ia32 } } } } */
-_Alignas (long long int) long double ldll; /* { dg-error "cannot reduce alignment" "" { target { ! { ia32 } } } } */
-_Alignas (float) long double ldf; /* { dg-error "cannot reduce alignment" "" { target { ! { ia32 } } } } */
-_Alignas (double) long double ldd; /* { dg-error "cannot reduce alignment" "" { target { ! { ia32 } } } } */
+
+#if __SIZEOF_LONG_DOUBLE__ == 12
+/* Get around PR testsuite/69573 - FAIL: gcc.dg/pr61053.c (test for excess
+ errors) on targets such as x86_64-apple-darwin15.3.0 where long double
+ is 16 bytes wide even in LP32. */
+# define X(T) short
+#else
+# define X(T) T
+#endif
+
+_Alignas (X (int)) long double ldi; /* { dg-error "cannot reduce alignment" } */
+_Alignas (X (long int)) long double ldl; /* { dg-error "cannot reduce alignment" } */
+_Alignas (X (long long int)) long double ldll; /* { dg-error "cannot reduce alignment" } */
+_Alignas (X (float)) long double ldf; /* { dg-error "cannot reduce alignment" } */
+_Alignas (X (double)) long double ldd; /* { dg-error "cannot reduce alignment" } */
_Alignas (long double) long double ldld;
