On Thu, Dec 15, 2011 at 5:16 AM, Michael Zolotukhin
wrote:
> Thanks!
> Fixed patch is attached.
>
> Any other comments?
>
> Changelog:
> 2011-12-14 Michael Zolotukhin
>
> * gcc.dg/vect/no-section-anchors-vect-31.c: Adjust array size and test
> diag-scans to fix fail on AVX.
>
Joel Sherrill writes:
> After all of Ian's commits, this is now the error output from a "make -k"
> so I think this is
> getting close.
>
> libtool: compile: /home2/joel/build/b-sparc-go/./gcc/gccgo
> -B/home2/joel/build/b-sparc-go/./gcc/
> -B/users/joel/test-gcc/install-svn/sparc-rtems4.11/bin/
On Thu, Dec 15, 2011 at 08:32:26AM +0200, Ira Rosen wrote:
> > + cond = build2 (LT_EXPR, boolean_type_node, oprnd0, build_int_cst
> > (itype, 0));
> > + gsi = gsi_for_stmt (last_stmt);
> > + if (rhs_code == TRUNC_DIV_EXPR)
> > +{
> > + tree var = vect_recog_temp_ssa_var (itype, NULL);
>
Jakub Jelinek wrote on 14/12/2011 02:25:13 PM:
>
> @@ -1573,6 +1576,211 @@ vect_recog_vector_vector_shift_pattern (
>return pattern_stmt;
> }
>
> +/* Detect a signed division by power of two constant that wouldn't be
> + otherwise vectorized:
> +
> + type a_t, b_t;
> +
> + S1 a_t =
Thanks!
Fixed patch is attached.
Any other comments?
Changelog:
2011-12-14 Michael Zolotukhin
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust array size and test
diag-scans to fix fail on AVX.
* gcc.dg/vect/no-section-anchors-vect-36.c: Ditto.
* gcc.dg/vect/
On 12/14/2011 10:45 AM, Richard Earnshaw wrote:
> On 10/12/11 23:21, Richard Henderson wrote:
>> +(define_insn "*xorsi3_compare0_scratch_arm"
>
> The convention in arm.md is only to put 'scratch' in the name if the
> operation needs to allocate a scratch register for a result that isn't
> used (fo
On 12/14/2011 10:25 AM, Richard Earnshaw wrote:
> Otherwise, with the changes for Ramana's comments, this is OK.
For the record, this is the patch as committed.
r~
commit dd120a9705b6c48fdb519e837ad47e41d155f50b
Author: rth
Date: Thu Dec 15 03:24:05 2011 +
arm-linux: Add libitm supp
On Wed, Dec 14, 2011 at 4:10 PM, Jason Merrill wrote:
> Here we were assuming that the type of a POINTER_PLUS_EXPR would reflect the
> underlying type of the object, which is not the case with this testcase. So
> now we keep looking until we find the ADDR_EXPR.
>
> Tested x86_64-pc-linux-gnu, app
This is fix for the RP. Is uses (reg:QI 28) instead of building SUBREG of frame
pointer.
Johann
PR target/51050
* config/avr/avr.c (expand_epilogue): Don't build SUBREG of fp.
(avr_prologue_setup_frame): Ditto.
Index: gcc/config/avr/avr.c
==
On 12/14/2011 03:41 PM, Dodji Seketeli wrote:
@@ -8041,6 +8041,7 @@ joust (struct z_candidate *cand1, struct z_candidate
*cand2, bool warn)
{
conversion *t1 = cand1->convs[i + off1];
conversion *t2 = cand2->convs[i + off2];
+ conversion *next_conv = next_conversion (t1
I used to think that there was no way to get a variant of an enum before
the end of the first mention of it. But when that's an enum-specifier
that refers to a cv-variant of the type in one of the enumerator
initializers, there is a way...
Tested x86_64-pc-linux-gnu, applying to 4.6 and trunk
On 12/14/2011 07:56 AM, Aldy Hernandez wrote:
Without the patch, it is ok.
If I remove completely this part:
if (DECL_DECLARED_INLINE_P (new_decl) && DECL_EXTERNAL (new_decl))
{
DECL_EXTERNAL (new_decl) = 0;
TREE_PUBLIC (new_decl) = 0;
}
It ends with *only* one undefined symbol:
src/UnitsSkins.
It doesn't make sense to mark a type with no fields as a transparent
union, and indeed handle_transparent_union checks for that. But this
testcase was slipping past the checks because we're applying the
attribute in place but after the type has been completed. This patch
adjusts the check log
Here we were assuming that the type of a POINTER_PLUS_EXPR would reflect
the underlying type of the object, which is not the case with this
testcase. So now we keep looking until we find the ADDR_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 482c1bb6a00cdd911df18d2fd3486ee00fc2fa
On Wed, Dec 14, 2011 at 9:47 AM, Xinliang David Li wrote:
> The patch is ok for google branches for now.
Committed to google/main.
Thanks,
-Sri.
>
> David
>
> On Tue, Dec 13, 2011 at 4:33 PM, wrote:
>> On 2011/12/14 00:04:10, davidxl wrote:
>>>
>>> http://codereview.appspot.com/5488054/diff/4
On Wed, Dec 14, 2011 at 10:17:11PM +0100, Paul Richard Thomas wrote:
> Dear All,
>
> This patch combines the trivial correction of an error in
> trans-decl.c, spotted by Jakub (thanks!), with a trivial fix for the
> scalarization of elemental typebound procedures. Neither needs
> explanation!
>
Dear All,
This patch combines the trivial correction of an error in
trans-decl.c, spotted by Jakub (thanks!), with a trivial fix for the
scalarization of elemental typebound procedures. Neither needs
explanation!
Boostrapped and regtested on x86_64/FC9 - OK for trunk?
Cheers
Paul
2011-12-14
On Mon, 12 Dec 2011 08:24:41 +0800, Doug Kwan wrote:
> Sorry about my oversight. I am on vacation now until Dec 19. I don't
> have good internet access now and I will backport this to upstream 4.6
> after I come back if the 4.6 maintainers agree to take this.
There isn't really anything to backpo
Jason Merrill writes:
> OK.
Thanks.
So here is the follow-up hardening patch that uses next_conversion
instead of touching conversion::u.next directly, for better safety and
maintainability.
Would this be OK for next stage 1?
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
OK.
Jason
Octeon2 includes the indexed load instructions from the DSP ASE and a
few extensions on top of those: lbx, lhux, and lwux.
This patch adds to GCC support for the DSP64 instruction ldx and also
all of the Octeon2 extensions.
I only added the builtin function for ldx to be the same as the other
l*x D
On 12/14/2011 10:09 AM, Anatoly Sokolov wrote:
> * config/ia64/ia64.h (REG_OK_FOR_BASE_P, REG_OK_FOR_INDEX_P,
> LEGITIMATE_ADDRESS_REG, LEGITIMATE_ADDRESS_DISP,
> GO_IF_LEGITIMATE_ADDRESS): Remove macros.
> * config/ia64/ia64.c (TARGET_LEGITIMATE_ADDRESS_P): Define.
On 12/14/2011 10:25 AM, Richard Earnshaw wrote:
> On 10/12/11 23:21, Richard Henderson wrote:
>> diff --git a/libitm/config/arm/hwcap.h b/libitm/config/arm/hwcap.h
>> new file mode 100644
>> index 000..16e4034
>> --- /dev/null
>> +++ b/libitm/config/arm/hwcap.h
>> +
>> +/* The following must ma
Ping for:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00273.html
To recap, this gets rid of some locally-cached state before writing
out the PCH file (which we have to do because some of that state is
not under GGC control). The patch doesn't change the user's MIPS16
vs. non-MIPS16 setting
"H.J. Lu" writes:
> On Wed, Dec 14, 2011 at 10:38 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> Since __SIGRTMIN is for the NPTL threading library, should we check
>>> __GLIBC__ instead of __linux__? Otherwise, it fails to build with
>>> Bionic library on Android.
>>
>> This is OK.
"Maciej W. Rozycki" writes:
> After some thinking I decided the simplest approach will be just emitting
> the missing location directive in the context of the MIPS16 thunk being
> built that will apply to the actual function prologue. The resulting
> change is included below -- this just repe
Hi All,
I have created a new git-only development branch called
"google/debugfission" for our DebugFission project, as described here:
http://gcc.gnu.org/wiki/DebugFission
Although definitely a work in progress, enough is working that it
might be worth a look around.
Sterling Augustine
saugust.
On 14/12/11 19:01, Anatoly Sokolov wrote:
> Hi.
>
> This patch removes obsolete REGISTER_MOVE_COST and MEMORY_MOVE_COST
> macros from the ARM back end in the GCC and introduces equivalent
> TARGET_REGISTER_MOVE_COST and TARGET_MEMORY_MOVE_COST target hooks.
>
> Bootstrapped and regression t
Hi.
This patch removes obsolete REGISTER_MOVE_COST and MEMORY_MOVE_COST
macros from the ARM back end in the GCC and introduces equivalent
TARGET_REGISTER_MOVE_COST and TARGET_MEMORY_MOVE_COST target hooks.
Bootstrapped and regression tested on arm-unknown-linux-gnueabi.
OK to install?
On Wed, Dec 14, 2011 at 10:38 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Since __SIGRTMIN is for the NPTL threading library, should we check
>> __GLIBC__ instead of __linux__? Otherwise, it fails to build with
>> Bionic library on Android.
>
> This is OK. But please just fix the exist
On 10/12/11 23:21, Richard Henderson wrote:
> +(define_insn "*xorsi3_compare0_scratch_arm"
The convention in arm.md is only to put 'scratch' in the name if the
operation needs to allocate a scratch register for a result that isn't
used (for example the iorsi3_compare0_scratch pattern).
Otherwise
The patch r172595 was intended for bionic setlocale() which always
returns 0. I don't remember I put NULL there initially.
We can simply replace all NULL in r172595 with 0.
I attached the updated patch.
If it is ok, I will commit the patch into google/gcc-4_6 and
google/gcc-4_6-mobile branches.
"H.J. Lu" writes:
> Since __SIGRTMIN is for the NPTL threading library, should we check
> __GLIBC__ instead of __linux__? Otherwise, it fails to build with
> Bionic library on Android.
This is OK. But please just fix the existing comment to say glibc
instead of Linux, or something like that.
On 10/12/11 23:21, Richard Henderson wrote:
> diff --git a/libitm/config/arm/hwcap.h b/libitm/config/arm/hwcap.h
> new file mode 100644
> index 000..16e4034
> --- /dev/null
> +++ b/libitm/config/arm/hwcap.h
> +
> +/* The following must match the kernel's . */
> +#define HWCAP_ARM_SWP
Hello,
When we walk conversions, we need to be careful that the struct
conversion::u.next union field is the one that is active, depending on
the struct conversion::kind field.
In this bug for instance we are wrongly accessing conversion::u.next
when conversion::kind is a ck_list. Oops.
So I am
>
> Seems reasonable. Jing, 172595 was a patch from you. Would it be the same
> if you just used 0 instead of NULL?
Or nothing.
Paolo
On 11-12-14 13:09 , Paolo Carlini wrote:
Hi,
Hi,
Revision 172595:
http://gcc.gnu.org/viewcvs?view=revision&revision=172595
added NULL to config/locale/generic/c_locale.h on
google/gcc-4_6-branch. But isn't included, which lead to
build failure since NULL isn't defined. This patch
includes.
Hi,
> Hi,
>
> Revision 172595:
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=172595
>
> added NULL to config/locale/generic/c_locale.h on google/gcc-4_6-branch.
> But isn't included, which lead to build failure since NULL isn't
> defined. This patch includes . OK for google/gcc-4_6-b
Hello.
This patch removes obsolete GO_IF_LEGITIMATE_ADDRESS macro from IA64 back
end in the GCC and introduces equivalent TARGET_LEGITIMATE_ADDRESS_P target
hook.
Bootstrapped and regression tested on ia64-unknown-linux-gnu.
OK to install?
* config/ia64/ia64.h (REG_OK_FOR_BASE_P
Another usability related issue for C++. The long demangled function
names will make the info messages very hard to swallow. Since there
will be source lines to show the source context, it might be better to
just use the short decl names. The downside is it can be ambiguous for
template functions.
On Wed, Dec 14, 2011 at 01:25:13PM +0100, Jakub Jelinek wrote:
> On Tue, Dec 13, 2011 at 05:57:40PM +0400, Kirill Yukhin wrote:
> > > Let me hack up a quick pattern recognizer for this...
>
> Here it is, untested so far.
> On the testcase doing 200 f1+f2+f3+f4 calls in the loop with -O3 -mavx
Hi!
As written in the PR, there are 3 bugs:
1) setting DECL_INITIAL on !TREE_STATIC span VAR_DECLs has no code
generation effect, only confuses dwarf2out.c
2) the span VAR_DECLs weren't initialized
3) coalescing at -O0 wrongly looked at DECL_ARTIFICIAL, we want
to look at DECL_IGNORED_P, as
The patch is ok for google branches for now.
David
On Tue, Dec 13, 2011 at 4:33 PM, wrote:
> On 2011/12/14 00:04:10, davidxl wrote:
>>
>> http://codereview.appspot.com/5488054/diff/4002/tree-vect-stmts.c
>> File tree-vect-stmts.c (right):
>
>
>
> http://codereview.appspot.com/5488054/diff/4002/
On 24/11/11 01:33, Xinyu Qi wrote:
> Hi Ramana,
>
> I solve the conflict, please try again. The new diff is attached.
>
> Thanks,
> Xinyu
>
> At 2011-11-19 07:36:15,"Ramana Radhakrishnan"
> wrote:
>>
>> Hi Xinyu,
>>
>> This doesn't apply cleanly currently on trunk and the reject appears
>> to
Hi,
This patch adds -mandroid support on Linux/i386, similar to Linux/ARM.
OK for trunk in stage 1?
Thanks.
H.J.
--
2011-12-13 H.J. Lu
* config/i386/linux.h (LINUX_TARGET_CC1_SPEC): New.
(CC1_SPEC): Use LINUX_OR_ANDROID_CC.
(CC1PLUS_SPEC): Likewise.
(LINUX_TA
Hi,
Android uses crtbegin_so.o and crtend_so.o to build shared library with
-mshared. OK for trunk in stage 1?
H.J.
---
2011-12-13 H.J. Lu
* config/linux-android.h (ANDROID_STARTFILE_SPEC): Use
crtbegin_so%O%s for -shared.
(ANDROID_ENDFILE_SPEC): Use crtend_so%O%s fo
Since __SIGRTMIN is for the NPTL threading library, should we check
__GLIBC__ instead of __linux__? Otherwise, it fails to build with
Bionic library on Android.
H.J.
---
libgcc/ChangeLog.hjl |4
libgcc/generic-morestack.c |5 -
2 files changed, 8 insertions(+), 1 deletion
Hi,
Revision 172595:
http://gcc.gnu.org/viewcvs?view=revision&revision=172595
added NULL to config/locale/generic/c_locale.h on google/gcc-4_6-branch.
But isn't included, which lead to build failure since NULL isn't
defined. This patch includes . OK for google/gcc-4_6-branch?
H.J.
---
libst
The following patch avoids streaming extern var and function decls
into the global decls and types section when streaming a tree
chain list (effectively only when processing BLOCK_VARS). This
avoids the last LTO debug-info ICE I know of (knocks on wood)
and provides a cleaner (well ...) fix for P
On 14/07/11 08:35, Xinyu Qi wrote:
>>> Hi,
>>>
>>> It is the first part of iWMMXt maintenance.
>>>
>>> *config/arm/arm.c (arm_option_override):
>>> Enable iWMMXt with VFP. iWMMXt and NEON are incompatible.
>> iWMMXt unsupported under Thumb-2 mode.
>>> (arm_expand_binop_builtin): Accept immedia
On 12/14/2011 05:04 PM, Ian Lance Taylor wrote:
> The OpenBSD thread runtime. It's similar to old LinuxThreads, but
> with only 1 kernel thread per process IIUC.
Oh, hmmm, that might be a problem.
The other Go compiler seems to use the rfork system call to create new
threads, passing RFPROC
Paolo Bonzini writes:
> On 12/14/2011 04:45 PM, Ian Lance Taylor wrote:
>>> > - sigaltstack always returns EINVAL when using threads;
>> That is odd. sigaltstack is very useful when using threads.
>>
>>> > - the threads are identified by the runtime from their stack pointer,
>>> > so you risk
On 12/14/2011 04:45 PM, Ian Lance Taylor wrote:
> - sigaltstack always returns EINVAL when using threads;
That is odd. sigaltstack is very useful when using threads.
> - the threads are identified by the runtime from their stack pointer,
> so you risk confusing the runtime very much if you
Paolo Bonzini writes:
> On 12/14/2011 04:00 PM, Ian Lance Taylor wrote:
>>
>> The other Go compiler already supports OpenBSD, so it must be possible
>> in some sense.
>
> Do they have specialised code for OpenBSD? I said "it cannot work" in
> the sense that:
>
> - *context functions are not ther
I committed a patch to update libgo to the weekly.2011-12-06 release of
the master Go library. As usual this e-mail message only includes the
patches to gccgo specific files, in this case a small patch.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
dif
Tristan Gingold writes:
> On Dec 14, 2011, at 3:48 PM, Ian Lance Taylor wrote:
>
>> The Go language was changed to permit omitting &T in composite literals,
>> as in
>>
>> var v = []*S{ &S{0}, &S{1} }
>>
>> This can now be written as
>>
>> var v = []*S{ {0}, {1} }
>>
>> This patch implements
With SPEC 2k6 testing I noticed we fail to update &MEM[&a] when
propagating &a. Fixed as follows.
Bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2011-12-14 Richard Guenther
* tree-cfg.c (replace_uses_by): Fixup TREE_CONSTANT for
propagating all kinds of constan
This fixes PR51497 by making sure to fixup types that are streamed
locally.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, SPEC 2k6
smoke-tested and applied.
Richard.
2011-12-14 Richard Guenther
PR lto/51497
* lto-streamer-in.c (lto_read_body): Fixup local types
On 12/14/2011 04:00 PM, Ian Lance Taylor wrote:
> > This implementation relies on the functions getcontext, setcontext, and
> > makecontext. If there are systems which don't have those, getcontext
> > and setcontext can be replaced by setjmp and longjmp, but there is no
> > obvious replaceme
Peter Maydell writes:
> On 14 December 2011 15:00, Ian Lance Taylor wrote:
>> Anyhow, makecontext is easy to write in a system specific manner. It
>> doesn't even have to be written in assembler, though getcontext and
>> setcontext do have to be assembler. Why not just implement them for
>> AR
On 14 December 2011 15:00, Ian Lance Taylor wrote:
> Anyhow, makecontext is easy to write in a system specific manner. It
> doesn't even have to be written in assembler, though getcontext and
> setcontext do have to be assembler. Why not just implement them for
> ARM?
We're looking at implement
Paolo Bonzini writes:
> On 11/28/2011 06:46 AM, Ian Lance Taylor wrote:
>> This implementation relies on the functions getcontext, setcontext, and
>> makecontext. If there are systems which don't have those, getcontext
>> and setcontext can be replaced by setjmp and longjmp, but there is no
>> o
On Dec 14, 2011, at 3:48 PM, Ian Lance Taylor wrote:
> The Go language was changed to permit omitting &T in composite literals,
> as in
>
> var v = []*S{ &S{0}, &S{1} }
>
> This can now be written as
>
> var v = []*S{ {0}, {1} }
>
> This patch implements this change in the gccgo frontend. Bo
Uros Bizjak writes:
> Still no success, now I get:
>
> --- FAIL: runtime_test.TestGcSys (4.21 seconds)
> ???:1: used 2554104 extra bytes
> ???:1: using too much memory: 2554104 bytes
> FAIL
> FAIL: runtime
Yeah, I was too aggressive. It had to be fixed in the master library
too.
The Go language was changed to permit omitting &T in composite literals,
as in
var v = []*S{ &S{0}, &S{1} }
This can now be written as
var v = []*S{ {0}, {1} }
This patch implements this change in the gccgo frontend. Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
On 11/28/2011 06:46 AM, Ian Lance Taylor wrote:
This implementation relies on the functions getcontext, setcontext, and
makecontext. If there are systems which don't have those, getcontext
and setcontext can be replaced by setjmp and longjmp, but there is no
obvious replacement for makecontext.
Patrick, I see what you mean. Your patch looks sensible, but Richard
will have to review.
Richard, here is a resubmission of Patrick's patch, as the original
patch had the wrong description, and one of the testcases no longer
applied. Could you please review?
The problem here is that a __c
Hi Jakub,
For 401.bzip2 it looks perfect. This is loop is vectorized:
.L6:
vmovdqa (%rsi,%rax), %ymm0
addl$1, %ecx
vpsrad $8, %ymm0, %ymm0
vpsrld $31, %ymm0, %ymm1
vpaddd %ymm1, %ymm0, %ymm0
vpsrad $1, %ymm0, %ymm0
vpaddd %ymm2, %ymm0
Hello!
Just a nit:
+proc check_prefer_avx128_specified { } {
Please name this function check_prefer_avx128. Nothing was specified anywhere.
Thanks,
Uros.
On Wed, Dec 14, 2011 at 12:15 AM, Ian Lance Taylor wrote:
>>> This patch changes the Go library to multiplex goroutines onto operating
>>> system threads. Previously, each new goroutine ran in a separate
>>> thread. That is inefficient for programs with lots of goroutines. This
>>> patch chang
Without the patch, it is ok.
If I remove completely this part:
if (DECL_DECLARED_INLINE_P (new_decl) && DECL_EXTERNAL (new_decl))
{
DECL_EXTERNAL (new_decl) = 0;
TREE_PUBLIC (new_decl) = 0;
}
It ends with *only* one undefined symbol:
src/UnitsSkins.o: In function
`_ZGTtStltIcSt11char_traitsIcESa
> Meh. This seems excruciatingly error prone.
>
> I think we should simply re-write the test cases so that it doesn't
> matter how many times we see a particular string. Don't combine so
> many (potentially vectorizable) loops within a test case that it matters.
Some rework on tests looks better
On Tue, Dec 13, 2011 at 05:57:40PM +0400, Kirill Yukhin wrote:
> > Let me hack up a quick pattern recognizer for this...
Here it is, untested so far.
On the testcase doing 200 f1+f2+f3+f4 calls in the loop with -O3 -mavx
on Sandybridge (so, vectorized just with 16 byte vectors) gives:
vanilla
Sergio Durigan Junior writes:
> Sergio Durigan Junior writes:
>
>> Bernd Schmidt writes:
>>
>>> On 12/01/11 13:01, Ramana Radhakrishnan wrote:
Sergio: Other than a few minor tweaks to the Changelog it largely
looks obvious to me.
Bernd, could you take another look at this s
Hi,
My comment isn't about the technical aspect of the patch itself -- it
is a simple patch. But we don't seem to understand yet the
implications of "final". As was observed on the standard reflectors,
the appropriate trait might actually need to be binary instead of
unary as this patch implem
And this time with the patch .
2011-12-14 Ramana Radhakrishnan
* config/arm/arm.h (LEGITIMIZE_RELOAD_ADDRESS): Call
arm_legitimize_reload_address for Thumb2 as well. Adjust call
to thumb_legitimize_reload_address.
* config/arm/arm-protos.h (thumb1_legitimize_reload_
Hi,
The fix for PR48250 overhauled arm_legitimize_reload_address taking
into account Thumb2 as well in the code , we forgot to call it for
TARGET_THUMB2 :) . I noticed this while reviewing an earlier patch and
today got reminded about this while looking at something else in the
backend. While the
Hello,
I just committed the following to svn as commit r182330.
ChangeLog:
* MAINTAINERS (picochip): Changed email address.
Cheers
Hari
Hi,
On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini
wrote:
On 12/12/2011 09:37 PM, Easwaran Raman wrote:
Thanks for the comments Paolo. I have attached the new patch. I have
bumped the version to 3.4.18
You shouldn't: 4.7 is not out yet, thus no reason to increase the minor
version beyond th
The following patch avoids issues with TYPE_STUB_DECL.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-12-14 Richard Guenther
* tree.c (free_lang_data_in_type): Do not clear fields
dependent on debuginfo level setting.
(find_decls_type
On Mon, 5 Dec 2011, Tom G. Christensen wrote:
> Latest results for 4.6.x
Thanks, Tom. Applied.
Gerald
On Wed, Dec 14, 2011 at 9:25 AM, Hans-Peter Nilsson
wrote:
>> From: Dmitry Vyukov
>> Date: Tue, 13 Dec 2011 11:43:18 +0100
>
>> On Tue, Dec 13, 2011 at 3:04 AM, Hans-Peter Nilsson
>> wrote:
>> > Details in PR51521.
>> Sorry for the trouble. What should I do now?
>
> Do what Diego and others aske
82 matches
Mail list logo
