[Bug web/114223] Utilize filtering for git://gcc.gnu.org/git/gcc.git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||fche at redhat dot com --- Comment #2 from Frank Ch. Eigler --- /etc/gitconfig now sports: [uploadpack] allowFilter = true
[Bug tree-optimization/113239] [13/14 regression] After 822a11a1e64, bogus -Warray-bounds warnings in std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239 --- Comment #7 from Frank Ch. Eigler --- Wonder if this similar but different diagnostic is closely related: https://kojipkgs.fedoraproject.org//work/tasks/6259/112176259/build.log [...] inlined from ‘mutatee::instrument_dynprobe_target(BPatch_object*, dynprobe_target const&)’ at mutatee.cxx:444:22: /usr/include/c++/14/bits/stl_algobase.h:438:30: error: ‘memmove’ writing between 9 and 9223372036854775800 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 438 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num); | ~^~~ In file included from /usr/include/c++/14/x86_64-redhat-linux/bits/c++allocator.h:33, from /usr/include/c++/14/bits/allocator.h:46, from /usr/include/c++/14/string:43: In member function ‘std::__new_allocator::allocate(unsigned long, void const*)’, [...] where the c++ code in question is a straight vector<> foo; vector<> bar; foo.insert(foo.end(), bar.begin(), bar.end());
[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function
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.
[Bug c++/94082] __builtin_memcpy in constexpr context should compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com test
[Bug driver/90902] New: collect2 does not propagate gcc -wrapper far enough to wrap ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90902 Bug ID: 90902 Summary: collect2 does not propagate gcc -wrapper far enough to wrap ld Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal 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 spawn a gdb for the collect2 process, but not well enough that the collect2 fork/exec of ld is also wrapped. Please consider adding this capability.
[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays
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 ... but if such a native target representation is not processed again before being sent to the assembler, it could even be stored compressed.)
[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays
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 code compresses by only 80%. In the case of the systemtap example, it's approximately a byte dump of the .debug_line section, which is relatively efficiently encoded, ergo incompressible.
[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #66 from Frank Ch. Eigler --- Just in case it helps, we are encountering this problem with fedora29's gcc 8.2.1, when compiling a 24-million unsigned-char initialized array: % gcc -c -Q -v foo.i [...] Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1243 kB ( 0%) phase parsing : 25.26 ( 83%) 26.12 (100%) 51.47 ( 90%) 2592523 kB (100%) phase opt and generate : 5.32 ( 17%) 0.08 ( 0%) 5.42 ( 10%) 7 kB ( 0%) phase finalize : 0.00 ( 0%) 0.02 ( 0%) 0.13 ( 0%) 0 kB ( 0%) garbage collection : 1.27 ( 4%) 0.00 ( 0%) 1.27 ( 2%) 0 kB ( 0%) callgraph construction : 4.05 ( 13%) 0.08 ( 0%) 4.15 ( 7%) 5 kB ( 0%) preprocessing : 5.99 ( 20%) 6.39 ( 24%) 12.20 ( 21%) 524289 kB ( 20%) lexical analysis : 7.34 ( 24%) 8.90 ( 34%) 16.18 ( 28%) 0 kB ( 0%) parser (global): 11.93 ( 39%) 10.83 ( 41%) 23.09 ( 40%) 2068233 kB ( 80%) TOTAL : 30.58 26.24 57.05 2593783 kB
[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build
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.
[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build
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, then I guess we must work around the change. In the sdt.h, we enjoyed using machine-independent operant-constraint codes - until now, I guess.
[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build
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 > with r245815 we diagnose that. Just curious, but could the "r" constraint be reinterpreted by gcc>6 so that it emits %si etc. for these small values rather than %sil?
[Bug web/77319] [bugzilla] bugzilla behaves erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77319 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #4 from Frank Ch. Eigler --- Reset the email delivery mode to 'sendmail' from the recently experimented-with 'smtp'.
[Bug web/72856] Trottle bug creation for newly created accounts (to limit spam)
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), and post-spam cleanup (blacklisting, history editing, bug hiding?) efforts.
[Bug c++/67499] New: c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499
Bug ID: 67499
Summary: c++ template/overload diagnostic compression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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 diagnostics, which overwhelm. Please
consider compressing / eliding / abbreviating ...
% cat foo.cxx
#include
class foo { int b; };
int main() {
foo bar;
std::cout << bar;
}
% g++ foo.cxx 2>&1 | wc -l
193
.. so that 193 number is closer to 1
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #46 from Frank Ch. Eigler fche at redhat dot com --- I can add a workaround in Bugzilla itself, if that helps. Frank? Please go ahead.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #13 from Frank Ch. Eigler fche at redhat dot com --- (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=35405action=edit This appears to be due to CSS/JS goo marking that attachment textarea as display: none !important for some reason.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com --- Comment #6 from Frank Ch. Eigler fche at redhat dot com --- Note that printf is a varargs function, and is defined to widen smaller-than-int parameters to at least int. unsigned short is subsumed in int.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #5 from Frank Ch. Eigler fche at redhat dot com --- The current .git repos are there as a backup. I'll move them out of the way.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #3 from Frank Ch. Eigler fche at redhat dot com --- If the spammer problem is brought under better control with bz5, sure.
[Bug testsuite/20003] libmudflap.cth timeouts too short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Frank Ch. Eigler fche at redhat dot com --- mudflap has been retired
[Bug web/45782] When updating a bug, an error can be thrown if an email cannot be sent to a recipient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45782 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Frank Ch. Eigler fche at redhat dot com --- problem appears to have been corrected
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 --- Comment #4 from Frank Ch. Eigler fche at redhat dot com --- is test/compile sufficient, or do you have to run it? Just compile.
[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
Frank Ch. Eigler fche at redhat dot com changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment #2 from Frank Ch. Eigler fche at redhat dot com ---
(Note that strictly speaking, systemtap per se doesn't need to support
an architecture for the sys/sdt.h header file to work there. gdb is
a fully independent client of sys/sdt.h markers.)
Perhaps the way to go forward is to have the gcc configury test-compile
some toy sys/sdt.h code [1], and activate the probes only if that works.
[1]
#include sys/sdt.h
int main ()
{
DTRACE_PROBE(foo,bar);
return 0;
}
[Bug libstdc++/59677] basic_istream::get leads to a mudflap violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59677 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fche at redhat dot com Resolution|--- |WONTFIX --- Comment #2 from Frank Ch. Eigler fche at redhat dot com --- This was a sign of incompleteness of libstdc++ support for libmudflap. Please try the address-sanitizer options for the currently maintained variant of this functionality.
[Bug web/60119] Bugzilla URLs don't work with https.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60119 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||fche at redhat dot com Resolution|--- |INVALID --- Comment #3 from Frank Ch. Eigler fche at redhat dot com --- 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 can only serve https for that alter ego. (A self-signed key is another possibility, but no one's too keen on that.)
[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358 --- Comment #11 from Frank Ch. Eigler fche at redhat dot com --- This problem continues to hit in gcc 4.8.2.
[Bug web/45655] GCC WIki Needs Text Colorizing Capability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45655 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fche at redhat dot com Resolution||FIXED --- Comment #4 from Frank Ch. Eigler fche at redhat dot com 2013-04-18 14:23:32 UTC --- The Color2 1.9.3-1 macro package has been installed for gcc moinmoin.
[Bug web/45655] GCC WIki Needs Text Colorizing Capability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45655 --- Comment #7 from Frank Ch. Eigler fche at redhat dot com 2013-04-18 18:44:30 UTC --- Added ThomasSchwinge, StevenBosscher, TobiasBurnus to the gcc wiki admins.
[Bug java/32247] -Wall enables -Wunused enables -Wunused-parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32247 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com --- Comment #14 from Frank Ch. Eigler fche at redhat dot com 2013-03-19 23:50:18 UTC --- no comment
[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793
Frank Ch. Eigler fche at redhat dot com changed:
What|Removed |Added
CC||tromey at redhat dot com
Severity|normal |major
--- Comment #3 from Frank Ch. Eigler fche at redhat dot com 2013-01-18
16:01:24 UTC ---
A little longer test case (which requires a location_list rather than location
for all the parameters) shows that gdb is adversely affected by this bug too;
its prologue-finding is no help:
% cat foo2.c
int foo (int a, int b) __attribute__((noinline));
int bar (int c, int d) __attribute__((noinline));
int bar (int c, int d)
{
while (c-- d++) ;
}
int foo (int a, int b)
{
asm volatile (nop);
return bar (a, b);
}
int main () {
return foo (7, 4);
}
% gcc -g -O2 -mfentry foo2.c -p
% gdb a.out
(gdb) break foo
Breakpoint 1 at 0x400660: file foo2.c, line 11.
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, foo (a=optimized out, b=optimized out) at foo2.c:11
11{
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446 --- Comment #8 from Frank Ch. Eigler fche at redhat dot com 2012-10-24 16:39:58 UTC --- Romain, good analysis.
[Bug libmudflap/24619] mudflap instrumentation of dlopen is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24619 --- Comment #3 from Frank Ch. Eigler fche at redhat dot com 2012-09-19 15:54:22 UTC --- (test only, please ignore)
[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358 --- Comment #5 from Frank Ch. Eigler fche at redhat dot com 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 corrected location list would cover.
[Bug debug/49167] dwarf marker for function return instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167 --- Comment #3 from Frank Ch. Eigler fche at redhat dot com 2012-05-22 14:30:35 UTC --- test comment
[Bug driver/52982] New: add option to select particular linker
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: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: f...@redhat.com If one has both ld and gold installed, gcc gives little help in letting someone choose one or the other for a particular link job. (Systemwide relinking a la alternatives(1), or forcing creation of a temporary -B directory, are not convenient.) Please consider adding an option to the driver, akin to -Wl... to allow overriding of the ld binary being invoked. Perhaps: gcc -Wl=/bin/ld.gold (and similar options for -Wa=, -Wp= could make sense).
[Bug libmudflap/40778] [4.5/4.6/4.7 Regression] Mudflap instrumentation missing in cloned function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40778 --- Comment #11 from Frank Ch. Eigler fche at redhat dot com 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 general DECL_ARTIFICIAL !mf_marked_p functions. Perhaps at the time, there was a problem propagating the mf_marked_p flag.
[Bug target/44995] define a macro for presence of -mregnames option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995 --- Comment #4 from Frank Ch. Eigler fche at redhat dot com 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.
[Bug debug/49167] New: dwarf marker for function return instruction
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...@gcc.gnu.org ReportedBy: f...@redhat.com CC: tro...@redhat.com It would be desirable to have a DWARF marker of some sort emitted for the point(s) of a function that correspond to the logical moment of its return. This would ideally be a point where all the nearby variables are still in scope, so the last-gasp variable state may be examined. Ideally, tail call sites would also have this marker, and so would inlined functions. One can dream...
[Bug libmudflap/12310] [tree-ssa] libmudflap fails to build on mips-sgi-IRIX6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12310 --- Comment #12 from Frank Ch. Eigler fche at redhat dot com 2011-03-23 14:52:34 UTC --- testing, please ignore
[Bug debug/47217] New: builtin functions should emit debug data
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...@gcc.gnu.org ReportedBy: f...@redhat.com CC: aol...@gcc.gnu.org, rol...@redhat.com Consider functions such as __builtin_memcpy, _strlen, etc. These functions often expand into just a handful of assembly instructions that allow fast execution. However, they preclude debugging because there is no debugging data emitted for them, so there is no metadata left to identify the source-level memcpy. So users can't put a breakpoint there via function name, such as to count or test run-time memcpy uses. It would be helpful if gcc were to arrange emission of dwarf data for some or all builtins. One possibility would be to represent them as inlined-instances of the standard memcpy etc. functions, with DWARF data such as DW_AT_artificial and no DECL coordinates.
[Bug middle-end/41633] -Wframe-larger-than should warn about outgoing function calls, specifically varargs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41633 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.05 18:12:22 Ever Confirmed|0 |1 --- Comment #2 from Frank Ch. Eigler fche at redhat dot com 2010-11-05 18:12:22 UTC --- Still present as of gcc 4.5.
[Bug web/45904] Email addresses used by Bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45904 --- Comment #3 from Frank Ch. Eigler fche at redhat dot com 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 with an alternative setting, after bounces started being collected as new comments, starting a mail loop.
[Bug web/45904] Email addresses used by Bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45904
Frank Ch. Eigler fche at redhat dot com changed:
What|Removed |Added
CC||LpSolit at netscape dot net
--- Comment #1 from Frank Ch. Eigler fche at redhat dot com 2010-10-06
01:25:33 UTC ---
I set the 'mailfrom' config options back to {gcc,sourceware}-bugzi...@foo.
There appears to be no setting to override the envelope-from / Return-Path:
fields, nor to append a Reply-To:, each of which may help fix the problem
of bugs getting bounces recorded in them.
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.09.24 18:33:22 date|| Ever Confirmed|0 |1 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-24 18:33:22 UTC --- Waiting for feedback asked for in comment #1. --- Comment #5 from Frank Ch. Eigler fche at redhat dot com 2010-09-27 16:34:50 UTC --- test test test
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.09.24 18:33:22 date|| Ever Confirmed|0 |1 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-24 18:33:22 UTC --- Waiting for feedback asked for in comment #1. --- Comment #5 from Frank Ch. Eigler fche at redhat dot com 2010-09-27 16:34:50 UTC --- test test test --- Comment #6 from Frank Ch. Eigler fche at redhat dot com 2010-09-27 17:05:17 UTC --- test test test
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- 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
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
-- fche at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |LpSolit at netscape dot net |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug target/44995] New: define a macro for presence of -mregnames option
In some cases, it would be useful if the presence of the gcc -mregnames option was not only communicated to the assembler, but also to the C program being compiled. This comes up in an unusual usage of inline-assembler operands, where the ambiguity between literals and register names is a problem. (http://sourceware.org/PR11821). With such a macro (say, -D__GCC_REGNAMES), the inline-asm code could emit extra code strings to allow resolution of the ambiguities. -- Summary: define a macro for presence of -mregnames option Product: gcc Version: 4.6.0 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
[Bug target/44995] define a macro for presence of -mregnames option
--- 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 inline assembly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- 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: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- 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 documentation to warn about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug middle-end/41633] -Wframe-larger-than should warn about outgoing function calls, specifically varargs
--- 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.org/bugzilla/show_bug.cgi?id=41633
[Bug c/41633] New: -Wframe-larger-than should warn about outgoing function calls, specifically varargs
gcc should warn when the stack frame for a called varargs function is in excess of a -Wframe-larger-than=NNN bytes. Such a check could be done at each call site, to see whether the outgoing arguments alone already exhaust NNN. -- Summary: -Wframe-larger-than should warn about outgoing function calls, specifically varargs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41633
[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid
-- fche at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-22 14:54:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41433
[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid
--- 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=18631action=view) proposed patch This patch fixes and documents the can-of-wormsness of setuid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41433
[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41433
[Bug middle-end/40207] request for enhancement: delay argument loading until needed
--- 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 at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40207
[Bug libmudflap/38462] test libmudflap.c/fail27-frag.c fails output pattern test for ppc64
--- 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 globals are supposed to be registered with the mudflap runtime, though they might be too far from buffer[] to be listed, so we should not depend on this. The real problem seems to be that test case should expect mudflap dead object rather than mudflap object to match buffer[], just like you say. -- fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38462
[Bug c/25509] can't disable __attribute__((warn_unused_result))
--- 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 you clean up every bit of your own code, there should be a way of disabling the warning clutter. Why GCC is not micromanaging at all, it just allows the developer of the API to have the warning. So your complaints here are useless. What the poster seems to be requesting is another -Wno-unused-FOO flag to override this warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug tree-optimization/34563] noinline function call being removed
--- 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
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- 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 new option to that effect would help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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 like the ones in the test suite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug debug/23551] dwarf records for inlines appear incomplete
--- 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 would make this bug other than invalid - at best a wontfix. -- fche at redhat dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- 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 an extra assignment. I believe the idea was to emit extra DWARF for that copy-propagation, so as to treat the destination as a location-list-level alias of the source. The idea was not to inhibit the copy, just to document it, if that is sensible feasible. Plus this issue is not a regression at all because the RTL level does the same. (Did someone say it was?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- 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 |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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, you could compare traces from the two variants. Or that you didn't invoke ./make and didn't in fact run the resulting exe? I certainly ran it. env MUDFLAP_OPTIONS=-collect-stats ./make gives some interesting figures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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 with mainline, CFLAGS=-fmudflap LDFLAGS=-lmudflap. ran resulting executable. No problems at all, just slower. Tried again with -O2 -fmudflap. Same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/28578] A most simple multithreaded program (practically any multithreaded one) causes mudflap violation
--- 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
[Bug libmudflap/28578] A most simple multithreaded program (practically any multithreaded one) causes mudflap violation
--- 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's calloc() gets redirected to __mf_0fn_calloc, and gets one of the preallocated buffers in .bss. The problem occurs at main thread shutdown, as caused by pthread_exit(). (An ordinary falling-off-the-end does not trigger this problem.) What happens is that __libc_start_main starts calling funky cleanup functions, including one __nptl_deallocate_tsd, which results in a free() call for that value allocated by dlerror(). But now, libmudflap is in normal non-reentrant state, so this free() is checked, and sure enough is found not to refer to a corresponding checked allocation call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28578
[Bug libmudflap/28578] A most simple multithreaded program (practically any multithreaded one) causes mudflap violation
--- 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 Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28578
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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 unlikely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/28578] A most simple multithreaded program (practically any multithreaded one) causes mudflap violation
-- fche at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-07 18:30:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28578
[Bug libmudflap/24619] mudflap instrumentation of dlopen is incorrect
-- fche at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-01 22:46:41 |2006-07-02 23:38:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24619
[Bug libmudflap/21724] [4.0 Regression] libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir
--- 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=11722action=view) patch for mainline -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
[Bug libmudflap/21724] [4.0 Regression] libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir
--- 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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
[Bug libmudflap/28077] [4.1/4.2 regression] pass39-frag.c produces mudflap violation on alpha
--- 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 MUDFLAP_OPTIONS? That way, the backtraces should have more symbolic information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- 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 the gfortran library. The mudflapped C code uses malloc(), which gets wrapped into calls to __mfwrap_malloc(). Unfortunately, libgfortran also uses malloc(), which is instrumented by libmudflap but shouldn't, as this exactly is causing the error. The link-time wrapping of malloc is designed precisely so that other uninstrumented libraries that call malloc by name still get registered in the libmudflap runtime. That way, pointers from these libraries may make their way to an instrumented routine, and be used without error. Does MUDFLAP_OPTIONS=-trace-calls produce anything? -- fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug libmudflap/26864] multithreaded mudflap not working
--- 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: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-22 15:42:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug libmudflap/26864] multithreaded mudflap not working
--- 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|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug other/20128] ice with mudflap + profile generate
--- 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 |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-28 06:29:27 |2006-04-22 20:10:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20128
[Bug libmudflap/20339] mudflap abort
--- 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 changed: What|Removed |Added CC||fche at redhat dot com Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20339
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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 test fails, please post an attachment with the error log. Since neither my x86 nor x86-64 machine shows the problem, it may be necessary for you to rebuild the test case with extra dump flags (-fdump-tree-all and friends) and scour through that for clues. -- What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/23084] mudflap crash upon accept() with argement 2 and 3 as NULL
--- Additional Comments From fche at redhat dot com 2005-09-23 21:58 --- patch committed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23084
[Bug libmudflap/18244] libmudflap installs include/mf-runtime.h in version-independent path
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-05-01 14:01:45 |2005-08-29 20:51:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18244
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-08-18 20:05 --- still broken. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/22064] New: libmudflap contains possible alias violations
http://gcc.gnu.org/ml/gcc/2005-06/msg00438.html -- Summary: libmudflap contains possible alias violations Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libmudflap 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
[Bug testsuite/21094] libmudflap C++ tests run even when C++ not configured
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21094
[Bug libmudflap/22064] libmudflap contains possible alias violations
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22064
[Bug libmudflap/21023] mudflap reports errors for external array variable with no size specified
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21023
[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir
--- Additional Comments From fche at redhat dot com 2005-06-14 19:18 --- thanks, sorry for the wait -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*
-- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824
[Bug other/19266] [mudflap] ICE when compiling with -fmudflap -O
--- 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
[Bug other/19266] [mudflap] ICE when compiling with -fmudflap -O
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19266
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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 this problem was this one: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00381.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-02-13 12:50 --- Thank you, Jason! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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 (tree *expr_p, tree
if (ret != GS_UNHANDLED)
return ret;
+ /* Handle aggregate returns from function calls. We need to mark
+ the LHS addressable, since the expanded call will pass its
+ address as a hidden argument. */
+ if (TREE_CODE (*from_p) == CALL_EXPR)
+{
+ if (aggregate_value_p (*to_p, *from_p))
+lang_hooks.mark_addressable (*to_p);
+}
+
/* If we've got a variable sized assignment between two lvalues (i.e. does
not involve a call), then we can make things a bit more straightforward
by converting the assignment to memcpy or memset. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 GCC build triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC host triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC target triplet| i686-pc-linux-gnu |i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2005-01-07 22:42:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug other/19266] [mudflap] ICE when compiling with -fmudflap -O
--- 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 gcc dot gnu |fche at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-05 20:36:31 |2005-01-06 02:50:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19266
