Hi,
On ARM-Embedded-4_7 branch, check-in(r193980) causes a "branch out of range"
bug. Root cause is the incorrect instruction length set by that check-in.
Since the length of instruction should strictly reflect the pattern it
matches, this patch fixes it by correcting the length.
Patch applied to
On Thu, Feb 21, 2013 at 12:38 PM, Benjamin De Kosnik wrote:
> Not seeing it.
>
> Say for:
>
> #include
>
> // A class for math constants.
> template
> struct __math_constants
> {
> // Constant @f$ \pi @f$.
> static constexpr _RealType __pie =
> 3.141592653589793238462643
On 02/28/2013 07:31 PM, Paolo Carlini wrote:
for 4.9 I'd like to clean-up a bit grokdeclarator: today I noticed this
low hanging fruit which seems straightforward enough for 4.8.0 too
(unless it hints to a bug?!?)
OK, looks like the code that set that variable was removed in 2004, by
the cdk_*
Hi,
for 4.9 I'd like to clean-up a bit grokdeclarator: today I noticed this
low hanging fruit which seems straightforward enough for 4.8.0 too
(unless it hints to a bug?!?)
Thanks,
Paolo.
//
2013-03-01 Paolo Carlini
* decl.c (grokdeclarator): Remove dead c
On Thu, Feb 28, 2013 at 11:59 AM, Jakub Jelinek wrote:
> On Thu, Feb 28, 2013 at 11:57:48AM -0800, Cary Coutant wrote:
>> Similarly, couldn't dlopen drop the loader lock while calling malloc?
>
> It can't, but perhaps it could call some alternative malloc instead
> (the simpler malloc version in l
On Thu, Feb 28, 2013 at 1:21 PM, Uros Bizjak wrote:
> On Thu, Feb 28, 2013 at 9:55 PM, Ian Lance Taylor wrote:
>> On Thu, Feb 28, 2013 at 12:44 PM, Uros Bizjak wrote:
>>>
I'm fine with not blocking a signal that the debugger needs, but I
have no idea what that signal might be.
>>>
>>>
On Thu, Feb 28, 2013 at 9:07 AM, Xinliang David Li wrote:
> Any insight about the relative performance of the two implementations?
We have a benchmark for the speed of unwinder. Here are results.
The number /1, /2, etc. is the number of levels in the stack trace.
Using frame-based unwinder:
B
Jakub Jelinek writes:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2013-02-28 Konstantin Serebryany
> Jakub Jelinek
>
> PR sanitizer/56454
> * asan.c (gate_asan): Lookup no_sanitize_address instead of
> no_address_safety_analysis attr
On Thu, Feb 28, 2013 at 3:06 PM, Jakub Jelinek wrote:
> Hi!
>
> This is small, but quite common memory leak in slp vectorization.
> vec_alloc (vec_defs, number_of_vects);
> on vl_ptr-ish vec *vec_defs; first calls new on the vec
> (i.e. allocates sizeof (void *) bytes), and then actually creates v
The problem with this testcase was that for a repeated &&, each call of
potential_constant_expression_1 led to two calls for the LHS, giving it
O(N^2) complexity. Fixed by avoiding the redundant call in
maybe_constant_value by calling cxx_eval_outermost_constant_expr directly.
Tested x86_64-p
Hi!
I'm not very happy about the renaming of the attribute, but it happened
in clang already, so here is a patch to do the same in gcc too.
The old name of the attribute is recognized too for compatibility e.g.
with code written for clang 3.[12] sanitizer, and during attribute parsing
changed into
Hi!
On #include on Linux we leak memory in the preprocessor.
The problem is that signal.h doesn't have standard multiple inclusion
guards, the multiple inclusion guard is defined only conditionally
and the whole header isn't protected by that guard, just big part of it.
Furthermore, signal.h incl
Hi!
This is small, but quite common memory leak in slp vectorization.
vec_alloc (vec_defs, number_of_vects);
on vl_ptr-ish vec *vec_defs; first calls new on the vec
(i.e. allocates sizeof (void *) bytes), and then actually creates vector
pointed to by that. Later on we copy the content of what it
On Thu, Feb 28, 2013 at 11:57:48AM -0800, Cary Coutant wrote:
> Similarly, couldn't dlopen drop the loader lock while calling malloc?
It can't, but perhaps it could call some alternative malloc instead
(the simpler malloc version in ld.so or similar).
Jakub
> Thread 1Thread 2
> dlopen malloc
>... takes loader lock ... takes malloc lock
>malloc _Unwind_Backtrace
>... needs malloc lock dl_iterate_phdr
>held by T2... needs loader lock held
On Thu, Feb 28, 2013 at 04:30:13PM +0400, Konstantin Serebryany wrote:
> I am sorry, I missed this message.
> Indeed, the change looks safe,
> http://llvm.org/viewvc/llvm-project?rev=176250&view=rev
Thanks, here is what I've committed to gcc:
2013-02-28 Jakub Jelinek
* asan/asan_mappi
> "Jakub" == Jakub Jelinek writes:
Jakub> 2013-02-27 Jakub Jelinek
Jakub> * files.c (_cpp_find_file): If returning early, before storing
Jakub> something to *hash_slot and *hash_slot is NULL, call htab_clear_slot
Jakub> on it. Access *hash_slot using void * type rather than
Jakub> st
On 28 February 2013 13:28, Rainer Orth wrote:
> Hi Paolo,
>
>> On 02/26/2013 12:33 PM, Rainer Orth wrote:
>>> Ok for mainline?
>> I suppose you don't need an approval for the Solaris-specific files, like
>> such baselines.
>
> probably not, but it's certainly good to have the changes sanity-checked
On Thu, Feb 28, 2013 at 07:27:48PM +0100, Marek Polacek wrote:
> The hunk
> probability = (double) REG_BR_PROB_BASE * compare_count / loop_count;
> in there should be probably handled in the same way. But I'll handle
> that separately.
>
> In the first hunk, I did s/int/HOST_WIDE_INT/, because H
On Thu, Feb 28, 2013 at 10:10 AM, Paul Pluzhnikov
wrote:
> On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor wrote:
>
>>> does call dl_iterate_phdr, which is just as deadly.
>>
>> Hmmm, I guess I can't remember why.
>
> Let me refresh your memory. You've seen this deadlock before:
>
> Thread 1
The following testcase ICEd because we were trying to negate
"-9223372036854775808", which results in UB, since it's LLONG_MAX + 1.
Then we got a SIGFPE on
-LLONG_MIN / -1
So fixed by doing the arithmetics on trees, and in case we got
an overflow, we bail out.
The hunk
probability = (double) REG_
On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor wrote:
>> does call dl_iterate_phdr, which is just as deadly.
>
> Hmmm, I guess I can't remember why.
Let me refresh your memory. You've seen this deadlock before:
Thread 1Thread 2
dlopen malloc
..
On Thu, Feb 28, 2013 at 8:23 AM, Paul Pluzhnikov wrote:
> On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor wrote:
>
>> I think that the libgcc unwinder only calls malloc if somebody calls
>> __register_frame_info.
>
> So I looked. Indeed it doesn't call malloc in our environment, but
> does call
Tilman Sauerbeck [2013-02-24 17:00]:
> Richard Earnshaw [2013-02-20 11:00]:
> > On 19/02/13 22:26, Tilman Sauerbeck wrote:
> > >I don't get why relaxing the restrictions for the
> > >andsi3_compare0_scratch pattern results in a mismatch for the
> > >zeroextractsi_compare0_scratch one.
> > >
> > >An
On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor wrote:
> I think that the libgcc unwinder only calls malloc if somebody calls
> __register_frame_info.
So I looked. Indeed it doesn't call malloc in our environment, but
does call dl_iterate_phdr, which is just as deadly.
To be fair, libunwind d
OK
On 28 February 2013 09:36, James Greenhalgh wrote:
>
> Hi,
>
> aarch64_mangle_type has no prototype, but it doesn't need one as
> it should be declared static.
>
> This patch fixes the warning:
>
> config/aarch64/aarch64.c:5974:1: warning: no previous prototype for
> ‘aarch64_mangle_type’ [-W
OK
On 28 February 2013 09:38, James Greenhalgh wrote:
>
> Hi,
>
> In aarch64_float_const_representable, `sign' is unused.
>
> This patch removes all references to it. The patch is equally
> applicable to trunk and aarch64-4.7-branch.
>
> This patch fixes the warning:
>
> config/aarch64/aarch64.c:
OK
On 28 February 2013 09:40, James Greenhalgh wrote:
>
> Hi,
>
> aarch64_simd_make_constant has no prototype, but it doesn't
> need one as it should be declared static.
>
> This patch fixes the warning:
>
> config/aarch64/aarch64.c:6574:1: warning: no previous prototype for
> ‘aarch64_simd_make
OK
On 28 February 2013 09:34, James Greenhalgh wrote:
>
> Hi,
>
> aarch64_init_simd_buitlins is not declared with a prototype, but it
> doesn't need one as it should be declared static.
>
> This patch fixes the warning:
>
> config/aarch64/aarch64-builtins.c:314:1: warning: no previous prototype f
On 02/28/2013 02:06 AM, Julian Brown wrote:
> On Wed, 27 Feb 2013 11:04:04 -0800
> Janis Johnson wrote:
>
>> On 02/27/2013 09:29 AM, Julian Brown wrote:
>>> Index: gcc/testsuite/gcc.dg/vect/slp-cond-3.c
>>> ===
>>> --- gcc/testsuite/
On 02/25/2013 06:25 PM, Jason Merrill wrote:
On 02/25/2013 06:24 PM, Jason Merrill wrote:
I think my preference would be to avoid calling fixed_type_or_null at
all when we're in a template. I already changed
resolves_to_fixed_type_p that way, now we need to fix build_vtbl_ref_1.
Oops, now I s
On Thu, Feb 28, 2013 at 9:54 AM, Andrew Sutton
wrote:
> Attached is the initial documentation for the previous patch.
Patch OK. Thanks!
-- Gaby
>
> Andrew
>
>
> 2013-02-28 Andrew Sutton
>
> * doc/extend.texi (write_symbol): Initial concept docs.
>
> On Thu, Feb 28, 2013 at 9:11 AM,
Attached is the initial documentation for the previous patch.
Andrew
2013-02-28 Andrew Sutton
* doc/extend.texi (write_symbol): Initial concept docs.
On Thu, Feb 28, 2013 at 9:11 AM, Gabriel Dos Reis
wrote:
> On Thu, Feb 28, 2013 at 9:01 AM, Andrew Sutton
> wrote:
>> Of course. I'
Dave> How did it build in the without sys/sdt.h case?
Sorry about that again.
I must have made some change after testing it.
Here is an updated version.
One thing I found out while fixing this up is that changes to
unwind-cxx.h do not cause anything to rebuild if I just run "make". I
have to
On Thu, Feb 28, 2013 at 9:01 AM, Andrew Sutton
wrote:
> Of course. I'll send that along shortly.
Patch OK.
-- Gaby
>
> Andrew
>
> On Thu, Feb 28, 2013 at 8:51 AM, Gabriel Dos Reis
> wrote:
>> On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton
>> wrote:
>>> Reserving a handful of new keywords for
Of course. I'll send that along shortly.
Andrew
On Thu, Feb 28, 2013 at 8:51 AM, Gabriel Dos Reis
wrote:
> On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton
> wrote:
>> Reserving a handful of new keywords for concepts and several new type
>> traits in preparation for future work on concepts.
>>
>>
On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton
wrote:
> Reserving a handful of new keywords for concepts and several new type
> traits in preparation for future work on concepts.
>
> Andrew
>
> 2013-02-05 Andrew Sutton
>
> * c-common.h (rid): New resreserved words for concepts.
>
> "Dave" == Dave Korn writes:
Dave> How did it build in the without sys/sdt.h case?
Dave> Without HAVE_SYS_SDT_H, there's no definition of PROBE2 at all,
Dave> but you use it unconditionally in eh_{catch,throw}.cc. Am I
Dave> missing something?
Ugh. I must have made some mistake in my t
Reserving a handful of new keywords for concepts and several new type
traits in preparation for future work on concepts.
Andrew
2013-02-05 Andrew Sutton
* c-common.h (rid): New resreserved words for concepts.
* c-common.c (c_common_reswords): Definitions thereof.
reswords.pa
Hi Paolo,
> On 02/26/2013 12:33 PM, Rainer Orth wrote:
>> Ok for mainline?
> I suppose you don't need an approval for the Solaris-specific files, like
> such baselines.
probably not, but it's certainly good to have the changes sanity-checked
by someone with knowledge of the libstdc++ ABI, even if
Hi,
On 02/26/2013 12:33 PM, Rainer Orth wrote:
Ok for mainline?
I suppose you don't need an approval for the Solaris-specific files,
like such baselines.
Paolo.
On Fri, Feb 22, 2013 at 8:32 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote:
>> Sure. ASAN_FIXED_MAPPING should be used for performance measurements
>> only -- this is not a release option.
>> (Added a more precise comment).
>
> BTW, today I think
On 27/02/2013 21:52, Tom Tromey wrote:
> I'm posting this now to get reactions to the probe before cleaning up
> the corresponding gdb patches for submission. I've built it both with
> and without sys/sdt.h, but I haven't yet run the test suite.
How did it build in the without sys/sdt.h case?
Hi,
Ports should call final_start_function and final_end_function to get
proper debug info for the thunk as per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55257#c3 . Fixes failing
tests in g++.dg for arm-*-*eabi.
Tested on arm-linux-gnueabi cross for armv7-a, arm/thumb2 and armv5t on
qemu
On Wed, 27 Feb 2013 11:04:04 -0800
Janis Johnson wrote:
> On 02/27/2013 09:29 AM, Julian Brown wrote:
> > Index: gcc/testsuite/gcc.dg/vect/slp-cond-3.c
> > ===
> > --- gcc/testsuite/gcc.dg/vect/slp-cond-3.c (revision 196170)
> > +++
On Thu, Feb 28, 2013 at 02:32:02PM +0900, Miles Bader wrote:
> Marek Polacek writes:
> > + bool changed = false;
> > + changed |= true;
> > + changed |= true;
> > + changed |= true;
> > + changed |= true;
> > +if (changed)
>
> Why do you use "|=" ...? Isn't it equivalent to
Hi,
aarch64_simd_make_constant has no prototype, but it doesn't
need one as it should be declared static.
This patch fixes the warning:
config/aarch64/aarch64.c:6574:1: warning: no previous prototype for
‘aarch64_simd_make_constant’ [-Wmissing-prototypes]
Which is hidden when building with g+
Hi,
In aarch64_float_const_representable, `sign' is unused.
This patch removes all references to it. The patch is equally
applicable to trunk and aarch64-4.7-branch.
This patch fixes the warning:
config/aarch64/aarch64.c: In function ‘aarch64_float_const_representable_p’:
config/aarch64/aarch6
Hi,
aarch64_mangle_type has no prototype, but it doesn't need one as
it should be declared static.
This patch fixes the warning:
config/aarch64/aarch64.c:5974:1: warning: no previous prototype for
‘aarch64_mangle_type’ [-Wmissing-prototypes]
Which is hidden when building with g++, but looks l
Hi,
aarch64_init_simd_buitlins is not declared with a prototype, but it
doesn't need one as it should be declared static.
This patch fixes the warning:
config/aarch64/aarch64-builtins.c:314:1: warning: no previous prototype for
‘aarch64_init_simd_builtins’ [-Wmissing-prototypes]
Which is hidd
http://gcc.gnu.org/r196332
This is obvious fix for problem with empty macro parameter.
Instead of an empty parameter, 'n' is used.
Johann
PR target/56445
* config/avr/avr.c (avr_init_builtins): Use 'n' instead of empty
macro parameters with: FX_FTYPE_FX, FX_FTYPE_FX_INT,
51 matches
Mail list logo
