Hi, there!
I am new for using GCC mail list, please forgive me if something is wrong.
I have some issues about how GCC deal with the different optimizations in a
UB program.
For example,
small.cc
*#include unsigned long long a;void b(unsigned long long *c, int
h) { *c = h; }int d =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
--- Comment #5 from Andrew Pinski ---
(In reply to otcmaf from comment #4)
> Do you mean that those pattern above are also wrong pattern ?
YES those are broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
--- Comment #4 from otcmaf ---
(In reply to Andrew Pinski from comment #3)
> The internals documentation documents this even, read:
> https://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html#index-match_005fdup
>
> From that:
> Note that
On Thu, May 21, 2020 at 03:12:21PM -0700, Ian Lance Taylor via Gcc wrote:
> Hi, this unfortunately breaks gccgo development. Significant parts of
> the gccgo sources are simply copied from other repositories. Those
> other repositories do not use ChangeLog files. The git commit hook
> should
On Thu, May 21, 2020 at 03:12:21PM -0700, Ian Lance Taylor via Gcc wrote:
> Hi, this unfortunately breaks gccgo development. Significant parts of
> the gccgo sources are simply copied from other repositories. Those
> other repositories do not use ChangeLog files. The git commit hook
> should
On Thu, May 21, 2020 at 7:18 PM Uros Bizjak wrote:
>
> On Thu, May 21, 2020 at 7:35 AM Hongtao Liu wrote:
> >
> > On Wed, May 20, 2020 at 11:43 PM Uros Bizjak wrote:
> > >
> > > On Wed, May 20, 2020 at 10:35 AM Hongtao Liu wrote:
> > > >
> > > > Hi:
> > > > Bootstrap is ok, regression test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
Max changed:
What|Removed |Added
CC||f.mach4 at gmail dot com
--- Comment #2 from Max
On 2020-05-21, Martin Liška wrote:
On 5/21/20 1:52 AM, Fangrui Song wrote:
The above issues motivated me to touch this line in PATCH v2.
Dropped in PATCH v2.
Thank you for the updated patch.
The patch is fine except coding style issues:
$ ./contrib/check_GNU_style.py
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
--- Comment #3 from CVS Commits ---
The releases/gcc-9 branch has been updated by Bin Cheng :
https://gcc.gnu.org/g:466ad887c9e1cd5a6762e7ec620eef2c8175b50d
commit r9-8614-g466ad887c9e1cd5a6762e7ec620eef2c8175b50d
Author: Bin Cheng
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Bin Cheng :
https://gcc.gnu.org/g:466ad887c9e1cd5a6762e7ec620eef2c8175b50d
commit r9-8614-g466ad887c9e1cd5a6762e7ec620eef2c8175b50d
Author: Bin Cheng
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
--- Comment #2 from otcmaf ---
(In reply to Andrew Pinski from comment #1)
> I think this is a back-end issue.
> Can you provide the definition of movtv8hf16 ?
> I don't think you can do:
> (set (match_operand 0 predicate constraint)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
Bug ID: 95267
Summary: [ICE][gcse]: in process_insert_insn at gcse.c
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Jiufu Guo writes:
> Jan Hubicka writes:
>
>>> Segher Boessenkool writes:
>>>
>>> > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote:
>>> >> I think this is the wrong way to approach this. You're doing too many
>>> >> things at once. Try to fix the powerpc regression with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95257
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95266
Bug ID: 95266
Summary: [11 regression] gcc.dg/vect/bb-slp-pr69907.c fails on
power 7
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
--- Comment #5 from bin cheng ---
(In reply to Richard Biener from comment #1)
> But IVOPTs is supposed to know how to eliminate equal IVs. Maybe it's
> confused
> about the IFN uses?
It's an known issue that IVOPTs has difficulty in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #20 from Rafael Avila de Espindola ---
The attached testcase also fails with just -fsanitize=undefined. I have tested
with gcc version
gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
Rafael Avila de Espindola changed:
What|Removed |Added
Attachment #48547|0 |1
is obsolete|
On May 19, 2020, Richard Biener wrote:
> On Tue, 19 May 2020, Alexandre Oliva wrote:
>> I've refreshed the patch, approved back on Jan 22 for gcc-11, in
>> refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
>> patches on top of it, that I hope to get approved for folding and
This is on top of the stdbool.h and stdint.h patches.
This adds a flag to c_parser so we know when we were trying to
constract a string literal. If there is a parse error and we were
constructing a string literal, and the next token is an unknown
identifier name, and we know there is a standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95265
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Snapshot gcc-8-20200521 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200521/
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95265
Bug ID: 95265
Summary: aarch64: suboptimal code generation for common neon
intrinsic sequence involving shrn and mull
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
On Tue, May 19, 2020 at 2:26 AM Martin Liška wrote:
>
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison of
On Thu, 2020-05-21 at 17:35 +0200, Romain Naour wrote:
> As reported by several Buildroot users [1][2][3], the gcc build
> may fail while running selftests makefile target.
>
> The problem only occurs when ccache is used with gcc 9 and 10,
> probably due to a race condition.
>
> While debuging
On Tue, May 19, 2020 at 2:26 AM Martin Liška wrote:
>
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264
Bug ID: 95264
Summary: Infinite Loop When Compiling Templated C++ code at -O1
and above
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
>
> On 5/15/20 3:22 PM, Marek Polacek wrote:
> > On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> >> On 5/15/20 2:42 PM, Marek Polacek wrote:
> >>> I actually use mklog -i all the time. But I can work around it if it
> >>>
On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
>
> On 5/15/20 3:22 PM, Marek Polacek wrote:
> > On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> >> On 5/15/20 2:42 PM, Marek Polacek wrote:
> >>> I actually use mklog -i all the time. But I can work around it if it
> >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95263
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95263
Martin Liška changed:
What|Removed |Added
Summary|ice in |[11 Regression] ICE in
On 5/21/20 11:01 PM, Jason Merrill wrote:
Why? What is the use of requiring ChangeLog entries at all for these changes?
I must confirm a common test-suite ChangeLog entry is something like:
$ grep ':' gcc/testsuite/ChangeLog | sed 's/.*://' | sort | uniq -c | sort -n |
tac | head -n 15
On 5/21/20 11:01 PM, Jason Merrill wrote:
Why? What is the use of requiring ChangeLog entries at all for these changes?
I must confirm a common test-suite ChangeLog entry is something like:
$ grep ':' gcc/testsuite/ChangeLog | sed 's/.*://' | sort | uniq -c | sort -n |
tac | head -n 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95263
Bug ID: 95263
Summary: ice in lookup_template_class_1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On Thu, May 21, 2020 at 4:27 PM Martin Liška wrote:
> On 5/21/20 9:51 PM, Jason Merrill wrote:
> > Modified. Adjustments to expected errors in testcases don't seem to me
> worth documenting in a ChangeLog.
>
> I see. As Jakub mentioned, I would keep the hook stricter for now.
>
Why? What is
On Thu, May 21, 2020 at 4:27 PM Martin Liška wrote:
> On 5/21/20 9:51 PM, Jason Merrill wrote:
> > Modified. Adjustments to expected errors in testcases don't seem to me
> worth documenting in a ChangeLog.
>
> I see. As Jakub mentioned, I would keep the hook stricter for now.
>
Why? What is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106
--- Comment #2 from anlauf at gcc dot gnu.org ---
Something like
diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
index bf163bc4f52..06313873002 100644
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@
Hi, all.
GCC have a extensive testsuite, that is no news at all. However they are
focused on the compiler (cc1*) or in libraries, and I can't find tests
related to the GCC driver.
Are there tests to the GCC driver? If yes, is there any docs about how
to write them?
Thank you,
Giuliano.
On 5/21/20 9:51 PM, Jason Merrill wrote:
Modified. Adjustments to expected errors in testcases don't seem to me worth
documenting in a ChangeLog.
I see. As Jakub mentioned, I would keep the hook stricter for now.
Martin
On 5/21/20 9:51 PM, Jason Merrill wrote:
Modified. Adjustments to expected errors in testcases don't seem to me worth
documenting in a ChangeLog.
I see. As Jakub mentioned, I would keep the hook stricter for now.
Martin
Hi!
On Thu, May 21, 2020 at 03:29:49PM +0200, Martin Liška wrote:
> Adding Segher to CC, he can help us.
Oh dear. Are you sure?
> On 5/21/20 2:51 PM, Martin Liška wrote:
> >Back to this I noticed that ppc64le target build is broken due to:
> >insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Hello Tony,
On Wed, May 20 2020, y2s1982 . wrote:
> Hello Martin,
> On Mon, May 18, 2020 at 11:32 AM Martin Jambor wrote:
>
>> Hello Tony,
>>
>> sorry for not getting back to you last week. Time seems to fly even
>> faster now that I'm forced to work from home :-/ Furthermore, both me
>> and
On Thu, May 21, 2020 at 2:58 PM Martin Liška wrote:
> On 5/21/20 8:52 PM, Jason Merrill wrote:
> > Was there a decision somewhere to require ChangeLog entries for all
> testcase changes now, as the hook is enforcing? They were optional before.
>
> Right now we ignore newly added test-case,
On Thu, May 21, 2020 at 2:58 PM Martin Liška wrote:
> On 5/21/20 8:52 PM, Jason Merrill wrote:
> > Was there a decision somewhere to require ChangeLog entries for all
> testcase changes now, as the hook is enforcing? They were optional before.
>
> Right now we ignore newly added test-case,
Hi
I got a bit over-zealous in the attempt to make better use of the higher-
level APIs in the c++ FE, this reverts that part of the change,
Tested on x86_64-darwin,
applied to master,
thanks
Iain
co_returns are statements, not expressions; they do not need
to be wrapped in an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79627
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95209
--- Comment #5 from Jonathan Wakely ---
(In reply to M Welinder from comment #4)
> Sorry about the missing "-v". It is indeed a x86_64-suse-linux system.
> (It's not internet facing or I'd go get the full output.)
>
> "Implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95195
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Component|fortran |libfortran
On 5/21/20 8:52 PM, Jason Merrill wrote:
Was there a decision somewhere to require ChangeLog entries for all testcase
changes now, as the hook is enforcing? They were optional before.
Right now we ignore newly added test-case, these don't have to be mentioned.
Can you please attach the patch
On 5/21/20 8:52 PM, Jason Merrill wrote:
Was there a decision somewhere to require ChangeLog entries for all testcase
changes now, as the hook is enforcing? They were optional before.
Right now we ignore newly added test-case, these don't have to be mentioned.
Can you please attach the patch
On Thu, May 21, 2020 at 02:52:37PM -0400, Jason Merrill wrote:
> Was there a decision somewhere to require ChangeLog entries for all
> testcase changes now, as the hook is enforcing? They were optional before.
>
> remote: *** ChangeLog format failed:
> remote: ERR: changed file not mentioned in
On Thu, May 21, 2020 at 02:52:37PM -0400, Jason Merrill wrote:
> Was there a decision somewhere to require ChangeLog entries for all
> testcase changes now, as the hook is enforcing? They were optional before.
>
> remote: *** ChangeLog format failed:
> remote: ERR: changed file not mentioned in
Was there a decision somewhere to require ChangeLog entries for all
testcase changes now, as the hook is enforcing? They were optional before.
remote: *** ChangeLog format failed:
remote: ERR: changed file not mentioned in a
ChangeLog:"gcc/testsuite/g++.dg/parse/error33.C"
On Thu, May 21, 2020
Was there a decision somewhere to require ChangeLog entries for all
testcase changes now, as the hook is enforcing? They were optional before.
remote: *** ChangeLog format failed:
remote: ERR: changed file not mentioned in a
ChangeLog:"gcc/testsuite/g++.dg/parse/error33.C"
On Thu, May 21, 2020
We give a better diagnostic for non-constant array bounds in
compute_array_index_type_loc, we don't need to diagnose it in the parser.
But to avoid a regression on parse/varmod1.C we need to actually check
non-dependent expressions in a template.
Tested x86_64-pc-linux-gnu, applying to trunk.
In a template we were happily embedding error_mark_node in a MODOP_EXPR,
leading to confusion later.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-21 Jason Merrill
* typeck.c (build_x_modify_expr): Handle error_mark_node arguments.
---
gcc/cp/typeck.c
The difference between a "potential" constant-expression and a regular
constant-expression is the treatment of parameters; in a constexpr function,
a parameter is potentially constant when evaluating a call to that function,
but it is not constant during parsing of the function.
If a parameter is erroneous, we currently drop it, leading to "too many
arguments" errors later. Treating the function as (...) avoids those
errors.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-21 Jason Merrill
* decl.c (grokparms): Return NULL_TREE if any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Ah, you are right. Please forget about this patch
mgeneral-regs-only
Target Report RejectNegative Mask(GENERAL_REGS_ONLY) Save
also contains the RejectNegative keyword.
Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95256
Uroš Bizjak changed:
What|Removed |Added
Depends on||95125
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95262
Bug ID: 95262
Summary: Taking address of function pointer do full concept
overload resolution
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95256
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.0
--- Comment #2 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 95229, which changed state.
Bug 95229 Summary: [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95261
Bug ID: 95261
Summary: [11 regression] gcc.target/powerpc/pr80695-p8.c and
gcc.target/powerpc/pr80695-p9.c fail starting with
r11-478
Product: gcc
Version: 11.0
On Thu, 2020-05-21 at 19:31 +0200, Richard Biener via Gcc-patches wrote:
> On May 21, 2020 5:35:19 PM GMT+02:00, Romain Naour via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > As reported by several Buildroot users [1][2][3], the gcc build
> > may fail while running selftests makefile
On Wed, May 20, 2020 at 4:21 AM H.J. Lu wrote:
>
> On Tue, May 19, 2020 at 11:10 PM Uros Bizjak wrote:
> >
> > On Tue, May 19, 2020 at 11:40 PM H.J. Lu wrote:
> >
> > > > > > > > > > I will take a look to see if we share the same CPU
> > > > > > > > > > detection code between
> > > > > > > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:ddfb80adbd91a0e45cc6e04a8b0dbe3ca15ba45f
commit r10-8167-gddfb80adbd91a0e45cc6e04a8b0dbe3ca15ba45f
Author: Uros Bizjak
Hi Martin
> -Original Message-
> From: Martin Liška
> Sent: 21 May 2020 16:01
> To: gcc-patches@gcc.gnu.org
> Cc: Sudakshina Das
> Subject: [PATCH] Fix handling of OPT_mgeneral_regs_only in attribute.
>
> Hi.
>
> Similarly to:
>
> case OPT_mstrict_align:
>if (val)
>
On May 21, 2020 5:35:19 PM GMT+02:00, Romain Naour via Gcc-patches
wrote:
>As reported by several Buildroot users [1][2][3], the gcc build
>may fail while running selftests makefile target.
>
>The problem only occurs when ccache is used with gcc 9 and 10,
>probably due to a race condition.
Just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95244
--- Comment #2 from Patrick J. LoPresti ---
Done (https://github.com/google/sanitizers/issues/1253). Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95209
--- Comment #4 from M Welinder ---
Sorry about the missing "-v". It is indeed a x86_64-suse-linux system. (It's
not internet facing or I'd go get the full output.)
"Implementation defined", yes, but the implementation is the os, not the
On Thu, May 21, 2020 at 9:22 AM Martin Liška wrote:
>
> Hi.
>
> Similarly to:
>
> case OPT_mstrict_align:
>if (val)
> opts->x_target_flags |= MASK_STRICT_ALIGN;
>else
> opts->x_target_flags &= ~MASK_STRICT_ALIGN;
>return true;
>
> the
On 21/05/20 17:46 +0200, Marc Glisse wrote:
On Thu, 21 May 2020, Jonathan Wakely wrote:
On 27/04/20 17:09 +0200, Matthias Kretz wrote:
From: Matthias Kretz
PR libstdc++/84949
* include/std/limits: Let is_iec559 reflect whether
__GCC_IEC_559 says float and double support
On Thu, 21 May 2020, Jonathan Wakely wrote:
On 27/04/20 17:09 +0200, Matthias Kretz wrote:
From: Matthias Kretz
PR libstdc++/84949
* include/std/limits: Let is_iec559 reflect whether
__GCC_IEC_559 says float and double support IEEE 754-2008.
*
Hi Andreas,
git is not doing a plain patch, it is doing a merge. It is not unusual
for a merge to have changes that are already present on both sides.
... which just goes to show that it is very easy to make a fool of
yourself with git if you have no mental model of what it does.
That's not
Hi Martin,
>> two comments:
>>
>> * Can you please avoid the use grey highlighting in that section? Black
>>script on a grey background is already hard to read for someone with
>>reasonable vision. I suspect it will be much harder for
>>vision-impaired people.
>
> You are right, I
Hi Martin,
>> two comments:
>>
>> * Can you please avoid the use grey highlighting in that section? Black
>>script on a grey background is already hard to read for someone with
>>reasonable vision. I suspect it will be much harder for
>>vision-impaired people.
>
> You are right, I
As reported by several Buildroot users [1][2][3], the gcc build
may fail while running selftests makefile target.
The problem only occurs when ccache is used with gcc 9 and 10,
probably due to a race condition.
While debuging with "make -p" we can notice that s-selftest-c target
contain only
On 5/21/20 5:14 PM, Rainer Orth wrote:
Hi Martin,
We've just installed server git hooks that verify git messages
for a correct ChangeLog format. For a limited time period, please
still apply ChangeLog changes to the corresponding ChangeLog files.
We'll use it for comparison of auto-generated
On 5/21/20 5:14 PM, Rainer Orth wrote:
Hi Martin,
We've just installed server git hooks that verify git messages
for a correct ChangeLog format. For a limited time period, please
still apply ChangeLog changes to the corresponding ChangeLog files.
We'll use it for comparison of auto-generated
Hi Martin,
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison of auto-generated CangeLog entries.
>
> The format is
Hi Martin,
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison of auto-generated CangeLog entries.
>
> The format is
Hi Kito,
> Tested and committed with fixes, thanks your review :)
this patch broke SPARC bootstrap:
In file included from ./tm_p.h:4,
from /vol/gcc/src/hg/master/local/gcc/adjust-alignment.c:28:
/vol/gcc/src/hg/master/local/gcc/config/sparc/sparc-protos.h:45:47: error: use
of
Hi.
Similarly to:
case OPT_mstrict_align:
if (val)
opts->x_target_flags |= MASK_STRICT_ALIGN;
else
opts->x_target_flags &= ~MASK_STRICT_ALIGN;
return true;
the MASK_GENERAL_REGS_ONLY mask should be handled the same way.
@Sudakshina: The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95260
--- Comment #4 from H.J. Lu ---
(In reply to Martin Liška from comment #1)
> Just a question: why do you create PRs for all these issues?
> Is it because you want to backport fixes to active branches?
That would be nice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95259
H.J. Lu changed:
What|Removed |Added
Attachment #48576|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95260
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 5/21/20 5:28 AM, Martin Liška wrote:
On 5/18/20 10:37 PM, Martin Sebor wrote:
I know there are some somewhat complex cases the attribute exclusion
mechanism isn't general enough to handle but this seems simple enough
that it should work. Unless I'm missing something that makes it not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95260
--- Comment #2 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a74630f3207d0bec63710c8c803685a0a4956986
commit r11-552-ga74630f3207d0bec63710c8c803685a0a4956986
Author: H.J. Lu
Date: Thu May 21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95260
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1
On 27/04/20 17:09 +0200, Matthias Kretz wrote:
From: Matthias Kretz
PR libstdc++/84949
* include/std/limits: Let is_iec559 reflect whether
__GCC_IEC_559 says float and double support IEEE 754-2008.
* testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559
Since Intel SDM uses hexadecimal, use hexadecimal in comments.
PR target/95260
* config/i386/cpuid.h: Use hexadecimal in comments.
---
gcc/ChangeLog | 5 +
gcc/config/i386/cpuid.h | 6 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git
Martin Liška writes:
> On 5/21/20 12:11 PM, Richard Sandiford wrote:
>> Yeah, agree it'd be worth having tests for both directions. The patch
>> itself looks good though -- thanks for doing this.
>
> Thanks. There's a version with 2 new tests that I've just tested.
>
> I'm going to install the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95260
Bug ID: 95260
Summary: Confusing comments in cpuid.h
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
1 - 100 of 193 matches
Mail list logo
