https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65004
Bug ID: 65004
Summary: Compare debug failure with -fno-sanitize-recover
-fsanitize=address -fsanitize=undefined
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
--- Comment #12 from manuel.reimer at gmx dot de ---
(In reply to Richard Earnshaw from comment #11)
> We don't have your hardware and we don't have the full code to your
> application, so we aren't going to be able to help you debug this.
The ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
Jakub Jelinek changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
--- Comment #10 from Jason Merrill ---
(In reply to Tobias Burnus from comment #9)
> In the real code, one has something like the following, which I tried to
> mimic in the test case. If I understood your comment correctly, I should use
> in "log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65004
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
--- Comment #11 from Tobias Burnus ---
(In reply to Jason Merrill from comment #10)
> Having #pragma implementation in LogListener.cc is sufficient:
> > The real-world LogListener.o has (full output as it is short):
> ...
> > V t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
--- Comment #12 from Jason Merrill ---
(In reply to Tobias Burnus from comment #11)
> Because log.o has due to the vptr sanitizer:
> U typeinfo for LogListener
And why isn't that reference satisfied by the definition in LogListe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982
--- Comment #7 from Jan Hubicka ---
Author: hubicka
Date: Tue Feb 10 16:38:31 2015
New Revision: 220587
URL: https://gcc.gnu.org/viewcvs?rev=220587&root=gcc&view=rev
Log:
PR ipa/64982
* cgraphunit.c (cgraph_node::expand_thunk): Look for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64985
--- Comment #2 from Eric Botcazou ---
> Confirmed, but please do _not_ use this pragma, it's essentially untested
> and is guaranteed to be a disaster performance-wise...
This comment is only for the configuration pragma, the regular form is OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64961
--- Comment #4 from Jonathan Wakely ---
No it isn't the same.
Foo<1> is a public member of bar::Bar ([class]/2 "For purposes of access
checking, the injected-class-name is treated as if it were a public member
name.")
Ba is a protected member o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963
--- Comment #8 from Jan Hubicka ---
Yeah, we was copying section as long as it was part of decl more or less by
accident than by design. I suppose keeping section (or not clonning at all)
makes sense. What about inlining across functions with us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56645
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55926
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963
--- Comment #9 from Jakub Jelinek ---
I think we should try to keep older gcc behavior, unless there is a strong
reason to change that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
manuel.reimer at gmx dot de changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #6 from Ian Lance Taylor ---
The odd addresses are most likely a symptom of the libbacktrace library. It
should probably be considered a bug. I'm guessing that it's because of the
--pc in the static function unwind in libbacktrace/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Tue Feb 10 17:20:01 2015
New Revision: 220589
URL: https://gcc.gnu.org/viewcvs?rev=220589&root=gcc&view=rev
Log:
PR c++/64994
* constexpr.c (cxx_eval_call_expression): Walk the cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
manuel.reimer at gmx dot de changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57775
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61838
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58327
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
Richard Henderson changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65004
--- Comment #1 from Jakub Jelinek ---
Created attachment 34716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34716&action=edit
gcc5-pr65004.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65005
Bug ID: 65005
Summary: [5 Regression] FAIL:
c-c++-common/torture/builtin-arith-overflow-12.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963
--- Comment #10 from Andi Kleen ---
Yes it has to be fixed. For example with the kernel __kprobes attribute it
could cause a real bug (__kprobes marks function that cannot be safely
instrumented)
We shouldn't inline over different section names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976
--- Comment #2 from David Edelsohn ---
This is caused by the GCC aggregate (struct) padding implementation for AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
--- Comment #17 from manuel.reimer at gmx dot de ---
I've tried that and unfortunately I still get the errors when connecting my
STM32 via USB.
So the only solution, available for me, seems to be to add a note to the
sourcecode that it has to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963
--- Comment #11 from Jan Hubicka ---
> Yes it has to be fixed. For example with the kernel __kprobes attribute it
> could cause a real bug (__kprobes marks function that cannot be safely
> instrumented)
>
> We shouldn't inline over different sec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
Bug ID: 65006
Summary: [5 Regression] 252.eon in SPEC CPU 2000 miscompiled
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29849
Oleg Endo changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
--- Comment #2 from H.J. Lu ---
(In reply to Jan Hubicka from comment #1)
> Hmm, I wonder why this reproduce on x86-32 only. Does it use any special
> local calling conventions that x86-64 doesn't?
For local functions, GCC will use regparm to pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
--- Comment #3 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #1)
> Hmm, I wonder why this reproduce on x86-32 only. Does it use any special
> local calling conventions that x86-64 doesn't?
Yes register argument passing. That is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64661
--- Comment #1 from Oleg Endo ---
Author: olegendo
Date: Tue Feb 10 20:47:33 2015
New Revision: 220594
URL: https://gcc.gnu.org/viewcvs?rev=220594&root=gcc&view=rev
Log:
gcc/
PR target/64661
* config/sh/sh-protos.h (TARGET_ATOMIC_ANY, TA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64974
--- Comment #1 from Oleg Endo ---
Author: olegendo
Date: Tue Feb 10 20:47:33 2015
New Revision: 220594
URL: https://gcc.gnu.org/viewcvs?rev=220594&root=gcc&view=rev
Log:
gcc/
PR target/64661
* config/sh/sh-protos.h (TARGET_ATOMIC_ANY, TA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64661
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
--- Comment #5 from Jan Hubicka ---
> Yes register argument passing. That is for x86-32 we use registers to pass
> for
> the local calling convention if we can.
Ah yes, got caught by this new calling scheme. I tought it is ILP32 model.
I will t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #9 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65005
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64974
--- Comment #2 from Oleg Endo ---
The problem got slightly worse with r220594. The dead store to the stack frame
is not eliminated anymore. Before the memory operands' addresses were loaded
into a reg using 'force_reg', which AFAIK dropped the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61145
--- Comment #1 from Andrew Pinski ---
I think this code has been removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65007
Bug ID: 65007
Summary: __builtin_uaddll_overflow wrong *res declaration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65008
Bug ID: 65008
Summary: [5 Regression] ICE: in estimate_edge_growth, at
ipa-inline.h:298 with -O2
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65005
--- Comment #2 from Jan Hubicka ---
Indeed, it is the problem with aliases not being streamed. i386.c check
can_change_signature of alias and not function itself. I am working on the
partitioner fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65004
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 10 22:00:11 2015
New Revision: 220596
URL: https://gcc.gnu.org/viewcvs?rev=220596&root=gcc&view=rev
Log:
PR sanitizer/65004
* ubsan.c (ubsan_expand_vptr_ifn): Always retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65004
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64985
--- Comment #3 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Feb 10 22:18:54 2015
New Revision: 220597
URL: https://gcc.gnu.org/viewcvs?rev=220597&root=gcc&view=rev
Log:
PR ada/64985
* varasm.c (initializer_constant_valid_p_1) : Dea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64985
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64894
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009
Bug ID: 65009
Summary: g++ 4.9 sometimes leaves inline methods undefined when
compiling with -Os
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29849
--- Comment #2 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #1)
> I think we can close this PR as 'won't fix'.
> I don't think sh-linux should be used as a shortcut for sh4-linux or
> something like that. I guess by now everybody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009
--- Comment #1 from Don Lewis ---
Created attachment 34719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34719&action=edit
example code that generates undefined symbols for inline methods when compiled
with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
Bug ID: 65010
Summary: ppc backend generates unnecessary signed extension
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65011
Bug ID: 65011
Summary: misleading error message for target attribute
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65012
Bug ID: 65012
Summary: [5 Regression] systemd fails to build at least on
ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with
-flto (ICE)
Product: gcc
Version: 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65012
--- Comment #1 from Matthias Klose ---
/bin/bash ./libtool --tag=CC --mode=link gcc -pipe -Wall -Wextra -Wno-inline
-Wundef -Wformat=2 -Wformat-security -Wformat
-nonliteral -Wlogical-op -Wsign-compare -Wmissing-include-dirs
-Wold-style-defini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822
--- Comment #8 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Feb 11 04:29:06 2015
New Revision: 220606
URL: https://gcc.gnu.org/viewcvs?rev=220606&root=gcc&view=rev
Log:
2015-02-10 Jerry DeLisle
PR libgfortran/57822
* io/write_fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64590
David Baron changed:
What|Removed |Added
CC||dbaron at dbaron dot org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #7 from Dominik Vogt ---
The "--pc" is definitely the cause of the bogus addresses. To me it seems that
these addresses are intended to identify the function and source line from the
dwarf info, not to be printed out as a real addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #8 from Dominik Vogt ---
The cause for this bug is the interaction between the "--pc" and this code
snippet from printStackRecord() in pprof.go:
... if runtime.GOARCH == "s390" || runtime.GOARCH == "s390x" {
// only works if fu
101 - 176 of 176 matches
Mail list logo
