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
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
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
18 matches
Mail list logo
