gcc/ChangeLog:
* config.gcc (riscv*-*-*): Drop some commited accidentally code.
---
gcc/config.gcc | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index c348596b1ac..4808b698f3a 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4615,7 +4615,6 @@ case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #17 from Richard Biener ---
Well - you're the first to add nontrivial (non-constant) trees to attributes.
In GIMPLE all effects are supposed to be reflected in the IL and thus things
like
variable TYPE_SIZE or TYPE_MIN/MAX_VALUE are
Let me know if I need to reference a specific paper or any other
Standard reference here. Maybe P1690R1 I used here ?
I tried to allow the same partition trick you can have on ordered
containers (see Partition in tests) even if here elements are not
ordered so I aren't sure there can be any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98077
Bug ID: 98077
Summary: C++ 17: Using alias template bug in gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
Bug ID: 98076
Summary: Increase speed of integer I/O
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
On 11/30/20 7:00 PM, Eugene Rozenfeld wrote:
> Thank you for the review Jeff.
>
> I don't need to look at the opcode to know the result. The pattern will be
> matched only in these 4 cases:
>
> X <= MAX(X, Y) -> true
> X > MAX(X, Y) -> false
> X >= MIN(X, Y) -> true
> X < MIN(X, Y) -> false
>
Hi:
There're many pairs of define_insn/define_expand that are very similar
to each other except mode iterator and condition. For these patterns
VI12_AVX512VL are used under condition TARGET_AVX512BW, and
VI48_AVX512VL are used under condition TARGET_AVX512F.
This patch is about to introduce a new
On Mon, Nov 30, 2020 at 9:46 PM Jakub Jelinek wrote:
>
> On Mon, Nov 30, 2020 at 09:11:10PM +0800, Hongtao Liu wrote:
> > +;; PR96906 - optimize vpsubusw compared to 0 into vpcmpleuw or vpcmpnltuw.
> > +(define_split
> > + [(set (match_operand: 0 "register_operand")
> > +(unspec:
> > +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94932
--- Comment #3 from Arseny Solokha ---
I cannot reproduce it anymore w/ gcc-11.0.0-alpha20201129 snapshot
(g:bb67ad5cff58a707aaae645d4f45a913d8511c86). gcc 10 and 11 now accept this
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97575
--- Comment #3 from Arseny Solokha ---
I cannot reproduce it anymore w/ gcc-11.0.0-alpha20201129 snapshot
(g:bb67ad5cff58a707aaae645d4f45a913d8511c86).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96177
--- Comment #1 from Arseny Solokha ---
I cannot reproduce it anymore w/ gcc-11.0.0-alpha20201129 snapshot
(g:bb67ad5cff58a707aaae645d4f45a913d8511c86).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98075
Bug ID: 98075
Summary: [10/11 Regression] ICE: verify_cgraph_node failed
(error: malloc attribute should be used for a function
that returns a pointer)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98074
Bug ID: 98074
Summary: [9/10 Regression] C Wrong code at O2~Os
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #46 from Levy ---
Looking at gcc/passed.def and gcc/config/riscv-passes.def:
pass_shorten_memrefs is inserted after NEXT_PASS (pass_rtl_store_motion);
NEXT_PASS (pass_rtl_store_motion);
(pass_shorten_memrefs)
NEXT_PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97975
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97975
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98073
Bug ID: 98073
Summary: error: in can_merge_p, at analyzer/region-model.cc
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98072
Bug ID: 98072
Summary: [11 Regression] ICE in cp_parser_omp_var_list_no_open,
at cp/parser.c:34843
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
Hi Bill,
On Mon, Nov 30, 2020 at 10:22:34PM +, Bill Messmer wrote:
> I'm still a bit confused here. And the reason I ask this is because
> I open this particular vmlinux image with an OSS ELF/DWARF
> library... which gives me the *WRONG* names for various DWARF DIEs.
> I stepped through
Thank you for the review Jeff.
I don't need to look at the opcode to know the result. The pattern will be
matched only in these 4 cases:
X <= MAX(X, Y) -> true
X > MAX(X, Y) -> false
X >= MIN(X, Y) -> true
X < MIN(X, Y) -> false
So, the result will be true for GE_EXPR and LE_EXPR and false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98066
--- Comment #8 from luoxhu at gcc dot gnu.org ---
Thanks for the quick fix!
> OK. Presumably once this is applied Richi is going to look at the
> higher level issues in the vectorizer which inhibit creating the HI/QI
> vector popcounts?
>
Yes, this is the prerequisite to look at the vectorization issue. I'll
ask Hongtao to
help check-in this patch. Thanks for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #16 from Martin Sebor ---
The ICE in pr97133 mentions BIND_EXPR. It's still there, even after unsharing:
$ gcc -O2 -S -flto -shared -fPIC /src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c
during IPA pass: modref
From: David Blaikie
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
On 11/30/20 1:49 PM, Jeff Law wrote:
On 11/29/20 3:27 PM, Martin Sebor wrote:
On 11/13/20 2:34 PM, Jeff Law wrote:
On 11/2/20 7:24 PM, Martin Sebor wrote:
The attached patch extends compute_objsize() to handle conditional
expressions represented either as PHIs or MIN_EXPR and MAX_EXPR.
To
Hello,
On Mon, 30 Nov 2020, Jeff Law wrote:
> >> So, then let's start with one of
> >> the prime examples of SSA deconstruction problems, the lost swap, and how
> >> it comes to be: we start with a swap:
> >>
> >> x = ..., y = ...
> >> if (cond)
> >> tmp=x, x=y, y=tmp
> >>
> >> (1)
Hi!
Thank you for all this.
On Wed, Nov 11, 2020 at 09:50:01PM +, Jonathan Wakely wrote:
> This adds support for the new __ieee128 long double format on
> powerpc64le targets.
> * testsuite/27_numerics/complex/abi_tag.cc: Add u9___ieee128 to
> regex matching expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #27 from abebeos at lazaridis dot com ---
The "contrib/compare_tests" created a wrong delta.
"contrib/dg-cmp-results.sh seems to produce a more concise delta, and it shows
that...
==> ...we are down to essentially 6 issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98070
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On Nov 30, 2020, at 11:18 AM, Martin Sebor wrote:
Does gcc provide an iterator to traverse all the local variables that
are declared in the current routine?
If not, what’s the best way to traverse the local variables?
>>>
>>> Depends on what for.
On 11/13/20 2:45 PM, Martin Sebor via Gcc-patches wrote:
> Bug 94527 is request from the kernel developers for an attribute
> to indicate that a user-defined function deallocates an object
> allocated by an earlier call to an allocation function. Their
> goal is to detect misuses of such
On 11/30/20 3:39 PM, David Malcolm wrote:
> On Mon, 2020-11-30 at 16:19 -0500, David Malcolm wrote:
>> I broke the build with --disable-analyzer with
>> g:66dde7bc64b75d4a338266333c9c490b12d49825, due to:
>>
>> ../../src/gcc/analyzer/analyzer-pass.cc: In member function 'virtual
>> unsigned int
On Mon, 2020-11-30 at 16:19 -0500, David Malcolm wrote:
> I broke the build with --disable-analyzer with
> g:66dde7bc64b75d4a338266333c9c490b12d49825, due to:
>
> ../../src/gcc/analyzer/analyzer-pass.cc: In member function 'virtual
> unsigned int {anonymous}::pass_analyzer::execute(function*)':
>
New +flagm (Condition flag manipulation from Armv8.4-A) feature option for
-march command line option.
Please note that FLAGM stays an Armv8.4-A feature but now can be
assigned to other architectures or CPUs.
OK for master?
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def
On 11/27/20 8:26 AM, Jan Hubicka wrote:
On Wed, Nov 25, 2020 at 3:11 PM Jan Hubicka wrote:
On Tue, 24 Nov 2020, Jan Hubicka wrote:
Hi,
at the end of processing function body we loop over basic blocks and
free all edges while we do not free the rest. I think this is leftover
from time eges
On 11/30/20 5:16 AM, Martin Liška wrote:
> On 11/13/19 7:29 AM, Strager Neds wrote:
>> -/* Worker for set_section. */
>> +void
>> +symtab_node::set_section_for_node (const symtab_node )
>> +{
>> + if (x_section == other.x_section)
>> + return;
>> + if (get_section () && other.get_section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98003
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-30
Mark,
Much appreciate the response.
I'm still a bit confused here. And the reason I ask this is because I open
this particular vmlinux image with an OSS ELF/DWARF library... which gives me
the *WRONG* names for various DWARF DIEs. I stepped through the library...
and the reason the names
On 11/30/20 1:29 PM, Jeff Law wrote:
On 11/17/20 7:09 PM, Martin Sebor wrote:
On 11/16/20 4:54 PM, Jeff Law wrote:
On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
wrote:
GCC considers PTRDIFF_MAX - 1 to be the size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98003
--- Comment #1 from John David Anglin ---
spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055
--- Comment #5 from Paul Smith ---
IMO that response is missing the point. This bug should be reopened and
resolved by removing this attribute from the __builtin_alloca function in GCC.
That's all that's needed: there's no need for more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #29 from seurer at gcc dot gnu.org ---
Still showing up on powerpc64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98023
--- Comment #3 from anlauf at gcc dot gnu.org ---
The patch in comment#1 does not work for me on x86_64-pc-linux-gnu.
In decl.c:
6242cleanup:
6243 if (saved_kind_expr)
6244gfc_free_expr (saved_kind_expr);
6245 if
Jonathan, could you send a fresh set of patches (or at least replacements)? I
tried installing the patches on a master branch I checked out this morning, and
I got two rejects:
--- libstdc++-v3/testsuite/util/testsuite_abi.cc
+++ libstdc++-v3/testsuite/util/testsuite_abi.cc
@@ -207,6 +207,7 @@
I broke the build with --disable-analyzer with
g:66dde7bc64b75d4a338266333c9c490b12d49825, due to:
../../src/gcc/analyzer/analyzer-pass.cc: In member function 'virtual unsigned
int {anonymous}::pass_analyzer::execute(function*)':
../../src/gcc/analyzer/analyzer-pass.cc:86:3: error:
On 11/27/20 9:31 AM, Richard Sandiford via Gcc-patches wrote:
> Michael Matz writes:
>> Hello,
>>
>> On Thu, 26 Nov 2020, Richard Sandiford via Gcc-patches wrote:
>>
> The aim is only to provide a different view of existing RTL instructions.
> Unlike gimple, and unlike (IIRC) the old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #9 from seurer at gcc dot gnu.org ---
I saw
FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c (test for bogus messages, line 170)
on a make check for 66dde7bc64b75d4a338266333c9c490b12d49825, r11-5583 just
moments ago on a powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #15 from Jan Hubicka ---
> I'm not sure I understand correctly what you mean by "avoiding the attribute
> for VLA types would likely also be good (are those handled in any reasonable
> way?)" As I explain in the thread at the link
On 11/27/20 6:08 PM, Iain Sandoe wrote:
Jason Merrill wrote:
On Mon, Nov 23, 2020 at 8:52 AM Iain Sandoe wrote:
Jason Merrill wrote:
(NOTE: likewise, ^~~ starting indent is below ‘int’ for a fixed spacing
font)
===
I’m inclined to think that the second is more useful,
but have
On 11/30/20 3:08 PM, Bernd Edlinger wrote:
Hi,
I'd like to ping for this patch:
I reviewed it on the 24th:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560118.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559882.html
Thanks
Bernd.
On 11/22/20 9:05 AM, Bernd
On 11/30/20 9:26 AM, Jakub Jelinek wrote:
> On Mon, Nov 30, 2020 at 09:23:15AM -0700, Jeff Law wrote:
>>
>> On 11/12/20 11:21 PM, Hongyu Wang wrote:
>>> Hi
>>>
>>> Thanks for reminding me about this patch. I didn't remove any existing
>>> intrinsics, just remove redundant builtin functions that
Hi!
On Mon, Nov 30, 2020 at 06:36:30PM +0800, Kewen.Lin wrote:
> --- a/gcc/config/rs6000/rs6000-cpus.def
> +++ b/gcc/config/rs6000/rs6000-cpus.def
> @@ -51,7 +51,6 @@
>| OPTION_MASK_CRYPTO \
>|
Hi, Jeff,
Sorry for the late reply due to thanksgiving long weekend.
> On Nov 25, 2020, at 1:37 PM, Jeff Law wrote:
>
>
>
> On 11/19/20 8:59 AM, Qing Zhao via Gcc-patches wrote:
>> Hi,
>>
>> PR9 - ICE: in df_refs_verify, at df-scan.c:3991 with -O
>> -ffinite-math-only
On 11/29/20 3:27 PM, Martin Sebor wrote:
> On 11/13/20 2:34 PM, Jeff Law wrote:
>>
>> On 11/2/20 7:24 PM, Martin Sebor wrote:
>>> The attached patch extends compute_objsize() to handle conditional
>>> expressions represented either as PHIs or MIN_EXPR and MAX_EXPR.
>>>
>>> To simplify the
On 11/30/20 5:48 AM, Martin Liška wrote:
> As mentioned in the PR, since 4656461585bfd0b9 implicit_section
> was not set to false when set_section was called with the argument
> equal to NULL.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
On 11/30/20 8:11 AM, Maciej W. Rozycki wrote:
> Fix a testsuite failure:
>
> /tmp/ccL65Mmt.s: Assembler messages:
> /tmp/ccL65Mmt.s:36: Warning: Symbol n used as immediate operand in PIC mode.
> FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto
> -flto-partition=none
On 11/17/20 7:09 PM, Martin Sebor wrote:
> On 11/16/20 4:54 PM, Jeff Law wrote:
>>
>> On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
>>> On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
>>> wrote:
GCC considers PTRDIFF_MAX - 1 to be the size of the largest object
On Mon, Nov 30, 2020 at 07:35:36PM +, Alexander Yermolovich via Gcc wrote:
> I guess discussion is from perspective of having both flags
> gdwarf32/gdwarf64. In which case it's a valid question on whether
> they should imply -g like -gdwarf-#. But can this be viewed as only
> a -gdwarf64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98041
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
This libgo patch changes the internal/cpu package to not define
CacheLinePadSize for mips64x. For libgo the definition always comes
from the generated file cpugen.go. This fixes GCC PR 98041.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98041
--- Comment #1 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:eafb46ce90c23efd22c61d941face060bb9f11f3
commit r11-5591-geafb46ce90c23efd22c61d941face060bb9f11f3
Author: Ian Lance Taylor
This patch to the Go frontend and runtime checks both len and cap when
handling the case of append(s, make(T, I)...). The overflow checks
done in growslice always reported an error for the capacity argument,
even if it was the length argument that overflowed. This change lets
the code pass the
This libgo patch defines SO_RCVTIMEO on 32-bit GNU/Linux. It was not
being defined before because it is defined as a conditional expression
that is too complicated for -fdump-go-spec to handle. This fixes
https://golang.org/issue/42872. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.
Hi Bill,
On Mon, Nov 30, 2020 at 07:18:50PM +, Bill Messmer via Gcc wrote:
> I am trying to understand something unexpected I am seeing in the relocations
> placed into a compiled Linux kernel for the .debug_info section. Those
> relocations seem to change the names of various entries in
This Go frontend patch improves the error messages for an expected
curly brace. This is for https://golang.org/issue/17328. This
requires updating some tests to the current sources in the main repo.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
This patch to the Go frontend uses the use correct assignment order
for type assertions. For "a, b := v.(T)" we must set a before b.
This is for https://golang.org/issue/13433. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich
wrote:
> Thank you David for driving the conversation, sorry I was on vacation.
>
All good - really appreciate everyone chipping in whenever/however they can!
>
> I guess discussion is from perspective of having both flags
>
On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich wrote:
>
> Thank you David for driving the conversation, sorry I was on vacation.
>
> I guess discussion is from perspective of having both flags
> gdwarf32/gdwarf64. In which case it's a valid question on whether they should
> imply -g
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559882.html
Thanks
Bernd.
On 11/22/20 9:05 AM, Bernd Edlinger wrote:
> Hi,
>
> this avoids the need to use -fno-threadsafe-statics on
> arm-none-eabi or working around that problem by supplying
> a
This patch changes the Go frontend to always use a context that
expects an int type when determining the type of an index value. This
is for https://golang.org/issue/14844. This requires updating one of
the tests in the testsuite to the source version. Bootstrapped and
ran Go testsuite on
This patch to the Go frontend generates better error messages for a
missing interface method. This is for https://golang.org/issue/10700.
This requires updating one test to the one in the source repo.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
On 11/13/20 1:19 AM, Richard Sandiford via Gcc-patches wrote:
> A later patch wants to be able to use the validate_change machinery
> to reduce the XVECLEN of a PARALLEL. This should be more efficient
> than allocating a separate PARALLEL at a possibly distant memory
> location, especially
This patch to the Go frontend improves the error message when using an
import statement with something other than a string. This requires
updating one of the tests to the current version in the main repo.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote:
> A later patch wants to be able to pass around subarray views of an
> existing array. The standard class to do that is std::span, but it's
> a C++20 thing. This patch just adds a cut-down version of it.
>
> The intention is just
On 11/13/20 1:18 AM, Richard Sandiford via Gcc-patches wrote:
> One of the recurring warts of RTL is that multiplication by a power
> of 2 is represented as a MULT inside a MEM but as an ASHIFT outside
> a MEM. It would obviously be better if we didn't have this kind of
> context sensitivity,
On 11/24/20 6:16 AM, Thomas Schwinge wrote:
> Hi!
>
> Ping. Anybody got an opinion on the approach we should take?
Could we set warning_threshold to a value to inhibit this behavior
completely. It seems backwards to me that warnings have this effect.
Jeff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97187
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97993
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Thank you David for driving the conversation, sorry I was on vacation.
I guess discussion is from perspective of having both flags gdwarf32/gdwarf64.
In which case it's a valid question on whether they should imply -g like
-gdwarf-#.
But can this be viewed as only a -gdwarf64 flag, that is a
On November 30, 2020 7:18:37 PM GMT+01:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On November 30, 2020 4:29:41 PM GMT+01:00, Richard Sandiford via
>Gcc-patches wrote:
>>>dse.c:find_shift_sequence tries to represent a store and load
>>>back as a shift right followed by a
On 11/24/20 2:53 AM, Thomas Schwinge wrote:
> Hi!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2020-11-06T10:26:46+0100, I wrote:
>> Hi, again!
>>
>> On 2018-09-25T16:00:14-0400, David Malcolm wrote:
>>> As noted at Cauldron, dumpfile.c currently emits "note: " for all kinds
>>> of dump message,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98034
Thomas Rodgers changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98071
--- Comment #1 from Barry Revzin ---
On further discussion, since the ABI disallows reusing the tail padding of
PODs, sizeof(B) cannot be 8. This is more likely a clang bug.
On 11/30/20 7:37 AM, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Now that h8300 has been converted to use MODE_CC, it might be a good idea
> to update the documentation on the wiki [1] which still lists h8300 as
> being cc0.
Thanks. I'd been meaning to update that.
I also took care of updating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780
--- Comment #11 from Jakub Jelinek ---
Created attachment 49654
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49654=edit
gcc11-pr80780.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97993
Marek Polacek changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Hello!
I am trying to understand something unexpected I am seeing in the relocations
placed into a compiled Linux kernel for the .debug_info section. Those
relocations seem to change the names of various entries in the debug info:
[65] .debug_info PROGBITS
This patch removes a bit of now dead cc0 code from the H8 port.
In particular it drops the "cc" attribute various insns and removes
notice_update_cc. We keep the attribute, but call it "old_cc" for now.
The compute_*_cc routines get re-purposed in the optimization patches
(not yet submitted),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98071
Bug ID: 98071
Summary: no_unique_address and reusing tail padding
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966
--- Comment #3 from Marek Polacek ---
Reduced (but invalid?):
// PR c++/97966
template
struct S {
__attribute__((used)) S() noexcept(noexcept(this->foo()));
void foo();
};
void
g ()
{
S<1> s;
}
On 11/30/20 7:02 AM, Martin Liška wrote:
> I noticed the test-case contains LIT annotation and
> it is possible to reduce. I did that with compiler that
> was affected by the PR.
>
> Ready for master?
> Tahnks,
> Martin
>
> gcc/testsuite/ChangeLog:
>
> Â Â Â Â * g++.dg/torture/pr93347.C:
On 11/27/20 1:50 PM, Maciej W. Rozycki wrote:
> From: Matt Thomas
>
> Fix an ICE with the handling of RTL expressions like:
>
> (subreg:QI (mem/c:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:67 i ]
> [67])
> (const_int 4 [0x4]))
> (reg/v/f:SI 7 %r7
On 11/30/20 9:02 AM, Maciej W. Rozycki wrote:
> On Fri, 20 Nov 2020, Jeff Law wrote:
>
>> ps. Yes, I skipped the insv/extv changes. They're usually a rats nest
>> of special cases. We'll come back to them.
> I've thought of actually reducing the number of patterns to the minimum
> possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-11-30
Ever confirmed|0
Richard Biener writes:
> On November 30, 2020 4:29:41 PM GMT+01:00, Richard Sandiford via Gcc-patches
> wrote:
>>dse.c:find_shift_sequence tries to represent a store and load
>>back as a shift right followed by a truncation. It therefore
>>needs to find an integer mode in which to do the shift
From: Thomas Rodgers
Adds __cpp_lib_atomic_wait feature test macro which was overlooked in
the initial commit of this feature. Replaces uses of
_GLIBCXX_HAVE_ATOMIC_WAIT.
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h: Replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84655
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780
--- Comment #10 from Jonathan Wakely ---
The values of __builtin_LINE and __builtin_FUNCTION do the right thing for
NSDMIs, but I don't know what they do to make that work.
(In reply to Jakub Jelinek from comment #9)
> If there is a user
1 - 100 of 291 matches
Mail list logo
