> Furthermore, it continues to nullify the Apache License by allowing patent
> treachery. The LLVM License is thus a perfidious license intended to
> allow the licensor to sue you at their choosing.=
“Patent treachery”? And the intent of the license is to... accommodate lawsuits?
That’s some
I was under the (likely incorrect, please enlighten me) impression
that the meteoric rise of LLVM had more to do with the license
allowing corporate contributors to ship derived works in binary form
without sharing proprietary code. - NightStrike
You are correct. LLVM is under the Apache
You have specified that the community does not require my approval or that
of Eric Raymond. That is true of course. But many have gone through so
much new age training that they ended up with a very sophisticated way
of bullshitting themselves.
Regards
Christopher
> I'll see my work in GCC11
The code presented at the time wrestrict was invoking ranger has a basic
block with about 7200 statements, all of them calculations which fed
into 2614 logical ORs and 1480 logical ANDs.
the GORI component which calculates outgoing ranges starts at the exit
of the block and works it way back
This conversation has moved well off-topic for the GCC mailing lists.
Some of the posts here do not follow the GNU Kind Communication
Guidelines (https://www.gnu.org/philosophy/kind-communication.en.html).
I suggest that people who want to continue this thread take it off the
GCC mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #11 from YunQiang Su ---
This problem will happen when gcc is configured with
--with-build-config=bootstrap-lto-lean
Option.
On 2021-04-17 12:08, Christopher Dimech wrote:
Thomas,
So we are decided? I am not pushing anybody down the cliff - rms, you
or anybody. I simply wish that after
a few world wars, people start seeing the light and things will be
somewhat blissed out working on free software.
In a lot of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132
--- Comment #1 from José Rui Faustino de Sousa ---
Patch posted
https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
Hi All!
Proposed patch to:
PR100132 - Optimization breaks pointer association.
Patch tested only on x86_64-pc-linux-gnu.
Correct pointer attributes when passing polymorphic pointers.
Thank you very much.
Best regards,
José Rui
Fortran: Fix function attributes [PR100132]
ing with -O1 or -O2, curiously not with
-O3 unless -fcheck=recursion is used
Seen on:
GNU Fortran (GCC) 11.0.1 20210417 (experimental)
GNU Fortran (GCC) 10.3.1 20210417
GNU Fortran (GCC) 9.3.1 20210417
Thank you very much.
Best regards,
José Rui
Snapshot gcc-10-20210417 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20210417/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100115
--- Comment #3 from Martin Sebor ---
The reason why the warning tends to disappear in a simpler test case is because
of the limit (I just had it happen with my reduction). Don't spend more time
on it than you already have, I'll work with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-04-17
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95763
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #19 from Jonathan Wakely ---
Why is that needed? It says the location is something like:
In member function ‘info& info::operator=(const info&)’,
or:
In copy constructor ‘info::info(const info&)’,
If that isn't explicitly defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100062
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> Since you say this happens on a DSO level why is this not achieved via some
> additional object at link-time (like crt*.o)? It sounds like you place
> the CDTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Glibc should probably act as though __NO_CTYPE is implicitly defined by
> __cplusplus, so that the effect is independent of the order of includes.
Or it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95364
Andrew Pinski changed:
What|Removed |Added
Severity|normal |trivial
Summary|[Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128
--- Comment #1 from Jonathan Wakely ---
(In reply to Travis Downs from comment #0)
> Evidently, the behavior and definitions exposed by these headers should not
> depend on the order of include. I suspect there are other cases besides the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124
Martin Sebor changed:
What|Removed |Added
Blocks||69698
--- Comment #5 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95034
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk so far, guess some backporting will be useful.
On Sat, Apr 17, 2021 at 11:25 AM Fangrui Song wrote:
>
>
> On 2021-04-17, H.J. Lu wrote:
> >On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote:
> >>
> >> On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
> >> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
> >> >>
> >> >> 1.
On 2021-04-17 10:40, Ville Voutilainen via Gcc wrote:
On Sat, 17 Apr 2021 at 20:31, Christopher Dimech
wrote:
I do not see people really intending to fork. It explains why
detractors
have gone berserk.
I appreciate your colorful exaggerations, but I should point out that
the libstdc++
On 2021-04-17, H.J. Lu wrote:
On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote:
On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
>On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
>>
>> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
>>
>> #define GNU_PROPERTY_UINT32_AND_LO 0xb000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971
David Stone changed:
What|Removed |Added
CC||davidfromonline at gmail dot
com
---
On 17/04/2021 13:56, Giacomo Tesio wrote:
> Hi Gerald,,
>
> On April 17, 2021 9:09:19 AM UTC, Gerald Pfeifer wrote:
>> On Fri, 16 Apr 2021, Frosku wrote:
>>> In my view, if people employed by a small number of American
>> companies
>>> succeed in disassociating GCC from GNU/FSF, which is
> Sent: Sunday, April 18, 2021 at 5:40 AM
> From: "Ville Voutilainen"
> To: "Christopher Dimech"
> Cc: "Jason Merrill" , "GCC Development"
> Subject: Re: A suggestion for going forward from the RMS/FSF debate
>
> On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote:
> > I do not see people
On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote:
> I do not see people really intending to fork. It explains why detractors
> have gone berserk.
I appreciate your colorful exaggerations, but I should point out that
the libstdc++
maintainer has stated his intention to fork, in unambigous
> Sent: Sunday, April 18, 2021 at 5:07 AM
> From: "Ville Voutilainen"
> To: "Jason Merrill"
> Cc: "Christopher Dimech" , "GCC Development"
> Subject: Re: A suggestion for going forward from the RMS/FSF debate
>
> On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote:
> >
> > On Fri, Apr 16, 2021
On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote:
>
> On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc
> wrote:
> > > Sent: Saturday, April 17, 2021 at 1:03 AM
> > > From: "Ville Voutilainen"
> > > To: "Christopher Dimech"
> > > Cc: "GCC Development"
> > > Subject: Re: A
Fundamentally, "micro-aggressions" describe insults and dismissals.
Interpreting insults and dismissals as aggression leads only to
an atrophy of the skills needed to mediate one's own disputes with
others. I oppose the use of the term absolutely.
-
Christopher Dimech
> Sent: Saturday, April 17, 2021 at 9:41 PM
> From: "Frosku"
> To: "Giacomo Tesio" , "Andrew Pinski" ,
> "Andrew Pinski via Gcc"
> Subject: Re: removing toxic emailers
>
> On Sat Apr 17, 2021 at 10:08 AM BST, Giacomo Tesio wrote:
> > But in fact, millions of people outside the US would feel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #18 from Jonny Grant ---
Hello Martin
It looks better.
May I ask, if the "implicitly generated copy assignment" and "copy constructor"
could be mentioned in the warning that they were implicitly generated?
Thank you, Jonny
> Sent: Saturday, April 17, 2021 at 11:56 PM
> From: "Giacomo Tesio"
> To: gcc@gcc.gnu.org, "Gerald Pfeifer" , "Frosku"
>
> Subject: Re: removing toxic emailers
>
> Hi Gerald,,
>
> On April 17, 2021 9:09:19 AM UTC, Gerald Pfeifer wrote:
> > On Fri, 16 Apr 2021, Frosku wrote:
> > > In my view,
Hi Jose,
Please take a look at my reply on the PR, which points to PR98534.
Regards
Paul
On Fri, 16 Apr 2021 at 20:47, José Rui Faustino de Sousa via Fortran <
fort...@gcc.gnu.org> wrote:
> Hi All!
>
> Proposed patch to:
> PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS
> Sent: Saturday, April 17, 2021 at 9:25 PM
> From: "Frosku"
> To: "Aaron Gyes" , gcc@gcc.gnu.org
> Subject: Re: removing toxic emailers
>
> On Sat Apr 17, 2021 at 10:04 AM BST, Aaron Gyes via Gcc wrote:
> > On Apr 17, 2021, at 1:36 AM, Frosku wrote:
> > > I feel imposed upon when, as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100131
Alexander Lelyakin changed:
What|Removed |Added
CC||alexander.lelyakin@googlema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
--- Comment #3 from Alexander Lelyakin ---
During last two and a half weeks
3 bugs was closed:
99283 - in assert_definition
99284 - in key_mergeable
99427 - non-constant condition for static assertion
99246 ICE in write_location was reopened
> Sent: Saturday, April 17, 2021 at 9:09 PM
> From: "Gerald Pfeifer"
> To: "Frosku"
> Cc: gcc@gcc.gnu.org
> Subject: Re: removing toxic emailers
>
> On Fri, 16 Apr 2021, Frosku wrote:
> > In my view, if people employed by a small number of American companies
> > succeed in disassociating GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100131
Bug ID: 100131
Summary: [meta-bug] internal compiler error: in
hashtab_chk_error, at hash-table.c:137
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100115
--- Comment #2 from Boris Kolpackov ---
> I'm trying to reduce the test case to something manageable but that can take
> many hours, even days.
Right. On our side we have spent hours, even days trying to suppress this
warning (both by
> >> It would be usefull to clarify with the FSF and GNU what the
> >> actual relations are,
> > Why? What would that gain? I go back to my analogy of the British Queen.
> > What would be gained by "clarifying" that if she actually intervenes
> > non-trivially in the government of any
On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote:
>
> On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
> >>
> >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
> >>
> >> #define GNU_PROPERTY_UINT32_AND_LO 0xb000
> >> #define
在 17/04/2021 16.27, Aaron Gyes 写道:
As far as I understand it Chris Punches lives in North America.
Only 2% of the world population lives in the US, indeed, most live in China.
It’s interesting the unkind reaction Liu Hao received in this very thread
when they encountered the arguments making
Hi,
Following up on the fix for PR99914, when testing on MinGW, it was found
not to support weak in the same way as on ELF or Mach-O targets.
So the linkage has been reverted back to COMDAT for that target, however
in order to properly support overriding functions and variables, all
declarations
Hi,
Following on from adding TARGET_D_REGISTER_OS_TARGET_INFO, this adds the
required handlers to implement `__traits(getTargetInfo, "objectFormat")'
for all platforms that have D support files.
Some back-ends (i386, rs6000, and pa) have some awarenes of the what
object format they are compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
--- Comment #5 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:bda519596543e49f77914b5677693e86be5d01d0
commit r11-8234-gbda519596543e49f77914b5677693e86be5d01d0
Author: Iain Buclaw
Date: Tue
Hi Gerald,,
On April 17, 2021 9:09:19 AM UTC, Gerald Pfeifer wrote:
> On Fri, 16 Apr 2021, Frosku wrote:
> > In my view, if people employed by a small number of American
> companies
> > succeed in disassociating GCC from GNU/FSF, which is representative
> > of the free software grassroots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100130
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-04-17
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100130
Bug ID: 100130
Summary: R section flag handling doesn't cope with intervening
decls
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #10 from DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534
Paul Thomas changed:
What|Removed |Added
Assignee|pault at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #3
On Sat Apr 17, 2021 at 10:08 AM BST, Giacomo Tesio wrote:
> But in fact, millions of people outside the US would feel excluded.
> And threatened. But we are all "jerks", right?
>
> ...
>
> Such culture is also dominated by RICH men, but it's unable to see the
> problem in term of global and local
Hi!
As mentioned in the PR, SIGSTKSZ is no longer a compile time constant in
glibc 2.34 and later, so
static const uptr kAltStackSize = SIGSTKSZ * 4;
needs dynamic initialization, but is used by a function called indirectly
from .preinit_array and therefore before the variable is constructed.
On Sat Apr 17, 2021 at 10:29 AM BST, Giacomo Tesio wrote:
> Beware with what you desire, Frosku.
>
> On April 16, 2021 11:15:57 PM UTC, Frosku wrote:
> >
> > I can't speak for others, but for me at least, replacing ties with GNU
> > with ties to another well-respected (non-corporate) entity in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d9f462fb372fb02da032cefd6b091d7582c425ae
commit r11-8230-gd9f462fb372fb02da032cefd6b091d7582c425ae
Author: Jakub Jelinek
Date:
On Sat Apr 17, 2021 at 10:08 AM BST, Aaron Gyes via Gcc wrote:
> > I feel imposed upon when, as a volunteer, I'm expected to submit not just
> > my volunteered time but all of my time in every venue to your cultural
> > norms.
>
> Can you not imagine… some people have already felt that way for
Beware with what you desire, Frosku.
On April 16, 2021 11:15:57 PM UTC, Frosku wrote:
>
> I can't speak for others, but for me at least, replacing ties with GNU
> with ties to another well-respected (non-corporate) entity in the free
> software world like Debian or the Apache foundation would
On Sat Apr 17, 2021 at 10:04 AM BST, Aaron Gyes via Gcc wrote:
> On Apr 17, 2021, at 1:36 AM, Frosku wrote:
> > I feel imposed upon when, as a volunteer, I'm expected to submit not just
> > my volunteered time but all of my time in every venue to your cultural
> > norms. This is not normal. Just
Le 16/04/2021 à 19:06, Richard Kenner a écrit :
>> The authority of the FSF, GNU and RMS over GCC is and has been a
>> fiction for decades,
> For the most part, I agree.
>
>> It would be usefull to clarify with the FSF and GNU what the
>> actual relations are,
> Why? What would that gain? I go
On Apr 12, 2021, Segher Boessenkool wrote:
> Hi!
> Sorry for the late answer.
> On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
>> Several compile tests that use the __ieee128 type do not ensure it is
>> defined. This patch adds -mfloat128 to their command lines, and
>>
On Fri, 16 Apr 2021, Frosku wrote:
> In my view, if people employed by a small number of American companies
> succeed in disassociating GCC from GNU/FSF, which is representative of
> the free software grassroots community
I find this insistant focus by some on "American companies"
interesting -
> I feel imposed upon when, as a volunteer, I'm expected to submit not just
> my volunteered time but all of my time in every venue to your cultural
> norms.
Can you not imagine… some people have already felt that way for quite some
time, and became excluded? That it is not a hypothetical for
Hi Andrew and GCC,
On April 17, 2021 5:04:55 AM UTC, Andrew Pinski via Gcc
wrote:
> On Fri, Apr 16, 2021 at 9:56 PM Frosku wrote:
> >
> > On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote:
> > > On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote:
> > > >
> > > > When I refer to a
On Apr 17, 2021, at 1:36 AM, Frosku wrote:
> I feel imposed upon when, as a volunteer, I'm expected to submit not just
> my volunteered time but all of my time in every venue to your cultural
> norms. This is not normal. Just because some of you are paid very nice
> salaries to hack on free
On Sat Apr 17, 2021 at 9:27 AM BST, Aaron Gyes via Gcc wrote:
> Give me a break Forsku.
>
> Could you care to share how you feel imposed upon or feel
> disenfranchised by
> this discussion not being sensitive to your culture? How does a code of
> conduct,
> or how would discouraging
> I wasn't even implying that these cultures are 'good' or 'bad', just
> that they exist and differ from the various regional cultures which
> exist all over the world. I think people were quite touchy at my line
> of questioning. I recognise that there are differences between i.e.
> LA and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
Tom de Vries changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment
On Sat Apr 17, 2021 at 7:21 AM BST, Chris Punches wrote:
> I've lived in most states in the US and can confirm exclusionary
> regional cultures not only exist but are more common than the absence
> of them.
>
> You might not see it in Sioux City, but you'll see it in LA, you'll see
> it in Dallas,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100129
Bug ID: 100129
Summary: [modules] ICE free(): invalid pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99722
--- Comment #1 from Alexander Lelyakin ---
All so far found examples of such error message
change its behavior if you add the parameter:
--param=hash-table-verification-limit=1000
Most of them to the error message: ICE in hashtab_chk_error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from
74 matches
Mail list logo
