Hanke Zhang via Gcc writes:
> Hi Filip,
>
> Thanks for your reply. But I'm not so familiar with VIM actually. Thus
> when I try the options listed there, nothing happened. (VSCODE is the
> IDE I'm using for development.)
>
> And I notice that there is a `vimrc` in the `contrib` directory, I
>
Mark Wielaard writes:
Hello Mark!
> gcc-patches, binutils and gdb-patches all have only one moderator
> (Jeff, Ian and Thiago). It would probably be good if there were
> more.
>
> Any volunteers? It shouldn't be more than 1 to 3 emails a week
> (sadly most of them spam).
If still needed, I
Sophie 'Tyalie' Friedrich via Gcc writes:
> Hello dear people,
>
> I want to try building a GCC compiler backend for the STM8 micro-controller
> target in order to make this wonderful architecture more accessible.
>
> But as I'm fairly new in this area of building compiler backends for GCC, I
Richard Sandiford writes:
>> +# this regex matches the first line of the "end" in the initial commit
>> message
>> +FIRST_LINE_OF_END_RE = re.compile('(?i)^(signed-off-by:|co-authored-by:|#)
>> ')
>
> Personally I think it would be safer to drop the final space in the regexp.
>
> OK with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105296
Bug ID: 105296
Summary: libgccjit crashes when creating a struct constructor
for an aligned struct type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105279
--- Comment #1 from Marc Nieper-Wißkirchen ---
The internal compiler error also seems to go away if I remove the pointer
subtraction around line 1833 in reproducer.c. Maybe this is the real problem
because I am not subtracting pointers the way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105286
Bug ID: 105286
Summary: Struct initializers do not work with function pointers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105279
Bug ID: 105279
Summary: Using libgccjit produces a null pointer access in
GCC's tree-optimization code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
build...@builder.wildebeest.org writes:
> Build Reason:
> Blamelist: Philip Herron
g++ -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
--- Comment #11 from Marc Nieper-Wißkirchen ---
(In reply to Richard Biener from comment #1 of bug 94416)
> I think there's a duplicate somewhere. We currently cannot encode "restrict"
> into the "accesses" implied by a call.
>
> Note there's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104574
Bug ID: 104574
Summary: GCC misses basic optimization for restricted pointers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Mark Wielaard writes:
> Sorry, I don't immediately know what is happening.
> I assume some merge took place and the buildbot doesn't know what are
> good/bad commits and just tries to do builds for everything in the
> merge. I have shutdown the buildbot till I have time to figure out what
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
Marc Nieper-Wißkirchen changed:
What|Removed |Added
CC||m...@nieper-wisskirchen.de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103989
Bug ID: 103989
Summary: [12 regression] std::optional and bogus
-Wmaybe-unitialized at -Og
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
--- Comment #17 from Marc Nieper-Wißkirchen ---
Does a viable workaround exist that doesn't amount to disabling the warning
option altogether?
In my case, the actual warning is triggered inside the standard library, which
is used by my code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103546
Bug ID: 103546
Summary: Analyzer reports null dereference in flex scanners
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Mark Wielaard writes:
> Hi,
>
> A rust source file can start with a UTF-8 BOM sequence (EF BB
> BF). This simply indicates that the file is encoded as UTF-8 (all rust
> input is interpreted as asequence of Unicode code points encoded in
> UTF-8) so can be skipped before starting real lexing.
>
>
Mark Wielaard writes:
> [PATCH 1/2] Handle shebang line, plus any whitespace and comment
> [PATCH 2/2] Remove has_shebang flag from AST and HIR Crate classes
Pushed to githup:
https://github.com/Rust-GCC/gccrs/pull/546
Marc
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
Mark Wielaard writes:
> It isn't necessary to know whether there are more segments while
> iteration through the expression segements.
Both patches in GH: https://github.com/Rust-GCC/gccrs/pull/537/commits
Fixed a small typo in the commit message while creating the PR :)
Marc
--
Gcc-rust
Mark Wielaard writes:
> On Tue, Jun 29, 2021 at 12:47:07AM +0200, Mark Wielaard wrote:
>> On Tue, Jun 29, 2021 at 12:06:56AM +0200, Marc wrote:
>> > Hi,
>> >
>> > > Translating the AST LifetimeType to the HIR LifetimeType causes a
>> > > warning:
>> > > warning: ‘ltt’ may be used uninitialized
Hi,
> Translating the AST LifetimeType to the HIR LifetimeType causes a warning:
> warning: ‘ltt’ may be used uninitialized
Was wondering why this is needed as the switch case covers all enum
variants, how can ltt be uninitialized ? I have the same fix locally but
was thinking something else was
Mark Wielaard writes:
> parse_inner_attribute tried to skip the right square token twice. This caused
> odd error
> messages in case there were multiple inner attributes. This bug masked
> another bug in
> parse_attr_input where when the (optional) attr input was an assignment to a
> literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97364
Bug ID: 97364
Summary: Clarify/improve documentation for __attribute__
((pure))
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
23 matches
Mail list logo
