https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85835
--- Comment #9 from Matthias Klose ---
Author: doko
Date: Fri Sep 21 07:18:26 2018
New Revision: 264457
URL: https://gcc.gnu.org/viewcvs?rev=264457&root=gcc&view=rev
Log:
2017-09-21 Matthias Klose
Backported from the gcc-7-branch:
sa-store-merging.c (imm_store_chain_info:coalesce_immediate):
Check that the entire merged store group is made of constants only for
overlapping stores.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20180921-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86990
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374
Bug ID: 87374
Summary: ICE in extract_insn, at recog.c:2305
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87195
--- Comment #1 from Martin Liška ---
Can you reproduce that Segher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #2 from Murat Ursavaş ---
Hi Umesh,
Could you test it with the following options:
-g3 -gdwarf-2 -mcpu=cortex-m3 -mthumb -std=c++1y '-DDEBUG=1' -O0 -pedantic
-Wall -Wextra -c -fmessage-length=0 -fno-rtti -fno-exceptions -mno-sched-pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87375
Bug ID: 87375
Summary: Conditional jump or move depends on uninitialised
value(s) in calculate_allocation_cost (ira.c:2453)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #3 from Umesh Kalappa ---
With -O0 , i see the byte load /store like
push{r7}
sub sp, sp, #12
add r7, sp, #0
ldr r2, .L3
mov r3, r7
str r3, [r2]
ldr r3, .L3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86990
--- Comment #5 from Zhendong Su ---
Thanks for the fix, Eric.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87195
Segher Boessenkool changed:
What|Removed |Added
Target|ppc64le-linux-gnu |powerpc*-*-*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #4 from Jonathan Wakely ---
(In reply to Murat Ursavaş from comment #0)
> I've faced a weird behavior on my ARM MCU about a year ago and reported it
> on the launchpad page. In the meantime I tried to report the issue at here
> but yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85737
Ignacio Fernández Galván changed:
What|Removed |Added
CC||jellby at yahoo dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #5 from Richard Earnshaw ---
It's not clear what behaviour you think is 'proper' for a packed struct with a
volatile member. Since packed is a GNU extension, there's nothing in the C (or
C++) standards that you can call upon to reach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #6 from Murat Ursavaş ---
Hi Jonathan,
I just wanted a dramatic entrance :) (There was a discussion about GCC bugzilla
on reddit recently) Of course it hasn't took that long. But this is like
missing a call. You would answer that at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #7 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #6)
> Hi Jonathan,
>
> I just wanted a dramatic entrance :) (There was a discussion about GCC
> bugzilla on reddit recently) Of course it hasn't took that long. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172
--- Comment #28 from Jonathan Wakely ---
Thanks, Dave. That's very helpful.
(In reply to Gubbins from comment #26)
> > The fix here is that __ZNSs4_Rep20_S_empty_rep_storageE needs to be weak
> > when libstdc++.6.dylib is built.
Or make sure t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #8 from Jonathan Wakely ---
Yes, I read the discussion on reddit, it was annoying. It took 7h18m for your
account to be created after you sent an email requesting it. Then it took 9
months for you to use the account. On the other hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #9 from Murat Ursavaş ---
Umesh,
The reason is step-by-step debugging. I'd like to debug it first with -O0, than
pack it with -Os for the release. Otherwise with a low resource MCU, things
become messy really fast.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #10 from Murat Ursavaş ---
Jonathan,
I don't blame any of you and very well aware of the volunteering effort. Please
don't get me wrong. It's just me attempted multiple times to open the case but
get distracted with something else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #13 from Jürgen Reuter ---
Created attachment 44732
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44732&action=edit
Promised shorted reproducer, 93 lines
This is the promised shortened reproducer, 93 lines long. This should ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #11 from Murat Ursavaş ---
Richard,
I don't know about the standards as you are and please accept me as a newbie.
The peripheral parameters of the manufacturer library are all defined as
volatile structs and accessed with pointers. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81035
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #12 from Murat Ursavaş ---
Richard,
Ok I remembered things with reading the old posts on launchpad. The compiler
was generating normal code if I use the struct variable directly. But if I use
a pointer to access it, it assigns not wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #13 from Murat Ursavaş ---
Richard,
Also as far as I remember GNU manual was indeed saying something on this case.
It was saying that "if the struct is not packed, it would access to members
word by word. But if unaligned access is d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87054
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87376
Bug ID: 87376
Summary: [avr] Miscompilation with __memx and long long
addition
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #16 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #15)
> I see that with the fix from comment 13 included, the slightly changed source
>
> #include
> struct S1 { S1(S1 &&); };
> struct S2: S1 {};
> S1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #14 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #13)
> Richard,
>
> Also as far as I remember GNU manual was indeed saying something on this
> case. It was saying that "if the struct is not packed, it would acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #15 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #12)
> Richard,
>
> Ok I remembered things with reading the old posts on launchpad. The compiler
> was generating normal code if I use the struct variable directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #16 from Murat Ursavaş ---
OK I understand conservative action and not wait for word by word access. But
the resulting value is not 0x401 on the test case, but it should be.
In my original case this was effecting a USART peripheral r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87377
Bug ID: 87377
Summary: error with generic lambda accessing static field
through argument within return type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #7 from Martin Liška ---
I started working on this, but it's not easy to register dummy global
variables. If I see correctly, global vars are emitted into assembly here:
#0 assemble_variable (decl=, top_level=0,
at_end=1, dont_outpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #17 from Jonathan Wakely ---
Yes please.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #17 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #16)
> OK I understand conservative action and not wait for word by word access.
> But the resulting value is not 0x401 on the test case, but it should be.
Is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #18 from Richard Earnshaw ---
BTW, are you really trying to say that your hardware has a register that isn't
naturally aligned? That's really weird if so. If not, there are much easier
ways to handle this sort of stuff.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309
--- Comment #5 from David Malcolm ---
Author: dmalcolm
Date: Fri Sep 21 14:17:07 2018
New Revision: 264481
URL: https://gcc.gnu.org/viewcvs?rev=264481&root=gcc&view=rev
Log:
dumpfile.c: fix stray dump_loc output (PR tree-optimization/87309)
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87378
Bug ID: 87378
Summary: False -Wredundant-move (derived vs. base)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #18 from Stephan Bergmann ---
(In reply to Jonathan Wakely from comment #17)
> Yes please.
bug 87378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309
--- Comment #7 from Ilya Leoshkevich ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87378
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87379
Bug ID: 87379
Summary: Warn about function pointer casts which differ in
variadic-ness
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #19 from Murat Ursavaş ---
Hi Richard,
This source code had been designed to see word by word access and may create
expected results. I'm not sure about that.
Let me use latest stable and see what happens. It wasn't plug and play la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #20 from Murat Ursavaş ---
By the way, the hardware peripheral registers are aligned to 32bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #21 from Richard Earnshaw ---
(In reply to Murat Ursavaş from comment #20)
> By the way, the hardware peripheral registers are aligned to 32bits.
So why don't you define your struct as
struct TestStructType
{
volatile unsigned o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
Bug ID: 87380
Summary: Explicit instantations should use weak symbols on
darwin
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ABI
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #22 from Richard Earnshaw ---
Or
#pragma pack(push, 1)
struct TestStructType
{
volatile unsigned one;
unsigned char two;
unsigned short three;
} __attribute__((aligned(32)));
#pragma pack(pop)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #23 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #22)
> Or
> #pragma pack(push, 1)
>
> struct TestStructType
> {
> volatile unsigned one;
> unsigned char two;
> unsigned short three;
> } __attribute__(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> The response from Apple quoted in 82172 comment 26 says that explicit
That should have said Bug 82172 comment 26.
The problem only arises when a template mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172
--- Comment #29 from Jonathan Wakely ---
I've opened Bug 87380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87379
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
--- Comment #5 from Marek Polacek ---
(In reply to eric-bugs from comment #4)
> Should I file a new bug with my new comment in it? I should probably test
> against a trunk with your change in it first.
Please open a separate PR for the issue in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #15 from Dominique d'Humieres ---
> Could you please test the attached patch?
The patch fixes both the reduced and the original tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #2 from Jonathan Wakely ---
The following should run and exit successfully:
$ cat lib.h
template
struct A {
static T member;
};
template
T A::member;
bool match(int*);
$ cat lib.cc
#include "lib.h"
template class A;
bool matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #3 from Jonathan Wakely ---
On GNU/Linux the symbol in the shared library is a global unique symbol:
$ nm --defined-only -g liblib.so | grep member
0020101c u _ZN1AIiE6memberE
It seems that we need to make it weak to ensure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
Bug ID: 87381
Summary: clang 6.0 will compile this constexpr construct, but
gcc 8.2.1 will not.
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #5 from Iain Sandoe ---
fudging the static member to be weak, and rebuilding the lib - the test
completes w/out throwing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #16 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
Many thanks for coming back so promptly. I will package it up for a
commit this evening.
Best regards
Paul
On 21 September 2018 at 17:12, dominiq at lps dot ens.fr
w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #1 from eric-bugs at omnifarious dot org ---
Godbolt link: https://godbolt.org/z/gHnb-G
Also, my attempt to simplify this failed because clang will not consider
arguments to constexpr functions to be constexpr. Which, IMHO, is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #1 from Will Wray ---
Created attachment 44734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44734&action=edit
Fix to pretty-print enumerator ids
c-pretty-print.c
c_pretty_printer::constant(tree)
Remove fall through f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #2 from Jonathan Wakely ---
(In reply to eric-bugs from comment #1)
> Godbolt link: https://godbolt.org/z/gHnb-G
>
> Also, my attempt to simplify this failed because clang will not consider
> arguments to constexpr functions to be co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #3 from eric-bugs at omnifarious dot org ---
Ahh, I guess that does make sense. Oh, well. I guess I'm stuck using template
arguments in place of function arguments in some cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #17 from Paul Thomas ---
Author: pault
Date: Fri Sep 21 17:26:23 2018
New Revision: 264485
URL: https://gcc.gnu.org/viewcvs?rev=264485&root=gcc&view=rev
Log:
2018-09-21 Paul Thomas
PR fortran/87359
* trans-stmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #18 from Paul Thomas ---
Hi Juergen,
Thanks for doing the reduction of the problem and thanks to Dominique for
testing the patch.
Fixed.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #4 from eric-bugs at omnifarious dot org ---
Given the new way of looking at things prompted by the correction of my
erroneous idea, I've rethought how to simplify this, and the simplification
does work in gcc 8.2, and I think is gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77325
--- Comment #4 from Paul Thomas ---
Author: pault
Date: Fri Sep 21 17:33:29 2018
New Revision: 264486
URL: https://gcc.gnu.org/viewcvs?rev=264486&root=gcc&view=rev
Log:
2018-09-21 Paul Thomas
PR fortran/77325
* trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #2 from Will Wray ---
Created attachment 44735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44735&action=edit
Test for enumerator id pretty print patch
pp_enum_test
auto_name returns std::array, splitting the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
Jürgen Reuter changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87382
Bug ID: 87382
Summary: warn for strncpy with a bound greater than the size of
source array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87383
Bug ID: 87383
Summary: improve text and detail in -Wstringop-truncation
warnings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #5 from eric-bugs at omnifarious dot org ---
Here is the problem, reduced to the simplest expression I could make:
-
template
struct test_template {
static int size() { return x; }
};
constexpr int ce_strlen(char const *s)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #21 from Jürgen Reuter ---
In our functional test suite, the tests nlo_4, nlo_5, fks_res_1 and another
test are still failing, they lead to segmentation faults. This will be really
difficult to isolate, but maybe this is a different r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87379
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #22 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #20)
> Paul, thanks for the fix, our code test suite is still running, most of the
> problems are solved, the unit test suite is completely good now, but there
> are cer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #23 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #21)
> In our functional test suite, the tests nlo_4, nlo_5, fks_res_1 and another
> test are still failing, they lead to segmentation faults. This will be
> really diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #24 from Jürgen Reuter ---
Paul, enjoy your time in Wales. Maybe this other issue wasn't caused by r263916
but by something else (though it must have been also in the past 2-3 weeks).
What our functional tests do: they call a code gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #25 from Jürgen Reuter ---
This is the part from the test-suite.log for the 4 failures, they are all in
one particular feature of our code, so I am pretty sure that this is only one
remaining open issue:
| Starting simulation for proc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
--- Comment #6 from Marek Polacek ---
Author: mpolacek
Date: Fri Sep 21 18:45:59 2018
New Revision: 264489
URL: https://gcc.gnu.org/viewcvs?rev=264489&root=gcc&view=rev
Log:
PR c++/87372 - __func__ constexpr evaluation.
* constex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #26 from paul.richard.thomas at gmail dot com ---
Jeurgen,
We are extremely pleased that you do follow developments on trunk. It
really helps to catch regressions early, while the changes are fresh
in mind :-)
Sometime, I would appr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #6 from Iain Sandoe ---
hmm...
Linux:
$ more lib.s
.file "lib.cc"
.text
.weak _ZN1AIiE6memberE
.section
.bss._ZN1AIiE6memberE,"awG",@nobits,_ZN1AIiE6memberE,comdat
.align 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87384
Bug ID: 87384
Summary: Likely syntax error not reported as such
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87384
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87385
Bug ID: 87385
Summary: -Wmisleading-indentation shouldn't warn for labels
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87386
Bug ID: 87386
Summary: Error message for static_assert show wrong range
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81035
--- Comment #3 from Florian Weimer ---
Author: fw
Date: Fri Sep 21 19:49:36 2018
New Revision: 264490
URL: https://gcc.gnu.org/viewcvs?rev=264490&root=gcc&view=rev
Log:
Document that attribute noreturn inhibits tail call optimization
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089
--- Comment #21 from mrs at gcc dot gnu.org ---
I'm fine with Backporting for affected branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87386
--- Comment #1 from trashyankes at wp dot pl ---
btw how reduce "Importance" of this bug?
Right now it have same level as bug that could break my code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87387
Bug ID: 87387
Summary: runk/gcc/builtins.c:585:7: warning: explicitly
assigning value of variable of type 'tree' (aka
'tree_node *') to itself [-Wself-assign]
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81035
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87388
Bug ID: 87388
Summary: Feature request: header-only -Wc++-compat
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
1 - 100 of 125 matches
Mail list logo
