Hi,
Please consider this as a gentle reminder to review the patch
posted at following link:-
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00823.html
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
Hi,
Please consider this as a gentle reminder to review the patch
posted at following link:-
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01412.html
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
Hi,
Please consider this as a reminder to review the patch posted at
following link:-
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01374.html
The patch is slightly modified to use CC_NZ mode instead of CC.
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
--- gcc
Is it OK for wwdocs?
Index: gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.96
diff -u -r1.96 changes.html
--- gcc-4.8/changes.html12 Feb 2013 16:33:58 - 1.96
++
cp_parser_member_declaration was seeing that the type-specifier in the
declaration had function type and concluded from that that the
declaration would have function type, without noticing that the
declarator isn't a simple identifier. We should check that.
Tested x86_64-pc-linux-gnu, applyin
On 02/13/2013 01:40 PM, Jason Merrill wrote:
I just noticed this patch. Since it was submitted well before the end
of stage 3 and looks quite safe, it's OK to go in for 4.8. Please
remember to CC/ping me for C++ patches.
Thanks,
Jason
Applied the following after build and test on x86_64-unk
On Tue, 12 Feb 2013, Jason Merrill wrote:
> Although __int128_t is technically not an extended integer type because we
> don't want to change intmax_t, it seems appropriate to me to give it the same
> semantics as an extended integer type apart from that one aspect.
>
> The only thing we weren't
ok.
thanks,
David
On Wed, Feb 13, 2013 at 4:41 PM, Sriraman Tallam wrote:
> Updated patch attached.
>
> Thanks
> Sri
>
> On Wed, Feb 13, 2013 at 4:39 PM, Sriraman Tallam wrote:
>> On Wed, Feb 13, 2013 at 4:32 PM, Xinliang David Li
>> wrote:
>>> when split_segment is specified but the API doe
Updated patch attached.
Thanks
Sri
On Wed, Feb 13, 2013 at 4:39 PM, Sriraman Tallam wrote:
> On Wed, Feb 13, 2013 at 4:32 PM, Xinliang David Li wrote:
>> when split_segment is specified but the API does not exist, why not
>> making it fatal ? Will it crash at some point when the null pointer is
On Wed, Feb 13, 2013 at 4:32 PM, Xinliang David Li wrote:
> when split_segment is specified but the API does not exist, why not
> making it fatal ? Will it crash at some point when the null pointer is
> referenced later?
It cannot be referenced later as the handlers will not get registered.
I wil
when split_segment is specified but the API does not exist, why not
making it fatal ? Will it crash at some point when the null pointer is
referenced later?
David
On Wed, Feb 13, 2013 at 4:19 PM, Sriraman Tallam wrote:
> Hi,
>
>I have attached a patch for the reordering plugin to display
> a
Hi,
I have attached a patch for the reordering plugin to display
appropriate error messages when incorrect options are passed or when
some API is unavailable.
The plugin will use the ld_plugin_message linker API to flag errors
(fatal or non-fatal) when incorrect options are passed or when t
On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote:
> > I agree with David that it might be better to give up pch.
>
> That'd be a really a good start.
You can do it with say following patch instead, PCH is just a compile time
optimization, so for -gstabs IMHO it is just fine if we j
On Thu, Feb 14, 2013 at 12:17 AM, John David Anglin wrote:
> On 2013-02-13 3:33 PM, David Edelsohn wrote:
>>
>> Perhaps Dave can explain what would have to be done to move this
>> > platform to DWARF2...?
>> >
>
> I had looked at this a bit in the past. I don't think it's that difficult
>
On 2013-02-13 3:33 PM, David Edelsohn wrote:
Perhaps Dave can explain what would have to be done to move this
> platform to DWARF2...?
>
I had looked at this a bit in the past. I don't think it's that
difficult to add DWARF2 support
to GCC on hppa. Although we don't support named sect
On Wed, Feb 13, 2013 at 2:14 PM, Chao-Ying Fu wrote:
> Hello All,
>
> Once in a while we got reports about programs (ex: WebKit, FireFox)
> crash due to ldc1/sdc1 unaligned accesses on MIPS targets. The root cause is
> that programmers
> neglect the alignment issue and cast arbitrary pointers
Hello,
today I found this patch that I had written a couple months ago, and I am
wondering whether we want it for 4.8. I am tempted to keep ?: undocumented
as long as the C front-end doesn't have it. The fact that very few
optimizations are done on it (and some might still be broken) is anothe
On 13-02-07 2:11 PM, Tom de Vries wrote:
Vladimir,
On 25/01/13 16:36, Vladimir Makarov wrote:
On 01/25/2013 08:05 AM, Tom de Vries wrote:
Vladimir,
this patch adds analysis of register usage of functions for usage by IRA.
The patch:
- adds analysis in pass_final to track which hard registers
Hello All,
Once in a while we got reports about programs (ex: WebKit, FireFox)
crash due to ldc1/sdc1 unaligned accesses on MIPS targets. The root cause is
that programmers
neglect the alignment issue and cast arbitrary pointers to point to double
variables.
Although the correct solution i
On 02/13/13 13:07, Jakub Jelinek wrote:
On Wed, Feb 13, 2013 at 11:23:24AM -0700, Jeff Law wrote:
On 02/13/13 08:54, Jakub Jelinek wrote:
That looks just like the patch I have here. Yet, I'm still seeing failures:
Running target unix/-m32/-gstabs
Using /usr/share/dejagnu/baseboards/unix.exp as
On 2/13/13, Diego Novillo wrote:
> Thanks. The patch is OK for the branch. You can address Nathan's
> review after he's back and gets a chance to look at it.
>
> Let me know when the patch is in. I've got another merge in process.
Committed.
--
Lawrence Crowl
On Wed, Feb 13, 2013 at 12:14 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 10:57:42AM -0800, Sriraman Tallam wrote:
>> I committed a trivial patch to fix this problem. mv12-aux.C is
>> auxiliary to mv12.C and should have the same test directives as
>> mv12.C.
>>
>> 2013-02-13 Sriraman Talla
On 02/13/2013 01:12 PM, Steven Bosscher wrote:
* ix86-*-interix* - no solution immediately available, and no-one
listed in MAINTAINERS to ask for help, so maybe Doug can say
something about this one?
Microsoft has pulled the plug on Interix, Windows 7 will be the last
version of Windows
The AIX system supports DWARF debugging, but GCC does not generate it
on AIX and GDB does not consume it on AIX.
There is no way that I will allow experimental DWARF support to be
enabled at the same time STABS support is removed.
This is a non-starter.
If you want to disable PCH on STABS system
On 18-Jan-13 20:35, Maxim Kuvyrkov wrote:
On 19/01/2013, at 9:18 AM, rbmj wrote:
-150,7 +158,7 @@ static __gthread_once_t tls_init_guard =
need to read tls_keys.dtor[key] atomically. */
static void
-tls_delete_hook (void *tcb ATTRIBUTE_UNUSED)
+tls_delete_hook (void *tcb)
Don't rem
On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote:
> Hi!
>
> As agreed on in the PR, here is the revertion of 3 commits, so that
> PCH works again for -gstabs and other debug info formats for 4.8
> release. For 4.9 we should either remove support for anything non-DWARF, or
> hope somebody steps
Hi,
>2013-02-13 Marc Glisse
>
> PR libstdc++/56111
> * include/std/complex (complex): Undefine.
> * include/c_compatibility/complex.h (complex): Only undefine if
>has been included.
> * testsuite/26_numerics/complex/56111.cc: New testcase.
Patch is Ok, thanks. Y
Committed then.
2013-02-13 François Dumont
* include/bits/hashtable_policy.h (_Hash_code_base): Restore
default constructor protected.
* include/bits/hashtable.h: static assert that _Hash_code_base has
a default constructor available through inheritance.
On 02/13/2013 12:36
On Wed, Feb 13, 2013 at 09:37:42PM +0100, Dodji Seketeli wrote:
> Hello,
>
> It appeared that in my previous patch, a stupid thinko can lead to a
> crash when instrumenting some builtin functionsK. Fixed thus.
>
> Tested against trunk on x86_64-unknown-linux-gnu, and a bootstrap is underway.
>
Jakub Jelinek writes:
> This is just a small improvement for Dodji's work. We can flush the hash
> table with memory references known to be instrumented only at extended basic
> block boundaries, no need to flush it at every bb (of course, for 4.9 we
> want to do something better).
This makes a
Hello,
It appeared that in my previous patch, a stupid thinko can lead to a
crash when instrumenting some builtin functionsK. Fixed thus.
Tested against trunk on x86_64-unknown-linux-gnu, and a bootstrap is underway.
gcc/
* asan.c (instrument_builtin_call): Really put the length of the
On Wed, Feb 13, 2013 at 10:57:42AM -0800, Sriraman Tallam wrote:
> I committed a trivial patch to fix this problem. mv12-aux.C is
> auxiliary to mv12.C and should have the same test directives as
> mv12.C.
>
> 2013-02-13 Sriraman Tallam
>
> * g++.dg/ext/mv12-aux.C: Add directives to ma
On Wed, Feb 13, 2013 at 11:48:32AM -0500, Jack Howarth wrote:
> On Wed, Feb 13, 2013 at 04:19:14PM +0100, Jakub Jelinek wrote:
> >
> > The reexec is problematic, what if the program already in constructors run
> > before __asan_init (perhaps ctors of other libraries etc.) does something
> > that r
Thanks. The patch is OK for the branch. You can address Nathan's
review after he's back and gets a chance to look at it.
Let me know when the patch is in. I've got another merge in process.
Diego.
On Wed, Feb 13, 2013 at 11:23:24AM -0700, Jeff Law wrote:
> On 02/13/13 08:54, Jakub Jelinek wrote:
> That looks just like the patch I have here. Yet, I'm still seeing failures:
>
> Running target unix/-m32/-gstabs
> Using /usr/share/dejagnu/baseboards/unix.exp as board description
> file for tar
On 2/13/13, Diego Novillo wrote:
> On Tue, Feb 12, 2013 at 2:47 PM, Lawrence Crowl wrote:
>> @@ -182,24 +163,9 @@ default_emutls_var_init (tree to, tree d
>> static tree
>> get_emutls_object_type (void)
>> {
>> - tree type, type_name, field;
>> -
>> - type = emutls_object_type;
>> - if (typ
On Wed, Feb 13, 2013 at 12:07:52PM -0600, Aldy Hernandez wrote:
> >Sorry, just noticed:
> >
> >>+ /* If the optabs changed, record it in the node. */
> >>+ if (memcmp (tmp_target_optabs, &default_target_optabs,
> >>+ sizeof (struct target_optabs)))
> >
> >This should be this_target_optab
Hello,
this patch was tested on x86_64-linux-gnu. For the testcase, I randomly
picked c99.cc which I copied and c++11 -> c++98, _Complex -> complex, but
anything using the macro would do.
2013-02-13 Marc Glisse
PR libstdc++/56111
* include/std/complex (complex): Undefine.
On Tue, Feb 12, 2013 at 2:47 PM, Lawrence Crowl wrote:
> @@ -182,24 +163,9 @@ default_emutls_var_init (tree to, tree d
> static tree
> get_emutls_object_type (void)
> {
> - tree type, type_name, field;
> -
> - type = emutls_object_type;
> - if (type)
> -return type;
> -
> - emutls_obje
Thomas Koenig wrote:
*ping*
* pong *
I'd like to get this into 4.8 before release.
Others as well, given that it is a release-blocking P1 regression …
However, I have already approved it:
http://gcc.gnu.org/ml/fortran/2013-02/msg00061.html
Tobias
On Wed, Feb 13, 2013 at 07:20:10PM +0100, Tobias Burnus wrote:
> *** PING ***
>
> I think it is now a bit late for 4.8. Thus, I change my request to: OK
> for the 4.9 trunk?
>
IMHO, yes. Don't know if others have an opinion, but
waiting any longer would seem to be counter productive.
--
Stev
*ping*
I'd like to get this into 4.8 before release.
> This version of the patch should fix that particular issue, and also has
no test cases.
Regression-tested. OK?
I can leave out the FIXME if people object.
Thomas
Hi!
This is just a small improvement for Dodji's work. We can flush the hash
table with memory references known to be instrumented only at extended basic
block boundaries, no need to flush it at every bb (of course, for 4.9 we
want to do something better). And, now that we have nonfreeing_call_p
ions
>> > +// are defined in different files. Auxiliary file for mv12.C.
>> > +// { dg-do compile }
>> > +
>> > +#include "mv12.h"
>> > +
>> > +__attribute__ ((target ("sse4.2")))
>> > +int foo ()
>>
>&g
I just noticed this patch. Since it was submitted well before the end
of stage 3 and looks quite safe, it's OK to go in for 4.8. Please
remember to CC/ping me for C++ patches.
Thanks,
Jason
On Wed, Feb 13, 2013 at 1:19 AM, Konstantin Serebryany
wrote:
> Hi,
>
> The attached patch is the libsanitizer merge from upstream r175042.
>
> Lots of changes. Among other things:
> - x86_64 linux: change the shadow offset to 0x7fff8000 (~5% speedup)
> - the new asan allocator is enabled on Mac
On 02/13/13 08:54, Jakub Jelinek wrote:
Hi!
As agreed on in the PR, here is the revertion of 3 commits, so that
PCH works again for -gstabs and other debug info formats for 4.8
release. For 4.9 we should either remove support for anything non-DWARF, or
hope somebody steps up and fixes dbxout.c
*** PING ***
I think it is now a bit late for 4.8. Thus, I change my request to: OK
for the 4.9 trunk?
Tobias
On January 5, 2013 00:31, Tobias Burnus wrote:
This patch "removes" -fno-whole-file. (Actually, it turns it into
"Ignore".)
Reasoning:
* -fwhole-file/-fno-whole-file was added in
From: Richard Biener
Date: Wed, 13 Feb 2013 12:15:13 +0100
> On Tue, Feb 12, 2013 at 11:31 PM, David Miller wrote:
>> Maybe what we really mean to do here is check both op1 and SUBREG_REG
>> (op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?
>
> Yes.
Ok, I'll commit this after doing s
Most of the G++ linkage code really needs to be torn out in favor of
just using cgraph. Until that happens, we need to set TREE_USED here so
that decl_needed_p will return true and allow cgraph to consider the
function.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 701e03d86ff
> Backport to 4.7.3, tested on i686-w64-mingw32, x86_64-w64-mingw32 and
> x86_64-unknown-gnu-linux.
>
> OK to apply?
OK
> 2013-02-13 Rainer Emrich
>
> PR target/52123
> * adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via
> SECURITY_DESCRIPTOR *
> (__gnat_set_OW
Backport to 4.7.3, tested on i686-w64-mingw32, x86_64-w64-mingw32 and
x86_64-unknown-gnu-linux.
OK to apply?
Rainer
2013-02-13 Rainer Emrich
PR target/52123
* adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via
SECURITY_DESCRIPTOR *
(__gnat_set_OWNER_ACL)
Sorry, just noticed:
+ /* If the optabs changed, record it in the node. */
+ if (memcmp (tmp_target_optabs, &default_target_optabs,
+ sizeof (struct target_optabs)))
This should be this_target_optabs rather than &default_target_optabs.
Nothing but target code and initialisers
On 02/13/13 10:44, Vladimir Makarov wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
The problem was in that reg equiv was not corrected for a split pseudo
because of incorrect code for recognition of situation when a split
pseudo was created.
The patch was su
> Here's a simple additional patch against trunk for 32bit mingw.
>
> OK to apply?
OK, thanks.
> Rainer
>
> 2013-02-13 Rainer Emrich
>
> PR target/52123
> * tracebak.c: Cast from pointer via FARPROC
Here's a simple additional patch against trunk for 32bit mingw.
OK to apply?
Rainer
2013-02-13 Rainer Emrich
PR target/52123
* tracebak.c: Cast from pointer via FARPROC
Index: ada/tracebak.c
===
--- ada/traceba
Aldy Hernandez writes:
> Richard.
>
> I made all the changes you suggested.
>
> I also changed other instances of s/this_target_optabs/this_fn_optabs/
> which I forgot in the previous iteration. And I also changed
> save_optabs_if_changed() to use this_fn_optabs, since init_all_optabs()
> will
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
The problem was in that reg equiv was not corrected for a split pseudo
because of incorrect code for recognition of situation when a split
pseudo was created.
The patch was successfully bootstrapped and tested on x86
Richard.
I made all the changes you suggested.
I also changed other instances of s/this_target_optabs/this_fn_optabs/
which I forgot in the previous iteration. And I also changed
save_optabs_if_changed() to use this_fn_optabs, since init_all_optabs()
will generate the optabs into this_fn_opt
In this PR, the constexpr evaluator was confused by a parameter that
changed to a reference type after the constant expression body was saved
for later evaluation; we ended up trying to evaluate an address of an
address, since we added one address on the caller side to pass to the
invisible ref
On Wed, Feb 13, 2013 at 04:19:14PM +0100, Jakub Jelinek wrote:
>
> The reexec is problematic, what if the program already in constructors run
> before __asan_init (perhaps ctors of other libraries etc.) does something
> that really shouldn't be done twice?
>
Jakub,
Wouldn't sorting all of the
Hi!
So that we don't keep GCC trunk in known broken state, I've
bootstrapped/regtested this change and installed it.
2013-02-13 Jakub Jelinek
* config/i386/i386.c (ix86_asan_shadow_offset): Revert last change.
* asan/asan_mapping.h (SHADOW_OFFSET): Set to (1ULL << 44) on x86-
OK.
Hi!
As agreed on in the PR, here is the revertion of 3 commits, so that
PCH works again for -gstabs and other debug info formats for 4.8
release. For 4.9 we should either remove support for anything non-DWARF, or
hope somebody steps up and fixes dbxout.c etc. not to emit debug info right
away, bu
Hi!
My SIZEOF_EXPR deferred folding changes regressed some sys/sdt.h macros
at -O0, the sizeof in there is no longer folded, so instead of
say "n" (-8) we ended up with "n" (-1 * (int) sizeof (void *)) and similar,
and as at -O0 we don't really optimize, the asm got rejected.
Fixed thusly, conste
On Wed, Feb 13, 2013 at 05:39:15PM +0400, Konstantin Serebryany wrote:
> > No. You can disable it for the whole system (prelink -ua), but that is not
> > a sane requirement to running sanitized programs.
>
> Why not?
> :)
Because that is a fully system operation, requires root access, etc.
The f
Hi,
On 02/13/2013 03:38 PM, Jason Merrill wrote:
On 02/12/2013 07:55 AM, Paolo Carlini wrote:
Again, the current status is in a sense good because when the
_GLIBCXX_HAVE_AT_QUICK_EXIT and _GLIBCXX_HAVE_QUICK_EXIT are defined,
thus the system has the functions in its c library, including
makes
On Wed, Feb 13, 2013 at 11:32:00AM +0100, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote:
> > Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1,
> > so this came unnoticed.
> > Fixed in r175049.
> ...
>
> This is ok, thanks.
>
>
The tests gcc.target/arm/interrupt-*.c are for ARM mode only.
This patch uses effective target arm_notthumb instead of __thumb_ predefine,
removes unreachable code, and fixes typos.
Ok for trunk?
Thanks,
Greta
ChangeLog
gcc/testsuite/
2012-02-13 Greta Yorsh
* gcc.target/arm/interr
On 02/12/2013 07:55 AM, Paolo Carlini wrote:
Again, the current status is in a sense good because when the
_GLIBCXX_HAVE_AT_QUICK_EXIT and _GLIBCXX_HAVE_QUICK_EXIT are defined,
thus the system has the functions in its c library, including
makes available the functions in namespace std irrespecti
When we added empty base handling to the ADDR_EXPR case in
cxx_fold_indirect_ref, we forgot to add it to the POINTER_PLUS_EXPR case
as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ed30015624f7d3f396e11fd5d96b548348a74688
Author: Jason Merrill
Date: Tue Feb 12 23:12:10 2013 -05
Within the { } of an enum-specifier with a fixed underlying type, the
enumerators are supposed to have that type. A comment in
build_enumerator mentioned that requirement, but nothing actually
implemented it.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4944c862e7cd742a4d963bc50ce4ac
When the only use of 'this' is implicitly by a dependent name, we don't
see the capture until instantiation time. Don't clobber its capture
list entry when we instantiate the ones seen at template definition time.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit cdcb44a750af3921d688383289
Hi Tobias,
since you're fixing test cases: What about PR 55852 comment 10?
"The test case fails because the match is too strict.
$ grep iszs intrinsic_size_3.f90.003t.original
integer(kind=2) iszs;
iszs = (integer(kind=2)) MAX_EXPR <(D.854->dim[0].ubound -
D.854->dim[0].lbound) + 1,
On Wed, Feb 13, 2013 at 5:07 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote:
>> On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek wrote:
>> > On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
>> >> > Unfortunately, it seems every
This patch defines peephole2 patterns that merge two individual LDR
instructions into LDRD instruction (resp. STR into STRD) whenever possible
using the following transformations:
* reorder two memory accesses,
* rename registers when storing two constants, and
* reorder target registers of a load
On Wed, Feb 13, 2013 at 02:27:56PM +0100, Richard Biener wrote:
> ASAN could set an ELF flag on the executable to tell the kernel not
> to use prelinked objects? That is, similar to how we handle executable
> stacks?
But we don't have such a flag right now, and what should old kernels that
don't
On 13 February 2013 13:28, James Greenhalgh wrote:
>
> Hi,
>
> If we enable section anchors by default we must fix the
> ABI testcase which is not expecting section anchors.
>
> This was fixed by Andrew Pinski on trunk here:
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00580.html
> So we backpor
Hi,
If we enable section anchors by default we must fix the
ABI testcase which is not expecting section anchors.
This was fixed by Andrew Pinski on trunk here:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00580.html
So we backport that fix.
I've tested this with no regressions on aarch64-none-e
On 13 February 2013 13:26, James Greenhalgh wrote:
>
> Hi,
>
> This patch is a backport of the section anchors support introduced
> to aarch64-branch here:
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00384.html
>
> The patch has been tested for aarch64-none-elf with only a known
> regression, f
On Wed, Feb 13, 2013 at 2:07 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote:
>> On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek wrote:
>> > On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
>> >> > Unfortunately, it seems every
Hi,
This patch is a backport of the section anchors support introduced
to aarch64-branch here:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00384.html
The patch has been tested for aarch64-none-elf with only a known
regression, fixed by backporting this patch by Andrew Pinski:
http://gcc.gnu.org
Le 13/02/2013 14:00, Richard Biener a écrit :
> Of course not. Next they'll add blver ...
Sorry
On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote:
> On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek wrote:
> > On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
> >> > Unfortunately, it seems everything fails with that change :( on Linux.
> >> > The problem
On Wed, Feb 13, 2013 at 1:55 PM, Mikael Morin wrote:
> Le 13/02/2013 09:32, Gopalasubramanian, Ganesh a écrit :
>> +Support for new AMD family 16h processors (Jaguar core) is now
>> available
>> + through -march=btver2 and -mtune=btver2
>> options.
>
> s/btver2/bdver2/ ?
Of course not.
On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
>> > Unfortunately, it seems everything fails with that change :( on Linux.
>> > The problem is that the default prelink library range for x86_64 is
>> > 0x30LL to
Le 13/02/2013 09:32, Gopalasubramanian, Ganesh a écrit :
> +Support for new AMD family 16h processors (Jaguar core) is now
> available
> + through -march=btver2 and -mtune=btver2
> options.
s/btver2/bdver2/ ?
On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
> > Unfortunately, it seems everything fails with that change :( on Linux.
> > The problem is that the default prelink library range for x86_64 is
> > 0x30LL to 0x40LL, and that unfortunately overlaps
>
> Forgiv
On Wed, Feb 13, 2013 at 3:59 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 11:32:00AM +0100, Jakub Jelinek wrote:
>> On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote:
>> > Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1,
>> > so this came unnoticed.
>
I have committed a fix for PR 56082, where the test case assumed that
C_Bool is a byte wide (kind=1); however, on 32bit Darwin, C_Bool is by
default an "int" (kind=4) – hence, a warning is not printed. The change
was to use logical(kind=2) for the example, assuming C_Bool is never kind=2.
Commi
This should fix PR50494 - when we gimplify a local initializer
via a block copy and emit a constant to the constant pool we
stream the representative VAR_DECL with LTO, including its
eventually changed alignment. When we then lookup RTL for this
constant at
/* If this variable belongs to the g
On Wed, Feb 13, 2013 at 11:32:00AM +0100, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote:
> > Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1,
> > so this came unnoticed.
> > Fixed in r175049.
> ...
>
> This is ok, thanks.
Unfortu
This fixes part 2 of PR56295, it un-does MEM_REF wrapping on the
writer side. Otherwise code-generation differences at compile-time
appear -flto vs. -fno-lto (with fat LTO objects).
LTO bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-02-13 Richard Biener
PR l
"Moore, Catherine" writes:
>> > Index: config/mips/mips.c
>> >
>> ==
>> =
>> > --- config/mips/mips.c (revision 195351)
>> > +++ config/mips/mips.c (working copy)
>> > @@ -77,6 +77,9 @@ along with GCC; see the file COPYING3.
On 13 February 2013 10:11, Richard Biener wrote:
>
> This fixes the reported ICE on arm. Similar to tree level unswitching
> RTL level unswitching can expose formerly irreducible regions as new
> loops. The following patch makes sure to discover them (we now
> verify we do).
>
> Bootstrap and re
On Wed, Feb 13, 2013 at 12:17 PM, Igor Zamyatin wrote:
>>
>> Please also mention new -mfxsr, -mxsave and -mxsaveopt options.
>>
>>>New built-in functions to detect run-time CPU type and ISA:
>>>
>>> A built-in function __builtin_cpu_is has been
>>> added to
>>>
>
> Please also mention new -mfxsr, -mxsave and -mxsaveopt options.
>
>>New built-in functions to detect run-time CPU type and ISA:
>>
>> A built-in function __builtin_cpu_is has been added
>> to
>> ***
>> *** 524,529
>> --- 530,538
>> http://gcc.
On Tue, Feb 12, 2013 at 11:31 PM, David Miller wrote:
> From: David Miller
> Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)
>
>> From: Richard Sandiford
>> Date: Mon, 29 Oct 2012 10:14:53 +
>>
>>> ...given that the code is like you say written:
>>>
>>> if (SHIFT_COUNT_TRUNCATED)
>>> {
>>>
On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote:
> Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1,
> so this came unnoticed.
> Fixed in r175049.
...
This is ok, thanks.
Jakub
And here 2/2 with the device -> arch mapping for gas.
Ok for trunk?
Johann
* config/avr/avr.h (device_to_arch): Rename to device_to_ld.
(avr_device_to_arch): Rename to avr_device_to_ld.
(avr_device_to_as): New prototype.
(EXTRA_SPEC_FUNCTIONS): Add device_to_as.
1 - 100 of 107 matches
Mail list logo
