[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #28 from Ian Lance Taylor 2012-09-06 05:30:05 UTC --- The log test problems should be fixed again. If it reappears, please don't add to this PR. This PR is about Solaris problems. Open a new PR instead. Thanks.
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #27 from ian at gcc dot gnu.org 2012-09-06 05:28:26 UTC --- Author: ian Date: Thu Sep 6 05:28:19 2012 New Revision: 191009 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191009 Log: debug/elf, debug/dwarf: DWARF line number fixes. Support DW_AT_high_pc as a constant. Support DW_AT_ranges. PR gcc/52583 Modified: branches/gcc-4_7-branch/libgo/go/debug/dwarf/line.go branches/gcc-4_7-branch/libgo/go/debug/elf/file.go
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #26 from ian at gcc dot gnu.org 2012-09-06 05:28:12 UTC --- Author: ian Date: Thu Sep 6 05:28:02 2012 New Revision: 191008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191008 Log: debug/elf, debug/dwarf: DWARF line number fixes. Support DW_AT_high_pc as a constant. Support DW_AT_ranges. PR gcc/52583 Modified: trunk/libgo/go/debug/dwarf/line.go trunk/libgo/go/debug/elf/file.go --- Comment #27 from ian at gcc dot gnu.org 2012-09-06 05:28:26 UTC --- Author: ian Date: Thu Sep 6 05:28:19 2012 New Revision: 191009 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191009 Log: debug/elf, debug/dwarf: DWARF line number fixes. Support DW_AT_high_pc as a constant. Support DW_AT_ranges. PR gcc/52583 Modified: branches/gcc-4_7-branch/libgo/go/debug/dwarf/line.go branches/gcc-4_7-branch/libgo/go/debug/elf/file.go
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #26 from ian at gcc dot gnu.org 2012-09-06 05:28:12 UTC --- Author: ian Date: Thu Sep 6 05:28:02 2012 New Revision: 191008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191008 Log: debug/elf, debug/dwarf: DWARF line number fixes. Support DW_AT_high_pc as a constant. Support DW_AT_ranges. PR gcc/52583 Modified: trunk/libgo/go/debug/dwarf/line.go trunk/libgo/go/debug/elf/file.go
[Bug tree-optimization/54494] [4.7/4.8 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Andrew Pinski changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2012-09/msg00321.htm |atches/2012-09/msg00350.htm |l |l --- Comment #4 from Andrew Pinski 2012-09-06 04:12:03 UTC --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00350.html
[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235 --- Comment #13 from Cary Coutant 2012-09-06 03:34:27 UTC --- Author: ccoutant Date: Thu Sep 6 03:34:22 2012 New Revision: 191005 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191005 Log: 2012-09-05 Cary Coutant Backport trunk patch to fix a problem where type signature does not include the type's context. 2012-07-19 Jason Merrill gcc/ PR debug/53235 * dwarf2out.c (get_die_parent): New. (generate_type_signature): Use it. gcc/testsuite/ * g++.dg/debug/dwarf2/nested-4.C: New. Added: branches/google/gcc-4_7/gcc/testsuite/g++.dg/debug/dwarf2/nested-4.C Modified: branches/google/gcc-4_7/gcc/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/dwarf2out.c branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7
[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|GCC produces wrong |[4.8 Regression] GCC |debugging information, |produces wrong debugging |failure while assembling|information, failure while |generated .s file |assembling generated .s ||file --- Comment #2 from Andrew Pinski 2012-09-06 00:26:17 UTC --- Is there a reason why you are using stabs+ debugging?
[Bug debug/54499] GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499 --- Comment #1 from Dmitry Gorbachev 2012-09-06 00:03:39 UTC --- Created attachment 28139 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28139 Code generated by GCC
[Bug debug/54499] New: GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499
Bug #: 54499
Summary: GCC produces wrong debugging information, failure
while assembling generated .s file
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
Created attachment 28138
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28138
Testcase
GCC 4.8.0 20120902 (experimental). Compile with `-gstabs+' option.
bug.s: Assembler messages:
bug.s:133: Error: can't resolve `.text._ZN2S3D1Ev' {.text._ZN2S3D1Ev section} -
`.LFBB3' {.text._ZN2S3D2Ev section}
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 --- Comment #6 from Aldy Hernandez 2012-09-05 22:43:03 UTC --- Created attachment 28137 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28137 proposed patch Proposed patch using the simulate-thread harness.
[Bug tree-optimization/54498] [4.7/4.8 Regression] incorrect code generation from g++ -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Last reconfirmed||2012-09-05
Component|c++ |tree-optimization
Ever Confirmed|0 |1
Summary|incorrect code generation |[4.7/4.8 Regression]
|from g++ -O on x86_64 |incorrect code generation
||from g++ -O
Target Milestone|--- |4.7.2
--- Comment #1 from Andrew Pinski 2012-09-05
22:21:58 UTC ---
Confirmed, here is the source unincluded:
#include
#include
using namespace std;
class bar_src {
public:
bar_src() : next(0) {}
virtual ~bar_src() { delete next; }
bar_src *next;
};
class foo_src : public bar_src {
public:
foo_src(double f, double fwidth, double s = 5.0);
virtual ~foo_src() {}
private:
double freq, width, peak_time, cutoff;
};
foo_src::foo_src(double f, double fwidth, double s) {
freq = f; width = 1/fwidth; cutoff = s*width; peak_time = cutoff;
}
complex do_ft2(int i) __attribute__ ((noinline));
complex do_ft2(int i) {
return i == 0 ? complex(-491.697,887.05) :
complex(-491.692,887.026);
}
void foo(void) {
complex prev_ft = 0.0, ft = 0.0;
for (int i=0; i < 2; i++) {
prev_ft = ft;
{
foo_src src(1.0, 1.0 / 20);
ft = do_ft2(i);
printf("ft (it = %d) = %g%+gi\n", i, real(ft), imag(ft));
}
if (i > 0)
printf("abs(ft - prev_ft) = %g\n",
abs(ft - prev_ft));
}
}
int main(void) {
foo();
return 0;
}
--- CUT ---
The problem comes from FRE, I think due to how it handles look though copies.
It happens on more than just x86_64.
[Bug c/54495] gcc gives a false warning in kernel/trace/trace_events_filter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54495 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson 2012-09-05 22:14:00 UTC --- But if the call to ftrace_function_filter_re sets re_cnt to 0, then ret indeed will be used uninitialized AFAICT. What am I missing?
[Bug c++/54498] New: incorrect code generation from g++ -O on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498 Bug #: 54498 Summary: incorrect code generation from g++ -O on x86_64 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: stev...@alum.mit.edu Created attachment 28136 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28136 preprocessed source exhibiting the problem The attached preprocessed source (bug.ii) illustrates an apparent incorrect code generation when it is compiled with g++ -O version 4.7.1 on x86_64 (Debian GNU/Linux). The program executes two iterations of a loop, calling a function that returns two slightly different complex numbers in the two iterations. After the second iteration, it prints the absolute value of the difference. The correct output (when compiled without optimization) is: ft (it = 0) = -491.697+887.05i ft (it = 1) = -491.692+887.026i abs(ft - prev_ft) = 0.0245153 (0.0245153 is the correct absolute difference of the two previous numbers.) When compiled with -O, it produces: ft (it = 0) = -491.697+887.05i ft (it = 1) = -491.692+887.026i abs(ft - prev_ft) = 491.692 Note that the first two numbers are the same, but the absolute value of the difference is wrong. The problem disappears if I use g++ 4.4.5, or if I make minor changes to the code; I've tried to boil it down to the minimal code that exhibits the problem. Steven PS. The preprocessed source is rather long only because it #includes and ; the program source at the end is quite short. PPS. Some of my g++ -v output follows, indicating the g++ configuration options etcetera: Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/stevenj/downloads/gcc/gcc-4.7.1/OBJ/../local --disable-multilib --enable-languages=c,c++ GNU C++ (GCC) version 4.7.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
[Bug tree-optimization/54497] New: Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497 Bug #: 54497 Summary: Revision 190015 causes 22% degradation on 172.mgrid on PowerPC Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: pthau...@gcc.gnu.org CC: berg...@gcc.gnu.org, de...@gcc.gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Created attachment 28135 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28135 Reduced testcase Starting with revision 190015 I'm seeing a major degradation on cpu2000 benchmark 172.mgrid. The core loop of the benchmark is in procedure RESID(). The main differences I see in the tree dumps, compared with the prior revision, which result in the degradation are the following. 1) IPA-CP creates a clone of RESID to be used at certain call sites. 2) Predictive Commoning doesn't optimize the hot loop in the cloned version of RESID. The attatched testcase was reduced from mgrid.f and can be compiled with gfortran -S -m64 -O3 -mcpu=power7 -mno-vsx -fno-inline. In the original version, resid_, predictive commoning has unrolled the loop by a factor of 2 so that memory refs can be resued (hot loop has 20 loads and 2 stfd). In the cloned version, resid_.constprop.0, no predictive commoning is done and we end up with a single copy of the the loop with 32 loads and a single store.
[Bug c/51840] asm goto enhancement request
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
Timo Kreuzer changed:
What|Removed |Added
CC||timo.kreuzer at reactos dot
||org
--- Comment #3 from Timo Kreuzer 2012-09-05
21:39:56 UTC ---
I support this enhancement request with additional explanation.
The documentation for asm goto in the online docs for gcc 4.7.1 contain an
example using a jump table. This is done by creating the jump table inside the
asm statement, using ".pushsection" and ".popsection" directives to move the
actual jump table data into a dedicated section.
This does not work on x86 PE targets.
2 possible workarounds come to mind:
a) Using explicit sections, like ".section bla; ... ;.section .text;"
But this has limitations, since you cannot use it in a function that will go to
a different section than the .text section, something pretty common for driver
code, where initialization code is put in ".INIT" and pageable code is put in
".PAGE". For my usage scenario (exception handling for reactos) this approach
will not work.
b) Use C-style jump tables. "static void *jmp_table[] = {&&label1, &&label2};"
This has also the advantage that it integrates better with the rest of the C
code and allows to reuse the jump tables in C code.
Sadly solution b) is broken.
Here's an example:
int
example1(int param)
{
int value = 0;
if (param > 2)
asm goto ("movl %0, %%ecx\n\tjmp %l[label1]\n" : : "i"(&&label1) :
"ecx" : label1);
value = 1;
if (param > 1)
asm goto ("movl %0, %%ecx\n\tjmp %l[label1]\n" : : "i"(&&label1) :
"ecx" : label1);
value = 2;
label1:
return value;
}
The compiler output looks like this (cleaned up):
_example1:
movl4(%esp), %edx
cmpl$2, %edx
jleL2
movl $L3, %ecx
jmp L4
L2:
movl$2, %eax
cmpl$1, %edx
jleL3
movl $L3, %ecx
jmp L6
ret
L4:
movl$0, %eax
ret
L6:
movl$1, %eax
L3:
rep
ret
The 2 jmp instructions jump to L4 and L6, while both mov instructions point
to L3. A jump from the asm goto to L3 would result in broken behaviour.
Using asm goto with C style jump tables causes the compiler to generate code
pathes that are incompatible with a jump to the static address of the label, as
stored in the jump table.
When a simple goto can correctly jump to addresses in static tables, then asm
goto should be able to do that as well.
There should also not be a big performance penalty for that, since the compiler
can simple move whatever is now put in the individual pathes to the place
before the asm goto is emitted.
[Bug driver/28718] Call to -lgcc added prior to user libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718 Georg-Johann Lay changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-09-05 CC||gdr at gcc dot gnu.org Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #14 from Georg-Johann Lay 2012-09-05 21:35:00 UTC --- CCing Gaby. He is the only one I know of who is committed to C++ and avr. (In reply to comment #13) > All this is fighting the symptoms though. > > My point (as outlined in comment #8) is: > > When operating as a C compiler, *all* user-supplied libraries are passed > to the linker *first*, followed by system libraries. > > When operating as a C++ compiler, libstdc++ and libm.a are passed *before* > any user-supplied library. This leaves the users in a situation where > they are no longer able to supply own overrides for some functions in > system libraries. Again, all this is in contrast to how the C compiler > works. > > In the AVR case, the situation is only worse since there's no libstdc++ > (yet), and somehow, libgcc is substituted in place of libstdc++ (which I > think is a completely flawed idea from the beginning). > > So despite all the artefacts which leaded to this bug report, I think at > least the last point mentioned is worth fixing: if there's no libstdc++, > there's no point in trying to pretend libgcc could be supplied as a > replacement for libstdc++. (The AVR-related artefacts are now mostly > fixed after Johann's recent work, the original bug(s) remain(s).) Ok, I untied the two PRs again and set this one to NEW.
[Bug other/54490] [4.7 Regression] ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490 --- Comment #2 from Georg-Johann Lay 2012-09-05 21:24:40 UTC --- I see hundreds of spill fails riunning the test suite -- with AVR-Libc. Some months ago, 2 or 3 pathological test cases failes with spill fails. Now there are hundreds of fails for simple test cases...
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184
Aldy Hernandez changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Aldy Hernandez 2012-09-05
21:15:52 UTC ---
What I was trying to test here originally was whether the LIM pass kept a flag
of changes to "count" and only if the flag was true, allow the cached version
of "count" to be stored.
Technically, I could get away with only checking the presence of count_lsm_flag
in the dump, though I realize that this also is an imperfect solution if a
previous pass changed things around.
Apart from checking count_lsm_flag, the only thing I can think of is replacing
this test with one within the simulate-thread/ infrastructure that actually
checks that no caching occurs unless p->data > 0.
Richard, which solution do you prefer, or do you recommend something else?
void func()
{
struct obj *p;
for (p = q; p; p = p->next)
if (p->data > 0)
count++;
}
[Bug other/54490] [4.7 Regression] ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490 Eric Weddington changed: What|Removed |Added Priority|P3 |P4 Severity|major |normal --- Comment #1 from Eric Weddington 2012-09-05 20:39:08 UTC --- Reducing importance. I don't know of anyone building toolchains with the avr target and using newlib as the C library. The avr-rtems target should be tried, though.
[Bug tree-optimization/54494] [4.7/4.8 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Ralf Baechle changed: What|Removed |Added CC||r...@linux-mips.org --- Comment #3 from Ralf Baechle 2012-09-05 20:06:47 UTC --- I've tested your proposed fix with the kernel configuration that I extracted the test case from and I'm happy to report that the patch is working for me.
[Bug libstdc++/54296] using the object in the map to erase element from the map crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54296 --- Comment #9 from François Dumont 2012-09-05 19:41:21 UTC --- Author: fdumont Date: Wed Sep 5 19:41:16 2012 New Revision: 190991 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190991 Log: 2012-09-05 François Dumont PR libstdc++/54296 * include/bits/hashtable.h (_M_erase(size_type, __node_base*, __node_type*)): New. (erase(const_iterator)): Use latter. (_M_erase(std::true_type, const key_type&)): New, likewise. (_M_erase(std::false_type, const key_type&)): New. Find all nodes matching the key before deallocating them so that the key doesn't get invalidated. (erase(const key_type&)): Use the new member functions. * testsuite/23_containers/unordered_map/erase/54296.cc: New. * testsuite/23_containers/unordered_multimap/erase/54296.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_map/erase/54276.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/54276.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #7 from Markus Trippelsdorf 2012-09-05 19:20:18 UTC --- (In reply to comment #6) > Markus, I looked at the gcda file you sent but don't see anything obviously > wrong with it. gcov-dump reports that most of the counts in that file are 0 or > very small, so I am not sure why there were messages about exceeding the > maximal count. Yes, as I wrote in my first message the point of failure always varies (for each bootstrap). The attached cp-demangle.gcda was from a failure similar to the one H.J. reported in Comment 2. I guess fixing H.J.'s issue will fix the other failures, too.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #6 from Teresa Johnson 2012-09-05 19:02:51 UTC --- I finally got a reproducer for the error that H.J. reported. I will work on fixing that first. Markus, I looked at the gcda file you sent but don't see anything obviously wrong with it. gcov-dump reports that most of the counts in that file are 0 or very small, so I am not sure why there were messages about exceeding the maximal count.
[Bug target/54496] New: [M32C] - Improve address costs estimations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54496 Bug #: 54496 Summary: [M32C] - Improve address costs estimations Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: m32c*-*-* With rev. 190990 the target hook TARGET_ADDRESS_COST has been extended to contain the mode of the addressed memory and the address space. On M32C the costs estimations should be adjusted, since addresses in different address spaces have different costs, at least when compiling with -Os.
[Bug tree-optimization/54494] [4.7/4.8 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 --- Comment #2 from Andrew Pinski 2012-09-05 18:23:56 UTC --- Created attachment 28134 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28134 Patch which fixes the problem Here is the fix.
[Bug c/54495] New: gcc gives a false warning in kernel/trace/trace_events_filter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54495
Bug #: 54495
Summary: gcc gives a false warning in
kernel/trace/trace_events_filter.c
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: toralf.foers...@gmx.de
The current git tree of linux gave with gcc-4.6.3 :
kernel/trace/trace_events_filter.c: In function
‘ftrace_function_set_filter_cb’:
kernel/trace/trace_events_filter.c:2074:8: warning: ‘ret’ may be used
uninitialized in this function [-Wuninitialized]
which refers to this piece of code:
2002 static int __ftrace_function_set_filter(int filter, char *buf, int len,
2003 struct function_filter_data
*data)
2004 {
2005 int i, re_cnt, ret;
2006 int *reset;
2007 char **re;
2008
2009 reset = filter ? &data->first_filter : &data->first_notrace;
2010
2011 /*
2012 * The 'ip' field could have multiple filters set, separated
2013 * either by space or comma. We first cut the filter and apply
2014 * all pieces separatelly.
2015 */
2016 re = ftrace_function_filter_re(buf, len, &re_cnt);
2017 if (!re)
2018 return -EINVAL;
2019
2020 for (i = 0; i < re_cnt; i++) {
2021 ret = ftrace_function_set_regexp(data->ops, filter,
*reset,
2022 re[i], strlen(re[i]));
2023 if (ret)
2024 break;
2025
2026 if (*reset)
2027 *reset = 0;
2028 }
2029
2030 argv_free(re);
2031 return ret;
2032 }
...
2061 static int ftrace_function_set_filter_cb(enum move_type move,
2062 struct filter_pred *pred,
2063 int *err, void *data)
2064 {
2065 /* Checking the node is valid for function trace. */
2066 if ((move != MOVE_DOWN) ||
2067 (pred->left != FILTER_PRED_INVALID)) {
2068 *err = ftrace_function_check_pred(pred, 0);
2069 } else {
2070 *err = ftrace_function_check_pred(pred, 1);
2071 if (*err)
2072 return WALK_PRED_ABORT;
2073
2074 *err = __ftrace_function_set_filter(pred->op == OP_EQ,
2075
pred->regex.pattern,
2076 pred->regex.len,
2077 data);
2078 }
2079
2080 return (*err) ? WALK_PRED_ABORT : WALK_PRED_DEFAULT;
2081 }
2082
Both a kernel dev :
>Strange, as ret is initialized to 'ret = -EINVAL;' in
>__ftrace_function_set_filter(). I'm thinking that gcc got confused here.
and a Gentoo Linux User points me to file a bug about this.
I'm running an almost stable Gentoo linux :
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.6.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.6.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.6.3/python
--enable-checking=release --disable-libgcj --with-arch=i686
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.6,
pie-0.5.2'
Thread model: posix
gcc version 4.6.3 (Gentoo 4.6.3 p1.6, pie-0.5.2)
[Bug tree-optimization/54494] [4.7/4.8 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-05 Known to work||4.6.1 Ever Confirmed|0 |1 Known to fail||4.7.0, 4.7.1, 4.8.0
[Bug tree-optimization/54491] interval membership optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54491 --- Comment #4 from Andrew Pinski 2012-09-05 17:52:53 UTC --- > integer overflow Note there is never any integer overflow with unsigned types but always wrapping.
[Bug tree-optimization/54494] [4.7/4.8 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.2 Summary|Missing store to volatile |[4.7/4.8 Regression] ||Missing store to volatile --- Comment #1 from Andrew Pinski 2012-09-05 17:48:42 UTC --- I am going to fix this. Note this is causing the mips linux kernel to become unstable.
[Bug tree-optimization/54494] New: Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494
Bug #: 54494
Summary: Missing store to volatile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Consider:
extern const unsigned long base;
static inline void wreg(unsigned char val, unsigned long addr)
{
*((volatile unsigned char *) (base + addr)) = val;
}
void wreg_twice(void)
{
wreg(0, 42);
wreg(0, 42);
}
CUT ---
At -O2 the second store to the volatile char is removed by the strlen pass.
[Bug fortran/54462] [4.8 Regression] Another "segmentation fault" after an error in COMMON statement after r190853
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54462 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Tobias Burnus 2012-09-05 17:00:48 UTC --- FIXED. Dominique, thanks for the bugreport and testing the patch!
[Bug fortran/54462] [4.8 Regression] Another "segmentation fault" after an error in COMMON statement after r190853
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54462 --- Comment #3 from Tobias Burnus 2012-09-05 16:40:56 UTC --- Author: burnus Date: Wed Sep 5 16:40:48 2012 New Revision: 190989 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190989 Log: 2012-09-05 Tobias Burnus PR fortran/54462 * symbol.c (gfc_undo_symbols): Avoid NULL pointer dereference. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c
[Bug bootstrap/54484] r190927 breaks bootstrap with clang compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54484 --- Comment #8 from dnovillo at google dot com 2012-09-05 16:38:21 UTC --- On 2012-09-05 12:11 , glisse at gcc dot gnu.org wrote: > I meant the one in this PR's description. The second overload of lower_bound > takes an argument lessthan_ but uses lessthan (no underscore). Thanks. Good catch. I just committed a fix for it. > I assume it is never instantiated? Right. Otherwise, we'd get an error while building stage2. Diego.
[Bug bootstrap/54484] r190927 breaks bootstrap with clang compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54484 --- Comment #7 from Diego Novillo 2012-09-05 16:34:54 UTC --- Author: dnovillo Date: Wed Sep 5 16:34:42 2012 New Revision: 190988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190988 Log: PR bootstrap/54484 * vec.h (vec_t::lower_bound): Fix spelling of LESSTHAN argument. Modified: trunk/gcc/ChangeLog trunk/gcc/vec.h
[Bug middle-end/54486] [4.6/4.7/4.8 Regression] Spurious printf format warning mentions nonexistent type 'sizetype'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54486 --- Comment #5 from Jakub Jelinek 2012-09-05 16:29:49 UTC --- Author: jakub Date: Wed Sep 5 16:29:42 2012 New Revision: 190987 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190987 Log: PR middle-end/54486 * builtins.c (fold_builtin_strspn, fold_builtin_strcspn): Use build_int_cst with size_type_node instead of size_int. * c-c++-common/pr54486.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/c-c++-common/pr54486.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/builtins.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/54486] [4.6/4.7/4.8 Regression] Spurious printf format warning mentions nonexistent type 'sizetype'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54486 --- Comment #4 from Jakub Jelinek 2012-09-05 16:28:27 UTC --- Author: jakub Date: Wed Sep 5 16:27:55 2012 New Revision: 190986 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190986 Log: PR middle-end/54486 * builtins.c (fold_builtin_strspn, fold_builtin_strcspn): Use build_int_cst with size_type_node instead of size_int. * c-c++-common/pr54486.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr54486.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #10 from Paolo Carlini 2012-09-05 16:22:14 UTC --- Richard, could you please review the 3 patches as sent to the mailing list?
[Bug c++/54420] [4.6/4.7/4.8 Regression] Segmentation fault in decl_mangling_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54420 Paolo Carlini changed: What|Removed |Added Target Milestone|4.6.4 |4.8.0
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #5 from H.J. Lu 2012-09-05 16:17:01 UTC --- I can reproduce it with only --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse
[Bug bootstrap/54484] r190927 breaks bootstrap with clang compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54484 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #6 from Marc Glisse 2012-09-05 16:11:01 UTC --- (In reply to comment #5) > > did you also take a look at the warning about lessthan_ in the clang > > messages? > No. Clang's output was very noisy. I did not look at any warnings, > just waited for the error that was preventing the build. I meant the one in this PR's description. The second overload of lower_bound takes an argument lessthan_ but uses lessthan (no underscore). I assume it is never instantiated?
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #4 from Markus Trippelsdorf 2012-09-05 15:46:16 UTC --- Created attachment 28133 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28133 bad .gcda file I've attached a bad .gcda file. Please note that both H.J. and I use --with-build-config=bootstrap-lto.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #3 from H.J. Lu 2012-09-05 15:41:18 UTC --- Also happens with revision 190982 on Fedora 18/x86-64. I configured GCC with --prefix=/usr/local --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --with-build-config=bootstrap-lto --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc and used make -j8 profiledbootstrap on a 8-core machine.
[Bug middle-end/36041] Speed up builtin_popcountll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |glisse at gcc dot gnu.org --- Comment #9 from Paolo Carlini 2012-09-05 15:21:12 UTC --- Maybe Marc is interested.
[Bug c++/54441] [4.7/4.8 Regression] Infinite loop with brace initializer on zero-length array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54441 Paolo Carlini changed: What|Removed |Added Target Milestone|4.7.2 |4.8.0
[Bug c++/18747] "template<> int i;" accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18747 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org Target Milestone|--- |4.8.0 --- Comment #7 from Paolo Carlini 2012-09-05 15:13:20 UTC --- Ah, this is fixed, then.
[Bug tree-optimization/54491] interval membership optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54491 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek 2012-09-05 15:09:18 UTC --- Ah, right, the #c7 from that PR applies here. If you use if ((c<=b) & (b <=42+c)) return c; in foo instead, bar will be optimized by the reassoc pass.
[Bug driver/28718] Call to -lgcc added prior to user libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718 --- Comment #13 from Joerg Wunsch 2012-09-05 15:08:27 UTC --- All this is fighting the symptoms though. My point (as outlined in comment #8: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718#c8 ) is: When operating as a C compiler, *all* user-supplied libraries are passed to the linker *first*, followed by system libraries. When operating as a C++ compiler, libstdc++ and libm.a are passed *before* any user-supplied library. This leaves the users in a situation where they are no longer able to supply own overrides for some functions in system libraries. Again, all this is in contrast to how the C compiler works. In the AVR case, the situation is only worse since there's no libstdc++ (yet), and somehow, libgcc is substituted in place of libstdc++ (which I think is a completely flawed idea from the beginning). So despite all the artefacts which leaded to this bug report, I think at least the last point mentioned is worth fixing: if there's no libstdc++, there's no point in trying to pretend libgcc could be supplied as a replacement for libstdc++. (The AVR-related artefacts are now mostly fixed after Johann's recent work, the original bug(s) remain(s).)
[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54463 --- Comment #6 from Steve Kargl 2012-09-05 14:56:36 UTC --- On Wed, Sep 05, 2012 at 10:21:53AM +, burnus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54463 > > --- Comment #5 from Tobias Burnus 2012-09-05 > 10:21:53 UTC --- > > [Comment to my patch:] > (In reply to comment #3) > > What about -freal-4-real-10 -freal-4-real-16 -freal-4-real-8 > > -freal-8-real-10 -freal-8-real-16 and -freal-8-real-4? > > Ugh, those flags are ugly! (Actually, I think you approved that > patch, which I regard as worse than -fdefault-real-8.) Yes, I did approve the patch. Oddly, I regard the -freal-4-real-8 option as a better version of -fdefault-real-8 because it is a complete promotion of real(4) to real(8). With -fdefault-real-8, there are a few "gotcha"s; one in particular gotcha is doing IO because of an alignment issue with a structure used within libgfortran. (Now, that I think about it, I do not recall testing whether the -freal-*-real-* have a similar IO issue.) > The -freal-*-real-* flags completely messes up everything. All of these options (ie, the -fdefault*, -freal-*, and -finteger-*) mess up everything. The correct solution is to fix the Fortran code so that these options are not needed. One way to encourage the user to fix the code is too unconditionally issue a warning that discourages the use of these options. By "unconditionally" I mean that the warning cannot be suppressed (without redirecting stderr to /dev/null). > Of course, I assume that one doesn't mess around with -fdefault-real-8 or > -freal-4-real-10 when compiling BLAS. If one does this, one gets what one > deserves. We've both been around long enough that the inventiveness of the gfortran user base should no longer cause surprise. :-) I personally prefer Dominique's suggestion that we add a a warning in the manual that -fexternal-blas and the -fdefault-* and -freal-* option have a conflict. That being said, you've provided a patch and I won't oppose you committing it.
[Bug tree-optimization/54491] interval membership optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54491 --- Comment #2 from Jakub Jelinek 2012-09-05 14:54:50 UTC --- I'm suprised PR46309 doesn't handle this. Will look at it.
[Bug tree-optimization/54491] interval membership optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54491 Richard Guenther changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-05 Component|c |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-09-05 14:21:47 UTC --- You are basically requesting 12 < a < 32 to be converted to (unsigned) a - 12 < 20, something fold does but not forwprop or ifcombine.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #37 from Ulrich Drepper 2012-09-05 13:57:27 UTC --- (In reply to comment #23) > (though, > apparently insufficient for i?86 - it should use either __get_cpuid, or > __get_cpuid_max before __cpuid). I fixed that. The code now should work in theory also on those systems. Although the sheer size of all the code together will prevent these systems from being used...
[Bug tree-optimization/54489] tree FRE uses an excessive amount of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54489
--- Comment #1 from Richard Guenther 2012-09-05
13:52:25 UTC ---
Testcase:
int foo (int a)
{
int b = 0;
#define X if (a) b = b + 1;
#define XX X X X X X X X X X X
#define XXX XX XX XX XX XX XX XX XX XX XX
#define XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX
#define X
#define XX X X X X X X X X X X
#define XXX XX XX XX XX XX XX XX XX XX
XX
XX
return b;
}
also relevant is the testcase from PR54492 which we should not regress.
[Bug fortran/54474] [4.8 Regression]: gfortran.dg/coarray_poly_3.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54474 Mikael Morin changed: What|Removed |Added Status|NEW |RESOLVED CC||mikael at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Mikael Morin 2012-09-05 13:37:37 UTC --- Fix committed.
[Bug tree-optimization/54492] [4.8 Regression] SLSR takes ages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54492 --- Comment #1 from Richard Guenther 2012-09-05 13:30:55 UTC --- Use -fno-guess-branch-probability.
[Bug middle-end/54493] New: -fguess-branch-probability takes ages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54493 Bug #: 54493 Summary: -fguess-branch-probability takes ages Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org For the testcase in PR54492 -fguess-branch-probability (default on at -O1) takes ages.
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #37 from Richard Guenther 2012-09-05 13:29:20 UTC --- Author: rguenth Date: Wed Sep 5 13:29:13 2012 New Revision: 190978 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190978 Log: 2012-09-05 Richard Guenther PR tree-optimization/46590 * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Do not update SSA form here. (canonicalize_induction_variables): Assert we do not need to update SSA form. (tree_unroll_loops_completely): Update SSA form here. * tree-ssa-loop-manip.c (gimple_duplicate_loop_to_header_edge): Do not verify loop-closed SSA form if SSA form is not up-to-date. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c trunk/gcc/tree-ssa-loop-manip.c
[Bug tree-optimization/54492] New: [4.8 Regression] SLSR takes ages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54492
Bug #: 54492
Summary: [4.8 Regression] SLSR takes ages
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: wschm...@gcc.gnu.org
For
int foo (int a, int b, int c)
{
int d;
switch (a)
{
#define X(N) \
case N ## 0: d = a + b; break; \
case N ## 1: d = a + b; break; \
case N ## 2: d = a + b; break; \
case N ## 3: d = a + b; break; \
case N ## 4: d = a + b; break; \
case N ## 5: d = a + b; break; \
case N ## 6: d = a + b; break; \
case N ## 7: d = a + b; break; \
case N ## 8: d = a + b; break; \
case N ## 9: d = a + b; break;
#define XX(N) \
X(N ## 0) X(N ## 1) X(N ## 2) X(N ## 3) X(N ## 4) X(N ## 5) X(N ## 6) X(N
## 7) X(N ## 8) X(N ## 9)
#define XXX(N) \
XX(N ## 0) XX(N ## 1) XX(N ## 2) XX(N ## 3) XX(N ## 4) XX(N ## 5) XX(N ##
6) XX(N ## 7) XX(N ## 8) XX(N ## 9)
#define (N) \
XXX(N ## 0) XXX(N ## 1) XXX(N ## 2) XXX(N ## 3) XXX(N ## 4) XXX(N ## 5)
XXX(N ## 6) XXX(N ## 7) XXX(N ## 8) XXX(N ## 9)
#define X(N) \
(N ## 0) (N ## 1) (N ## 2) (N ## 3) (N ## 4) (N ##
5) (N ## 6) (N ## 7) (N ## 8) (N ## 9)
X(1)
#if 0
X(2)
X(3)
X(4)
X(5)
X(6)
X(7)
X(8)
X(9)
#endif
}
return d;
}
I see SLSR taking all of the compile-time at -O1:
straight-line strength reduction: 195.66 (95%) usr 0.02 ( 2%) sys 196.32
(94%) wall 0 kB ( 0%) ggc
something must go wrong here (testcase for a FRE change I am doing ...)
[Bug fortran/54474] [4.8 Regression]: gfortran.dg/coarray_poly_3.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54474 --- Comment #4 from Mikael Morin 2012-09-05 13:27:08 UTC --- Author: mikael Date: Wed Sep 5 13:26:58 2012 New Revision: 190977 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190977 Log: 2012-09-05 Dominique Dhumieres PR fortran/54474 * gfortran.dg/coarray_poly_3.f90: Adjust error messages. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_poly_3.f90
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #36 from Ulrich Drepper 2012-09-05 13:25:21 UTC --- (In reply to comment #35) > What will happen if the assembly accept rdrand, but not the CPU? The code at runtime checks for the feature bit. There will be no problem. This is *exclusively* a problem with obsolete assemblers.
[Bug c/54491] New: interval membership optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54491
Bug #: 54491
Summary: interval membership optimization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nel...@seznam.cz
A common optimization to test range membership b \in [c,d] is to use integer
overflow as in function range below.
gcc does this optimization when both c and d are constants. However inlining
disables this optimization.
Same optimization can be automatically applied for c arbitrary expression and
d=c+positive_constant
unsigned int range(unsigned int b,unsigned int c){
if (b-c<=42) return c;
return b;
}
unsigned int foo(unsigned int b,unsigned int c){
if (c<=b && b <=42+c) return c;
return b;
}
unsigned int bar(unsigned int b){
return foo(b,42);
}
unsigned int baz(unsigned int b){
if (42<=b && b<=84) return 42;
return b;
}
.file "a.c"
.text
.p2align 4,,15
.globl range
.type range, @function
range:
.LFB0:
.cfi_startproc
movl %edi, %eax
subl %esi, %eax
cmpl $42, %eax
movl %esi, %eax
cmova %edi, %eax
ret
.cfi_endproc
.LFE0:
.size range, .-range
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB1:
.cfi_startproc
cmpl %edi, %esi
movl %edi, %eax
ja .L5
leal 42(%rsi), %edx
cmpl %edx, %edi
cmovbe %esi, %eax
.L5:
rep; ret
.cfi_endproc
.LFE1:
.size foo, .-foo
.p2align 4,,15
.globl bar
.type bar, @function
bar:
.LFB2:
.cfi_startproc
cmpl $41, %edi
movl %edi, %eax
jbe .L10
cmpl $85, %edi
movl $42, %edx
cmovb %edx, %eax
.L10:
rep; ret
.cfi_endproc
.LFE2:
.size bar, .-bar
.p2align 4,,15
.globl baz
.type baz, @function
baz:
.LFB3:
.cfi_startproc
leal -42(%rdi), %edx
movl $42, %eax
cmpl $42, %edx
cmova %edi, %eax
ret
.cfi_endproc
.LFE3:
.size baz, .-baz
.ident "GCC: (Debian 20120820-1) 4.8.0 20120820 (experimental) [trunk
revision 190537]"
.section .note.GNU-stack,"",@progbits
[Bug target/54461] [avr] add configure option for better AVR-Libc integration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54461 Georg-Johann Lay changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #4 from Georg-Johann Lay 2012-09-05 13:02:24 UTC --- *** Bug 28718 has been marked as a duplicate of this bug. ***
[Bug driver/28718] Call to -lgcc added prior to user libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #12 from Georg-Johann Lay 2012-09-05 13:02:24 UTC --- Not really a doublicate of PR54461, but the new configure option --with-avrlibc introduced in 4.7.2 solves the issue by removing the doublicate functions from libgcc so that the optimized versions from AVR-Libc will be used no matter how the -l order is. *** This bug has been marked as a duplicate of bug 54461 ***
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #35 from Dominique d'Humieres
2012-09-05 12:59:09 UTC ---
> No, the #c24 and #c25 comments make no sense at all.
My only claim is that they allow to bootstrap again my platform of choice.
> In void f(void) { asm ("rdrand %eax"); } rdrand shouldn't be optimized out, at
> least not by gcc, asm in this case is implicitly volatile.
As said in comment #24, the configure test yields ac_cv_x86_rdrand=yes. When
run manually, the test compiles without assembler error and looking at the
assembly, there is no rdrand in it. My naive explanation was that foo was never
generated, but if you have a better one, be my guest!-)
> AC_TRY_RUN is not
> desirable for many reasons, as has been said and you can read in the code, the
> runtime detection is done in libstdc++ code (ctor which uses cpuid), all
> configury should test is whether assembler is able to assemble rdrand.
What will happen if the assembly accept rdrand, but not the CPU?
> Furthermore, never patch configure, you need to patch configure.ac resp.
> configure.in instead.
I know that, but I don't know how to write *.ac or *.in stuff. Also my previous
attempts to use the auto* tools have left my tree in a total mess.
Now, I did not commit the patch responsible for this PR and I am quite upset
(to say the least) that the one who did it is doing very little to fix it
(remember that the problem occurs also on some machines in the gcc farm, so any
maintainer should be able to test a patch on a failing machine).
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #34 from Jakub Jelinek 2012-09-05
12:40:49 UTC ---
No, the #c24 and #c25 comments make no sense at all.
In void f(void) { asm ("rdrand %eax"); } rdrand shouldn't be optimized out, at
least not by gcc, asm in this case is implicitly volatile. AC_TRY_RUN is not
desirable for many reasons, as has been said and you can read in the code, the
runtime detection is done in libstdc++ code (ctor which uses cpuid), all
configury should test is whether assembler is able to assemble rdrand.
Furthermore, never patch configure, you need to patch configure.ac resp.
configure.in instead.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-05 CC||hjl.tools at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu 2012-09-05 12:40:59 UTC --- Same here on x86-64: http://gcc.gnu.org/ml/gcc-regression/2012-09/msg00080.html
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #33 from Dominique d'Humieres 2012-09-05 12:31:06 UTC --- > Er, did you read comment #26? Do comments #24 and #25 answer this question? > Jack says the configure test is being run with > clang, which if true looks like a bug. It is not the way I read Jack's comments. Due to my own bias, I read it as "the as provided by Xcode 4.4 support `rdrand %eax' even if it is not supported by the CPU which will run the code", hence my second patch in comment #25 which uses ac_fn_c_try_run. Indeed I am assuming that everything occurs for the target when doing a cross compilation. > (doesn't change the fact that this PR is about assembler support, but > sometimes > studying one bug unearths other bugs) If you can show that the compiler used for the tests in libstdc++-v3/configure is not the right one, please open a new PR.
[Bug c++/43122] g++ does not allow overloading operators for sse types (__m128, __m128d)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43122 --- Comment #10 from SergeyN 2012-09-05 12:24:49 UTC --- (In reply to comment #9) > Then put it into a class and add overloaded comparison operators for the > wrapper class. That is the same thing as with float/double, you can't > overload > float/double comparison operator either. Well, I'll of course find a way to workaround this issue by either using a class, or using a separate function like cmp_less or something like that. The point of this thread is that operator overloading for vector types doesn't not work in gcc, and not how to work around that (which I'm sure people have no problem doing given that the problem was reported 2 years ago). Sergey.
[Bug target/54461] [avr] add configure option for better AVR-Libc integration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54461 Georg-Johann Lay changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Georg-Johann Lay 2012-09-05 12:23:00 UTC --- Fixed in 4.7.2
[Bug target/54461] [avr] add configure option for better AVR-Libc integration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54461 --- Comment #2 from Georg-Johann Lay 2012-09-05 12:19:54 UTC --- Author: gjl Date: Wed Sep 5 12:19:47 2012 New Revision: 190973 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190973 Log: Backport from 2012-09-05 mainline r190697. PR target/54461 * configure.ac (noconfigdirs,target=avr-*-*): Add target-newlib, target-libgloss if configured --with-avrlibc. * configure: Regenerate. libgcc/ Backport from 2012-09-05 mainline r190697. PR target/54461 * config.host (tmake_file,host=avr-*-*): Add avr/t-avrlibc if configured --with-avrlibc. * Makefile.in (FPBIT_FUNCS): filter-out LIB2FUNCS_EXCLUDE. (DPBIT_FUNCS): Ditto. (TPBIT_FUNCS): Ditto. * config/avr/t-avrlibc: New file. gcc/ Backport from 2012-09-05 mainline r190697. PR target/54461 * config.gcc (tm_file,target=avr-*-*): Add avr/avrlibc.h if configured --with-avrlibc. (tm_defines,target=avr-*-*): Add WITH_AVRLIBC if configured --with-avrlibc. * config/avr/avrlibc.h: New file. * config/avr/avr-c.c: Build-in define __WITH_AVRLIBC__ if configured --with-avrlibc. * doc/invoke.texi (AVR Built-in Macros): Document __WITH_AVRLIBC__ Added: branches/gcc-4_7-branch/gcc/config/avr/avrlibc.h branches/gcc-4_7-branch/libgcc/config/avr/t-avrlibc Modified: branches/gcc-4_7-branch/ChangeLog branches/gcc-4_7-branch/configure branches/gcc-4_7-branch/configure.ac branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config.gcc branches/gcc-4_7-branch/gcc/config/avr/avr-c.c branches/gcc-4_7-branch/gcc/doc/invoke.texi branches/gcc-4_7-branch/libgcc/ChangeLog branches/gcc-4_7-branch/libgcc/Makefile.in branches/gcc-4_7-branch/libgcc/config.host
[Bug c++/43122] g++ does not allow overloading operators for sse types (__m128, __m128d)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43122 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek 2012-09-05 12:13:55 UTC --- Then put it into a class and add overloaded comparison operators for the wrapper class. That is the same thing as with float/double, you can't overload float/double comparison operator either.
[Bug other/54490] [4.7 Regression] ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-05 CC||eric.weddington at atmel ||dot com Ever Confirmed|0 |1
[Bug other/54490] New: ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490
Bug #: 54490
Summary: ICE: Spill failure in newlib build
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code, ra
Severity: major
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr
../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2
--enable-languages=c,c++ --enable-target-optspace=yes --enable-checking=rtl,yes
For this configure, the build aborts with a spill fail ICE if newlib is in the
source path. SVN is from today's (2012-09-05) gcc-4_7-branch
/home/georg/gnu/build/gcc-4.7-avr/./gcc/xgcc
-B/home/georg/gnu/build/gcc-4.7-avr/./gcc/ -nostdinc
-B/home/georg/gnu/build/gcc-4.7-avr/avr/avr25/newlib/ -isystem
/home/georg/gnu/build/gcc-4.7-avr/avr/avr25/newlib/targ-include -isystem
/home/georg/gnu/gcc.gnu.org/gcc-4_7-branch/newlib/libc/include
-B/home/georg/gnu/build/gcc-4.7-avr/avr/avr25/libgloss/avr
-L/home/georg/gnu/build/gcc-4.7-avr/avr/avr25/libgloss/libnosys
-L/home/georg/gnu/gcc.gnu.org/gcc-4_7-branch/libgloss/avr
-B/local/gnu/install/gcc-4.7/avr/bin/ -B/local/gnu/install/gcc-4.7/avr/lib/
-isystem /local/gnu/install/gcc-4.7/avr/include -isystem
/local/gnu/install/gcc-4.7/avr/sys-include -mmcu=avr25
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.18.0\" -DPACKAGE_STRING=\"newlib\ 1.18.0\"
-DPACKAGE_BUGREPORT=\"\" -I.
-I../../../../../../../gcc.gnu.org/gcc-4_7-branch/newlib/libc/stdlib -Os
-DPREFER_SIZE_OVER_SPEED -mcall-prologues -DNO_EXEC -DSMALL_MEMORY
-DMISSING_SYSCALL_NAMES -fno-builtin -g -Os -mmcu=avr25 -c -o
lib_a-mprec.o `test -f 'mprec.c' || echo
'../../../../../../../gcc.gnu.org/gcc-4_7-branch/newlib/libc/stdlib/'`mprec.c
../../../../../../../gcc.gnu.org/gcc-4_7-branch/newlib/libc/stdlib/mprec.c: In
function '__multiply':
../../../../../../../gcc.gnu.org/gcc-4_7-branch/newlib/libc/stdlib/mprec.c:419:1:
error: unable to find a register to spill in class 'POINTER_REGS'
../../../../../../../gcc.gnu.org/gcc-4_7-branch/newlib/libc/stdlib/mprec.c:419:1:
error: this is the insn:
(insn 98 97 101 12 (set (reg:SI 75 [ D.2858 ])
(mem:SI (post_inc:HI (reg:HI 16 r16 [orig:50 ivtmp.180 ] [50])) [16
MEM[base: D.3213_188, offset: 0B]+0 S4 A8]))
../../../../../../../gcc.gnu.org/gcc-4_7-branch/newlib/libc/stdlib/mprec.c:370
36 {*movsi}
(expr_list:REG_INC (reg:HI 16 r16 [orig:50 ivtmp.180 ] [50])
(nil)))
../../../../../../../gcc.gnu.org/gcc-4_7-branch/newlib/libc/stdlib/mprec.c:419:1:
internal compiler error: in spill_failure, at reload1.c:2120
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[8]: *** [lib_a-mprec.o] Error 1
make[8]: Leaving directory
`/local/gnu/build/gcc-4.7-avr/avr/avr25/newlib/libc/stdlib'
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory `/local/gnu/build/gcc-4.7-avr/avr/avr25/newlib/libc'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory `/local/gnu/build/gcc-4.7-avr/avr/avr25/newlib'
make[5]: *** [all] Error 2
make[5]: Leaving directory `/local/gnu/build/gcc-4.7-avr/avr/avr25/newlib'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory `/local/gnu/build/gcc-4.7-avr/avr/newlib'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory `/local/gnu/build/gcc-4.7-avr/avr/newlib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/local/gnu/build/gcc-4.7-avr/avr/newlib'
make[1]: *** [all-target-newlib] Error 2
make[1]: Leaving directory `/local/gnu/build/gcc-4.7-avr'
make: *** [all] Error 2
[Bug bootstrap/54484] r190927 breaks bootstrap with clang compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54484 --- Comment #5 from dnovillo at google dot com 2012-09-05 11:48:38 UTC --- On Wed, Sep 5, 2012 at 2:12 AM, glisse at gcc dot gnu.org wrote: > did you also take a look at the warning about lessthan_ in the clang messages? No. Clang's output was very noisy. I did not look at any warnings, just waited for the error that was preventing the build. Diego.
[Bug fortran/54462] [4.8 Regression] Another "segmentation fault" after an error in COMMON statement after r190853
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54462 --- Comment #2 from Dominique d'Humieres 2012-09-05 11:46:24 UTC --- Indeed the patch in comment #1 fixes the PR without regression.
[Bug c++/54483] undefined reference to static constexpr in .so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483 Paolo Carlini changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-09-05 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #4 from Paolo Carlini 2012-09-05 11:21:06 UTC --- Let's reopen this, then.
[Bug c++/54483] undefined reference to static constexpr in .so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483 --- Comment #3 from Daniel Krügler 2012-09-05 11:12:13 UTC --- (In reply to comment #1) > This is invalid as per [class.static.data]/3 : On C++11 level it should be valid, because odr-usage does not happen here according to [basic.def.odr] p3: "A variable x whose name appears as a potentially-evaluated expression ex is odr-used unless x is an object that satisfies the requirements for appearing in a constant expression (5.19) and ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion (4.1) is applied to e, or e is a discarded-value expression (Clause 5)."
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #36 from Richard Guenther 2012-09-05 10:59:52 UTC --- If I fix that (PR54489) by iterating over immediate dominators when querying AVAIL_OUT instead of accumulating then other loop opts quickly take over in compile-time, but memory usage stays reasonable at -O1. LIM is now the pass that pushes memory usage to 1.8GB - all other optimization passes are happy with just ~800MB. The issue with LIM is that it analyzes the whole function instead of working on outermost loops at a time (PR54488). Then of course IRA comes along and wrecks memory usage again ... (create_loop_tree_nodes). One can tame down IRA a bit using -fno-ira-loop-pressure -fira-region=one. We then arrive at roughly a constant 900MB memory usage for the full(!) testcase at -O1 and Execution times (seconds) phase opt and generate : 495.90 (99%) usr 1.98 (98%) sys 499.91 (99%) wall 870508 kB (92%) ggc df reaching defs: 19.16 ( 4%) usr 0.06 ( 3%) sys 19.18 ( 4%) wall 0 kB ( 0%) ggc alias stmt walking : 28.75 ( 6%) usr 0.21 (10%) sys 29.12 ( 6%) wall 2336 kB ( 0%) ggc tree SSA rewrite: 63.42 (13%) usr 0.02 ( 1%) sys 63.77 (13%) wall 18830 kB ( 2%) ggc tree SSA incremental: 74.64 (15%) usr 0.03 ( 1%) sys 74.44 (15%) wall 25886 kB ( 3%) ggc dominance frontiers : 101.71 (20%) usr 0.09 ( 4%) sys 102.17 (20%) wall 0 kB ( 0%) ggc dominance computation : 52.56 (11%) usr 0.09 ( 4%) sys 53.35 (11%) wall 0 kB ( 0%) ggc loop invariant motion : 101.20 (20%) usr 0.10 ( 5%) sys 101.75 (20%) wall 2700 kB ( 0%) ggc TOTAL : 498.79 2.03 502.87 947764 kB (all entries > 10s) The incremental SSA stuff is complete loop unrolling / IV canonicalization which does SSA update once per loop (similar to what loop header copying formerly did). Fixing that leads to Execution times (seconds) phase opt and generate : 214.62 (99%) usr 1.53 (96%) sys 217.41 (99%) wall 870508 kB (92%) ggc df reaching defs: 23.07 (11%) usr 0.01 ( 1%) sys 23.10 (10%) wall 0 kB ( 0%) ggc alias stmt walking : 28.51 (13%) usr 0.23 (14%) sys 28.93 (13%) wall 2336 kB ( 0%) ggc loop invariant motion : 105.43 (48%) usr 0.01 ( 1%) sys 106.22 (48%) wall 2700 kB ( 0%) ggc TOTAL : 217.56 1.59 220.44 947764 kB so RTL invariant motion is now the main offender ;)
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070 --- Comment #23 from amker at gcc dot gnu.org 2012-09-05 10:54:11 UTC --- Author: amker Date: Wed Sep 5 10:54:08 2012 New Revision: 190971 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190971 Log: Backport from 2012-09-04 mainline r190919 PR target/45070 * config/arm/arm.c (thumb1_extra_regs_pushed): Handle return value of size less than 4 bytes by using macro ARM_NUM_INTS. (thumb1_unexpanded_epilogue): Use macro ARM_NUM_INTS. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.c
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070 --- Comment #22 from amker at gcc dot gnu.org 2012-09-05 10:50:00 UTC --- Author: amker Date: Wed Sep 5 10:49:56 2012 New Revision: 190970 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190970 Log: Backport from 2012-09-04 mainline r190919 PR target/45070 * config/arm/arm.c (thumb1_extra_regs_pushed): Handle return value of size less than 4 bytes by using macro ARM_NUM_INTS. (thumb1_unexpanded_epilogue): Use macro ARM_NUM_INTS. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/arm/arm.c
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #32 from Marc Glisse 2012-09-05 10:46:35 UTC --- (In reply to comment #30) > > Er, why should this test ever be run with the system compiler? libstdc++ > > should > > only ever be built by a newly built g++. > > The problem is not with the compiler, but with the (target?) assembler and > possibly the target CPU. Er, did you read comment #26? Jack says the configure test is being run with clang, which if true looks like a bug. (doesn't change the fact that this PR is about assembler support, but sometimes studying one bug unearths other bugs)
[Bug middle-end/36041] Speed up builtin_popcountll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
José Salavert Torres changed:
What|Removed |Added
CC||jsalavert at gmail dot com
--- Comment #8 from José Salavert Torres
2012-09-05 10:39:45 UTC ---
Hello, there has been any advance in in this issue, Knuth's publication
approach would be great for 8 bit registers also.
Also, allowing different behaviour for each architecture would be better.
In the forums the implementation described here is now like this, seems to use
less operations:
inline unsigned int bitcount32(uint32_t i) {
//Parallel binary bit add
i = i - ((i >> 1) & 0x);
i = (i & 0x) + ((i >> 2) & 0x);
return (((i + (i >> 4)) & 0xF0F0F0F) * 0x1010101) >> 24;
}
//Parallel binary bit add
i = i - ((i >> 1) & 0x);
i = (i & 0x) + ((i >> 2) & 0x);
return (((i + (i >> 4)) & 0xF0F0F0F0F0F0F0F) * 0x101010101010101) >> 56;
}
[Bug tree-optimization/54489] New: tree FRE uses an excessive amount of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54489 Bug #: 54489 Summary: tree FRE uses an excessive amount of memory Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: memory-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org FRE can use an excessive amount of memory for storing AVAIL_OUT bitmaps needed for leader finding in eliminate (). The testcase of PR46590 does not fit into 4GB of memory because of this. The root cause is: /* Initially, the set of available values in BLOCK is that of its immediate dominator. */ dom = get_immediate_dominator (CDI_DOMINATORS, block); if (dom) bitmap_set_copy (AVAIL_OUT (block), AVAIL_OUT (dom)); basically accumulating at least all dominating SSA defs with different value-number in each basic-block. Instead of applying surgery to FRE in tree-ssa-pre.c FRE should be split out and unify eliminate () and avail computation in a dominator walk which would avoid keeping all AVAIL_OUT bitmaps live at a time.
[Bug c++/54191] [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Paolo Carlini 2012-09-05 10:28:05 UTC --- Fixed.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #8 from Paolo Carlini 2012-09-05 10:25:16 UTC --- I think we should identify when this changed and why. Then, we can certainly add the export (please send a regular patch to the library mailing list) but at a new minor version, thus CXXABI_1.3.7.
[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54463 --- Comment #5 from Tobias Burnus 2012-09-05 10:21:53 UTC --- (In reply to comment #1) > This bug report should be closed. Combining > -fexternal-blas and -fdefault-real-8 would > add needless complexity to the compiler. I think a patch like mine in comment 2 should be sufficient and it not that complex. > The correct solution is to write proper Fortran > code. To be even more specific, don't use > -fdefault-real-8. It was a really, really, > bad idea and was only supplied to give > backwards compatibility with g77. Well, many compilers have such a flag and there are several programs which rely on the presence of such a flag. It might not be the most sensible to write programs that way, but it is common enough that a compiler should support it. [Comment to my patch:] (In reply to comment #3) > What about -freal-4-real-10 -freal-4-real-16 -freal-4-real-8 > -freal-8-real-10 -freal-8-real-16 and -freal-8-real-4? Ugh, those flags are ugly! (Actually, I think you approved that patch, which I regard as worse than -fdefault-real-8.) the -freal-*-real-* flags completely messes up everything. However, since everything is handled in primary.c/decl.c, the internal kind numbers should be fine. (There are bits in trans-types.c, but they only error out when a given kind doesn't exist.) Of course, I assume that one doesn't mess around with -fdefault-real-8 or -freal-4-real-10 when compiling BLAS. If one does this, one gets what one deserves.
[Bug tree-optimization/54488] New: tree loop invariant motion uses an excessive amount of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 Bug #: 54488 Summary: tree loop invariant motion uses an excessive amount of memory Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: memory-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org LIM works on the whole function, gathering all memory accesses of all loops at a time instead of working on individual loop nests. For the testcase in PR46590 this uses 1GB of memory.
[Bug c++/54191] [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 --- Comment #6 from paolo at gcc dot gnu.org 2012-09-05 10:14:43 UTC --- Author: paolo Date: Wed Sep 5 10:14:37 2012 New Revision: 190969 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190969 Log: /cp 2012-09-05 Paolo Carlini PR c++/54191 * search.c (lookup_base): Add tsubst_flags_t parameter. (adjust_result_of_qualified_name_lookup, check_final_overrider): Adjust. * name-lookup.c (do_class_using_decl): Adjust. * typeck2.c (binfo_or_else, build_scoped_ref, build_m_component_ref): Likewise. * cvt.c (cp_convert_to_pointer, convert_to_pointer_force, build_up_reference): Likewise. * rtti.c (build_dynamic_cast_1): Likewise. * tree.c (maybe_dummy_object): Likewise. * call.c (build_conditional_expr_1, build_over_call): Likewise. * cp-tree.h (UNIQUELY_DERIVED_FROM_P, PUBLICLY_UNIQUELY_DERIVED_P): Remove. (enum base_access_flags, ba_quiet): Remove. (uniquely_derived_from_p, publicly_uniquely_derived_p): Declare. * except.c (can_convert_eh): Adjust. * decl.c (grokdeclarator): Likewise. * typeck.c (comp_except_types, build_class_member_access_expr, finish_class_member_access_expr, get_member_function_from_ptrfunc, build_static_cast_1, get_delta_difference_1): Likewise. * class.c (build_base_path, convert_to_base, build_vtbl_ref_1, warn_about_ambiguous_bases): Likewise. (uniquely_derived_from_p, publicly_uniquely_derived_p): Define. /testsuite 2012-09-05 Paolo Carlini PR c++/54191 * g++.dg/cpp0x/sfinae39.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cvt.c trunk/gcc/cp/decl.c trunk/gcc/cp/except.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/rtti.c trunk/gcc/cp/search.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #31 from Dominique d'Humieres 2012-09-05 09:45:08 UTC --- http://gcc.gnu.org/ml/gcc/2012-09/msg00025.html clock ticking;-(
[Bug c++/43122] g++ does not allow overloading operators for sse types (__m128, __m128d)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43122 --- Comment #8 from SergeyN 2012-09-05 09:42:58 UTC --- (In reply to comment #7) > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02098.html That's nice, but I would really prefer to define my own comparison operator, because the actual comparison instruction for __m256 and __m256d types has a way to control handling of nans, which wouldn't be allowed by a built-in comparison operator.
[Bug tree-optimization/54481] missed optimization: unnecessary indirect call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54481 --- Comment #2 from Ondrej Bilka 2012-09-05 09:42:27 UTC --- On Wed, Sep 05, 2012 at 09:30:04AM +, rguenth at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54481 > > Richard Guenther changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2012-09-05 > Component|c |tree-optimization > Ever Confirmed|0 |1 >Severity|normal |enhancement > > --- Comment #1 from Richard Guenther 2012-09-05 > 09:30:04 UTC --- > The issue is that a.fn(&a) is _not_ pure. foo is, but to see that a.fn is > always foo we'd have to know a.fn is always foo ... (we are not optimistically > assuming this which isn't easily possible within any of our memory > optimization > frameworks). > > Confirmed anyway, in theory it should be possible. Or allow pure attribute in function pointers that is now ignored. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #30 from Dominique d'Humieres 2012-09-05 09:39:17 UTC --- > Er, why should this test ever be run with the system compiler? libstdc++ > should > only ever be built by a newly built g++. The problem is not with the compiler, but with the (target?) assembler and possibly the target CPU.
[Bug tree-optimization/54000] [4.6/4.7/4.8 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000 Benedict Geihe changed: What|Removed |Added Attachment #27816|0 |1 is obsolete|| --- Comment #7 from Benedict Geihe 2012-09-05 09:32:27 UTC --- Created attachment 28132 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28132 preprocessed minimal example without std::vector
[Bug c++/43122] g++ does not allow overloading operators for sse types (__m128, __m128d)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43122 --- Comment #7 from Marc Glisse 2012-09-05 09:32:11 UTC --- http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02098.html
[Bug tree-optimization/54000] [4.6/4.7/4.8 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000 --- Comment #6 from Benedict Geihe 2012-09-05 09:30:05 UTC --- I originally reported that using a C array instead of STL's vector solves the problem. I am afraid that was wrong. I can also not remember what lead me to this conclusion. Anyway I attached a new minimal example without STL stuff. Hope it helps.
[Bug tree-optimization/54481] missed optimization: unnecessary indirect call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54481 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-05 Component|c |tree-optimization Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther 2012-09-05 09:30:04 UTC --- The issue is that a.fn(&a) is _not_ pure. foo is, but to see that a.fn is always foo we'd have to know a.fn is always foo ... (we are not optimistically assuming this which isn't easily possible within any of our memory optimization frameworks). Confirmed anyway, in theory it should be possible.
[Bug c++/54483] undefined reference to static constexpr in .so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther 2012-09-05 09:21:42 UTC --- .
[Bug c++/54485] g++ should diagnose default arguments in out-of-line definitions for template class member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54485 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-05 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-09-05 09:20:27 UTC --- Confirmed. Probably worth accepting with -fpermissive?
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 Richard Guenther changed: What|Removed |Added CC||tejohnson at google dot com --- Comment #1 from Richard Guenther 2012-09-05 09:18:41 UTC --- CCing author of patch.
[Bug target/54461] [avr] add configure option for better AVR-Libc integration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54461 --- Comment #1 from Georg-Johann Lay 2012-09-05 08:48:00 UTC --- Author: gjl Date: Wed Sep 5 08:47:50 2012 New Revision: 190967 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190967 Log: PR target/54461 * configure.ac (noconfigdirs,target=avr-*-*): Add target-newlib, target-libgloss if not configured --with-avrlibc=no. * configure: Regenerate. libgcc/ PR target/54461 * config.host (tmake_file,host=avr-*-*): Add avr/t-avrlibc if not configured --with-avrlibc=no. * config/avr/t-avrlibc: New file. * Makefile.in (FPBIT_FUNCS): filter-out LIB2FUNCS_EXCLUDE. (DPBIT_FUNCS): Ditto. (TPBIT_FUNCS): Ditto. gcc/ PR target/54461 * config.gcc (tm_file,target=avr-*-*): Add avr/avrlibc.h if not configured --with-avrlibc=no. (tm_defines,target=avr-*-*): Add WITH_AVRLIBC if not configured --with-avrlibc=no. * config/avr/avrlibc.h: New file. * config/avr/avr-c.c: Build-in define __WITH_AVRLIBC__ if not configured --with-avrlibc=no. * doc/invoke.texi (AVR Built-in Macros): Document __WITH_AVRLIBC__ Added: trunk/gcc/config/avr/avrlibc.h trunk/libgcc/config/avr/t-avrlibc Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/avr/avr-c.c trunk/gcc/doc/invoke.texi trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/config.host
[Bug regression/53964] regression: sparc64 FreeBSD: /usr/ports/lang/gcc46/work/build/./prev-gcc/include/stddef.h:150:26: error: two or more data types n declaration specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964 --- Comment #6 from Anton Shterenlikht 2012-09-05 08:44:00 UTC --- on 4.7 the error is slightly different: gmake[3]: Entering directory `/usr/ports/lang/gcc47/work/build/libcpp' /usr/ports/lang/gcc47/work/build/./prev-gcc/g++ -B/usr/ports/lang/gcc47/work/build/./prev-gcc/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -nostdinc++ -B/usr/ports/lang/gcc47/work/build/prev-sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs -B/usr/ports/lang/gcc47/work/build/prev-sparc64-portbld-freebsd10.0/libstdc++-v3/libsupc++/.libs -I/usr/ports/lang/gcc47/work/build/prev-sparc64-portbld-freebsd10.0/libstdc++-v3/include/sparc64-portbld-freebsd10.0 -I/usr/ports/lang/gcc47/work/build/prev-sparc64-portbld-freebsd10.0/libstdc++-v3/include -I/usr/ports/lang/gcc47/work/gcc-4.7-20120825/libstdc++-v3/libsupc++ -L/usr/ports/lang/gcc47/work/build/prev-sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs -L/usr/ports/lang/gcc47/work/build/prev-sparc64-portbld-freebsd10.0/libstdc++-v3/libsupc++/.libs -I.././../gcc-4.7-20120825/libcpp -I. -I.././../gcc-4.7-20120825/libcpp/../include -I.././../gcc-4.7-20120825/libcpp/include -g -O2 -gtoggle -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I.././../gcc-4.7-20120825/libcpp -I. -I.././../gcc-4.7-20120825/libcpp/../include -I.././../gcc-4.7-20120825/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo .././../gcc-4.7-20120825/libcpp/charset.c In file included from .././../gcc-4.7-20120825/libcpp/system.h:30:0, from .././../gcc-4.7-20120825/libcpp/charset.c:22: /usr/ports/lang/gcc47/work/build/./prev-gcc/include/stddef.h:150:26: error: multiple types in one declaration /usr/ports/lang/gcc47/work/build/./prev-gcc/include/stddef.h:150:26: error: declaration does not declare anything [-fpermissive]
