Segher Boessenkool writes:
> Hi!
>
> On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
>> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
>> relates to max of '-inf' and 'nan'. This regression occur on P9 which has
>> new instruction 'xsmaxcdp/xsmincdp'.
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
--- Comment #4 from Paul ---
That worked. Thank you for the explanation!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31386
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94114
Bug ID: 94114
Summary: [10 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5936
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
--- Comment #2 from Paul ---
Created attachment 48003
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48003=edit
The assembly output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
--- Comment #1 from Paul ---
Created attachment 48002
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48002=edit
The original C file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
Bug ID: 94113
Summary: Apparently incorrect register allocation in inline asm
when using CMOV.
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94098
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Hi,
On 2020/3/9 下午10:32, Segher Boessenkool wrote:
Hi!
On Mon, Mar 09, 2020 at 01:58:01PM +0800, binbin wrote:
2020-03-09 Bin Bin Lv
* config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
builtin_mode_to_type[MAX_MACHINE_MODE][2]): Remove the declaration.
Just
On 2020/3/10 05:28, Segher Boessenkool wrote:
On Thu, Mar 05, 2020 at 02:21:58AM -0600, luo...@linux.ibm.com wrote:
From: Xionghu Luo
Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
No changes were needed?
Yes, no conflicts of the patch and instruction counts are
On 2020-03-10 01:25, Segher Boessenkool wrote:
> On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
>> On 2020-03-09 19:01, Segher Boessenkool wrote:
>>> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
int foo = 0
try
{
On 2020-03-09 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
>> There is also still the question of whether non-volatile asms should be
>> allowed to throw or not. I don't know if that should be discussed here
>> or on the PR.
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94112
Bug ID: 94112
Summary: Please add a warning for potentially throwing code in
noexcept function
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
On Mon, 9 Mar 2020, Christophe Lyon wrote:
> Hi Joseph,
>
> I've noticed that your patch introduces regressions on aarch64:
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve (test for errors, line 33)
> we now get
>
On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
> On 2020-03-09 19:01, Segher Boessenkool wrote:
> > On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> >> int foo = 0
> >> try
> >> {
> >> asm volatile ("..." : "=r" (foo));
> >>
On 3/9/20 5:39 PM, Martin Sebor wrote:
On 3/9/20 1:40 PM, Jason Merrill wrote:
On 3/9/20 12:31 PM, Martin Sebor wrote:
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93870
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92031
Marek Polacek changed:
What|Removed |Added
Summary|[9/10 Regression] Incorrect |[9 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
Marek Polacek changed:
What|Removed |Added
Summary|[9/10 Regression] |[9 Regression] unexpected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068
--- Comment #4 from Marek Polacek ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek
Date: Fri Feb 28 16:57:04 2020 -0500
c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]
The point of
On 3/9/20 7:32 PM, Marek Polacek wrote:
On Mon, Mar 02, 2020 at 05:50:01PM -0500, Jason Merrill wrote:
On 2/29/20 2:32 PM, Marek Polacek wrote:
The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.
On Mon, Mar 02, 2020 at 05:50:01PM -0500, Jason Merrill wrote:
> On 2/29/20 2:32 PM, Marek Polacek wrote:
> > The point of this patch is to fix the recurring problem of trees
> > generated by convert_like while processing a template that break when
> > substituting. For instance, when
The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.
For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin
On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote:
> 6) there used to be a Raw text URL to grab the raw email, now there is nothing
Based on info from #overseers ...
While you can't download the raw text of an individual email now, you
can get the entire month's mail in a compressed archive, from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
Alexander Cherepanov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #3 from Alexander Cherepanov ---
*** Bug 92824 has been marked as a duplicate of this bug. ***
This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend
which controls how deeply we replay errors when diagnosing a constraint
satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which
diagnoses only the topmost constraint satisfaction failure and is
The first patch tries to avoid changing our current default diagnostics. But
for the sake of consistency we arguably should also respect
current_constraint_diagnosis_depth in diagnose_compound_requirement() like we do
in the other error-replaying diagnostic routine. But doing so would be a
Hi all,
second version of the patch for the 200 characters limit for literal
strings addressing comments.
make check-jit is passing clean.
Best Regards
Andrea
gcc/jit/ChangeLog
2020-??-?? Andrea Corallo
* jit-playback.h
(gcc::jit::playback::context m_recording_ctxt):
On Mon, 2020-03-09 at 22:01 +, Joseph Myers wrote:
> On Mon, 9 Mar 2020, Paul Smith wrote:
> > I have a sysroot I've created (downloading RPMs from older systems and
> > unpacking them) which is sufficient to build GCC (and binutils etc.) I
> > need the GCC binaries I create to be compiled
The bug 94085 that I reported at 2020-03-07 06:26 appears to be one of
a half dozen that lost their comments due to the server move. I've
been standing by as instructed, but I wonder when or if corrections
will happen. Will these comments be restored, or should I reconstruct
them?
Also, I
On Mon, 9 Mar 2020 at 19:57, Thomas König wrote:
> As far as the advantages go: A per-thread view is nice, but I don't
> think having it outweighs the disadvantages above.
We always had a threaded view:
https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/threads.html
It just wasn't the default:
Hi!
On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
> The only question I have left now is if my proposed change to the
> documentation is acceptable or should be expanded/reworded.
I think it is fine. It's easier to judge if you look fresh at it, in
my experience, so I might
On Mon, 9 Mar 2020, Paul Smith wrote:
> I have a sysroot I've created (downloading RPMs from older systems and
> unpacking them) which is sufficient to build GCC (and binutils etc.) I
> need the GCC binaries I create to be compiled using this sysroot so
> that they can run on older systems.
>
>
I have a somewhat complex makefile that I've been using for many years
to build GCC: it builds tools needed (make, bison, flex, m4, binutils),
downloads the source prerequisites and links them, etc.
I'd like some advice, hopefully an easy answer, that allows me to
simplify that system, which
Hi,
Please see attached the patches to add -moutline-atomics to the gcc-9 branch.
Tested on graviton2 aarch64-linux with bootstrap and
`make check` passes with no new fails.
Tested `make check` on glibc built with gcc-9 with and without
"-moutline-atomics"
and CFLAGS=" -O2 -g
On 3/9/20 1:40 PM, Jason Merrill wrote:
On 3/9/20 12:31 PM, Martin Sebor wrote:
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #42 from Segher Boessenkool ---
Okay, I see your dumps are 64-bit as well. But mine are very different, huh.
Still, it crashes in pretty much the same way.
On Thu, Mar 05, 2020 at 02:21:58AM -0600, luo...@linux.ibm.com wrote:
> From: Xionghu Luo
>
> Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
No changes were needed?
> Tested pass on P9/P8/P7, ok to commit?
Yes, okay for 9. Thanks!
Segher
> 2020-03-05 Luo
On Mon, 9 Mar 2020, Jakub Jelinek via Overseers wrote:
> 5) emails used to be sanitized against harvesters, now they aren't
The pipermail munging feature was unusably bad (it messed up Texinfo diffs
very badly, including in the mbox version of the archive, e.g. "+@node" at
the start of a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94111
Bug ID: 94111
Summary: Wrong optimization: decimal floating-point infinity
casted to double -> zero
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94067
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 3/6/20 7:57 AM, Jakub Jelinek wrote:
Hi!
Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c
OK. It's unfortunate that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94074
--- Comment #2 from Marek Polacek ---
And this should be diagnosed but isn't:
struct X {
int i;
};
template
struct S {
const X x;
constexpr S(int) : x{}
{
const_cast(x).i = 19; // { dg-error "modifying a const object" }
}
};
On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek wrote:
> On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote:
> > On 3/9/20 9:40 AM, Marek Polacek wrote:
> > > On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> > > > On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > > > >
On 3/5/20 5:26 PM, Jeff Law wrote:
On Fri, 2020-02-14 at 15:41 -0700, Martin Sebor wrote:
Because attribute weakref introduces a kind of a definition, it can
only be applied to declarations of symbols that are not defined. GCC
normally issues a warning when the attribute is applied to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110
Bug ID: 94110
Summary: Erroneous code compiling
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote:
> On 3/9/20 9:40 AM, Marek Polacek wrote:
> > On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
> > > On 3/9/20 8:58 AM, Jakub Jelinek wrote:
> > > > On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
> > > > >
Hi!
On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
> relates to max of '-inf' and 'nan'. This regression occur on P9 which has
> new instruction 'xsmaxcdp/xsmincdp'.
> The similar issue also could be find on
> On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
> >
> > On 3/9/20 4:36 PM, H.J. Lu wrote:
> > > We nee to support different variables, like TLS, data and bss variables.
> >
> > Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
>
> Since you are introducing symbol
Hi,
Some comments.
Generally, I found the old format to be very good for navigating, and I
would like to have the new one match the old one as closely as possible.
1) the by date monthly list of mails used to be ordered newest to oldest
mails first, now it is oldest to newest, so when dealing
On Mon, Mar 09, 2020 at 10:10:31AM -0400, Frank Ch. Eigler via Overseers wrote:
>Hi -
>
>> one more point: The gcc mailing list including this discussion is
>> currently not being archived, the last message is from 2020-03-06.
>
>Found & fixed a permission problem with the mailmnan archives.
Hello,
On Mon, 9 Mar 2020, Martin Liška wrote:
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm.
Of course it does. It's the 'T' (or 't') character. When you introduce
On 3/9/20 12:31 PM, Martin Sebor wrote:
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the
On 3/9/20 9:40 AM, Marek Polacek wrote:
On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
On 3/9/20 8:58 AM, Jakub Jelinek wrote:
On Fri, Mar 06, 2020 at 07:43:43PM -0500, Jason Merrill wrote:
On 3/6/20 6:54 PM, Marek Polacek wrote:
I got a report that building Chromium fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
Bug ID: 94109
Summary: Memory leak introduced in 8.3.0->8.3.1
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94108
Bug ID: 94108
Summary: transaction memory attributes not documented
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
X86 GCC automated testers are back online. They bootstrap and run
testsuite for master
branch and the current 2 release branches on Linux/x86-64 and Linux/i686:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555912.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94106
Martin Sebor changed:
What|Removed |Added
Summary|error on a function |[8/9/10 Regression] error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94107
Bug ID: 94107
Summary: Infinite loop with malformed requires-expression
inside a static_assert
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94106
Bug ID: 94106
Summary: error on a function redeclaration with attribute
transaction_safe
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94105
Bug ID: 94105
Summary: ICE in get_region, at analyzer/region-model.h:1744
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104
Bug ID: 94104
Summary: Request for diagnostic improvement
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
On 2020-03-09 19:01, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
>> I think memory operands are fine - my original concern was about
>> register outputs and SSA form that should reflect the correct def
>> on the EH vs non-EH edge. From a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #41 from Martin Liška ---
Ok, the way how we build our compiler is to use:
./configure --with-cpu=default32
that should also lead to the ICE. I'm checking that.
On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
>
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
Since you are introducing symbol types, why not
... a call to ranges::begin on an input range.
This implements LWG 3286. The new wording for the single-argument
subrange::subrange constructor is implemented by splitting the constructor into
two delegating constructors, one constrained by _S_store_size and the other by
!_S_store_size.
Tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #40 from Martin Liška ---
(In reply to Segher Boessenkool from comment #36)
> > > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > > but that builds stage2 as 64-bit?
> >
> > Hm, that's possible. But the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #39 from Vladimir Makarov ---
I've reverted the patch in trouble:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=5dc1390b41db5c1765e25fd21dad1a930a015aac
Hi!
On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> I think memory operands are fine - my original concern was about
> register outputs and SSA form that should reflect the correct def
> on the EH vs non-EH edge. From a "miscompile" perspective
> doing nothig which means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #38 from Segher Boessenkool ---
Then, how did you do that?
Hi,
There is no single PC offset that is correct given CPUs may use different
offsets.
GCC may also schedule the instruction that stores the PC. This feature used to
work on early Arms but is no longer functional or useful today, so the best way
forward is to remove it altogether. There are many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #37 from Segher Boessenkool ---
Oh wait. I am dumb I guess? You did those dumps with a stage1 compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #36 from Segher Boessenkool ---
> > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > but that builds stage2 as 64-bit?
>
> Hm, that's possible. But the stage2 should not crash right?
It doesn't work, of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922
--- Comment #6 from Jakub Jelinek ---
The problem as I understand it is that
#1 0x00abeb95 in mark_used (decl=, complain=3) at ../../gcc/cp/decl2.c:5686
#2 0x00987243 in build_over_call (cand=0x375c910, flags=35,
complain=3) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #2 from Andrew Pinski ---
long double has padding bits on x86_64 so that is not shocking there.
_Decimal3 is a different issue all together.
On Mon, Mar 09, 2020 at 09:48:01AM -0500, will schmidt wrote:
> On Tue, 2020-02-25 at 12:15 -0600, will schmidt wrote:
> > PR90763: PowerPC vec_xl_len should take const argument.
>
> ping! :-)
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540969.html
Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #1 from Alexander Cherepanov ---
Example with decimal floating-point:
--
#include
#include
int main()
{
_Decimal32 x = 999; // maximum significand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
Bug ID: 94103
Summary: Wrong optimization: reading value of a variable
changes its representation for optimizer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
On Mon, Mar 9, 2020 at 10:26 AM Wilco Dijkstra wrote:
>
> Hi Christophe,
>
> > I noticed a regression introduced by Delia's patch "aarch64: ACLE
> > intrinsics for BFCVTN, BFCVTN2 and BFCVT":
> > (on aarch64-linux-gnu)
> > FAIL: g++.dg/cpp0x/variadic-sizeof4.C -std=c++14 (internal compiler
Hi Christophe,
> I noticed a regression introduced by Delia's patch "aarch64: ACLE
> intrinsics for BFCVTN, BFCVTN2 and BFCVT":
> (on aarch64-linux-gnu)
> FAIL: g++.dg/cpp0x/variadic-sizeof4.C -std=c++14 (internal compiler error)
>
> I couldn't reproduce it with current ToT, until I realized
On 3/9/20 1:07 PM, Jonathan Wakely wrote:
On Mon, 9 Mar 2020 at 16:58, Nathan Sidwell wrote:
On 3/9/20 9:57 AM, Thomas König wrote:
Hi,
I concur with what Jakub wrote. The new web interface is much less useful than
the old one; a severe regression for developers, so to speak.
OMG I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922
--- Comment #5 from Jakub Jelinek ---
Testcase modified to be usable in the testsuite:
// PR c++/93922
// { dg-do link { target c++11 } }
template
struct A {
A () {}
template
A (A const &) {}
~A () {}
};
int t;
struct B {};
struct C :
On Mon, 9 Mar 2020 at 16:58, Nathan Sidwell wrote:
>
> On 3/9/20 9:57 AM, Thomas König wrote:
> > Hi,
> >
> > I concur with what Jakub wrote. The new web interface is much less useful
> > than the old one; a severe regression for developers, so to speak.
>
> OMG I've just looked. It's awful.
On Mär 09 2020, Nathan Sidwell wrote:
> For example https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html
> just gives a list of emails, no dates shown. There's no indication what
> the ordering is -- and apparently it is not most recent first.
Heading says:
Starting: Sun Mar 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #7 from
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
About BSS and DATA I agree that it would be handy. I can theoretically
covered with code in
On 3/9/20 9:57 AM, Thomas König wrote:
Hi,
I concur with what Jakub wrote. The new web interface is much less useful than
the old one; a severe regression for developers, so to speak.
OMG I've just looked. It's awful. Sorry, but No.
For example
From: Andrew Pinski
The problem here is there was a typo in the documentation
for the 'A' modifier in the table, it was recorded as 'a'
in the table on the modifier column.
Committed as obvious.
2020-03-09 Andrew Pinski
PR inline-asm/94095
* doc/extend.texi (x86 Operand
‐‐‐ Original Message ‐‐‐
On Thursday, March 5, 2020 6:59 PM, Segher Boessenkool
wrote:
> On Thu, Mar 05, 2020 at 05:04:16PM +, GT wrote:
>
> > At the top of that file is dejagnu directive:
> > /* { dg-require-effective-target vect_int } */
> >
> > 1. How do I check to see if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file,
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
Hi Bin Bin,
On Mon, Mar 09, 2020 at 09:55:22PM +0800, binbin wrote:
> OK, removed the empty line and showed the changelog. And I found that the
> declaration in rs6000-internal.h should also be removed, right? The
> attachment is the latest patch. Thanks.
> gcc/ChangeLog
>
> 2020-03-09 Bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
--- Comment #1 from Andrew Pinski ---
The problem is just 'a' in the first (Modifier) column is wrong, it should have
been 'A'. I will commit the patch in a few minutes. Operand column is correct
to use 'A'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94101
rosemberg at ymail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
1 - 100 of 216 matches
Mail list logo
