OK.
On Fri, Sep 21, 2018 at 3:51 PM, Marek Polacek wrote:
> Use the proper type for "complain".
>
> I guess it's obvious, but anyway, bootstrapped/regtested on x86_64-linux, ok
> for trunk?
>
> 2018-09-21 Marek Polacek
>
> * cp-tree.h (build_noexcept_spec, add_exception_specifier): Adj
Use the proper type for "complain".
I guess it's obvious, but anyway, bootstrapped/regtested on x86_64-linux, ok
for trunk?
2018-09-21 Marek Polacek
* cp-tree.h (build_noexcept_spec, add_exception_specifier): Adjust
declarations.
* except.c (build_noexcept_spec): Chang
Jakub spotted this wart in my last change.We have already tested
that we do not have 0 or 1 ops. So != 2 is more clearly written as > 2.
Bootstrapped and regression tested on x86_64. Committed to the trunk.
Jeff
commit 04acc76e9d46299f5251bf9f495d1b7688d7907f
Author: law
Date: Fri Oct 1
On Fri, Jul 21, 2017 at 10:36:46AM +0200, Ulrich Drepper wrote:
> While looking through dwarf2out.c I came across this if expression where
> supposedly in case DWARF before 5 is used the 128 LEB encoding is used.
> This of course cannot be the case. There isn't really a deeper problem
> since th
While looking through dwarf2out.c I came across this if expression where
supposedly in case DWARF before 5 is used the 128 LEB encoding is used.
This of course cannot be the case. There isn't really a deeper problem
since the entire block is guarded by a test for at least DWARF 5.
I propose the
On 12/12/2016 02:03 PM, Marek Polacek wrote:
At least these should be HOST_WIDE_INTs rather than ints. There might be
more opportunities than this.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-12-12 Marek Polacek
* tree-data-ref.c (compute_overlap_steps_for_affine_uni
At least these should be HOST_WIDE_INTs rather than ints. There might be
more opportunities than this.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-12-12 Marek Polacek
* tree-data-ref.c (compute_overlap_steps_for_affine_univar): Change
parameters' type from int
Hi,
Consider testcase:
...
int __attribute__((noinline, noclone))
foo (int *__restrict__ a, int *__restrict__ b)
{
*a = 1;
*b = 2;
}
int __attribute__((noinline, noclone))
bar (int *a, int *b)
{
foo (a, b);
}
...
Using this patch we have this diff in the pta dumpfile:
...
@@ -24,7 +24,7 @
Hi,
On Mon, 30 Sep 2013, Jeff Law wrote:
> > - the compiler better do an awesome job of sharing stack space for
> > user variables in a function... I wouldn't want to blow up the stack
> > with a bazillion unrelatd temps each wit their own location.
> If the objects have the same type and disj
On 09/28/13 08:31, Andrew MacLeod wrote:
temps would be OK with me, but there are a couple of concerns.
- I'd want to be able to declare the temps at the point of use, not
the top of the function. this would actually help with clarity I think.
Not sure what the current coding standard says abo
On 09/30/13 02:05, Michael Matz wrote:
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
My example in this form would look something like:
int unsignedsrcp = ptrvar.type().type().type_unsigned();
<...>
GimpleType t1 = ptrvar.type ();
GimpleType t2 = t1.type ();
Stop that CamelCase dyslexia al
On 09/30/2013 04:05 AM, Michael Matz wrote:
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
My example in this form would look something like:
int unsignedsrcp = ptrvar.type().type().type_unsigned();
<...>
GimpleType t1 = ptrvar.type ();
GimpleType t2 = t1.type ();
Stop that CamelCase dyslexi
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
> My example in this form would look something like:
> int unsignedsrcp = ptrvar.type().type().type_unsigned();
>
> <...>
> GimpleType t1 = ptrvar.type ();
> GimpleType t2 = t1.type ();
Stop that CamelCase dyslexia already, will you? ;-)
Ciao,
M
On 09/27/2013 01:03 AM, Jeff Law wrote:
On 09/26/2013 08:15 AM, Michael Matz wrote:
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 cod
On 09/26/2013 08:15 AM, Michael Matz wrote:
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Yea. I actual
On 09/26/2013 10:21 AM, Richard Biener wrote:
On Thu, Sep 26, 2013 at 4:15 PM, Michael Matz wrote:
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the
On Thu, Sep 26, 2013 at 4:15 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 25 Sep 2013, Jeff Law wrote:
>
>> > > I was going to bring it up at some point too. My preference is
>> > > strongly to simply eliminate the space on methods...
>> > Which wouldn't be so weird: in the libstdc++-v3 code we do i
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
> > > I was going to bring it up at some point too. My preference is
> > > strongly to simply eliminate the space on methods...
> > Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
> Yea. I actually reviewed the libstdc++ guide
On Wed, Sep 25, 2013 at 01:18:06PM -0600, Jeff Law wrote:
> On 09/25/2013 10:04 AM, Jakub Jelinek wrote:
> >On Wed, Sep 25, 2013 at 11:46:12AM -0400, Andrew MacLeod wrote:
> >>I noticed that with the wrapper conversion, often you will get a
> >>sequence of 3 or more method calls, and its quite unbe
On 09/25/2013 10:04 AM, Jakub Jelinek wrote:
On Wed, Sep 25, 2013 at 11:46:12AM -0400, Andrew MacLeod wrote:
I noticed that with the wrapper conversion, often you will get a
sequence of 3 or more method calls, and its quite unbearable to have
the spaces.
simple things like
int unsignedsrcp =
On Wed, Sep 25, 2013 at 11:46:12AM -0400, Andrew MacLeod wrote:
> I noticed that with the wrapper conversion, often you will get a
> sequence of 3 or more method calls, and its quite unbearable to have
> the spaces.
> simple things like
> int unsignedsrcp = ptrvar.type().type().type_unsigned();
>
On 09/25/2013 09:48 AM, Paolo Carlini wrote:
On 9/25/13 10:46 AM, Andrew MacLeod wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Yea. I actual
On 9/25/13 10:46 AM, Andrew MacLeod wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Paolo.
On 09/25/2013 11:33 AM, Jeff Law wrote:
I was looking at the vec class to figure out the best way to do some
things and realized we have a "last" member function. Using
foo.last() is clearer than foo[foo.length() - 1]
On a related note, our current standards require a space between a
funct
I was looking at the vec class to figure out the best way to do some
things and realized we have a "last" member function. Using foo.last()
is clearer than foo[foo.length() - 1]
On a related note, our current standards require a space between a
function name and the open paren for its argum
25 matches
Mail list logo
