https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
--- Comment #2 from Tim Shen ---
(In reply to Jonathan Wakely from comment #1)
> Tim, how hard would it be to hardcode limits somewhere for these cases?
It's easy. 6 lines. I'll propose a patch soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #7 from Tim Shen ---
"(.*{100}{100}{100})" seems to be a stack overflow. It's because regex executor
uses recursion. It could be fixed (not segfault but memory exhaustion) by using
a std::stack and simulate recursion; IMH, however, di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61537
Adam Butcher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61537
--- Comment #7 from Adam Butcher ---
Author: abutcher
Date: Thu Jun 26 05:12:52 2014
New Revision: 212008
URL: https://gcc.gnu.org/viewcvs?rev=212008&root=gcc&view=rev
Log:
Fix PR c++/61537
* parser.c (cp_parser_elaborated_type_specifier):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57939
Tom Tromey changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947
--- Comment #15 from amker at gcc dot gnu.org ---
Well, only thing suspicious that I can see, the memset function is a special
implementation and not from C standard library. Basically it doesn't need to
follow the standard, which means the retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
--- Comment #4 from n8tm at aol dot com ---
On 6/25/2014 2:49 PM, Tim Prince wrote:
>
> On 6/25/2014 1:57 PM, mpolacek at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
>>
>> Marek Polacek changed:
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57939
--- Comment #2 from chihin ko ---
Yeah, difference version of gdb resulting different behavior:
On Red Hat Enterprise Linux Server release 5.4 (Tikanga)
GNU gdb Fedora (6.8-37.el5)
(gdb) p L
$1 = 98
gcc version 4.7.2 (GCC)
On Oracle Linux Serv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
Bug 39139 depends on bug 16331, which changed state.
Bug 16331 Summary: x86-64 inline asm register constraints insufficient WRT ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331
Gerald Pfeifer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49342
Gerald Pfeifer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/home/cx/gccTRUNK/
--disable-multilib
Thread model: posix
gcc version 4.10.0 20140625 (experimental) (GCC)
cx@cx:~/REtrunk/kozak5$ ~/gccTRUNK/bin/g++ c11re.c -o c11re -std=c++11
cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #2 from ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61615
Bug ID: 61615
Summary: Failure to resolve correct generic with TYPE(C_PTR)
arguments
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14494
Paolo Carlini changed:
What|Removed |Added
CC|bkoz at redhat dot com,|jason at gcc dot
gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61242
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Wed Jun 25 21:42:37 2014
New Revision: 211998
URL: https://gcc.gnu.org/viewcvs?rev=211998&root=gcc&view=rev
Log:
PR c++/61242
* call.c (build_aggr_conv): Ignore passed in flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61614
Bug ID: 61614
Summary: [4.9/4.10 Regression] Bogus error: taking address of
temporary array
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #19 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #18)
> (In reply to Marc Glisse from comment #17)
> > And if func is inline,
> > it will require -fkeep-inline-functions.
>
> What is the difference between inlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499
Paul Thomas changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57019
Paul Thomas changed:
What|Removed |Added
Assignee|pault at gcc dot gnu.org |unassigned at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60239
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
--- Comment #4 from Marek Polacek ---
BTW, clang doesn't warn even when neither operand comes from a macro expansion;
and clang version 3.4 doesn't know -Wlogical-op warning option (so I tried
-Wall -Wextra -Weverything, but still no warning). Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #1)
> Sorry, this is too large to analyze. Maybe you can reduce it following the
> ideas here: https://gcc.gnu.org/bugs/minimize.html
Wrong bug! Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
--- Comment #1 from Arthur O'Dwyer ---
Already filed against Clang: http://llvm.org/bugs/show_bug.cgi?id=19141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
Bug ID: 61613
Summary: ,##__VA_ARGS__ fails to expand the first variadic
argument if it is a macro-name
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
Tom Tromey changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Peter Eisentraut from comment #2)
> No, these "functions" need to have a usable return value, because someone
> could write
>
> if (!sigemptyset(...))
> weirderror();
Note that just u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #5 from Maksymilian Arciemowicz ---
Thanks for feedback. I'm going verify this on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
--- Comment #2 from Tom Tromey ---
(In reply to David Blaikie from comment #1)
> Any idea what value it should have? (how GDB would like to have the member
> function pointer encoded)
Sorry I didn't reply to this sooner.
Nope, no idea :-)
I thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54774
Tom Tromey changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063
Tom Tromey changed:
What|Removed |Added
CC||chihin.ko at oracle dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
--- Comment #3 from n8tm at aol dot com ---
On 6/25/2014 1:57 PM, mpolacek at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
>
> Marek Polacek changed:
>
> What|Removed |Added
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58589
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61598
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57939
Tom Tromey changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
--- Comment #3 from Marek Polacek ---
I don't think so, -ftrack-macro-expansion=2 is on by default and I don't see
-ftrack-macro-expansion=0 anywhere in the log of bootstrap. So maybe my
approach would be viable after all (and I could fix PR6108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
Jonathan Wakely changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Marek Polacek from comment #1)
> and then we could use from_macro_expansion_at and don't warn if it's true.
> But the problem is with -ftrack-macro-expansion=0, since
> from_macro_expansio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Jonathan Wakely changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
--- Comment #2 from Paolo Carlini ---
Ed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57233
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
Manuel López-Ibáñez changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|2014-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
--- Comment #1 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Wed Jun 25 16:36:49 2014
New Revision: 211986
URL: https://gcc.gnu.org/viewcvs?rev=211986&root=gcc&view=rev
Log:
fix typo in winnt.c
gcc/
PR c/61612
* config/i38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61610
--- Comment #1 from Sandra Loosemore ---
Hmmm, this looks like a bug in LRA exposed by the change to register alloc
order. In particular this comment in the code just above the assertion seems
to reflect an incorrect assumption:
/* We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612
Bug ID: 61612
Summary: trunk revision 211984 winnt.c ‘hash_table_c’ does not
name a type
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61598
--- Comment #3 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Wed Jun 25 16:02:04 2014
New Revision: 211985
URL: https://gcc.gnu.org/viewcvs?rev=211985&root=gcc&view=rev
Log:
fix checking=fold
gcc/
PR bootstrap/61598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723
Dodji Seketeli changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61611
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61611
Bug ID: 61611
Summary: Incorrect exception rethrown from a function-try-catch
block when a nested try-catch executes
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
e06 execute
../../gcc/ira.c:5486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
gcc version 4.10.0 20140625 (experimental) [trunk revision 211980]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49132
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49132
--- Comment #8 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Jun 25 14:27:35 2014
New Revision: 211981
URL: https://gcc.gnu.org/viewcvs?rev=211981&root=gcc&view=rev
Log:
/cp
2014-06-25 Paolo Carlini
DR 178
PR c++/49132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #4 from Richard Biener ---
(In reply to Kai Tietz from comment #3)
> Thanks for testing. I will sent a patch for it.
> It seems after all that we need to run peephole2 pass twice.
Bad for compile-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61609
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409
--- Comment #7 from Jakub Jelinek ---
I think what is important that if the other conditions besides mini_p != 0 are
not met, then control flow goes to basic blocks from which there is no path to
the bb with the use (in this testcase just to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #3 from Kai Tietz ---
Thanks for testing. I will sent a patch for it.
It seems after all that we need to run peephole2 pass twice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #17 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #16)
> Marc:
>
> struct Iter
> {
> Iter& operator+=(int) { return *this; }
>
> int operator*() { return i; }
>
> int i;
> };
>
> Iter& func(Iter iter, int n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61609
Bug ID: 61609
Summary: running libraries compiled with different gcc versions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #43 from thopre01 at gcc dot gnu.org ---
> Thanks. In the stage before the one that fails, could you add
> -fdump-tree-all-details -fdump-rtl-all-details to the command lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
Yes, it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #6 from Sebastian Meyer ---
Ah, okay, thank you for the clarification, Jakub.
So this is indeed RESOLVED INVALID, sorry.
I am still sure I saw the example I gave, but can't seem to find it now.
Chances are good though it wasn't GCC,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #16 from Jonathan Wakely ---
Marc:
struct Iter
{
Iter& operator+=(int) { return *this; }
int operator*() { return i; }
int i;
};
Iter& func(Iter iter, int n) {
return iter += n;
}
int main()
{
Iter iter = Iter();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #1 from Kai Tietz ---
Does this issue get fixed by adding the peephole2 also at old place too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Target||arm*-none-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #15 from Marc Glisse ---
If you can reduce the testcase to a manageable size, I'll see why
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html is not enough (it
should be, with -fkeep-inline-functions, but is apparently missing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61433
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
Bug ID: 61608
Summary: [4.10 regression] FAIL: gcc.target/arm/epilog-1.c
scan-assembler tests
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #12 from Marek Polacek ---
Author: mpolacek
Date: Wed Jun 25 12:43:05 2014
New Revision: 211978
URL: https://gcc.gnu.org/viewcvs?rev=211978&root=gcc&view=rev
Log:
PR c/61162
* c-parser.c (c_parser_statement_after_labels): Pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
--- Comment #3 from Richard Biener ---
Like with
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 211969)
+++ gcc/tree-ssa-threadupdate.c (working co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542
Bill Schmidt changed:
What|Removed |Added
Summary|[4.8/4.9 Regression]|[4.8/4.9/trunk]
|vect-n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Marc Glisse changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #22 from Marc Glisse ---
Author: glisse
Date: Wed Jun 25 12:27:13 2014
New Revision: 211977
URL: https://gcc.gnu.org/viewcvs?rev=211977&root=gcc&view=rev
Log:
2014-06-25 Marc Glisse
PR tree-optimization/57742
gcc/
* tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #14 from Jonathan Wakely ---
Yes, I can't convince gcc or clang to give a warning. Even address sanitizer
and undefined-behaviour sanitizer don't catch the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61575
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
--- Comment #2 from Richard Biener ---
With the propagation limitation removed we get
Registering jump thread: (2, 4) incoming edge; (4, 5) joiner; (5, 7)
normal;
Cancelling jump thread: (2, 4) incoming edge; (4, 5) joiner; (5, 7) normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
--- Comment #1 from Richard Biener ---
Optimizing block #5
1>>> COND 1 = i_1 ge_expr R_6(D)
1>>> COND 0 = i_1 lt_expr R_6(D)
LKUP STMT inter0p_13 = PHI
inter0p_13 = PHI
2>>> STMT inter0p_13 = PHI
inter0p_13 = PHI
LKUP STM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
Bug ID: 61607
Summary: DOM missed jump threading and destroyed loops
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: missed-optimization, wrong-code
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61606
Bug ID: 61606
Summary: About GCC install, testing step (mostly check...)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
Bug ID: 61605
Summary: Potential optimization: Keep unclobbered argument
registers live across function calls
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #4 from Sebastian Meyer ---
Richard: The typdef gets optimized away very quickly, so I needed to trick
around a bit. But the array won't use the typedef anyway, the produced DWARF is
equal to what was produced before (DWARF3 keeps it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
Matthias Klose changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #13 from Adrien Hamelin ---
I'm sorry that i made you lose your time :-(
I thought that kind of code would trigger a warning though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Marek Polacek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61604
Bug ID: 61604
Summary: missing line numbers in a sanitizer backtrace from an
OMP region
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445
Richard Biener changed:
What|Removed |Added
Version|unknown |4.10.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61500
Richard Biener changed:
What|Removed |Added
Target Milestone|4.9.1 |4.8.4
1 - 100 of 134 matches
Mail list logo
