Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators
> On 15 Jan 2016, at 05:10, Patrick Palka wrote: > > On Thu, 14 Jan 2016, Ryan Burn wrote: > >> Also caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091 > > Thanks for the heads up, I was not aware I had caused this regression. While looking at last few failures with GCC 6.0.0 in our software, I found one compilation error related to PR c++/21802 fix. I am not yet sure if this is a compiler issue or something else, thus instead just made a comment [1] to PR c++/21802 with the current details (incl. pre-processed source). It works fine with GCC 5.3.0, Clang 3.7.0 and ICC (16.0.2 20160204). david - - - [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802#c8
[committed] Fix [Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c
I have committed the following patch for PR70573 (preapproved by Jakub Jelinek
in bugzilla)
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 234847)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2016-04-09 Dominique d'Humieres
+
+ PR sanitizer/70573
+ * c-c++-common/asan/halt_on_error-1.c: Replace memset
+ with __builtin_memset
+ * c-c++-common/asan/halt_on_error-2.c: Likewise.
+
2016-04-08 Cesar Philippidis
PR lto/70289
Index: gcc/testsuite/c-c++-common/asan/halt_on_error-1.c
===
--- gcc/testsuite/c-c++-common/asan/halt_on_error-1.c (revision 234847)
+++ gcc/testsuite/c-c++-common/asan/halt_on_error-1.c (working copy)
@@ -9,7 +9,7 @@
int main() {
char x[10];
- memset(x, 0, ten + 1);
+ __builtin_memset(x, 0, ten + 1);
asm volatile ("" : : : "memory");
volatile int res = x[ten];
x[ten] = res + 3;
Index: gcc/testsuite/c-c++-common/asan/halt_on_error-2.c
===
--- gcc/testsuite/c-c++-common/asan/halt_on_error-2.c (revision 234847)
+++ gcc/testsuite/c-c++-common/asan/halt_on_error-2.c (working copy)
@@ -10,7 +10,7 @@
int main() {
char x[10];
- memset(x, 0, ten + 1);
+ __builtin_memset(x, 0, ten + 1);
asm volatile ("" : : : "memory");
volatile int res = x[ten];
x[ten] = res + 3;
Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct
>>> On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote: Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it be back ported to the gcc-5 branch? >>> >>> No and No. > Le 7 avr. 2016 à 15:59, Steve Kargl a > écrit : > > The latter is obvious as this "fixes" neither a regression > nor documentation. I won’t argue. > For the former, see Fortran 95, section 4.5. > > -- > steve Are you referring to (a) An empty sequence forms a zero-sized rank-one array. (b) The type and type parameters of an array constructor are those of the ac-value expressions. (c) something else? For (a) gfortran accepts zero-sized rank-one array with a type as shown by the instances in the added test. AFAIU (b), it implicitly rules out a zero-sized rank-one array without a type, which is rejected by gfortran (if not what is the type of ‘[ ]’ and what should be the result of SUM([ ])?). Note that I see NOTE 4.73 Examples of zero-size array constructors are: [ INTEGER :: ] in my copy of the f2015 draft. Note that the patch is not mine but has been submitted by Tobias Burnus more than five years ago. It does not change any gfortran functionality and is only intended to help the end user. I have no intention to fight for this patch. If you think it is really irrelevant, please close the PR according your taste. Dominique
Re: [PATCH] Fix ifcombine (PR tree-optimization/70586)
On April 8, 2016 10:00:58 PM GMT+02:00, Jakub Jelinek wrote: >On Fri, Apr 08, 2016 at 09:14:33PM +0200, Richard Biener wrote: >> Hmm, I think this means GIMPLE_has_side_effects is to be fixed then. > >> Note that honza had plans to compute things like 'uses FP' and >'contains arith with undefined overflow' and propagate that alongside >pure/const-ness. >> >> Can you try to asses the impact of fixing no-side-effects? > >That sounds extremely risky to me, there are lots of callers of that, >and >many really don't care, they e.g. check if they can remove the stmt, or >if it can be moved towards the exit block, etc. >Plus even other side-effects like maybe throwing are not included in >gimple_has_side_effects and are tested separately. >Maybe just return true on all calls in gimple_could_trap_p, but even >that >has 5 other callers that would need to be carefully analyzed. Even >that >looks too risky for late stage4 to me. I agree, but even PPRE may cause wrong code in this case, phiopt comes to myind as well as ifcvt. So this is papering over an issue in our infrastructure really. Let me think about this some more after returning from my sick leave. Your patch is OK for trunk (with a comment added), but please make sure a bug is left open for the general issue. Richard. > Jakub
Re: [PATCH] Fix ifcombine (PR tree-optimization/70586)
On April 9, 2016 1:17:51 PM GMT+02:00, Richard Biener wrote: >On April 8, 2016 10:00:58 PM GMT+02:00, Jakub Jelinek > wrote: >>On Fri, Apr 08, 2016 at 09:14:33PM +0200, Richard Biener wrote: >>> Hmm, I think this means GIMPLE_has_side_effects is to be fixed then. >> >>> Note that honza had plans to compute things like 'uses FP' and >>'contains arith with undefined overflow' and propagate that alongside >>pure/const-ness. >>> >>> Can you try to asses the impact of fixing no-side-effects? >> >>That sounds extremely risky to me, there are lots of callers of that, >>and >>many really don't care, they e.g. check if they can remove the stmt, >or >>if it can be moved towards the exit block, etc. >>Plus even other side-effects like maybe throwing are not included in >>gimple_has_side_effects and are tested separately. >>Maybe just return true on all calls in gimple_could_trap_p, but even >>that >>has 5 other callers that would need to be carefully analyzed. Even >>that >>looks too risky for late stage4 to me. > >I agree, but even PPRE may cause wrong code in this case, phiopt comes >to myind as well as ifcvt. So this is papering over an issue in our >infrastructure really. > >Let me think about this some more after returning from my sick leave. > >Your patch is OK for trunk (with a comment added), but please make sure >a bug is left open for the general issue. To followup myself here - we can also make sure the function doesn't become pure/const. Similar issues exist with pure/const functions with ops with undefined overflow (and code gen taking advantage of that). So it's not only trapping that needs to be guarded against... :/ Richard. >Richard. > >> Jakub
Re: [PATCH, PR68953] Fix pdr accesses order
On April 9, 2016 6:07:19 AM GMT+02:00, Sebastian Pop wrote:
>On Fri, Apr 8, 2016 at 2:03 AM, Tom de Vries
>wrote:
>> pdr_0 (read
>> in gimple stmt: _9 = yu[_8][0];
>> data accesses: { S_4[i1, i2] -> [1, 0, 1 + i1] }
>
>data access should be { S_4[i1, i2] -> [1, 1 + i1, 0] }
>
>> subscript sizes: { [1, i1, 0] : i1 >= 0 and i1 <= 3 }
>> )
>[...]
>> I'm not really sure how this is supposed to be fixed. I imagine that
>we should do one of 3:
>> 1. we change the order in the access functions
>> 2. we change the order in the subscript_sizes
>> 3. we keep the orders as they are, but don't intersect them directly
>>but do an order inversion before.
>>
>> I've picked 1, since that was the easiest for me to implement (but
>I'm not sure if by doing so, I've broken any hardcoded graphite
>assumptions).
>
>1 is the right fix: both access functions and subscript sizes should
>be in the same order.
>If Richi agrees, ok to commit.
OK.
Richard.
>Thanks,
>Sebastian
Re: [PATCH] Fix ifcombine (PR tree-optimization/70586)
On Sat, Apr 09, 2016 at 01:21:06PM +0200, Richard Biener wrote: > To followup myself here - we can also make sure the function doesn't become > pure/const. > > Similar issues exist with pure/const functions with ops with undefined > overflow (and code gen taking advantage of that). > So it's not only trapping that needs to be guarded against... :/ But then we'd probably want 2 categories, keep pure/const meaning it had (that allows trapping/FPU exceptions, because, aren't most of libm const functions in this category?), and then have another attributes for functions that can't trap/don't use FPU etc. Anyway, I've committed the patch and will change the PR to be 7/Regression, so that it is not forgotten. Jakub
Re: [PATCH] Fix ifcombine (PR tree-optimization/70586)
On April 9, 2016 1:29:51 PM GMT+02:00, Jakub Jelinek wrote: >On Sat, Apr 09, 2016 at 01:21:06PM +0200, Richard Biener wrote: >> To followup myself here - we can also make sure the function doesn't >become pure/const. >> >> Similar issues exist with pure/const functions with ops with >undefined overflow (and code gen taking advantage of that). >> So it's not only trapping that needs to be guarded against... :/ > >But then we'd probably want 2 categories, keep pure/const meaning it >had >(that allows trapping/FPU exceptions, because, aren't most of libm >const >functions in this category?), and then have another attributes for >functions >that can't trap/don't use FPU etc. I have to think about this. We need to look at the user documented semantics of pure/const and need to decide where We can directly use them in the middle end and where we need some 'derived' Property instead. >Anyway, I've committed the patch and will change the PR to be >7/Regression, >so that it is not forgotten. Thanks, Richard. > Jakub
Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend
On Fri, 8 Apr 2016, Jake Hamby wrote: > Thanks for the info! I've discovered a few additional clues which should > help, namely the optimizer pass that's introducing the problem. Through > process of elimination, I discovered that adding "-fno-tree-ter" will > prevent the unrecognizable insn error. Strangely, I can't cause the > problem by using "-ftree-ter" and -O0, which seems odd, unless the code > is checking directly for a -O flag. You can't turn most optimisations on at -O0, you need to globally enable optimisation in the first place -- any -O setting will do, e.g. -O, -Os, etc., as per the GCC manual: "Most optimizations are only enabled if an `-O' level is set on the command line. Otherwise they are disabled, even if individual optimization flags are specified." So to enable a single optimisation only you'll have to use e.g. -O combined with a list of negated -f options to disable this level's optimisation defaults. Yes, I agree this sounds like an awkward UI; I guess it dates back to GCC's early days and nobody bothered to fix it. Maybe we need -Onone or suchlike. > I'll continue to clean up the diffs that I've been working on, and send > out something when I've made more progress. I like the "cc" attr code > that I've added to fix the overaggressive elimination of CC0 tests, but > the problem is that now it's too conservative, because many insns are > defined as calls into C code which may or may not generate insns that > set the condition codes. I have a few ideas on how to clean up and > refactor that code, but first I had to convince myself that most of > what's in there now are actually useful optimizations, and they seem to > be. Good luck! > Thanks for the help! You are welcome! Maciej
Re: [C PATCH] PR43651: add warning for duplicate qualifier
On 04/08/2016 08:54 PM, Martin Sebor wrote:
>> The name for new option "-Wduplicate-decl-specifier" and wording was
>> chosen to match the same option in Clang.
>
> My version of Clang also warns in C++ mode but if I'm reading
> the patch right, GCC would warn only C mode. I would find it
> surprising if GCC provided the same option as Clang but didn't
> make it available in the same languages. Do you have some
> reason for leaving it out that I'm not thinking of?
It is an error in C++ mode. Do we want to change this behavior?
>
> Also, in C11 mode, Clang issues the warning for duplicated
> _Atomic qualifiers but it doesn't look like GCC would with
> the patch. Here again, unless there's some reason not to,
> I would expect GCC to issue the same warning as Clang for
> the same code.
>
Fixed.
--
Regards,
Mikhail Maltsev
gcc/c/ChangeLog:
2016-04-08 Mikhail Maltsev
PR c/43651
* c-decl.c (declspecs_add_qual): Warn when -Wduplicate-decl-specifier
is enabled.
* c-errors.c (pedwarn_c90): Return true if warned.
* c-tree.h (pedwarn_c90): Change return type to bool.
(enum c_declspec_word): Add new enumerator cdw_atomic.
gcc/ChangeLog:
2016-04-08 Mikhail Maltsev
PR c/43651
* doc/invoke.texi (Wduplicate-decl-specifier): Document new option.
gcc/testsuite/ChangeLog:
2016-04-08 Mikhail Maltsev
PR c/43651
* gcc.dg/Wduplicate-decl-specifier-c11.c: New test.
* gcc.dg/Wduplicate-decl-specifier.c: Likewise.
gcc/c-family/ChangeLog:
2016-04-08 Mikhail Maltsev
PR c/43651
* c.opt (Wduplicate-decl-specifier): New option.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 4f86876..f7f844d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1000,6 +1000,10 @@ Wsubobject-linkage
C++ ObjC++ Var(warn_subobject_linkage) Warning Init(1)
Warn if a class type has a base or a field whose type uses the anonymous namespace or depends on a type with no linkage.
+Wduplicate-decl-specifier
+C ObjC Var(warn_duplicate_decl_specifier) Warning LangEnabledBy(C ObjC,Wall)
+Warn when a declaration has duplicate const, volatile, restrict or _Atomic specifier.
+
ansi
C ObjC C++ ObjC++
A synonym for -std=c89 (for C) or -std=c++98 (for C++).
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 0dd2121..bc3af02 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -9539,32 +9539,48 @@ declspecs_add_qual (source_location loc,
gcc_assert (TREE_CODE (qual) == IDENTIFIER_NODE
&& C_IS_RESERVED_WORD (qual));
i = C_RID_CODE (qual);
+ location_t prev_loc = 0;
switch (i)
{
case RID_CONST:
dupe = specs->const_p;
specs->const_p = true;
+ prev_loc = specs->locations[cdw_const];
specs->locations[cdw_const] = loc;
break;
case RID_VOLATILE:
dupe = specs->volatile_p;
specs->volatile_p = true;
+ prev_loc = specs->locations[cdw_volatile];
specs->locations[cdw_volatile] = loc;
break;
case RID_RESTRICT:
dupe = specs->restrict_p;
specs->restrict_p = true;
+ prev_loc = specs->locations[cdw_restrict];
specs->locations[cdw_restrict] = loc;
break;
case RID_ATOMIC:
dupe = specs->atomic_p;
specs->atomic_p = true;
+ prev_loc = specs->locations[cdw_atomic];
+ specs->locations[cdw_atomic] = loc;
break;
default:
gcc_unreachable ();
}
if (dupe)
-pedwarn_c90 (loc, OPT_Wpedantic, "duplicate %qE", qual);
+{
+ bool warned = pedwarn_c90 (loc, OPT_Wpedantic,
+ "duplicate %qE declaration specifier", qual);
+ if (!warned
+ && warn_duplicate_decl_specifier
+ && prev_loc >= RESERVED_LOCATION_COUNT
+ && !from_macro_expansion_at (prev_loc)
+ && !from_macro_expansion_at (loc))
+ warning_at (loc, OPT_Wduplicate_decl_specifier,
+ "duplicate %qE declaration specifier", qual);
+}
return specs;
}
diff --git a/gcc/c/c-errors.c b/gcc/c/c-errors.c
index d5e78b8..af157c0 100644
--- a/gcc/c/c-errors.c
+++ b/gcc/c/c-errors.c
@@ -71,11 +71,12 @@ pedwarn_c99 (location_t location, int opt, const char *gmsgid, ...)
ISO C99 but not supported in ISO C90, thus we explicitly don't pedwarn
when C99 is specified. (There is no flag_c90.) */
-void
+bool
pedwarn_c90 (location_t location, int opt, const char *gmsgid, ...)
{
diagnostic_info diagnostic;
va_list ap;
+ bool warned = false;
rich_location richloc (line_table, location);
va_start (ap, gmsgid);
@@ -92,6 +93,7 @@ pedwarn_c90 (location_t location, int opt, const char *gmsgid, ...)
? DK_PEDWARN : DK_WARNING);
diagnostic.option_index = opt;
report_diagnostic (&diagnostic);
+ warned = true;
goto out;
}
}
@@ -114,7 +116,9 @@ pedwarn_c90 (location_t location, int opt, const char *gmsgid, ...)
diagnostic_set_info (&diagnostic, gmsgid, &ap, &richloc, DK_PEDWARN);
diagnostic.option_index = opt;
report_d
[committed] PR70592 New test gfortran.dg/deferred_character_16.f90
As asked by Paul Richard Thomas on IRC I have committed the following patch to
trunk. I’ll commit it to the gcc-5 branch tomorrow.
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 234849)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2016-04-09 Dominique d'Humieres
+
+ PR fortran/70592
+ * gfortran.dg/deferred_character_16.f90: New test.
+
2016-04-09 Jakub Jelinek
PR tree-optimization/70586
Index: gcc/testsuite/gfortran.dg/deferred_character_16.f90
===
--- gcc/testsuite/gfortran.dg/deferred_character_16.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/deferred_character_16.f90 (working copy)
@@ -0,0 +1,19 @@
+! { dg-do run }
+! PR70592 dynamically-allocated character array
+! Contributed by Peter Knowles
+!
+PROGRAM main
+ character(len=7) :: res
+ CHARACTER(len=:), DIMENSION(:), POINTER :: cp
+ INTEGER :: i
+ ALLOCATE(CHARACTER(len=1) :: cp(1:6))
+ if (SIZE(cp) /= 6 .or. LBOUND(cp,1) /= 1 .or. UBOUND(cp,1) /= 6) call abort()
+ cp(1)='1'
+ cp(2)='2'
+ cp(3)='3'
+ cp(4)='4'
+ cp(5)='5'
+ cp(6)='6'
+ write (res, *) cp
+ if (res /= ' 123456') call abort()
+END PROGRAM main
Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct
On Sat, Apr 09, 2016 at 12:28:12PM +0200, Dominique d'Humières wrote: > >>> On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote: > Is the following patch OK (regtested on x86_64-apple-darwin15)? Should > it be back ported to the gcc-5 branch? > >>> > >>> No and No. > > Le 7 avr. 2016 à 15:59, Steve Kargl a > > écrit : > > > > The latter is obvious as this "fixes" neither a regression > > nor documentation. > > I won’t argue. > > > For the former, see Fortran 95, section 4.5. > > > > -- > > steve > > > Are you referring to > > (a) An empty sequence forms a zero-sized rank-one array. > > (b) The type and type parameters of an array constructor are those of the > ac-value expressions. > > (c) something else? > Fortran 95 doesn't have a type-spec in an array constructor. Fortran 95 explicitly states "The type and type parameters of an array constructor are those of the ac-value expressions." (/ /) is valid Fortran 95 syntax while (/ type-spec :: /) is not valid. type-spec was introduced in Fortran 2003. The error message as written is correct. (/ /) is empty. (/type-spec :: /) is not empty, and is invalid Fortan 95. (/1, 2, 3/) is not empty and has a type of INTEGER. program foo call bar((/ /)) end program foo % gfc -c -std=f95 foo.f90 foo.f90:2:17: call bar((/ /)) 1 Error: Empty array constructor at (1) is not allowed The above error is correct. Adding any text referring to type-spec is wrong. -- Steve
Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct
> (/ /) is valid Fortran 95 syntax > ... > > program foo > call bar((/ /)) > end program foo > > % gfc -c -std=f95 foo.f90 > foo.f90:2:17: > >call bar((/ /)) > 1 > Error: Empty array constructor at (1) is not allowed > > The above error is correct. Well the two assertions look contradictory: if (/ /) is valid Fortran 95 syntax why is it not allowed? > Adding any text referring > to type-spec is wrong. > > -- > Steve Are you considering (/ ( i, i = 1, 0 ) /) as non empty? Dominique
Re: [PATCH 2/3] [graphite] add array access function in the right order
On 09/12/15 19:26, Sebastian Pop wrote:
we used to add the access functions in the wrong order, Fortran style, leading
to unprofitable interchanges.
---
gcc/graphite-sese-to-poly.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index 887c212..480c552 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -912,7 +912,7 @@ pdr_add_memory_accesses (isl_map *acc, dr_info &dri)
for (i = 0; i < nb_subscripts; i++)
{
isl_pw_aff *aff;
- tree afn = DR_ACCESS_FN (dr, nb_subscripts - 1 - i);
+ tree afn = DR_ACCESS_FN (dr, i);
aff = extract_affine (scop, afn,
isl_space_domain (isl_map_get_space (acc)));
Hi,
I think the fix for PR68953 (
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=234851 ) undoes
this fix.
What problem was this patch intending to address?
In other words, have I re-introduced a problem by fixing PR68953 ?
Thanks,
- Tom
Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct
On Sat, Apr 09, 2016 at 05:56:12PM +0200, Dominique d'Humières wrote: > > > (/ /) is valid Fortran 95 syntax > > ... > > > > program foo > > call bar((/ /)) > > end program foo > > > > % gfc -c -std=f95 foo.f90 > > foo.f90:2:17: > > > >call bar((/ /)) > > 1 > > Error: Empty array constructor at (1) is not allowed > > > > The above error is correct. > > Well the two assertions look contradictory: if (/ /) is valid > Fortran 95 syntax why is it not allowed? It is valid syntax because of "An empty sequence forms a zero-sized rank-one array." It seems that J3 saw the error in their ways as (/ /) is clearly an empty array constructor, and fixed the possibility of creating a typeless zero-sized, rank-one array. > > Adding any text referring > > to type-spec is wrong. > > > > Are you considering (/ ( i, i = 1, 0 ) /) as non empty? > It is a zero-sized rank-one array with type INTEGER. "The type and type parameters of an array constructor are those of the ac-value expressions." ac-valueis expr or ac-implied-do "If an ac-value is an ac-implied-do, it is expanded to form an ac-value sequence under the control of the ac-do-variable..." -- Steve
Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct
> > It is valid syntax because of > > "An empty sequence forms a zero-sized rank-one array." > > It seems that J3 saw the error in their ways as (/ /) is clearly > an empty array constructor, and fixed the possibility of creating > a typeless zero-sized, rank-one array. This is exactly the point of the patch! typeless zero-sized, rank-one array are not allowed, while typed zero-sized, rank-one array are. > >>> Adding any text referring >>> to type-spec is wrong. >>> >> >> Are you considering (/ ( i, i = 1, 0 ) /) as non empty? >> > > It is a zero-sized rank-one array with type INTEGER. That is not the answer to the question. Is (/ ( i, i = 1, 0 ) /) non empty, yes or no? IMO "empty array constructor" is ambiguous. One meaning is nothing but spaces between (/ and /) in the source code, another one is zero-sized rank-one array. Dominique PS I have wasted enough time on this patch. If you don’t accept it, close PR47040.
Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct
On Sat, Apr 09, 2016 at 06:51:50PM +0200, Dominique d'Humières wrote: > > > > > It is valid syntax because of > > > > "An empty sequence forms a zero-sized rank-one array." > > > > It seems that J3 saw the error in their ways as (/ /) is clearly > > an empty array constructor, and fixed the possibility of creating > > a typeless zero-sized, rank-one array. > > This is exactly the point of the patch! typeless zero-sized, rank-one array > are not allowed, while typed zero-sized, rank-one array are. > And, you're missing the point that your patch is suggesting that one use (/ INTEGER :: /), which is clearly invalid Fortran 95. > >>> Adding any text referring > >>> to type-spec is wrong. > >>> > >> > >> Are you considering (/ ( i, i = 1, 0 ) /) as non empty? > >> > > > > It is a zero-sized rank-one array with type INTEGER. > > That is not the answer to the question. I answered the question that was asked. The crucial point is that (/ (i,i=1,0) /) as a type! > Is (/ ( i, i = 1, 0 ) /) non empty, yes or no? That wasn't that originally asked question. > IMO "empty array constructor" is ambiguous. Yes, it is. That is why J3 made changes in Fortran 2003. -- Steve
Re: [PATCH withdrawn] PR47040 - Make error message for empty array constructor more helpful/correct, closed as INVALID
Patch withdrawn, PR47040 closed as INVALID. Dominique
[committed] Testsuite fixes for hppa
Attached are a set of testsuite updates for hppa. The pr64434.c.d.txt,
ivopts-lt-2.c.d.txt and uninit-19.c.d.txt changes
were applied to both gcc-5 and trunk. The rest were applied to the trunk.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Sorry, for batch update. Mail wasn't working.
Dave
--
John David Anglin dave.ang...@bell.net
2016-04-09 John David Anglin
PR rtl-optimization/64886
* gcc.dg/pr64434.c: Skip on hppa*-*-hpux*.
Index: gcc.dg/pr64434.c
===
--- gcc.dg/pr64434.c(revision 234351)
+++ gcc.dg/pr64434.c(working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O1 -fdump-rtl-expand-details" } */
+/* { dg-skip-if "PR64886" { hppa*-*-hpux* } { "*" } { "" } } */
#define N 256
int a1[N], a2[N], a3[N], a4[N];
2016-04-09 John David Anglin
PR tree-optimization/68644
* gcc.dg/tree-ssa/ivopts-lt-2.c: Skip on hppa*-*-*.
Index: gcc.dg/tree-ssa/ivopts-lt-2.c
===
--- gcc.dg/tree-ssa/ivopts-lt-2.c (revision 234351)
+++ gcc.dg/tree-ssa/ivopts-lt-2.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-ivopts" } */
+/* { dg-skip-if "PR68644" { hppa*-*-* } { "*" } { "" } } */
void
f1 (int *p, unsigned int i)
2016-04-09 John David Anglin
* gcc.dg/uninit-19.c: Fix warning line for hppa*64*-*-*.
Index: gcc.dg/uninit-19.c
===
--- gcc.dg/uninit-19.c (revision 234351)
+++ gcc.dg/uninit-19.c (working copy)
@@ -22,5 +22,5 @@
fn1 (l, &d, &e, &g, &i, &h, &k, n); /* 22. */
}
-/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
-/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */
+/* { dg-warning "may be used uninitialized" "" { target { { nonpic } || {
hppa*64*-*-* } } } 13 } */
+/* { dg-warning "may be used uninitialized" "" { target { ! { { nonpic } || {
hppa*64*-*-* } } } } 22 } */
2016-04-09 John David Anglin
* gcc.dg/pic-1.c: Skip on hppa*-*-*.
* gcc.dg/pie-1.c: Likewise.
* gcc.dg/pic-3.c: Skip on hppa*64*-*-*.
* gcc.dg/pic-4.c: Likewise.
* gcc.dg/pie-3.c: Likewise.
* gcc.dg/pie-4.c: Likewise.
Index: gcc.dg/pic-1.c
===
--- gcc.dg/pic-1.c (revision 234788)
+++ gcc.dg/pic-1.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-do compile { target { ! { *-*-darwin* hppa*-*-* } } } } */
/* { dg-options "-fpic" } */
#if __PIC__ != 1
Index: gcc.dg/pic-3.c
===
--- gcc.dg/pic-3.c (revision 234788)
+++ gcc.dg/pic-3.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-do compile { target { ! { *-*-darwin* hppa*64*-*-* } } } } */
/* { dg-options "-fno-pic" } */
#ifdef __PIC__
Index: gcc.dg/pic-4.c
===
--- gcc.dg/pic-4.c (revision 234788)
+++ gcc.dg/pic-4.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-do compile { target { ! { *-*-darwin* hppa*64*-*-* } } } } */
/* { dg-options "-fno-PIC" } */
#ifdef __PIC__
Index: gcc.dg/pie-1.c
===
--- gcc.dg/pie-1.c (revision 234788)
+++ gcc.dg/pie-1.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-do compile { target { ! { *-*-darwin* hppa*-*-* } } } } */
/* { dg-options "-fpie" } */
#if __PIC__ != 1
Index: gcc.dg/pie-3.c
===
--- gcc.dg/pie-3.c (revision 234788)
+++ gcc.dg/pie-3.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-do compile { target { ! { *-*-darwin* hppa*64*-*-* } } } } */
/* { dg-options "-fno-pie" } */
#ifdef __PIC__
Index: gcc.dg/pie-4.c
===
--- gcc.dg/pie-4.c (revision 234788)
+++ gcc.dg/pie-4.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-do compile { target { ! { *-*-darwin* hppa*64*-*-* } } } } */
/* { dg-options "-fno-PIE" } */
#ifdef __PIC__
2016-04-09 John David Anglin
* gcc.dg/debug/dwarf2/prod-options.c: Adjust scan for hppa*64*-*-*.
Index: gcc.dg/debug/dwarf2/prod-options.c
===
--- gcc.dg/debug/dwarf2/prod-options.c (revision 234858)
+++ gcc.dg/debug/dwarf2/prod-options.c (working copy)
@@ -4,8 +4,8 @@
as well. */
/* { dg-do compile } */
/* { dg-options "-O2 -gdwarf -dA -fdebug-prefix-map=a=b"
[wwwdocs,Java] java/index.html -- fix formatting on gcc.gnu.org
It turns out the stricter server settings also broke the /java
page on gcc.gnu.org.
This restores showing two columns on this page (though it still
uses non-standard CSS extensions).
That said, looking at the page, and how since 2005 nearly all changes
have been maintainance ones from me, is it really worthwhile keeping
this (short of historic reasons)?
2016-04-08 Gerald Pfeifer
* index.html: Replace manual style to establish two columns
by new global CSS class "twocolumns".
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.38
diff -u -r1.38 gcc.css
--- gcc.css 5 Apr 2016 16:20:29 - 1.38
+++ gcc.css 9 Apr 2016 16:22:40 -
@@ -15,6 +15,8 @@
.highlight{ color: darkslategray; font-weight:bold; }
.smaller { font-size: 80%; }
+.twocolumns { column-counts:2; -moz-column-count:2; }
+
td.news { width: 50%; padding-right: 8px; }
td.news h2 { font-size: 1.2em; margin-top: 0; margin-bottom: 2%; }
td.news dl { margin-top:0; }
Index: java/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/java/index.html,v
retrieving revision 1.177
diff -u -r1.177 index.html
--- java/index.html 27 Jun 2014 15:04:39 - 1.177
+++ java/index.html 9 Apr 2016 16:22:41 -
@@ -32,7 +33,7 @@
GCJ News
-
+
[wwwdocs] Simplify gcc-4.6/cxx0x_status.html (and convert to global CSS)
And here is the version for GCC 4.6. Applied. Gerald Index: gcc-4.6/cxx0x_status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/cxx0x_status.html,v retrieving revision 1.11 diff -u -r1.11 cxx0x_status.html --- gcc-4.6/cxx0x_status.html 5 Dec 2011 21:51:05 - 1.11 +++ gcc-4.6/cxx0x_status.html 10 Apr 2016 01:21:25 - @@ -2,13 +2,6 @@ Status of Experimental C++0x Support in GCC 4.6 - -/* */ - @@ -36,7 +29,7 @@ - + Language Feature Proposal @@ -45,315 +38,315 @@ Rvalue references http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html";>N2118 - Yes + Yes Rvalue references for *this http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm";>N2439 - No + No Initialization of class objects by rvalues http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html";>N1610 - Yes + Yes Non-static data member initializers http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2756.htm";>N2756 - No + No Variadic templates http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf";>N2242 - Yes + Yes Extending variadic template template parameters http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2555.pdf";>N2555 - Yes + Yes Initializer lists http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm";>N2672 - Yes + Yes Static assertions http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html";>N1720 - Yes + Yes auto-typed variables http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf";>N1984 - Yes + Yes Multi-declarator auto http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1737.pdf";>N1737 - Yes + Yes Removal of auto as a storage-class specifier http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2546.htm";>N2546 - Yes + Yes New function declarator syntax http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm";>N2541 - Yes + Yes New wording for C++0x lambdas http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf";>N2927 - Yes + Yes Declared type of an expression http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf";>N2343 - Yes + Yes Right angle brackets http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html";>N1757 - Yes + Yes Default template arguments for function templates http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226";>DR226 - Yes + Yes Solving the SFINAE problem for expressions http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html";>DR339 - Yes + Yes Template aliases http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf";>N2258 - No + No Extern templates http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm";>N1987 - Yes + Yes Null pointer constant http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf";>N2431 - Yes + Yes Strongly-typed enums http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf";>N2347 - Yes + Yes Forward declarations for enums http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf";>N2764 - Yes + Yes Generalized attributes http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf";>N2761 - No + No Generalized constant expressions http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf";>N2235 - Yes + Yes Alignment support http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf";>N2341 - No + No Delegating constructors http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf";>N1986 - No + No Inheriting constructors http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm";>N2540 - No + No Explicit conversion operators http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf";>N2437 - Yes
