This is a follow up to PR95586 which fixed only the ICE that occurred
when using derived types in an implicit statement. The ICE occurred
because an attempt was made to determine kind for types that do not have
kinds.
This patch ensures that kind is only determined for types that support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97268
Bug ID: 97268
Summary: Segfault on 11.0.0 20200930
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On Thu, 1 Oct 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Re-enable pr94600-{1,3}.c tests for arm ]
>
> On 10/1/20 7:38 AM, Hans-Peter Nilsson wrote:
> > On Wed, 30 Sep 2020, Tom de Vries wrote:
> >> I've analyzed the compilation on strict-alignment target arm-eabi, and
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
--- Comment #6 from Richard Smith ---
My apologies, I misread the testcase. Yes, this is UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96828
--- Comment #2 from Ilya Oleinik ---
Seems like PR85434 caused this issue.
This patch fixes it, however i'm not sure if mov instruction insertion is the
right way of fixing armv6m inability to do a load from hiregs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96828
--- Comment #1 from Ilya Oleinik ---
Created attachment 49296
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49296=edit
patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267
Alan Modra changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267
Bug ID: 97267
Summary: Missed tail calls on ppc64 ELFv2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
On 10/1/20 5:26 AM, Richard Biener wrote:
On Wed, 30 Sep 2020, Jason Merrill wrote:
On 9/28/20 3:09 PM, Jason Merrill wrote:
On 9/28/20 3:56 AM, Richard Biener wrote:
On Fri, 25 Sep 2020, Jason Merrill wrote:
On 9/25/20 2:30 AM, Richard Biener wrote:
On Thu, 24 Sep 2020, Jason Merrill
On Tue, Aug 25, 2020 at 12:39 PM Jim Wilson wrote:
> On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches
> wrote:
> > * config/riscv/riscv.c (asan_shadow_offset): Implement the offset
> > of asan shadow memory for risc-v.
> > (asan_shadow_offset): new macro definition.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69286
Eric Gallager changed:
What|Removed |Added
Keywords||easyhack
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
> > I wonder I can get the branch moved, so I can do the benchmarking :)
> > Any suggestions how to do that?
I just installed a small patch, hot-fix style which I am hoping will
fix your problem. Can you try it? It passes the testsuite, so the change
should be safe.
Let me know how it goes. I
On Thu, Oct 1, 2020 at 8:02 PM Andrew MacLeod wrote:
>
> On 10/1/20 5:30 PM, David Edelsohn wrote:
> >>> * config/rs6000/rs6000-call.c: Include value-range.h.
> >>> * config/rs6000/rs6000.c: Likewise.
> >> This is okay for trunk, thanks! (It is trivial and obvious as well, so
> >> please just
On 10/1/20 5:30 PM, David Edelsohn wrote:
* config/rs6000/rs6000-call.c: Include value-range.h.
* config/rs6000/rs6000.c: Likewise.
This is okay for trunk, thanks! (It is trivial and obvious as well, so
please just commit things like this without prior approval.)
This patch is not the correct
From: Thomas Rodgers
Updated patch incorporating latest feedback.
Add support for -
* atomic_flag::wait/notify_one/notify_all
* atomic::wait/notify_one/notify_all
* counting_semaphore
* binary_semaphore
* latch
libstdc++-v3/ChangeLog:
* include/Makefile.am (bits_headers):
This Go frontend patch set varargs correctly for the type of method
expression. This fixes https://golang.org/issue/41737. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline
and GCC 10 branch.
Ian
8e23cd3a2d23ad851938bf7015fc97539d65a8c6
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
--- Comment #10 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index 99cb4f9dda4..034de497390 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -6333,6 +6333,8 @@ expand_omp_simd (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #4 from m farazma ---
(In reply to Jonathan Wakely from comment #3)
> No, the type is ValidateFlag. It has an underlying type of int8_t, but that
> just means it has the same size and range of values as int8_t. It's not
> actually
On Thu, 24 Sep 2020, Michael Meissner via Gcc-patches wrote:
> To map the math functions, typically this patch changes l to f128.
> However there are some exceptions that are handled with this patch.
glibc 2.32 added __*ieee128 names for the *f128 functions, to allow the
long double functions
On Thu, 24 Sep 2020, Tobias Burnus wrote:
> Hi all,
>
> we got the user comment that it is far from obvious to
> use -foffload=-latomic if the following error shows up:
>
> unresolved symbol __atomic_compare_exchange_16
> collect2: error: ld returned 1 exit status
> mkoffload: fatal error:
Hi!
On Thu, Oct 01, 2020 at 11:03:37PM +0930, Alan Modra wrote:
> during RTL pass: fwprop1
> gcc.dg/pr82596.c: In function 'test_cststring':
> gcc.dg/pr82596.c:27:1: internal compiler error: in decompose, at rtl.h:2282
>
> -m32 gcc/testsuite/gcc.dg/pr82596.c fails along with other tests after
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #3 from Jonathan Wakely ---
No, the type is ValidateFlag. It has an underlying type of int8_t, but that
just means it has the same size and range of values as int8_t. It's not
actually that type.
Snapshot gcc-8-20201001 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20201001/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi Alan,
On Fri, Oct 02, 2020 at 07:06:46AM +0930, Alan Modra wrote:
> > > I was looking at it again today
> > > with the aim of converting this ugly macro to a function, and spotted
> > > the duplication in freebsd64.h. Which has some bit-rot.
> > >
> > > Do you like the following?
No one is interested in the mangled name of the C++20 template parameter
object for a class NTTP. So instead of printing
required for the satisfaction of ‘positive’ [with T =
X<::_ZTAXtl5ratioLin1ELi2EEE>]
let's print
required for the satisfaction of ‘positive’ [with T = X<{-1, 2}>]
I
Hi Segher,
On Thu, Oct 01, 2020 at 01:22:07PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 01, 2020 at 10:57:48PM +0930, Alan Modra wrote:
> > On Wed, Sep 30, 2020 at 03:56:32PM -0500, Segher Boessenkool wrote:
> > > On Wed, Sep 30, 2020 at 05:01:45PM +0930, Alan Modra wrote:
> > > >
> > * config/rs6000/rs6000-call.c: Include value-range.h.
> > * config/rs6000/rs6000.c: Likewise.
>
> This is okay for trunk, thanks! (It is trivial and obvious as well, so
> please just commit things like this without prior approval.)
This patch is not the correct long-term solution, as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97014
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On Thu, Oct 01, 2020 at 08:08:01AM +0200, Richard Biener wrote:
> On Wed, 30 Sep 2020, Segher Boessenkool wrote:
>
> > On Wed, Sep 30, 2020 at 09:02:34AM +0200, Richard Biener wrote:
> > > On Tue, 29 Sep 2020, Segher Boessenkool wrote:
> > > > I don't see much about optabs in the docs either.
There are only a couple of asserts remaining using this macro, and
nothing using TYPE_HIDDEN_P. Killed thusly.
gcc/cp/
* cp-tree.h (DECL_ANTICIPATED): Adjust comment.
(DECL_HIDDEN_P, TYPE_HIDDEN_P): Delete.
* tree.c (ovl_insert): Delete DECL_HIDDEN_P assert.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80845
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi,
When running:
...
$ gcc.sh src/gcc/testsuite/gcc.target/nvptx/abi-complex-arg.c -S -dP
...
we have in abi-complex-arg.s:
...
//(insn 3 5 4 2
// (set
//(reg:QI 23)
//(truncate:QI (reg:SI 22))) "abi-complex-arg.c":38:1 29 {truncsiqi2}
// (nil))
cvt.u32.u32 %r23,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80845
--- Comment #5 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:b3ec0de08250d7e0599e36895d5cb727016c81d3
commit r11-3601-gb3ec0de08250d7e0599e36895d5cb727016c81d3
Author: Tom de Vries
Date: Thu
On Thu, Oct 01, 2020 at 08:59:12PM +0200, Martin Liška wrote:
> Since a889e06ac68 the following fails.
>
> In file included from ../../gcc/tree-ssa-propagate.h:25:0,
> from ../../gcc/config/rs6000/rs6000.c:78:
> ../../gcc/value-query.h:90:31: error: ‘irange’ has not been declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
--- Comment #17 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:84dc3879f377ddaecb4054a7bf7671114dfb7228
commit r10-8840-g84dc3879f377ddaecb4054a7bf7671114dfb7228
Author: Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96979
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:b62c649466f3ae029bf348027ece9530f79d3ce1
commit r10-8839-gb62c649466f3ae029bf348027ece9530f79d3ce1
Author: Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97069
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:bc3914f307211c42f31af7e64d2e6cc8a69837cb
commit r10-8838-gbc3914f307211c42f31af7e64d2e6cc8a69837cb
Author: Martin Liska
I'm going to install the following 3 tested backports.
Martin
>From 0d91a9613ca1c4b8b11d668a1b8e1a6a37c41b7a Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 25 Sep 2020 16:21:34 +0200
Subject: [PATCH 3/3] gcov: fix streaming of HIST_TYPE_IOR histogram type.
gcc/ChangeLog:
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #2 from m farazma ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to m farazma from comment #0)
> > ```
> > #include
> >
> > enum ValidateFlag : int8_t {
> >a = 0, b , c
> > };
> >
> > int main(){
> > bool t =
The latest irange patch has broken bootstrap for PowerPC
In file included from /nasfarm/edelsohn/src/src/gcc/tree-ssa-propagate.h:25:0,
from
/nasfarm/edelsohn/src/src/gcc/config/rs6000/rs6000-call.c:67:
/nasfarm/edelsohn/src/src/gcc/value-query.h:90:31: error: 'irange' has
not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #1 from Jonathan Wakely ---
(In reply to m farazma from comment #0)
> ```
> #include
>
> enum ValidateFlag : int8_t {
>a = 0, b , c
> };
>
> int main(){
> bool t = static_cast(c);
> return static_cast(t);
> }
> ```
>
>
Since a889e06ac68 the following fails.
In file included from ../../gcc/tree-ssa-propagate.h:25:0,
from ../../gcc/config/rs6000/rs6000.c:78:
../../gcc/value-query.h:90:31: error: ‘irange’ has not been declared
virtual bool range_of_expr (irange , tree name, gimple * = NULL) =
> I wonder I can get the branch moved, so I can do the benchmarking :)
> Any suggestions how to do that?
Unfortunately, I think the only way (sort of adding the suggested
workaround in the commit-extra-checker script), is to update
the branch directly in the bare repository on sourceware.org.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #19 from Martin Liška ---
(In reply to Martin Jambor from comment #18)
> I proposed the patch on the mailing list (I guess I should put Martin's name
> at least to the testsuite ChangeLog and probably to both):
>
Don't worry about
Hi!
On Thu, Oct 01, 2020 at 10:57:48PM +0930, Alan Modra wrote:
> On Wed, Sep 30, 2020 at 03:56:32PM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 30, 2020 at 05:01:45PM +0930, Alan Modra wrote:
> > > * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't
> > > set -mcmodel=small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
Bug ID: 97266
Summary: "enum constant in boolean context" warning seems
incorrect
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673
Martin Sebor changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
On Thu, 1 Oct 2020 at 18:38, Joseph Myers wrote:
>
> On Thu, 1 Oct 2020, Jonathan Wakely via Gcc wrote:
>
> > The problem is that the script doesn't check whether the new_object is
> > 0.
> >
> > I think we want something like this:
> >
> > --- update_hook 2020-09-02 23:30:25.074884982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554
Marco Trevisan changed:
What|Removed |Added
CC||mail at 3v1n0 dot net
--- Comment #5
Sorry for the slow review.
HAO CHEN GUI via Gcc-patches writes:
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index 513fc5fe295..6f5bf8d7d73 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -9315,10 +9315,10 @@ mips_select_rtx_section (machine_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #18 from Martin Jambor ---
I proposed the patch on the mailing list (I guess I should put Martin's name at
least to the testsuite ChangeLog and probably to both):
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555284.html
On Thu, 1 Oct 2020, Jonathan Wakely via Gcc wrote:
> The problem is that the script doesn't check whether the new_object is
> 0.
>
> I think we want something like this:
>
> --- update_hook 2020-09-02 23:30:25.074884982 +
> +++ /tmp/update_hook2020-10-01 13:57:14.681656258 +
Hi,
as the FIXME which this patch removes states, the current code does
not work when a call with multiple speculative targets gets resolved
through parameter tracking during inlining - it feeds the inliner an
edge it has already dealt with. The patch makes the code which should
prevent it aware
On 10/1/20 7:35 AM, Alejandro Colomar via Libc-alpha wrote:
+The narrowest signed integer type
+of a width of at least N bits,
Motivation is missing here. Why is there an int_leastN_t type at all? Also, on
all glibc platforms, int_leastN_t is equivalent to intN_t; this should probably
be
If you're going to document this at all, I suggest documenting 'void' as well as
'void *', and putting both sets of documentation into the same man page.
For 'void *' you should also mention that one cannot use arithmetic on void *
pointers, so they're special in that way too. Also, you should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment
On Thu, 1 Oct 2020, Alejandro Colomar via Gcc wrote:
> Because 'intmax_t' has a bug
> (actually I know GCC rejected the bug report,
> but the problem is still there and users should be informed about this)
> which is related to __int128.
__int128 is not an integer type as defined by any existing
On 10/1/20 9:34 AM, Aldy Hernandez wrote:
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Thanks for doing all this! There isn't anything I don't understand
>>> in the sprintf changes so no questions from me (well, almost none).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97014
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97230
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Marek Polacek
This PR points out that when we're invoking a non-static member function
on a null instance during constant evaluation, we should reject.
cxx_eval_call_expression calls cxx_bind_parameters_in_call which
evaluates function arguments, but it won't detect problems like these.
Well, ok, so use
On Wed, Sep 30, 2020 at 11:35 PM Richard Biener
wrote:
> On Wed, Sep 30, 2020 at 10:01 PM Jim Wilson wrote:
> > We have a lot of examples in gcc/testsuite/gcc.target/riscv/rvv that
> > we are using for testing the vector support.
>
> That doesn't seem to exist (but maybe it's just not on trunk
On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote:
Hi Alex,
+According to the C language standard,
+a pointer to any object type may be converted to a pointer to
+.I void
+and back.
+POSIX further requires that any pointer,
+including pointers to functions,
+may be converted to a
Christophe Lyon writes:
> On Wed, 30 Sep 2020 at 12:53, Richard Sandiford via Gcc-patches
> wrote:
>>
>> movti lacked an way of zeroing an FPR, meaning that we'd do:
>>
>> mov x0, 0
>> mov x1, 0
>> fmovd0, x0
>> fmovv0.d[1], x1
>>
>> instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96519
Thomas Schwinge changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |kcy at codesourcery dot
com
Hi Alex,
> +According to the C language standard,
> +a pointer to any object type may be converted to a pointer to
> +.I void
> +and back.
> +POSIX further requires that any pointer,
> +including pointers to functions,
> +may be converted to a pointer to
> +.I void
> +and back.
I know you are
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 40
1 file changed, 40 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e545aa1a0..5f9aa648f 100644
--- a/man7/system_data_types.7
+++
Signed-off-by: Alejandro Colomar
---
man3/__int128.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/__int128.3
diff --git a/man3/__int128.3 b/man3/__int128.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/__int128.3
@@ -0,0 +1 @@
+.so
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 35 +++
1 file changed, 35 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 5f9aa648f..3cf3f0ec9 100644
--- a/man7/system_data_types.7
+++
Hi Michael,
I think this might be ready for a patch.
I'm done for today :-)
Cheers,
Alex
Alejandro Colomar (4):
system_data_types.7: Add '__int128'
__int128.3: New link to system_data_types(7)
system_data_types.7: Add 'unsigned __int128'
unsigned-__int128.3: New link to
Signed-off-by: Alejandro Colomar
---
man3/unsigned-__int128.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/unsigned-__int128.3
diff --git a/man3/unsigned-__int128.3 b/man3/unsigned-__int128.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++
Hi all,
I'd like to add a prefer_advsimd_autovec internal tune_flag that makes GCC pick
Advanced SIMD over SVE for autovectorisation.
No CPU tuning uses it yet, but I'd like to add this to the GCC 8 and 9 branches
only as SVE autovectorisation is less mature there and CPUs
may want to prefer
On 01/10/2020 18.04, Olivier Hainque wrote:
> Hello,
>
> This patch is a proposal to add an if-exists-then-else
> builtin spec function, which tests for the existence of
> a file and returns one or the other of the following
> arguments depending on the result of the test.
>
Hello,
could you
Qing Zhao writes:
> Hi, Richard,
>
> To answer the question, which registers should be included in “ALL”.
> I studied X86 hard register set in more details. And also consulted with
> H.J.Lu, And found:
>
> In the current x86 implementation, mask registers, MM0-MM7 registers, and
> ST0-ST7
Alex Coplan writes:
> Hi Christophe,
>
> On 08/09/2020 10:14, Christophe Lyon wrote:
>> On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote:
>> >
>> > gcc/ChangeLog:
>> >
>> > * config/aarch64/aarch64.md
>> > (*adds__): Ensure extended operand
>> > agrees with width of
Hello,
This patch is a proposal to add an if-exists-then-else
builtin spec function, which tests for the existence of
a file and returns one or the other of the following
arguments depending on the result of the test.
This differs from the existing if-exists or
if-exists-else function which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97260
--- Comment #4 from Martin Sebor ---
It should be possible to handle in the strlen pass.
I added a paragraph about not being able to dereference a void *,
and changed the link page, which was very weird.
Alejandro Colomar (2):
system_data_types.7: Add 'void *'
void.3: New link to system_data_types(7)
man3/void.3 | 1 +
man7/system_data_types.7 | 47
Signed-off-by: Alejandro Colomar
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 47 ++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e42cf2557..e545aa1a0 100644
--- a/man7/system_data_types.7
+++
Hi Michael,
On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote:
Hello Alex,
On 10/1/20 5:06 PM, Alejandro Colomar wrote:
Hello Michael,
This type is very special,
so I will probably have missed some details about it.
I do wonder if we actually need this in page at all, and given:
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #5 from Martin Sebor ---
I'm not at all familiar with this part of GCC so I'm not sure what needs to be
done here. It seems to me that the streamer is missing support for certain
trees under some conditions. It knows how to stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #4 from Martin Sebor ---
*** Bug 97133 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97133
Martin Sebor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
Kyrylo Tkachov writes:
>> -Original Message-
>> From: Andrea Corallo
>> Sent: 01 October 2020 15:36
>> To: gcc-patches@gcc.gnu.org
>> Cc: Richard Earnshaw ; Kyrylo Tkachov
>> ; Christophe Lyon
>> Subject: Re: [PATCH PR96375] arm: Fix testcase selection for Low Overhead
>> Loop tests
>>
Hello Alex,
On 10/1/20 5:06 PM, Alejandro Colomar wrote:
> Hello Michael,
>
> This type is very special,
> so I will probably have missed some details about it.
I do wonder if we actually need this in page at all, and given:
> Also, do you like the link name?
I really don't like it... I don't
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Thanks for doing all this! There isn't anything I don't understand
>>> in the sprintf changes so no questions from me (well, almost none).
>>> Just some comments:
>> Thanks for your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96375
--- Comment #6 from CVS Commits ---
The master branch has been updated by Andrea Corallo :
https://gcc.gnu.org/g:968ec08efefeea6fbc0cdc379e98ce3e28904083
commit r11-3598-g968ec08efefeea6fbc0cdc379e98ce3e28904083
Author: Andrea Corallo
Date:
Thanks, Alex. Applied.
On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 75
> 1 file changed, 75 insertions(+)
>
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index
Thanks, Alex. Applied.
On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man3/uint_least16_t.3 | 1 +
> man3/uint_least32_t.3 | 1 +
> man3/uint_least64_t.3 | 1 +
> man3/uint_least8_t.3 | 1 +
> man3/uint_leastN_t.3 | 1 +
> 5 files changed, 5
Thanks, Alex. Applied.
On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man3/int_least16_t.3 | 1 +
> man3/int_least32_t.3 | 1 +
> man3/int_least64_t.3 | 1 +
> man3/int_least8_t.3 | 1 +
> man3/int_leastN_t.3 | 1 +
> 5 files changed, 5 insertions(+)
>
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man3/int_fast16_t.3 | 1 +
> man3/int_fast32_t.3 | 1 +
> man3/int_fast64_t.3 | 1 +
> man3/int_fast8_t.3 | 1 +
> man3/int_fastN_t.3 | 1 +
> 5 files changed, 5 insertions(+)
>
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man3/uint_fast16_t.3 | 1 +
> man3/uint_fast32_t.3 | 1 +
> man3/uint_fast64_t.3 | 1 +
> man3/uint_fast8_t.3 | 1 +
> man3/uint_fastN_t.3 | 1 +
> 5 files changed, 5 insertions(+)
>
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 80
> 1 file changed, 80 insertions(+)
>
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index
Hi, Richard,
To answer the question, which registers should be included in “ALL”.
I studied X86 hard register set in more details. And also consulted with
H.J.Lu, And found:
In the current x86 implementation, mask registers, MM0-MM7 registers, and
ST0-ST7 registers are not zeroed.
The
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 77
> 1 file changed, 77 insertions(+)
>
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97261
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
On 2020-10-01 13:07, Jonathan Wakely wrote:
I don't see anything in this man page saying that the types
are all typedefs, rather than new types that are distinct from the
standard integer types. That seems like useful information.
Hello Jonathan,
I almost missed this.
We (Michael and
1 - 100 of 258 matches
Mail list logo
