Re: [PATCH] RISC-V: Note that __builtin_riscv_pause() implies Xgnuzihintpausestate
It took me a few minutes to understand the purpose of this chicanery, but
there's indeed a contradiction in the ISA spec. HINT instructions _do_
affect architectural state in a limited fashion--namely, updating the PC.
So, it's incorrect to say that PAUSE changes no architectural state.
Because these statements are contradictory, a common-sense reading should
parse this as "PAUSE changes no architectural state in the same informal
sense as other HINTs". Otherwise, PAUSE wouldn't actually be a HINT.
I'm just going to delete the erroneous text. This eliminates the
contradiction and makes the spec consistent with both the de facto and de
jure golden models, which behave in the common-sense manner Palmer's
Xgnuzihintpausestate extension would suggest.
To avoid confusion, I strongly suggest deleting all references
to Xgnuzihintpausestate, since its existence invites a question that no
longer needs to be answered.
cc'ing Greg since AFAICS he merged in the erroneous text.
On Fri, Dec 16, 2022 at 8:48 AM Palmer Dabbelt wrote:
> On Mon, 28 Nov 2022 10:45:51 PST (-0800), Palmer Dabbelt wrote:
> > On Fri, 18 Nov 2022 09:01:08 PST (-0800), Palmer Dabbelt wrote:
> >> On Thu, 17 Nov 2022 22:59:08 PST (-0800), Kito Cheng wrote:
> >>> Wait, what's Xgnuzihintpausestate???
> >>
> >> I just made it up, it's defined right next to the name like those
> >> profile extensions are. I figured that's the most RISC-V way to define
> >> something like this, but we could just drop it and run with the
> >> definition -- IIRC we just stuck a comment in for Linux and QEMU, I
> >> doubt anyone is actually going to implement the "doesn't touch PC"
> >> version of pause.
> >
> > Just checking up on this one. I don't care a ton about the name, just
> > that we document where we're intentionally violating the specs.
>
> I'm just committing this one, no big deal if you want to change the
> wording. I just want it out of my queue.
>
> >
> >>
> >>> On Fri, Nov 18, 2022 at 12:30 PM Palmer Dabbelt
> wrote:
>
> gcc/ChangeLog:
>
> * doc/extend.texi (__builtin_riscv_pause): Imply
> Xgnuzihintpausestate.
> ---
> gcc/doc/extend.texi | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index b1dd39e64b8..26f14e61bc8 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -21103,7 +21103,9 @@ Returns the value that is currently set in
> the @samp{tp} register.
> @end deftypefn
>
> @deftypefn {Built-in Function} void __builtin_riscv_pause (void)
> -Generates the @code{pause} (hint) machine instruction.
> +Generates the @code{pause} (hint) machine instruction. This implies
> the
> +Xgnuzihintpausestate extension, which redefines the @code{pause}
> instruction to
> +change architectural state.
> @end deftypefn
>
> @node RX Built-in Functions
> --
> 2.38.1
>
>
Re: [PATCH] RISC-V: Note that __builtin_riscv_pause() implies Xgnuzihintpausestate
On Dez 17 2022, Andrew Waterman wrote: > It took me a few minutes to understand the purpose of this chicanery, but > there's indeed a contradiction in the ISA spec. HINT instructions _do_ > affect architectural state in a limited fashion--namely, updating the PC. How can an insn _not_ affect the PC? (Other than the trivial infinite loop.) -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] RISC-V: Note that __builtin_riscv_pause() implies Xgnuzihintpausestate
On Sat, Dec 17, 2022 at 2:10 AM Andreas Schwab wrote: > > On Dez 17 2022, Andrew Waterman wrote: > > > It took me a few minutes to understand the purpose of this chicanery, but > > there's indeed a contradiction in the ISA spec. HINT instructions _do_ > > affect architectural state in a limited fashion--namely, updating the PC. > > How can an insn _not_ affect the PC? (Other than the trivial infinite > loop.) Heh, yeah, that's roughly what I meant by "common-sense reading" (and that's my rationale for simply clarifying the spec and nuking this Xgnuzihintpausestate extension). > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: [PATCH] RISC-V: Note that __builtin_riscv_pause() implies Xgnuzihintpausestate
On Dez 17 2022, Andrew Waterman wrote: > On Sat, Dec 17, 2022 at 2:10 AM Andreas Schwab wrote: >> >> On Dez 17 2022, Andrew Waterman wrote: >> >> > It took me a few minutes to understand the purpose of this chicanery, but >> > there's indeed a contradiction in the ISA spec. HINT instructions _do_ >> > affect architectural state in a limited fashion--namely, updating the PC. >> >> How can an insn _not_ affect the PC? (Other than the trivial infinite >> loop.) > > Heh, yeah, that's roughly what I meant by "common-sense reading" (and > that's my rationale for simply clarifying the spec and nuking this > Xgnuzihintpausestate extension). My point is that the implicit update of the PC cannot be part of the architectural state in the first place. Even the trivial infinite loop has this, before the actual state change (setting PC back) is performed. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] RISC-V: Note that __builtin_riscv_pause() implies Xgnuzihintpausestate
On Sat, Dec 17, 2022 at 2:21 AM Andreas Schwab wrote: > > On Dez 17 2022, Andrew Waterman wrote: > > > On Sat, Dec 17, 2022 at 2:10 AM Andreas Schwab > > wrote: > >> > >> On Dez 17 2022, Andrew Waterman wrote: > >> > >> > It took me a few minutes to understand the purpose of this chicanery, but > >> > there's indeed a contradiction in the ISA spec. HINT instructions _do_ > >> > affect architectural state in a limited fashion--namely, updating the PC. > >> > >> How can an insn _not_ affect the PC? (Other than the trivial infinite > >> loop.) > > > > Heh, yeah, that's roughly what I meant by "common-sense reading" (and > > that's my rationale for simply clarifying the spec and nuking this > > Xgnuzihintpausestate extension). > > My point is that the implicit update of the PC cannot be part of the > architectural state in the first place. Even the trivial infinite loop > has this, before the actual state change (setting PC back) is performed. It's just a definitional issue. By analogy, this is why we have the concept of "explicit memory access" (the thing a load or store is trying to do) and "implicit memory access" (all of the other memory accesses, like the instruction fetch or page-table walk). The PC update is very much an architectural-state change, but it would be fair to call it an "implicit architectural-state change" to contrast with e.g. writing an x-register being an "explicit architectural state change". Anyway, I don't think we're disagreeing with each other (and I still think there's no problem to be solved here). > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: [PATCH] contracts: Stop relying on mangling for naming .pre/.post clones
Jason Merrill writes: > > It's best to wrap the ChangeLog entry at column 75 so that the extra > indentation added by git log doesn't push past column 80. > > Applied with that change. > > Jason Heh, I thought I fixed my fill-column. Will check. Thanks! Have a great day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH] contracts: Stop relying on mangling for naming .pre/.post clones
Iain Sandoe writes: > I think you want to use 'write_string (JOIN_STR “pre”);’ etc. since that > handles targets > that cannot use a period in symbol names. Ah - I think you're right. I'll have to delay checking/fixing for now. Thanks for the note. > If this is the right place, then I can update my patch for coroutines - both > Gor and Lewis replied that ‘extern “C”’ coroutines seemed reasonable to > them. Yes, that seems about right to me. Have a great day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH v2] coroutines: Accept 'extern "C"' coroutines.
Hi.
It seems that everyone agrees that extern C coroutines should be permitted,
although I have yet to see a useful testcase.
This patch has been revised to append the suffices for such functions in
mangle.cc rather than as part of the outlined function decl production.
tested on x86_64-darwin21.
OK for trunk?
Iain
— 8< —
'extern "C"' coroutines are permitted by the standard and expected to work
(although constructing useful cases could be challenging). In order to
permit this we need to arrange for the outlined helper functions to be
named properly, even when no mangling is required. To do this, we append
the actor and destroy suffixes in all cases.
Signed-off-by: Iain Sandoe
gcc/cp/ChangeLog:
* mangle.cc (write_mangled_name): Append the helper function
suffixes here...
(write_encoding): ... rather than here.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/torture/extern-c-coroutine.C: New test.
---
gcc/cp/mangle.cc | 23 ++---
.../coroutines/torture/extern-c-coroutine.C | 89 +++
2 files changed, 101 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/coroutines/torture/extern-c-coroutine.C
diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
index 074cf27ec7a..5789adcf680 100644
--- a/gcc/cp/mangle.cc
+++ b/gcc/cp/mangle.cc
@@ -805,6 +805,18 @@ write_mangled_name (const tree decl, bool top_level)
write_string (".pre");
else if (DECL_IS_POST_FN_P (decl))
write_string (".post");
+
+ /* If this is a coroutine helper, then append an appropriate string to
+ identify which. */
+ if (tree ramp = DECL_RAMP_FN (decl))
+{
+ if (DECL_ACTOR_FN (ramp) == decl)
+ write_string (JOIN_STR "actor");
+ else if (DECL_DESTROY_FN (ramp) == decl)
+ write_string (JOIN_STR "destroy");
+ else
+ gcc_unreachable ();
+}
}
/* Returns true if the return type of DECL is part of its signature, and
@@ -863,17 +875,6 @@ write_encoding (const tree decl)
mangle_return_type_p (decl),
d);
- /* If this is a coroutine helper, then append an appropriate string to
-identify which. */
- if (tree ramp = DECL_RAMP_FN (decl))
- {
- if (DECL_ACTOR_FN (ramp) == decl)
- write_string (JOIN_STR "actor");
- else if (DECL_DESTROY_FN (ramp) == decl)
- write_string (JOIN_STR "destroy");
- else
- gcc_unreachable ();
- }
}
}
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/extern-c-coroutine.C
b/gcc/testsuite/g++.dg/coroutines/torture/extern-c-coroutine.C
new file mode 100644
index 000..c178a80ee4b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/torture/extern-c-coroutine.C
@@ -0,0 +1,89 @@
+#include
+#include
+
+#ifndef OUTPUT
+# define PRINT(X)
+# define PRINTF(X,...)
+#else
+# define PRINT(X) puts(X)
+# define PRINTF printf
+#endif
+
+struct future {
+ struct promise_type;
+ using handle_type = std::coroutine_handle;
+ handle_type handle;
+ future () : handle(0) {}
+ future (handle_type _handle)
+: handle(_handle) {
+PRINT("Created future object from handle");
+ }
+ future (const future &) = delete; // no copying
+ future (future &&s) : handle(s.handle) {
+ s.handle = nullptr;
+ PRINT("future mv ctor ");
+ }
+ future &operator = (future &&s) {
+ handle = s.handle;
+ s.handle = nullptr;
+ PRINT("future op= ");
+ return *this;
+ }
+ ~future() {
+PRINT("Destroyed future");
+if ( handle )
+ handle.destroy();
+ }
+
+ struct promise_type {
+void return_value (int v) {
+ PRINTF ("return_value (%d)\n", v);
+ vv = v;
+}
+
+std::suspend_always initial_suspend() noexcept { return {}; }
+std::suspend_always final_suspend() noexcept { return {}; }
+void unhandled_exception() {}
+auto get_return_object() {return handle_type::from_promise (*this);}
+
+int get_value () { return vv; }
+ private:
+int vv;
+ };
+ bool await_ready() { return false; }
+ void await_suspend(std::coroutine_handle<>) {}
+ void await_resume() {}
+};
+
+extern "C" future
+test () {
+ co_return 22;
+}
+
+extern "C" future
+f () noexcept
+{
+ PRINT ("future: about to return");
+ co_return 42;
+}
+
+int main ()
+{
+ PRINT ("main: create future");
+ future x = f ();
+ PRINT ("main: got future - resuming");
+ if (x.handle.done())
+__builtin_abort ();
+ x.handle.resume();
+ PRINT ("main: after resume");
+ int y = x.handle.promise().get_value();
+ if ( y != 42 )
+__builtin_abort ();
+ if (!x.handle.done())
+{
+ PRINT ("main: apparently not done...");
+ __builtin_abort ();
+}
+ PRINT ("main: returning");
+ return 0;
+}
--
2.37.1 (Apple Git-137.1)
[PATCH, m2]: PR-108122 Reduce sleep times in gm2/pimcoroutines/run/pass/testtime.mod
PR-108122 Reduce sleep times in gm2/pimcoroutines/run/pass/testtime.mod
Change time unit to 1 jiffy (with respect to TimerHandler.def) rather
than a second.
gcc/testsuite/ChangeLog:
* gm2/pimcoroutines/run/pass/testtime.mod: Reduce sleep times in
the test by a factor of 25.
Tested on amd64, ok for Trunk?
diff --git a/gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod
b/gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod
index fa43163b107..f457716c89e 100644
--- a/gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod
+++ b/gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod
@@ -1,4 +1,4 @@
-(* Copyright (C) 2005-2020
+(* Copyright (C) 2005-2022
Free Software Foundation, Inc. *)
(* This file is part of GNU Modula-2.
@@ -31,30 +31,34 @@ FROM SYSTEM IMPORT ADR ;
FROM libc IMPORT write, printf ;
+CONST
+ TicksPerTimeUnit = 1 ;
+
+
(*
- OneSecond -
+ OneUnit -
*)
-PROCEDURE OneSecond ;
+PROCEDURE OneUnit ;
VAR
n: CARDINAL ;
BEGIN
OldInts := TurnInterrupts (MIN (PROTECTION)) ;
- printf ("1 second process has come to life\n");
+ printf ("1 unit second process has come to life\n");
n := 0 ;
LOOP
- Sleep (1*TicksPerSecond) ;
+ Sleep (1*TicksPerTimeUnit) ;
INC (n) ;
- printf ("%d seconds\n", n);
+ printf ("%d units\n", n);
END
-END OneSecond ;
+END OneUnit ;
(*
- FourSeconds -
+ FourUnits -
*)
-PROCEDURE FourSeconds ;
+PROCEDURE FourUnits ;
VAR
n: CARDINAL ;
BEGIN
@@ -62,23 +66,23 @@ BEGIN
printf ("4 seconds process has come to life\n");
n := 0 ;
LOOP
- Sleep (4*TicksPerSecond) ;
+ Sleep (4*TicksPerTimeUnit) ;
INC (n) ;
- printf ("4 second alarm (%d occurance)\n", n);
+ printf ("4 units alarm (%d occurance)\n", n);
END
-END FourSeconds ;
+END FourUnits ;
(*
- SixSeconds -
+ SixUnits -
*)
-PROCEDURE SixSeconds ;
+PROCEDURE SixUnits ;
VAR
n: CARDINAL ;
BEGIN
OldInts := TurnInterrupts (MAX (PROTECTION)) ;
- printf ("6 seconds process has come to life\n");
+ printf ("6 units process has come to life\n");
n := 0 ;
LOOP
Timeout := ArmEvent (6*TicksPerSecond) ;
@@ -87,10 +91,10 @@ BEGIN
WriteString ('...someone cancelled it...')
ELSE
INC (n) ;
- printf ("6 second alarm (%d occurance)\n", n)
+ printf ("6 unit alarm (%d occurance)\n", n)
END
END
-END SixSeconds ;
+END SixUnits ;
CONST
@@ -107,10 +111,10 @@ BEGIN
printf ("now to create three processes...\n") ;
- p1 := Resume (InitProcess (OneSecond , StackSize, '1')) ;
- p4 := Resume (InitProcess (FourSeconds, StackSize, '4')) ;
- p6 := Resume (InitProcess (SixSeconds , StackSize, '6')) ;
+ p1 := Resume (InitProcess (OneUnit , StackSize, '1')) ;
+ p4 := Resume (InitProcess (FourUnits, StackSize, '4')) ;
+ p6 := Resume (InitProcess (SixUnits , StackSize, '6')) ;
- Sleep (20*TicksPerSecond) ;
+ Sleep (20*TicksPerTimeUnit) ;
printf ("successfully completed, finishing now.\n")
END testtime.
[patch, fortran] PR107397 ICE in gfc_arith_plus, at fortran/arith.cc:654
Hi all,
The attached patch fixes a regression and is a patch from Steve. I have
regression tested it and provided a test case. It is fairly simple and
I will commit under the "simple" rule in a little while.
Thanks Steve for Patch. Thanks Harald for helping me get back up to
speed on the git magic.
Regards,
Jerry
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..1562dc22bc6 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2221,6 +2221,14 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
sym->ts.f90_type = init->ts.f90_type;
}
+ /* Catch the case: type(t), parameter :: x = z'1'. */
+ if (sym->ts.type == BT_DERIVED && init->ts.type == BT_BOZ)
+ {
+ gfc_error ("Entity %qs at %L is incompatible with a BOZ "
+ "literal constant", name, &sym->declared_at);
+ return false;
+ }
+
/* Add initializer. Make sure we keep the ranks sane. */
if (sym->attr.dimension && init->rank == 0)
{
diff --git a/gcc/testsuite/gfortran.dg/pr107397.f90 b/gcc/testsuite/gfortran.dg/pr107397.f90
new file mode 100644
index 000..4592a275e70
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107397.f90
@@ -0,0 +1,9 @@
+!{ dg-do compile }
+!
+program p
+ type t
+real :: a = 1.0
+ end type
+ type(t), parameter :: x = z'1' ! { dg-error "incompatible with BOZ" }
+ x%a = x%a + 2 ! { dg-error "has no IMPLICIT type"}
+end
Re: [PATCH RFA] gimplify: avoid unnecessary copy of init array [PR105838]
On 12/8/22 15:01, Jason Merrill via Gcc-patches wrote: After the previous patches, I noticed that we were putting the array of strings into .rodata, but then memcpying it into an automatic array, which is pointless; we should be able to use it directly. C++ doesn't allow us to do this for the backing array of an initializer_list, but should be able to do it for the implementation detail array we use to construct the backing array. This doesn't happen automatically because TREE_ADDRESSABLE is set, and gimplify_init_constructor uses that to decide whether to promote a variable to static. Ideally this could use escape analysis to recognize that the address, though taken, never leaves the function; that should allow promotion when we're only using the address for indexing within the function, as in initlist-opt2.C. But in initlist-opt1.C, we're passing the array address to another function, so it definitely escapes; it's only safe in this case because it's calling a standard library function that we know only uses it for indexing. So, a flag seems needed. I first thought to put the flag on the TARGET_EXPR, but the VAR_DECL seems more appropriate. Bikeshedding, or other approaches, welcome. PR c++/105838 gcc/ChangeLog: * tree.h (DECL_NOT_OBSERVABLE): New. * tree-core.h (struct tree_decl_common): Mention it. * gimplify.cc (gimplify_init_constructor): Check it. gcc/cp/ChangeLog: * call.cc (maybe_init_list_as_array): Set DECL_NOT_OBSERVABLE. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/initlist-opt1.C: Check for static array. * g++.dg/tree-ssa/initlist-opt2.C: Likewise. Presumably the DECL in question isn't actually compiler generated and thus DECL_ARTIFICIAL is not appropriate here. Assuming that's the case, should we be setting DECL_NON_OBSERVABLE on VAR_DECLs with DECL_ARTIFICIAL set? I don't think that needs to be done for this patch to move forward though. There haven't been any objections, so OK. Jeff
[PATCH] rs6000: Add Rust support to traceback table
Use 0 for the "lang" identifier for Rust, just like we do for all other source languages without assigned language code (0 means "C"). Tested on powerpc64-linux. Without this patch there are ICEs galore in the gm2 testsuite for 64-bit Linux targets, and with the ptch there are just a few FAILs. Committed. Segher 2022-12-17 Segher Boessenkool * config/rs6000/rs6000-logue.cc (rs6000_output_function_epilogue): Handle GNU Rust for the tbtab lang field. --- gcc/config/rs6000/rs6000-logue.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/config/rs6000/rs6000-logue.cc b/gcc/config/rs6000/rs6000-logue.cc index 3621cb501c70..669a2583402a 100644 --- a/gcc/config/rs6000/rs6000-logue.cc +++ b/gcc/config/rs6000/rs6000-logue.cc @@ -5350,6 +5350,7 @@ rs6000_output_function_epilogue (FILE *file) || ! strcmp (language_string, "GNU GIMPLE") || ! strcmp (language_string, "GNU Go") || ! strcmp (language_string, "GNU D") + || ! strcmp (language_string, "GNU Rust") || ! strcmp (language_string, "libgccjit")) i = 0; else if (! strcmp (language_string, "GNU F77") -- 1.8.3.1
[PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]
Dear all,
the previous fix for pr103505 introduced a regression that could lead
to wrong array bounds when LBOUND/UBOUND were used in the array spec
of a declaration. The reason was that we tried to simplify too early
the array element spec, which appears to have interfered with the
subtle semantics of the bound intrinsics.
The solution is to undo the fix for pr103505. It turns out that
there are other code changes in place that were put in place to
fix related ICEs, and which handle that one, too, and only lead
to a change of the emitted error diagnostics.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a 10/11/12/13 regression, I would like to backport
as seems fit.
Thanks,
Harald
From 531be0753352ec30c4b1e24591ec3e0c33cd4409 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 17 Dec 2022 22:04:32 +0100
Subject: [PATCH] Fortran: incorrect array bounds when bound intrinsic used in
decl [PR108131]
gcc/fortran/ChangeLog:
PR fortran/108131
* array.cc (match_array_element_spec): Avoid too early simplification
of matched array element specs that can lead to a misinterpretation
when used as array bounds in array declarations.
gcc/testsuite/ChangeLog:
PR fortran/108131
* gfortran.dg/pr103505.f90: Adjust expected patterns.
* gfortran.dg/pr108131.f90: New test.
---
gcc/fortran/array.cc | 4
gcc/testsuite/gfortran.dg/pr103505.f90 | 8 +---
gcc/testsuite/gfortran.dg/pr108131.f90 | 25 +
3 files changed, 30 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr108131.f90
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index 10d9e0c5354..7457c03e6cd 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -512,8 +512,6 @@ match_array_element_spec (gfc_array_spec *as)
if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
return AS_UNKNOWN;
- gfc_try_simplify_expr (*upper, 0);
-
if (((*upper)->expr_type == EXPR_CONSTANT
&& (*upper)->ts.type != BT_INTEGER) ||
((*upper)->expr_type == EXPR_FUNCTION
@@ -546,8 +544,6 @@ match_array_element_spec (gfc_array_spec *as)
if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
return AS_UNKNOWN;
- gfc_try_simplify_expr (*upper, 0);
-
if (((*upper)->expr_type == EXPR_CONSTANT
&& (*upper)->ts.type != BT_INTEGER) ||
((*upper)->expr_type == EXPR_FUNCTION
diff --git a/gcc/testsuite/gfortran.dg/pr103505.f90 b/gcc/testsuite/gfortran.dg/pr103505.f90
index 522e53efcb2..01308019b2c 100644
--- a/gcc/testsuite/gfortran.dg/pr103505.f90
+++ b/gcc/testsuite/gfortran.dg/pr103505.f90
@@ -3,7 +3,9 @@
! Testcase by G.Steinmetz
program p
- integer, parameter :: a((2.)) = [4,8] ! { dg-error "scalar INTEGER" }
- integer, parameter :: z(1:(2.)) = [4,8] ! { dg-error "scalar INTEGER" }
- print *, a(1:1) ! { dg-error "Syntax error" }
+ integer, parameter :: a((2.)) = [4,8] ! { dg-error "INTEGER type" }
+ integer, parameter :: z(1:(2.)) = [4,8] ! { dg-error "INTEGER type" }
+ print *, a(1:1)
end
+
+! { dg-prune-output "Parameter array" }
diff --git a/gcc/testsuite/gfortran.dg/pr108131.f90 b/gcc/testsuite/gfortran.dg/pr108131.f90
new file mode 100644
index 000..4a3c467f73a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108131.f90
@@ -0,0 +1,25 @@
+! { dg-do run }
+! { dg-additional-options "-fdump-tree-original" }
+! PR fortran/108131
+!
+! Incorrect array bounds when bound intrinsic used in declaration
+
+program test
+ implicit none
+ integer, parameter :: mg(7:10) = 0
+ integer, parameter :: u = ubound(mg, dim=1)
+ integer, parameter :: cx(-1:ubound(mg, dim=1)) = 1
+ integer, parameter :: dx(lbound(mg, dim=1):ubound(mg, dim=1)) = 2
+
+ write(*,*) ubound(mg, dim=1)
+ write(*,*) ubound(cx, dim=1)
+ if (u /= 10) stop 1
+ if (ubound(mg, dim=1) /= 10) stop 2
+ if (ubound(cx, dim=1) /= 10) stop 3
+ if (ubound(dx, dim=1) /= 10) stop 4
+ if (lbound(mg, dim=1) /= 7) stop 5
+ if (lbound(cx, dim=1) /= -1) stop 6
+ if (lbound(dx, dim=1) /= 7) stop 7
+end program test
+
+! { dg-final { scan-tree-dump-not "_gfortran_stop_numeric" "original" } }
--
2.35.3
[r13-4716 Regression] FAIL: libgomp.fortran/allocate-4.f90 -O (test for excess errors) on Linux/x86_64
On Linux/x86_64,
e205ec03f0794aeac3e8a89e947c12624d5a274e is the first bad commit
commit e205ec03f0794aeac3e8a89e947c12624d5a274e
Author: Tobias Burnus
Date: Thu Dec 15 12:25:07 2022 +0100
libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only
code [PR108056]
caused
FAIL: libgomp.fortran/allocate-4.f90 -O (test for errors, line 19)
FAIL: libgomp.fortran/allocate-4.f90 -O (test for errors, line 25)
FAIL: libgomp.fortran/allocate-4.f90 -O (test for errors, line 31)
FAIL: libgomp.fortran/allocate-4.f90 -O (test for errors, line 34)
FAIL: libgomp.fortran/allocate-4.f90 -O (test for errors, line 37)
FAIL: libgomp.fortran/allocate-4.f90 -O (test for errors, line 40)
FAIL: libgomp.fortran/allocate-4.f90 -O (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-4716/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="fortran.exp=libgomp.fortran/allocate-4.f90
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="fortran.exp=libgomp.fortran/allocate-4.f90
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="fortran.exp=libgomp.fortran/allocate-4.f90
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="fortran.exp=libgomp.fortran/allocate-4.f90
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com)
[r13-4727 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ] on Linux/x86_64
On Linux/x86_64,
12abd5a7d13209f79664ea603b3f3517f71b8c4f is the first bad commit
commit 12abd5a7d13209f79664ea603b3f3517f71b8c4f
Author: Vladimir N. Makarov
Date: Thu Dec 15 14:11:05 2022 -0500
IRA: Check that reg classes contain a hard reg of given mode in reg move
cost calculation
caused
FAIL: 20_util/to_chars/float16_c++23.cc execution test
FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-4727/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=20_util/to_chars/float16_c++23.cc
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=20_util/to_chars/float16_c++23.cc
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr64110.c --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr64110.c --target_board='unix{-m32\
-march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com)
[r13-4749 Regression] FAIL: gcc.dg/ira-loop-pressure.c scan-rtl-dump loop2_invariant "Decided to move invariant" on Linux/x86_64
On Linux/x86_64,
b50fe16a3b2214c418ecc5febc0bb21bc17912b7 is the first bad commit
commit b50fe16a3b2214c418ecc5febc0bb21bc17912b7
Author: Vladimir N. Makarov
Date: Fri Dec 16 13:16:31 2022 -0500
Revert "IRA: Check that reg classes contain a hard reg of given mode in reg
move cost calculation"
caused
FAIL: gcc.dg/ira-loop-pressure.c scan-rtl-dump loop2_invariant "Decided to move
invariant"
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-4749/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=gcc.dg/ira-loop-pressure.c --target_board='unix{-m64\
-march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com)
