https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93253
--- Comment #8 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:c35a3046247c495509610b50c7a85683d540811a
commit r10-5994-gc35a3046247c495509610b50c7a85683d540811a
Author: Tobias Burnus
Date:
> > + gassign *get_res = gimple_build_assign (lhs, done);
> > + gsi_replace (gsi, get_res, true);
> > + *handled_ops_p = true;
> > + }
> > + break;
> > + }
> > +}
> > + return NULL_TREE;
> > +}
> > +
> > +/* Main entry point for lowering
On Wed, 15 Jan 2020, Martin Jambor wrote:
> when going over stuff linked from the SummerOfCode wiki page,
> I found out that doc/install.texi still refers to Subversion.
We've got a fair number of references left in various places;
working through that slowly and appreciate your help!
> The
Replace two references to svn.html and svnwrite.html by git.html and
gitwrite.html, respectively. Reduce an explicit reference to whatever
tool we use on the way.
Pushed.
---
htdocs/contribute.html | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/htdocs/contribute.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #24 from Marc Glisse ---
Something like that, yes. Essentially, I used trivial because I was convinced
it was safe in that case, not because it looked like the perfect condition. If
someone can convincingly argue for a weaker
On January 16, 2020 12:56:48 AM GMT+01:00, David Malcolm
wrote:
>Various 32-bit targets show failures in gcc.dg/analyzer/data-model-1.c
>with tests of the form:
> __analyzer_eval (q[-2].x == 107024); /* { dg-warning "TRUE" } */
> __analyzer_eval (q[-2].y == 107025); /* { dg-warning "TRUE" } */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #10 from rguenther at suse dot de ---
On January 16, 2020 3:55:18 AM GMT+01:00, wwwhhhyyy333 at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
>
>--- Comment #9 from Hongyu Wang ---
>(In reply to
On 1/15/20 10:52 PM, Jonathan Wakely wrote:
On 15/01/20 21:48 +, Jonathan Wakely wrote:
On 14/01/20 22:25 +0100, François Dumont wrote:
On 1/13/20 10:53 PM, Jonathan Wakely wrote:
On 13/01/20 22:41 +0100, François Dumont wrote:
For the multi-keys we could still avoid redundant
From: Andrew Pinski
In struct _dep, there is an implicit padding of 4bits. This
bit-field padding is uninitialized when init_dep_1 is being called.
This means we access uninitialized memory but never use it for
anything. Adding an unused bit-field field and initializing it
in init_dep_1 will
From: Andrew Pinski
Commit g:f96bf49a0 added the target field to expand_operand.
But it leaves it uninitialized when doing a full initialization
inside create_expand_operand. This fixes the problem and improves
the code generation inside create_expand_operand too.
OK? Bootstrapped and tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #9 from Hongyu Wang ---
(In reply to Hongtao.liu from comment #6)
> New fail by removal
> unix/-m32: gcc.dg/tree-ssa/copy-headers-5.c scan-tree-dump ch2 "is now
> do-while loop"
> unix/-m32: gcc.dg/tree-ssa/copy-headers-5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #23 from Arthur O'Dwyer ---
@Dan Stahlke: I believe
https://stackoverflow.com/questions/47464819/uninitialized-copy-memcpy-memmove-optimization
answers your question. Or, if it doesn't, then Marc or someone should consider
posting an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
Dan Stahlke changed:
What|Removed |Added
CC||dan at stahlke dot org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31350
Andrew Pinski changed:
What|Removed |Added
CC||josh at joshtriplett dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93284
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93284
Bug ID: 93284
Summary: gcc -v --help emits some messages to stderr
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93281
--- Comment #3 from David Malcolm ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00924.html
Various 32-bit targets show failures in gcc.dg/analyzer/data-model-1.c
with tests of the form:
__analyzer_eval (q[-2].x == 107024); /* { dg-warning "TRUE" } */
__analyzer_eval (q[-2].y == 107025); /* { dg-warning "TRUE" } */
where they emit UNKNOWN instead.
The root cause is that gimple has a
Pushed to origin/master as 5b6681201ae54a3272d49e390f96a1a45a6eb435
gcc/ChangeLog:
* doc/analyzer.texi (Overview): Add note about
-fdump-ipa-analyzer.
---
gcc/doc/analyzer.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/doc/analyzer.texi b/gcc/doc/analyzer.texi
I rewrote class impl_region_model_context to avoid using multiple
inheritance during patch review but forgot to update this comment.
Fix it.
Pushed to origin/master as 49e9a9996ab334133c78f1445173d8e663edd3e9
gcc/analyzer/ChangeLog:
* engine.cc (class impl_region_model_context): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93282
--- Comment #1 from Andrew Pinski ---
s-options: $(ALL_OPT_FILES) Makefile $(srcdir)/opt-gather.awk
I don't see anything wrong with this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93277
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Wed, Jan 15, 2020 at 11:25:44PM +0100, Tobias Burnus wrote:
>
> regarding the release-notes text: I like your version – it helps if
> someone writes the text, who knows what changed. I have fixed a typo and
> adapted the syntax – see attachment. Any comment to it? Otherwise, I
> intent to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93281
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93283
Bug ID: 93283
Summary: Partial specialization not specializing any parameters
is allowed with alias templates
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
A reasonable replacement for those push rules might be command aliases
(e.g. "git upush " to push the user branch ).
--
Joseph S. Myers
jos...@codesourcery.com
Hello,
Google Summer of Code (aka GSoC) 2020 yesterday started accepting
Organization Applications. I believe the last year was very successful
and so think that we want to take part again this year again. I'll be
happy to volunteer to be the main Org Admin for GCC again (so let me
know if you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93072
Joseph S. Myers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93072
--- Comment #6 from CVS Commits ---
The releases/gcc-8 branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:67cceb6c538b7a10cd5cf5693bce7fc7a646581d
commit r8-9938-g67cceb6c538b7a10cd5cf5693bce7fc7a646581d
Author: Joseph Myers
On Wed, 2020-01-15 at 17:27 -0500, John David Anglin wrote:
> On 2020-01-15 3:45 p.m., Jeff Law wrote:
> > On Mon, 2019-12-30 at 14:23 -0500, John David Anglin wrote:
> > > Tested on hppa64-hp-hpux11.11.
> > >
> > > Okay?
> > >
> > > Dave
> > >
> > > 2019-12-30 John David Anglin
> > >
> > >
On 2020-01-15 3:45 p.m., Jeff Law wrote:
> On Mon, 2019-12-30 at 14:23 -0500, John David Anglin wrote:
>> Tested on hppa64-hp-hpux11.11.
>>
>> Okay?
>>
>> Dave
>>
>> 2019-12-30 John David Anglin
>>
>> PR libgcc/92988
>> * crtstuff.c (__do_global_dtors_aux): Only call __cxa_finalize if
Hi Steve,
regarding the release-notes text: I like your version – it helps if
someone writes the text, who knows what changed. I have fixed a typo and
adapted the syntax – see attachment. Any comment to it? Otherwise, I
intent to commit it tomorrow.
Regarding the patch, I enclosed a revised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #11 from joseph at codesourcery dot com ---
On Wed, 15 Jan 2020, christophe.monat at st dot com wrote:
> Now that C11 is complete, would it be acceptable to have GCC define
> __STDC_NO_THREADS__ and __STDC_NO_ATOMIC__ when
On 15/01/20 21:48 +, Jonathan Wakely wrote:
On 14/01/20 22:25 +0100, François Dumont wrote:
On 1/13/20 10:53 PM, Jonathan Wakely wrote:
On 13/01/20 22:41 +0100, François Dumont wrote:
For the multi-keys we could still avoid redundant comparisons
when _Equal is just doing == on the key
On 14/01/20 22:25 +0100, François Dumont wrote:
On 1/13/20 10:53 PM, Jonathan Wakely wrote:
On 13/01/20 22:41 +0100, François Dumont wrote:
For the multi-keys we could still avoid redundant comparisons when
_Equal is just doing == on the key type. On unordered_multiset we
could just avoids
Pushed.
Gerald
- Log -
commit 335d0b9345d12398b14ad6f69c3572861ce49d5b
Author: Gerald Pfeifer
Date: Wed Jan 15 22:34:53 2020 +0100
Swap links to our previous SVN documentation with those for Git.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|paolo at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
--- Comment #14 from Jakub Jelinek ---
(In reply to Wilco from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Any -march= or similar? Can't reproduce with current trunk, nor
> > with even Oct 10 GCC snapshot (crosses in both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
David Binderman changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073
--- Comment #11 from CVS Commits ---
The master branch has been updated by Paolo Carlini :
https://gcc.gnu.org/g:83fe2b921830c177e3dee514aa07cbc7c8ceef1c
commit r10-5990-g83fe2b921830c177e3dee514aa07cbc7c8ceef1c
Author: Paolo Carlini
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
--- Comment #1 from David Binderman ---
Reduced C++ code is:
struct a {
template a(b);
int c;
};
struct d {
a e{0};
};
void f() {
d g;
g = {};
}
$ /home/dcb/gcc/results/bin/gcc -c bug583.cc
bug583.cc: In function ‘void f()’:
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
seen with trunk 20200115:
x86_64-linux-gnu-g++-9 -std=gnu++98 -c -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind
On 13/01/20 09:02 -0500, Eric S. Raymond wrote:
diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index b4bf333e26a..21c312dce35 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -34,9 +34,8 @@
clauses 20 through 33 and annex D (prior to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93072
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:7cc6b679a0d0e50c0e1671fefa815dc753554184
commit r9-8136-g7cc6b679a0d0e50c0e1671fefa815dc753554184
Author: Joseph Myers
On Wed, Jan 15, 2020 at 01:18:54PM +, Martin Sebor wrote:
> @@ -4099,14 +4122,18 @@ determine_min_objsize (tree dest)
>
>init_object_sizes ();
>
> - if (compute_builtin_object_size (dest, 2, ))
> -return size;
> -
>/* Try to determine the size of the object through the RHS
>
On Mon, 2019-12-30 at 14:23 -0500, John David Anglin wrote:
> Tested on hppa64-hp-hpux11.11.
>
> Okay?
>
> Dave
>
> 2019-12-30 John David Anglin
>
> PR libgcc/92988
> * crtstuff.c (__do_global_dtors_aux): Only call __cxa_finalize if
> DEFAULT_USE_CXA_ATEXIT is true.
Who is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93281
--- Comment #1 from David Malcolm ---
These are all of the various:
__analyzer_eval (q[-2].x == 107024); /* { dg-warning "TRUE" } */
__analyzer_eval (q[-2].y == 107025); /* { dg-warning "TRUE" } */
emitting UNKNOWN instead.
The -m32 gimple
On Wed, 2020-01-15 at 13:18 +, Martin Sebor wrote:
> The strcmp optimization newly introduced in GCC 10 relies on
> the size of the smallest referenced array object to determine
> whether the function can return zero. When the size of
> the object is smaller than the length of the other
On Wed, 2020-01-15 at 13:30 +0100, Rainer Orth wrote:
> Hi David,
>
> > I've rebased and squashed the analyzer patch kit and squashed patch
> > 2
> > of the hash_table fix into it, and re-tested it successfully, so
> > I've
> > pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7).
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93281
Bug ID: 93281
Summary: Various analyzer testsuite failures for 32-bit targets
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93281
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
‐‐‐ Original Message ‐‐‐
On Thursday, January 9, 2020 8:42 AM, Richard Biener
wrote:
>
> As for the other question for testing you probably want to provide a
> OMP simd declaration
> of a function like
>
> _Complex double mycexpi (double);
>
> and make a testcase like
>
> void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
Bug ID: 93280
Summary: ice: in cp_gimplify_expr, at cp /cp-gimplify.c:933
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93257
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:299ddc612136421f1d9865ea4f2f84f7e3791824
commit r10-5989-g299ddc612136421f1d9865ea4f2f84f7e3791824
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93257
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 1/11/20 12:12 AM, Jason Merrill wrote:
This is a pretty rare situation since the C++11 change to make all
destructors default to noexcept, but it is still possible to define throwing
destructors, and if a destructor for a local variable throws during the
return, we've already constructed the
A prvalue can have void type, and if it doesn't do anything prohibited in a
constant expression, it's vacuously constant.
Tested x86_64-pc-linux-gnu, applying to trunk.
* constexpr.c (verify_constant): Allow void_node.
---
gcc/cp/constexpr.c | 3 ++-
Dimitar Dimitrov wrote:
On Wed, 15.01.2020, 14:30:43 EET Rainer Orth wrote:
Hi David,
I've rebased and squashed the analyzer patch kit and squashed patch 2
of the hash_table fix into it, and re-tested it successfully, so I've
pushed it to master (as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92871
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93257
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93277
--- Comment #4 from Peter Bergner ---
(In reply to Peter Bergner from comment #3)
> Strangely, using "gcc.foo" seems to be ok. Is there something special about
> source directory names "gcc.svn" and "gcc.git"?
So even "gcc-foo.git" causes a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92831
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:7192b1ec12484f5ca8b20930d8dc4d28ab4a533a
commit r10-5987-g7192b1ec12484f5ca8b20930d8dc4d28ab4a533a
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92871
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:7192b1ec12484f5ca8b20930d8dc4d28ab4a533a
commit r10-5987-g7192b1ec12484f5ca8b20930d8dc4d28ab4a533a
Author: Jason Merrill
Date:
I steered Jakub wrong on the desired behavior for temp-extend1.C in the
context of bug 92831; it doesn't make sense to try to extend the lifetime of
a temporary that we've already materialized to evaluate the test. So this
patch munges the stabilized expression so that it won't be subject to
On Wed, 15.01.2020, 14:30:43 EET Rainer Orth wrote:
> Hi David,
>
> > I've rebased and squashed the analyzer patch kit and squashed patch 2
> > of the hash_table fix into it, and re-tested it successfully, so I've
> > pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7).
> >
> > I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93277
--- Comment #3 from Peter Bergner ---
So this ends up not being a git conversion issue. I can also get this to fail
using my svn tree as well now. The problem seems to be the choice in gcc
source tree directory name. I had chosen "gcc.git" to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93254
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93254
--- Comment #4 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:49e76760a298b735a07e4165d9b8c73946e32287
commit r9-8135-g49e76760a298b735a07e4165d9b8c73946e32287
Author: Uros Bizjak
Date:
H.J. Lu's https://sourceware.org/ml/binutils/2019-11/msg00174.html
assembler patch series added -mbranches-within-32B-boundaries and some
fine-grained tuning options to GNU as, which are considered a pretty
important performance mitigation of a serious CPU bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92590
--- Comment #5 from Pavel Roskin ---
Confirming fix on the original code. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
Bug ID: 93279
Summary: [9 Regression] Template substitution ICE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
On Wed, Jan 15, 2020 at 05:37:11PM +0100, Tobias Burnus wrote:
> Fortran before 2013 only allowed binary-octal-hex values (BOZ literals)
> in DATA statements; Fortran 2013 extended it to support them also as
> argument to INT(), REAL() etc. — Additionally, various compilers
> (including
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
Bug ID: 93278
Summary: huge almost empty array takes huge time to compile and
produces huge object file
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93231
--- Comment #7 from CVS Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:bc071d3a951a98284a3f46043afd44c03c123376
commit r10-5986-gbc071d3a951a98284a3f46043afd44c03c123376
Author: Wilco Dijkstra
Date:
Hi all,
I think would be quite useful for client code to be able to probe for
the libgccjit version.
This patch add three entry points for that: gcc_jit_version_major,
gcc_jit_version_minor, gcc_jit_version_patchlevel.
Does not introduce regressions running make check-jit.
Feedback are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93277
--- Comment #2 from Peter Bergner ---
(In reply to Jonathan Wakely from comment #1)
> I don't see this, could one of your trees be corrupted somehow?
I see this on two different systems using src trees from two separate git
clones (ie, I didn't
On Wed, 15 Jan 2020, Richard Earnshaw (lists) wrote:
> How about separate email list(s) for the vendor and personal spaces? I do
> think changes there should be visible, but perhaps fewer folk will be
> interested in tracking them at the same level.
That's currently documented as a feature not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93277
--- Comment #1 from Jonathan Wakely ---
I don't see this, could one of your trees be corrupted somehow?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85515
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93267
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93277
Bug ID: 93277
Summary: powerpc64*-linux doesn't bootstrap after switch to git
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Tue, 14 Jan 2020, Joseph Myers wrote:
> On Tue, 14 Jan 2020, Jakub Jelinek wrote:
>
> > (untested), another, suggested by Richard on IRC, would be to reject
> > commits where the first line starts with whitespace.
>
> I'd suggest making the hooks reject whitespace at the start of the first
Hi,
when going over stuff linked from the SummerOfCode wiki page, I found
out that doc/install.texi still refers to Subversion. The following
patch replaces SVN to Git almost mechanically. Tested with make info
and make html. OK for trunk?
And then perhaps for the opened release branches too?
On 15/01/2020 15:19, David Malcolm wrote:
Although most of the analyzer work is now on master I'm tracking
additional work in a branch (for future features, work that isn't quite
ready yet, etc).
This used to be "dmalcolm/analyzer" on the git mirror.
The new git server doesn't seem to like
The __iota_diff_t alias can be the type __int128, but that does not
satisfy the signed_integral and __is_signed_integer_like concepts when
__STRICT_ANSI__ is defined (which is true for -std=c++2a).
Because weakly_incrementable is defined in terms of signed_integral, it
is not satisfied by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
Christophe Monat changed:
What|Removed |Added
CC||christophe.monat at st dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93267
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2a0f6c61b4db19535c632be68bddad74b6adb6cf
commit r10-5985-g2a0f6c61b4db19535c632be68bddad74b6adb6cf
Author: Jonathan Wakely
Date:
As discussed on IRC, this adds a couple more checks in the customization
setup for git. If the variables user.name and user.email are not set
anywhere in the git config hierarchy, we set some local values. We
always ask about the values we detect and if the user gives an answer
that is new,
On 1/15/20 11:37 AM, Iain Sandoe wrote:
Joseph Myers wrote:
On Wed, 15 Jan 2020, Jason Merrill wrote:
On 1/15/20 9:56 AM, Joseph Myers wrote:
On Wed, 15 Jan 2020, Jakub Jelinek wrote:
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |markeggleston
Hi Mark,
it is more than just 'X' – also B/O/Z when used as postfix ('AB'Z) are
nonstandard as in general the use outside DATA and a handful of
intrinsic functions. For instance, print *, Z'ABC' is also nonstandard
and affected by -fallow-invalid-boz. (GCC < 10 silently accepted the
On 15/01/2020 16:30, Joseph Myers wrote:
On Wed, 15 Jan 2020, Jason Merrill wrote:
On 1/15/20 9:56 AM, Joseph Myers wrote:
On Wed, 15 Jan 2020, Jakub Jelinek wrote:
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?
I think this is desirable.
Joseph Myers wrote:
> On Wed, 15 Jan 2020, Jason Merrill wrote:
>
>> On 1/15/20 9:56 AM, Joseph Myers wrote:
>>> On Wed, 15 Jan 2020, Jakub Jelinek wrote:
>>>
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?
>>
>> I think this is
On 1/15/20 11:30 AM, Joseph Myers wrote:
On Wed, 15 Jan 2020, Jason Merrill wrote:
On 1/15/20 9:56 AM, Joseph Myers wrote:
On Wed, 15 Jan 2020, Jakub Jelinek wrote:
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?
I think this is desirable.
Fortran before 2013 only allowed binary-octal-hex values (BOZ literals)
in DATA statements; Fortran 2013 extended it to support them also as
argument to INT(), REAL() etc. — Additionally, various compilers
(including gfortran) support more as (legacy) extension.
Diagnostic: DATA vs. non DATA
On Wed, 15 Jan 2020, Jason Merrill wrote:
> On 1/15/20 9:56 AM, Joseph Myers wrote:
> > On Wed, 15 Jan 2020, Jakub Jelinek wrote:
> >
> > > Or, if that is not possible, disable gcc-cvs mail for vendor and private
> > > branches altogether?
>
> I think this is desirable. gcc-cvs should only
On 1/15/20 9:56 AM, Joseph Myers wrote:
On Wed, 15 Jan 2020, Jakub Jelinek wrote:
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?
I think this is desirable. gcc-cvs should only mail about changes to
master and release branches.
Jason
1 - 100 of 223 matches
Mail list logo
