On Tue, Dec 03, 2013 at 09:43:51PM -0700, Jeff Law wrote:
> On 12/03/13 15:46, Jakub Jelinek wrote:
> >As described in the PR, the problem here is that during combine
> >i2 pattern is substituted into more than one place in i3 pattern,
> >unique_copy is 0 (but, even if it would be non-zero, it coul
On Tue, 3 Dec 2013 15:12:05, Richard Biener wrote:
>
> On Tue, Dec 3, 2013 at 2:10 PM, Richard Biener
> wrote:
>> On Tue, Dec 3, 2013 at 1:48 PM, Bernd Edlinger
>> wrote:
>>> Hi Jeff,
>>>
>>> please find attached the patch (incl. test cases) for the unaligned read
>>> BUG that I found while inve
On Wed, Dec 04, 2013 at 06:28:31AM +0100, Konstantin Serebryany wrote:
> We don't have any .cfi stuff in sanitizer_common (and I don't think we
> really need it in the internal_clone).
> Before fixing the tsan sources I'd like to see some indication that
> anyone cares about tsan working on older s
Hi Uros!
Attached is the revised patch.
The target independent part has been already approved and added.
This revision of the patch adds a x86 tune definition and checks it while
deciding the unroll factor.
Accommodated the comments given by you except one.
> *x will never be null for active i
On Mon, Dec 2, 2013 at 11:58 PM, Jakub Jelinek wrote:
> As discussed in the PR, combiner can combine e.g. unaligned integral
> load (e.g. TImode) together with some SSE instruction that requires aligned
> load, but doesn't actually check it. For AVX, most of the instructions
> actually allow una
On Wed, Dec 4, 2013 at 9:39 AM, Gopalasubramanian, Ganesh
wrote:
> Attached is the revised patch.
> The target independent part has been already approved and added.
>
> This revision of the patch adds a x86 tune definition and checks it while
> deciding the unroll factor.
>
> Accommodated the co
Hi Jeff,
to my understanding a leaf function is characterized by not calling another
function in its function
body. So for the patch the question is whether we consider the mcount call
belonging to the function
body or not. As I see it from the backends for all uses of is_leaf the function
body
Hi!
On Thu, 21 Nov 2013 20:20:45 -, ja...@gcc.gnu.org wrote:
> Author: jakub
> Date: Thu Nov 21 20:20:44 2013
> New Revision: 205231
>
> URL: http://gcc.gnu.org/viewcvs?rev=205231&root=gcc&view=rev
> Log:
> svn merge -r204964:205223 svn+ssh://gcc.gnu.org/svn/gcc/trunk
Jakub, many thanks for
> Fixed by making sure force_to_mode doesn't modify x in place.
I think that it's the way to go, force_to_mode doesn't modify its argument
except for these 2 cases. I'm not sure what the story is, but calling SUBST
for these 2 cases doesn't seem really necessary.
> Bootstrapped/regtested on x8
On Wed, Dec 04, 2013 at 10:20:20AM +0100, Uros Bizjak wrote:
> When "trap on unaligned" is activated, some program should not trap in
> different way due to compiler transformations. The optimized and
> unoptimized code should run (and trap) in the same way.
Ok.
Note, seems I have missed a i386/s
> I'd worry there's other latent bugs of this nature and if we'd be better
> off avoiding the temporary sharing. We have structure sharing rules for
> a reason -- I'd hate to think of all the code that would need auditing
> to ensure it was safe with this bogus sharing.
I wouldn't throw the baby
On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
wrote:
> On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
>> Yufeng Zhang wrote:
>> >On 12/03/13 14:20, Richard Biener wrote:
>> >> On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhang
>> >wrote:
>> >>> On 12/03/13 06:48, Jeff Law wrote:
>>
>> >>
On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
wrote:
> On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> wrote:
>> On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
>>> Yufeng Zhang wrote:
>>> >On 12/03/13 14:20, Richard Biener wrote:
>>> >> On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhang
>>
> Ouch... mem_count can be zero. Is there a reason to change this part from
> previous patch?
Oops! You're right. I will correct this.
The idea is to count the memory references and decide on the unrolling factor.
Previous patch does that in two steps I thought of doing that in a single step.
On Tue, Dec 3, 2013 at 11:54 PM, Xinliang David Li wrote:
> Done. Retested with the suggested change.
>
> Ok for trunk?
Ok.
Thanks,
Richard.
> thanks,
>
> David
>
> On Tue, Dec 3, 2013 at 2:13 AM, Richard Biener
> wrote:
>> On Mon, Dec 2, 2013 at 6:38 PM, Xinliang David Li wrote:
>>> Points t
On Wed, Dec 4, 2013 at 1:03 AM, Richard Sandiford
wrote:
> Richard Biener writes:
Looking at the implementation it seems it would also work with
return MIN (TREE_INT_CST_EXT_NUNITS (m_t), N / HOST_BITS_PER_WIDE_INT);
>>>
>>> Yeah, the MIN in the patch was probably bogus sorry.
On Wed, Dec 4, 2013 at 11:07 AM, Eric Botcazou wrote:
>> Fixed by making sure force_to_mode doesn't modify x in place.
>
> I think that it's the way to go, force_to_mode doesn't modify its argument
> except for these 2 cases. I'm not sure what the story is, but calling SUBST
> for these 2 cases d
On Wed, Dec 4, 2013 at 11:15 AM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 10:20:20AM +0100, Uros Bizjak wrote:
>> When "trap on unaligned" is activated, some program should not trap in
>> different way due to compiler transformations. The optimized and
>> unoptimized code should run (and tra
In Ada 2012 we now have case expressions, i.e. conditional expressions with
more than 2 choices, and this exposes an issue with the way such conditional
constructs are translated in gigi, resulting in released stack storage being
used in some cases.
Tested on x86_64-suse-linux, applied on the m
Sorry about the slow response. Been on holiday.
On 20/11/13 16:27, Renlin Li wrote:
Hi all,
This patch will make the arm back-end use vcvt for float to fixed point
conversions when applicable.
Test on arm-none-linux-gnueabi has been done on the model.
Okay for trunk?
+ (define_insn "*comb
In Ada we have the equivalent of bit-fields with zero size but they don't
behave as in C (or rather according to most ABIs) when it comes to the layout.
This patch makes it so that they are laid out manually instead of being passed
to stor-layout.c as for the other fields.
Tested on x86_64-suse-
On 12/04/13 10:30, Richard Biener wrote:
On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
wrote:
On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
wrote:
On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
Yufeng Zhang wrote:
On 12/03/13 14:20, Richard Biener wrote:
On Tue, Dec 3, 2013
Committed on Kugan's behalf as rev 205666.
Christophe.
On 3 December 2013 20:47, Jeff Law wrote:
> On 12/02/13 23:39, Kugan wrote:
>>>
>>>
>>> +2013-11-27 Kugan Vivekanandarajah
>>> +
>>> + * config/arm/bpapi-lib.h (TARGET_HAS_NO_HW_DIVIDE): Define for
>>> + architectures that do
> Of course various parties care about that. But that doesn't necessarily
> imply they can or want to run buildbots for a different compiler they don't
> care about, there are e.g. security implications to that, resources etc.
This brings us back to the initial issue: the way asan&co are develope
Richard Sandiford writes:
> This patch handles multiplications using a single HWIxHWI->2HWI multiplication
> on hosts that have one. This removes all uses of the slow (half-HWI) path
> for insn-recog.ii. The slow path is still used 58 times for cp/parser.ii
> and 168 times for fold-const.ii, but
On Wed, Dec 04, 2013 at 04:49:22PM +0400, Konstantin Serebryany wrote:
> I would start from kernel version and glibc version, this should cover
> the majority of use cases.
Well, for the kernel headers what we perhaps can do is just add
libsanitizer/include/linux/ tree that will be maintained by G
On Wed, 2013-12-04 at 11:26 +0100, Richard Biener wrote:
> On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> wrote:
> > On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
> >> Yufeng Zhang wrote:
> >> >On 12/03/13 14:20, Richard Biener wrote:
> >> >> On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zha
On Wed, 2013-12-04 at 11:30 +0100, Richard Biener wrote:
> On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
> wrote:
> > On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> > wrote:
> >> On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
> >>> Yufeng Zhang wrote:
> >>> >On 12/03/13 14:20, Richa
On Wed, 2013-12-04 at 11:32 +, Yufeng Zhang wrote:
> On 12/04/13 10:30, Richard Biener wrote:
> > On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
> > wrote:
> >> On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> >> wrote:
> >>> On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
> Y
On Wed, 2013-12-04 at 07:13 -0600, Bill Schmidt wrote:
> On Wed, 2013-12-04 at 11:30 +0100, Richard Biener wrote:
> > On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
> > wrote:
> > > On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> > > wrote:
> > >> On Tue, 2013-12-03 at 21:35 +0100, Richard Biene
On Wed, Dec 4, 2013 at 5:02 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 04:49:22PM +0400, Konstantin Serebryany wrote:
>> I would start from kernel version and glibc version, this should cover
>> the majority of use cases.
>
> Well, for the kernel headers what we perhaps can do is just add
On Wed, Dec 04, 2013 at 05:28:40PM +0400, Konstantin Serebryany wrote:
> > Well, for the kernel headers what we perhaps can do is just add
> > libsanitizer/include/linux/ tree that will be maintained by GCC and will
>
> if that works for you, no objections.
I haven't tried to do that yet, so don'
And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
split out of the huge patch. It really is dependent on the generic
parts, when commiting, I'll put both parts together.
Uros, would you mind taking a look at this?
Regtested/bootstrapped on x86_64-linux. Ok for trunk?
20
This is a repost of rebased version of the signed-integer-overflow
patch, split into generic parts and i?86 parts. By i?86 parts I mean
the stuff that resides in config/i386, I haven't really tried to
untangle it more.
Except the two formatting fixes I also moved various PROB_ macros into
predict.
On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> split out of the huge patch. It really is dependent on the generic
> parts, when commiting, I'll put both parts together.
Just a question (I will review the patch la
On 12/04/2013 07:56 AM, Richard Sandiford wrote:
Richard Sandiford writes:
This patch handles multiplications using a single HWIxHWI->2HWI multiplication
on hosts that have one. This removes all uses of the slow (half-HWI) path
for insn-recog.ii. The slow path is still used 58 times for cp/pa
On Wed, Dec 04, 2013 at 02:52:25PM +0100, Uros Bizjak wrote:
> On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> > And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> > split out of the huge patch. It really is dependent on the generic
> > parts, when commiting, I'll
On Wed, Dec 04, 2013 at 08:53:50AM +0100, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 08:49:32AM +0100, Aurelien Jarno wrote:
> > On sparc, the --with-long-double-128 option doesn't change anything for
> > a 64-bit compiler, as it always default to 128-bit long doubles. For
> > a 32/64-bit compi
On Wed, Dec 04, 2013 at 02:52:25PM +0100, Uros Bizjak wrote:
> On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> > And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> > split out of the huge patch. It really is dependent on the generic
> > parts, when commiting, I'll
[new subject. was: libsanitizer merge from upstream r196090]
>> .cfi is used only in tsan sources now, and tsan is not supported
>> anywhere but x86_64
>
> But the .cfi_* issue is platform independent. Whether the compiler
> decides to emit them or not depends on how it was configured, on assembl
On Tue, Dec 03, 2013 at 02:14:17PM -0700, Jeff Law wrote:
> Perhaps split this patch into two parts which can be reviewed
> independently, but go into the tree at the same time. The obvious
> hope would be that Uros or one of the other x86 backend folks could
> chime in on that part.
I posted the
On Wed, Dec 04, 2013 at 06:09:56PM +0400, Konstantin Serebryany wrote:
> This is a maintenance problem because we can not test if we broke
> something during development.
> e.g. clang doesn't seem to support -fno-dwarf2-cfi-asm
It does, at least both clang 3.3 (from Fedora 19) and clang
3.4 r19468
On Wed, Dec 4, 2013 at 5:44 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 05:28:40PM +0400, Konstantin Serebryany wrote:
>> > Well, for the kernel headers what we perhaps can do is just add
>> > libsanitizer/include/linux/ tree that will be maintained by GCC and will
>>
>> if that works for y
On Tue, Dec 3, 2013 at 6:55 PM, Gerald Pfeifer wrote:
> On Thu, 28 Nov 2013, Richard Biener wrote:
>> Why remove ChangeLog files, web pages and comments?
>
> I was going to complain about web pages being removed. :-)
>
> On Thu, 28 Nov 2013, Diego Novillo wrote:
>> -Fixes for obvious typos in Chan
Hi all,
This is the final patch in the series, adding the documentation for the
intrinsics. Most of it is autogenerated from neon-docgen.ml and the ones that
are not are added explicitly in neon-docgen.ml so that they appear in the
generated .texi file. Not much else to say on this patch.
Ok
Hi all,
This patch series implements the new arm_neon.h intrinsics that map down to the
ARMv8-A cryptographic instructions. The instructions are considered to be part
of NEON and they can be enabled by specifying -mfpu=crypto-neon-fp-armv8 (of
course we still need the hard or softfp float ABI)
On 12/03/2013 02:38 PM, Jeff Law wrote:
On 12/03/13 12:25, Kenneth Zadeck wrote:
On 12/03/2013 01:52 PM, Mike Stump wrote:
On Dec 2, 2013, at 10:26 PM, Jeff Law wrote:
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from
df*.[ch]
in combi
Looks good to me, but I cannot approve it.
Yufeng
On 12/03/13 21:24, Andrew Pinski wrote:
Hi,
The arguments to --with-multilib-list for AARCH64 are exclusive but
currently is being treated as ones which are not. This causes problems in that
we get four library sets with --with-multilib-l
I'm applying the following as obvious, GCC 4.7 doesn't grok -Wpedantic.
Sorry for not testing that properly.
2013-12-04 Marek Polacek
PR c/59351
testsuite/
* gcc.dg/pr59351.c: Use -pedantic instead of -Wpedantic.
--- gcc/testsuite/gcc.dg/pr59351.c.mp3 2013-12-04 16:49:17.2328
> > Well, it regresses against 4.8, so it still is a P1 regression.
>
> Does anyone care?
Well, you’re one of the maintainers of libsanitizer for GCC, so if you do not
care about regressions in your code, it makes little sense for GCC (the whole
project) to keep libsanitizer.
I’ve posted this
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33)
Hi,
Currently, on ARM, you have to either call abort() or raise(SIGTRAP)
to achieve a handy crash.
This patch allows you to instead call __builtin_trap() which is much
more efficient at falling over because it becomes just a single
instruction that will trap for you.
Two testcases have been adde
On Wed, Dec 4, 2013 at 8:06 AM, Tejas Belagod wrote:
> Thanks Richard. Here is a revised patch. Sorry about the delay - I was
> investigating to make sure an LRA ICE I was seeing on aarch64 was unrelated
> to this patch. I've added a test case that I expect to pass for aarch64.
> I've also added t
On 12/04/13 03:40, Richard Biener wrote:
On Wed, Dec 4, 2013 at 11:07 AM, Eric Botcazou wrote:
Fixed by making sure force_to_mode doesn't modify x in place.
I think that it's the way to go, force_to_mode doesn't modify its argument
except for these 2 cases. I'm not sure what the story is, bu
I think together with this patch, the default value for
--with-multilib-list when it is absent can be updated to "lp64,ilp32"
from "lp64" only. This will make the multi-lib default setting on
aarch64*-*-linux* consist that on aarch64*-*-elf. See gcc/config.gcc.
Thanks,
Yufeng
P.S. Copy&past
On Wed, Dec 4, 2013 at 8:04 AM, FX wrote:
>> > Well, it regresses against 4.8, so it still is a P1 regression.
>>
>> Does anyone care?
>
>
> Well, you’re one of the maintainers of libsanitizer for GCC, so if you do not
> care about regressions in your code, it makes little sense for GCC (the whol
On 12/04/13 07:20, Diego Novillo wrote:
On Tue, Dec 3, 2013 at 6:55 PM, Gerald Pfeifer wrote:
On Thu, 28 Nov 2013, Richard Biener wrote:
Why remove ChangeLog files, web pages and comments?
I was going to complain about web pages being removed. :-)
On Thu, 28 Nov 2013, Diego Novillo wrote:
> I believe this is a case where the GCC project gets more benefit from
> libsanitizer than libsanitizer gets from being part of the GCC
> project. We should work with the libsanitizer developers to make this
> work, not just push everything back on them.
You’re vastly better qualified than me to
On Wed, Dec 4, 2013 at 8:41 AM, Ian Lance Taylor wrote:
> On Wed, Dec 4, 2013 at 8:04 AM, FX wrote:
>>> > Well, it regresses against 4.8, so it still is a P1 regression.
>>>
>>> Does anyone care?
>>
>>
>> Well, you’re one of the maintainers of libsanitizer for GCC, so if you do
>> not care about
> I think libsanitizer should be disabled automatically if kernel or glibc are
> too old.
I think pretty much everyone agrees. But noone’s willing to put forward a
patch, and so far the libsanitizer maintainers have failed to even document the
requirements. (There are also binutils requirements,
On Wed, Dec 4, 2013 at 8:50 AM, FX wrote:
>> I think libsanitizer should be disabled automatically if kernel or glibc are
>> too old.
>
> I think pretty much everyone agrees. But noone’s willing to put forward a
> patch,
What are the agreed-upon minimum kernel and glibc? I
can give it a try.
>
On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
> > I believe this is a case where the GCC project gets more benefit from
> > libsanitizer than libsanitizer gets from being part of the GCC
> > project. We should work with the libsanitizer developers to make this
> > work, not just push ev
Hello,
MSVC and ICC (currently Windows version, Linux version soon) have
dedicated intrinsics to read/set EFLAGS register ([1], [2]).
Patch introduces these intrinsics and tests for them.
Bootstrapped. New tests pass.
Although gate is closed patch is obvious.
So, is it ok for trunk?
ChangeLog/
On Wed, Dec 4, 2013 at 8:58 AM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
>> > I believe this is a case where the GCC project gets more benefit from
>> > libsanitizer than libsanitizer gets from being part of the GCC
>> > project. We should work with the libs
On 12/04/13 06:44, Marek Polacek wrote:
This is a repost of rebased version of the signed-integer-overflow
patch, split into generic parts and i?86 parts. By i?86 parts I mean
the stuff that resides in config/i386, I haven't really tried to
untangle it more.
Except the two formatting fixes I als
On Wed, 4 Dec 2013, Ian Bolton wrote:
> The main update, other than cosmetic differences, is that we've chosen
> the same ARM encoding as LLVM for practical purposes. (The Thumb
> encoding in Mark's patch already matched LLVM.)
Do the encodings match what plain "udf" does in recent-enough gas (t
On Wed, Dec 4, 2013 at 11:24 AM, Jeff Law wrote:
> Here's feedback. Install it now :-)
Works for me :) Committed.
Diego.
On Wed, 4 Dec 2013, H.J. Lu wrote:
> The kernel and glibc check should be done at the toplevel.
> So what are the minimum kernel and glibc we want to
> support?
Checking those at toplevel is tricky in general because you're checking
something for the target rather than the host. You'd need to m
On 12/04/13 09:14, H.J. Lu wrote:
+
+/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
aarch64*-*-* } } } */
Any particular reason why it doesn't work for x86?
I don't think so. I'm pretty sure Tejas is focused on ARM platforms for
the obvious reason.
jeff
On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
> On 12/04/13 09:14, H.J. Lu wrote:
>
>>> +
>>> +/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
>>> aarch64*-*-* } } } */
>>
>>
>> Any particular reason why it doesn't work for x86?
>
> I don't think so. I'm pretty sure Tejas
On 3 December 2013 19:42, Cary Coutant wrote:
>> This patches gen_compile_unit_die to use the DW_LANG_D DWARF language
>> code for D. Is in relation to some other D language fixes that are
>> going to be submitted to gdb.
>
> Is this for a private front end? I'm not aware of any front ends that
>
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> Richard Sandiford wrote:
Tejas Belagod writes:
>> The problem is that one reg rtx can span several hard registers.
>> E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
>> but it might in
On 12/03/13 21:24, Andrew Pinski wrote:
Hi,
With ILP32 AARCH64, Pmode (DImode) != ptrmode (SImode) so the variable decl
has a mode of SImode while the register is DImode. So the target that gets
passed down to expand_builtin_thread_pointer is NULL as expand does not
know how to get a subreg f
> gcc/
> 2013-11-24 Tobias Burnus
>
> PR debug/37132
> * lto-streamer.h (LTO_tags): Add LTO_namelist_decl_ref.
> * tree.def (NAMELIST_DECL): Add.
> * tree.h (NAMELIST_DECL_ASSOCIATED_DECL): New macro.
> * tree.c (initialize_tree_contains_struct): Add asserts for it.
In C99, one way how to deal with inline functions is to put definition
of the function into header:
inline void foo (void) { /* ... */ }
and put the declaration into exactly one .c file, with extern keyword
(it can also have inline keyword):
extern void foo (void);
But in this case, we shouldn't is
On Wed, Dec 04, 2013 at 06:47:09PM +0100, Marek Polacek wrote:
> In C99, one way how to deal with inline functions is to put definition
> of the function into header:
> inline void foo (void) { /* ... */ }
> and put the declaration into exactly one .c file, with extern keyword
> (it can also have i
OK.
Jason
On Wed, Dec 04, 2013 at 06:47:09PM +0100, Marek Polacek wrote:
> In C99, one way how to deal with inline functions is to put definition
> of the function into header:
> inline void foo (void) { /* ... */ }
> and put the declaration into exactly one .c file, with extern keyword
> (it can also have i
On Wed, Dec 04, 2013 at 09:47:36AM -0800, Cary Coutant wrote:
> > gcc/
> > 2013-11-24 Tobias Burnus
> >
> > PR debug/37132
> > * lto-streamer.h (LTO_tags): Add LTO_namelist_decl_ref.
> > * tree.def (NAMELIST_DECL): Add.
> > * tree.h (NAMELIST_DECL_ASSOCIATED_DECL): New ma
Hello,
On 04 Dec 19:59, Kirill Yukhin wrote:
> So, is it ok for trunk?
Small correction. I think it is better to use
popfql/pushfql instead of popf/pushf (however they're
encoded equally).
--
Thanks, K
Ping for this patch, which is the only one of the series that hasn't
been approved.
Thanks,
Richard
Richard Sandiford writes:
> I have a patch to upgrade most genrecog warnings into errors. This patch
> fixes those for tilegx. There seemed to be two sources of warnings:
>
> - the intrinsics of
On Wed, Dec 4, 2013 at 9:58 AM, Kirill Yukhin wrote:
> Hello,
> On 04 Dec 19:59, Kirill Yukhin wrote:
>> So, is it ok for trunk?
>
> Small correction. I think it is better to use
> popfql/pushfql instead of popf/pushf (however they're
> encoded equally).
>
If you define the proper type, you can u
> On Wed, 4 Dec 2013, Ian Bolton wrote:
>
> > The main update, other than cosmetic differences, is that we've
> chosen
> > the same ARM encoding as LLVM for practical purposes. (The Thumb
> > encoding in Mark's patch already matched LLVM.)
>
> Do the encodings match what plain "udf" does in rece
On 04/12/13 16:05, Ian Bolton wrote:
Hi,
Currently, on ARM, you have to either call abort() or raise(SIGTRAP)
to achieve a handy crash.
This patch allows you to instead call __builtin_trap() which is much
more efficient at falling over because it becomes just a single
instruction that will trap
On 12/03/13 21:24, Andrew Pinski wrote:
Hi,
With ILP32, some simple usage of TLS variables causes an unrecognizable
instruction due to needing to use SImode for loading pointers from memory.
This fixes the three (tlsie_small, tlsle_small, tlsdesc_small) patterns to
support SImode for pointers.
On Wed, Dec 04, 2013 at 06:55:52PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 06:47:09PM +0100, Marek Polacek wrote:
> > In C99, one way how to deal with inline functions is to put definition
> > of the function into header:
> > inline void foo (void) { /* ... */ }
> > and put the declar
On Wed, 4 Dec 2013, Marek Polacek wrote:
> In C99, one way how to deal with inline functions is to put definition
> of the function into header:
> inline void foo (void) { /* ... */ }
> and put the declaration into exactly one .c file, with extern keyword
> (it can also have inline keyword):
> ext
On Wed, Dec 04, 2013 at 06:22:28PM +, Joseph S. Myers wrote:
> On Wed, 4 Dec 2013, Marek Polacek wrote:
>
> > In C99, one way how to deal with inline functions is to put definition
> > of the function into header:
> > inline void foo (void) { /* ... */ }
> > and put the declaration into exactl
On Wed, 4 Dec 2013, Marek Polacek wrote:
> I can, the question is whether we want that. Anyway, this is version
> which looks for the gnu_inline attribute.
If anything, I'd think it should apply to all inline functions. The point
of this warning is that non-static functions should be declared
On Wed, Dec 04, 2013 at 06:30:37PM +, Joseph S. Myers wrote:
> On Wed, 4 Dec 2013, Marek Polacek wrote:
>
> > I can, the question is whether we want that. Anyway, this is version
> > which looks for the gnu_inline attribute.
>
> If anything, I'd think it should apply to all inline functions.
On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> split out of the huge patch. It really is dependent on the generic
> parts, when commiting, I'll put both parts together.
>
> Uros, would you mind taking a look at th
On Wed, Dec 04, 2013 at 07:58:20PM +0100, Uros Bizjak wrote:
> > @@ -8617,6 +8740,49 @@
> >[(set_attr "type" "negnot")
> > (set_attr "mode" "SI")])
> >
> > +;; Negate with jump on overflow.
> > +(define_expand "negv3"
> > + [(parallel [(set (reg:CCO FLAGS_REG)
> > + (ne:CC
On Wed, Dec 4, 2013 at 5:59 PM, Kirill Yukhin wrote:
> MSVC and ICC (currently Windows version, Linux version soon) have
> dedicated intrinsics to read/set EFLAGS register ([1], [2]).
>
> Patch introduces these intrinsics and tests for them.
>
> Bootstrapped. New tests pass.
> Although gate is cl
On Wed, Dec 4, 2013 at 8:07 PM, Jakub Jelinek wrote:
>> > @@ -8617,6 +8740,49 @@
>> >[(set_attr "type" "negnot")
>> > (set_attr "mode" "SI")])
>> >
>> > +;; Negate with jump on overflow.
>> > +(define_expand "negv3"
>> > + [(parallel [(set (reg:CCO FLAGS_REG)
>> > + (ne:
On 12/03/2013 02:48 PM, Iyer, Balaji V wrote:
Now, after all that I must admit that cilk_spawn could only ever see
VEC_INIT_EXPR in the context of a lambda closure initialization, and the
default behavior should always be correct for a lambda closure initialization,
so I guess I'm willing to allo
On 12/03/2013 02:45 PM, Marek Polacek wrote:
You're right. I wanted to use cp_save_expr and/or stabilize_expr, but
that didn't work out. So I resorted to restrict the condition a bit
and only pass INDIRECT_REFs to the ubsan routine (which, after all,
has
if (!INDIRECT_REF_P (init))
retu
On Wed, Dec 04, 2013 at 08:23:22PM +0100, Uros Bizjak wrote:
> > My memory is fuzzy about that, but I think that was my first version which
> > didn't work, because with match_dup then it requires on the internal-fn.c
> > side to pass 4 arguments instead of just 3. I can try again though.
Weird,
On 12/04/13 09:06, Tejas Belagod wrote:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead repres
On Wed, Dec 4, 2013 at 9:01 PM, Jakub Jelinek wrote:
>> > My memory is fuzzy about that, but I think that was my first version which
>> > didn't work, because with match_dup then it requires on the internal-fn.c
>> > side to pass 4 arguments instead of just 3. I can try again though.
>
> Weird, n
OK, thanks.
Jason
1 - 100 of 125 matches
Mail list logo
