Re: PATC: PR target/64409: ICE building Mesa 10.4.0 for x32 ABI
On Fri, Dec 26, 2014 at 7:38 PM, H.J. Lu wrote: > There is no counter part of x32 in MS ABI. Issue an error when ms_abi > attribute is used with x32. OK for trunk and branches? Is there a fundamental reason that x32 doesn't support ms_abi? IIRC, x32 uses x86_64 ABI, so I see no reason why ms_abi should be disabled. I think that from the user perspective, ms_abi should "just work" on x32 in the same way as on x86_64. Uros.
Re: [PATCH] Use x{v,}asprintf some more
On Fri, Dec 26, 2014 at 9:52 PM, Andi Kleen wrote:
> Uros Bizjak writes:
>
>> Hello!
>>
>> This patch uses x{v,}asprintf where the result of the function is unused.
>
> I would be careful with it. Some old glibc versions have an asprintf
> that corrupts memory. If you do this force the libiberty version
> unconditionally.
Please see the patch, where existing asprintfs are replaced with the
new one from libiberty. I didn't touch asprints that have their result
used.
Uros.
Re: [PATCH][ARM][doc] Remove mention of Advanced RISC Machines
On Friday 2014-12-19 10:24, Kyrill Tkachov wrote: >>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00947.html >> This patch almost certainly falls under the obvious rule: > Yeah, one could almost make an argument that it's a typo fix. > Committed as r218897. I am not a big fan of stretching the concept of a typo fix. Rather, let's comfortably call obvious what _is_ obvious and have people like you fix things like this, or improve things, without having to wait for approval. Just go for it. :-) Gerald
Re: [WWW] Update index.html and gcc-5/changes.html to reflect offloading changes.
Hi Kirill, On Friday 2014-12-12 14:43, Kirill Yukhin wrote: > These change adds mention of OpenMP4 offloading support in GCC: in > release notes and in news section of main page. good you thought of that, thank you! > Index: htdocs/index.html > === > + OpenMP 4.0 offloading support in GCC > + [2014-12-12] > + http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf";> > + OpenMP 4.0 offloading features support was added to GCC. Generic > changes: How about omitting "features" in the above? > + Generic infrastructure (suitable for any vendor). > + Testsuite which covers offloading from > + http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf";> > + OpenMP 4.0 Examples document. "from the" > + Specific for upcoming Intel MIC products: Is everyone aware what MIC stands for, or is that the marketing name? > + Runtime library. I believe that would be "run-time library"? > +Contributed by Jakub Jelinek (RedHat), Thomas Schwinge (CodeSourcery), Red Hat. It's Red Hat. Two words. Why does "everybody" get this wrong? > + Bernd Schmidt (CodeSourcery), Andrey Turetskiy (Intel), > + Ilya Verbin (Intel) and Kirill Yukhin (Intel). How about if you contract this to "Thomas Schwinge and Bernd Schmidt (CodeSourcery)" and similarly for you guys from Intel? Incidently the alphabetical ordering nicely supports this here. Note: Schwinge > Schmidt, so I think you'll want to switch those two. That said, overall this is a bit too long for an entry on the home page. Can you put all those details in the gcc-5/changes.html page (this is good material) and link to it from a shortened entry for the home page? > Index: htdocs/gcc-5/changes.html > === > New Languages and Language specific > improvements + + href="http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf";> OpenMP 4.0 > + specification offloading features are now supported in C/C++ and > + Fortran compiler + "supported by the C, C++ and Fortran compilers" (plural) (This adds "the", but also splits C and C++ which really are to different compilers in many ways. No need to be shy. ;-) Given the number of suggestions, in this case I'd prefer to have another look at an updated version. Now that I am back online, I should be able to turn this quickly. Gerald
[PATCH, i386]: Fix MMX *vec_extractv2{sf,si}_1 patterns
Hello!
unpckhps and punpckhpd are not correct insns to move 32bit X[1] to
X[0] in XMM registers. These two insns move X[2] to X[0]. The patch
uses movshdup, pshufd and shufps instead.
This problem however is a non-issue since MMX moves are never
generated, but insn pattern should be fixed nevertheless.
2014-12-27 Uros Bizjak
* config/i386/mmx.md (*vec_extractv2sf_1): Do not emit unpckhps.
Emit movshdup for SSE3 and shufps otherwise.
(*vec_extractv2si_1): Do not emit punpckhdq and unpckhps.
Emit pshufd for SSE2 and shufps otherwise.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32},
committed to mainline SVN and 4.9 branch.
Uros.
Index: mmx.md
===
--- mmx.md (revision 219073)
+++ mmx.md (working copy)
@@ -600,20 +600,25 @@
;; Avoid combining registers from different units in a single alternative,
;; see comment above inline_secondary_memory_needed function in i386.c
(define_insn "*vec_extractv2sf_1"
- [(set (match_operand:SF 0 "nonimmediate_operand" "=y,x,y,x,f,r")
+ [(set (match_operand:SF 0 "nonimmediate_operand" "=y,x,x,y,x,f,r")
(vec_select:SF
- (match_operand:V2SF 1 "nonimmediate_operand" " 0,0,o,o,o,o")
+ (match_operand:V2SF 1 "nonimmediate_operand" " 0,x,x,o,o,o,o")
(parallel [(const_int 1)])))]
"TARGET_MMX && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
"@
punpckhdq\t%0, %0
- unpckhps\t%0, %0
+ %vmovshdup\t{%1, %0|%0, %1}
+ shufps\t{$0xe5, %1, %0|%0, %1, 0xe5}
#
#
#
#"
- [(set_attr "type" "mmxcvt,sselog1,mmxmov,ssemov,fmov,imov")
- (set_attr "mode" "DI,V4SF,SF,SF,SF,SF")])
+ [(set_attr "isa" "*,sse3,noavx,*,*,*,*")
+ (set_attr "type" "mmxcvt,sse,sseshuf1,mmxmov,ssemov,fmov,imov")
+ (set_attr "length_immediate" "*,*,1,*,*,*,*")
+ (set_attr "prefix_rep" "*,1,*,*,*,*,*")
+ (set_attr "prefix" "orig,maybe_vex,orig,orig,orig,orig,orig")
+ (set_attr "mode" "DI,V4SF,V4SF,SF,SF,SF,SF")])
(define_split
[(set (match_operand:SF 0 "register_operand")
@@ -1288,26 +1293,23 @@
;; Avoid combining registers from different units in a single alternative,
;; see comment above inline_secondary_memory_needed function in i386.c
(define_insn "*vec_extractv2si_1"
- [(set (match_operand:SI 0 "nonimmediate_operand" "=y,x,x,x,y,x,r")
+ [(set (match_operand:SI 0 "nonimmediate_operand" "=y,x,x,y,x,r")
(vec_select:SI
- (match_operand:V2SI 1 "nonimmediate_operand" " 0,0,x,0,o,o,o")
+ (match_operand:V2SI 1 "nonimmediate_operand" " 0,x,x,o,o,o")
(parallel [(const_int 1)])))]
"TARGET_MMX && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
"@
punpckhdq\t%0, %0
- punpckhdq\t%0, %0
- pshufd\t{$85, %1, %0|%0, %1, 85}
- unpckhps\t%0, %0
+ %vpshufd\t{$0xe5, %1, %0|%0, %1, 0xe5}
+ shufps\t{$0xe5, %1, %0|%0, %1, 0xe5}
#
#
#"
- [(set (attr "isa")
- (if_then_else (eq_attr "alternative" "1,2")
- (const_string "sse2")
- (const_string "*")))
- (set_attr "type" "mmxcvt,sselog1,sselog1,sselog1,mmxmov,ssemov,imov")
- (set_attr "length_immediate" "*,*,1,*,*,*,*")
- (set_attr "mode" "DI,TI,TI,V4SF,SI,SI,SI")])
+ [(set_attr "isa" "*,sse2,noavx,*,*,*")
+ (set_attr "type" "mmxcvt,sseshuf1,sseshuf1,mmxmov,ssemov,imov")
+ (set_attr "length_immediate" "*,1,1,*,*,*")
+ (set_attr "prefix" "orig,maybe_vex,orig,orig,orig,orig")
+ (set_attr "mode" "DI,TI,V4SF,SI,SI,SI")])
(define_split
[(set (match_operand:SI 0 "register_operand")
Fix sanity check in sreal.h
Hi, sreal::shift does have wrong bounds on exponent shift (that was copied over from shift_right). Bootstrapped/regtested x86_64-linux, comitted as obvious. Honza * sreal.h (sreal::shift): Fix sanity check. Index: sreal.h === --- sreal.h (revision 219073) +++ sreal.h (working copy) @@ -87,8 +87,8 @@ public: /* Zero needs no shifting. */ if (!m_sig) return *this; -gcc_checking_assert (s <= SREAL_BITS); -gcc_checking_assert (s >= -SREAL_BITS); +gcc_checking_assert (s <= SREAL_MAX_EXP); +gcc_checking_assert (s >= -SREAL_MAX_EXP); /* Overflows/drop to 0 could be handled gracefully, but hopefully we do not need to do so. */
[PATCH, moxie] Limit moxie sto/ldo offsets to 16-bits.
I'm checking in the attached patch to switch ldo/sto offsets to 16 bits
from 32. This was a long overdue backwards incompatible change to the
ISA.
2014-12-27 Anthony Green
* config/moxie/moxie-protos.h (moxie_offset_address_p): Define.
* config/moxie/constraints.md (B): Replace inline test with call
to moxie_offset_address_p.
* config/moxie/moxie.h (GO_IF_LEGITIMATE_ADDRESS): Limit offset
addressing to 16-bit offsets.
* config/moxie/moxie.c (moxie_asm_trampoline_template): Remove
nop, which is no longer needed for aligned write to trampoline.
(moxie_trampoline_init): Adjust for smaller trampoline.
(moxie_offset_address_p): New function.
* config/moxie/moxie.md (*movsi, *movhi, *movqi): Adjust length
attr for shorter ldo/sto instructions.
* config/moxie/predicates.md: Only allow REG+CONST_INT for offset
load/stores.
Index: gcc/config/moxie/constraints.md
===
--- gcc/config/moxie/constraints.md (revision 219054)
+++ gcc/config/moxie/constraints.md (working copy)
@@ -32,7 +32,7 @@
(define_constraint "B"
"An offset address."
(and (match_code "mem")
- (match_test "GET_CODE (XEXP (op, 0)) == PLUS")))
+ (match_test "moxie_offset_address_p (op)")))
(define_constraint "W"
"A register indirect memory operand."
Index: gcc/config/moxie/moxie-protos.h
===
--- gcc/config/moxie/moxie-protos.h (revision 219054)
+++ gcc/config/moxie/moxie-protos.h (working copy)
@@ -22,3 +22,6 @@
extern int moxie_initial_elimination_offset (int, int);
extern void moxie_print_operand (FILE *, rtx, int);
extern void moxie_print_operand_address (FILE *, rtx);
+extern bool moxie_offset_address_p (rtx);
+
+
Index: gcc/config/moxie/moxie.c
===
--- gcc/config/moxie/moxie.c(revision 219056)
+++ gcc/config/moxie/moxie.c(working copy)
@@ -555,7 +555,6 @@
fprintf (f, "\tldi.l $r0, 0x0\n");
fprintf (f, "\tsto.l 0x8($fp), $r0\n");
fprintf (f, "\tpop $sp, $r0\n");
- fprintf (f, "\tnop\n");
fprintf (f, "\tjmpa 0x0\n");
}
@@ -571,10 +570,28 @@
mem = adjust_address (m_tramp, SImode, 4);
emit_move_insn (mem, chain_value);
- mem = adjust_address (m_tramp, SImode, 20);
+ mem = adjust_address (m_tramp, SImode, 16);
emit_move_insn (mem, fnaddr);
}
+/* Return true for memory offset addresses between -32768 and 32767. */
+bool
+moxie_offset_address_p (rtx x)
+{
+ x = XEXP (x, 0);
+
+ if (GET_CODE (x) == PLUS)
+{
+ x = XEXP (x, 1);
+ if (GET_CODE (x) == CONST_INT)
+ {
+ unsigned int v = INTVAL (x) & 0x8000;
+ return (v == 0x8000 || v == 0x);
+ }
+}
+ return 0;
+}
+
/* The Global `targetm' Variable. */
/* Initialize the GCC target structure. */
Index: gcc/config/moxie/moxie.h
===
--- gcc/config/moxie/moxie.h(revision 219054)
+++ gcc/config/moxie/moxie.h(working copy)
@@ -362,7 +362,7 @@
#define FUNCTION_PROFILER(FILE,LABELNO) (abort (), 0)
/* Trampolines for Nested Functions. */
-#define TRAMPOLINE_SIZE (2 + 6 + 6 + 2 + 2 + 6)
+#define TRAMPOLINE_SIZE (2 + 6 + 4 + 2 + 6)
/* Alignment required for trampolines, in bits. */
#define TRAMPOLINE_ALIGNMENT 32
@@ -462,7 +462,8 @@
op1 = XEXP(X,0);\
op2 = XEXP(X,1);\
if (GET_CODE(op1) == REG\
- && CONSTANT_ADDRESS_P(op2) \
+ && GET_CODE(op2) == CONST_INT \
+ && IN_RANGE (INTVAL (op2), -32768, 32767) \
&& REGNO_OK_FOR_BASE_P(REGNO(op1))) \
goto LABEL; \
}\
Index: gcc/config/moxie/moxie.md
===
--- gcc/config/moxie/moxie.md (revision 219056)
+++ gcc/config/moxie/moxie.md (working copy)
@@ -266,7 +266,7 @@
lda.l %0, %1
sto.l %0, %1
ldo.l %0, %1"
- [(set_attr "length" "2,2,6,2,6,2,6,6,6")])
+ [(set_attr "length" "2,2,6,2,6,2,6,4,4")])
(define_insn_and_split "zero_extendqisi2"
[(set (match_operand:SI 0 "register_operand" "=r,r,r,r")
@@ -344,7 +344,7 @@
lda.b %0, %1
sto.b %0, %1
ldo.b %0, %1"
- [(set_attr "length" "2,2,6,2,6,2,6,6,6")])
+ [(set_attr "length" "2,2,6,2,6,2,6,4,4")])
(define_expand "movhi"
[(set (match_operand:HI 0 "general_operand" "")
@@ -372,7 +372,7 @@
lda.s %0, %1
sto.s %0, %1
ldo.s %0, %1"
- [(set_attr "length" "2,2,6,2,6,2,6,6,6")])
+ [(set_attr "length" "2,2,6,2,6,2,6,4,4")])
;; -
Re: [WWW] Update index.html and gcc-5/changes.html to reflect offloading changes.
On Dec 27, 2014, at 3:07 AM, Gerald Pfeifer wrote: >> New Languages and Language specific >> improvements + + > href="http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf";> OpenMP 4.0 >> + specification offloading features are now supported in C/C++ and >> + Fortran compiler + > > "supported by the C, C++ and Fortran compilers" (plural) Further, it should also be supported by the Object-C and C++ compilers. Should just come up for free.
Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all
On Dec 24, 2014, at 3:21 PM, Segher Boessenkool wrote: > I normally build with --disable-libsanitizer, because the sanitizers > testresults are very unreproducable, so just annoying noise. This however > makes most (all?) ubsan testcases fail, since they want to load a shared > library that does not exist. > > This patch disables the ubsan testcases if a trivial program does not > run when compiled with ubsan. > > Tested on powerpc64-linux, -m32,-m32/-mpowerpc64,-m64,-m64/-mlra; > 5452 failures gone, no other changes. > > Okay for mainline? So, I was hoping the ubsan people would have weighed in... Ok. Please watch for nits from them. Please consider pulling the check out and putting it in at the top of the ubsan.exp type of files. I suspect there is little need to check this more than once per language or so.
Re: [PATCH] X86-64: Add -mskip-rax-setup
On Dec 26, 2014, at 7:57 AM, "H.J. Lu" wrote: > On Thu, Dec 25, 2014 at 9:07 PM, Gerald Pfeifer wrote: >> On Thursday 2014-12-18 11:35, H.J. Lu wrote: >>> Updated. >> >> "the RAX register" (i.e., add "the"), and I suggest to make >> this a sentence, similar to my previous mail for the other >> update. >> >> This is fine with these changes. > > Done. > >> Thank you -- and that's a nice hack (in the positive sense)! >> > > It really is a hack :-) and was suggested by Rasmus Villemoes. So, my suggestion is similar, but different. Imagine you find 10 of these things over the years, 10 flags look horrible. I like the -mkernel style flag where all are bundled up under it, essentially it becomes the kernel API flag.
Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all
On Sat, Dec 27, 2014 at 08:09:47AM -0800, Mike Stump wrote: > > I normally build with --disable-libsanitizer, because the sanitizers > > testresults are very unreproducable, so just annoying noise. This however > > makes most (all?) ubsan testcases fail, since they want to load a shared > > library that does not exist. > > > > This patch disables the ubsan testcases if a trivial program does not > > run when compiled with ubsan. > > > > Tested on powerpc64-linux, -m32,-m32/-mpowerpc64,-m64,-m64/-mlra; > > 5452 failures gone, no other changes. > > > > Okay for mainline? > > So, I was hoping the ubsan people would have weighed in... Holidays... > Ok. Please watch for nits from them. > > Please consider pulling the check out and putting it in at the top of the > ubsan.exp type of files. > > I suspect there is little need to check this more than once per language or > so. It already is cached, but yeah I see what you mean. Something for the ubsan people to handle, perhaps? Or someone else who can actually write dejagnu things :-) Segher
Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all
On Sat, Dec 27, 2014 at 10:11:59AM -0600, Segher Boessenkool wrote: > > Please consider pulling the check out and putting it in at the top of the > > ubsan.exp type of files. > > > > I suspect there is little need to check this more than once per language or > > so. Actually, that is already how it is done :-) Segher
[C++ Patch] PR 64418
Hello,
This patch fixes an issue with C++11 where user-defined conversion is
not properly suppressed in certain cases of list-initialisation.
Consider the example:
--- 8< --
struct C {
C(const C &);
};
struct X {
operator C() const;
};
C a{X()};
--- 8< --
This program is successfully compiled. However, I believe this is an
erroneous behaviour.
The variable "a" is initialised by direct list-initialization
according to 8.5.4. [dcl.init.list] #3 and 13.3.1.7 [over.match.list].
As the class C does not have an initializer-list ctor, all the
constructors of C are tried with the elements of the initializer list
as arguments.
GCC tries and in fact finds a user-defined conversion sequence from X
to the first parameter of the C's copy-ctor.
However, according to 13.3.3.1 [over.best.ics] #4,
"[...] when considering the argument of a constructor [...] that is a
candidate by [...] by 13.3.1.7 [...] or when the initializer list has
exactly one element and a conversion to some class X or reference to
(possibly cv-qualified) X is considered for the first parameter of a
constructor of X [...] only standard conversion sequences and ellipsis
conversion sequences are considered.
Bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553 is related to
this one.
Bootstrapped and regtested on:
Target: x86_64-unknown-linux-gnu
Configured with: /home/chill/src/gcc-list-conv/configure
--prefix=/home/chill/opt/gcc-list-conv --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 5.0.0 20141225 (experimental) [chill/list-conv revision
b97cebe:8ccc35f:77c6247fdf2b97e796de45e5a2279b3a44b2f998] (GCC)
without regressions, except the testcase initlist64.C, which, I believe
is flawed and was fixed.
/cp
2014-12-27 Momchil Velikov
PR c++/64418
* call.c (add_function_candidate): Do not allow user-defined
conversions during list-initialisation, when the constructor is
called with a single argument that takes a reference to the
constructor's class.
/testsuite
2014-12-27 Momchil Velikov
PR c++/64418
* g++.dg/cpp0x/initlist64.C: Fix testcase.
* g++.dg/cpp0x/initlist91.C: New.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 86c78ab..1e36dd2 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -2078,11 +2078,10 @@ add_function_candidate (struct z_candidate **candidates,
{
if (!(flags & LOOKUP_ONLYCONVERTING))
lflags |= LOOKUP_COPY_PARM;
- /* We allow user-defined conversions within init-lists, but
- don't list-initialize the copy parm, as that would mean
- using two levels of braces for the same type. */
- if ((flags & LOOKUP_LIST_INIT_CTOR)
- && BRACE_ENCLOSED_INITIALIZER_P (arg))
+
+ /* According to [over.best.ics] #4, suppress user-defined
+ conversion in the context of list-initialisation. */
+ if ((flags & LOOKUP_LIST_INIT_CTOR))
lflags |= LOOKUP_NO_CONVERSION;
}
else
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist64.C b/gcc/testsuite/g++.dg/cpp0x/initlist64.C
index 78e5308..11e6bd9 100644
--- a/gcc/testsuite/g++.dg/cpp0x/initlist64.C
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist64.C
@@ -16,14 +16,14 @@ struct Z
explicit operator X() const;
};
-X a = { Y() };
+X a = { Y() }; // { dg-error "" }
X aa = Y();
-X b{ Y() };
+X b{ Y() }; // { dg-error "" }
X bb(Y());
X c = { Z() }; // { dg-error "" }
X cc = Z(); // { dg-error "" }
-X d{ Z() };
+X d{ Z() }; // { dg-error "" }
X dd( Z() );
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist91.C b/gcc/testsuite/g++.dg/cpp0x/initlist91.C
new file mode 100644
index 000..9debb79
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist91.C
@@ -0,0 +1,25 @@
+// PR c++/51553
+// { dg-do compile { target c++11 } }
+
+struct C {
+ C(const C &);
+ C(const C &, int);
+ C(int, const C &);
+};
+
+struct X {
+ operator C() const;
+};
+
+X x;
+
+C a{x}; // { dg-error "" }
+C b{x, 1};
+C c{1, x};
+C d(x);
+C e(x, 1);
+C f(1, x);
+C g = x;
+C h = {x}; // { dg-error "" }
+C i = {x, 1};
+C j = {1, x};
Re: [PATCH] X86-64: Add -mskip-rax-setup
On Sat, Dec 27, 2014 at 8:18 AM, Mike Stump wrote: > On Dec 26, 2014, at 7:57 AM, "H.J. Lu" wrote: >> On Thu, Dec 25, 2014 at 9:07 PM, Gerald Pfeifer wrote: >>> On Thursday 2014-12-18 11:35, H.J. Lu wrote: Updated. >>> >>> "the RAX register" (i.e., add "the"), and I suggest to make >>> this a sentence, similar to my previous mail for the other >>> update. >>> >>> This is fine with these changes. >> >> Done. >> >>> Thank you -- and that's a nice hack (in the positive sense)! >>> >> >> It really is a hack :-) and was suggested by Rasmus Villemoes. > > So, my suggestion is similar, but different. Imagine you find 10 of these > things over the years, 10 flags look horrible. I like the -mkernel style > flag where all are bundled up under it, essentially it becomes the kernel API > flag. So far, for Linux x86-64 kernel, we added -mskip-rax-setup and allowed -mpreferred-stack-boundary=3. We will see how far it goes :-). -- H.J.
Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all
On Dec 27, 2014, at 8:33 AM, Segher Boessenkool
wrote:
> On Sat, Dec 27, 2014 at 10:11:59AM -0600, Segher Boessenkool wrote:
>>> Please consider pulling the check out and putting it in at the top of the
>>> ubsan.exp type of files.
>>>
>>> I suspect there is little need to check this more than once per language or
>>> so.
>
> Actually, that is already how it is done :-)
No, examine i386.exp for the line at the top that does this:
# Exit immediately if this isn't a x86 target.
if { ![istarget i?86*-*-*] && ![istarget x86_64-*-*] } then {
return
}
Here, you see that if there are 100,000 x86 test cases, this is checked once
and only about 2 lines of tcl are run. In yours, if there were 100,000 ubsan
test cases, you would discover millions of lines run, not 2. millions is
slightly more than 2.
[Patch, Fortran, F08] PR 60357: structure constructor with unspecified values for allocatable components
Hi all,
here is a small patch for an F08 extension: Allocatable components
don't have to be specified in structure constructors any more.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-27 Janus Weil
PR fortran/60357
* array.c (check_constructor): Ignore empty expressions.
* expr.c (check_alloc_comp_init): Check if constructor expression
exists.
* primary.c (build_actual_constructor): Warn for absent alloc-comp
initializers in pre-2008 standards.
2014-12-27 Janus Weil
PR fortran/60357
* gfortran.dg/alloc_comp_constructor_7.f90: New.
Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c (Revision 219082)
+++ gcc/fortran/array.c (Arbeitskopie)
@@ -1309,6 +1309,9 @@ check_constructor (gfc_constructor_base ctor, bool
{
e = c->expr;
+ if (!e)
+ continue;
+
if (e->expr_type != EXPR_ARRAY)
{
if (!(*check_function)(e))
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (Revision 219082)
+++ gcc/fortran/expr.c (Arbeitskopie)
@@ -2201,7 +2201,7 @@ check_alloc_comp_init (gfc_expr *e)
ctor = gfc_constructor_first (e->value.constructor);
comp; comp = comp->next, ctor = gfc_constructor_next (ctor))
{
- if (comp->attr.allocatable
+ if (comp->attr.allocatable && ctor->expr
&& ctor->expr->expr_type != EXPR_NULL)
{
gfc_error ("Invalid initialization expression for ALLOCATABLE "
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (Revision 219082)
+++ gcc/fortran/primary.c (Arbeitskopie)
@@ -2367,6 +2367,13 @@ build_actual_constructor (gfc_structure_ctor_compo
return false;
value = gfc_copy_expr (comp->initializer);
}
+ else if (comp->attr.allocatable)
+ {
+ if (!gfc_notify_std (GFC_STD_F2008, "No initializer for "
+ "allocatable component '%s' given in the structure "
+ "constructor at %C", comp->name))
+ return false;
+ }
else if (!comp->attr.deferred_parameter)
{
gfc_error ("No initializer for component %qs given in the"
! { dg-do compile }
!
! PR 60357: [F08] structure constructor with unspecified values for allocatable components
!
! Contributed by Antony Lewis
Type A
integer :: X = 1
integer, allocatable :: y
end type A
Type(A) :: Me = A(X=1)
end
Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all
On Sat, Dec 27, 2014 at 09:34:44AM -0800, Mike Stump wrote:
> >>> Please consider pulling the check out and putting it in at the top of the
> >>> ubsan.exp type of files.
> >>>
> >>> I suspect there is little need to check this more than once per language
> >>> or so.
> >
> > Actually, that is already how it is done :-)
>
> No, examine i386.exp for the line at the top that does this:
>
> # Exit immediately if this isn't a x86 target.
>
> if { ![istarget i?86*-*-*] && ![istarget x86_64-*-*] } then {
> return
> }
>
> Here, you see that if there are 100,000 x86 test cases, this is checked once
> and only about 2 lines of tcl are run. In yours, if there were 100,000 ubsan
> test cases, you would discover millions of lines run, not 2. millions is
> slightly more than 2.
>From gcc.dg/ubsan/ubsan.exp:
# Main loop.
if [check_effective_target_fsanitize_undefined] {
gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c
$srcdir/c-c++-common/ubsan/*.c]] "" ""
}
That only runs once, doesn't it? Am I missing something?
There are some init things before it, but they may be needed for the
check itself.
Segher
Re: [C++ Patch] PR 64418
Hi, On 12/27/2014 05:49 PM, Momchil Velikov wrote: +conversion in the context of list-initialisation. */ Nit: I think you want to spell initialization, with a z, like in the standard (and all the uses of the expression in our front-end) Paolo.
Re: [patch, fortran] PR 56867
> OK for trunk? What about the other open branches? OK for trunk. After it’s been in for a bit of time, probably OK for all active branches, unless someone (or you) think it’s unwise. FX
Re: [PATCH] Fix PR c++/59366 A friend function template defined in a class is found without ADL
Ping
On 5.05.2014 13:06, Momchil Velikov wrote:
Hello,
A friend function, defined in a class and not declared outside should
be hidden from ordinary name lookup and only found by argument-dependent
lookup, like:
struct S
{
friend void f() {}
friend void g(const S &) {}
};
int
main()
{
f(); // error
g(S()); // correct, found by ADL
}
GCC correctly handles this case, but fails for function templates like:
struct S
{
template friend void f(T) {}
};
int
main()
{
f(1); // should be an error, GCC succeeds
f(S()); // correct, found by ADL
}
Bootstrapped and regtested again on top of:
Target: x86_64-unknown-linux-gnu
Configured with: /home/chill/src/gcc-friend-define/configure
--prefix=/home/chill/opt/gcc-friend-define --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 5.0.0 20141227 (experimental) (GCC)
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index b982451..5059e14 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -927,6 +927,29 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
if (DECL_DECLARES_FUNCTION_P (t))
check_default_args (t);
+ if (TREE_CODE (x) == FUNCTION_DECL || DECL_FUNCTION_TEMPLATE_P (x))
+{
+ if (is_friend)
+ {
+ if (t == x && !flag_friend_injection)
+ {
+ /* This is a new friend declaration of a function or
+ a function template, so hide it from ordinary
+ function lookup. */
+ DECL_ANTICIPATED (t) = 1;
+ DECL_HIDDEN_FRIEND_P (t) = 1;
+ }
+ }
+ else if (t != x && t != error_mark_node)
+ {
+ /* This is a non-friend re-declaration of a possibly
+ hidden function or a function template, so don't hide
+ it. */
+ DECL_ANTICIPATED (t) = 0;
+ DECL_HIDDEN_FRIEND_P (t) = 0;
+ }
+ }
+
if (t != x || DECL_FUNCTION_TEMPLATE_P (t))
return t;
@@ -987,16 +1010,6 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
}
}
- if (TREE_CODE (x) == FUNCTION_DECL
- && is_friend
- && !flag_friend_injection)
- {
- /* This is a new declaration of a friend function, so hide
- it from ordinary function lookup. */
- DECL_ANTICIPATED (x) = 1;
- DECL_HIDDEN_FRIEND_P (x) = 1;
- }
-
/* This name is new in its binding level.
Install the new declaration and return it. */
if (namespace_bindings_p ())
diff --git a/gcc/testsuite/g++.dg/template/friend57.C b/gcc/testsuite/g++.dg/template/friend57.C
new file mode 100644
index 000..7077d5e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/friend57.C
@@ -0,0 +1,21 @@
+// PR c++/59366
+// { dg-do compile }
+template void f(T);
+
+struct S
+{
+ template friend void f(T) {}
+ template friend void g(T) {}
+ template friend void h(T) {}
+};
+
+template void h(T);
+
+int
+main ()
+{
+ f(1);
+ g(1); // { dg-error "'g' was not declared in this scope" }
+ g(S());
+ h(1);
+}
diff --git a/gcc/testsuite/g++.old-deja/g++.pt/friend5.C b/gcc/testsuite/g++.old-deja/g++.pt/friend5.C
index 3feeb68..edb9d62 100644
--- a/gcc/testsuite/g++.old-deja/g++.pt/friend5.C
+++ b/gcc/testsuite/g++.old-deja/g++.pt/friend5.C
@@ -14,5 +14,5 @@ class C
int main()
{
- f(7);
+ f(C());
}
/cp
2014-12-27 Momchil Velikov
PR c++/59366
* name-lookup.c (pushdecl_maybe_friend_1): Hide friend functions
and function templates, declared only in the class.
/testsuite
2014-12-27 Momchil Velikov
PR c++/59366
* g++.dg/template/friend57.C: New
* g++.old-deja/g++.pt/friend5.C (main): Fix testcase. The friend
functions `f` should be found only by ADL.
[patch libstdc++] Fix assignability check in uninitialized_copy
std::uninitialized_copy tries to test assignability as follows:
is_assignable<_ValueType1, _RefType>::value
This is the wrong way around. For example, when the iterators are char*, this
ends up as
is_assignable::value
which is false. It should be
is_assignable::value
which is true.
The result is that uninitialized_copy needlessly picks the slow implementation.
Trivial fix attached. (No tests ran because I'm getting "runtest: command not
found" errors that I don't know how to fix.)
Index: libstdc++-v3/include/bits/stl_uninitialized.h
===
--- libstdc++-v3/include/bits/stl_uninitialized.h (revision 219070)
+++ libstdc++-v3/include/bits/stl_uninitialized.h (working copy)
@@ -105,29 +105,29 @@
template
inline _ForwardIterator
uninitialized_copy(_InputIterator __first, _InputIterator __last,
_ForwardIterator __result)
{
typedef typename iterator_traits<_InputIterator>::value_type
_ValueType1;
typedef typename iterator_traits<_ForwardIterator>::value_type
_ValueType2;
#if __cplusplus < 201103L
const bool __assignable = true;
#else
// trivial types can have deleted assignment
typedef typename iterator_traits<_InputIterator>::reference _RefType;
- const bool __assignable = is_assignable<_ValueType1, _RefType>::value;
+ const bool __assignable = is_assignable<_RefType, _ValueType1>::value;
#endif
return std::__uninitialized_copy<__is_trivial(_ValueType1)
&& __is_trivial(_ValueType2)
&& __assignable>::
__uninit_copy(__first, __last, __result);
}
template
struct __uninitialized_fill
{
template
static void
Re: [PATCH] Fix PR c++/59366 A friend function template defined in a class is found without ADL
On 12/27/2014 04:38 PM, Momchil Velikov wrote:
+ else if (t != x && t != error_mark_node)
+ {
+ /* This is a non-friend re-declaration of a possibly
+hidden function or a function template, so don't hide
+it. */
+ DECL_ANTICIPATED (t) = 0;
+ DECL_HIDDEN_FRIEND_P (t) = 0;
+ }
Doesn't duplicate_decls handle clearing these?
Jason
Re: [C++ Patch] PR 64418
On 12/27/2014 11:49 AM, Momchil Velikov wrote:
struct C {
C(const C &);
};
struct X {
operator C() const;
};
C a{X()};
The variable "a" is initialised by direct list-initialization
according to 8.5.4. [dcl.init.list] #3 and 13.3.1.7 [over.match.list].
As the class C does not have an initializer-list ctor, all the
constructors of C are tried with the elements of the initializer list
as arguments.
As I commented on the PR, the current G++ behavior is correct under the
resolution of DR 1467.
Jason
[wwwdocs] C++ SD-6 feature test column for cxx0x.html and cxx1y.html
Greetings, I would like peoples opinion of adding another column to the tables indicating C++ feature status for C++11 and C++14 that contains the relevant SD-6 feature macro. Ed Index: htdocs/projects/cxx0x.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx0x.html,v retrieving revision 1.66 diff -r1.66 cxx0x.html 63a64 > SD-6 Feature Test 68a70 > __cpp_rvalue_references >= 200610 73a76 > __cpp_ref_qualifiers >= 200710 78a82 > 83a88 > __cpp_nsdmi >= 200809 89a95 > __cpp_variadic_templates >= 200704 95a102 > 100a108 > __cpp_initializer_lists >= 200806 105a114 > __cpp_static_assert >= 200410 110a120 > 115a126 > 120a132 > 125a138 > 130a144 > __cpp_lambdas >= 200907 136a151 > __cpp_decltype >= 200707 141a157 > 147a164 > 153a171 > 159a178 > 164a184 > __cpp_alias_templates >= 200704 169a190 > 174a196 > 180a203 > 187a211 > 192a217,218 > __cpp_attributes >= 200809; __has_cpp_attribute(noreturn) >= 200809; > __has_cpp_attribute(carries_dependency) == 0 (not implemented) 197a224 > __cpp_constexpr >= 200704 202a230 > 209a238 > __cpp_delegating_constructors >= 200604 214a244 > __cpp_inheriting_constructors >= 200802 219a250 > 224a256 > __cpp_unicode_characters >= 200704 229a262 > __cpp_unicode_literals >= 200710 234a268 > __cpp_raw_strings >= 200710 239a274 > 244a280 > __cpp_user_defined_literals >= 200809 249a286 > 255a293 > 260a299 > 265a305 > 271a312 > 276a318 > 281a324 > 286a330 > __cpp_range_based_for >= 200907 293a338 > 298a344 > 303a350 > 308a356 > 312c360 < Concurrency --- > Concurrency 317a366 > 322a372 > 327a378 > 332a384 > 338a391 > 343a397 > 349a404 > 354a410 > 359a416 > 364a422 > 369a428 > 373c432 < C99 Features in C++11 --- > C99 Features in C++11 379a439 > 385a446 > 391a453 > 396a459 > Index: htdocs/projects/cxx1y.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1y.html,v retrieving revision 1.21 diff -r1.21 cxx1y.html 47a48 > SD-6 Feature Test 59a61,62 > __cpp_binary_literals >= 201304 > 66a70,71 > __cpp_decltype_auto >= 201304 > 73a79,80 > __cpp_init_captures >= 201304 > 80a88,89 > __cpp_generic_lambdas >= 201304 > 87a97,98 > __cpp_variable_templates >= 201304 > 94a106 > __cpp_constexpr >= 201304 101a114 > __cpp_aggregate_nsdmi >= 201304 106a120 > 113a128 > __cpp_sized_deallocation >= 201309 119a135 > __has_cpp_attribute(deprecated) >= 201309 125a142,143 > __has_cpp_attribute(deprecated) >= 201309 > __cpp_digit_separator >= 201309 145a164 > __cpp_runtime_arrays >= 198712
RE: [build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest
Hi Michael and Jan-Benedict, On Fri, 19 Dec 2014 13:56:50, Michael Haubenwallner wrote: > On the way to prepare some (aix) libtool patch for toplevel libtool.m4 > I've discovered that different versions of automake were used to generate > files across various libs: > > most libs: automake-1.11.1 > libatomic r211747: automake-1.11.6 > libgfortran r204654: automake-1.11.3 > r215741: automake-1.11.6 Michael proposes to change everything to automake-1.11.1. But the helper files "missing" and friends were updated to automake-1.14.1 by: 2014-11-16 Jan-Benedict Glaw * compile: Sync with upstream Automake. * depcomp: Ditto. * install-sh: Ditto. * missing: Ditto. * mkinstalldirs: Ditto. * ylwrap: Ditto. Actually I thought that was in preparation to move everything to automake 1.14.1 If I see that right, calling automake without parameters does not touch these helper files, but "automake --add-missing --copy --force-missing" would replace them with the copy from the automake installation additionally to just rewriting the Makefile.in. I think we should have all automake files from the same version, either 1.11.1 or 1.14.1. What do you think? Regards, Bernd.
Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all
On Dec 27, 2014, at 9:56 AM, Segher Boessenkool
wrote:
> From gcc.dg/ubsan/ubsan.exp:
>
> # Main loop.
> if [check_effective_target_fsanitize_undefined] {
> That only runs once, doesn't it?
Yes, it does. Perfect.
