https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93086
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93086
Bug ID: 93086
Summary: build_nonstandard_integer_type should take signop
instead of int
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: enhancement
On Fri, Dec 27, 2019 at 2:33 PM Jakub Jelinek wrote:
>
> This will be ABI incompatible between GCC and Clang, that doesn't look like
> a good idea to me. I thought the plan is to use what you have in the
> _GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION case always, except that if
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085
Bug ID: 93085
Summary: ICE in get_class_binding_direct and alias_ctad_tweaks,
with C++20 NTTP + CTAD + alias template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Andreas Schwab :
> On Dez 25 2019, Eric S. Raymond wrote:
>
> > That's easily fixed by adding a timezone entry to your author-map
> > entry - CET, is it?
>
> The time zone is not constant.
Congratulations, you have broken one of reposurgeon's assumptions.
It is possible to use reposurgeon;d
Joseph Myers :
> reposurgeon results are fully reproducible (by design, the same inputs to
> the same version of reposurgeon should produce the same output as a
> git-fast-import stream,
Designer confirms, and adds that we gave a *very* stringent test suite
to verify this.
Much of it consists
Richard Earnshaw (lists) :
> Well, personally, I'd rather we didn't throw away data we have in our
> current SVN repo unless it's unpresentable in the final conversion.
I agree with this philosophy. You will have noticed by now, I hope,
that reposurgeon peserves as much as it can, leaving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066
--- Comment #1 from dave.anglin at bell dot net ---
This is a target issue. I’m testing an include fix.
Including stdint.h after inttypes.h would avoid the problem but I think header
needs fixing.
--
John David Anglin
Maxim Kuvyrkov :
> Removing auto-generated .gitignore files from reposurgeon conversion
> would allow comparison of git trees vs gcc-pretty and gcc-reparent
> beyond r195087. So, while we are evaluating the conversion
> candidates, it is best to disable conversion features that cause
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Jan Hubicka changed:
What|Removed |Added
CC||fxue at os dot
amperecomputing.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #1
Snapshot gcc-8-20191227 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20191227/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074
Thomas Schwinge changed:
What|Removed |Added
CC||frederik at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064
Jakub Jelinek changed:
What|Removed |Added
Keywords||error-recovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92966
Jakub Jelinek changed:
What|Removed |Added
CC||jengelh at inai dot de
--- Comment #4
On Fri, 27 Dec 2019, Andreas Schwab wrote:
> SVN also only has a committer, so the fabricated author should not be
> influenced by the committer.
That issue has been fixed.
--
Joseph S. Myers
j...@polyomino.org.uk
On Dez 25 2019, Eric S. Raymond wrote:
> That's easily fixed by adding a timezone entry to your author-map
> entry - CET, is it?
The time zone is not constant.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now
On Dez 25 2019, Joseph Myers wrote:
> On investigation, I think you are referring to the conversion of r269472.
> That was committed for you by Jim Wilson and thus has you as author and
> Jim Wilson as committer and Jim Wilson's timezone entry has been applied.
> So the argument here is that
Email addresses from the ChangeLog files are not validated during
commits, so a number of typos exist in the extracted data. I've
extracted the 'Author:' entry from a prototype conversion and then piped
that through sort and uniq -c. Subsequent analysis shows the following
addresses/names that
On Fri, Dec 27, 2019 at 02:27:12PM -0500, JeanHeyd Meneide wrote:
> This patch implements std::source_location. There's a couple
> cases where the builtin implemented does not do what is expected of
> it, and so the bottom 3 batches of test cases fails. I'm still
> including the patch so that
This patch implements std::source_location. There's a couple
cases where the builtin implemented does not do what is expected of
it, and so the bottom 3 batches of test cases fails. I'm still
including the patch so that others can pick up on what might need to
change about the
Hi!
On Fri, Dec 27, 2019 at 12:44:25PM -0500, David Malcolm wrote:
> I'm wondering what the plan is for the git-only branches currently
> hosted on the gcc.gnu.org git server.
Those should be pretty trivial to convert, *if* the chosen conversion
does not change file contents at all (it
On Fri, 27 Dec 2019, Richard Biener wrote:
> Does this allow to keep the URL of the old git mirror and the new
> official fit repo the same or would that cause conflicts with existing
> clones?
The URL of the old mirror feels like it's the right URL to use for the new
conversion. It would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Bug ID: 93084
Summary: Infinite loop in ipa-cp when building clang with
LTO+PGO
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
On December 27, 2019 6:58:11 PM GMT+01:00, Joseph Myers
wrote:
>On Fri, 27 Dec 2019, David Malcolm wrote:
>
>> What the plan for such branches?
>
>My view is: add all refs (and thus all objects) from the existing git
>mirror to the converted repository, probably under names that are not
On Tue, Dec 24, 2019 at 07:21:53PM +0530, Ayush Mittal wrote:
> [BUG: 93065] libgomp: destructor missing to delete goacc_cleanup_key
> libgomp constructor creates goacc_cleanup_key on dlopen but doesn't delete
> key on dlclose.
> dlopen and dlclose of libgomp.so exhausts pthread keys, which
On Fri, 27 Dec 2019, David Malcolm wrote:
> What the plan for such branches?
My view is: add all refs (and thus all objects) from the existing git
mirror to the converted repository, probably under names that are not
fetched by default (this increases the repository size, after git gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93077
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
(Sorry if I'm missing a FAQ here, but the discussion about the git
conversion has grown very large)
I'm wondering what the plan is for the git-only branches currently
hosted on the gcc.gnu.org git server.
In particular, I'm actively developing stuff in my "dmalcolm/analyzer"
branch there, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
Bug ID: 93083
Summary: copy deduction rejected when doing CTAD for NTTP
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93078
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
On Fri, 2019-12-27 at 10:53 -0500, David Edelsohn wrote:
> > > > > > John Paul Adrian Glaubitz wrote:
> > The programming language Rust has become very popular over the past
> > few years
> > with many projects rewriting parts of their codebase in that
> > language. While
> > these rewrites often
All VNx2 V_INT_CONTAINER entries should map to VNx2DI. The lower-case
version was already correct.
Tested on aarch64-linux-gnu and applied as r279743.
Richard
2019-12-27 Richard Sandiford
gcc/
* config/aarch64/iterators.md (V_INT_CONTAINER): Fix VNx2SF entry.
gcc/testsuite/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67834
John David Anglin changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
On December 27, 2019 5:02:55 PM GMT+01:00, Richard Sandiford
wrote:
>The fold-left reduction code has a (rarely-used) fallback that handles
>cases in which the loop is fully-masked and the target has no native
>support for the reduction. The fallback includea a VEC_COND_EXPR
>between the
The fold-left reduction code has a (rarely-used) fallback that handles
cases in which the loop is fully-masked and the target has no native
support for the reduction. The fallback includea a VEC_COND_EXPR
between the reduction vector and a safe value, so we should check
whether that VEC_COND_EXPR
Jason Merrill writes:
> On 12/18/19 1:24 PM, Richard Sandiford wrote:
>> The SVE port needs to maintain a different type identity for
>> GNU vectors and "SVE vectors" even during LTO, since the types
>> use different ABIs. The easiest way of doing that seemed to be
>> to use type attributes.
> John Paul Adrian Glaubitz wrote:
> The programming language Rust has become very popular over the past few years
> with many projects rewriting parts of their codebase in that language. While
> these rewrites often make the code perform faster and potentially safer, using
> Rust makes these
On Fri, Dec 27, 2019 at 7:23 AM J Decker wrote:
> would you suggest I go? It doesn't look like C standards, unlike
> es-discuss for ecma script, I couldn't find a open forum to discuss such
> things... or even a github group like... https://github.com/tc39/proposals
You can table the proposal
On Thu, Dec 26, 2019 at 05:32:52PM -0500, Eric S. Raymond wrote:
> Toon Moene :
> > So we are going to base this world wide free software endeavor on a source
> > code system that doesn't keep time by UTC ?
>
> They all *do* keep time by UTC.
(Git stores unix time, instead -- close enough ;-) )
On 25/12/2019 11:02, Roman Zhuykov wrote:
> First of all thanks to everyone who spent time making the conversion
> better and better. Here is my 2c, I have studied a little my colleagues
> trunk history in Maxim's gcc-pretty vs gcc-reposurgeon-5b.
>
> 1) In gcc-pretty timezone info is lost in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
--- Comment #7 from Jan Hubicka ---
This patch fixes the testcase, but I am not familiar enough with the code to
say if that is correct fix :)
Index: ../../gcc/cp/cp-gimplify.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93079
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93079
--- Comment #1 from Jan Hubicka ---
We rewrite VAR_DECL to invalid tree code by gimple_set_plf
(gdb) p ((tree)0x7fffeccfba20).base.code
$22 = VAR_DECL
(gdb) c
Continuing.
Hardware watchpoint 1: *$13
Old value = 17039395
New value = 17041443
On Fri, Dec 27, 2019 at 03:32:57AM -0800, Andrew Pinski wrote:
> The one branch merge which would have helped me track down why a
> testcase was added is the tree-ssa branch merge. If we had the commit
> for the merge to have the merge info, it would have been easier for me
> to track down that.
On Fri, Dec 27, 2019 at 11:21:41AM +, Richard Earnshaw (lists) wrote:
> On 26/12/2019 18:59, Joseph Myers wrote:
> > On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> >> Yes, I'd prefer the trunk to have no merge commits (in svn I've removed the
> >> svn:mergeinfo property on the trunk when it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93078
Alexander Monakov changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
Bug ID: 93082
Summary: macOS Authorization.h needs fixinclude
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
On 27/12/2019 11:35, Joseph Myers wrote:
> On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote:
>
>> I'm not really sure I understand why we don't want merge commits into
>> trunk, especially for large changes. Performing archaeology on a change
>> is just so much easier if the development
On Fri, 27 Dec 2019, Alexandre Oliva wrote:
> That depends on the used tool. A reproducible one, or at least one that
> aimed at stability across multiple conversions, could make this easier,
> but I guess reposurgeon is not such a tool. Which suggests to me we
> have to be even more reassured
On Dec 26, 2019, Joseph Myers wrote:
> We should ensure we don't have missing branches in the first place (for
> whatever definition of what branches we should have).
*nod*
> Adding a branch after the fact is a fundamentally different kind of
> operation
That depends on the used tool. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
Bug ID: 93081
Summary: insertation followed by another inseration to the same
location is not optimized away
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865
--- Comment #5 from Jozef Lawrynowicz ---
(In reply to Segher Boessenkool from comment #4)
> Created attachment 47550 [details]
> simplify-rtx patch for extends of AND of hard reg
>
> So I did a patch to make this work (in simplify-rtx) also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
Bug ID: 93080
Summary: insert of an extraction on the same location is not
optimized
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93079
Bug ID: 93079
Summary: ICE in mark_operand_necessary
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote:
> I'm not really sure I understand why we don't want merge commits into
> trunk, especially for large changes. Performing archaeology on a change
> is just so much easier if the development history is just there.
To some extent it fits with
On Fri, Dec 27, 2019 at 3:22 AM Richard Earnshaw (lists)
wrote:
>
> On 26/12/2019 18:59, Joseph Myers wrote:
> > On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> >
> >> On Thu, Dec 26, 2019 at 04:58:22PM +, Joseph Myers wrote:
> >>> If we don't want merge commits on git master for the cases where
On 26/12/2019 18:59, Joseph Myers wrote:
> On Thu, 26 Dec 2019, Jakub Jelinek wrote:
>
>> On Thu, Dec 26, 2019 at 04:58:22PM +, Joseph Myers wrote:
>>> If we don't want merge commits on git master for the cases where people
>>> put merge properties on trunk in the past, we can use a
Here is the patch to extend DR 526 to forward_list and list remove_if
and unique.
As the adopted pattern is simpler I also applied it to the remove methods.
PR libstdc++/91620
* include/bits/forward_list.tcc (forward_list<>::remove): Collect nodes
to destroy in an intermediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
> On Dec 27, 2019, at 4:32 AM, Joseph Myers wrote:
>
> On Thu, 26 Dec 2019, Joseph Myers wrote:
>
>>> It appears that .gitignore has been added in r1 by reposurgeon and then
>>> deleted at r130805. In SVN repository .gitignore was added in r195087.
>>> I speculate that addition of
66 matches
Mail list logo
