On 22 July 2013 21:16, Eric Botcazou wrote:
>> And if df_live is non-zero, do we need update df_lr's IN and OUT? I think
>> we need another patch to make all these consistency.
>
> Possibly, but this would belong to another patch. I nevertheless think that
> we
> should set the bit in the GEN se
2013/7/30 Janus Weil :
>>> The attached new version should do the right thing now. At least it
>>> shows the correct dump for the original test case as well as yours. It
>>> is currently being regtested.
>>
>> unfortunately it shows a couple of runtime problems with type-bound
>> operators:
>>
>>
Hi,
thanks for the email I was supposed to write.
On Mon, Jul 29, 2013 at 02:20:02PM -0400, David Malcolm wrote:
> On Thu, 2013-07-25 at 15:08 +0200, Martin Jambor wrote:
> > Hi,
> >
> > I don't know why it's me again but again I do have a few comments.
>
> Thanks for looking over the patch.
>
Hi,
On Mon, Jul 29, 2013 at 09:02:53PM +0200, Oleg Endo wrote:
> On Mon, 2013-07-29 at 14:20 -0400, David Malcolm wrote:
> > >
> > > The same here and at a few other places. It may be just me not being
> > > used to references... nevertheless, if someone really wants to use
> > > them like this,
On 29/07/13 14:58, Kyrylo Tkachov wrote:
Hi all,
Now that combine emits the canonical form for (eq (neg x) (y)) instead of (eq
(x) (neg y)), this patch fixes up the corresponding pattern in aarch64 to
match that. This enables combine to properly generate the cmn instruction
where appropriate.
T
On Tue, 23 Jul 2013, Steve Ellcey wrote:
> While doing some space optimization work with mips16 I found that using a
> larger case threshold value could shrink the code. I did testing on some
> libraries like libpng and libjpeg as well as some test cases I wrote and
> came up with 10 as the best
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
> Ive been poking at this today, and Im wondering what you think of the idea of
> adding a flag to MODIFY_EXPR,
> #define MODIFY_EXPR_IS_COMPOUND(NODE)
> MODIFY_EXPR_CHECK(NODE)->base.asm_written_flag
>
> and set that in the MODIFY_EXPR node when we crea
Hi,
as noticed by Martin we ICE when value profiles get mismatch only in some
values.
This seems to be happening on Firefox 8 for weird reason where we optimize out
&sym == &sym2 comparsion at profile-use but not at profile-generate time. We
are
still looking into that problem, but this patch fi
On Mon, Jul 29, 2013 at 4:26 PM, Paolo Carlini wrote:
> Ah, excellent. As usual, let's wait a day or so for further comments and
> then please commit the whole thing.
Commited.
--
Tim Shen
Just to confirm that the patch successfully regtested on
x86_64-unknown-linux-gnu.
thanks,
Alexander
2013/7/29 Alexander Ivchenko :
> 2013/7/28 Michael Eager :
>> On 07/27/13 15:18, Alexander Ivchenko wrote:
>>>
>>> Hi Joseph, thanks for your comments.
>>>
>>> I updated the patch:
>>
>>
>>>
>>>
On 07/30/2013 07:41 AM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
Ive been poking at this today, and Im wondering what you think of the idea of
adding a flag to MODIFY_EXPR,
#define MODIFY_EXPR_IS_COMPOUND(NODE)
MODIFY_EXPR_CHECK(NODE)->base.asm_written_flag
and set tha
Hi,
this issue, error recovery in C++98 mode, is a bit tricky: as far as I
can see, it boils down to the fact that in C++98 mode we don't want to
handle specially std::initializer_list. Otherwise, after the error
message we crash in convert_like_real where we try to handle ck_list, @
line 605
On Tue, 30 Jul 2013, Andrew MacLeod wrote:
> > A flag on the expression could indicate that the floating-point semantics
> > are required. I'd guess back ends would need to provide three insn
> > patterns, corresponding to feholdexcept, feclearexcept and feupdateenv,
> > that there'd be correspon
Fallout from when I started checking for abstract classes as function
parameter types; if we see an incomplete type when we check for
abstractness, we save it to a list and check it again later when it's
complete. But we shouldn't do that in SFINAE context. This change is
already on the trunk
We need to use break_out_target_exprs for unsharing the constexpr body,
because unshare_expr doesn't unshare TARGET_EXPRs.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 405d150804256f94e63101f35535098c9e74438b
Author: Jason Merrill
Date: Mon Jul 29 16:12:56 2013 -0400
PR
Our movdi_aarch64 pattern allows moving a constant into an FP_REG,
but has the constraint Dd, which is stricter than the one for
moving a constant into a CORE_REG. This is due to restricted values
allowed for MOVI instructions.
Due to the predicate for the pattern allowing any constant that is
va
How about just returning false from is_std_init_list in C++98 mode?
Jason
If you compile the following C++ code at -O for Linux or Solaris:
int exchange (int *loc, int val)
{
return __atomic_exchange_4 (loc, val, __ATOMIC_SEQ_CST);
}
you get in the assembly file:
_Z8exchangePii:
.LLFB0:
mov %o0, %g1
membar 2
mov %o1, %o0
swap
On 07/30/2013 09:16 AM, Joseph S. Myers wrot
My reasoning for such a flag is:
Hence my suggestion that the operands to the new built-in function /
operation do not include the unmodified RHS, and do not directly specify
the operation in question. Instead, one operand is an expression of the
f
Hi,
symtab nodes are (ab)used to prevent removal of debug info from functions that
appear as
abstract origins of other functions. I am not sure if this is the best way to
do so,
but the code is fundamentaly broken on few places and it seems to make sense to
get it working
before thinking what w
This adds missing -static-libubsan option. It's already handled in
the gcc.c via various macros.
Tested x86_64-pc-linux-gnu, applying to ubsan branch.
diff --git a/gcc/ChangeLog.ubsan b/gcc/ChangeLog.ubsan
index 3d15c19..47f81b4 100644
--- a/gcc/ChangeLog.ubsan
+++ b/gcc/ChangeLog.ubsan
@@ -1,3
This is something I've stumbled upon when trying to bootstrap with
-fsanitize=undefined (doesn't work so far...). It's pretty serious
stuff, but clang doesn't handle it either... We errored on e.g.
enum e { x = 1 << 1 };
because of the instrumentation. Fixed by doing the instrumentation only
whe
This adds the bootstrap-ubsan.mk file so that
--with-build-config=bootstrap-ubsan be possible. I doesn't work yet,
though :(.
Tested x86_64-pc-linux-gnu, applying to ubsan branch.
diff --git a/config/ChangeLog.ubsan b/config/ChangeLog.ubsan
new file mode 100644
index 000..f7a2125
--- /dev/nu
This is only a cleanup; build_constructor_va is much more convenient
than build_constructor when we know the number of elements in
a constructor.
Tested x86_64-pc-linux-gnu, applying to ubsan branch.
diff --git a/gcc/ChangeLog.ubsan b/gcc/ChangeLog.ubsan
index 47f81b4..311a15c 100644
--- a/gcc/Ch
Hi,
On 07/30/2013 03:30 PM, Jason Merrill wrote:
How about just returning false from is_std_init_list in C++98 mode?
Sure. It works great.
Thanks,
Paolo.
/cp
2013-07-30 Paolo Carlini
PR c++/57947
* call.c (is_std_init_list): Return false if cxx_dialect
Thank you for the reply.
I am in the process of modifying the patch according to some comments received.
Currently I am considering the usage of DECL_BIT_FIELD_REPRESENTATIVE.
I see that they can be used during analysis phase for deciding which accesses
can be merged - only accesses with same repr
Apparently I forgot to check rs6000.h when doing the flag_asan
-> flag_sanitize change. This broke bootstrap on ppc.
Tested powerpc64-unknown-linux-gnu, applying to ubsan branch.
diff --git a/gcc/ChangeLog.ubsan b/gcc/ChangeLog.ubsan
index 311a15c..ac584ff 100644
--- a/gcc/ChangeLog.ubsan
+++ b/
When we have the DSP multiply extension (armv5e and up for ARM or T2),
then a 16-bit multiply is best done with smulbb rather than mul. This
saves us doing redundant extends and may even be a faster instruction on
some cores. Unfortunately, expand does not try this operation by
default; but i
Most arm target configs now require a 64-bit HW-int. Unfortunately a
few of the older, less commonly used config targets do not. The code in
arm.c now pretty much requires that a 64-bit HW-int is used, especially
for vectorization to work.
This patch makes 64-bit HW-int the default for all a
On Mon, Jul 29, 2013 at 11:24 AM, Tom Tromey wrote:
> This converts the C++ front end.
>
> This renames g++spec.o to cp/g++spec.o for uniformity.
> This lets us remove an explicit rule.
>
> This patch does not remove various *_H macros from cp/Make-lang.in.
> These are still needed by ObjC++. The
OK.
On 07/26/2013 01:15 PM, Andrew MacLeod wrote:
This patch adds an atomic type qualifier to GCC. It can be accessed
via __attribute__((atomic)) or in C11 mode via the _Atomic keyword.
What it does:
* All the __atomic builtins now expect an atomic qualified value for
the atomic variable. Non
On Tue, 2013-07-30 at 11:18 +0100, Maciej W. Rozycki wrote:
>
> -- it may be that the tests have to be disabled at -Os just like e.g.
> code-readable-1.c already is at -O0.
>
> Maciej
Sorry about that, not sure why I didn't notice the failures. Rather
then skipping the tests for -Os I was th
On Tue, Jul 30, 2013 at 04:34:14PM +0200, Marek Polacek wrote:
> This adds the bootstrap-ubsan.mk file so that
> --with-build-config=bootstrap-ubsan be possible. I doesn't work yet,
> though :(.
One of the reasons is that we use -Werror and e.g. on the following
testcase
static int x;
void
foo (
On 07/30/2013 02:07 PM, Tim Shen wrote:
On Mon, Jul 29, 2013 at 4:26 PM, Paolo Carlini wrote:
Ah, excellent. As usual, let's wait a day or so for further comments and
then please commit the whole thing.
Commited.
The bootstrap is currently broken due to this commit. I'm quickly moving
inline
This patch adds an atomic qualifier to the type node. it sets up
atomic{QHSDT}I_type_node types upon startup and used the alignment
target hook to override alignment if need be.
Whenever new atomic types are created, they will inherit this alignment
setting if they would otherwise be aligned
Teach the front ends to handle __attribute__((atomic)) and set the
ATOMIC_TYPE bit in the type tree.
Also add RID_ATOMIC and recognize the _Atomic keyword, and treat it like
__attribute__((atomic)) was specified.
Places that set TREE_THIS_VOLATILE and TREE_SIDE_EFFECTS for volatile
symbols a
.. no, too many changes, please simply revert the commit ASAP and next
time please test more carefully before posting.
Thanks,
Paolo.
This patch changes all the __Atomic built-in functions to take a pointer
to an atomic volatile object instead of just a volatile object.
This will allow the atomic operations to work with any requested
alignment change for a target.
I am not adding support for the __sync built-ins to expect t
This patch adds a target hook which a target can use to override the
alignment of the lock-free atomic type for a given mode.
Andrew
* hooks.c (hook_uint_mode_0): Return 0 unit hook.
* hooks.h (hook_uint_mode_0): Prototype.
* target.def (atomic_align_for_mode): define hook.
* tm.texi (TAR
This patch turns on the atomic qualifier for all C++ atomic objects
It also modifies a few testcases to ensure __attribute__((atomic)) and
_Atomic are recognized by the compiler and compile as expected.
libstdc++-v3
* include/bits/atomic_base.h (struct __atomic_base): Add
__attribute__((a
On Sun, Jul 28, 2013 at 3:03 PM, Maxim Kuvyrkov wrote:
> While verifying license compliance for GCC and its libraries I noticed that
> several libgcc files that end up in the final library are licensed under
> GPL-3.0+ instead of GPL-3.0-with-GCC-exception.
>
> This is, obviously, was not the in
Hi,
we currently fail to parse this rather simple NSDMI usage (note that
wrapping the whole initializer in parentheses works around the problem
because cp_parser_cache_group handles the special case).
Simply detecting that we are parsing an ellipsis in an nsdmi and not
ending the main while
On 07/25/2013 05:36 PM, DJ Delorie wrote:
I tried to reproduce the original bugs that led to these patterns, but
was unable. Testsuite results are the same with and without, and
eembc code size doesn't change.
So, I'm removing these patterns from the port.
The remaining (subreg...) patterns ar
On 07/23/2013 04:08 PM, DJ Delorie wrote:
Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 201184)
+++ gcc/cfgexpand.c (working copy)
I thought I already approved this. Go ahead and install it.
Index: gcc/simplif
On Mon, 29 Jul 2013, Maciej W. Rozycki wrote:
> > > These stubs are I believe not really covered in our testing, because
> > > they
> > > require a mixed standard-MIPS/MIPS16 environment.
> >
> > What's the barrier to testing a mixed environment? The normal *-linux-gnu
> > configurations have
On Tue, 30 Jul 2013, Steve Ellcey wrote:
> > -- it may be that the tests have to be disabled at -Os just like e.g.
> > code-readable-1.c already is at -O0.
>
> Sorry about that, not sure why I didn't notice the failures. Rather
> then skipping the tests for -Os I was thinking it might be better
> > Index: gcc/cfgexpand.c
> > ===
> > --- gcc/cfgexpand.c (revision 201184)
> > +++ gcc/cfgexpand.c (working copy)
> I thought I already approved this. Go ahead and install it.
Sorry, I forgot to split out those three patches when
Hello
This change allows to complete profiledbootstrap on the google gcc-4.8
branch, tested with make bootstrap with no new regressions. OK for
google 4.8?
thanks, Dinar.
profiledbootstrap-fix.patch
Description: Binary data
On Tue, 2013-07-30 at 11:30 +0200, Martin Jambor wrote:
> Hi,
>
> On Mon, Jul 29, 2013 at 09:02:53PM +0200, Oleg Endo wrote:
> > On Mon, 2013-07-29 at 14:20 -0400, David Malcolm wrote:
> > > >
> > > > The same here and at a few other places. It may be just me not being
> > > > used to references
> So it's a little unclear to me which patterns you removed. Your message
> has two patterns attached with comments they were to work around reload
> issues. Are these the patterns you removed?
Yes. I was unable to reproduce the reload problems to which those
comments referred.
> First, if
cc'ing Rong and David since this came from LIPO support.
The patch as-is removes the one use of PARAM_GCOV_DEBUG (which is on
by default) without removing the parameter itself. What is the failure
mode you see from this code?
Thanks,
Teresa
On Tue, Jul 30, 2013 at 11:50 AM, Dinar Temirbulatov
w
On Mon, 2013-07-29 at 13:56 -0600, Jeff Law wrote:
> On 07/26/2013 09:04 AM, David Malcolm wrote:
[...snip quote of ChangeLog...]
> So as has been discussed elsewhere I'd like to see pipeline changed to
> pass_manager.
>
> WRT references. Not being a C++ guy, I'd always mentally equated
> refer
I need to understand why this affects profile bootstrap -- is this due
to file name conflict?
The fix is wrong -- please do not remove the parameter. If it is a
problem, a better fix is to change the default parameter value to 0.
David
On Tue, Jul 30, 2013 at 11:56 AM, Teresa Johnson wrote:
>
Steve Ellcey writes:
> 2013-07-30 Steve Ellcey
>
> * gcc.target/mips/code-readable-1.c: Increase switch size.
> * gcc.target/mips/code-readable-2.c: Ditto.
> * gcc.target/mips/code-readable-3.c: Ditto.
> * gcc.target/mips/code-readable-4.c: Ditto.
OK, thanks.
Richard
OK.
Jason
We have seen the issue before. It does fail the profile boostrap as it
reads a wrong gcda file.
I thought it had been fixed. (The fix was as David mentioned, setting
the default value of the parameter to 0).
-Rong
On Tue, Jul 30, 2013 at 12:02 PM, Xinliang David Li wrote:
> I need to understand
>I need to understand why this affects profile bootstrap -- is this due
>to file name conflict?
Yes, It is simple. During the profiledbootstrap on x86_64 platform for
libiberty the compiler picks an incorrect profile from the current
directory(non-pic version), while compiling pic version, and
prof
Ok. Rong, can you help commit the parameter default setting patch?
thanks,
David
On Tue, Jul 30, 2013 at 12:48 PM, Rong Xu wrote:
> We have seen the issue before. It does fail the profile boostrap as it
> reads a wrong gcda file.
> I thought it had been fixed. (The fix was as David mentioned, s
Will do.
The patch was in gcc-4_7 by Dehao.
r194713 | dehao | 2012-12-24 16:49:06 -0800 (Mon, 24 Dec 2012) | 5 lines
Fix the profiled bootstrap:
1. Set the default value of gcov-debug to be 0.
2. Merge profile summaries from different instrumented binaries.
On Tue, Jul 30, 2013 at 12:58 PM, Xi
On 07/23/2013 12:08 PM, DJ Delorie wrote:
> ===
> --- gcc/simplify-rtx.c(revision 201184)
> +++ gcc/simplify-rtx.c(working copy)
> @@ -5884,12 +5884,23 @@ simplify_immed_subreg (enum machine_mode
> /* Simplify SUBREG:O
On 07/30/2013 12:47 PM, DJ Delorie wrote:
+; Note: using POPM.A #1 is two bytes smaller than using POPX.A
+
+(define_insn "movsipsi2"
+ [(set (match_operand:PSI0 "register_operand" "=r")
+ (subreg:PSI (match_operand:SI 1 "register_operand" "r") 0))]
+ "TARGET_LARGE"
+ "
On 07/30/2013 12:51 PM, DJ Delorie wrote:
First, if you can handle ASHIFT directly in PSImode, that's advantageous
for address calculations.
Yup, I have patterns for 1 and 2 bit shifts, which are all that really
happen. They look remarkably like your patterns, but use a subreg on
0 instead o
The following patch forces the command line match for -ansi option
in LIPO use build. Otherwise, it gets various undefined symbol errors.
This is exposed in LIPO random grouping test.
Tested with google internal benchmarks and gcc regression test.
2013-07-30 Rong Xu
* gcc/coverage.c (
On Tue, Jul 30, 2013 at 1:44 PM, Rong Xu wrote:
> The following patch forces the command line match for -ansi option
> in LIPO use build. Otherwise, it gets various undefined symbol errors.
Parsing error as you have clarified.
> This is exposed in LIPO random grouping test.
>
> Tested with googl
I have some preliminary comments. Mostly just related to code style
and missing documentation.
David
>
> #define DEFAULT_AUTO_PROFILE_FILE "fbdata.afdo"
>
> struct SourceLocation
Is using Upper case in struct names allowed?
> {
> tree func_decl;
> unsigned lineno;
> };
>
> typedef std::vect
Hi again,
I reverted the commit and tested that mainline is fine again.
Just to clarify how we normally handle these issues in v3: *temporarily*, to
avoid the linkage issues which broke the bootstrap today, all the non-template
functions must be inline, even if large. In the past normally we
On 07/30/2013 03:31 AM, Eric Botcazou wrote:
> 2013-07-30 Eric Botcazou
>
> * config/sparc/sparc.c (sparc_emit_membar_for_model) : Add
> the implied StoreLoad barrier for atomic operations if before.
Looks good.
r~
On Wed, Jul 31, 2013 at 6:10 AM, Paolo Carlini wrote:
> I reverted the commit and tested that mainline is fine again.
Sorry for the accident!
> Just to clarify how we normally handle these issues in v3: *temporarily*, to
> avoid the linkage issues which broke the bootstrap today, all the
> non
On Wed, Jul 31, 2013 at 6:44 AM, Tim Shen wrote:
> On Wed, Jul 31, 2013 at 6:10 AM, Paolo Carlini
> wrote:
>> I reverted the commit and tested that mainline is fine again.
>
> Sorry for the accident!
>
>> Just to clarify how we normally handle these issues in v3: *temporarily*, to
>> avoid the
Hi,
On 07/31/2013 12:44 AM, Tim Shen wrote:
I see. So I include in different files and then compile them
together, it broke. I've make every non-templated function in this
commit inline. Now it compiles. Sorry again for this commit.
Did you actually bootstrap & test the patch? Because you didn
On Wed, Jul 31, 2013 at 7:03 AM, Paolo Carlini wrote:
> Did you actually bootstrap & test the patch? Because you didn't last time,
> right?
I compiled it and run the 28_regex testsuite, nothing wrong happened
because there're all single-file testcases in it;
but I ignored the duplicated definitio
Hi,
On 07/31/2013 01:11 AM, Tim Shen wrote:
On Wed, Jul 31, 2013 at 7:03 AM, Paolo Carlini wrote:
Did you actually bootstrap & test the patch? Because you didn't last time,
right?
I compiled it and run the 28_regex testsuite, nothing wrong happened
because there're all single-file testcases i
Maciej,
When I run two of your new tests in gcc.target/mips (nan-legacy.c and
nans-legacy.c), they are failing because my GCC is putting out
.word 4294967295
instead of
.word -1
like the test is expecting.
I believe they are equivalent (0x) but I am not sure what
On Wed, Jul 31, 2013 at 7:18 AM, Paolo Carlini wrote:
> Please post the complete patch you intend to commit. Part of the GCC policy
> is also that all the patches must be posted complete, exactly as would be
> committed upon approval.
Here it is.
--
Tim Shen
bfs.patch
Description: Binary dat
On 07/31/2013 01:26 AM, Tim Shen wrote:
On Wed, Jul 31, 2013 at 7:18 AM, Paolo Carlini wrote:
Please post the complete patch you intend to commit. Part of the GCC policy
is also that all the patches must be posted complete, exactly as would be
committed upon approval.
Here it is.
Ok, thanks.
On Mon, 2013-07-29 at 14:01 -0600, Jeff Law wrote:
> On 07/26/2013 09:04 AM, David Malcolm wrote:
> > Introduce a new gen-pass-instances.awk script, and use it at build time
> > to make a pass-instances.def from passes.def.
> >
> > An example of the result can be seen at:
> >
> >http://dmalcolm
[nickc added for comments about the bits he wrote]
> ... define these as
>
> (define_predicate "msp_general_operand"
> (match_code "mem,reg,subreg,const_int,const,symbol_ref,label_ref"
> {
> int save_volatile_ok = volatile_ok;
> volatile_ok = 1;
> int ret = general_operand (op, mode);
>
OK
- Joey
> -Original Message-
> From: Terry Guo
> Sent: Wednesday, July 24, 2013 16:15
> To: Joey Ye
> Cc: gcc-patches@gcc.gnu.org
> Subject: [arm-embedded] Patch to define multilibs for arm embedded-4_8-
> branch
>
> Hi Joey,
>
> This patch is to define multilibs for recently created
I found some other wired problems in that patch after committing.
Probably need more time to work on it, so now I revert it :(
--
Tim Shen
Hi,
Please find the patch to add assembler option "-mcu" for generating assembler
error messages when target not supporting hardware FPU were seeing FPU code,
namely RX100 and RX200.
KPIT has recently submitted a patch to add warnings of RX variants that do not
have hardware FPU support,
http://w
Running
make -C gcc check RUNTESTFLAGS='--target_board=unix/-fsanitize=undefined
dg.exp=*const-expr*' unveiled a pretty stupid bug: we should
instrument expression only when it's actually needed, not otherwise.
On the C++ FE this is handled right, the thinko was only in C FE.
Tested x86_64-unknown
82 matches
Mail list logo
