> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
> wrote:
>
> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
>> As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
>> UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk
>> and change the
On 2020-01-09, Fangrui Song wrote:
On 2020-01-08, Fangrui Song wrote:
On 2020-01-07, Szabolcs Nagy wrote:
On 07/01/2020 07:25, Fangrui Song wrote:
On 2020-01-06, Fangrui Song wrote:
The addresses of NOPs are collected in a section named
__patchable_function_entries.
A __patchable_function_
On 2020-01-08, Fangrui Song wrote:
On 2020-01-07, Szabolcs Nagy wrote:
On 07/01/2020 07:25, Fangrui Song wrote:
On 2020-01-06, Fangrui Song wrote:
The addresses of NOPs are collected in a section named
__patchable_function_entries.
A __patchable_function_entries entry is relocated by a symbol
This is at LTO time and the function in question is this:
#include "stdlib.h"
typedef struct bogus type_ta;
struct bogus {
int i;
double x;
int j;
};
void
helper( void *x)
{
type_ta *y = (type_ta*)x;
y->i = rand();
}
and I'm checking the local_decls it like this:
cgraph_node* node
On Thu, 9 Jan 2020, Joseph Myers wrote:
> On Mon, 16 Sep 2019, Joel Brobecker wrote:
>
> > Looking at the configuration file, I believe the git-hooks
> > should have most, if not all, of the features that would be needed for
> > the GCC repository. In particular, there is already a way to relay
>
On Thu, 9 Jan 2020, Joseph Myers wrote:
> Here's a test conversion with the conversion machinery in what should be
> essentially final form. This is like the "b" versions (dead and vendor
> branches present but not fetched by default), with the addition of refs
> from the existing git mirror a
Richard,
Alas, when doing structure reorg I have to be able to know some
arbitrary use of variable X in some GIMPLE expression is of a
type that needs to be transformed in that given expression. I see no
way around this.
From: Richard Biener
Sent: Thursday, Januar
Hi Christophe,
> Actually I got a confirmation of what I suspected: the offending function
> foo()
> is part of ARM CMSIS libraries, although the users are able to recompile them,
> they don't want to modify that source code. Having a compilation option to
> avoid generating problematic code sequ
On Tue, 7 Jan 2020 at 17:33, Christophe Lyon wrote:
>
> On Tue, 7 Jan 2020 at 17:18, Marc Glisse wrote:
> >
> > On Tue, 7 Jan 2020, Christophe Lyon wrote:
> >
> > > I've received a support request where GCC generates strd/ldrd which
> > > require aligned memory addresses, while the user code actu
On Mon, 16 Sep 2019, Joel Brobecker wrote:
> Looking at the configuration file, I believe the git-hooks
> should have most, if not all, of the features that would be needed for
> the GCC repository. In particular, there is already a way to relay
> commits to third-party tools via calling of a scri
Joseph Myers :
> I want to consider the conversion machinery essentially frozen at this
> point and not to add any new features not present in the conversion now
Very well, I won't push the inegration change for those commits.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Richard Earnshaw (lists) :
> I want to also take this opportunity to thank Maxim for the work he has
> done. Having that fallback option has meant that we could press harder for
> a timely solution and has also driven several significant improvements to
> the overall result. I do not think we wou
On Thu, 9 Jan 2020, Eric S. Raymond wrote:
> If anyone else can scrounge up materials that could help complete
> the fossil sequence, now would be a really good time for that. We
> have only three days at most left to integrate them.
I want to consider the conversion machinery essentially frozen
On Sat, Dec 28, 2019 at 9:01 PM GT wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 9, 2019 3:39 AM, Richard Biener
> wrote:
>
> > > I'm modifying the code trying to get complex double accepted as a valid
> > > type by the vectorizer.
> > > This is the first time I'm dealing wi
On 1/9/20 1:37 PM, Joseph Myers wrote:
On Thu, 9 Jan 2020, Martin Liška wrote:
On 1/9/20 12:45 PM, Martin Jambor wrote:
I use the release tags every now and then so this caught my attention
but I do not understand what the problem is?
Problem is that if you do:
$ git log origin/releases/gcc-
I have been able to rescue or reconstruct from patches the following
prehisoric GCC releases
gcc-0.9
gcc-1.21
gcc-1.22
gcc-1.25
gcc-1.26
gcc-1.27
gcc-1.28
gcc-1.35
gcc-1.36
gcc-1.37.1
gcc-1.38
gcc-1.39
gcc-1.40
gcc-1.41
gcc-1.42
gcc-2.1
gcc-2.2.2
gcc-2.3.3
gcc-2.4.5
gcc-2.5.8
gcc-2.6.3
gcc-2.7.2
On Thu, 9 Jan 2020, Martin Liška wrote:
> On 1/9/20 12:45 PM, Martin Jambor wrote:
> > I use the release tags every now and then so this caught my attention
> > but I do not understand what the problem is?
>
> Problem is that if you do:
> $ git log origin/releases/gcc-9
>
> you will not find the
On Wed, 8 Jan 2020, Jeff Law wrote:
> Is there any chance we could get one more trunk snapshot before the
> conversion starts -- even if that means firing up the snapshot process
> Friday? It'd be quite useful for the ongoing Fedora build testing.
I could run a snapshot manually. I was planning
On Fri, 3 Jan 2020, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Joseph Myers wrote:
>
> > Two more.
> >
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6b.git
>
> Two more.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposur
On 09/01/2020 02:38, Segher Boessenkool wrote:
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk
and change the SVN hooks to make SVN read
On 09/01/2020 11:57, Richard Earnshaw (lists) wrote:
On 09/01/2020 11:45, Martin Jambor wrote:
Hi,
On Thu, Jan 09 2020, Martin Liška wrote:
Hi.
I have question about release branches and release tags. For the current
git mirror, we do have release tags living on release branches. Example:
co
On 09/01/2020 11:45, Martin Jambor wrote:
Hi,
On Thu, Jan 09 2020, Martin Liška wrote:
Hi.
I have question about release branches and release tags. For the current
git mirror, we do have release tags living on release branches. Example:
commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66
Author:
On Thu, Jan 9, 2020 at 9:53 AM Jan Hubicka wrote:
>
> > There doesn't seem to be a way to compare types at LTO time. The functions
> > same_type_p and comptypes are front end only if I'm not totally confused
> > (which is quite possible) and type_hash_eq doesn't seem to apply for
> > structure typ
On 1/9/20 12:45 PM, Martin Jambor wrote:
I use the release tags every now and then so this caught my attention
but I do not understand what the problem is?
Problem is that if you do:
$ git log origin/releases/gcc-9
you will not find the 9.2.0 tag. Which is a useful information when
you seek fo
Hi,
On Thu, Jan 09 2020, Martin Liška wrote:
> Hi.
>
> I have question about release branches and release tags. For the current
> git mirror, we do have release tags living on release branches. Example:
>
> commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66
> Author: jakub
> Date: Mon Aug 12 08:40
Martin Liška :
> > Anyway, please check Joseph's next candidate to see if this shows what you
> > expect -- I think it should be out later today.
>
> I'll check it once it's published.
Everybody: time is growing short before the final conversion, so if you
see anything that looks wrong or anomal
On 1/9/20 11:51 AM, Richard Earnshaw (lists) wrote:
SVN makes tags using copy operations. By default this tends to result in the
copies hanging off the side of the main branch and so the tags are not in a
particularly git-friendly location. Reposurgeon has code now to try to spot
this and co
On 09/01/2020 09:44, Martin Liška wrote:
Hi.
I have question about release branches and release tags. For the current
git mirror, we do have release tags living on release branches. Example:
commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66
Author: jakub
Date: Mon Aug 12 08:40:24 2019 +
Am 13.12.19 um 13:45 schrieb Richard Sandiford:
Georg-Johann Lay writes:
Am 11.12.19 um 18:55 schrieb Richard Sandiford:
Georg-Johann Lay writes:
Hi, doesn't actually anybody know know to make memory more expensive
than registers when it comes to allocating registers?
Whatever I am trying f
Hi.
I have question about release branches and release tags. For the current
git mirror, we do have release tags living on release branches. Example:
commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66
Author: jakub
Date: Mon Aug 12 08:40:24 2019 +
* BASE-VER: Set to 9.2.1.
> There doesn't seem to be a way to compare types at LTO time. The functions
> same_type_p and comptypes are front end only if I'm not totally confused
> (which is quite possible) and type_hash_eq doesn't seem to apply for
> structure types. Please, any advice would be welcome.
At LTO time it is b
31 matches
Mail list logo
