http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #4 from Ben Woodard woodard at redhat dot com ---
Created attachment 30127
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30127action=edit
Patch from Ariel that prevents the segv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #5 from Ben Woodard woodard at redhat dot com ---
Ariel,
In talking to the engineers regarding this, they would like _builtin_expect
hints to tell the compiler to generate code saying that hitting this is
unlikely.
http://blog.man7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #6 from Ben Woodard woodard at redhat dot com ---
Created attachment 30134
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30134action=edit
reproducer program
still working on getting access to the machine where I have ICC. My
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #7 from Ben Woodard woodard at redhat dot com ---
Created attachment 30137
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30137action=edit
t_repro.c compiled -g -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
Ben Woodard woodard at redhat dot com changed:
What|Removed |Added
Attachment #30127|0 |1
Severity: minor
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
This is an easy problem to solve and there are a couple of ways to solve it.
The underlying problem is that I don't have one of the glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
Ben Woodard woodard at redhat dot com changed:
What|Removed |Added
Severity|minor |trivial
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Created attachment 30602
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30602action=edit
a flattened self contained version of the NAS benchmark.
When I try to compile one of the NAS benchmark's with -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #3 from Ben Woodard woodard at redhat dot com ---
(In reply to Uroš Bizjak from comment #2)
You can add -mtls-dialect=gnu2 to -fpic and -mcmodel=large.
Though doing that prevents the ICE, the compilation spits out about 78 lines
like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #6 from Ben Woodard woodard at redhat dot com ---
I just rebuilt the trunk with the patch that Alexandre Oliva provided and I can
confirm that it solves the problem with notes about non-delegitimized
addresses.
However, I haven't yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #7 from Ben Woodard woodard at redhat dot com ---
Created attachment 30622
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30622action=edit
Alexandre's patch as a file rather than as text.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855
--- Comment #2 from Ben Woodard ---
This is about as simple of a reproducer as I have been able to come up with:
#define _GNU_SOURCE
#include
#include
#include
void
m4_error (int status, int errnum, const char *format, ...)
{
va_list
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
I was looking at the DWARF generated by GCC 6.1 for M4 and it emits two DIEs
for unspecified parameters. Before Dodji
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855
--- Comment #1 from Ben Woodard ---
I just discovered (by mistake) that the problem does not seem to happen with
GCC 4.4.7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358
--- Comment #13 from Ben Woodard ---
This adds some additional complexity to a feature request in
https://sourceware.org/bugzilla/show_bug.cgi?id=19949. It would be helpful it
were resolved.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
-95 ~]$ cat testg++.C
#include
class Error {
public:
virtual void error( int, int, const char *, ... ) const;
};
void Error::error(int a, int b, const char * c, ...) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81812
--- Comment #2 from Ben Woodard ---
Uncommenting the printf allows it to compile.
This showed up on F26 x86_64 compiling MRNet
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
Created attachment 42776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42776=edit
example program
gfortran 7.1 -> current trunk doesn't consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83254
--- Comment #2 from Ben Woodard ---
my bad my trunk was out of date.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478
Ben Woodard changed:
What|Removed |Added
CC||woodard at redhat dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #4 from Ben Woodard ---
Without this Is there a way to read and write floats and doubles accurately
without the rounding that converting to/from base 10 ends up introducing? How
are you supposed to use istreams like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #5 from Ben Woodard ---
The example code in: http://en.cppreference.com/w/cpp/io/manip/fixed
suggests that this should work. Probably either the behavior or the library or
the example on cppreference should change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #10 from Ben Woodard ---
Also note: https://connect.microsoft.com/VisualStudio/feedback/details/742775
My reading of:
https://wg21.link/lwg2381
is that if the first part of the number includes a '.' then the portion after
the 'p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #15 from Ben Woodard ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Ben Woodard from comment #10)
> > Also note:
> > https://connect.microsoft.com/VisualStudio/feedback/details/742775
> >
> > My reading of:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #2 from Ben Woodard ---
Created attachment 48955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48955=edit
gcc binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #1 from Ben Woodard ---
Created attachment 48954
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48954=edit
clang binary
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
When GCC compiles C and there is a call to an external function the full ABI
information for the function being called doesn't exist in the caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #3 from Ben Woodard ---
This also affects C++ but in that case some info can be derived due to
mangling.
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
One problem that I have run into over and over with developers that I support
is they think that -O0 will generate
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
Created attachment 51523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51523=edit
demonstration program
Given a program like this:
1 #include
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534
--- Comment #4 from Ben Woodard ---
There continues to be an instruction after the completion of the inlining, the
next instruction in the sequence, At the time when the inlining occurs why
can’t the .loc 1 6 1 be placed there as part of the
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
When you look at libgcc_s.so's implementation of
_Unwind_GetLanguageSpecificData
$ eu-readelf -s /lib64/libgcc_s.so.1 | grep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054
--- Comment #3 from Ben Woodard ---
Actually what we were hoping to achieve was not to substitute another version
of _Unwind_GetLanguageSpecificData for the one that is in libgcc_s.so but
rather to make it so that that another implementation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054
Ben Woodard changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
--- Comment #10 from Ben Woodard ---
Currently Libabigail is not able to detect this kind of ABI break. We would be
able to detect this if https://dwarfstd.org/issues/221105.1.html were
implemented. As mentioned in the DWARF issue, this would
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
There is a currently an issue filed against the DWARF5 standard that asks for
DW_AT_location to be the DW_TAG_subprogram and DW_TAG_inlined_subprogram.
https://dwarfstd.org
36 matches
Mail list logo
