[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

extra -O3 test.c && ./a.out >val1: 0 >repr: 1 >val2: 1 >-- >gcc x86-64 version: gcc (GCC) 10.0.0 20191229 (experimental) >-- > >C1

[Bug target/93082] macOS Authorization.h needs fixinclude

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #2 from mcccs at gmx dot com --- Reported on the "other side" https://bugs.llvm.org/show_bug.cgi?id=44406 Changing it to enum works too, my only doubt is that it has a different width and sign (but better than not compiling) Updated

[patch, libfortran] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors

Hi all, The attached patch includes adjustments to the test case. The Fortran Standard states the exponent width when using the e0 exponent specfier results in the smallest possible exponent width. This patch implements that case. I got frustrated with trying to re-understand this code

[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084 --- Comment #6 from fxue at gcc dot gnu.org --- Could you share how you build clang with PGO, and train workload?

[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084 fxue at gcc dot gnu.org changed: What|Removed |Added CC||fxue at gcc dot gnu.org ---

Re: *ping**2 Re: [Patch, Fortran] OpenMP/OpenACC – fix more issues with OPTIONAL

Between Holidays and being short on people that understand this, I would say commit it unless Jakub objects. (When in doubt, make a decision and move forward principle, assuming one is not stupid,) Cheers, Jerry On 12/29/19 2:27 PM, Tobias Burnus wrote: On 12/16/19 9:06 AM, Tobias Burnus

Re: *ping*[patch, fortran] Fix PR 91541, ICE on valid for INDEX

On 12/29/19 2:16 AM, Thomas Koenig wrote: Am 19.12.19 um 08:23 schrieb Thomas Koenig: Regression-tested. OK for trunk? Ping? This looks good Thomas, Thanks for patch, Jerry

Re: [patch, fortran] Updated fix PR 92961, ICE on division by zero error in array bounds

This one looks OK Thomas Cheers, Jerry On 12/22/19 7:28 AM, Thomas Koenig wrote: Hello world, here is an update for the fix for PR 92961, which also takes care of the second test case in the PR (included in the first one). The patch itself should be clear enough - make sure that there is a

[Bug c++/93095] Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93095 --- Comment #3 from Andrew Pinski --- (In reply to fdlbxtqi from comment #2) > (In reply to Jakub Jelinek from comment #1) > > Can't reproduce and don't see anything problematic on that code. > > Unless e.g. the system headers are defining

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #27 from fdlbxtqi --- (In reply to Bernd Edlinger from comment #26) > (In reply to fdlbxtqi from comment #2) > > Also find a bug of __memmove > > > > /* > >* A constexpr wrapper for __builtin_memmove. > >* @param __num The

[Bug c++/93095] Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93095 --- Comment #2 from fdlbxtqi --- (In reply to Jakub Jelinek from comment #1) > Can't reproduce and don't see anything problematic on that code. > Unless e.g. the system headers are defining throws as a macro, can you e.g. > attach preprocessed

[Bug c++/67834] Local references inside comdat groups

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67834 --- Comment #10 from John David Anglin --- Created attachment 47564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47564=edit Patch Untested fix.

Re: Proposal for the transition timetable for the move to GIT

Le 30/12/2019 à 01:18, Joseph Myers a écrit : Do "git log egcs_1_1_2_prerelease_2" in gcc-reparent, for example. The history ends up containing two different versions of SVN r5 and of many other commits. When trying to migrate Blender from svn to git, we actually tried git-svn first, and it

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 18:30, Ian Lance Taylor via gcc a écrit : On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD wrote: Which brings me to something I find strange in your policy: to me, merges from trunk to branches should be rare if not nonexistent. And you are deciding to banish

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote: > gcc-reparent is better, but many (most?) of the release tags are shown > as merge commits with a fake parent back to the gcc-3 branch point, > which is certainly not what happened when the tagging was done at that > time. And looking at the

Re: Proposal for the transition timetable for the move to GIT

On Sun, 2019-12-29 at 22:30 +0100, Thomas Koenig wrote: > Am 29.12.19 um 14:26 schrieb Segher Boessenkool: > > We cannot waste a year on a social experiment. We can slowly and carefully > > adopt new procedures, certainly. But anything drastic isn't advisable imo. > > > > Also, many GCC

[Bug libgomp/93097] Wrong OpenMP version reported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93097 --- Comment #1 from Jakub Jelinek --- That would be incorrect, as OpenMP 5 is only partially supported, there are various OpenMP 5 features missing, some of them on the compiler side only, but others (e.g. the allocators) on the library side

Re: [C++ PATCH] PR c++/92745 - bogus error when initializing array of vectors.

On Fri, Dec 20, 2019 at 06:22:10PM -0500, Marek Polacek wrote: > > > 2019-12-20 Marek Polacek > > > > > > PR c++/92745 - bogus error when initializing array of vectors. > > > * decl.c (reshape_init_r): For a nested compound literal, do > > > call reshape_init_{class,array,vector}. > > >

[Bug c++/92745] [8/9 Regression] Initializing array with vec4 results in compile error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92745 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Sun Dec 29 23:47:55 2019 New Revision: 279758 URL: https://gcc.gnu.org/viewcvs?rev=279758=gcc=rev Log: PR c++/92745 * g++.dg/cpp0x/initlist118.C: Add -Wno-psabi -w to

[PATCH] Fix vextract* masked patterns (PR target/93069)

Hi! The AVX512F documentation clearly states that in instructions where the destination is a memory only merging-masking is possible, not zero-masking, and the assembler enforces that. The testcase in this patch fails to assemble because of Error: unsupported masking for `vextracti32x8' on

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote: > fixups in bugdb.py - and that way benefit both from reposurgeon making > choices that are as conservatively safe as possible, which seems a > desirable property for problem cases that haven't been manually reviewed, Problem cases

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Eric S. Raymond wrote: > Joseph Myers : > > The case you mention is one where there was a merge to a branch not from > > its immediate parent but from an indirect parent. I don't think it would > > be hard to support detecting such merges in reposurgeon. > > We're working

Re: Git conversion: fixing email addresses from ChangeLog files

Richard Earnshaw (lists) : > Weak in the sense that it isn't proof given that the user name is > partially redacted. There's nothing in the gcc archives that gives a > full name either, unfortunately. > > Yes, it's the most likely match, but there's still an element of doubt. > > R.

Re: Git conversion: fixing email addresses from ChangeLog files

On Sun, 29 Dec 2019, Joseph Myers wrote: > I've now made those changes to the checked-in list so it's pure UTF-8, and > thus easier to review and edit. We still need to implement code in > bugdb.py to use that list to pick the preferred form from each list of > variants (and people may wish

Re: Proposal for the transition timetable for the move to GIT

Joseph Myers : > The case you mention is one where there was a merge to a branch not from > its immediate parent but from an indirect parent. I don't think it would > be hard to support detecting such merges in reposurgeon. We're working on it. > This is an example where the originally added

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Mark Wielaard wrote: > Maybe we should have a separate historical git repo which contains > everything that we were able to salvage and that people could git > remote add if they are really, really interested. I'm not convinced that's very different from having one repo with

gcc-10-20191229 is now available

Snapshot gcc-10-20191229 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20191229/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

Re: The far past of GCC

On Sat, 28 Dec 2019, Jeff Law wrote: > I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. But I'm not aware of anyone still > having a copy of the old RCS ,v files. See ftp://gcc.gnu.org/pub/gcc/old-releases/old-cvs/ for the old repository

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 22:24, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> Also, for this one: >> >> # "47044": "", >> >> There's some (relatively weak) evidence that this is Bjørn Wennberg (eg >> https://groups.google.com/forum/#!msg/comp.databases.sybase/Uz8ICef9Qr8/uPwanH6is60J), >> but in

*ping**2 Re: [Patch, Fortran] OpenMP/OpenACC – fix more issues with OPTIONAL

On 12/16/19 9:06 AM, Tobias Burnus wrote: Ping. On 12/10/19 6:54 PM, Tobias Burnus wrote: Nonallocatable, nonpointer array arguments (of assumed shape) are special as they get a get an array descriptor ('arg') as argument but create a local variable which accesses the actual data ('arg.0 =

Re: Git conversion: fixing email addresses from ChangeLog files

Richard Earnshaw (lists) : > Also, for this one: > > # "47044": "", > > There's some (relatively weak) evidence that this is Bjørn Wennberg (eg > https://groups.google.com/forum/#!msg/comp.databases.sybase/Uz8ICef9Qr8/uPwanH6is60J), > but in the absence of stronger evidence, I'm going to just

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 18:30, Maxim Kuvyrkov wrote: > Below are several more issues I found in reposurgeon-6a conversion comparing > it against gcc-reparent conversion. > > I am sure, these and whatever other problems I may find in the reposurgeon > conversion can be fixed in time. However, I don't see

Re: Proposal for the transition timetable for the move to GIT

Am 29.12.19 um 14:26 schrieb Segher Boessenkool: We cannot waste a year on a social experiment. We can slowly and carefully adopt new procedures, certainly. But anything drastic isn't advisable imo. Also, many GCC developers aren't familiar with Git at all. It takes time to learn it, and to

[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #5 from Jan Hubicka --- Created attachment 47563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47563=edit fixed testcase I have verified that building with g++ -O3 -march=bdver1 -fno-prefetch-loop-arrays

Re: [PATCH] PR tree-optimization/90836 Missing popcount pattern matching

On Mon, Oct 7, 2019 at 3:05 AM Richard Biener wrote: > > On Tue, Oct 1, 2019 at 1:48 PM Dmitrij Pochepko > wrote: > > > > Hi Richard, > > > > I updated patch according to all your comments. > > Also bootstrapped and tested again on x86_64-pc-linux-gnu and > > aarch64-linux-gnu, which took some

[Bug tree-optimization/93098] [10 Regression] ICE with negative shifter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93098 --- Comment #1 from Andrew Pinski --- This was introduced with r276721 .

[Bug tree-optimization/93098] New: [10 Regression] ICE with negative shifter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93098 Bug ID: 93098 Summary: [10 Regression] ICE with negative shifter Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal

[Bug tree-optimization/93098] [10 Regression] ICE with negative shifter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93098 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Maxim Kuvyrkov wrote: > With the "Missed merges" problem (see below) I don't see how reposurgeon > conversion can be considered "ready". It aims to be conservatively safe regarding merges, erring on the side of not adding incorrect merges if in doubt. Because of the

Re: Proposal for the transition timetable for the move to GIT

Below are several more issues I found in reposurgeon-6a conversion comparing it against gcc-reparent conversion. I am sure, these and whatever other problems I may find in the reposurgeon conversion can be fixed in time. However, I don't see why should bother. My conversion has been

[Bug target/93094] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93094 --- Comment #2 from Jakub Jelinek --- Scalar MASK_STORE really shouldn't appear in the IL except in the copy of the loop intended for vectorization only (when it is transformed into vectorized MASK_STORE). So I'm afraid the above change leaks

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de ---

[Bug target/93094] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93094 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/93095] Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93095 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com ---

[Bug libgomp/93097] New: Wrong OpenMP version reported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93097 Bug ID: 93097 Summary: Wrong OpenMP version reported Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Joseph Myers wrote: > Concretely, what I'd suggest is: convert ISO-8859-1 entries in the > checked-in list to UTF-8, removing anything that thereby becomes a > duplicate or unnecessary; handle anything whose encoding isn't simply > ISO-8859-1 or UTF-8 via a hardcoded entry

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

;& ./a.out val1: 0 repr: 1 val2: 1 -- gcc x86-64 version: gcc (GCC) 10.0.0 20191229 (experimental) -- C11, 6.2.6.1p4: "Two values (other than NaNs) with t

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD wrote: > > Which brings me to something I find strange in your policy: to me, > merges from trunk to branches should be rare if not nonexistent. And you > are deciding to banish merges the other way around. Out of curiosity, why do you

Re: Git conversion: fixing email addresses from ChangeLog files

On Sun, 2019-12-29 at 07:32 -0500, Eric S. Raymond wrote: > Richard Earnshaw (lists) : > > I've just commented that one out for now; if anybody knows the correct > > addresses, please let me know. Also, there's one joint list that I've > > not attempted to fix at this time. > > # "28488": "Jim

Re: C++ PATCH for c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr

On Sat, Dec 21, 2019 at 04:50:41PM -0500, Jason Merrill wrote: > On 12/17/19 5:34 PM, Marek Polacek wrote: > > + /* [class.cdtor]/6 "If the operand of the dynamic_cast refers to > > + the object under construction or destruction and the static type > > + of the operand is not a pointer to

[Bug c++/93096] New: detect [class.cdtor]/6 UB in constexpr dynamic_cast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93096 Bug ID: 93096 Summary: detect [class.cdtor]/6 UB in constexpr dynamic_cast Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug libgomp/93066] libgomp/target.c:525:46: error: expected expression before ')' token

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066 --- Comment #4 from John David Anglin --- Created attachment 47562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47562=edit Patch I'm fine with the proposed changes to target.c but I think we need the include fix as it's needed for other

[Bug c++/88323] implement C++20 language features.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 Bug 88323 depends on bug 88337, which changed state. Bug 88337 Summary: Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337 What|Removed

[Bug c++/55004] [meta-bug] constexpr issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 88337, which changed state. Bug 88337 Summary: Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337 What|Removed

[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

Re: Proposal for the transition timetable for the move to GIT

Hi, On Wed, 2019-12-25 at 06:10 -0600, Segher Boessenkool wrote: > git-svn did not miss any branches. Finding branches is not done by > git-svn at all, for this. These branches were skipped because they > have nothing to do with GCC, have no history in common (they are not > descendants of

[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337 --- Comment #11 from Marek Polacek --- Author: mpolacek Date: Sun Dec 29 16:44:41 2019 New Revision: 279755 URL: https://gcc.gnu.org/viewcvs?rev=279755=gcc=rev Log: PR c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr.

[Bug libgcc/92988] crtstuff.c:387:21: error: '__dso_handle' undeclared (first use in this function)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92988 --- Comment #1 from John David Anglin --- Created attachment 47561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47561=edit Patch

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 17:32, Richard Earnshaw a écrit : We agreed that for changes in our current workflow practices we'd defer that until *after* we'd switched to git; so this is getting off topic. On the other hand, we do need to sort out what we do with existing merge history, as that forms part

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 12:15, Segher Boessenkool wrote: > On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote: >> For bisecting trunk a merge would be a single commit, right? So I could see >> value in preserving a patch series where individual steps might introduce >> temporary issues as a

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 12:32, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> I've just commented that one out for now; if anybody knows the correct >> addresses, please let me know.  Also, there's one joint list that I've >> not attempted to fix at this time. > >> #  "28488": "Jim Kingdon

Re: The far past of GCC

Mark Wielaard : > Apparently less complete, but there is also > https://ftp.gnu.org/old-gnu/gcc/ > Which does have some old diff files to reconstruct some missing versions. There are quite a few ancient preserved release tarballs out there Here is the list of reconstructable pre-r3 releases as as

[Bug c++/93095] New: Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93095 Bug ID: 93095 Summary: Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’ Product: gcc Version: 10.0

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #25 from fdlbxtqi --- Created attachment 47560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47560=edit forgot to_address 2nd patch I am going to run testsuites

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #24 from fdlbxtqi --- Comment on attachment 47559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559 An untested patch >From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001 >From: expnkx >Date: Sun, 29 Dec

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #20 from fdlbxtqi --- Comment on attachment 47559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559 An untested patch >From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001 >From: expnkx >Date: Sun, 29 Dec

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #23 from fdlbxtqi --- Comment on attachment 47559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559 An untested patch >From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001 >From: expnkx >Date: Sun, 29 Dec

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #22 from fdlbxtqi --- Comment on attachment 47559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559 An untested patch >From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001 >From: expnkx >Date: Sun, 29 Dec

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #21 from fdlbxtqi --- Comment on attachment 47559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559 An untested patch >From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001 >From: expnkx >Date: Sun, 29 Dec

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 02:48:31PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: > >Merges aren't scary. Merges are inconvenient. > > No they are not. You are unaccustomed to them, which is different. Lol. Okay, end of discussion. You are assuming all the wrong things. Segher

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #19 from fdlbxtqi --- Created attachment 47559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559=edit An untested patch From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001 From: expnkx Date: Sun, 29 Dec

Re: The far past of GCC

On Sat, Dec 28, 2019 at 09:15:53PM -0700, Jeff Law wrote: > I don't have a gitlab account, so I'm commenting here. > > I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. But I'm not aware of anyone still > having a copy of the old RCS ,v files.

[Bug rtl-optimization/93094] New: [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93094 Bug ID: 93094 Summary: [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 14:31, Segher Boessenkool a écrit : On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: At worst, no commit is testable in the branch except the last, and git will say that the bug was introduced in the branch, which is not worse that what you'd get

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 14:26, Segher Boessenkool a écrit : Hi! On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: I'm not arguing that you should go that route, it seems a bit extreme to me. But outright refusing merges on the basis they are painful is (if you can accept the

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: > At worst, no commit is testable in the > branch except the last, and git will say that the bug was introduced in > the branch, which is not worse that what you'd get without a merge commit. We normally require every

Re: Proposal for the transition timetable for the move to GIT

Hi! On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: > I'm not arguing that you should go that route, it seems a bit extreme to > me. But outright refusing merges on the basis they are painful is (if > you can accept the strong word) ludicrous. They are painful for

Re: The far past of GCC

> I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. Your memory agrees with mine.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #18 from fdlbxtqi --- (In reply to Marc Glisse from comment #17) > (In reply to fdlbxtqi from comment #15) > > What I am worried about is that whether revamping these functions would be > > a new wave of ABI breaking. > > I don't

Re: The far past of GCC

Jeff Law : > I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. That year sounds right - it's when I wrote the original vcs.el for Emacs and a lot of Emacs users who hadn't been usiing version control started to. Doesn't give us a Subversion

Re: Git conversion: fixing email addresses from ChangeLog files

Richard Earnshaw (lists) : > I've just commented that one out for now; if anybody knows the correct > addresses, please let me know. Also, there's one joint list that I've > not attempted to fix at this time. > # "28488": "Jim Kingdon ", That's Jim Kingdon the

[Bug fortran/91310] Read overflow generated by character array assignment to self

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote: > For bisecting trunk a merge would be a single commit, right? So I could see > value in preserving a patch series where individual steps might introduce > temporary issues as a branch merge (after rebasing) so the series is visible

[Bug fortran/91310] Read overflow generated by character array assignment to self

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 --- Comment #6 from Thomas Koenig --- Comment on attachment 46648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46648 test case 1 Oops, correction. If len is small enough, the test case can be valid (well, it could be if str was ever

[Bug fortran/91310] Read overflow generated by character array assignment to self

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 12:02, Richard Biener a écrit : On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool wrote: On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: Oh, I'm not talking about historical merges. I'm saying we shouldn't do future merges, where we

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 11:41, Segher Boessenkool a écrit : On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: Oh, I'm not talking about historical merges. I'm saying we shouldn't do future merges, where we can help that. It disagrees with our documented "submitting patches"

Re: [PATCH] libstdc++: Define std::lexicographical_compare_three_way for C++20

On 05/12/2019 13:46, Jonathan Wakely wrote: commit 5012548fd62526fdf5e04aeacee2b127efbac0e0 Author: Jonathan Wakely Date: Thu Dec 5 12:23:53 2019 + libstdc++: Define std::lexicographical_compare_three_way for C++20 * include/bits/stl_algobase.h

Re: [PATCH] Allow {nearby,r}int{,f} vectorization on x86 with sse4.1 and later (PR target/93078)

On Sat, Dec 28, 2019 at 02:20:09PM +0100, Uros Bizjak wrote: > > The conditions are: > > (define_expand "nearbyint2" > > [(use (match_operand:MODEF 0 "register_operand")) > >(use (match_operand:MODEF 1 "nonimmediate_operand"))] > > "(TARGET_USE_FANCY_MATH_387 > > && (!(SSE_FLOAT_MODE_P

[Bug target/93078] Missing fma and round functions auto-vectorization with x86-64 (sse2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93078 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sun Dec 29 11:03:25 2019 New Revision: 279754 URL: https://gcc.gnu.org/viewcvs?rev=279754=gcc=rev Log: PR target/93078 * config/i386/i386-builtins.c

Re: Proposal for the transition timetable for the move to GIT

On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool wrote: >On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud >wrote: >> >Oh, I'm not talking about historical merges. I'm saying we >shouldn't do >> >future merges, where we can help that. It disagrees with our

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: > >Oh, I'm not talking about historical merges. I'm saying we shouldn't do > >future merges, where we can help that. It disagrees with our documented > >"submitting patches" protocol. > > I don't see how that can be

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #17 from Marc Glisse --- (In reply to fdlbxtqi from comment #15) > What I am worried about is that whether revamping these functions would be a > new wave of ABI breaking. I don't foresee any ABI issue here. Do make sure your code

*ping*[patch, fortran] Fix PR 91541, ICE on valid for INDEX

Am 19.12.19 um 08:23 schrieb Thomas Koenig: Regression-tested. OK for trunk? Ping?

*ping* [patch, fortran] Updated fix PR 92961, ICE on division by zero error in array bounds

Am 22.12.19 um 16:28 schrieb Thomas Koenig: here is an update for the fix for PR 92961, which also takes care of the second test case in the PR (included in the first one). The patch itself should be clear enough - make sure that there is a MATCH_ERROR on matching an array spec which contains

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #16 from fdlbxtqi --- (In reply to Marc Glisse from comment #13) > (In reply to fdlbxtqi from comment #11) > > TBH. I would rather see the library does the optimization instead of the > > compiler. I do not trust the compiler can

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #15 from fdlbxtqi --- (In reply to fdlbxtqi from comment #14) > I think It is worth the effort to rewrite these functions since they are so > fundamental to the performance of entire C++. What I am worry about is that > whether

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #14 from fdlbxtqi --- I think It is worth the effort to rewrite these functions since they are so fundamental to the performance of entire C++. What I am worry about is that whether revamping these functions would be a new ABI

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #13 from Marc Glisse --- (In reply to fdlbxtqi from comment #11) > TBH. I would rather see the library does the optimization instead of the > compiler. I do not trust the compiler can always optimize this stuff. If we have both,

  1   2   >