On Tue, Mar 29, 2016 at 10:13 PM, H.J. Lu wrote:
> Tested on x86-64. OK for trunk?
>
> H.J.
> ---
> PR testsuite/70364
> * gcc.target/i386/cleanup-1.c: Include .
> (check): New function.
> (bar): Call check.
> (foo): Align stack to 16 bytes when calling bar
On Tue, Mar 29, 2016 at 8:42 PM, Jason Merrill wrote:
> On 03/29/2016 06:37 AM, Jan Hubicka wrote:
>>>
>>> On Mon, Mar 28, 2016 at 11:26 PM, Jason Merrill wrote:
The constexpr evaluation code uses the inlining code to remap the
constexpr
function body for evaluation so that re
On Tue, Mar 29, 2016 at 7:16 PM, Jakub Jelinek wrote:
> On Tue, Mar 29, 2016 at 12:01:20PM -0500, Bill Schmidt wrote:
>> Again, this is good information to know about. But the "stuff" we were
>> talking about was the failures on powerpc*, and I took what you said to
>> mean that nobody was workin
On Wed, Mar 30, 2016 at 12:04 AM, Jan Hubicka wrote:
> Hi,
> this patch fixes stupid overflow in tree-ssa-loop-ivcanon.c.
> If the estimated number of execution of loop is INT_MAX+1 it will get peeled
> incorrectly.
>
> Bootstrapped/regtested x86_64-linux and committed (it is regression WRT the
>
On Wed, 23 Mar 2016, Richard Biener wrote:
>
> This reduces the compile-time for the testcase from PR12392 from
> ~50s to ~35s, dropping the alias-stmt walking time from 40% to around 8%.
>
> Currently (even when -fno-devirtualize-speculatively - heh) when
> looking for a must-def that specifies
On Tue, Mar 29, 2016 at 8:56 PM, H.J. Lu wrote:
> Since %ecx can't be used for both DRAP register and __builtin_eh_return,
> we need to check if crtl->drap_reg uses %ecx before using %ecx for
> __builtin_eh_return.
>
> Testing on x86-64. OK for trunk if there are no regressions?
>
>
> H.J.
> ---
On Thu, Mar 24, 2016 at 6:26 PM, Bin Cheng wrote:
> Hi,
> Quite lot of time is used when IVOPT computes cost for pairs. As
> a matter of fact, some pairs are very similar to each other, and we can
> abstract and compute cost only once for these pairs. This is a patch doing
> so, the idea is
On Mar 29, 2016, at 8:57 PM, Jeff Law wrote:
> I'm installing this on the trunk momentarily.
Thank you for the review.
On 29/03/16 19:46, Christophe Lyon wrote:
On 16 March 2016 at 16:54, Ramana Radhakrishnan
wrote:
On Wed, Feb 24, 2016 at 11:23 AM, Kyrill Tkachov
wrote:
Hi all,
This is the GCC 4.9 backport of
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01338.html.
The differences are that TARGET_HAVE_LPA
Hello Segher,
> On Mar 28, 2016, at 13:18 , Segher Boessenkool
> wrote:
>
>> You need to have had r11 last used to designate a global
>> symbol as part of the function body (in order to have base_term
>> designate a symbol_ref etc), and then have the scheduler
>> decide that moving across is a
On 24/03/16 21:02, Charles Baylis wrote:
> When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc
> function are not generated as long calls.
>
> This is the sequel to this patch
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00881.html
>
> This patch fixes the following pr
> Index: tree-ssa-loop-ivcanon.c
> > ===
> > --- tree-ssa-loop-ivcanon.c (revision 234516)
> > +++ tree-ssa-loop-ivcanon.c (working copy)
> > @@ -935,7 +935,7 @@ try_peel_loop (struct loop *loop,
> >edge exit,
And some more formatting issues.
On 30/03/16 10:33, Ramana Radhakrishnan wrote:
>
>
> On 24/03/16 21:02, Charles Baylis wrote:
>> When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc
>> function are not generated as long calls.
>>
>> This is the sequel to this patch
>> http
Hi,
while looking into sudoku solving benchark, I noticed that we incorrectly
estimate loop to iterate 10 times just because the array it traverses is of
dimension 10. This of course is just upper bound and not realistic bound.
Realistically those loops iterates once most of time.
It turns out thi
On Wed, Mar 30, 2016 at 12:47 AM, Uros Bizjak wrote:
> On Tue, Mar 29, 2016 at 8:56 PM, H.J. Lu wrote:
>> Since %ecx can't be used for both DRAP register and __builtin_eh_return,
>> we need to check if crtl->drap_reg uses %ecx before using %ecx for
>> __builtin_eh_return.
>>
>> Testing on x86-64.
On Wed, Mar 30, 2016 at 1:00 PM, H.J. Lu wrote:
> On Wed, Mar 30, 2016 at 12:47 AM, Uros Bizjak wrote:
>> On Tue, Mar 29, 2016 at 8:56 PM, H.J. Lu wrote:
>>> Since %ecx can't be used for both DRAP register and __builtin_eh_return,
>>> we need to check if crtl->drap_reg uses %ecx before using %ec
On Wed, Mar 30, 2016 at 09:07:17AM +0200, Uros Bizjak wrote:
> On Tue, Mar 29, 2016 at 10:13 PM, H.J. Lu wrote:
> > Tested on x86-64. OK for trunk?
> >
> > H.J.
> > ---
> > PR testsuite/70364
> > * gcc.target/i386/cleanup-1.c: Include .
> > (check): New function.
> >
On Wed, 30 Mar 2016, Jan Hubicka wrote:
> Hi,
> while looking into sudoku solving benchark, I noticed that we incorrectly
> estimate loop to iterate 10 times just because the array it traverses is of
> dimension 10. This of course is just upper bound and not realistic bound.
> Realistically those
The patch for PR63764 (accepts-invalid / ICE) caused us to generate
worse code for rvalue vector indexing by forcing the vector to a
temporary. It turns out this is not necessary if we alter the
way the C/C++ FE lower the vector to perform the indexing operation
from lowering to a pointer-to-elem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68475
This patch fixes an ICE with -fno-exceptions. We were not checking eh spec
equality when merging decls, leading to a checking-assert blowing up later. As
postulated in the bug report, always checking leads to good behaviour. Even
though we
On Wed, Mar 30, 2016 at 9:09 AM, Richard Biener
wrote:
> On Thu, Mar 24, 2016 at 6:26 PM, Bin Cheng wrote:
>> Hi,
>> Quite lot of time is used when IVOPT computes cost for pairs.
>> As a matter of fact, some pairs are very similar to each other, and we can
>> abstract and compute cost only on
On Wed, Mar 30, 2016 at 02:07:07PM +0200, Richard Biener wrote:
> The patch for PR63764 (accepts-invalid / ICE) caused us to generate
> worse code for rvalue vector indexing by forcing the vector to a
> temporary. It turns out this is not necessary if we alter the
> way the C/C++ FE lower the vect
>
> You are only changing one place in this file.
You are right. I am attaching the updated patch which I am re-testing now.
>
> The vectorizer already checks this (albeit indirectly):
>
> HOST_WIDE_INT max_niter
> = max_stmt_executions_int (LOOP_VINFO_LOOP (loop_vinfo));
> if ((LOOP_VI
Since GTM::gtm_thread has
gtm_thread *next_thread __attribute__((__aligned__(HW_CACHELINE_SIZE)));
GTM::gtm_thread::operator new should allocate aligned memory.
Tested on Linux/x86-64. OK for trunk.
H.J.
PR libitm/70456
* beginend.cc (GTM::gtm_thread::operator new): Use
On Wed, 30 Mar 2016, Jan Hubicka wrote:
> >
> > You are only changing one place in this file.
>
> You are right. I am attaching the updated patch which I am re-testing now.
> >
> > The vectorizer already checks this (albeit indirectly):
> >
> > HOST_WIDE_INT max_niter
> > = max_stmt_exec
Hi Guys,
I am applying this patch as a further fix for PR 62254.
In the long run we will hopefully be dropping support for ARM v3 (and
earlier) so this is more in the nature of a plaster than a real fix.
Cheers
Nick
gcc/ChangeLog
2016-03-30 Nick Clifton
PR target/62254
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux following
backports from trunk and committed them to gcc-5-branch.
Jakub
2016-03-30 Jakub Jelinek
Backported from mainline
2016-02-12 Jakub Jelinek
PR ipa/68672
* ipa-split.c (split_func
If --with-arch-32= is used to configure GCC, it should be used to
compile 32-bit x86 libatomic library. Since --with-arch for 64-bit
> i486, we can use it for 32-bit target library.
Tested on x86-64, with and without --with-arch=. OK for stage 1?
H.J.
--
PR target/70454
* config
If --with-arch-32= is used to configure GCC, it should be used to
compile 32-bit x86 libgomp library. Since --with-arch for 64-bit
> i486, we can use it for 32-bit target library.
Tested on x86-64, with and without --with-arch=. OK for stage 1?
H.J.
PR target/70454
* configure.t
If --with-arch-32= is used to configure GCC, it should be used to
compile 32-bit x86 libitm library. Since --with-arch for 64-bit
> i486, we can use it for 32-bit target library.
Tested on x86-64, with and without --with-arch=. OK for stage 1?
H.J.
PR target/70454
* configure.t
The following fixes a pasto in cp_build_binary_op. Will apply
as obvious after it passes bootstrap/testing on x86_64-unknown-linux-gnu.
Richard.
2016-03-30 Richard Biener
PR c++/70430
* typeck.c (cp_build_binary_op): Fix operand order of vector
conditional in truth o
On Wed, Mar 30, 2016 at 11:00 AM, Jan Hubicka wrote:
> Hi,
> while looking into sudoku solving benchark, I noticed that we incorrectly
> estimate loop to iterate 10 times just because the array it traverses is of
> dimension 10. This of course is just upper bound and not realistic bound.
> Realist
The following patch fixes PR70450 where I (again...) was not able
to decipher wide-int workings in a first try. (the 'sign' op
looks redundant for a tree wide_int::from so I was thinking it
must apply to the destination to specify eventual zero/sign-extension
if the 'precision' arg is not a multi
On 03/30/2016 08:09 AM, Nathan Sidwell wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68475
This patch fixes an ICE with -fno-exceptions. We were not checking eh
spec equality when merging decls, leading to a checking-assert blowing
up later. As postulated in the bug report, always checki
On 29 Mar 19:49, Jakub Jelinek wrote:
> On Tue, Mar 29, 2016 at 11:44:15AM -0600, Jeff Law wrote:
> > On 03/29/2016 11:05 AM, Jakub Jelinek wrote:
> > >Hi!
> > >
> > >The various blendm expanders look like:
> > >(define_insn "_blendm"
> > > [(set (match_operand:V48_AVX512VL 0 "register_operand" "
On Wed, Mar 30, 2016 at 04:53:48PM +0300, Kirill Yukhin wrote:
> I think that order of arguments in built-in might be changed easily.
> This doesn't affect intrinsics at all, because of that.
>
> I can hardly recall, but my bet is that this order was dictated by:
> ix86_expand_sse_movcc where orde
On Wed, Mar 30, 2016 at 04:06:30PM +0200, Thomas Schwinge wrote:
> This is to integrate into trunk a large amount of the test case updates
> that we have accumulated on gomp-4_0-branch. OK to commit?
Ok.
Jakub
> > - /* If access is not executed on every iteration, we must ensure that
> > overlow may
> > - not make the access valid later. */
> > + /* If access is not executed on every iteration, we must ensure that
> > overlow
> > + may not make the access valid later. */
> >if (!dominat
On Wed, Mar 30, 2016 at 11:02:41AM +0200, Olivier Hainque wrote:
> void g(int, char *);
>
> void f(int x)
> {
>char big[20];
> start:
>g(x, big);
>g(x, big);
>register void *p asm("r11") = &&start;
>asm("" : : "r"(p));
>asm("" : : :"r28");
>
On Wed, Mar 30, 2016 at 3:22 PM, Jan Hubicka wrote:
>> > - /* If access is not executed on every iteration, we must ensure that
>> > overlow may
>> > - not make the access valid later. */
>> > + /* If access is not executed on every iteration, we must ensure that
>> > overlow
>> > + m
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be given that this is my first time
working in this area. Which piece of code or what assumption
in particular are you concerned about?
I w
On 17/03/16 16:33, Andre Vieira (lists) wrote:
> On 23/10/15 12:31, Bernd Schmidt wrote:
>> On 10/12/2015 11:58 AM, Ulrich Weigand wrote:
>>>
>>> Index: gcc/configure.ac
>>> ===
>>> --- gcc/configure.ac(revision 228530)
>>> +++ g
The patch for PR69614 has been backported to gcc-5 branch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
Committed as rev. 234577.
On 29/03/16 17:49, Andre Vieira (lists) wrote:
> On 29/01/16 17:07, Andre Vieira (lists) wrote:
>> On 26/12/15 01:54, Thomas Preud'homme wrote:
>>> [Sending on behalf of Andre Vieira]
>>>
>>> Hello,
>>>
>>> This patch extends support for the ARMv8-M Security Extensions
>>> 'cmse_nonsecure_entry' at
This test ICEs since the addition of the assert in pp_string which ensures that
we aren't trying to print an empty string. But that's what happens here, the
location is actually UNKNOWN_LOCATION, so LOCATION_FILE on that yields null.
Fixed byt not trying to print the filename of UNKNOWN_LOCATION.
Add scalar 0.0 to the aarch64_simd_reg_or_zero predicate.
2016-03-30 Evandro Menezes
* gcc/config/aarch64/predicates.md
(aarch64_simd_reg_or_zero predicate): Add the "const_double"
constraint.
It seems to me that the aarch64_simd_reg_or_zero should also handle the
Hi!
On Wed, 18 Nov 2015 16:17:39 +0100, Tom de Vries wrote:
> On 22/10/15 20:27, Thomas Schwinge wrote:
> > diff --cc libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-1.c
> > index d478ce2,22cef6d..f3b490a
> > --- libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-1.c
> > +++ libgomp/test
Hi Ilya,
> This patch fixes gcc.target/i386/chkp-hidden-def.c test failure
> on Solaris. Failure happens because some Solaris emit code
> ignores transparent alias chains for assembler names. The patch
> was tested and approved by Rainer Orth (see [1] for more details).
> Applied to trunk.
>
> [
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be given that this is my first time
working in this area. Which piece of code or what assumptio
On 29/01/16 17:08, Andre Vieira (lists) wrote:
> On 19/01/16 15:28, Andre Vieira (lists) wrote:
>> On 16/01/16 14:49, Senthil Kumar Selvaraj wrote:
>>> User-agent: mu4e 0.9.13; emacs 24.5.1
>>>
>>> Hi,
>>>
>>> Apologies for the bad posting style (I don't have the
>>> original email handy), but shou
OK.
Jason
This patch (provided by Jakub in the PR) fixes a failure of
gcc.target/i386/avx-vextractf128-256-5.c on the gcc-5 branch with the
Solaris assembler:
FAIL: gcc.target/i386/avx-vextractf128-256-5.c (test for excess errors)
The problem is that a target selector to dg-do overrides a previous
dg-requi
On 03/29/2016 08:40 AM, Nathan Sidwell wrote:
+ /* The field we're initializing must be on the field
+list. Look to see if it is present before the
+field the current ELT initializes. */
+ for (; fields != cep->index; fields = DECL_CHAIN (
Hi there,
Applied https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02148.html on
embedded-5-branch using the included patch at revision r234582.
Cheers,
Andre
*** gcc ***
2016-03-30 Andre Vieira
Thomas Preud'homme
* config.gcc (extra_headers): Added arm_cmse.h.
Hi,
Applied https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02150.html on
embedded-5-branch using the included patch at revision r234583.
*** gcc ***
2016-03-30 Andre Vieira
Thomas Preud'homme
* config/arm/arm.c (arm_handle_cmse_nonsecure_entry): New.
(arm_at
Hi,
Applied the patch in
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02151.html on
embedded-5-branch at revision r234584.
Cheers,
Andre
On 03/30/16 13:22, Jason Merrill wrote:
On 03/29/2016 08:40 AM, Nathan Sidwell wrote:
+ /* The field we're initializing must be on the field
+ list. Look to see if it is present before the
+ field the current ELT initializes. */
+ for (; fields != cep->index;
Applied the patch in
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01524.html on
embedded-5-branch at revision r234585.
Cheers,
Andre
Hi,
Applied https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02153.html on
embedded-5-branch using included patch at revision r234586.
*** gcc ***
2016-03-30 Andre Vieira
Thomas Preud'homme
* config/arm/arm.c (gimplify.h): New include.
(arm_handle_cmse_nonsecu
Hi,
Applied https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02334.html on
embedded-5-branch using the included patch at revision r234587.
*** gcc/ ***
2016-03-30 Andre Vieira
Thomas Preud'homme
* config/arm/arm.c (detect_cmse_nonsecure_call): New.
(cmse_nonse
Hi,
Applied https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02155.html on
embedded-5-branch using included patch at revision r234589.
*** gcc/ ***
2016-03-30 Andre Vieira
Thomas Preud'homme
* config/arm/arm-builtins.c (arm_builtins): Define
ARM_BUILTIN_CMSE_N
On Sun, 27 Mar 2016, Hongxu Jia wrote:
> PR other/70428
> * final.c (remap_debug_filename): Use lrealpath to translate
> relative path before remapping
I think this would break cases that currently work. When using
-fdebug-prefix-map you should understand what paths will appear in debug
info (
On Sun, 27 Mar 2016, Andi Kleen wrote:
> 2016-03-27 Andi Kleen
>
> * gen_autofdo_event.py: New file to regenerate
> gcc-auto-profile.
It may not be required in contrib, but does this script work with both
Python 2 and Python 3? (New code that only works with Python 2 seems like
On March 30, 2016 2:36:14 PM GMT+02:00, Richard Biener
wrote:
>On Wed, 30 Mar 2016, Jan Hubicka wrote:
>
>> >
>> > You are only changing one place in this file.
>>
>> You are right. I am attaching the updated patch which I am re-testing
>now.
>> >
>> > The vectorizer already checks this (albei
On Wed, Mar 30, 2016 at 06:05:00PM +, Joseph Myers wrote:
> On Sun, 27 Mar 2016, Andi Kleen wrote:
>
> > 2016-03-27 Andi Kleen
> >
> > * gen_autofdo_event.py: New file to regenerate
> > gcc-auto-profile.
>
> It may not be required in contrib, but does this script work with both
>
gcc.dg/ifcvt-4.c currently FAILs for 64-bit SPARC:
FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"
Eric suggested in the PR that Jeff's fix for PR rtl-optimization/69942
to gcc.dg/ifcvt-5.c applies here as well and indeed it does.
While I was at it, I removed the superfluous defau
On 03/25/2016 04:43 AM, Aldy Hernandez wrote:
If Bernd is fine with this, I'm happy to retract my patch and any
possible followups. I'm just interested in having no path causing a
possible out of bounds access. If your patch will do that, I'm cool.
I'll need to see that patch first to comment
On 03/29/2016 12:03 PM, Jakub Jelinek wrote:
On Tue, Mar 29, 2016 at 11:47:57AM -0600, Jeff Law wrote:
2016-03-29 Jakub Jelinek
PR rtl-optimization/70429
* combine.c (simplify_shift_const_1): For ASHIFTRT don't optimize
(cst1 >> count) >> cst2 into (cst1 >> cst2) >> c
Hi
This patch adds a plugin event when evaluating a call expression in constexpr.
The goal of this patch is to allow the plugins to analyze and or
modify the evaluation of constant expressions.
Changelog 2016-3-30 Andres Tiraboschi
*gcc/plugin.c (PLUGIN_EVAL_CALL_CONSTEXPR): New event.
On 03/30/2016 12:32 PM, Martin Sebor wrote:
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be given that this is my first time
working in this
On 03/30/2016 01:40 PM, Nathan Sidwell wrote:
On 03/30/16 13:22, Jason Merrill wrote:
On 03/29/2016 08:40 AM, Nathan Sidwell wrote:
+ /* The field we're initializing must be on the field
+ list. Look to see if it is present before the
+ field the current ELT initialize
Is the following patch OK for trunk and the gcc-4.9 and gcc-5 branches after
some delay (bootstrapped and regtested on x86_64-apple-darwin15)?
TIA
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revisi
On 03/30/2016 01:18 PM, Dominique d'Humières wrote:
> Is the following patch OK for trunk and the gcc-4.9 and gcc-5 branches after
> some delay (bootstrapped and regtested on x86_64-apple-darwin15)?
Yes, OK, thanks for help!!
Jerry
2016-03-29 12:07 GMT-03:00 Andres Tiraboschi
:
> Hi,
> the attached patch adds a new compilation flag
> 'ftemplate-instantiations' in order
> to allow dumping debug information for template instantiations.
> This flag has 2 possible values: none(by default) and hreadable, that
> prints witch
> temp
On 29 March 2016 at 18:28, Vladimir Makarov wrote:
> The following patch improves the code in 2 out of 3 cases in
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
>
> The patch uses more accurate costs for the RA cost improvement
> optimization after colouring.
>
> The patch was tested
Hi!
As mentioned in the PR, we are miscompiling glibc on i686-linux, because
the new indirect_jump_optimize mini-pass thinks that a insn
which has REG_LABEL_OPERAND note necessarily has to set the target register
to that label, while in the glibc case it is actually that label + some
offset, where
Thanks for the quick review. Committed on trunk as revision r234600. I’ll wait
a week for gcc-5 and gcc-4.9.
Dominique
> Le 30 mars 2016 à 22:38, Jerry DeLisle a écrit :
>
> On 03/30/2016 01:18 PM, Dominique d'Humières wrote:
>> Is the following patch OK for trunk and the gcc-4.9 and gcc-5 bra
On 30/03/16 17:14, Marek Polacek wrote:
This test ICEs since the addition of the assert in pp_string which ensures that
we aren't trying to print an empty string. But that's what happens here, the
location is actually UNKNOWN_LOCATION, so LOCATION_FILE on that yields null.
Fixed byt not trying t
On 03/30/2016 01:25 PM, Jason Merrill wrote:
On 03/30/2016 12:32 PM, Martin Sebor wrote:
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as
POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be gi
On 30 March 2016 at 23:42, Manuel López-Ibáñez wrote:
> On 30/03/16 17:14, Marek Polacek wrote:
>>
>> This test ICEs since the addition of the assert in pp_string which ensures
>> that
>> we aren't trying to print an empty string. But that's what happens here,
>> the
>> location is actually UNKNO
On Wed, Mar 30, 2016 at 11:27:28PM +0200, Jakub Jelinek wrote:
> As mentioned in the PR, we are miscompiling glibc on i686-linux, because
> the new indirect_jump_optimize mini-pass thinks that a insn
> which has REG_LABEL_OPERAND note necessarily has to set the target register
> to that label, whil
On 03/31/2016 01:58 AM, Joseph Myers wrote:
On Sun, 27 Mar 2016, Hongxu Jia wrote:
PR other/70428
* final.c (remap_debug_filename): Use lrealpath to translate
relative path before remapping
I think this would break cases that currently work. When using
-fdebug-prefix-map you should understand
Yo, sexy guy LOL! I want to meet you in real life. txt me @ 657 363 five zero
two four if you want sum of mine sexy photos. Will u message me soon? IMU, OX.
On 03/30/2016 06:50 PM, Martin Sebor wrote:
On 03/30/2016 01:25 PM, Jason Merrill wrote:
On 03/30/2016 12:32 PM, Martin Sebor wrote:
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as
POINTER_PLUS_EXPR or
Hi Bernd,
> Are all the places being patched really problematic ones where an input file
> could realistically cause an overflow, or just the string functions?
The loop in demangle_args allows to call the patched register*- and
remember*-methods arbitrarily often. So, those should also overflow
85 matches
Mail list logo
