Re: Go patch committed: Update libgo to 1.1.1
On 07/16/2013 08:55 AM, Ian Lance Taylor wrote: I have committed a large patch to update libgo to the library that was part of the Go 1.1.1 release. As usual, I'm not including the entire patch in this e-mail message, because it is too large. I'm only including the changes to the files that are partially gccgo-specific. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.8 branch. I think this change at least needs a soname bump: Index: libgo/go/encoding/xml/xml.go === --- libgo/go/encoding/xml/xml.go(revision 200973) +++ libgo/go/encoding/xml/xml.go(revision 200974) @@ -169,6 +169,11 @@ // the CharsetReader's result values must be non-nil. CharsetReader func(charset string, input io.Reader) (io.Reader, error) + // DefaultSpace sets the default name space used for unadorned tags, + // as if the entire XML stream were wrapped in an element containing + // the attribute xmlns="DefaultSpace". + DefaultSpace string + r io.ByteReader buf bytes.Buffer saved *bytes.Buffer The size of the public Decoder struct changes, and this size has been compiled into client code. -- Florian Weimer / Red Hat Product Security Team
Re: [PATCH] Fix pr57637
On 11 July 2013 18:31, Eric Botcazou wrote: >> Shrink-wrap optimization sinks some instructions for more >> opportunities. It uses DF_LR_BB_INFO (bb)->def to check whether BB >> clobbers SRC. But for ARM, gcc might generate cond_exec insns before >> shrink-wrapping. And DF_LR_BB_INFO (bb)->def does not include def info >> from cond_exec insns. So the check in function >> move_insn_for_shrink_wrap is not enough. > > Posting a testcase would be even better, but the analysis looks plausible. > DF_REF_CONDITIONAL and DF_REF_PARTIAL defs aren't killing defs so they are not > included in the def set for LR. > > As you pointed out, they are included in the gen set for LIVE if it exists, so > I guess we should wonder if we really want to do the scanning if LIVE doesn't > exist, i.e. at -O1, instead of simply giving up. In any case, the scanning Thanks. The patch is updated based the comments: it will check GEN set of LIVE if df_live exists. Otherwise, just give up. And a testcase is included in the attached patch. -Zhenqiang > doesn't need to be redundant with the previous work, so: > > if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL))) > continue; > > is missing in the patch. > > -- > Eric Botcazou pr57637-updated.patch Description: Binary data
[PATCH] Update configure{.ac,} from binutils
Hi! A small patch was missing from binutils configury, which I just synced: 2013-07-16 Jan-Benedict Glaw * configure.ac: Sync from binutils. * configure: Regenerate. Index: configure === --- configure (revision 200975) +++ configure (working copy) @@ -3762,10 +3762,14 @@ noconfigdirs="$noconfigdirs gprof target-libgloss" ;; mips*-*-bsd*) -noconfigdirs="$noconfigdirs gprof target-libgloss" +noconfigdirs="$noconfigdirs ld gas gprof target-libgloss" ;; mips*-*-linux*) ;; + mips*-*-ultrix* | mips*-*-osf* | mips*-*-ecoff* | mips*-*-pe* \ + | mips*-*-irix* | mips*-*-lnews* | mips*-*-riscos*) +noconfigdirs="$noconfigdirs ld gas gprof" +;; mips*-*-*) noconfigdirs="$noconfigdirs gprof" ;; Index: configure.ac === --- configure.ac(revision 200975) +++ configure.ac(working copy) @@ -1101,10 +1101,14 @@ noconfigdirs="$noconfigdirs gprof target-libgloss" ;; mips*-*-bsd*) -noconfigdirs="$noconfigdirs gprof target-libgloss" +noconfigdirs="$noconfigdirs ld gas gprof target-libgloss" ;; mips*-*-linux*) ;; + mips*-*-ultrix* | mips*-*-osf* | mips*-*-ecoff* | mips*-*-pe* \ + | mips*-*-irix* | mips*-*-lnews* | mips*-*-riscos*) +noconfigdirs="$noconfigdirs ld gas gprof" +;; mips*-*-*) noconfigdirs="$noconfigdirs gprof" ;; -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Eine Freie Meinung in einem Freien Kopf the second : für einen Freien Staat voll Freier Bürger. signature.asc Description: Digital signature
Re: [PATCH] S/390: Hardware transactional memory support
On Tue, Jul 16, 2013 at 1:24 AM, Jakub Jelinek wrote: > On Mon, Jul 15, 2013 at 10:40:04PM -0500, Peter Bergner wrote: >> On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote: >> > On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner >> > wrote: >> > > David, do you prefer reverting the above hunk from the Power HTM >> > > patch or should I add the associated -mno-* options to the building >> > > of libitm? >> > >> > How is libitm built for Intel? The principle of least surprises >> > suggests following that precedent. >> >> They use -mrtm (like we use -mhtm) to build libitm, but it looks like >> their -mrtm does not enable any other isa flags like we currently are >> doing with -mhtm. Meaning their -mrtm option is independent of any >> -mcpu values while ours is not. If we revert the patch I mentioned, >> then I think we will match what Intel is doing. >> Hopefully Jakub will correct me if I am wrong. > > Yes, that is my understanding of it too. On Intel we have: > #define OPTION_MASK_ISA_RTM_SET OPTION_MASK_ISA_RTM > #define OPTION_MASK_ISA_RTM_UNSET OPTION_MASK_ISA_RTM > which means that -mrtm doesn't set any other options except for itself > and -mno-rtm doesn't reset other options. libitm is built with -mrtm, > assuming that the only thing the -mrtm switch affects are the HTM builtins > and that those will only be found explicitly in code guarded with the > htm_available () runtime check. > Right now, -mhtm on PowerPC basically implies -march=power8 if I understand > the code well, and libitm is built with it, which means essentially that > when gcc is configured for a pre-power8 CPU, libitm will work just fine on > power8 (including HTM support), but when running on power7 and earlier > it might very well SIGILL, because the implicit -march=power8 could affect > even code not guarded by htm_available (). > And on s/390, right now we enable HTM support in libitm when configured for > -march=zEC12 by default (which isn't ideal). Then I agree that the hunk should be reverted so that HTM does not imply POWER8. Thanks, David
Re: Go patch committed: Update libgo to 1.1.1
Hello! > I have committed a large patch to update libgo to the library that was > part of the Go 1.1.1 release. As usual, I'm not including the entire > patch in this e-mail message, because it is too large. I'm only > including the changes to the files that are partially gccgo-specific. > Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. > Committed to mainline and 4.8 branch. I have hit following build failure on non-USING_SPLIT_STACK target (alpha-linux-gnu): ../../../gcc-svn/trunk/libgo/runtime/proc.c: In function ‘runtime_entersyscall’: ../../../gcc-svn/trunk/libgo/runtime/proc.c:1669:27: error: ‘v’ undeclared (first use in this function) g->gcnext_sp = (byte *) &v; ^ ../../../gcc-svn/trunk/libgo/runtime/proc.c:1669:27: note: each undeclared identifier is reported only once for each function it appears in ../../../gcc-svn/trunk/libgo/runtime/proc.c: In function ‘runtime_entersyscallblock’: ../../../gcc-svn/trunk/libgo/runtime/proc.c:1716:27: error: ‘v’ undeclared (first use in this function) g->gcnext_sp = (byte *) &v; ^ make[4]: *** [proc.lo] Error 1 make[4]: *** Waiting for unfinished jobs Uros.
[ARM][Insn classification refactoring 4/N] Cleanup "insn" attribute
Hi, This patch is the part of the ongoing work of ARM instruction classification cleanup. This patch deletes redundant values "mrs", "msr", "xtab" and "sat" from the "insn" attribute, and moves the "clz" value to the "type" attribute. The remaining values "mov" and "mvn" will be dealt with in a separate patch. This has been tested with a full arm-none-eabi toolchain build and regression run, as well as using random code generation tests to compare the output versus a baseline compiler. OK for trunk? Thanks Sofiane arm-clear-insn-attr.diff Description: Binary data
[PATCH] MIPS: Remove VR54xx NMADD.fmt/NMADD.fmt control breakage
On Thu, 21 Feb 2013, Richard Sandiford wrote:
> > Finally, while at it, I found it interesting that we have separate
> > conditions to cover MADD.fmt/MSUB.fmt (ISA_HAS_FP_MADD4_MSUB4) and
> > NMADD.fmt/NMADD.fmt (ISA_HAS_NMADD4_NMSUB4) while all the four
> > instructions need to be implemented as a whole group per data format
> > supported and cannot be separated (the MIPS architecture specification
> > explicitly forbids subsetting). The difference between the two conditions
> > is the former expands to ISA_HAS_FP4, that is enables the subsubset for
> > any MIPS IV and up FPU while the latter has an extra "&& (!TARGET_MIPS5400
> > || TARGET_MAD)" qualifier.
> >
> > I went ahead and checked available NEC VR54xx documentation and here's
> > what I came up with:
> >
> > 1. "VR5400 MIPS RISC Microprocessor Family" datasheet (NEC doc #13362)
> >says:
> >
> >"The VR5400 processor family complies with the MIPS IV instruction set
> >and IEEE-754 floating-point and IEEE-1149.1/1149.1a JTAG specification,
> >[...]"
> >
> > 2. "VR5432 MIPS RISC Microprocessor User's Manual, Volume 2" (NEC doc
> >#13751) lists all the individual MADD.fmt, MSUB.fmt, NMADD.fmt and
> >NMSUB.fmt instructions in Chapter 18 "Floating-Point Unit Instruction
> >Set" with no restrictions as to their availability (the only other
> >member of the VR54xx family I know of is the VR5464 that is a
> >high-performance version of the VR5432 and is fully software
> >compatible).
> >
> > Further to that TARGET_MAD controls whether to "Use PMC-style 'mad'
> > instructions" that are all CPU rather than FPU instructions. The VR5432
> > indeed supports extra integer multiply-accumulate instructions, as
> > documented in #2 above; these are the MACC/MACCHI/MACCHIU/MACCU and
> > MSAC/MSACHI/MSACHIU/MSACU instructions as roughly covered by our
> > ISA_HAS_MACC, ISA_HAS_MSAC and ISA_HAS_MACCHI knobs (the latter is not
> > implied for TARGET_MIPS5400, perhaps because the family does not support
> > the doubleword variants).
> >
> > All in all it looks to me like a misplaced hunk. It was introduced in
> > rev. 56471 (you were named as one of the contributors on that commit, so
> > you may be able to remember and/or correct me if I am wrong here anywhere)
> > and it looks to me it should have been applied to the ISA_HAS_MADD_MSUB
> > macro instead that's still just a few lines above ISA_HAS_NMADD4_NMSUB4
> > (and was even closer to ISA_HAS_NMADD_NMSUB as the latter was then called;
> > the bodies were close enough back then for a hunk to apply cleanly to
> > either).
>
> I was named in that commit but the VR54xx stuff wasn't mine. I do remember
> that Mike put a lot of effort into tuning the VR54xx madd stuff though,
> because of the difficulty of having multiply-accumulate instructions
> that force the use of HI/LO on an architecture that also has efficient
> three-operand multiplies. So I'm pretty sure that this worked correctly
> in the Cygnus devo tree, and your explanation of a misplaced hunk seems
> very convincing.
Here's a change to remove this hunk as obviously inappropriate for
ISA_HAS_NMADD4_NMSUB4. Also AFAICT all integer multiply-accumulate
control for the VR54xx is done via the ISA_HAS_MACC and ISA_HAS_MSAC
rather than ISA_HAS_MADD_MSUB. The latter is only used to control MIPS
architecture multiply-accumulate instructions. See the `macc', `msac',
`mul_acc_si', `mul_sub_si', `maddsidi4' and `msubsidi4' patterns.
My conclusion therefore is there is no point in trying to fit this code to
ISA_HAS_MADD_MSUB, it's just not relevant there. It might go with
ISA_HAS_MACC and ISA_HAS_MSAC instead, but 11 years on I think it's simply
safer just to discard it entirely.
The hunk only seems to have slipped through, probably from an earlier
development version, because of its limited impact -- while disabling
NMADD.fmt and NMSUB.fmt for the VR54xx can result in a performance hit
it's by no means fatal.
I'm not sure how to test this change beyond making sure it builds (it
does, for the mips-linux-gnu target at least). I don't have a VR54xx
system available. OK to apply?
2013-07-16 Maciej W. Rozycki
gcc/
* config/mips/mips.h (ISA_HAS_NMADD4_NMSUB4): Remove
TARGET_MIPS5400 checking.
Maciej
gcc-mips-mad-5400.diff
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.h
===
--- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.h 2013-07-13
00:13:02.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/config/mips/mips.h 2013-07-13 00:47:48.490937673
+0100
@@ -915,7 +915,6 @@ struct mips_cpu_info {
|| (ISA_MIPS32R2 && (MODE) == V2SFmode) \
|| ISA_MIPS64 \
|| ISA_MIPS64R2) \
-&& (!TARGET_MIPS5400 || TARGET
[PATCH v2] MIPS: MIPS32r2 FP MADD instruction set support
On Wed, 27 Feb 2013, Maciej W. Rozycki wrote:
> > Maciej, in that case, the rest of the patch is OK for 4.9, thanks.
>
> I will apply in due course then, thanks for your review.
Regrettably after further investigation I have realised the change I
proposed inadvertently enables more than just the FP MADD instruction set.
It also enables the FP indexed memory access instructions. While that
itself is not a bad change, it will better be discussed separately.
Here's a new version that does not enable anything beyond the FP MADD
instruction set. While making this update I also noticed and fixed a
place in mips_rtx_costs where ISA_HAS_FP4 was used where ISA_HAS_FP_MADD*
should be.
I have regression-tested this change with the mips-linux-gnu target and
the mips32r2/o32 multilib. I have also verified that the instructions
affected were absent across the binaries produced by the testsuite before
applying this change and present afterwards. For some reason only MADD.S,
MADD.D, MSUB.S and MSUB.D instructions were produced though -- it looks
like none of NMADD.S, NMADD.D, NMSUB.S and NMSUB.D instructions has
coverage in our testsuite.
I have also verified no FP indexed memory access instructions were
produced whether with or without the patch applied. And for safety I have
also likewise checked the reciprocals that I'll handle separately as well.
OK to apply?
2013-07-16 Maciej W. Rozycki
gcc/
* config/mips/mips.h (ISA_HAS_FP4): Correct formatting.
(ISA_HAS_FP_MADD4_MSUB4): Also enable for ISA_MIPS32R2.
(ISA_HAS_NMADD4_NMSUB4): Remove the MODE argument; rewrite in
terms of ISA_HAS_FP4, and also enable for ISA_MIPS32R2.
(ISA_HAS_NMADD3_NMSUB3): Remove the MODE argument.
* config/mips/mips.c (mips_rtx_costs) : Check for
ISA_HAS_FP_MADD4_MSUB4 || ISA_HAS_FP_MADD3_MSUB3 rather than
ISA_HAS_FP4.
: Update according to changes to ISA_HAS_NMADD4_NMSUB4
and ISA_HAS_NMADD3_NMSUB3.
* config/mips/mips.md (nmadd4, nmadd3): Likewise.
(nmadd4_fastmath, nmadd3_fastmath): Likewise.
(nmsub4, nmsub3): Likewise.
(nmsub4_fastmath, nmsub3_fastmath): Likewise.
Maciej
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.c 2013-07-13
00:59:53.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/config/mips/mips.c 2013-07-13 01:24:21.590274806
+0100
@@ -3857,7 +3857,7 @@ mips_rtx_costs (rtx x, int code, int out
case MINUS:
if (float_mode_p
- && (ISA_HAS_NMADD4_NMSUB4 (mode) || ISA_HAS_NMADD3_NMSUB3 (mode))
+ && (ISA_HAS_NMADD4_NMSUB4 || ISA_HAS_NMADD3_NMSUB3)
&& TARGET_FUSED_MADD
&& !HONOR_NANS (mode)
&& !HONOR_SIGNED_ZEROS (mode))
@@ -3890,7 +3890,7 @@ mips_rtx_costs (rtx x, int code, int out
{
/* If this is part of a MADD or MSUB, treat the PLUS as
being free. */
- if (ISA_HAS_FP4
+ if ((ISA_HAS_FP_MADD4_MSUB4 || ISA_HAS_FP_MADD3_MSUB3)
&& TARGET_FUSED_MADD
&& GET_CODE (XEXP (x, 0)) == MULT)
*total = 0;
@@ -3909,7 +3909,7 @@ mips_rtx_costs (rtx x, int code, int out
case NEG:
if (float_mode_p
- && (ISA_HAS_NMADD4_NMSUB4 (mode) || ISA_HAS_NMADD3_NMSUB3 (mode))
+ && (ISA_HAS_NMADD4_NMSUB4 || ISA_HAS_NMADD3_NMSUB3)
&& TARGET_FUSED_MADD
&& !HONOR_NANS (mode)
&& HONOR_SIGNED_ZEROS (mode))
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.h
===
--- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.h 2013-07-13
00:59:53.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/config/mips/mips.h 2013-07-13 01:12:22.560918747
+0100
@@ -881,7 +881,7 @@ struct mips_cpu_info {
FP madd and msub instructions, and the FP recip and recip sqrt
instructions. */
#define ISA_HAS_FP4((ISA_MIPS4 \
- || (ISA_MIPS32R2 && TARGET_FLOAT64) \
+ || (ISA_MIPS32R2 && TARGET_FLOAT64) \
|| ISA_MIPS64 \
|| ISA_MIPS64R2) \
&& !TARGET_MIPS16)
@@ -903,24 +903,20 @@ struct mips_cpu_info {
#define GENERATE_MADD_MSUB (TARGET_IMADD && !TARGET_MIPS16)
/* ISA has floating-point madd and msub instructions 'd = a * b [+-] c'. */
-#define ISA_HAS_FP_MADD4_MSUB4 ISA_HAS_FP4
+#define ISA_HAS_FP_MADD4_MSUB4 (ISA_HAS_FP4 \
+|| (ISA_MIPS32R2 && !TARGET_MIPS16))
/* ISA has floating-point madd and msub instructions 'c = a * b [+-] c'. */
#define ISA_HAS_FP_MADD3_MSUB3 TARGET_LOONGSON_2EF
/* ISA has floating-point nmadd and nmsub ins
RE: [AArch64] Convert ld1, st1 arm_neon.h intrinsics to RTL builtins.
Ping? > -Original Message- > From: James Greenhalgh > Sent: 04 July 2013 09:18 > To: gcc-patches@gcc.gnu.org > Cc: Marcus Shawcroft > Subject: RE: [AArch64] Convert ld1, st1 arm_neon.h intrinsics to RTL > builtins. > > > > > 2013-07-02 James Greenhalgh > > > > > > * config/aarch64/aarch64-builtins.c > > > (aarch64_simd_expand_builtin): Handle AARCH64_SIMD_STORE1. > > > * config/aarch64/aarch64-simd-builtins.def (ld1): New. > > > (st1): Likewise. > > > * config/aarch64/aarch64-simd.md > > > (aarch64_ld1): New. > > > (aarch64_st1): Likewise. > > > * config/aarch64/arm_neon.h > > > (vld1_<8, 16, 32, 64>): Convert to RTL builtins. > > > > > > > OK > > /Marcus > > Thanks Marcus, > > I've committed this as r200634. > > As this is a bug-fix I'd like to backport it to the 4.8 branch. > I've attached a copy of the patch that applies to 4.8 > and run it through testing on aarch64-none-elf with no issues. > > Is this OK to commit to gcc-4_8-branch? > > Thanks, > James > > --- > gcc/ > > 2013-07-04 James Greenhalgh > > Backport From mainline: > 2013-07-03 James Greenhalgh > > * config/aarch64/aarch64-builtins.c > (aarch64_simd_expand_builtin): Handle AARCH64_SIMD_STORE1. > * config/aarch64/aarch64-simd-builtins.def (ld1): New. > (st1): Likewise. > * config/aarch64/aarch64-simd.md > (aarch64_ld1): New. > (aarch64_st1): Likewise. > * config/aarch64/arm_neon.h > (vld1_<8, 16, 32, 64>): Convert to RTL builtins.
Re: [AArch64] Convert ld1, st1 arm_neon.h intrinsics to RTL builtins.
On 04/07/13 09:17, James Greenhalgh wrote: I've committed this as r200634. As this is a bug-fix I'd like to backport it to the 4.8 branch. I've attached a copy of the patch that applies to 4.8 and run it through testing on aarch64-none-elf with no issues. Is this OK to commit to gcc-4_8-branch? OK /Marcus
[PATCH] GOMP_CPU_AFFINITY fails with >1024 cores
Jakub et al, Steffen has developed a nice fix [1] for GOMP_CPU_AFFINITY failing with >1024 cores. What steps are needed to get this into GCC 4.8.2? Thanks, Daniel [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57298 -- Daniel J Blueman Principal Software Engineer, Numascale
Re: [PATCH] S/390: Hardware transactional memory support
On Tue, 2013-07-16 at 08:08 -0400, David Edelsohn wrote: > Then I agree that the hunk should be reverted so that HTM does not imply > POWER8. Ok, I'll bootstrap and regtest just to be sure there is no unintended fallout for such a small path before committing. Thanks. Peter
[Patch, Fortran] PR57894 - MIN/MAX arg= check
As reported in the PR, gfortran was lacking a check for the args= for
MIN/MAX. Those are special as they accept 'infinitely' many arguments -
while others have a finite set.
Added checks:
- Ensure that only a1=, a2=, a3= etc. is used.
- Ensure that every argument occurs only once
- ensure that the first two arguments (a1=, a2= when keywords are used)
are always present
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-07-16 Tobias Burnus
PR fortran/57894
* check.c (min_max_args): Add keyword= check.
2013-07-16 Tobias Burnus
PR fortran/57894
* gfortran.dg/min_max_conformance_2.f90: New.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 4024cd4..492c8ec 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -2328,16 +2328,85 @@ gfc_check_logical (gfc_expr *a, gfc_expr *kind)
/* Min/max family. */
static bool
-min_max_args (gfc_actual_arglist *arg)
+min_max_args (gfc_actual_arglist *args)
{
- if (arg == NULL || arg->next == NULL)
+ gfc_actual_arglist *arg;
+ int i, j, nargs, *nlabels, nlabelless;
+ bool a1 = false, a2 = false;
+
+ if (args == NULL || args->next == NULL)
{
gfc_error ("Intrinsic '%s' at %L must have at least two arguments",
gfc_current_intrinsic, gfc_current_intrinsic_where);
return false;
}
+ if (!args->name)
+a1 = true;
+
+ if (!args->next->name)
+a2 = true;
+
+ nargs = 0;
+ for (arg = args; arg; arg = arg->next)
+if (arg->name)
+ nargs++;
+
+ if (nargs == 0)
+return true;
+
+ /* Note: Having a keywordless argument after an "arg=" is checked before. */
+ nlabelless = 0;
+ nlabels = XALLOCAVEC (int, nargs);
+ for (arg = args, i = 0; arg; arg = arg->next, i++)
+if (arg->name)
+ {
+int n;
+char *endp;
+
+ if (arg->name[0] != 'a' || arg->name[1] < '1' || arg->name[1] > '9')
+ goto unknown;
+n = strtol (&arg->name[1], &endp, 10);
+if (endp[0] != '\0')
+ goto unknown;
+if (n <= 0)
+ goto unknown;
+if (n <= nlabelless)
+ goto duplicate;
+nlabels[i] = n;
+ if (n == 1)
+ a1 = true;
+ if (n == 2)
+ a2 = true;
+ }
+else
+ nlabelless++;
+
+ if (!a1 || !a2)
+{
+ gfc_error ("Missing '%s' argument to the %s intrinsic at %L",
+ !a1 ? "a1" : "a2", gfc_current_intrinsic,
+ gfc_current_intrinsic_where);
+ return false;
+}
+
+ /* Check for duplicates. */
+ for (i = 0; i < nargs; i++)
+for (j = i + 1; j < nargs; j++)
+ if (nlabels[i] == nlabels[j])
+ goto duplicate;
+
return true;
+
+duplicate:
+ gfc_error ("Duplicate argument '%s' at %L to intrinsic %s", arg->name,
+ &arg->expr->where, gfc_current_intrinsic);
+ return false;
+
+unknown:
+ gfc_error ("Unknown argument '%s' at %L to intrinsic %s", arg->name,
+ &arg->expr->where, gfc_current_intrinsic);
+ return false;
}
@@ -2345,7 +2414,6 @@ static bool
check_rest (bt type, int kind, gfc_actual_arglist *arglist)
{
gfc_actual_arglist *arg, *tmp;
-
gfc_expr *x;
int m, n;
diff --git a/gcc/testsuite/gfortran.dg/min_max_conformance_2.f90 b/gcc/testsuite/gfortran.dg/min_max_conformance_2.f90
new file mode 100644
index 000..085206c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/min_max_conformance_2.f90
@@ -0,0 +1,24 @@
+! { dg-do compile }
+!
+! PR fortran/57894
+!
+! Contributed by Vittorio Zecca
+!
+print *, max(a2=2,a65=45,a2=5) ! { dg-error "has already appeared in the current argument list" }
+print *, min(a1=2.0,a65=45.0,a2=5.0e0) ! OK
+print *, max(a2=2,a65=45,a3=5) ! { dg-error "Missing 'a1' argument to the max intrinsic" }
+print *, min(a1=2.0,a65=45.0,a3=5.0e0) ! { dg-error "Missing 'a2' argument to the min intrinsic" }
+print *, min1(2.0,a1=45.0,a2=5.0e0) ! { dg-error "Duplicate argument 'a1'" }
+
+print *, max0(a1=2,a65a=45,a2=5) ! { dg-error "Unknown argument 'a65a'" }
+print *, amax0(a1=2,as65=45,a2=5) ! { dg-error "Unknown argument 'as65'" }
+print *, max1(a1=2,a2=45,5) ! { dg-error "Missing keyword name in actual argument list" }
+print *, amax1(a1=2,a3=45,a4=5) ! { dg-error "Missing 'a2' argument" }
+print *, dmax1(a1=2,a2=45,a4z=5) ! { dg-error "Unknown argument 'a4z'" }
+
+print *, min0(a1=2,a65a=45,a2=5) ! { dg-error "Unknown argument 'a65a'" }
+print *, amin0(a1=2,as65=45,a2=5) ! { dg-error "Unknown argument 'as65'" }
+print *, min1(a1=2,a2=45,5) ! { dg-error "Missing keyword name in actual argument list" }
+print *, amin1(a1=2,a3=45,a4=5) ! { dg-error "Missing 'a2' argument" }
+print *, dmin1(a1=2,a2=45,a4z=5) ! { dg-error "Unknown argument 'a4z'" }
+end
! { dg-do compile }
! Test the fix for PR20896 in which the ambiguous use
! of p was not detected.
!
! Contributed by Joost VandeVondele
!
INTERFACE g
SUBROUTINE s1(p) ! { dg-error "is already being used" }
INTERFACE
SUBROUTINE p
END
END INTERFACE
END
SUBROUTINE s2(p) ! { dg-error "Global name" }
INTERFACE
RE
Re: [Patch, Fortran] PR57894 - MIN/MAX arg= check
Tobias Burnus wrote:
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Scratch the second test case / second attachment ("fiif.f90"), which
wasn't supposed to get attached.
(If you wonder, it's Joost's/Dominique's test case, reated to
PR39290/PR40276, cf.
http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html. The test is now
rejected by my PR40276/PR57711 patch - but I fear for the wrong reasons:
While the interface is ambiguous, the current patch only rejects the
use. I have to check whether the check could also reject valid use - or
only gives the slightly puzzling error for invalid use. In any case, the
ambiguity check has to be corrected [long standing issue].)
Tobias
Re: Go patch committed: Update libgo to 1.1.1
On Tue, Jul 16, 2013 at 12:33 AM, Florian Weimer wrote: > On 07/16/2013 08:55 AM, Ian Lance Taylor wrote: >> >> I have committed a large patch to update libgo to the library that was >> part of the Go 1.1.1 release. As usual, I'm not including the entire >> patch in this e-mail message, because it is too large. I'm only >> including the changes to the files that are partially gccgo-specific. >> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. >> Committed to mainline and 4.8 branch. > > > I think this change at least needs a soname bump: Thanks. I already bumped the soname for the change in the way that functions are represented. The next releases will have different sonames. Ian
Re: Go patch committed: Update libgo to 1.1.1
On Tue, Jul 16, 2013 at 6:07 AM, Uros Bizjak wrote: > >> I have committed a large patch to update libgo to the library that was >> part of the Go 1.1.1 release. As usual, I'm not including the entire >> patch in this e-mail message, because it is too large. I'm only >> including the changes to the files that are partially gccgo-specific. >> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. >> Committed to mainline and 4.8 branch. > > I have hit following build failure on non-USING_SPLIT_STACK target > (alpha-linux-gnu): > > ../../../gcc-svn/trunk/libgo/runtime/proc.c: In function > ‘runtime_entersyscall’: > ../../../gcc-svn/trunk/libgo/runtime/proc.c:1669:27: error: ‘v’ > undeclared (first use in this function) > g->gcnext_sp = (byte *) &v; >^ > ../../../gcc-svn/trunk/libgo/runtime/proc.c:1669:27: note: each > undeclared identifier is reported only once for each function it > appears in > ../../../gcc-svn/trunk/libgo/runtime/proc.c: In function > ‘runtime_entersyscallblock’: > ../../../gcc-svn/trunk/libgo/runtime/proc.c:1716:27: error: ‘v’ > undeclared (first use in this function) > g->gcnext_sp = (byte *) &v; >^ > make[4]: *** [proc.lo] Error 1 > make[4]: *** Waiting for unfinished jobs Thanks. Fixed like so. Committed to mainline and 4.8 branch. Ian foo.patch Description: Binary data
Re: [Patch, Fortran] Coarrays: Don't (free)/alloc LHS coarray components on assignment
Tobias Burnus wrote: Tobias Burnus wrote: With coarrays, allocation/deallocation of coarrays requires a synchronization with all other images. Thus, the standard restricts changing the allocation status to: ALLOCATE and DEALLOCATE statements plus end-of-scope deallocation. In particular, with intrinsic assignment the allocation status does not change. Hence, there is no realloc on assignment. But also (this patch!) no deallocation/allocation of allocatable components during intrinsic assignment of derived types. [This implies that the LHS componet has to have the same allocation status, shape, type-parameters and actual type as the RHS.] The patch additionally checks whether end-of-scope deallocation of coarrays properly calls the deregister function (it did/does). Build and regtested on x86-64-gnu-linux. OK for the trunk? Update: I forgot to copy the back the address of the allocated CAF - which lead to an unwanted address sharing between the RHS and LHS. Note: structure_alloc_comps also contains bits from http://gcc.gnu.org/ml/fortran/2013-06/msg00131.html Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias 2013-06-26 Tobias Burnus * trans-array.h (gfc_deallocate_alloc_comp_no_caf, gfc_reassign_alloc_comp_caf): New prototype. * trans-array.c (enum): Add DEALLOCATE_ALLOC_COMP_NO_CAF and COPY_ALLOC_COMP_CAF. (structure_alloc_comps): Handle it. (gfc_reassign_alloc_comp_caf, gfc_deallocate_alloc_comp_no_caf): New function. (gfc_alloc_allocatable_for_assignment): Call it. * trans-expr.c (gfc_trans_scalar_assign, gfc_trans_arrayfunc_assign, gfc_trans_assignment_1): Ditto. * parse.c (parse_derived): Correctly set coarray_comp. * resolve.c (resolve_symbol): Improve error wording. 2013-06-26 Tobias Burnus * gfortran.dg/coarray_lib_realloc_1.f90: New. * gfortran.dg/coarray/lib_realloc_1.f90: New. * gfortran.dg/coarray_6.f90: Add dg-error. Hi, I observed that this patch causes an ICE with one of the fortran tests. I've filed a bug report here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912. Thanks, Tejas Belagod. ARM.
Re: [PATCH] S/390: Hardware transactional memory support
On Tue, 2013-07-16 at 09:49 -0500, Peter Bergner wrote: > On Tue, 2013-07-16 at 08:08 -0400, David Edelsohn wrote: > > Then I agree that the hunk should be reverted so that HTM does not imply > > POWER8. > > Ok, I'll bootstrap and regtest just to be sure there is no unintended > fallout for such a small path before committing. Thanks. Ok, committed as revision 200985. Thanks. Peter
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Mon, 2013-07-15 at 22:35 +0200, Jakub Jelinek wrote:
> On Mon, Jul 15, 2013 at 02:46:56PM -0500, Peter Bergner wrote:
> > > I'd say something like (but, untested and can't test it right now (and no
> > > access to power8 anyway)):
> >
> > Do we also need to update DWARF_REG_TO_UNWIND_COLUMN similarly, which
> > also uses FIRST_PSEUDO_REGISTER when the dwarf reg is an SPE synthetic
> > register?
>
> Looks like it. Guess that "- 1" in there:
> #define DWARF_REG_TO_UNWIND_COLUMN(r) \
> ((r) > 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER - 1) : (r))
> stands for the sfp register and thus it would be "- 4".
>
> > Or should we just break the dependence on FIRST_PSEUDO_REGISTER
> > altogether so this type of thing doesn't happen again? Otherwise, we
> > should place a comment at the definition of FIRST_PSEUDO_REGISTER
> > warning of it's use in DWARF_FRAME_REGISTER.
>
> That is surely an option too. Or use (DWARF_FRAME_REGISTERS - 32)
> in the DWARF_REG_TO_UNWIND_COLUMN definition instead of the current
> FIRST_PSEUDO_REGISTER - 1, and perhaps make DWARF_FRAME_REGISTERS
> just a number (independent on FIRST_PSEUDO_REGISTER).
> Guess this depends on what David prefers.
I like the idea of removing FIRST_PSEUDO_REGISTER from the definition
of DWARF_REG_TO_UNWIND_COLUMN. I'll still let David decide whether
he wants DWARF_FRAME_REGISTERS to be just a number of computed off
of FIRST_PSEUDO_REGISTER. In the meantime, I'll bootstrap and
regtest your patch along with the DWARF_REG_TO_UNWIND_COLUMN
change.
Peter
* config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTERS): Mention HTM
registers in the comment.
(DWARF_FRAME_REGISTERS): Subtract also the 3 HTM registers.
(DWARF_REG_TO_UNWIND_COLUMN): Use DWARF_FRAME_REGISTERS
rather than FIRST_PSEUDO_REGISTERS.
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h (revision 200985)
+++ gcc/config/rs6000/rs6000.h (working copy)
@@ -892,15 +892,17 @@ enum data_align { align_abi, align_opt,
in inline functions.
Another pseudo (not included in DWARF_FRAME_REGISTERS) is soft frame
- pointer, which is eventually eliminated in favor of SP or FP. */
+ pointer, which is eventually eliminated in favor of SP or FP.
+ The 3 HTM registers aren't also included in DWARF_FRAME_REGISTERS. */
+
#define FIRST_PSEUDO_REGISTER 117
/* This must be included for pre gcc 3.0 glibc compatibility. */
#define PRE_GCC3_DWARF_FRAME_REGISTERS 77
/* Add 32 dwarf columns for synthetic SPE registers. */
-#define DWARF_FRAME_REGISTERS ((FIRST_PSEUDO_REGISTER - 1) + 32)
+#define DWARF_FRAME_REGISTERS ((FIRST_PSEUDO_REGISTER - 4) + 32)
/* The SPE has an additional 32 synthetic registers, with DWARF debug
info numbering for these registers starting at 1200. While eh_frame
@@ -916,7 +918,7 @@ enum data_align { align_abi, align_opt,
We must map them here to avoid huge unwinder tables mostly consisting
of unused space. */
#define DWARF_REG_TO_UNWIND_COLUMN(r) \
- ((r) > 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER - 1) : (r))
+ ((r) > 1200 ? ((r) - 1200 + (DWARF_FRAME_REGISTERS - 32)) : (r))
/* Use standard DWARF numbering for DWARF debugging information. */
#define DBX_REGISTER_NUMBER(REGNO) rs6000_dbx_register_number (REGNO)
Re: [PATCH] S/390: Hardware transactional memory support
On Tue, Jul 16, 2013 at 07:24:31AM +0200, Jakub Jelinek wrote:
> And on s/390, right now we enable HTM support in libitm when configured for
> -march=zEC12 by default (which isn't ideal).
Ok. What about the following patch (untested so far)?
It basically copies what the Power folks are doing with getauxval.
I've also added the configure check for HTM assembler support which so
far was missing on S/390.
Bye,
-Andreas-
---
gcc/config/s390/s390.c |7 !!!
gcc/config/s390/s390.h |3 !!!
libitm/acinclude.m4 | 11 +++
libitm/config/s390/target.h | 23 !!!
libitm/configure| 36
libitm/configure.tgt|2 +-
6 files changed, 48 insertions(+), 1 deletion(-), 33 modifications(!)
Index: libitm/acinclude.m4
===
*** libitm/acinclude.m4.orig
--- libitm/acinclude.m4
*** powerpc*)
*** 135,140
--- 135,151
AC_DEFINE(HAVE_AS_HTM, 1, [Define to 1 if the assembler supports HTM.])
fi
;;
+ s390*)
+ AC_CACHE_CHECK([if the assembler supports HTM], libitm_cv_as_htm, [
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS -march=zEC12"
+ AC_TRY_COMPILE([], [asm("tbegin 0,0; tend");],
+ [libitm_cv_as_htm=yes], [libitm_cv_as_htm=no])
+ CFLAGS="$save_CFLAGS"])
+ if test x$libitm_cv_as_htm = xyes; then
+ AC_DEFINE(HAVE_AS_HTM, 1, [Define to 1 if the assembler supports HTM.])
+ fi
+ ;;
esac])
sinclude(../libtool.m4)
Index: libitm/config/s390/target.h
===
*** libitm/config/s390/target.h.orig
--- libitm/config/s390/target.h
***
*** 22,32
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
Re: [PATCH] S/390: Hardware transactional memory support
On Tue, Jul 16, 2013 at 07:03:18PM +0200, Andreas Krebbel wrote: > On Tue, Jul 16, 2013 at 07:24:31AM +0200, Jakub Jelinek wrote: > > And on s/390, right now we enable HTM support in libitm when configured for > > -march=zEC12 by default (which isn't ideal). > > Ok. What about the following patch (untested so far)? > > It basically copies what the Power folks are doing with getauxval. > I've also added the configure check for HTM assembler support which so > far was missing on S/390. Looks good to me from quick skimming. Jakub
Merge from GCC 4.8 branch to gccgo branch
I've merged GCC 4.8 branch revision 200985 to the gccgo branch. Ian
Re: [PATCH v2] MIPS: MIPS32r2 FP MADD instruction set support
"Maciej W. Rozycki" writes: > I have regression-tested this change with the mips-linux-gnu target and > the mips32r2/o32 multilib. I have also verified that the instructions > affected were absent across the binaries produced by the testsuite before > applying this change and present afterwards. For some reason only MADD.S, > MADD.D, MSUB.S and MSUB.D instructions were produced though -- it looks > like none of NMADD.S, NMADD.D, NMSUB.S and NMSUB.D instructions has > coverage in our testsuite. Hmm, can you double-check? We have gcc.target/mips/nmadd-*, so if we're not producing the instructions there then that sounds like a bug. Thanks, Richard
Re: [PATCH] MIPS: Remove VR54xx NMADD.fmt/NMADD.fmt control breakage
"Maciej W. Rozycki" writes: > 2013-07-16 Maciej W. Rozycki > > gcc/ > * config/mips/mips.h (ISA_HAS_NMADD4_NMSUB4): Remove > TARGET_MIPS5400 checking. OK, thanks. Richard
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Tue, 2013-07-16 at 11:55 -0500, Peter Bergner wrote: > * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTERS): Mention HTM > registers in the comment. > (DWARF_FRAME_REGISTERS): Subtract also the 3 HTM registers. > (DWARF_REG_TO_UNWIND_COLUMN): Use DWARF_FRAME_REGISTERS > rather than FIRST_PSEUDO_REGISTERS. FYI, this bootstrapped and regtested with no regressions. David, is this ok for mainline? Peter
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Tue, Jul 16, 2013 at 3:27 PM, Peter Bergner wrote: > On Tue, 2013-07-16 at 11:55 -0500, Peter Bergner wrote: >> * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTERS): Mention HTM >> registers in the comment. >> (DWARF_FRAME_REGISTERS): Subtract also the 3 HTM registers. >> (DWARF_REG_TO_UNWIND_COLUMN): Use DWARF_FRAME_REGISTERS >> rather than FIRST_PSEUDO_REGISTERS. > > FYI, this bootstrapped and regtested with no regressions. > David, is this ok for mainline? Okay. Thanks, David
Re: [PATCH v2] MIPS: MIPS32r2 FP MADD instruction set support
On Tue, 16 Jul 2013, Richard Sandiford wrote: > > I have regression-tested this change with the mips-linux-gnu target and > > the mips32r2/o32 multilib. I have also verified that the instructions > > affected were absent across the binaries produced by the testsuite before > > applying this change and present afterwards. For some reason only MADD.S, > > MADD.D, MSUB.S and MSUB.D instructions were produced though -- it looks > > like none of NMADD.S, NMADD.D, NMSUB.S and NMSUB.D instructions has > > coverage in our testsuite. > > Hmm, can you double-check? We have gcc.target/mips/nmadd-*, so if we're > not producing the instructions there then that sounds like a bug. I only checked executables, these tests do not produce any. I didn't think of checking tests that do not produce executables, because they do not check run-time validity of code produced. These three tests you've referred to all pass with or without the change, but they are tangential to it because they all force -mips4. Sorry for being inaccurate. Maciej
Re: [PATCH] MIPS: IEEE 754-2008 features support
"Maciej W. Rozycki" writes:
> The run-time selection options are -mnan=2008 and -mnan=legacy for the
> 2008 NaN and the legacy NaN mode respectively. The binary patterns of NaN
> data produced by compiler builtins or otherwise is adjusted accordingly,
> as is a `.nan' directive included now with the assembly source produced,
> used by GAS to set the NAN2008 ELF file header flag appropriately. These
> options are also passed down to GAS by the GCC driver so that user
> assembly sources have the said NAN2008 flag set correctly in the absence
> of a `.nan' directive. Finally the name of the dynamic linker is changed
> accordingly if the driver is used to invoke the linker.
I was a bit surprised that a change to the NaN format requires a change
to the dynamic linker, but I suppose that's the consequence of forcing
every ELF object to fall on one side of the fence?
I assume eventually there'll be an -mmac={legacy|2008} option too,
although of course it's good that that's a separate patch. But then
the question is: is there a plan for handling all 8 possible combinations
of -mnan, -mabs and -mmac? How would the FCSR be set up?
Even if we do plan to have all three be separately configurable,
I imagine most people will want them all set the same way, so it would
probably make sense to have something like -mfp-model={legacy|2008}
for that case. And then my inclination would be to start with that
option and only add the split-out versions if we have a specific
(rather than theoretical) use case for them.
The patch mostly looks good apart from that, but please use a single
enum for the 2008/legacy thing, both in mips.h and mips.opt.
> +;; On pre IEEE 754-2008 processors abs.fmt is an arithmetic instruction
> +;; and treats all NaN inputs as invalid; it does not clear their sign bit.
> +;; We therefore can't use abs.fmt unless in the IEEE 754-2008 mode or if
> +;; the signs of NaNs matter.
"don't matter". Or maybe to avoid the double negative:
;; The "legacy" (as opposed to "2008") form of ABS.FMT is an arithmetic
;; instruction that treats all NaN inputs as invalid; it does not flip
;; their sign bit. We therefore can't use that form if the signs of
;; NaNs matter.
> +These options control the treatment of the special not-a-number (NaN)
> +IEEE 754 floating-point data with the @code{abs.@i{fmt}} and
> +@code{neg.@i{fmt}} machine instructions.
> +
> +By default or when the @option{-mabs=legacy} is used the legacy
> +treatment is selected. In this case these instructions are considered
> +arithmetic and avoided where correct operation is required and the
> +input operand might be a NaN. A longer sequence of instructions that
> +manipulate the sign bit of floating-point datum manually is used
> +instead unless the @option{-ffinite-math-only} option has also been
> +specified.
> +
> +The @option{-mabs=2008} option selects the IEEE 754-2008 treatment. In
I think it reads better without the "-2008" bit, since even the 1985
version suggested this behaviour in the appendix.
> +The @option{-mnan=legacy} option selects the legacy encoding. In this
> +case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
> +significand field being 0, whereas signalling NaNs (sNaNs) are denoted
> +by the first bit of their trailing significand field being 1.
> +
> +The @option{-mnan=2008} option selects the IEEE 754-2008 encoding. In
> +this case qNaNs are denoted by the first bit of their trailing
> +significand field being 1, whereas sNaNs are denoted by the first bit of
> +their trailing significand field being 0.
Very minor, but I'd prefer this without the "trailing"s.
> +These options are only supported on targets using the ELF binary format.
Let's drop that bit. We don't support non-ELF on MIPS.
> +/* { dg-do compile } */
> +/* { dg-options "-mhard-float -mabs=2008" } */
Please instead make "-mabs=" imply "-mhard-float" in mips.exp.
(It is an "imply"; you can still test for -msoft-float -mabs=...
if you want.)
> +# Return 1 if this is a MIPS target supporting -mnan=.
> +# Old versions of binutils may not support this option.
> +
> +proc check_effective_target_mips_nan { } {
> +if { ![istarget mips*-*-*] } {
> + return 0
> +}
> +return [check_no_compiler_messages mips_nan object {
> + int dummy;
> +} "-mnan=2008"]
> +}
The tests you added are dg-do compile tests, which stop after assembly
generation, so this guard shouldn't be needed. FWIW, if you did have
dg-do assemble or dg-do run tests, the mips.exp approach would be to
downgrade them to dg-do compile rather than skip them altogether.
We can add that later if we need it though...
Thanks,
Richard
Re: [PATCH v2] MIPS: MIPS32r2 FP MADD instruction set support
"Maciej W. Rozycki" writes: > On Tue, 16 Jul 2013, Richard Sandiford wrote: > >> > I have regression-tested this change with the mips-linux-gnu target and >> > the mips32r2/o32 multilib. I have also verified that the instructions >> > affected were absent across the binaries produced by the testsuite before >> > applying this change and present afterwards. For some reason only MADD.S, >> > MADD.D, MSUB.S and MSUB.D instructions were produced though -- it looks >> > like none of NMADD.S, NMADD.D, NMSUB.S and NMSUB.D instructions has >> > coverage in our testsuite. >> >> Hmm, can you double-check? We have gcc.target/mips/nmadd-*, so if we're >> not producing the instructions there then that sounds like a bug. > > I only checked executables, these tests do not produce any. I didn't > think of checking tests that do not produce executables, because they do > not check run-time validity of code produced. These three tests you've > referred to all pass with or without the change, but they are tangential > to it because they all force -mips4. OK, as long as those tests pass then the patch is OK, thanks. They aren't tangential for a -march=vr5400 run though. The tests force isa=4 rather than -mips4, and since the VR5432 is a MIPS IV processor, the tests will be run with that -march value. E.g. make check-gcc RUNTESTFLAGS="--target_board unix/-march=vr5400 mips.exp=nmadd*" fails for me but: make check-gcc RUNTESTFLAGS="--target_board unix/-march=vr5400/-mmad mips.exp=nmadd*" passes. Richard
Re: [Patch, Fortran] Coarrays: Don't (free)/alloc LHS coarray components on assignment
Tejas Belagod wrote:
I observed that this patch causes an ICE with one of the fortran
tests. I've filed a bug report here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912.
Thanks for the report! For some reason, the following bit from my local
tree didn't end up in the patch. Committed as Rev. 200987.
Tobias
PS: Your backtrace in the PR looks odd; I get the following (also on
x86-64-gnu-linux), which is much more reasonable. I wonder why yours is off.
0x5fb0ee gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool,
bool, bool)
../../gcc/fortran/trans-expr.c:6862
0x606e62 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:7792
0x5cb565 trans_code
../../gcc/fortran/trans.c:1646
0x5f434e gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5524
0x5ccef1 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:1955
0x58b147 translate_all_program_units
../../gcc/fortran/parse.c:4496
0x58b147 gfc_parse_file()
../../gcc/fortran/parse.c:4706
0x5c7205 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:189
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 200986)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,9 @@
+2013-07-16 Tobias Burnus
+
+ PR fortran/57912
+ * trans-expr.c (gfc_trans_scalar_assign): Correct if
+ condition for caf realloc.
+
2013-07-15 Tobias Burnus
* trans-array.h (gfc_deallocate_alloc_comp_no_caf,
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 200986)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -6857,9 +6857,8 @@ gfc_trans_scalar_assign (gfc_se * lse, gfc_se * rs
fold_convert (TREE_TYPE (lse->expr), rse->expr));
/* Restore pointer address of coarray components. */
- if (ts.u.derived->attr.coarray_comp && deep_copy)
+ if (ts.u.derived->attr.coarray_comp && deep_copy && tmp_var != NULL_TREE)
{
- gcc_assert (tmp_var != NULL_TREE);
tmp = gfc_reassign_alloc_comp_caf (ts.u.derived, tmp_var, lse->expr);
tmp = build3_v (COND_EXPR, cond, build_empty_stmt (input_location),
tmp);
Re: [PATCH, rs6000, libitm] Enable Hardware Transactional Memory (HTM) support on Power
On Tue, 2013-07-16 at 15:31 -0400, David Edelsohn wrote: > On Tue, Jul 16, 2013 at 3:27 PM, Peter Bergner wrote: > > On Tue, 2013-07-16 at 11:55 -0500, Peter Bergner wrote: > >> * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTERS): Mention HTM > >> registers in the comment. > >> (DWARF_FRAME_REGISTERS): Subtract also the 3 HTM registers. > >> (DWARF_REG_TO_UNWIND_COLUMN): Use DWARF_FRAME_REGISTERS > >> rather than FIRST_PSEUDO_REGISTERS. > > > > FYI, this bootstrapped and regtested with no regressions. > > David, is this ok for mainline? > > Okay. Committed as revision 200988. Thanks Jakub and David! Peter
Go patch committed: Fix composite literal with enclosing var as key
This patch to the Go frontend fixes a bug when there is a composite
literal that uses a struct field where the name of the field happens to
be the same as the name of a variable in an enclosing function. This
used to work fine, but it broke when I added a new field to function
closures as part of the change to the function representation. I've
added a test to the master Go repository to catch this in the future.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
diff -r a1afec89faee go/gogo.cc
--- a/go/gogo.cc Tue Jul 16 08:44:25 2013 -0700
+++ b/go/gogo.cc Tue Jul 16 15:41:23 2013 -0700
@@ -3380,7 +3380,7 @@
st->push_field(Struct_field(Typed_identifier(".$f", voidptr_type,
this->location_)));
- unsigned int index = 0;
+ unsigned int index = 1;
for (Closure_fields::const_iterator p = this->closure_fields_.begin();
p != this->closure_fields_.end();
++p, ++index)
Re: [PATCH] MIPS: Remove VR54xx NMADD.fmt/NMADD.fmt control breakage
On Tue, 16 Jul 2013, Richard Sandiford wrote: > > * config/mips/mips.h (ISA_HAS_NMADD4_NMSUB4): Remove > > TARGET_MIPS5400 checking. > > OK, thanks. Committed now, thanks. Maciej
RE: [ping] Re: [patch 0/4] reimplement -fstrict-volatile-bitfields, v3
On Sat, 13 Jul 2013, Bernd Edlinger wrote: > Hi Sandra, > > On Fri, 5 Jul 2013, Hans-Peter Nilsson wrote > > Or - maybe more acceptable - an optional warning, say > > -Wportable-volatility, to warn about code for which separate > > incompatbile definitions on different platforms (or between C > > and C++) exist even within gcc. It would be usable for driver > > code you want to be usable on different architectures, say, in > > an OS commonly compiled with gcc, if you can think of some. :) > > > I like this idea, and this warning would add some real value for everyone. > Therefore I added that option as part 5 of this patch series, I hope you > don't mind :) Definitely not. Thanks for picking up the ball! > I really hope that the GCC maintainers can accept this patch now, as the > current state of -fstrict-volatile-bitfields is very painful to all of us. I guess I should offer a first-hand review of the warnings part. I've got nothing on the code, however the documentation ties the warning only to -fstrict-volatile-bitfields, which it shouldn't; it should be stated generic, but perhaps with -fstrict-volatile-bitfields as an *example*. (And for those who now feel the need to say "but volatile behavior is undefined" without reading the rest of the thread, remember that this is intended to cover cases where some definition actually *exist* whether in some language standard or some target-specific ABI document.) It also needs test-cases, both for some positive cases (warning hits) and some case where it doesn't (and shouldn't). ...and ChangeLog entries. Thanks again! brgds, H-P
Re: [PATCH v2] MIPS: MIPS32r2 FP MADD instruction set support
On Tue, 16 Jul 2013, Richard Sandiford wrote: > > I only checked executables, these tests do not produce any. I didn't > > think of checking tests that do not produce executables, because they do > > not check run-time validity of code produced. These three tests you've > > referred to all pass with or without the change, but they are tangential > > to it because they all force -mips4. > > OK, as long as those tests pass then the patch is OK, thanks. They aren't > tangential for a -march=vr5400 run though. The tests force isa=4 rather > than -mips4, and since the VR5432 is a MIPS IV processor, the tests will > be run with that -march value. E.g. > > make check-gcc RUNTESTFLAGS="--target_board unix/-march=vr5400 > mips.exp=nmadd*" > > fails for me but: > > make check-gcc RUNTESTFLAGS="--target_board unix/-march=vr5400/-mmad > mips.exp=nmadd*" > > passes. Thanks for correcting me on how isa=4 works in these tests. Doesn't that mean they don't really provide correct coverage then? I mean they should really pass on whetever targets support these instructions and shouldn't fail on targets that do not, either by being skipped or better yet by verifying that these instructions are not accidentally produced, shouldn't they? I have applied this change now, thanks for your review. Maciej
Re: [PATCH] Fix the bug to check if lookup_stmt_eh_lp returns positive instead of non-zero
ping...
Thanks,
Dehao
On Mon, Jul 8, 2013 at 5:55 PM, Dehao Chen wrote:
> In lookup_stmt_eh_lp, negative return value indicates a MUST_NOT_THROW
> region index. In this case, we should *not* add an EH edge during VPT.
>
> Bootstrapped and passed regression test.
>
> OK for trunk?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
>
> 2013-07-08 Dehao Chen (de...@google.com)
>
> * value-prof.c (gimple_ic): Fix the bug of adding EH edge.
>
> Index: gcc/value-prof.c
> ===
> --- gcc/value-prof.c (revision 200375)
> +++ gcc/value-prof.c (working copy)
> @@ -1359,8 +1359,7 @@ gimple_ic (gimple icall_stmt, struct cgraph_node *
>
>/* Build an EH edge for the direct call if necessary. */
>lp_nr = lookup_stmt_eh_lp (icall_stmt);
> - if (lp_nr != 0
> - && stmt_could_throw_p (dcall_stmt))
> + if (lp_nr > 0 && stmt_could_throw_p (dcall_stmt))
> {
>edge e_eh, e;
>edge_iterator ei;
Add myself to MAINTAINERS
For libstdc++, regex. -- Tim Shen MAINTAINERS.patch Description: Binary data
Re: Group static constructors and destructors in specific subsections
> On Mon, Jul 15, 2013 at 11:18 AM, Jan Hubicka wrote: > >> On Mon, Jul 15, 2013 at 11:05 AM, Jan Hubicka wrote: > >> > >> > The next thing is how to tell GNU LD/Gold the relative order of > >> > functions. > >> > I.e. my_function_section.order.125 or something like that? > >> > >> Gold has a --section-ordering-file option that lets you specify the > >> order in which sections should appear in the executable. Sections not > >> listed there follow the default rules. > > > > Yep, the problem is where to produce the section ordering file. > > The scheme is as follows: > > - with -fprofile-generate instrument every function entry point and record > > time of first and last invocation of the functoin > > - At compile time we take functions that are executed during the startup > > and we want to order them in the increasing order of the first > > invocation > > time measured at FDO time. So we know the relative position of given > > function > > in the program, but not the complette function order. > > Perhaps I misunderstand, but you can use --section-ordering-file > without knowing the complete function ordering. Just specify the > functions you care about. The thing is that when compiling given object file, you know only functions in that object file, so you can not produce full --section-ordering-file. We would need a tool colleting the partial orders from all objects to single file that I think may be just done in linker. Honza > > Ian
Re: [PATCH] GOMP_CPU_AFFINITY fails with >1024 cores
On 17/07/2013, at 2:29 AM, Daniel J Blueman wrote: > Jakub et al, > > Steffen has developed a nice fix [1] for GOMP_CPU_AFFINITY failing with >1024 > cores. > > What steps are needed to get this into GCC 4.8.2? > > Thanks, > Daniel > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57298 It's easy! Just follow the steps: 1. You test the patch on one of the primary architectures and make sure there are no regressions in the testsuites. 2. Ideally you add a test that fails before your patch, but passes with it. 3. You post your final patch to gcc-patches@ mailing list (this is gcc@ mailing list); CC one of the maintainers. If you CC both -- each will think that the other will review the patch. 4. You include full description and analysis of the problem in the body of message (people are lazy to click on links). You describe how your patch fixes the problem. You write how and which architectures your patch was tested on. 5. You ping your submission every 2 weeks to one of the maintainers until they review your patch. Good luck! -- Maxim Kuvyrkov KugelWorks
Re: Go patch committed: Update libgo to 1.1.1
On Tue, Jul 16, 2013 at 5:45 PM, Ian Lance Taylor wrote: > On Tue, Jul 16, 2013 at 6:07 AM, Uros Bizjak wrote: >> >>> I have committed a large patch to update libgo to the library that was >>> part of the Go 1.1.1 release. As usual, I'm not including the entire >>> patch in this e-mail message, because it is too large. I'm only >>> including the changes to the files that are partially gccgo-specific. >>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. >>> Committed to mainline and 4.8 branch. >> >> I have hit following build failure on non-USING_SPLIT_STACK target >> (alpha-linux-gnu): > > Thanks. Fixed like so. Committed to mainline and 4.8 branch. Thanks, with your patch, I was able to compile libgo without problems. The testsuite run exposes a timeout in net/http, I am looking into it. Another problem was triggered on CentOS 5.9, where compile fails with: ../../../gcc-svn/trunk/libgo/runtime/netpoll_epoll.c: In function ‘runtime_epollcreate1’: ../../../gcc-svn/trunk/libgo/runtime/netpoll_epoll.c:41:2: error: implicit declaration of function ‘epoll_create1’ [-Werror=implicit-function-declaration] r = epoll_create1(flags); ^ cc1: all warnings being treated as errors gmake[4]: *** [netpoll_epoll.lo] Error 1 gmake[4]: *** Waiting for unfinished jobs CentOS has glibc 2.5 and epoll_create1 is not supported. Uros.
