On Sat, Dec 21, 2019 at 11:11 AM Allan Sandfeld Jensen
wrote:
> On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access
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 .gitignore at r1 is expected, but it's
> > deletion at r130805 is
Vincent Lefevre :
> What matters is that the date is correct. I don't think the timezone
> matters (that's why SVN doesn't store timezone information, I assume),
> possibly except for the committer himself (?). For instance,
Subversion doesn't store timezone because all commits are consifered
to
Hello!
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 projects less portable as Rust is
On 2019-12-26 16:30:15 -0500, Eric S. Raymond wrote:
> Vincent Lefevre :
> > > Here's why you want to get timezones right: there are going to be times
> > > when the order of commits is significant information for a developer's
> > > understanding of what happened. But without a timezone you only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93078
Bug ID: 93078
Summary: Missing fma and round functions auto-vectorization
with x86-64 (sse2)
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
I've added author fixups to bugdb.py, so you can add any number of fixes
(e.g. based on authors that look suspicious in "git
Toon Moene :
> On 12/26/19 10:30 PM, Eric S. Raymond wrote:
>
> > Me, I don't undertstand why version-control systems designed for distributed
> > use don't ignore timezones entirely and display all times in UTC - relative
> > time is surely more imoortant than the commit time's relationship to
On 12/26/19 10:30 PM, Eric S. Raymond wrote:
Me, I don't undertstand why version-control systems designed for distributed
use don't ignore timezones entirely and display all times in UTC - relative
time is surely more imoortant than the commit time's relationship to solar
noon wherever the
Vincent Lefevre :
> > Here's why you want to get timezones right: there are going to be times
> > when the order of commits is significant information for a developer's
> > understanding of what happened. But without a timezone you only know
> > the actual time of a commit to 24-hour resoltion.
Alexandre Oliva :
> I don't see that it does (help). Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion. git-svn can do that incrementally, after the
On 2019-12-25 14:33:45 -0500, Eric S. Raymond wrote:
> Segher Boessenkool :
> > The goal is not to pretend we never used SVN.
>
> One of *my* goals is that the illusion of git back to the beginning of
> time should be as consistent as possible.
>
> > The goal is to have a Git repo that is as
On December 26, 2019 5:58:22 PM GMT+01:00, Joseph Myers
wrote:
>On Thu, 26 Dec 2019, Maxim Kuvyrkov wrote:
>
>> Reposurgeon creates merge entries on trunk when changes from a branch
>
>> are merged into trunk. This brings entire development history from
>the
>> branch to trunk, which is both
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> I don't see that it does (help). Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion. git-svn can do
On Dec 26, 2019, "Eric S. Raymond" wrote:
> Alexandre Oliva :
>> On Dec 25, 2019, "Eric S. Raymond" wrote:
>>
>> > Reposurgeon has a reparent command. If you have determined that a
>> > branch is detached or has an incorrect attachment point, patching the
>> > metadata of the root node to fix
Alexandre Oliva :
> On Dec 25, 2019, "Eric S. Raymond" wrote:
>
> > Reposurgeon has a reparent command. If you have determined that a
> > branch is detached or has an incorrect attachment point, patching the
> > metadata of the root node to fix that is very easy.
>
> Thanks, I see how that can
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. However, these type attributes
On 12/18/19 1:03 AM, Julian Brown wrote:
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the C and C++ changes to parse attach and detach
clauses and struct
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 reposurgeon
> > "unmerge" command in gcc.lift to stop
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 reposurgeon
> "unmerge" command in gcc.lift to stop the few commits in question from
> being merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93077
Bug ID: 93077
Summary: internal compiler error: in hash_operand during GIMPLE
pass: fre
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93076
Bug ID: 93076
Summary: internal compiler error: Segmentation fault during
GIMPLE pass: cddce
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
On Thu, 26 Dec 2019, Maxim Kuvyrkov wrote:
> Reposurgeon creates merge entries on trunk when changes from a branch
> are merged into trunk. This brings entire development history from the
> branch to trunk, which is both good and bad. The good part is that we
> get more visibility into how
> On Dec 26, 2019, at 2:16 PM, Jakub Jelinek wrote:
>
> On Thu, Dec 26, 2019 at 11:04:29AM +, Joseph Myers wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
> E.g. there are misspelled surnames, etc. (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93075
Bug ID: 93075
Summary: Incorrect line number in DW_MACRO_start_file entry of
file included via "-include" option
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
On Dec 25, 2019, Alexandre Oliva wrote:
> 3. do not take the executable name into account when it shares the
> basename with an input file; combine executable basename with input name
> otherwise. this makes gcc -o foo[.exe] -g -gsplit-dwarf foo.c output
> foo.dwo rather than foo-foo.dwo, which
On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
These can be corrected via reposurgeon commands in gcc.lift (see the
existing "// attribution =A set
jwakely@gmail.com"
On Thu, Dec 26, 2019 at 11:04:29AM +, Joseph Myers wrote:
Is there some easy way (e.g. file in the conversion scripts) to correct
spelling and other mistakes in the commit authors?
E.g. there are misspelled surnames, etc. (e.g. looking at my name, I see
Jakub Jakub Jelinek (1):
Jakub Jeilnek
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> Could make it a requirement that at least the commits associated with
> head branches and published tags compare equal in both conversions, or
> that differences are known, understood and accepted, before we switch
> over to either one? Going over
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92438
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression] Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92438
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Dec 26 10:16:01 2019
New Revision: 279736
URL: https://gcc.gnu.org/viewcvs?rev=279736=gcc=rev
Log:
PR c++/92438
* parser.c (cp_parser_constructor_declarator_p): If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074
--- Comment #2 from Dmitry G. Dyachenko ---
(In reply to Andrew Pinski from comment #1)
> According to
> https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__DEVICE.html
>
> cuDeviceGetName exists.
> Maybe F31 has an older version of Cuda
32 matches
Mail list logo
