Re: [PATCH] libstdc++: add uniform on sphere distribution
On Fri, 8 Aug 2014, Ulrich Drepper wrote: Now also for a fix of the sphere distribution. Unless someone objects I'll check in the patch below. 2014-08-08 Ulrich Drepper drep...@gmail.com * include/ext/random.tcc (uniform_on_sphere_distribution::__generate_impl): Reject vectors with norm zero. While there, do we want to also reject infinite norms? I would have done: while (__sum small || __sum large) but testing exactly for 0 and infinity seems good enough. -- Marc Glisse
Re: [GSoC] Elimination of CLooG library installation dependency
Is this segmentation fault at compile time or at run-time? I believe it was
a segfault at run-time due to a miscompile.
Yes, it's a segfault at run-time. These source codes produce wrong object files.
Possibly. Can you split the .cpp files such that you only compile a single
function with graphite and that compiling this function causes the
miscompile. This allows us to look at less code.
I've tried to reduce btCollisionWorld.cpp and
btCollisionDispatcher.cpp (They can be found attached). Should we ask
Sven?
--
Cheers, Roman Gareev.
void *btAlignedAlloc (int size, int alignment);
template typename T, unsigned Alignment
class btAlignedAllocator
{
typedef btAlignedAllocator T, Alignment self_type;
public:
T *allocate (int n, const T** hint = 0)
{
(void) hint;
return reinterpret_castT*(btAlignedAlloc(sizeof (T) * n, Alignment));
}
};
#include new
template typename T
class btAlignedObjectArray
{
btAlignedAllocatorT, 16 m_allocator;
int m_size;
T *m_data;
public:
void push_back ()
{
T *s = (T*) m_allocator.allocate (m_size * 2);
int i;
for (i=0; im_size; ++i)
new (s[i]) T (m_data[i]);
}
};
class btCollisionDispatcher
{
btAlignedObjectArraybtCollisionDispatcher* m_manifoldsPtr;
virtual void getNewManifold ();
};
void btCollisionDispatcher::getNewManifold ()
{
m_manifoldsPtr.push_back ();
}
void* btAlignedAlloc (int size, int alignment);
template typename T, unsigned Alignment
class btAlignedAllocator
{
typedef btAlignedAllocatorT, Alignment self_type;
public:
template typename Other
btAlignedAllocator (const btAlignedAllocatorOther, Alignment ) {}
T *allocate (int n, const T **hint = 0)
{
(void) hint;
return reinterpret_castT* (btAlignedAlloc (sizeof (T) * n ,
Alignment));
}
};
#include new
template typename T
class btAlignedObjectArray
{
btAlignedAllocatorT, 16 m_allocator;
int m_size;
T *m_data;
public:
void push_back (const T _Val)
{
T *s = (T*) m_allocator.allocate (m_size * 2);
int i;
for (i=0; im_size; ++i)
new (s[i]) T (m_data[i]);
new (m_data[m_size]) T (_Val);
}
};
typedef btAlignedObjectArrayclass btCollisionObject* btCollisionObjectArray;
class btCollisionObject;
class btCollisionWorld
{
protected:
btAlignedObjectArraybtCollisionObject* m_collisionObjects;
public:
virtual void addCollisionObject(btCollisionObject* collisionObject);
};
void btCollisionWorld::addCollisionObject(btCollisionObject* collisionObject)
{
m_collisionObjects.push_back(collisionObject);
}
Re: [GSoC] Elimination of CLooG library installation dependency
On 09/08/2014 09:42, Roman Gareev wrote: Is this segmentation fault at compile time or at run-time? I believe it was a segfault at run-time due to a miscompile. Yes, it's a segfault at run-time. These source codes produce wrong object files. Possibly. Can you split the .cpp files such that you only compile a single function with graphite and that compiling this function causes the miscompile. This allows us to look at less code. I've tried to reduce btCollisionWorld.cpp and btCollisionDispatcher.cpp (They can be found attached). Should we ask Sven? With just C++ code, Sven can help little. He has no knowledge about graphite internals. Do you now have a setup where you can just compile one of the attached files with graphite and everything else without and the code crashes? Why did you provide two files. I assume one should be sufficient to reproduce the crash, no? I think for the one file you choose, it would be interesting to look at the code generation input as well as the kernels generated by CLooG and isl. Maybe we can understand what is going on. Cheers, Tobias
Re: [C++ Patch] PR 51312
Hi,
On 08/09/2014 03:33 AM, Jason Merrill wrote:
On 08/08/2014 07:26 PM, Paolo Carlini wrote:
Ok (that seems a latent buglet...). By the way, since I wondered briefly
about SFINAE wrt the existing documentation, does what we do in the
*non* constant case really matter for SFINAE?
Yes; in unevaluated context, at least.
I see... If you have hints about c++/57460, I would be glad to work on it...
Anyway, Ok if testing passes with that change?
Yes, thanks.
Thanks. I'm going to apply the below. Unfortunately the library bit
turns out to be a bit ugly because int_type can be a pod struct with an
int data member, or an integer type, possibly unsigned, maybe Jon can
help with something more elegant.
Thanks again,
Paolo.
PS: in fact we have got quite a few pedwarns protected by complain
where, when the condition is false, we just go on, we don't immediately
return error_mark_node, as we would normally do for plain errors.
Probably I will audit next week.
2014-08-08 Paolo Carlini paolo.carl...@oracle.com
* doc/invoke.texi ([Wnarrowing]): Update for non-constants in C++11.
/cp
2014-08-08 Paolo Carlini paolo.carl...@oracle.com
* typeck2.c (check_narrowing): Add tsubst_flags_t parameter, change
return type to bool; in C++11 for constants give errors, not pedwarns.
* cp-tree.h (check_narrowing): Adjust declaration.
* call.c (convert_like_real): Update calls.
* semantics.c (finish_compound_literal): Likewise.
/testsuite
2014-08-08 Paolo Carlini paolo.carl...@oracle.com
* g++.dg/cpp0x/Wnarrowing1.C: Adjust for errors.
* g++.dg/cpp0x/enum29.C: Adjust.
/libstdc++-v3
2014-08-08 Paolo Carlini paolo.carl...@oracle.com
* include/ext/pod_char_traits.h (char_traits__gnu_cxx::
character_Value, _Int, _St ::eof): Fix vs narrowing conversion.
Index: gcc/cp/call.c
===
--- gcc/cp/call.c (revision 213775)
+++ gcc/cp/call.c (working copy)
@@ -6251,8 +6251,9 @@ convert_like_real (conversion *convs, tree expr, t
1, false, false, complain);
if (sub == error_mark_node)
return sub;
- if (!BRACE_ENCLOSED_INITIALIZER_P (val))
- check_narrowing (TREE_TYPE (sub), val);
+ if (!BRACE_ENCLOSED_INITIALIZER_P (val)
+!check_narrowing (TREE_TYPE (sub), val, complain))
+ return error_mark_node;
CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (new_ctor), NULL_TREE,
sub);
if (!TREE_CONSTANT (sub))
TREE_CONSTANT (new_ctor) = false;
@@ -6480,8 +6481,9 @@ convert_like_real (conversion *convs, tree expr, t
break;
}
- if (convs-check_narrowing)
-check_narrowing (totype, expr);
+ if (convs-check_narrowing
+ !check_narrowing (totype, expr, complain))
+return error_mark_node;
if (issue_conversion_warnings)
expr = cp_convert_and_check (totype, expr, complain);
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 213775)
+++ gcc/cp/cp-tree.h(working copy)
@@ -6214,7 +6214,7 @@ extern int abstract_virtuals_error_sfinae (tree, t
extern int abstract_virtuals_error_sfinae (abstract_class_use, tree,
tsubst_flags_t);
extern tree store_init_value (tree, tree, vectree,
va_gc**, int);
-extern void check_narrowing(tree, tree);
+extern bool check_narrowing(tree, tree, tsubst_flags_t);
extern tree digest_init(tree, tree,
tsubst_flags_t);
extern tree digest_init_flags (tree, tree, int);
extern tree digest_nsdmi_init (tree, tree);
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c (revision 213775)
+++ gcc/cp/semantics.c (working copy)
@@ -2597,8 +2597,8 @@ finish_compound_literal (tree type, tree compound_
compound_literal = reshape_init (type, compound_literal, complain);
if (SCALAR_TYPE_P (type)
!BRACE_ENCLOSED_INITIALIZER_P (compound_literal)
- (complain tf_warning_or_error))
-check_narrowing (type, compound_literal);
+ !check_narrowing (type, compound_literal, complain))
+return error_mark_node;
if (TREE_CODE (type) == ARRAY_TYPE
TYPE_DOMAIN (type) == NULL_TREE)
{
Index: gcc/cp/typeck2.c
===
--- gcc/cp/typeck2.c(revision 213775)
+++ gcc/cp/typeck2.c(working copy)
@@ -842,17 +842,19 @@ store_init_value (tree decl, tree init, vectree,
}
-/* Give errors about narrowing conversions within { }. */
+/* Give diagnostic about narrowing conversions within { }. */
-void
-check_narrowing (tree type, tree init)
+bool
+check_narrowing (tree type, tree init, tsubst_flags_t complain)
{
tree
Re: [GSoC] Elimination of CLooG library installation dependency
With just C++ code, Sven can help little. He has no knowledge about graphite
internals.
I want to ask him about correctness of ISL ASTs generated from
mentioned isl_codegens.
Do you now have a setup where you can just compile one of the attached files
with graphite and everything else without and the code crashes?
No, I don't. As I mentioned earlier, all the files from this test case
individually produce object files which linked into the one
executable, which cause “Segmentation fault (core dumped)” (It'll
cause “Segmentation fault (core dumped)”, if we try to run it). I
think that it's very difficult to detach the code, which would produce
the executable and save the semantics of this big OOP project.
Furthermore, there is a possibility that the detached code can produce
no new useful information.
I've found that if we try to compile any of the btCollisionWorld.cpp,
btCollisionDispatcher.cpp
and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the
produced object file will lead to creation of the wrong executable
(after linking with other object files generated by origin Graphite).
That's why I think that we could consider only, for example,
btCollisionDispatcher.cpp. It contains only one scope, which is
incorrectly processed by Graphite with the ISL code generator as the
main generator.
Why did you provide two files. I assume one should be sufficient to
reproduce the crash, no?
I've detached the code, which is used by Graphite to produce similar AST's.
I think for the one file you choose, it would be interesting to look
at the code generation input as well as the kernels generated by CLooG and
isl. Maybe we can understand what is going on.
What do you mean by the kernels generated by CLooG and isl?
btCollisionDispatcher.cpp:
isl_codegen:
[P_2, P_11] - { S_6[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_2)/4294967296), e1 = floor((P_11 + 8i0)/18446744073709551616): i0 =
0 and 4294967296e0 = -1 + P_2 and 4294967296e0 = -4294967296 + P_2
and 4294967296e0 = -1 + P_2 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_11 + 8i0 and
18446744073709551616e1 = -1 + P_11 + 8i0) }
[P_2, P_11] - { : exists (e0 = floor((-1 + P_2)/4294967296):
4294967296e0 = -1 + P_2 and 4294967296e0 = -2147483647 + P_2 and P_2
= -2147483648 and P_2 = 2147483647 and P_11 = 0 and P_11 =
18446744073709551615) }
[P_2, P_11] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_2; c1 += 1)
if ((P_11 + 8 * c1) % 18446744073709551616 = 1)
S_6(c1);
cloog_input:
# CLooG - CLooG
# This is an automatic dump of a CLooG input file from a CloogInput data
# structure.
# Language: C
c
# Context:
1
4 4 0 0 0 2
1 1 0-1
1-1 0 2147483647
1 0-1 18446744073709551615
1 0 1 0
1 # Parameter name(s)
T_2 T_11
# Statement number:
1
# Iteration domain of statement 1 ().
1
7 7 1 0 2 2
1 1 0 0 0 0 0
1 0 -4294967296 0 1 0-1
1 0 4294967296 0-1 0 4294967296
1-1 -4294967296 0 1 0-1
1-1 0 0 0 0 2147483646
1-8 0 18446744073709551616 0-1 18446744073709551615
1 8 0 -18446744073709551616 0 1-1
0 0 0 # For future options.
1 # Iterator name(s)
git_0
# - SCATTERING
1 # Scattering functions
# Scattering of statement 1 ().
1
3 8 3 1 0 2
0 0 0 1 0 0 0 0
0 0 1 0-1 0 0 0
0 1 0 0 0 0 0 0
1 # Scattering dimension name(s)
scat_0 scat_1 scat_2
CLAST generated by ClooG:
if (8*T_2 = -T_11+9) {
for (scat_1=0;scat_1=T_2-1;scat_1++) {
if ((8*scat_1+T_11+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
--
Cheers, Roman Gareev.
Re: [PATCH 40/50] rtlanal.c:for_each_inc_dec
Jeff Law l...@redhat.com writes: On 08/03/14 08:32, Richard Sandiford wrote: The old for_each_inc_dec callback had a for_each_rtx-like return value, with 0 being returned directly, 0 meaning continue and 0 meaning skip subrtxes. But there's no reason to distinguish the latter two cases since auto-inc/dec expressions aren't allowed to contain other auto-inc/dec expressions. And if for_each_rtx is going away, there's no longer any consistency argument for using the same interface. gcc/ * rtl.h (for_each_inc_dec_fn): Remove special case for -1. * cselib.c (cselib_record_autoinc_cb): Update accordingly. (cselib_record_sets): Likewise. * dse.c (emit_inc_dec_insn_before, check_for_inc_dec_1) (check_for_inc_dec): Likewise. * rtlanal.c (for_each_inc_dec_ops): Delete. (for_each_inc_dec_find_inc_dec): Take the MEM as argument, rather than a pointer to the memory address. Replace for_each_inc_dec_ops argument with separate function and data arguments. Abort on non-autoinc addresses. (for_each_inc_dec_find_mem): Delete. (for_each_inc_dec): Use FOR_EACH_SUBRTX_VAR to visit every autoinc MEM. So this patch has me a little bit concerned. @@ -2523,7 +2523,7 @@ cselib_record_sets (rtx insn) data.sets = sets; data.n_sets = n_sets_before_autoinc = n_sets; - for_each_inc_dec (insn, cselib_record_autoinc_cb, data); + for_each_inc_dec (PATTERN (insn), cselib_record_autoinc_cb, data); n_sets = data.n_sets; So wouldn't this miss an autoincrement operation embedded in a note, such as a REG_EQUAL note? My memory is very fuzzy here, but I can't recall any policy which prohibits an autoincrement addressing mode from appearing in a REG_EQUAL note. Worse yet, I have vague memories of embedded side effects actually showing up in REG_EQUAL notes. But either: (a) those notes would contain side effects that are also present in the main pattern, e.g.: (set (reg Z) (plus (mem (pre_inc X)) (reg Y))) REG_EQUAL: (plus (mem (pre_inc X)) (const_int Z)) (b) those notes would contain side effects that are not present in the main pattern. (b) seems completely invalid to me. REG_EQUAL notes are just a hint and it's perfectly OK to remove them if they're no longer accurate (e.g. because a register value used in the note is no longer available). It's also possible to remove them if the set destination gets combined with something else. Plus the whole idea of a REG_EQUAL note is that you could replace the SET_SRC with the note value without changing the effect of the instruction. For (a) the current code would end up recording the same side-effect twice, so looking at just the pattern is likely to be a bug fix. But (a) is probably invalid too in practice. Just a guess, but maybe the thing you were thinking of was related to the old REG_LIBCALL/REG_RETVAL support? Although I only vaguely remember how that worked now... Thanks, Richard
Re: [PATCH 01/50] Add rtl-iter.h
Richard Henderson r...@redhat.com writes:
On 08/03/2014 03:39 AM, Richard Sandiford wrote:
+struct rtx_subrtx_bound_info {
+ unsigned char start;
+ unsigned char count;
+};
Given this structure is only two bytes...
+ /* The bounds to use for iterating over subrtxes. */
+ const rtx_subrtx_bound_info *m_bounds;
... wouldn't it be better to pass by value instead of by reference?
This shows I should expand the comment, but m_bounds is an array indexed
by rtx code.
Thanks,
Richard
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sat, Aug 9, 2014 at 3:15 AM, Marc Glisse marc.gli...@inria.fr wrote: While there, do we want to also reject infinite norms? I would have done: while (__sum small || __sum large) but testing exactly for 0 and infinity seems good enough. I guess the squaring can theoretically overflow and produce infinity. It will never happen with the way we generate normally distributed numbers, though. These values are always so unlikely that it is OK that the algorithms cannot return them. If you insist I'll add a test for infinity. The other change (which would eliminate the necessity for this test in a special case) is to use hypot for _Dimen==2. This might be a case common enough to warrant that little bit of extra text. I'll prepare a patch.
PR tree-optimization/52904 testcase
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
Tescase was generating warning: assuming signed overflow does not occur
when simplifying conditional to constant [-Wstrict-overflow] due to VRP
missing the value range.
This seems to have been fixed and the PR is now closed. However, as
requested there in the PR, I am sending this patch to add the test-case
to test-suite.
Is this OK ?
Thanks,
Kugan
gcc/testsuite
2014-08-09 Kugan Vivekanandarajah kug...@linaro.org
PR tree-optimization/52904
* gcc.dg/PR52904.c: New test.
diff --git a/gcc/testsuite/gcc.dg/PR52904.c b/gcc/testsuite/gcc.dg/PR52904.c
index e69de29..e490d23 100644
--- a/gcc/testsuite/gcc.dg/PR52904.c
+++ b/gcc/testsuite/gcc.dg/PR52904.c
@@ -0,0 +1,26 @@
+
+/* { dg-do compile } */
+/* { dg-options -S -Wstrict-overflow -O2 -fdump-tree-vrp2 } */
+
+extern int foo (int);
+
+
+int
+wait_reading_process_output (void)
+{
+ int nfds = 0;
+ int channel;
+ for (channel = 0; channel 1024; ++channel)
+{
+ if (foo (channel))
+ nfds++;
+}
+ if (nfds 0)
+return 1;
+ return 0;
+}
+
+/* { dg-bogus assuming signed overflow does not occur when simplifying\
+ conditional to constant */
+/* { dg-final { scan-tree-dump \\\[0, 1023\\\] vrp2 } } */
+/* { dg-final { cleanup-tree-dump vrp2 } } */
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sat, 9 Aug 2014, Ulrich Drepper wrote: On Sat, Aug 9, 2014 at 3:15 AM, Marc Glisse marc.gli...@inria.fr wrote: While there, do we want to also reject infinite norms? I would have done: while (__sum small || __sum large) but testing exactly for 0 and infinity seems good enough. I guess the squaring can theoretically overflow and produce infinity. It will never happen with the way we generate normally distributed numbers, though. These values are always so unlikely that it is OK that the algorithms cannot return them. If you insist I'll add a test for infinity. Oh, a comment saying exactly what you just said would be fine with me (or even nothing). The other change (which would eliminate the necessity for this test in a special case) is to use hypot for _Dimen==2. This might be a case common enough to warrant that little bit of extra text. I'll prepare a patch. If you are going to specialize for dim 2, I imagine you won't be computing normal distributions, you will only generate a point uniformy in a square and reject it if it is not in the ball? (interestingly enough this is used as a subroutine by the implementation of normal_distribution) -- Marc Glisse
Re: patch to fix a wrong code generation with LRA when SDmode is used on ppc.
Hi, Vlad
Thanks for the explanation.
The patch is okay.
Thanks, David
On Fri, Aug 8, 2014 at 5:26 PM, Vladimir Makarov vmaka...@redhat.com wrote:
On 2014-08-08, 2:53 PM, David Edelsohn wrote:
Hi, Vlad
Why does rs6000_emit_move need special support for SDmode with LRA and
not with reload?
rs6000_emit_move has also special SDmode support for *reload too*. It is
not implemented generically in reload as you wrote. Please, look at the
code with reload_in_progress nearby. So I am trying to do basically the
same as done by rs6000 back end for reload but by means of LRA. The
difference between code for reload and LRA is in that a special stack slot
is created for reload. Reload through a hook SECONDARY_MEMORY_NEEDED_RTX
provided by rs6000 back-end generates a move using the stack slot and that
triggers a special code generation in rs6000_emit_move. So it is a trick,
not a general support in reload.
LRA uses a spilled pseudo for this and don't use the hook at all. It means
that the stack slot created for reload is used only for SD moves. LRA uses
a common stack slot allocation techniques for spilled pseudos which permits
to share this slot for other purposes, generates a better code, and uses
less one hook. But basically code for LRA in rs600_emit_move do the same as
analogous code for reload.
But if you mean that general support you mentioned is the usage of
absolutely the same trick for LRA as for reload (through
SECONDARY_MEMORY_NEEDED_RTX), I could do this. But as I wrote it would be
worse code generation than LRA currently produces and using an additional
hook out of many already used by LRA.
In other words, why is this a specific fix for
rs6000 instead of a general improvement for reload?
Because it is too specific. It is about how rs6000 too specifically
implements sd load/store. For example, SECONDARY_MEMORY_NEEDED_RTX is a
creation only for rs6000. No other port uses it because the hook is used
for the trick I wrote above. I don't think other port will use the trick in
future.
SDmode has some bizarre restrictions on PPC, but one of the historical
advantages of GCC was reload's ability to support strange addressing
modes of processors. Why fix this in a target-specific way and then
possibly replicated this in other architectures instead of fixing it
more generally?
It is not about addressing. It is about machine description of insns. If
movsd_{load,store} insns were part of common move insns, we would have no
problem at all. But I guess, achieving this would be not possible or easy.
I believe Mike had serious reasons to do this such way. I am not such a
specialist in md writing as Mike.
If I could solve this problem only in LRA, I'd prefer to do this because it
is simpler for me as I don't need an approval.
RE: [PATCH mips] Do not compile mips16.S in soft-float mode
-Original Message- From: Steve Ellcey [mailto:sell...@mips.com] Subject: [PATCH mips] Do not compile mips16.S in soft-float mode This libgcc patch is the second of two patches needed to build GCC soft-float multilibs when using the latest binutils. It skips assembling any of the code in mips16.S when in soft-float mode because the code is not used when in soft- float mode and because doing so generates errors during assembly (due to using floating point registers in soft-float mode). Tested with the mips-mti-linux-gnu toolchain. FWIW, this patch looks okay to me (although I can't approve it). Catherine 2014-08-08 Steve Ellcey sell...@mips.com * config/mips/mips16.S: Skip when __mips_soft_float is defined. diff --git a/libgcc/config/mips/mips16.S b/libgcc/config/mips/mips16.S index 6a43a98..150a23a 100644 --- a/libgcc/config/mips/mips16.S +++ b/libgcc/config/mips/mips16.S @@ -21,7 +21,7 @@ a copy of the GCC Runtime Library Exception along with this program; see the files COPYING3 and COPYING.RUNTIME respectively. If not, see http://www.gnu.org/licenses/. */ -#ifdef __mips_micromips +#if defined(__mips_micromips) || defined(__mips_soft_float) /* DO NOTHING */ #else @@ -749,4 +749,4 @@ CALL_STUB_RET (__mips16_call_stub_dc_10, 10, DC) #endif /* !__mips_single_float */ #endif -#endif /* __mips_micromips */ +#endif /* defined(__mips_micromips) || defined(__mips_soft_float) */
RE: [PATCH mips] Pass -msoft-float/-mhard-float flags to GAS
-Original Message-
From: Steve Ellcey [mailto:sell...@mips.com]
Sent: Friday, August 08, 2014 3:42 PM
To: Moore, Catherine; matthew.fort...@imgtec.com; echri...@gmail.com;
2014-08-08 Steve Ellcey sell...@mips.com
* config/mips/mips.h (ASM_SPEC): Pass float options to assembler.
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
8d7a09f..9a15287 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1187,6 +1187,8 @@ struct mips_cpu_info { %{mshared} %{mno-
shared} \ %{msym32} %{mno-sym32} \ %{mtune=*} \
+%{mhard-float} %{msoft-float} \
+%{msingle-float} %{mdouble-float} \
%(subtarget_asm_spec)
/* Extra switches sometimes passed to the linker. */
Hi Steve,
The patch itself looks okay, but perhaps a question for Matthew.
Does the fact that the assembler requires -msoft-float even if .set softfloat
is present in the .s file deliberate behavior?
I don't have a problem with passing along the *float* options to gas, but would
hope that the .set options were honored as well.
My short test indicated that the .set *float* options were being ignored if the
correct command line option wasn't present.
Thanks,
Catherine
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sat, Aug 9, 2014 at 8:34 AM, Marc Glisse marc.gli...@inria.fr wrote: Oh, a comment saying exactly what you just said would be fine with me (or even nothing). We might at some point use a different method than Box-Muller sampling so I'm OK with the test. If you are going to specialize for dim 2, I imagine you won't be computing normal distributions, you will only generate a point uniformy in a square and reject it if it is not in the ball? (interestingly enough this is used as a subroutine by the implementation of normal_distribution) We need to be *on* the circle, not inside. We'll still have to follow the algorithm unless I miss something. With reasonable probability we cannot generate those numbers directly from a uniform source. What is optimized is just the norm computation.
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sat, 9 Aug 2014, Ulrich Drepper wrote: If you are going to specialize for dim 2, I imagine you won't be computing normal distributions, you will only generate a point uniformy in a square and reject it if it is not in the ball? (interestingly enough this is used as a subroutine by the implementation of normal_distribution) We need to be *on* the circle, not inside. Yes, you still need the normalization step (divide by the norm). It works whether you start from a uniform distribution in the disk or from a Gaussian in the plane, but the first one is easier to generate (generate points in a square until you get one in the disk). When the dimension becomes higher, the probability that a point in the cube actually belongs to the ball decreases, and it becomes cheaper to use a Gaussian. -- Marc Glisse
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
Excuse me, when I try the testsuite for a new patch which I will send, I realize I should make sure some related information. So I consult for them, please help check, thanks. On 8/1/14 6:36, Jeff Law wrote: make make check It is OK (I finish the 2 steps under Mac book). save various .sum files Excuse me, I can not find it with `find ./ | grep \.sum$` [...] compare .sum files After comparing, should the related .sum files be the same (same means pass checking)? Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] libstdc++: add uniform on sphere distribution
Marc Glisse marc.gli...@inria.fr writes:
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
Yes, you still need the normalization step (divide by the norm).
I guess we can do this.
How about the patch below? Instead of specializing the entire class for
_Dimen==2 I've added a class at the implementation level.
I've also improved existing tests and add some new ones.
2014-08-09 Ulrich Drepper drep...@gmail.com
* include/ext/random.tcc (uniform_on_sphere_helper): Define.
(uniform_on_sphere_distribution::operator()): Use the new helper
class for the implementation.
* testsuite/ext/random/uniform_on_sphere_distribution/operators/
equal.cc: Remove bogus part of comment.
* testsuite/ext/random/uniform_on_sphere_distribution/operators/
inequal.cc: Likewise.
* testsuite/ext/random/uniform_on_sphere_distribution/operators/
serialize.cc: Add check to verify result of serialzation and
deserialization.
* testsuite/ext/random/uniform_on_sphere_distribution/operators/
generate.cc: New file.
diff --git a/libstdc++-v3/include/ext/random.tcc
b/libstdc++-v3/include/ext/random.tcc
index 05361d8..d536ecb 100644
--- a/libstdc++-v3/include/ext/random.tcc
+++ b/libstdc++-v3/include/ext/random.tcc
@@ -1540,6 +1540,83 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
+ namespace {
+
+// Helper class for the uniform_on_sphere_distribution generation
+// function.
+templatestd::size_t _Dimen, typename _RealType
+ class uniform_on_sphere_helper
+ {
+ typedef typename uniform_on_sphere_distribution_Dimen,
_RealType::result_type result_type;
+
+ public:
+ templatetypename _NormalDistribution, typename
_UniformRandomNumberGenerator
+ result_type operator()(_NormalDistribution __nd,
+ _UniformRandomNumberGenerator __urng)
+{
+ result_type __ret;
+ typename result_type::value_type __norm;
+
+ do
+ {
+ auto __sum = _RealType(0);
+
+ std::generate(__ret.begin(), __ret.end(),
+ [__nd, __urng, __sum](){
+ _RealType __t = __nd(__urng);
+ __sum += __t * __t;
+ return __t; });
+ __norm = std::sqrt(__sum);
+ }
+ while (__norm == _RealType(0) || ! std::isfinite(__norm));
+
+ std::transform(__ret.begin(), __ret.end(), __ret.begin(),
+[__norm](_RealType __val){ return __val / __norm; });
+
+ return __ret;
+}
+ };
+
+
+templatetypename _RealType
+ class uniform_on_sphere_helper2, _RealType
+ {
+ typedef typename uniform_on_sphere_distribution2, _RealType::
+ result_type result_type;
+
+ public:
+ templatetypename _NormalDistribution,
+typename _UniformRandomNumberGenerator
+ result_type operator()(_NormalDistribution,
+ _UniformRandomNumberGenerator __urng)
+{
+ result_type __ret;
+ _RealType __sq;
+ std::__detail::_Adaptor_UniformRandomNumberGenerator,
+ _RealType __aurng(__urng);
+
+ do
+ {
+ __ret[0] = __aurng();
+ __ret[1] = __aurng();
+
+ __sq = __ret[0] * __ret[0] + __ret[1] * __ret[1];
+ }
+ while (__sq == _RealType(0) || __sq _RealType(1));
+
+ // Yes, we do not just use sqrt(__sq) because hypot() is more
+ // accurate.
+ auto __norm = std::hypot(__ret[0], __ret[1]);
+ __ret[0] /= __norm;
+ __ret[1] /= __norm;
+
+ return __ret;
+}
+ };
+
+ }
+
+
templatestd::size_t _Dimen, typename _RealType
templatetypename _UniformRandomNumberGenerator
typename uniform_on_sphere_distribution_Dimen, _RealType::result_type
@@ -1547,18 +1624,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator()(_UniformRandomNumberGenerator __urng,
const param_type __p)
{
- result_type __ret;
- _RealType __sum = _RealType(0);
-
- std::generate(__ret.begin(), __ret.end(),
- [__urng, __sum, this](){ _RealType __t = _M_nd(__urng);
-__sum += __t * __t;
-return __t; });
- auto __norm = std::sqrt(__sum);
- std::transform(__ret.begin(), __ret.end(), __ret.begin(),
- [__norm](_RealType __val){ return __val / __norm; });
-
- return __ret;
+uniform_on_sphere_helper_Dimen, _RealType __helper;
+return __helper(_M_nd, __urng);
}
templatestd::size_t _Dimen, typename _RealType
diff --git
a/libstdc++-v3/testsuite/ext/random/uniform_on_sphere_distribution/operators/equal.cc
Re: [PATCH] libstdc++: add uniform on sphere distribution
On 08/09/2014 11:33 AM, Marc Glisse wrote: On Sat, 9 Aug 2014, Ulrich Drepper wrote: If you are going to specialize for dim 2, I imagine you won't be computing normal distributions, you will only generate a point uniformy in a square and reject it if it is not in the ball? (interestingly enough this is used as a subroutine by the implementation of normal_distribution) We need to be *on* the circle, not inside. Yes, you still need the normalization step (divide by the norm). It works whether you start from a uniform distribution in the disk or from a Gaussian in the plane, but the first one is easier to generate (generate points in a square until you get one in the disk). When the dimension becomes higher, the probability that a point in the cube actually belongs to the ball decreases, and it becomes cheaper to use a Gaussian. If we pull in the implementation of normal you will just be able to use the two values that normal computes on the first, (and third, ...) calls without doing two calls. That and hypot would be a real win.
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
How about the patch below?
Looks good, with two details:
+templatetypename _RealType
+ class uniform_on_sphere_helper2, _RealType
+ {
+ typedef typename uniform_on_sphere_distribution2, _RealType::
+ result_type result_type;
+
+ public:
+ templatetypename _NormalDistribution,
+typename _UniformRandomNumberGenerator
+ result_type operator()(_NormalDistribution,
+ _UniformRandomNumberGenerator __urng)
+{
+ result_type __ret;
+ _RealType __sq;
+ std::__detail::_Adaptor_UniformRandomNumberGenerator,
+ _RealType __aurng(__urng);
+
+ do
+ {
+ __ret[0] = __aurng();
I must be missing something obvious, but normal_distribution uses:
__x = result_type(2.0) * __aurng() - 1.0;
to get a number between -1 and 1, and I don't see where you do this
rescaling. Does __aurng() already return a number in the right interval in
this context? If so we may want to update our naming of variables to make
that clearer.
+ __ret[1] = __aurng();
+
+ __sq = __ret[0] * __ret[0] + __ret[1] * __ret[1];
+ }
+ while (__sq == _RealType(0) || __sq _RealType(1));
+
+ // Yes, we do not just use sqrt(__sq) because hypot() is more
+ // accurate.
+ auto __norm = std::hypot(__ret[0], __ret[1]);
Assuming the 2 coordinates are obtained through a rescaling x-2*x-1, if
__sq is not exactly 0, it must be between 2^-103 and 1 (for ieee
double), so I am not sure hypot gains that much (at least in my mind
hypot was mostly a gain close to 0 or infinity, but maybe it has more
advantages). It can only hurt speed though, so not a big issue.
--
Marc Glisse
Re: [PATCH] libstdc++: add uniform on sphere distribution
On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse marc.gli...@inria.fr wrote: __x = result_type(2.0) * __aurng() - 1.0; You're right, we of course need the negatives as well. Assuming the 2 coordinates are obtained through a rescaling x-2*x-1, if __sq is not exactly 0, it must be between 2^-103 and 1 (for ieee double), so I am not sure hypot gains that much (at least in my mind hypot was mostly a gain close to 0 or infinity, but maybe it has more advantages). It can only hurt speed though, so not a big issue. Depending on how similar in size the two values are, not using hypot() can drop quite a few bits. Especially with the scaling through division this error can be noticeable. Better be sure. Maybe at some point I have time to investigate the worst case scenario for the numbers in question but until this shows hypot isn't needed it's best to leave it in. I've committed the patch.
Re: [C PATCH] Implement -Wc90-c99-compat (PR c/51849)
On Thu, Aug 07, 2014 at 05:10:43PM +, Joseph S. Myers wrote: On Thu, 31 Jul 2014, Marek Polacek wrote: A few issues: currently we don't warn (in -std=c90 -pedantic mode) about the usage of __func__ and _Pragma (possible others - va_copy?). I'm hoping this is not that important though. For restrict/inline, in GNU90 mode we just don't compile the code at all (unless we use __restrict and similar), and -Wc90-c99-compat does not warn about those. And, -pedantic -Wno-c90-c99-compat - outside C99 mode - doesn't disable the relevant warnings (I'd think of it as logically like -pedantic -Wno-long-long, so it should disable them, while leaving all the -pedantic diagnostics for features that aren't in C99). Though I think implementing that could reasonably be a followup fix. E.g., in C90 mode, -Wlong-long is more specific than -Wc90-c99-compat, which is more specific than -pedantic. So the long long warnings should be determined by any explicit -W(no-)long-long if given, otherwise by any -W(no-)c90-c99-compat if given, otherwise by -pedantic, following the general rule of the most specific option taking precedence (and command-line order only being relevant when multiple variants of the same option are used, e.g. -Wlong-long -Wno-long-long). Outside C90 mode, -pedantic is irrelevant to such warnings; -W(no-)long-long should take precedence over -W(no-)c90-c99-compat if both are used. For warnings without a more specific option such as -Wlong-long, of course it's a bit simpler. Yeah, makes sense. I just finished testing a patch that implements the above; will post it momentarily. a specific option. OK with that change. Fixed, thanks for reviewing this. Marek
[C PATCH] Tidy up pedwarn_c90
This patch fixes the issue that -pedantic -Wno-c90-c99-compat outside
C99 didn't disable the compat warnings (except -Wvariadic-macros that
is enabled by default). It turned out to be quite
hairy. Also I noticed a bug that -Wno-declaration-after-statement
didn't disable the warning in C90 -pedantic as it should. Furthermore,
the patch brings a little cleanup to pedwarn_c90, so that we don't have
to play tricks with pedantic !flag_isoc99 and OPT_Wpedantic when using
a special option such as -Wvla or -Wlong-long - this allowed me to drop
some code. (-Wlong-long is even more special in the way it's set in
sanitize_cpp_opts...)
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-08-09 Marek Polacek pola...@redhat.com
gcc/c-family/
* c-opts.c (sanitize_cpp_opts): Make warn_long_long be set according
to warn_c90_c99_compat.
* c.opt (Wc90-c99-compat, Wdeclaration-after-statement): Initialize
to -1.
gcc/c/
* c-decl.c (warn_variable_length_array): Pass OPT_Wvla unconditionally
to pedwarn_c90.
* c-errors.c: Include opts.h.
(pedwarn_c90): Rewrite to handle -Wno-c90-c99-compat better.
* c-parser.c (disable_extension_diagnostics): Handle negative value
of warn_c90_c99_compat, too.
(restore_extension_diagnostics): Likewise.
(c_parser_compound_statement_nostart): Pass
OPT_Wdeclaration_after_statement unconditionally to pedwarn_c90.
gcc/testsuite/
* gcc.dg/Wc90-c99-compat-4.c: Remove all dg-warnings.
* gcc.dg/Wc90-c99-compat-5.c: Remove all dg-errors.
* gcc.dg/Wc90-c99-compat-7.c: New test.
* gcc.dg/Wdeclaration-after-statement-4.c: New test.
libcpp/
* charset.c (_cpp_valid_ucn): Warn only if -Wc90-c99-compat.
* lex.c (_cpp_lex_direct): Likewise.
* macro.c (replace_args): Likewise.
(parse_params): Likewise.
* include/cpplib.h (cpp_options): Change cpp_warn_c90_c99_compat
to char.
diff --git gcc/gcc/c-family/c-opts.c gcc/gcc/c-family/c-opts.c
index 43a8b9d..b0cad20 100644
--- gcc/gcc/c-family/c-opts.c
+++ gcc/gcc/c-family/c-opts.c
@@ -1299,10 +1299,13 @@ sanitize_cpp_opts (void)
/* Wlong-long is disabled by default. It is enabled by:
[-Wpedantic | -Wtraditional] -std=[gnu|c]++98 ; or
- [-Wpedantic | -Wtraditional] -std=non-c99 .
+ [-Wpedantic | -Wtraditional] -std=non-c99 ; or
+ -Wc90-c99-compat, if specified.
Either -Wlong-long or -Wno-long-long override any other settings. */
- if (warn_long_long == -1)
+ if (warn_long_long == -1 warn_c90_c99_compat != -1)
+warn_long_long = warn_c90_c99_compat;
+ else if (warn_long_long == -1)
warn_long_long = ((pedantic || warn_traditional)
(c_dialect_cxx () ? cxx_dialect == cxx98 :
!flag_isoc99));
cpp_opts-cpp_warn_long_long = warn_long_long;
diff --git gcc/gcc/c-family/c.opt gcc/gcc/c-family/c.opt
index 356a79f..087eabd 100644
--- gcc/gcc/c-family/c.opt
+++ gcc/gcc/c-family/c.opt
@@ -292,7 +292,7 @@ C ObjC C++ ObjC++ Warning
Warn when a built-in preprocessor macro is undefined or redefined
Wc90-c99-compat
-C ObjC Var(warn_c90_c99_compat) Warning
+C ObjC Var(warn_c90_c99_compat) Init(-1) Warning
Warn about features not present in ISO C90, but present in ISO C99
Wc++-compat
@@ -344,7 +344,7 @@ C++ ObjC++ Var(warn_ctor_dtor_privacy) Warning
Warn when all constructors and destructors are private
Wdeclaration-after-statement
-C ObjC Var(warn_declaration_after_statement) Warning
+C ObjC Var(warn_declaration_after_statement) Init(-1) Warning
Warn when a declaration is found after a statement
Wdelete-incomplete
diff --git gcc/gcc/c/c-decl.c gcc/gcc/c/c-decl.c
index 7ba35bf..138b014 100644
--- gcc/gcc/c/c-decl.c
+++ gcc/gcc/c/c-decl.c
@@ -4920,27 +4920,23 @@ check_bitfield_type_and_width (tree *type, tree *width,
tree orig_name)
static void
warn_variable_length_array (tree name, tree size)
{
- int const_size = TREE_CONSTANT (size);
- enum opt_code opt = (warn_vla == -1 !warn_c90_c99_compat)
- ? OPT_Wpedantic : OPT_Wvla;
-
- if (const_size)
+ if (TREE_CONSTANT (size))
{
if (name)
- pedwarn_c90 (input_location, opt,
+ pedwarn_c90 (input_location, OPT_Wvla,
ISO C90 forbids array %qE whose size
can%'t be evaluated, name);
else
- pedwarn_c90 (input_location, opt, ISO C90 forbids array
+ pedwarn_c90 (input_location, OPT_Wvla, ISO C90 forbids array
whose size can%'t be evaluated);
}
else
{
if (name)
- pedwarn_c90 (input_location, opt,
+ pedwarn_c90 (input_location, OPT_Wvla,
ISO C90 forbids variable length array %qE, name);
else
- pedwarn_c90 (input_location, opt, ISO C90 forbids variable
+ pedwarn_c90 (input_location, OPT_Wvla, ISO C90 forbids variable
length array);
}
}
RE: [PATCH mips] Pass -msoft-float/-mhard-float flags to GAS
Moore, Catherine catherine_mo...@mentor.com writes:
-Original Message-
From: Steve Ellcey [mailto:sell...@mips.com]
Sent: Friday, August 08, 2014 3:42 PM
To: Moore, Catherine; matthew.fort...@imgtec.com; echri...@gmail.com;
2014-08-08 Steve Ellcey sell...@mips.com
* config/mips/mips.h (ASM_SPEC): Pass float options to assembler.
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
8d7a09f..9a15287 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1187,6 +1187,8 @@ struct mips_cpu_info { %{mshared} %{mno-
shared} \ %{msym32} %{mno-sym32} \ %{mtune=*} \
+%{mhard-float} %{msoft-float} \
+%{msingle-float} %{mdouble-float} \
%(subtarget_asm_spec)
/* Extra switches sometimes passed to the linker. */
Hi Steve,
The patch itself looks okay, but perhaps a question for Matthew.
Does the fact that the assembler requires -msoft-float even if .set
softfloat is present in the .s file deliberate behavior?
The assembler requires -msoft-float if .gnu_attribute 4,3 is given. I.e. the
overall module options must match the ABI which has been specified. .set
directives can still be used to override the 'current' options and be
inconsistent with the overall module and/or .gnu_attribute setting.
I don't have a problem with passing along the *float* options to gas, but
would hope that the .set options were honored as well.
Yes they should be.
My short test indicated that the .set *float* options were being ignored if
the correct command line option wasn't present.
I'm not certain what you are describing here. Could you confirm with an example
just in case something is not working as expected?
Thanks,
Matthew
Fix side case in ipa-devirt
Hi,
tree-ssa-pre is checking that new dynamic type detection (get_dynamic_type)
catch all cases as old.
Firefox has somewhat obscure case when new code runs into placement new
paranoia earlier.
This patch fixes it and also fixes templates of last two testcases that had
unresolved tests.
* g++.dg/ipa/devirt-35.C: Fix template.
* g++.dg/ipa/devirt-36.C: Likewise.
* g++.dg/ipa/devirt-37.C: New testcase.
* ipa-devirt.c (get_dynamic_type): Handle case when instance is in
DECL correctly; do not give up on types in static storage.
Index: testsuite/g++.dg/ipa/devirt-35.C
===
--- testsuite/g++.dg/ipa/devirt-35.C(revision 213757)
+++ testsuite/g++.dg/ipa/devirt-35.C(working copy)
@@ -15,9 +15,9 @@ m(struct B *b)
// test2 may change the type of A by placement new.
// C++ standard is bit imprecise about this.
}
-/* { dg-final { scan-ipa-dump converting indirect call to function virtual
int B::t fre1 } } */
+/* { dg-final { scan-tree-dump converting indirect call to function virtual
int B::t fre1 } } */
/* { dg-final { scan-ipa-dump to virtual int B::t devirt } } */
/* { dg-final { scan-ipa-dump 1 speculatively devirtualized devirt } } */
/* { dg-final { cleanup-ipa-dump devirt } } */
-/* { dg-final { cleanup-tree-dump fre } } */
+/* { dg-final { cleanup-tree-dump fre1 } } */
Index: testsuite/g++.dg/ipa/devirt-37.C
===
--- testsuite/g++.dg/ipa/devirt-37.C(revision 0)
+++ testsuite/g++.dg/ipa/devirt-37.C(revision 0)
@@ -0,0 +1,35 @@
+/* { dg-options -fpermissive -fno-indirect-inlining
-fno-devirtualize-speculatively -fdump-tree-fre2-details } */
+#include stdlib.h
+struct A {virtual void test() {abort ();}};
+struct B:A
+ {virtual void test() {}
+B();
+B(void (*test)(struct A *));};
+
+void extcall(void);
+
+inline void tt(struct A *a)
+{
+ a-test();
+}
+
+B::B (void (*test)(struct A *))
+{
+ struct B c;
+ struct A *a=this;
+ extcall();
+ test(a);
+}
+void
+t()
+{
+ struct B b(tt);
+}
+/* After inlining the call within constructor needs to be checked to not go
into a basetype.
+ We should see the vtbl store and we should notice extcall as possibly
clobbering the
+ type but ignore it because b is in static storage. */
+/* { dg-final { scan-tree-dump Determined dynamic type. fre2 } } */
+/* { dg-final { scan-tree-dump Checking vtbl store: fre2 } } */
+/* { dg-final { scan-tree-dump Function call may change dynamic type:extcall
fre2 } } */
+/* { dg-final { scan-tree-dump converting indirect call to function virtual
void fre2 } } */
+/* { dg-final { cleanup-tree-dump fre2 } } */
Index: testsuite/g++.dg/ipa/devirt-36.C
===
--- testsuite/g++.dg/ipa/devirt-36.C(revision 213757)
+++ testsuite/g++.dg/ipa/devirt-36.C(working copy)
@@ -17,9 +17,9 @@ m(struct B *b)
// test2 may change the type of A by placement new.
// C++ standard is bit imprecise about this.
}
-/* { dg-final { scan-ipa-dump converting indirect call to function virtual
int B::t fre1 } } */
+/* { dg-final { scan-tree-dump converting indirect call to function virtual
int B::t fre1 } } */
/* { dg-final { scan-ipa-dump to virtual int B::t devirt } } */
/* { dg-final { scan-ipa-dump 1 speculatively devirtualized devirt } } */
/* { dg-final { cleanup-ipa-dump devirt } } */
-/* { dg-final { cleanup-tree-dump fre } } */
+/* { dg-final { cleanup-tree-dump fre1 } } */
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 213757)
+++ ipa-devirt.c(working copy)
@@ -2799,10 +2799,12 @@ get_dynamic_type (tree instance,
/* Finally verify that what we found looks like read from
OTR_OBJECT
or from INSTANCE with offset OFFSET. */
if (base_ref
- TREE_CODE (base_ref) == MEM_REF
- ((offset2 == context-offset
- TREE_OPERAND (base_ref, 0) == instance)
- || (!offset2 TREE_OPERAND (base_ref, 0) ==
otr_object)))
+ ((TREE_CODE (base_ref) == MEM_REF
+ ((offset2 == context-offset
+TREE_OPERAND (base_ref, 0) == instance)
+ || (!offset2 TREE_OPERAND (base_ref, 0) ==
otr_object)))
+ || (DECL_P (instance) base_ref == instance
+ offset2 == context-offset)))
{
stmt = SSA_NAME_DEF_STMT (ref);
instance_ref = ref_exp;
@@ -2923,7 +2925,14 @@ get_dynamic_type (tree instance,
!function_entry_reached
!tci.multiple_types_encountered)
{
-
[patch, Fortran] Fix for PR 61999, dot_product simplification
Hello world,
the attached patch fixes the regression by converting the arguments
to dot_product to the proper types.
Regression-tested on x86_64-unknown-linux-gnu.
OK for all affected branches (trunk, 4.9 and 4.8)?
Thomas
2014-08-10 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/61999
* simplify.c (gfc_simplify_dot_product): Convert types of
vectors before calculating the result.
2014-08-10 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/61999
* gfortran.dg/dot_product_3.f90: New test case.
Index: simplify.c
===
--- simplify.c (Revision 213778)
+++ simplify.c (Arbeitskopie)
@@ -1882,6 +1882,9 @@
gfc_expr*
gfc_simplify_dot_product (gfc_expr *vector_a, gfc_expr *vector_b)
{
+
+ gfc_expr temp;
+
if (!is_constant_array_expr (vector_a)
|| !is_constant_array_expr (vector_b))
return NULL;
@@ -1888,8 +1891,14 @@
gcc_assert (vector_a-rank == 1);
gcc_assert (vector_b-rank == 1);
- gcc_assert (gfc_compare_types (vector_a-ts, vector_b-ts));
+ temp.expr_type = EXPR_OP;
+ gfc_clear_ts (temp.ts);
+ temp.value.op.op = INTRINSIC_NONE;
+ temp.value.op.op1 = vector_a;
+ temp.value.op.op2 = vector_b;
+ gfc_type_convert_binary (temp, 1);
+
return compute_dot_product (vector_a, 1, 0, vector_b, 1, 0, true);
}
! { dg-do compile }
! { dg-options -fdump-tree-original }
! PR 61999 - this used to ICE.
! Original test case by A. Kasahara
program main
use, intrinsic:: iso_fortran_env, only: output_unit
implicit none
write(output_unit, *) dot_product([1, 2], [2.0, 3.0])
stop
end program main
! { dg-final { scan-tree-dump-times 8\\.0e\\+0 1 original } }
! { dg-final { cleanup-tree-dump original } }
Re: [patch, Fortran] Fix for PR 61999, dot_product simplification
On Sun, Aug 10, 2014 at 12:27:47AM +0200, Thomas Koenig wrote: the attached patch fixes the regression by converting the arguments to dot_product to the proper types. Regression-tested on x86_64-unknown-linux-gnu. OK for all affected branches (trunk, 4.9 and 4.8)? Yes. -- Steve
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 8/10/14 0:55, Chen Gang wrote: On 8/1/14 6:36, Jeff Law wrote: make make check It is OK (I finish the 2 steps under Mac book). save various .sum files Excuse me, I can not find it with `find ./ | grep \.sum$` [...] compare .sum files After comparing, should the related .sum files be the same (same means pass checking)? Oh! I guess ... means optional steps, make make check are enough for simple modification. And I shall send the trivial patch directly, if it really needs additional necessary steps, please reply that thread. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
[PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes
For [%d] in sprintf(), theoretically, the maximize size is 14 -- for
0x8000, it is sizeof([-2147483648]). Normally, it may not cause
real world bug, but if another issues occur, it may lead things worse.
It passes make make check under x86_64-apple-darwin13.3.0.
2014-08-09 Chen Gang gang.chen.5...@gmail.com
* c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 14 bytes.
---
gcc/c/c-aux-info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/c/c-aux-info.c b/gcc/c/c-aux-info.c
index 4b6b2d0..b7eacd7 100644
--- a/gcc/c/c-aux-info.c
+++ b/gcc/c/c-aux-info.c
@@ -311,7 +311,7 @@ gen_type (const char *ret_val, tree t, formals_style style)
else
{
int size = (int_size_in_bytes (t) / int_size_in_bytes (TREE_TYPE
(t)));
- char buff[10];
+ char buff[14];
sprintf (buff, [%d], size);
ret_val = gen_type (concat (ret_val, buff, NULL),
TREE_TYPE (t), style);
--
1.8.5.2 (Apple Git-48)
