--- Comment #4 from fche at redhat dot com 2006-04-22 15:37 ---
(In reply to comment #3)
>
> I investigated further and found that it is not the size of the memory that
> matters. The problem seems to be that we also use fortran code, which is not
> mudflapped, but needs
--- Comment #2 from fche at redhat dot com 2006-04-22 15:42 ---
Indeed, -fmudflapth used to imply -fmudflap, but something broke that
association. As a workaround, the test case works if both -fmudflap and
-fmudflapth are specified.
--
fche at redhat dot com changed
--- Comment #3 from fche at redhat dot com 2006-04-22 16:22 ---
patch committed to mainline
--
fche at redhat dot com changed:
What|Removed |Added
Status
--- Comment #8 from fche at redhat dot com 2006-04-22 20:10 ---
The problem is triggered for the synthetic _gcov_* type global variables that
the profiling code emits. mudflap tries to register them with libmudflap.
--
fche at redhat dot com changed:
What|Removed
--- Comment #2 from fche at redhat dot com 2006-06-19 14:01 ---
It looks like only the statically linked multithreding test cases trigger the
problem. Would you mind trying ot hand-build one of those executables, but
adding -rdynamic to LDFLAGS, and run with -backtrace=99 in
--- Comment #7 from fche at redhat dot com 2006-06-21 16:36 ---
Created an attachment (id=11722)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11722&action=view)
patch for mainline
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
--- Comment #8 from fche at redhat dot com 2006-06-21 16:40 ---
patch in 4.2-bound mainline
--
fche at redhat dot com changed:
What|Removed |Added
Status
--
fche at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org
--- Comment #22 from fche at redhat dot com 2008-11-22 18:35 ---
(In reply to comment #21)
> Sent from my iPhone
Good to know.
> > GCC should not be trying to micromanage coding styles - either of
> > the rest of gnu software or anywhere else, but at least until y
--- Comment #2 from fche at redhat dot com 2009-05-20 16:56 ---
(In reply to comment #1)
> The define and the static inline functions are not equivalent at all.
Right, in general, but if the expressions are side-effect-free,
gcc could move their evaluation farther down.
--
fche
--
fche at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org
--- Comment #15 from fche at redhat dot com 2007-03-15 21:41 ---
This still seems fishy to me FWIW: both gcc's implementation and documentation
appear to be needlessly aggressive.
--
fche at redhat dot com changed:
What|Removed |
--- Comment #13 from fche at redhat dot com 2007-03-30 19:21 ---
> Case 1, is also too hard to fix as it would make us lose a lot of
> optimizations.
If aoliva is correct in comment# 11, then some information is being lost
that could be retained with some additional effort. That
--- Comment #15 from fche at redhat dot com 2007-03-30 22:10 ---
(In reply to comment #14)
> This is basically the same as case 1 (though a constant instead of a call to
> rand()), now do we want not to prop x1 into x? I say we always do want that
> because otherwise we get
--- Additional Comments From fche at redhat dot com 2005-03-10 21:57
---
Myseriously, the bug still appears fixed, in both 4_0-branch and mainline,
despite the reversion. See libmudflap/testsuite/*++/pass55*. For archival
purposes, the last approved but apparently unnecessary patch for
--- Additional Comments From fche at redhat dot com 2005-04-12 16:50
---
I can no longer reproduce this failure with mainline on x86 nor x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19266
--
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19266
--- Comment #10 from fche at redhat dot com 2008-01-17 21:04 ---
Is the mailing-list suggested workaround of adding
asm ("");
into the not-to-be-inlined test function satisfactory?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563
--- Comment #1 from fche at redhat dot com 2009-03-23 22:53 ---
(In reply to comment #0)
> Here there is only one nearby object; argv[] and environ[] are missing. [...]
> Should the objects argv and environ be reported in the -m64 output.
I believe so, because those globa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32247
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
||fche at redhat dot com
Resolution||FIXED
--- Comment #4 from Frank Ch. Eigler 2013-04-18
14:23:32 UTC ---
The Color2 1.9.3-1 macro package has been installed for gcc moinmoin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45655
--- Comment #7 from Frank Ch. Eigler 2013-04-18
18:44:30 UTC ---
Added ThomasSchwinge, StevenBosscher, TobiasBurnus to the gcc wiki admins.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358
--- Comment #5 from Frank Ch. Eigler 2012-08-12
20:21:24 UTC ---
(In reply to comment #4)
> It would not be helpful, systemtap would then see no data [...]
Not quite; systemtap can search the PC ranges/line tables for a nearby address
where a co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24619
--- Comment #3 from Frank Ch. Eigler 2012-09-19
15:54:22 UTC ---
(test only, please ignore)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
--- Comment #8 from Frank Ch. Eigler 2012-10-24
16:39:58 UTC ---
Romain, good analysis.
--
fche at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org
--- Comment #2 from fche at redhat dot com 2009-09-22 15:52 ---
Created an attachment (id=18631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18631&action=view)
proposed patch
This patch fixes and documents the can-of-wormsness of setuid.
--
http://gcc.gnu.org/b
--- Comment #3 from fche at redhat dot com 2009-09-22 16:18 ---
Committed.
--
fche at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41633
--- Comment #1 from fche at redhat dot com 2009-11-02 16:43 ---
Please be aware that the linux kernel uses this flag in its builds
as a tool to help limit runtime stack consumption, as a safety/security
matter. So it goes beyond a "nice to have".
--
http://gcc.gnu.or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47217
Summary: builtin functions should emit debug data
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995
--- Comment #4 from Frank Ch. Eigler 2011-08-19
11:24:19 UTC ---
We have worked around this powerpc oddity in systemtap's recent sdt.h
versions by using both %0 and %I0 together to get a special markup for
literals vs. register names.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167
--- Comment #3 from Frank Ch. Eigler 2012-05-22
14:30:35 UTC ---
test comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52982
Bug #: 52982
Summary: add option to select particular linker
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358
--- Comment #11 from Frank Ch. Eigler ---
This problem continues to hit in gcc 4.8.2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40778
--- Comment #11 from Frank Ch. Eigler 2012-01-17
16:23:15 UTC ---
Jakub's patch makes sense to me in the sense that it's the least modification
over what's there.
Unfortunately, I do not recall what other problems there were with
instrumenting
--- Comment #29 from fche at redhat dot com 2007-06-20 19:37 ---
> This is the patch mentioned in my explanation. It is against the 4.1.1
> release
> source.
Thanks!
This patch applies fine to CVS head, but it does not appear to help
significantly
with the C++ test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #68 from Frank Ch. Eigler ---
(In reply to Jakub Jelinek from comment #67)
> Are the values completely random or are there big chunks with the same
> values?
I'd suspect pretty random, considering that gzip of the
generated source c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #70 from Frank Ch. Eigler ---
> We could add a NATIVE_ENCODE_RANGE_EXPR that encodes a contiguous range of
> bytes in native target representation. Of course that has to be kept
> throughout GIMPLE.
(Just a silly spitballing here ...
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: fche at redhat dot com
Target Milestone: ---
We have a situation where we need to debug an ld run, which is invoked via
g++/collect2. g++ -wrapper gdb,--args works well enough to
--- Additional Comments From fche at redhat dot com 2005-09-23 21:35
---
I can't explain it, but on today's mainline, this bug does not appear. I'm
going to commit the smaller test case ("... make_k ...") from above to
libmudflap/testsuite. If this t
--- Additional Comments From fche at redhat dot com 2005-09-23 21:58
---
patch committed
--
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793
Frank Ch. Eigler changed:
What|Removed |Added
CC||tromey at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115
--- Comment #5 from Frank Ch. Eigler ---
(In reply to Jakub Jelinek from comment #4)
> This "worked" in gcc 6 and earlier because we happily emitted %sil etc. into
> the inline assembly, even when it is not valid for 32-bit code, but starting
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115
--- Comment #7 from Frank Ch. Eigler ---
The systemtap operand encoding machinery separately gives us the byte-size of
the operand, so even if gcc told us %si, we'd only look at %sil only anyway.
But if gcc cannot let that level of ambiguity be,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115
--- Comment #9 from Frank Ch. Eigler ---
Thanks, Jakub; git systemtap now includes your %w[] patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
--- Comment #4 from Frank Ch. Eigler ---
> is test/compile sufficient, or do you have to run it?
Just compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #13 from Frank Ch. Eigler ---
(In reply to Mikael Morin from comment #12)
> Hello, not sure this is due to the upgrade, but the attachment
> appears empty in the page:
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35405&action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #46 from Frank Ch. Eigler ---
> I can add a workaround in Bugzilla itself, if that helps. Frank?
Please go ahead.
||fche at redhat dot com
Resolution|--- |INVALID
--- Comment #3 from Frank Ch. Eigler ---
Until we can get hold of a x509 certificate for the gcc.gnu.org domain (i.e.,
via someone from the FSF, who holds the gnu.org admin contacts), sourceware.org
||fche at redhat dot com
Resolution|--- |WONTFIX
--- Comment #2 from Frank Ch. Eigler ---
This was a sign of incompleteness of libstdc++ support for libmudflap. Please
try the address-sanitizer options for the currently maintained variant of this
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fche at redhat dot com
CC: dmalcolm at redhat dot com
Target Milestone: ---
It is very easy for c++ typos or errors involving templates or overloaded
functions to generate a "wall of text" of d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #3 from Frank Ch. Eigler ---
If the spammer problem is brought under better control with bz5, sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #5 from Frank Ch. Eigler ---
The current .git repos are there as a backup.
I'll move them out of the way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
Frank Ch. Eigler changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45782
Frank Ch. Eigler changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--- Additional Comments From fche at redhat dot com 2005-08-18 20:05
---
still broken.
--
What|Removed |Added
Status|RESOLVED|REOPENED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org |
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12310
--- Comment #12 from Frank Ch. Eigler 2011-03-23
14:52:34 UTC ---
testing, please ignore
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fche at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995
--- Comment #2 from fche at redhat dot com 2010-07-19 21:51 ---
> It is not ambiguous at all in correct usage of inline-asm.
Well, considering that the "g" constraint can generate either a literal or
a naked register number, the ambiguity is real even for normal in
--- Comment #36 from fche at redhat dot com 2010-09-07 18:16 ---
You're all set with plain shell access now.
Connect to irc.freenode.net #overseers for any further needs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
--
fche at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |LpSolit at netscape dot net
|dot org
CC||fche at redhat dot com
--- Comment #4 from Ralf Wildenhues 2010-09-24
18:33:22 UTC ---
Waiting for feedback asked for in comment #1.
--- Comment #5 from Frank Ch. Eigler 2010-09-27
16:34:50 UTC ---
test test test
CC||fche at redhat dot com
--- Comment #4 from Ralf Wildenhues 2010-09-24
18:33:22 UTC ---
Waiting for feedback asked for in comment #1.
--- Comment #5 from Frank Ch. Eigler 2010-09-27
16:34:50 UTC ---
test test test
--- Comment #6 from Frank Ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45904
Frank Ch. Eigler changed:
What|Removed |Added
CC||LpSolit at netscape dot net
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45904
--- Comment #3 from Frank Ch. Eigler 2010-10-06
13:03:48 UTC ---
> I don't know where you see that. All emails I get from GCC Bugzilla have and
> always had the From: field set to gcc-bugzi...@gcc.gnu.org.
Federic, yesterday we did experiment wi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41633
Frank Ch. Eigler changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
--- Comment #10 from fche at redhat dot com 2010-06-10 12:11 ---
(In reply to comment #9)
> You cannot use an "m" operand more than once, since it can include side
> effects.
Nor less than once, apparently.
--
fche at redhat dot com changed:
--- Comment #16 from fche at redhat dot com 2010-06-10 13:24 ---
(In reply to comment #13)
> "m" is defined to be the most general memory constraint, and a pre/post
> modified memory operand is still a memory operand.
If this is to stand, please amend the documentati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167
Summary: dwarf marker for function return instruction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: aol
--- Comment #38 from fche at redhat dot com 2008-01-04 03:19 ---
(In reply to comment #37)
> Downgrading to P4. We seem to have consensus that this is [not] a GCC
> wrong-code
> bug.
Yeah, it seems to be a mistaken expectation of -ffreestanding not to
call libgcc. Maybe a n
--- Comment #32 from fche at redhat dot com 2008-04-09 19:15 ---
The patch has been committed for some time, and this test case passes.
--
fche at redhat dot com changed:
What|Removed |Added
--- Comment #3 from fche at redhat dot com 2006-01-24 22:54 ---
With today's svn snapshot on x86, nptl, test case works ok.
If you can reproduce a crash, it would be useful to first amend the test case
to keep a log of malloc/free operations.
--
fche at redhat dot com ch
AssignedTo: fche at redhat dot com
ReportedBy: fche at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22064
--- Additional Comments From fche at redhat dot com 2005-06-14 18:37
---
patched to look for build tree g++
--
What|Removed |Added
Status|NEW
--- Additional Comments From fche at redhat dot com 2005-06-14 18:38
---
slightly hacky but unobtrusive patch to use type-safe code
--
What|Removed |Added
--- Additional Comments From fche at redhat dot com 2005-06-14 19:13
---
the suggestion seemed to work, thank you!
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From fche at redhat dot com 2005-06-14 19:18
---
thanks, sorry for the wait
--
What|Removed |Added
Status|UNCONFIRMED
--
Bug 21824 depends on bug 21724, which changed state.
Bug 21724 Summary: [gcc]/libmudflap/Makefile.am, refusing to install
mf-runtime.h in includedir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
What|Old Value |New Value
--- Additional Comments From fche at redhat dot com 2005-01-06 02:50
---
reproduced bug, only on original test case
--
What|Removed |Added
AssignedTo|unassigned at
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org |
Status|UNCONFIRMED
--- Additional Comments From fche at redhat dot com 2005-01-07 22:58
---
Here is a simpler test case for at least one of the problems.
struct k {
int data;
k(int j): data(j) {}
};
k make_k () { return k(1); }
int main ()
{
k foo = make_k ();
return 0;
}
--
http
--- Additional Comments From fche at redhat dot com 2005-01-10 17:04
---
This patch appears to fix the problem: testing and getting approvals
--- gimplify.c 1 Jan 2005 01:43:08 - 2.101
+++ gimplify.c 10 Jan 2005 17:03:54 -
@@ -2949,6 +2949,15 @@ gimplify_modify_expr
--- Additional Comments From fche at redhat dot com 2005-02-13 12:50
---
Thank you, Jason!
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From fche at redhat dot com 2004-10-15 15:21 ---
I cannot reproduce this problem with current mainline any more.
--
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72856
--- Comment #6 from Frank Ch. Eigler ---
Per-account rate limits seem so easy to overcome, with spammers already
creating numerous verified junk accounts with ease.
I would suggest focusing on spam-prevention content analysis (spamassassin
style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77319
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment
--- Comment #18 from fche at redhat dot com 2006-11-10 03:09 ---
For what it's worth, this problem does not appear to show up in current
mainline
gcc. If indeed it was caused by tree-ssa passes other than mudflap itself,
a backport of whatever is making it work now seems very unl
--- Comment #2 from fche at redhat dot com 2006-11-10 16:04 ---
As shown by MUDFLAP_OPTIONS="-viol-gdb", the deallocation is occurring
during the pthread exit process, and relates to dlopen's thread-local
variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28578
--- Comment #3 from fche at redhat dot com 2006-11-10 17:43 ---
Some more details.
The data value in question comes from an allocation due to dlerror(),
performed during __mf_init()'s lookup of inteposed dynamic symbols.
Since mudflap is still in __mf_starting_p state, dlerror
--- Comment #5 from fche at redhat dot com 2006-11-10 18:43 ---
The committed patch appears to work around this problem.
--
fche at redhat dot com changed:
What|Removed |Added
--- Comment #23 from fche at redhat dot com 2006-11-14 03:53 ---
As I said in comment 16, this problem isn't limited to C++ code either.
> Instrument gmake-3.81, and you'll get 100,000+ violations
Sorry, I don't see that.
configured gnu make 3.81
compiled wit
--- Comment #25 from fche at redhat dot com 2006-11-14 12:19 ---
(In reply to comment #24)
> Might the problem be that I am compiling on an "old" glibc?
That is possible. Try MUDFLAP_OPTIONS="-trace-calls -verbose-trace".
If you have access to a modern glibc, y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99654
--- Comment #4 from Frank Ch. Eigler ---
A quick diff between the two -fverbose-asm dumps confirms that the generated
object code is identical with or without the -gno-as-locview-support, but the
DW_AT_entry_pc differs.
|--- |FIXED
CC||fche at redhat dot com
--- Comment #2 from Frank Ch. Eigler ---
/etc/gitconfig now sports:
[uploadpack]
allowFilter = true
1 - 100 of 101 matches
Mail list logo
