On Wed, Mar 18, 2020 at 11:30:22PM -0400, Christopher Faylor wrote:
>On Wed, Mar 18, 2020 at 06:44:15PM -0400, Frank Ch. Eigler wrote:
>>> N.B. the CC list has got too big and is causing posts to this thread
>>> to be held for moderator approval.
>>
>>Ah, can cycle through the lists and raise that
On Wed, Mar 18, 2020 at 06:44:15PM -0400, Frank Ch. Eigler wrote:
>> N.B. the CC list has got too big and is causing posts to this thread
>> to be held for moderator approval.
>
>Ah, can cycle through the lists and raise that limit.
>The default 10 is too low.
Didn't you have to lower that limit f
Hi Nick,
On Wed, Mar 18, 2020 at 08:56:11PM -0400, Nicholas Krause wrote:
> I've not sure if I've misunderstanding something in the combine code but
> in make_more_copies
> for combine.c this seems very odd:
> if (!(REG_P (dest) && !HARD_REGISTER_P (dest)))
> continue;
>
> rtx src = SET_
Greetings Segher,
I've not sure if I've misunderstanding something in the combine code but
in make_more_copies
for combine.c this seems very odd:
if (!(REG_P (dest) && !HARD_REGISTER_P (dest)))
continue;
rtx src = SET_SRC (set);
if (!(REG_P (src) && HARD_REGISTER_P (src)))
Hi!
On Wed, Mar 18, 2020 at 02:52:14PM -0700, Jim Wilson wrote:
> I'm one of the old timers that likes our current work flow, but even I
> think that we are risking our future by staying with antiquated tools.
It's not ancient tools, it is low-requirement generic tools, and
everyone can use that
Hi!
On Wed, Mar 18, 2020 at 06:33:08PM -0400, Frank Ch. Eigler wrote:
> > [...] We need to think about setting up easier ways for people to
> > submit patches, rather than trying to fix all of the MUAs and MTAs
> > in the world.
>
> Another related point. We are comingling email as a communicat
On Wed, 18 Mar 2020 at 22:45, Joseph Myers wrote:
>
> On Wed, 18 Mar 2020, Jonathan Wakely via Gcc wrote:
>
> > > Some git based projects are using gerrit.
> >
> > Which I looked into previously and decided I didn't like it. If I
> > recall correctly, gerrit has to "own" the repo, and so it's only
On Wed, 18 Mar 2020, Jonathan Wakely via Gcc wrote:
> > Some git based projects are using gerrit.
>
> Which I looked into previously and decided I didn't like it. If I
> recall correctly, gerrit has to "own" the repo, and so it's only
The glibc experiment with gerrit worked without it owning the
Hi -
> N.B. the CC list has got too big and is causing posts to this thread
> to be held for moderator approval.
Ah, can cycle through the lists and raise that limit.
The default 10 is too low.
- FChE
N.B. the CC list has got too big and is causing posts to this thread
to be held for moderator approval.
On Wed, 18 Mar 2020 at 21:54, Jim Wilson wrote:
>
> I'm one of the old timers that likes our current work flow, but even I
> think that we are risking our future by staying with antiquated tools.
> One of the first things I need to teach new people is now to use email
> "properly". It is a barrier
Hi, Jim -
> [gerrit etc.]
Good points.
> [...] We need to think about setting up easier ways for people to
> submit patches, rather than trying to fix all of the MUAs and MTAs
> in the world.
Another related point. We are comingling email as a communication
medium AND a commit transport mediu
I'm one of the old timers that likes our current work flow, but even I
think that we are risking our future by staying with antiquated tools.
One of the first things I need to teach new people is now to use email
"properly". It is a barrier to entry for new contributors, since our
requirements are
That's a known to-do item – see "cvsweb/svn" under
https://sourceware.org/sourceware-wiki/MigrationWorkItems/?updated
Tobias
On 3/18/20 9:07 PM, Nicholas Krause via Gcc wrote:
On 3/18/20 3:49 PM, Martin Sebor via Gcc wrote:
I've been getting Error 403 (Forbidden - You don't have permission
t
On 3/18/20 3:49 PM, Martin Sebor via Gcc wrote:
I've been getting Error 403 (Forbidden - You don't have permission
to access /viewcvs on this server) following the Subversion links
in Bugzilla for some time now (they worked for me before the switch
to Git, but I'm not sure if they also did bef
I've been getting Error 403 (Forbidden - You don't have permission
to access /viewcvs on this server) following the Subversion links
in Bugzilla for some time now (they worked for me before the switch
to Git, but I'm not sure if they also did before the recent hardware
upgrade).
For example:
www.gam.cati...@gam.cat
___
Copyright
© 2020· Gam Consultoría y Formación· C/ Pirineus s/n (esq. Orriols) 17460
Celrà
www.gam.cati...@gam.cat
___
Copyright
© 2020· Gam Consultoría y Formación· C/ Pirineus s/n (esq. Orriols) 17460
Celrà
Hello,
On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > > The From: header rewriting for DMARC participants is something sourceware
> > > is doing now.
> >
> > Out of curiousity, is this rewriting you are talking about the cause for a
> > lot of mails showing up as "From: GCC List" rathe
Hi -
> > The From: header rewriting for DMARC participants is something sourceware
> > is doing now.
>
> Out of curiousity, is this rewriting you are talking about the cause for a
> lot of mails showing up as "From: GCC List" rather than their real senders?
> This has become very annoying recentl
On 3/18/20 3:22 PM, Frank Ch. Eigler via Gcc wrote:
The From: header rewriting for DMARC participants is something sourceware
is doing now.
Out of curiousity, is this rewriting you are talking about the cause for
a lot of mails showing up as "From: GCC List" rather than their real
senders? Th
On Tue, 17 Mar 2020, Giuliano Belinassi wrote:
> Hi, all
>
> I have applied some revews to the project. Please see the new proposal
> here:
Looks good, some editorial changes below
> https://www.ime.usp.br/~belinass/Automatic_Detection_of_Parallel_Compilation_Viability.pdf
>
> **Automatic Dete
Hi -
> [...] You're talking about rewriting or adding headers (where the
> former is Real Bad, no matter what DMARC wants to impose), but the
> suggestion is based on not rewriting the body. If the body
> (including attachtments) is rewritten any way then that simply is a
> bug. [...]
We're mix
Hi,
On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > > The key here is to realize that the raw message is not what you get
> > > back from the mailing list reflector, and also not the raw message
> > > that was sent by the sender. In this day of mta intermediaries,
> > > proxies, reflect
* Frank Ch. Eigler:
> Hi -
>
>> > The key here is to realize that the raw message is not what you get
>> > back from the mailing list reflector, and also not the raw message
>> > that was sent by the sender. In this day of mta intermediaries,
>> > proxies, reflectors, it may be time to revisit th
That way we can have a clean subsystems of commands for easy processing
On Tue, 17 Mar 2020, Giuliano Belinassi wrote:
> Hi, Richi
>
> Thank you for your review!
>
> On 03/16, Richard Biener wrote:
> > On Fri, 13 Mar 2020, Giuliano Belinassi wrote:
> >
> > > Hi, all
> > >
> > > I want to propose and apply for the following GSoC project: Automatic
> > > Detection o
Thanks Richard!
This is very helpful to see where you’re going with the changes!
Cheers,
Tamar
From: Richard Biener
Sent: Friday, March 13, 2020 11:57 AM
To: Tamar Christina
Cc: Kewen.Lin ; GCC Development ; Segher
Boessenkool
Subject: Re: How to extend SLP to support this case
On Tue, Mar
Hi -
> > The key here is to realize that the raw message is not what you get
> > back from the mailing list reflector, and also not the raw message
> > that was sent by the sender. In this day of mta intermediaries,
> > proxies, reflectors, it may be time to revisit that suggestion.
>
> But thes
* Frank Ch. Eigler via Gcc:
>> > Are you trying to copy from the raw message representation?
>>
>> Everyone trying to work with a patch (instead of just the email) always
>> is working with the raw message. Just patch < mbox or git-am mbox
>> for example.
>>
>> https://gcc.gnu.org/contribute
Good Morning
We have attach our March order to this mail, confirm this order
by return mail and issue send Invoice Asap.
Thanks & Best Regards
May Lee
Know How International GmbH & Co. KG
Import
* aotto:
> Hi, the following scenario has a "definition hole" in the "C" language
>
> code example:
>
> -
> struct base {
> ...
> };
>
> struct A {
> struct base obj;
> ...
> } aObj;
>
> struct B {
> struct base obj;
> ...
> } bObj;
>
> void method_base (stru
On Mär 17 2020, Holger Lamm wrote:
> ANSI C 6.5.8 (5) confirms that "... pointers to structure members
> declared later compare greater than pointers to members
> declared earlier in the structure"; I found no definition of address
> to structure vs. address of structure member but t
33 matches
Mail list logo
