Hi Nick,
On 4/8/22 14:36, Nick Clifton wrote:
Hi Luis,
There is a CVE [1] for zlib < 1.2.12 (released march 27th).
GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib
directory from GCC. The recommendation is to get it updated to 1.2.12,
which contains the proper fix [2].
I
Hi,
There is a CVE [1] for zlib < 1.2.12 (released march 27th).
GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib
directory from GCC. The recommendation is to get it updated to 1.2.12,
which contains the proper fix [2].
It might not affect gcc/binutils/gdb since the code does
Hi,
cc-ing the GCC mailing list, as we may want to use the same coding style
for GDB and GCC.
Yesterday I brought this topic up on IRC. I notice we started using more
and more the "auto" keyword. In some cases, this is actually useful and
makes the code a bit more compact. GDB has been using
On 10/16/19 11:17 AM, Luis Machado wrote:
Hi Maciej,
On 10/16/19 11:11 AM, Maciej W. Rozycki wrote:
Hi Luis,
Is there a better way to force the compiler to output such a line table
transition without having to resort to a dummy jump? Is there a safer
way to add such transitions without
On 10/16/19 5:59 AM, Richard Biener wrote:
I think that adding an extra jump is unwanted. Instead - if you disregard
the single-source-line case - there's always the jump and the label we jump
to which might/should get different source locations. Like in one of the above
cases:
main ()
{
in
Hi Maciej,
On 10/16/19 11:11 AM, Maciej W. Rozycki wrote:
Hi Luis,
Is there a better way to force the compiler to output such a line table
transition without having to resort to a dummy jump? Is there a safer
way to add such transitions without worrying about the optimizer getting
rid of them
Hi,
I'd like to get some feedback from the compiler's side before
implementing a fix for this line numbering problem. I also want to make
sure i fix it in the right tool.
This is related to this bug report in GDB's bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=21221
It deals wi
Actually, thinking further, the fix is for a consequence of the
incorrect placement of the breakpoint right after the branch.
I remember hitting the problem described too, but i didn't pursue a fix
for that (yet).
Luis
On Tue, 2009-07-21 at 10:50 -0300, Luis Machado wrote:
> Hi,
>
Hi,
Yes, this is exactly what i was chasing some time ago. The GCC fix i had
in mind (it just changes the ordering of statements) didn't get through
since it dealt with arch-independent code and there was fear that this
would break architectures other than PPC (or have the potential to do
so).
Th
Hi Vladimir,
Firstly, thanks for looking into this.
> Analysis of 187.facerec problem was actually easier than applu one.
> It has one very hot (80%) function localmove::graphRoutines.f90 and
> there is only one hot loop in the function. Although the loop is
> pretty big because of inlining To
On Mon, 2008-09-08 at 09:47 -0400, Vladimir Makarov wrote:
> Jeff Law wrote:
> > H.J. Lu wrote:
> >> My understanding is PowerPC is quite sensitive to choice of register
> >> as shown in PR 28690. IRA merge may make fixes for PR 28690
> >> ineffective. There are a few small testcases in PR 28690. Y
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
> On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
> >> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]>
>
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> >
> > H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
>
> I won't apply any non-IRA related patches to ira-merge branch so
> that you can g
On Fri, 2008-09-05 at 12:36 -0400, Vladimir Makarov wrote:
> Luis Machado wrote:
> > Hi Vladimir,
> >
> > I was just going through some benchmarks on PPC and noticed that your
> > patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> > caused
On Fri, 2008-09-05 at 09:03 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 8:01 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
> >> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> >
On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> > Hi Vladimir,
> >
> > I was just going through some benchmarks on PPC and noticed that your
> > patch from 08/26 (http://gcc.gnu.org
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu (~4%)
for 64-bit PPC.
There are other degradations that i'm still working on i
17 matches
Mail list logo
