[Bug middle-end/99797] accessing uninitialized automatic variables

2021-04-18 Thread muecker at gwdg dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #9 from Martin Uecker --- The behavior of GCC is dangerous as the example in comment #1 show. You can not reason at all about the generated code. It is not just that the uninitialized value causes some random choice but it creates

[Bug c/100140] New: Reference gcc development github mirror - Latest Development Build

2021-04-18 Thread j130496 at live dot co.uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100140 Bug ID: 100140 Summary: Reference gcc development github mirror - Latest Development Build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

Re: removing toxic emailers

2021-04-18 Thread Christopher Dimech via Gcc
> Sent: Monday, April 19, 2021 at 1:10 PM > From: "Frosku" > To: "Alexandre Oliva" , "Jonathan Wakely via Gcc" > > Subject: Re: removing toxic emailers > > On Sun Apr 18, 2021 at 9:22 PM BST, Alexandre Oliva via Gcc wrote: > > That's why it's best to dissent politely, lest they incorrectly

[Bug c++/100138] ICE with constructor constrained (C++20 Concepts) by parameter pack length

2021-04-18 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138 Patrick Palka changed: What|Removed |Added Last reconfirmed||2021-04-19 Ever confirmed|0

[Bug c++/99859] constexpr evaluation with member function is incorrect

2021-04-18 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 Patrick Palka changed: What|Removed |Added CC||pkeir at outlook dot com --- Comment

[Bug c++/96414] Second char relation test incorrect with constexpr dynamic allocation

2021-04-18 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96414 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

Re: removing toxic emailers

2021-04-18 Thread Frosku
On Sun Apr 18, 2021 at 9:22 PM BST, Alexandre Oliva via Gcc wrote: > That's why it's best to dissent politely, lest they incorrectly conclude > their opinions are consensual, or majoritary, just because they've > driven dissenters into silence. The problem is, Alex, that the trolls mostly haven't

[Bug libstdc++/100139] std::views::{take, drop} don't type erase

2021-04-18 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Andrew Sutton via Gcc
> > > Of computer science graduates I have encountered over the last decade, I > > know few who started their journey with gcc and they were all in the > > initial part of the decade. In recent years I don't think I encountered > > any student who works on gcc; many even start with the assumption

Re: removing toxic emailers

2021-04-18 Thread Frosku
On Sun Apr 18, 2021 at 8:13 PM BST, Jonathan Wakely via Gcc wrote: > Utter nonsense, Alex. I think it's clear I don't agree with most of > your posts on this list in the past month, but it would be silly to > suggest that you should not be allowed to post here, given your track > record. Dave

[PATCH] PR tree-optimization/100081 - Limit depth of logical expression windback.

2021-04-18 Thread Andrew MacLeod via Gcc-patches
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 

[PATCH] or1k: Add mcmodel option to handle large GOTs

2021-04-18 Thread Stafford Horne via Gcc-patches
When building libgeos we get an error with: linux-uclibc/9.3.0/crtbeginS.o: in function `__do_global_dtors_aux': crtstuff.c:(.text+0x118): relocation truncated to fit: R_OR1K_GOT16 against symbol `__cxa_finalize' defined in .text section in

[Bug libstdc++/100139] New: std::views::{take, drop} don't type erase

2021-04-18 Thread gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139 Bug ID: 100139 Summary: std::views::{take, drop} don't type erase Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/100138] New: ICE with constructor constrained (C++20 Concepts) by parameter pack length

2021-04-18 Thread pkeir at outlook dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138 Bug ID: 100138 Summary: ICE with constructor constrained (C++20 Concepts) by parameter pack length Product: gcc Version: 11.0 Status: UNCONFIRMED Severity:

Re: [PATCH 1/3] openacc: Add support for gang local storage allocation in shared memory

2021-04-18 Thread Andrew Stubbs
On 16/04/2021 18:30, Thomas Schwinge wrote: Hi! On 2021-04-16T17:05:24+0100, Andrew Stubbs wrote: On 15/04/2021 18:26, Thomas Schwinge wrote: and optimisation, since shared memory might be faster than the main memory on a GPU. Do we potentially have a problem that making more use of

[PATCH] wwwdocs: Do not rewrite the page titles

2021-04-18 Thread Jonathan Wakely via Gcc-patches
Remove GNU and FSF attribution from HTML page titles. I don't see why we should have to "comply with the GNU style" if we're truly an independent project run by the GCC developers and aided by the steering committee. OK for wwwdocs? commit d157082f49725510560cb83f2f1c045e2968ad3b Author:

gcc-11-20210418 is now available

2021-04-18 Thread GCC Administrator via Gcc
Snapshot gcc-11-20210418 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20210418/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: [PATCH,FORTRAN 00/29] Move towards stringpool, part 1

2021-04-18 Thread Bernhard Reutner-Fischer via Gcc-patches
On Fri, 7 Sep 2018 10:30:30 +0200 Bernhard Reutner-Fischer wrote: > On Thu, 6 Sep 2018 at 03:25, Jerry DeLisle wrote: > > > > On 09/05/2018 07:57 AM, Bernhard Reutner-Fischer wrote: > > > Hi, > > > > > > The fortran frontend still uses stack-based handling of (symbol) names > > > with

[Bug c++/100137] -Werror=array-bounds false positive:"subscript -1 is outside array bounds"

2021-04-18 Thread spamandnoise at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137 --- Comment #1 from Moritz Beutel --- The problem was discovered in gsl-lite by a user of the library: https://github.com/gsl-lite/gsl-lite/issues/303 This bug (if confirmed) should probably be added to the -Warray-bounds meta-bug:

[Bug c++/100137] New: -Werror=array-bounds false positive:"subscript -1 is outside array bounds"

2021-04-18 Thread spamandnoise at gmail dot com via Gcc-bugs
} return len; } int main() { char hello[] = "hello"; span s{ hello, string_length( hello ) }; s.back() = '2'; } - `g++ -v` output: - Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++ Target: x86_64-linux-gnu Configured with: .

Re: removing toxic emailers

2021-04-18 Thread Alexandre Oliva via Gcc
On Apr 18, 2021, Jonathan Wakely via Gcc wrote: > "Just ignore them" allows the trolls to dominate the discussion *nod* That's why it's best to dissent politely, lest they incorrectly conclude their opinions are consensual, or majoritary, just because they've driven dissenters into silence.

[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441

2021-04-18 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 --- Comment #2 from anlauf at gcc dot gnu.org --- Replacing class(t) :: x by class(t), allocatable :: x avoids the ICE. Could be an error recovery issue.

Re: removing toxic emailers

2021-04-18 Thread Alexandre Oliva via Gcc
On Apr 18, 2021, Jonathan Wakely wrote: > Dave didn't say who he thinks should or shouldn't be moderated, Shall we ask him to confirm what I read between the lines? Shall we ask Nathan? Shall we ask you? > it would be silly to suggest that you should not be allowed to post > here, given

[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'

2021-04-18 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'

2021-04-18 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:aff57bcebe534b1d92f78bdfb89a4001a6d12af2 commit r10-9712-gaff57bcebe534b1d92f78bdfb89a4001a6d12af2 Author: Harald Anlauf

Re: removing toxic emailers

2021-04-18 Thread Jonathan Wakely via Gcc
On Sun, 18 Apr 2021 at 19:54, Alexandre Oliva via Gcc wrote: > That you claim some are entitled to share their opinions, because > they've contributed code (and you agree with them), and that others are > not because they haven't (and you disagree with them), but you do not > disqualify those who

Re: removing toxic emailers

2021-04-18 Thread Jonathan Wakely via Gcc
On Sun, 18 Apr 2021 at 16:32, David Malcolm wrote: > > "Don't feed the trolls" might have worked once, but sometimes they > start talking to each other, and it becomes difficult for a bystander > to tell that everyone else is ignoring them, and it keeps threads like > this one alive. > > I reject

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

2021-04-18 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Jonathan

Re: removing toxic emailers

2021-04-18 Thread Alexandre Oliva via Gcc
David, On Apr 18, 2021, David Malcolm via Gcc wrote: > I reject the idea that those of us who work on GCC have to put up with > arbitrary emails from random crazies on the internet without even the > simple recourse of being able to put individuals on moderation. All sides in this

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
> Sent: Monday, April 19, 2021 at 4:58 AM > From: "Thomas Rodgers" > To: "Christopher Dimech" > Cc: "Siddhesh Poyarekar" , "GCC Development" > , "Ville Voutilainen" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 2021-04-18 00:38, Christopher Dimech via Gcc

[Bug middle-end/99797] accessing uninitialized automatic variables

2021-04-18 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #8 from Andrew

[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747

2021-04-18 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #13) > The following variant gives an ICE > >type t >end type > contains >function f() result(t) > character(3) :: c > c =

[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3

2021-04-18 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 康桓瑋 changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

2021-04-18 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 康桓瑋 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

2021-04-18 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 --- Comment #2 from 康桓瑋 --- After actually executing the same code on my local and remote servers, I did not produce such a result. In both cases, std::copy achieved the expected high-efficiency performance, so I think this should only be Quick

Re: [PATCH] libstdc++: Update some baseline_symbols.txt

2021-04-18 Thread H.J. Lu via Gcc-patches
On Fri, Apr 16, 2021 at 9:25 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > As we have only one P1 left right now, I think it is the right time > to update abi list files in libstdc++. > > Attached are two patches, one is update for x86_64/i?86/s390x/ppc64 > linux (aarch64 seems to be

Re: [PATCH] combine: Don't create REG_UNUSED notes if the reg already died (PR99927)

2021-04-18 Thread Segher Boessenkool
Hi! On Sun, Apr 18, 2021 at 05:24:50PM +0200, Jakub Jelinek wrote: > On Sun, Apr 18, 2021 at 03:03:07PM +, Segher Boessenkool wrote: > > If the register named in an existing REG_UNUSED note dies somewhere > > between where the note used to be and I3, we should just drop it. > > > >

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Thomas Rodgers
On 2021-04-18 00:38, Christopher Dimech via Gcc wrote: Listen very carefully - In the first quarter of 2011, Keith Chuvala began discussing the need to drop all proprietary systems used to command the ISS. He specifically mentioned products from Microsoft and Red Hat. This was communicated

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Thomas Rodgers
On 2021-04-17 20:10, Christopher Dimech via Gcc wrote: 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

Re: removing toxic emailers

2021-04-18 Thread Christopher Dimech via Gcc
- Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent:

Re: [PATCH] combine: Don't create REG_UNUSED notes if the reg already died (PR99927)

2021-04-18 Thread Jakub Jelinek via Gcc-patches
On Sun, Apr 18, 2021 at 03:03:07PM +, Segher Boessenkool wrote: > If the register named in an existing REG_UNUSED note dies somewhere > between where the note used to be and I3, we should just drop it. > > 2021-04-21 Segher Boessenkool > > PR rtl-optimization/99927 > *

[Patch, fortran] PR fortran/100136 - ICE, regression, using flag -fcheck=pointer

2021-04-18 Thread José Rui Faustino de Sousa via Gcc-patches
Hi All! Proposed patch to: PR100136 - ICE, regression, using flag -fcheck=pointer Patch tested only on x86_64-pc-linux-gnu. Add handling for pointer expressions. Thank you very much. Best regards, José Rui Fortran: Fix ICE with -fcheck=pointer [PR100136] gcc/fortran/ChangeLog: PR

[Bug rtl-optimization/99927] Wrong code since r11-39-gf9e1ea10e657af9f

2021-04-18 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #18 from

[Bug fortran/100136] New: ICE, regression, using flag -fcheck=pointer

2021-04-18 Thread jrfsousa at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 Bug ID: 100136 Summary: ICE, regression, using flag -fcheck=pointer Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[PATCH] combine: Don't create REG_UNUSED notes if the reg already died (PR99927)

2021-04-18 Thread Segher Boessenkool
If the register named in an existing REG_UNUSED note dies somewhere between where the note used to be and I3, we should just drop it. 2021-04-21 Segher Boessenkool PR rtl-optimization/99927 * combine.c (distribute_notes) [REG_UNUSED]: If the register already is dead,

[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f

2021-04-18 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 --- Comment #17 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:b412ce8e961052e6becea3bc783a53e1d5feaa0f commit r11-8237-gb412ce8e961052e6becea3bc783a53e1d5feaa0f Author: Segher Boessenkool

Re: removing toxic emailers

2021-04-18 Thread David Malcolm via Gcc
On Sun, 2021-04-18 at 09:10 -0400, Eric S. Raymond wrote: Sorry for prolonging this thread-of-doom; I'm loathe to reply to Eric because I worry that it will encourage him. I wrote a long rebuttal to his last email to me about his great insights into the minds of women but didn't send it in the

[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)

2021-04-18 Thread jg at jguk dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175 --- Comment #20 from Jonny Grant --- (In reply to Jonathan Wakely from comment #19) > Why is that needed? It says the location is something like: > > In member function ‘info& info::operator=(const info&)’, > > or: > > In copy constructor

Re: [Bug libstdc++/99402] [10 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator

2021-04-18 Thread Jonathan Wakely via Gcc-patches
On Sun, 18 Apr 2021, 15:01 François Dumont via Libstdc++, < libstd...@gcc.gnu.org> wrote: > Hi > > Ok to backport this to gcc-10 branch ? > Yes please, thanks. > Tested under Linux x86_64. > > François > > > On 13/04/21 10:51 pm, redi at gcc dot gnu.org wrote: > >

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
Some had contacted me about it. Could have sent response off the list. > Sent: Monday, April 19, 2021 at 1:05 AM > From: "Richard Kenner" > To: dim...@gmx.com > Cc: gcc@gcc.gnu.org, siddh...@gotplt.org, ville.voutilai...@gmail.com > Subject: Re: A suggestion for going forward from the RMS/FSF

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
But that was around 2017. Perhaps people want to cut costs again - that's not a new thing. After all, they changed their mind in 2011 only because they got in excess of 5000 attacks that year. At any time in the past, I would have decided that science was good for the Sapiens. But now, with

Re: [Bug libstdc++/99402] [10 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator

2021-04-18 Thread François Dumont via Gcc-patches
Hi     Ok to backport this to gcc-10 branch ?     Tested under Linux x86_64. François On 13/04/21 10:51 pm, redi at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 Jonathan Wakely changed: What|Removed |Added

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

2021-04-18 Thread pault at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 --- Comment #5 from Paul Thomas --- This needs to be incorporated into the fix for PR100027. I hope that Jose takes this PR over :-) Paul

Re: [PATCH] docs: Remove empty table column.

2021-04-18 Thread Paul Richard Thomas via Gcc-patches
Hi Martin, It looks good to me - please push before release. Thanks Paul On Mon, 12 Apr 2021 at 16:59, Martin Liška wrote: > A column with empty values seems suspicious. > > Ready to be installed? > Thanks, > Martin > > gcc/fortran/ChangeLog: > > * intrinsic.texi: The table has

Re: identifying toxic emailers (was: removing toxic emailers)

2021-04-18 Thread Giacomo Tesio
Hi Kenner On April 18, 2021 12:42:25 PM UTC, ken...@vlsi1.ultra.nyu.edu wrote: > > So I think it's quite reasonable to expect that their employers > could > > read the SC's secret exchanges (since they technically CAN read them). > > I'm a bit lost here. What do you think is the content of "the

Re: removing toxic emailers

2021-04-18 Thread Eric S. Raymond
Ian Lance Taylor via Gcc : > 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

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Richard Kenner via Gcc
> It is an argument against the idea that LLVM is the default way that > people choose. I don't think that anybody made the argument that LLVM is the "default" in any sense. What's being given here are reasons why some people prefer LLVM over GCC. > In those places, they don't trust Microsoft

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
> Sent: Sunday, April 18, 2021 at 10:49 PM > From: "Richard Kenner" > To: dim...@gmx.com > Cc: gcc@gcc.gnu.org, siddh...@gotplt.org, ville.voutilai...@gmail.com > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > Depends on the use cases. Not in military surveillance.

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325

2021-04-18 Thread bernd.edlinger at hotmail dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446 --- Comment #13 from Bernd Edlinger --- Hi Nathan, I've been playing with a variant of c-c++-common/raw-string-6.c with your patch: $ cat raw-string-6.c $ cat raw-string-6.c // { dg-do compile } // { dg-options "-std=gnu99" { target c } } //

Re: identifying toxic emailers (was: removing toxic emailers)

2021-04-18 Thread Richard Kenner via Gcc
> So I think it's quite reasonable to expect that their employers could > read the SC's secret exchanges (since they technically CAN read them). I'm a bit lost here. What do you think is the content of "the SC's secret exchanges"?

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

2021-04-18 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98088 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Hafiz Abid Qadeer : https://gcc.gnu.org/g:e4dcb3383bff4c209a918127551cabc56b4171ae commit r10-9711-ge4dcb3383bff4c209a918127551cabc56b4171ae Author: Hafiz Abid

[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747

2021-04-18 Thread dominiq at lps dot ens.fr via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #13 from Dominique d'Humieres --- The following variant gives an ICE type t end type contains function f() result(t) character(3) :: c c = 'abc' end end The back trace is * thread #1, queue =

[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441

2021-04-18 Thread dominiq at lps dot ens.fr via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-18

identifying toxic emailers (was: removing toxic emailers)

2021-04-18 Thread Giacomo Tesio
Hi David, Ian, Nathan and GCC all. Let's start from what we agree upon: On April 17, 2021 6:11:57 PM UTC, David Brown wrote: > The way you go on about "controversial American companies" and "undue > influence" suggests you think these companies are forcing their > employees on the gcc

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Ville Voutilainen via Gcc
On Sun, 18 Apr 2021 at 13:49, Richard Kenner wrote: > > > Depends on the use cases. Not in military surveillance. And certainly not > > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > > I'm not sure. Before 2011, rather than building things from scratch, > >

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Richard Kenner via Gcc
> Depends on the use cases. Not in military surveillance. And certainly not > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > I'm not sure. Before 2011, rather than building things from scratch, > washington bureaucrats simply picked from among existing

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Richard Kenner via Gcc
> You will not get funding grants in the US if you mention free software, > because the US Department of Commerce does not allow it. This is not correct and I suspect is a misunderstanding of what "government data rights" means.

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
> Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Siddhesh Poyarekar" > To: "Christopher Dimech" > Cc: "NightStrike" , "Ville Voutilainen" > , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/18/21 1:08 PM, Christopher Dimech wrote: > >> The

[Bug c++/100135] New: ICE when using constants in a mdoule

2021-04-18 Thread patrick.kox at commandoregel dot be via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100135 Bug ID: 100135 Summary: ICE when using constants in a mdoule Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
> Sent: Sunday, April 18, 2021 at 9:06 PM > From: "Jonathan Wakely via Gcc" > To: "Aaron Gyes" > Cc: "gcc@gcc.gnu.org" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Sun, 18 Apr 2021, 10:01 Christopher Dimech via Gcc, > wrote: > > > You don't have to believe me

[Bug c++/100134] New: ICE when using a vector in a mdoule

2021-04-18 Thread patrick.kox at commandoregel dot be via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100134 Bug ID: 100134 Summary: ICE when using a vector in a mdoule Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug fortran/100132] Optimization breaks pointer association

2021-04-18 Thread dominiq at lps dot ens.fr via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-18 Ever confirmed|0

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Jonathan Wakely via Gcc
On Sun, 18 Apr 2021, 10:01 Christopher Dimech via Gcc, wrote: > You don't have to believe me of course. Go ask any lawyer worth her > salt and she'll tell you the same thing! > And if they don't tell you the same thing, they're obviously not a true Scotsman.

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
You don't have to believe me of course. Go ask any lawyer worth her salt and she'll tell you the same thing! > Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Aaron Gyes" > To: "Christopher Dimech" > Cc: gcc@gcc.gnu.org > Subject: Re: A suggestion for going forward from the RMS/FSF debate >

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
> Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Siddhesh Poyarekar" > To: "Christopher Dimech" > Cc: "NightStrike" , "Ville Voutilainen" > , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/18/21 1:08 PM, Christopher Dimech wrote: > >> The

[Bug libstdc++/100133] std::copy extremely slow for random access iterator

2021-04-18 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 --- Comment #1 from 康桓瑋 --- And the libstdc++‘s std::copy is also 8.9 times slower than the equivalent std::tranfrom: #include #include #include const std::vector v(100, 42); static void copy_from_vector(benchmark::State& state) { for

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
Please refer to the *Exemptions* section listed in the link below https://www.commerce.gov/about/policies/source-code - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping -

[Bug libstdc++/100133] New: std::copy extremely slow for random access iterator

2021-04-18 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 Bug ID: 100133 Summary: std::copy extremely slow for random access iterator Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Siddhesh Poyarekar
On 4/18/21 1:08 PM, Christopher Dimech wrote: The cause IMO is accessibility to other projects, most notably compiler researchers and students who find it a lot easier to target llvm than gcc because compiler-as-a-library. License may have been a factor for some of those uses (e.g. I know some

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Aaron Gyes via Gcc
If the purpose was to facilitate lawsuits, and these lawsuits haven’t occurred after all these years, it seems like it didn’t work. Maybe you are wrong about the intent? Aaron > On Apr 18, 2021, at 12:50 AM, Christopher Dimech wrote: > > > I know that Apple can make some strong ownership

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Aaron Gyes via Gcc
> Correct. The Apache License included certain patent termination and > counterclaim provisions, made void and null by the LLVM Exceptions. > Originally, the LLVM License > was based on the two free software licenses - the X11 license and the > 3-clause BSD license. By 2005, Apple managed

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Siddhesh Poyarekar
On 4/18/21 1:15 PM, Gabriel Ravier via Gcc wrote: I'd like to see a source for that. It certainly seems like complete bullshit to me, unless you're trying to tell me that they simultaneously do not fund anything related to free software while also having policy that mandates at least 20

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Gabriel Ravier via Gcc
On 4/18/21 8:44 AM, Christopher Dimech via Gcc wrote: Sent: Sunday, April 18, 2021 at 6:09 PM From: "Siddhesh Poyarekar" To: "NightStrike" , "Ville Voutilainen" Cc: "GCC Development" Subject: Re: A suggestion for going forward from the RMS/FSF debate On 4/17/21 12:11 AM, NightStrike via Gcc

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
- Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent:

Re: [PATCH] docs: Remove empty table column.

2021-04-18 Thread Gerald Pfeifer
On Mon, 12 Apr 2021, Martin Liška wrote: > A column with empty values seems suspicious. > > Ready to be installed? Yes, if you've been able to validate this visually (before/after). Please give the Fortran folks the rest of the weekend/another 24h to chim in. > gcc/fortran/ChangeLog: > >

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Christopher Dimech via Gcc
> Sent: Sunday, April 18, 2021 at 6:09 PM > From: "Siddhesh Poyarekar" > To: "NightStrike" , "Ville Voutilainen" > > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/17/21 12:11 AM, NightStrike via Gcc wrote: > > I was under the (likely

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Siddhesh Poyarekar
On 4/17/21 12:11 AM, NightStrike via Gcc wrote: 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. Intel, IBM,