On Fri, 2013-10-25 at 17:37 -0400, David Malcolm wrote:
> This patch addresses various forms of failure described in
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01974.html
>
> It adds a "default: gcc_unreachable();" to the autogenerated switch()
> statement in the routines for a base class, con
Ok with the change.
David
On Fri, Oct 25, 2013 at 6:17 PM, Dehao Chen wrote:
> Most are within 10. The largest one I see is 17 across all benchmark.
>
> Dehao
>
> On Fri, Oct 25, 2013 at 4:21 PM, Xinliang David Li wrote:
>> What is the usual number of iterations?
>>
>> David
>>
>> On Fri, Oct 2
Most are within 10. The largest one I see is 17 across all benchmark.
Dehao
On Fri, Oct 25, 2013 at 4:21 PM, Xinliang David Li wrote:
> What is the usual number of iterations?
>
> David
>
> On Fri, Oct 25, 2013 at 4:10 PM, Dehao Chen wrote:
>> If the propagation finds an infinite look, if the i
I've committed this patch to C11-atomic branch with more miscellaneous
fixes. The compiler changes and additions to c11-atomic-3.c are based
on reviewing existing C/ObjC front-end code for constructs likely to
need updating to handle atomics. In addition, execution test coverage
is added for lang
What is the usual number of iterations?
David
On Fri, Oct 25, 2013 at 4:10 PM, Dehao Chen wrote:
> If the propagation finds an infinite look, if the in-edge count is
> non-zero, then it will cause compiler go into infinite loop when
> building with AutoFDO.
>
> Bootstrapped and regression test o
Looks good.
David
On Fri, Oct 25, 2013 at 4:04 PM, Rong Xu wrote:
> Hi,
>
> This patch writes out ggc_memory to gcda files.
>
> Google branches only. Test is ongoing. OK to check-in after test passes?
>
> -Rong
Christian Bruel wrote:
> No regressions for -m2 and -m4 for sh-elf.
> OK for trunk ?
OK with the change of ChangeLog entry suggested by your another mail.
Thanks!
Regards,
kaz
If the propagation finds an infinite look, if the in-edge count is
non-zero, then it will cause compiler go into infinite loop when
building with AutoFDO.
Bootstrapped and regression test on-going.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
Hi,
This patch writes out ggc_memory to gcda files.
Google branches only. Test is ongoing. OK to check-in after test passes?
-Rong
2013-10-25 Rong Xu
* contrib/profile_tool (ModuleInfo): write out ggc_memory to gcda file.
* gcc/gcov-io.c (gcov_read_module_info): Ditto.
Hi!
And here is a patch that allows vectorization without peeling for alignment
and scalar loop for bound even for fn2, fn3 and fn4 in the following
testcase, though as with the range __builtin_unreachable () notes, it is
quite fragile, because it only works if there are no immediate uses of the
t
On Fri, 25 Oct 2013, Tobias Burnus wrote:
> Tobias Burnus wrote:
> > Jason Merrill wrote:
> > > I would think that a range-based loop over an array should vectorize
> > > nicely:
> > [...]
> > Therefore, I will send a follow up patch.
>
> Attached is that patch [C++].
>
> [C/C++:] Additionally,
This patch addresses various forms of failure described in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01974.html
It adds a "default: gcc_unreachable();" to the autogenerated switch()
statement in the routines for a base class, converting various kinds of
tag errors from leading to silent lack-of
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58759
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 204080.
2013-10-25 Vladimir Makarov
PR rtl-optimization/58759
* lra-constraints.c (lra_constraints): Remove
On 10/25/13 10:26, Joseph S. Myers wrote:
On Fri, 25 Oct 2013, Richard Biener wrote:
Ok with preserving options as dummy, see examples like
fargument-alias
Common Ignore
Does nothing. Preserved for backward compatibility.
I don't think we should sorry (), but we can certainly warn that
mudfla
I've committed the following patch to use LRA for ppc. By default
reload pass is used. To use LRA, please add option -mlra.
I also removed change in constraints for swap insn as it was
requested by David Edelsohn. It was necessary to fix one failure of new
gcc tests. I'll work on more
Tobias Burnus wrote:
Jason Merrill wrote:
I would think that a range-based loop over an array should vectorize
nicely:
[...]
Therefore, I will send a follow up patch.
Attached is that patch [C++].
[C/C++:] Additionally, as Jakub proposed and other compilers also
support, the patch accepts
Tobias Burnus wrote:
Thanks for looking at the patch. However, the patch has a link
problem. The documentation is at
http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
That's also the link I use in the changes.html file. However, some
script changes the link to:
http://gcc.gn
On Fri, Oct 25, 2013 at 03:30:47PM -0400, Diego Novillo wrote:
> On 2013-10-10 14:07 , tsaund...@mozilla.com wrote:
> >This makes the implementation of stack vectors simpler and easier to use.
> >This
> >
On Fri, 25 Oct 2013, Mike Stump wrote:
> On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
> >> I too would like to include this change on those branches, as
> >> recent generic newlib changes has caused these tests to break
> >> (regress) fo
On 2013-10-10 14:07 , tsaund...@mozilla.com wrote:
This makes the implementation of stack vectors simpler and easier to use. This
works by
making
Jakub Jelinek wrote:
FYI, I'm seeing various new FAILs on i686-linux:
+FAIL: gcc.dg/vect/vect-ivdep-1.c (test for warnings, line )
+FAIL: gcc.dg/vect/vect-ivdep-1.c -flto (test for warnings, line )
+FAIL: gfortran.dg/vect/vect-do-concurrent-1.f90 -O (test for warnings, line
)
+FAIL: g++.dg/
> > Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
> > when it's really one.
>
> Well, it's not really a lie if you map hardware registers 22 and 23 to
> a single register for the purposes of gcc internals.
Yeah, I'm basically making those two registers into a permanent bigg
On 10/25/2013 03:03 PM, Marek Polacek wrote:
On Fri, Oct 25, 2013 at 02:17:48PM -0400, Jason Merrill wrote:
I think the right place to handle both ubsan and c++1y VLA checks is
in compute_array_index_type, in the block where we're calling
variable_size.
I'm sorry, you want me to move the c++1y
On 10/25/2013 01:53 PM, Eric Botcazou wrote:
This has introduced a problem for the -fdump-ada-spec machinery, which boils
down to the TYPE_METHODS field of the following structure:
struct _outer {
struct _inner {
int x;
} inner;
} outer;
Previously it was empty, now it contain
On Fri, Oct 25, 2013 at 02:17:48PM -0400, Jason Merrill wrote:
> On 10/25/2013 12:58 PM, Marek Polacek wrote:
> >I've tried to implement the instrumentation in cp_finish_decl.
> >However, the problem is with multidimensional arrays, e.g. for
> >
> >int x = -1;
> >int a[1][x];
> >
> >array_of_runtim
On 10/25/2013 12:58 PM, Marek Polacek wrote:
I've tried to implement the instrumentation in cp_finish_decl.
However, the problem is with multidimensional arrays, e.g. for
int x = -1;
int a[1][x];
array_of_runtime_bound_p returns false, thus we don't instrument this
at all, nor throw an exceptio
2013/10/25 Jeff Law :
> On 10/21/13 05:49, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> This patch introduces built-in functions used by Pointers Checker and flag
>> to enable Pointers Checker. Builtins available for user are expanded in
>> expand_builtin. All other builtins are not allowed in expand until
> Late in the C++11 process it was decided that a constructor or
> destructor can be trivial but not callable; as a result, everywhere that
> assumed that a call to a trivial function didn't need any processing
> needed to be updated. This patch does that.
This has introduced a problem for the -f
Hi!
The following patch makes use of the computed nonzero_bits preserved
in the SSA_NAME_RANGE_INFO.
I chose to write a new routine instead of improving current
highest_pow2_factor, because that routine didn't care about overflows etc.
and by working on ctz numbers instead of powers of two in UHWI
On Thu, 2013-10-10 at 09:56 +0200, Richard Biener wrote:
> As a general observation I don't like the
>
> if (pass->has_foo_member_function)
>pass->foo_member_function ()
>
> style. It is totally against the idea of having virtual functions. Why
> not simply provide stub implementations in
On Fri, 25 Oct 2013, Richard Biener wrote:
you can followup with handling POINTER_PLUS_EXPR if you like.
Like this? (bootstrap+testsuite on x86_64-unknown-linux-gnu)
2013-10-26 Marc Glisse
gcc/
* tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Look for a
POINTER_PLUS_EXP
On Thu, Oct 24, 2013 at 03:57:17PM -0400, Jason Merrill wrote:
> On 09/25/2013 08:41 AM, Marek Polacek wrote:
> >+ /* Do the instrumentation of VLAs if desired. */
> >+ if ((flag_sanitize & SANITIZE_VLA)
> >+ && size && !TREE_CONSTANT (size)
> >+ /* From C++1y onwards, we throw an exce
On Fri, 25 Oct 2013, Richard Biener wrote:
> Btw, the C++ standard doesn't cover packed or aligned attributes so
> we could declare this a non-issue. Any opinion on that?
I think the memory model naturally applies to packed structures (i.e.,
writes to fields in them should not write to any othe
On Fri, 25 Oct 2013, Richard Biener wrote:
> Ok with preserving options as dummy, see examples like
>
> fargument-alias
> Common Ignore
> Does nothing. Preserved for backward compatibility.
>
> I don't think we should sorry (), but we can certainly warn that
> mudflap was replaced by -fsanitize=
On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson wrote:
> On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
>> On Mon, 21 Oct 2013, Mike Stump wrote:
>>
>>> On Oct 21, 2013, at 3:28 AM, Vidya Praveen wrote:
Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
can
On 10/25/13 03:29, Marc Glisse wrote:
It doesn't get lost, but this is the missed optimization that malloc
results still alias with global pointers (here a function argument).
Taking into account the offset shouldn't change anything.
I think this is a different issue (but if you say improving
On Thu, Oct 24, 2013 at 09:17:55PM +0200, Tobias Burnus wrote:
> 2013-08-24 Tobias Burnus
>
> PR other/33426
> * g++.dg/parse/ivdep.C: New.
> * g++.dg/vect/pr33426-ivdep.cc: New.
FYI, I'm seeing various new FAILs on i686-linux:
+FAIL: gcc.dg/vect/vect-ivdep-1.c (test for war
OK.
Jason
Hi,
here the issue is that we fail to detect shadowing declarations in
inline member function templates. The reason is the following check in
check_template_shadow:
if (decl == olddecl
- || TEMPLATE_PARMS_FOR_INLINE (current_template_parms))
+ || (DECL_TEMPLATE_PARM_P (decl)
+
Hi,
On Thu, Oct 24, 2013 at 01:02:51AM +0200, Steven Bosscher wrote:
> On Wed, Oct 23, 2013 at 6:46 PM, Martin Jambor wrote:
>
> > /* Perform the second half of the transformation started in
> > @@ -4522,7 +4704,15 @@ ira (FILE *f)
> > allocation because of -O0 usage or because the functio
On Fri, Oct 25, 2013 at 10:29:41AM -0400, Ed Smith-Rowland wrote:
> 2013-10-25 Edward Smith-Rowland <3dw...@verizon.net>
>
> PR c++/58708
> * parser.c (make_string_pack): Discover non-const type and size
> of character and build parm pack with correct type and chars.
>
> gcc
On 10/25/2013 04:29 PM, Ed Smith-Rowland wrote:
Here is one with necessary tools inlined.
You still have a lot of redundant code... I'm not going to insist anyway.
Paolo.
On 10/25/2013 10:01 AM, Paolo Carlini wrote:
On 10/25/2013 03:46 PM, Ed Smith-Rowland wrote:
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++
front-end
On 10/25/2013 10:01 AM, Paolo Carlini wrote:
On 10/25/2013 03:46 PM, Ed Smith-Rowland wrote:
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++
front-end
> "Andrew" == Andrew Pinski writes:
>> enum raw_str_phase phase = RAW_STR_PREFIX;
Andrew> This is a good work around but please add a comment of why this is
Andrew> needed (to work around a bug in XLC++).
I agree.
It's ok with this update.
thanks,
Tom
On 10/25/2013 04:22 PM, Tim Shen wrote:
On Fri, Oct 25, 2013 at 10:12 AM, Paolo Carlini
wrote:
Ah good. Can't you just have split_bfs.cc defining the
_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT macro and including the existing
split.cc?
Here :) Hack the __FILE__ macro to let it report correctly.
Uhm,
On 07/09/13 18:54, Jason Merrill wrote:
> OK.
>
I've reproduced the same problem with the 4.7 and 4.8 branch, and checked that
applying the patch fixes the problem.
Committed to 4.7 and 4.8 branch as well.
Thanks,
- Tom
In the ChangeLog, the entry
* gcc/config/sh/sh-mem.cc (sh_expand_cmpnstr): Moved here.
is instead
* gcc/config/sh/sh-mem.cc (sh_expand_cmpnstr): New function.
Sorry for this,
Christian
Hello,
This patch implements the cmpstrnsi pattern to support the strncmp
builtin for constant lengths. The cmp/str instructions is used for size
>= 8 bytes, else fall back to the byte-at-a-time check to favor small
strings.
I now also handle the cases where align is known for both cmpstr and
cmp
Hi,
On 10/25/2013 04:05 PM, Tim Shen wrote:
On Fri, Oct 25, 2013 at 5:07 AM, Paolo Carlini wrote:
Ok. Are there measurable performance changes at this point? I'm asking
because we should take the chance and add performance testcases when we
improve the performance: later, unless somebody files
On 10/25/2013 03:46 PM, Ed Smith-Rowland wrote:
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++ front-end
testcase doesn't, why not.
Paolo.
I think
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++ front-end
testcase doesn't, why not.
Paolo.
I think this patch should be sufficient - no containers,
But it's nothing to do with construction inside
memory_address_addr_space but with validity of an address construct.
first thing memory_address_addr_space does is deconstructing
address_mode from as parameter. But if one doesn't pass actual mode
there's not way to find it and call to legitimate_add
Hi,
On Fri, Oct 25, 2013 at 12:51:13PM +0200, Richard Biener wrote:
> On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger
> wrote:
> > Hi,
> >
> >> Eh ... even
> >>
> >> register struct { int i; int a[0]; } asm ("ebx");
> >>
> >> works. Also with int a[1] but not with a[2]. So just handling trailing
On 25 October 2013 05:15, DJ Delorie wrote:
>
> Yup, my registers are smaller than Pmode.
>
> This is what I ended up with...
>
> Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
> when it's really one.
Well, it's not really a lie if you map hardware registers 22 and 23 to
a si
On Fri, 25 Oct 2013, Tobias Burnus wrote:
Marc Glisse wrote:
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it m
On Fri, 25 Oct 2013, Jan Hubicka wrote:
> > > OK, so it is about 2%. Did you try if you need lookahead even in the
> > > early pass (before reload)? My guess would be so, but if not, it could
> > > cut the cost to half. For -Ofast/-O3 it looks resonable to me, but we
> > > will need to anno
> > OK, so it is about 2%. Did you try if you need lookahead even in the early
> > pass (before reload)? My guess would be so, but if not, it could cut the
> > cost to half. For -Ofast/-O3 it looks resonable to me, but we will need
> > to announce it on the ML. For other settings I think we
This patch prevents the use of requires expressions in non-template
scopes. This restriction was relaxed in the most recent version of
concepts lite, but the implementation requires some thought. For now,
I am marking it an error to make it consistent with previous versions
of the spec.
2013-10-25
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++ front-end
testcase doesn't, why not.
Paolo.
On 10/25/2013 06:08 AM, Paolo Carlini wrote:
Hi,
On 10/18/2013 04:42 AM, Ed Smith-Rowland wrote:
--- testsuite/g++.dg/cpp1y/pr58708.C (revision 0)
+++ testsuite/g++.dg/cpp1y/pr58708.C(working copy)
@@ -0,0 +1,70 @@
+// { dg-options -std=c++1y }
+
+#include
+#include
+#include
+#include
Hi,
On Fri, 25 Oct 2013 11:26:20, Richard Biener wrote:
>
> On Fri, Oct 25, 2013 at 10:40 AM, Bernd Edlinger
> wrote:
>> Hello,
>>
>> this patch fixes the recently discovered data store race on arm-eabi-gcc
>> with -fno-strict-volatile-bitfields
>> for structures like this:
>>
>> #define test_ty
Marc Glisse wrote:
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am a bit afraid of
losing some
Hi, GCC global reviewers,
I would like to thank Joseph Myers's preliminary review and
Richard Sandiford's help for further technical review in these
three months:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01138.html
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01180.html
Their comments cle
Hi, all,
This is v4 patch for Andes nds32 port on machine description part 3,
which includes other rtl patterns and settings.
gcc/
2013-10-25 Chung-Ju Wu
Shiva Chen
* config/nds32/constants.md: New file.
* config/nds32/constraints.md: New file.
* config/n
Hi,
I had a look to the testcases Jason added / tweaked in his recent patch
about trivial but non-callable [cd]tors: I think a simple testcase
directly from 54812 cannot hurt.
Thanks,
Paolo.
2013-10-25 Paolo Carlini
PR c++/54812
* g++.dg/cpp0x/defaulted47
On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger
wrote:
> Hi,
>
>> Eh ... even
>>
>> register struct { int i; int a[0]; } asm ("ebx");
>>
>> works. Also with int a[1] but not with a[2]. So just handling trailing
>> arrays makes this case regress as well.
>>
>> Now I'd call this use questionable ..
On Fri, Oct 25, 2013 at 12:39:58PM +0200, Paolo Carlini wrote:
> On 10/23/2013 09:16 PM, Jason Merrill wrote:
> >The second hunk adds %X for printing an exception-specification in
> >diagnostics.
>
> In my experience these convenience %? that we have got easily
> trigger warnings during bootstrap/
On Fri, 25 Oct 2013, Richard Biener wrote:
Ah, so you are looking at call_may_clobber_ref_p_1 and its pointer handling
when special-casing builtins?
Yes.
Note that fields can only be disambiguated
if the size of the access is known
TBAA could also help sometimes.
(not sure what fancy att
Hi,
On 10/23/2013 09:16 PM, Jason Merrill wrote:
The second hunk adds %X for printing an exception-specification in
diagnostics.
In my experience these convenience %? that we have got easily trigger
warnings during bootstrap/build, eg:
/scratch/Gcc/svn-dirs/trunk/gcc/cp/error.c:3302:53: war
Hi,
On 10/18/2013 04:42 AM, Ed Smith-Rowland wrote:
--- testsuite/g++.dg/cpp1y/pr58708.C(revision 0)
+++ testsuite/g++.dg/cpp1y/pr58708.C(working copy)
@@ -0,0 +1,70 @@
+// { dg-options -std=c++1y }
+
+#include
+#include
+#include
+#include
are you sure you want these includes in a C
Hi,
> Eh ... even
>
> register struct { int i; int a[0]; } asm ("ebx");
>
> works. Also with int a[1] but not with a[2]. So just handling trailing
> arrays makes this case regress as well.
>
> Now I'd call this use questionable ... but we've likely supported that
> for decades and cannot change th
On Fri, Oct 25, 2013 at 11:29 AM, Marc Glisse wrote:
> On Fri, 25 Oct 2013, Richard Biener wrote:
>
>> On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
>> wrote:
>>>
>>> On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse
>>> wrote:
On Thu, 24 Oct 2013, Jeff Law wrote:
> On 10/24/13
> Doesn't that also apply to arithmetic on symbols when the offset is NULL?
This can presumably be retrofitted when the offset is null or constant.
> But yes, the codegen example posted shows this kind of difference
> (though it doesn't seem to save anything for that case). I'd have expected
> a
On Fri, 25 Oct 2013, Richard Biener wrote:
On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
wrote:
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse wrote:
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find a
On Fri, Oct 25, 2013 at 10:40 AM, Bernd Edlinger
wrote:
> Hello,
>
> this patch fixes the recently discovered data store race on arm-eabi-gcc with
> -fno-strict-volatile-bitfields
> for structures like this:
>
> #define test_type unsigned short
>
> typedef struct s{
> unsigned char Prefix[1];
>
Hi!
tree-ssa-ccp.c already computes which bits are known to be zero, but
we preserve that info only for pointers and not for integers.
This patch changes SSA_NAME_RANGE_INFO, so we preserve that info even for
integers. The bitmask is also computed from range info.
There are no users of this besid
On Fri, Oct 25, 2013 at 8:29 AM, Bernd Edlinger
wrote:
> Hi Richard,
>
>
>>> Did you just propose:
>>>
>>> --- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
>>> +++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
>>> @@ -471,27 +471,7 @@
>>> static enum machine_mode
>>> mode_for_array (
On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
wrote:
> On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse wrote:
>> On Thu, 24 Oct 2013, Jeff Law wrote:
>>
>>> On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
informat
Hi,
On 10/24/2013 09:22 PM, François Dumont wrote:
Ok to commit ?
Looks great to me.
Thanks!
Paolo.
On 10/25/2013 06:30 AM, Tim Shen wrote:
This patch optimizes BFS executor by removing quantifier tracking, but
precisely control the assignment order of the variable recording the
optimal solution.
Ok. Are there measurable performance changes at this point? I'm asking
because we should take the
Hi!
As discussed on IRC, this patch attempts to preserve VRP computed
range info for some simple __builtin_unreachable () using assertions.
If there are no immediate uses of some SSA_NAME except for those in
a condition guarding __builtin_unreachable () and in ASSERT_EXPR
in the following basic bl
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse wrote:
> On Thu, 24 Oct 2013, Jeff Law wrote:
>
>> On 10/24/13 23:23, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> I noticed that in some cases we were failing to find aliasing
>>> information because we were only looking at an SSA_NAME variable,
>>> missi
2013/10/25 Uros Bizjak :
> Hello!
>
> 2013-10-25 Uros Bizjak
>
> * config/i386/i386.h (TARGET_MPX): New define.
> (TARGET_MPX_P): Ditto.
>
> Tested on x86_64-pc-linux-gnu, committed.
Thanks for fixing it!
>
> Uros.
Hello,
this patch fixes the recently discovered data store race on arm-eabi-gcc with
-fno-strict-volatile-bitfields
for structures like this:
#define test_type unsigned short
typedef struct s{
unsigned char Prefix[1];
test_type Type;
}__attribute((__packed__,__aligned__(4))) ss;
volatile ss
> Thanks. Installed on the trunk.
Well, no, that will be problematic for some architectures. The history of
this piece of code is complicated and it's admittedly lacking a comment, but
the purpose of the block is clear enough:
op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_SUM);
On Fri, Oct 25, 2013 at 3:17 AM, David Malcolm wrote:
> I noticed that some of the macros in tree.h that act on trees have
> parameters named "CODE", rather "NODE", which is confusing when in the
> presence of other macros that act on enum tree_code values.
>
> The attached patch renames such para
> OK, so it is about 2%. Did you try if you need lookahead even in the early
> pass (before reload)? My guess would be so, but if not, it could cut the
> cost to half. For -Ofast/-O3 it looks resonable to me, but we will need to
> announce it on the ML. For other settings I think we need to
On Thu, Oct 24, 2013 at 10:35 PM, Jeff Law wrote:
> On 10/24/13 07:40, Richard Biener wrote:
we were supposed to remove mudflap for 4.9, no?
>>> Really? I guess it hasn't been removed yet since the include is still
>>> there? who is doing that?
>>
>>
>> Yeah, nobody has done
On 24/10/13 20:03, Kugan wrote:
Hi Kyrill,
It happens for armv5te arm-none-linux-gnueabi. --with-mode=arm
--with-arch=armv5te --with-float=soft
Ah ok, I can reproduce it now. So, while I agree that we add a scan for vbit and
vbif to these testcases, there seems to be something dodgy going on
> Actually I think it's jfc's code; he had a major revamp of alias.c back
> in the early egcs days and getting it integrated was one of the
> project's early wins. Sadly, jfc hasn't been involved in GCC work for a
> long long time.
OK, thanks for the clarification.
> Anyway, I think the issue he
Dear all,
I have committed the patch below as obvious (Rev. 204049).
Seemingly, there are a lot of places which have to be updated for
a new OpenMP version ...
Tobias
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (Revision 204048
On Thu, 24 Oct 2013, Paolo Carlini wrote:
> Hi,
>
> this is just a preview, but I decided to send it out early to understand if
> I'm on the right track or not. As you can see in the Bug, this started as a
> spin-off of a library issue with complex pow, which led us to:
>
> __builtin_exp(-__
Hi!
Ping. To sum it up, with these patches applied, there are no changes for
a "regular" build (not using the new configure options). On the other
hand, configuring GCC as described, it is possible use the 32-bit x86
linker for/with a x86_64 build, and get the very same GCC test results as
when
On Fri, Oct 25, 2013 at 03:11:40AM +0200, Gerald Pfeifer wrote:
> Hi Tobias,
>
> On Thu, 24 Oct 2013, Tobias Burnus wrote:
> >the attached patch updates the gomp project patch.
> >
> >(Besides adding an item for the OpenMP 4.0 merge, I removed the "95" from
> >"Fortran 95" as Fortran is backward c
Hello!
2013-10-25 Uros Bizjak
* config/i386/i386.h (TARGET_MPX): New define.
(TARGET_MPX_P): Ditto.
Tested on x86_64-pc-linux-gnu, committed.
Uros.
Index: i386.h
===
--- i386.h (revision 204047)
+++ i386.h (wor
Adding Ilya.
On 25 October 2013 10:48, Tobias Burnus wrote:
> Hi Kirill,
>
> with the current trunk (newst "git" mirror version), bootstrapping fails
> here with the following error. Did you forget to commit one file?
>
>
> g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti
> -fasynchronous-unwind
97 matches
Mail list logo
