[Bug middle-end/53922] VRP: semantic conflict between range_includes_zero_p and value_inside_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Guenther 2012-07-11 07:35:38 UTC --- The disparity between those functions is a (documented) red herring. Are you saying we miscompile something here?
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-11 Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther 2012-07-11 07:38:01 UTC --- Confirmed.
[Bug other/53918] Incorrect version for cloog-ppl listed in prerequisites.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53918 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-11 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-07-11 07:41:17 UTC --- The instructions point to cloog-0.17.0, I don't see any pointers to cloog-ppl.
[Bug gcov-profile/53915] gcov can call format_gcov with top > bottom, which is unexpected and gives 99.99%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-11 CC||nathan at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther 2012-07-11 07:44:31 UTC --- Confirmed.
[Bug middle-end/53922] VRP: semantic conflict between range_includes_zero_p and value_inside_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922
--- Comment #2 from amker.cheng 2012-07-11
08:03:11 UTC ---
Yes, the dump before pass vrp2 is like:
main ()
{
int (*) (int) cstore.6;
int g.2;
int g.0;
:
g.0_1 = g;
if (g.0_1 != 0)
goto ;
else
goto ;
:
:
# cstore.6_9 = PHI
scan_func = cstore.6_9;
if (cstore.6_9 != 0B)
goto ;
else
goto ;
:
g.2_4 = cstore.6_9 (10);
g = g.2_4;
:
return 0;
}
gcc parses "# cstore.6_9 = PHI " and asserts that cstore.6_9
non-zero, then folds predicate cstore.6_9 != 0B to 1, which is wrong, because
weak symbol y could be zero.
[Bug rtl-optimization/53908] [4.6/4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 H.J. Lu changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #7 from H.J. Lu 2012-07-11 08:04:48 UTC --- It is caused by revision 167779: http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00461.html
[Bug target/53859] ICE when calculate insn latency for armv7e-m arch in O2 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859 --- Comment #4 from gretay at gcc dot gnu.org 2012-07-11 08:41:43 UTC --- Author: gretay Date: Wed Jul 11 08:41:37 2012 New Revision: 189423 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189423 Log: 2012-07-10 Greta Yorsh gcc/ PR target/53859 * config/arm/arm.c (arm_early_load_addr_dep): Handle new epilogue patterns. gcc/testsuite PR target/53859 * gcc.target/arm/pr53859.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr53859.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 --- Comment #16 from chrbr at gcc dot gnu.org 2012-07-11 09:05:03 UTC --- humm I forgot about this case. It works in one of my dev branches, Let me extract the uncommitted change and send it to gcc-patches. Cheers Christian (In reply to comment #15) > Created attachment 27754 [details] > combine pass based patch > > A possible combine pass based solution for the problem. > It fixes the case mentioned in the original description. > > I've also briefly checked some CSiBE code size results with this > patch applied to rev 189338 for '-m4-single -ml -O2 -mpretend-cmove'. > It hits only a few spots, but if those are buried inside loops, it might > be a win. > > I'm not sure what's the best thing to do if the mov.l displacement > goes out of range... > > Chris, I know it's been a while but any old memories? :) (In reply to comment #15) > Created attachment 27754 [details] > combine pass based patch > > A possible combine pass based solution for the problem. > It fixes the case mentioned in the original description. > > I've also briefly checked some CSiBE code size results with this > patch applied to rev 189338 for '-m4-single -ml -O2 -mpretend-cmove'. > It hits only a few spots, but if those are buried inside loops, it might > be a win. > > I'm not sure what's the best thing to do if the mov.l displacement > goes out of range... > > Chris, I know it's been a while but any old memories? :)
[Bug other/53923] New: ICE: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53923 Bug #: 53923 Summary: ICE: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build, ice-checking Severity: blocker Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr trunk 189422 from 2012-07-11 ICEs while building libgcc /home/georg/gnu/build/gcc-trunk-avr/./gcc/xgcc -B/home/georg/gnu/build/gcc-trunk-avr/./gcc/ -B/local/gnu/install/gcc-4.8/avr/bin/ -B/local/gnu/install/gcc-4.8/avr/lib/ -isystem /local/gnu/install/gcc-4.8/avr/include -isystem /local/gnu/install/gcc-4.8/avr/sys-include-g -Os -mmcu=avr25 -O2 -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -Os -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -DDF=SF -Dinhibit_libc -mcall-prologues -Os -I. -I. -I../../.././gcc -I../../../../../gcc.gnu.org/trunk/libgcc -I../../../../../gcc.gnu.org/trunk/libgcc/. -I../../../../../gcc.gnu.org/trunk/libgcc/../gcc -I../../../../../gcc.gnu.org/trunk/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _mulsc3.o -MT _mulsc3.o -MD -MP -MF _mulsc3.dep -DL_mulsc3 -c ../../../../../gcc.gnu.org/trunk/libgcc/libgcc2.c ../../../../../gcc.gnu.org/trunk/libgcc/libgcc2.c: In function '__mulsc3': ../../../../../gcc.gnu.org/trunk/libgcc/libgcc2.c:1929:1: internal compiler error: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091 ../../../../../gcc.gnu.org/trunk/libgcc/libgcc2.c:1929:1: internal compiler error: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091 == configure == ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2 --enable-checking=yes,rtl --enable-languages=c,c++ --enable-target-optspace=yes
[Bug other/53923] ICE: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53923 --- Comment #1 from Georg-Johann Lay 2012-07-11 09:27:26 UTC --- Created attachment 27773 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27773 libgcc2-mulsc3.c: preprocessed bit of libgcc2.c compile with avr-gcc libgcc2-mulsc3.c -c -mmcu=avr25 -Os -g -mcall-prologues
[Bug other/53923] ICE: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53923 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-11 CC||eric.weddington at atmel ||dot com Ever Confirmed|0 |1
[Bug rtl-optimization/53908] [4.6/4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 --- Comment #8 from Mikael Pettersson 2012-07-11 09:46:06 UTC --- Backporting r186159 and its followup fix r186164 to 4.7.1 was easy and fixed the test case there too (untested beyond this test case). Backporting those revisions to 4.6.3 required more elbow grease but didn't fix the test case there. I'm going to test the 4.7 backport properly now, in case a smaller more direct fix doesn't emerge soon.
[Bug other/53923] ICE: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53923
--- Comment #2 from Georg-Johann Lay 2012-07-11
10:03:49 UTC ---
avr.c already contains code to work around problems from DCE, instead of DCE
working out proper solutions to cover AVR, see PR50063
Something goes wrong in
df-problems.c:dead_debug_insert_temp
(insn 328 886 866 37 (set (reg:SF 16 r16)
(unspec:SF [
(reg:SF 16 r16)
(reg/v:SF 4 r4 [orig:162 b ] [162])
] UNSPEC_COPYSIGN)) libgcc2-mulsc3.c:1307 322 {copysignsf3}
(expr_list:REG_DEAD (reg/v:SF 4 r4 [orig:162 b ] [162])
(expr_list:REG_DEAD (reg/v:SF 4 r4 [orig:162 b ] [162])
(expr_list:REG_EQUAL (unspec:SF [
(const_double:SF 0 [0] 0.0 [0x0.0p+0])
(reg/v:SF 4 r4 [orig:162 b ] [162])
] UNSPEC_COPYSIGN)
(nil)
There is this code that sets reg from NULL to garbage (debug_expr:SF D#2)
/* Move all uses of uregno from debug->head to uses, setting mode to
the widest referenced mode. */
while ((cur = *tailp))
{
if (DF_REF_REGNO (cur->use) == uregno)
{
*usesp = cur;
usesp = &cur->next;
*tailp = cur->next;
cur->next = NULL;
if (!reg
|| (GET_MODE_BITSIZE (GET_MODE (reg))
< GET_MODE_BITSIZE (GET_MODE (*DF_REF_REAL_LOC (cur->use)
reg = *DF_REF_REAL_LOC (cur->use);
[Bug middle-end/53922] VRP: semantic conflict between range_includes_zero_p and value_inside_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922
--- Comment #3 from amker.cheng 2012-07-11
10:12:24 UTC ---
vrp processes PHI node " # cstore.6_9 = PHI " in calling sequence:
vrp_visit_phi_node
-> vrp_meet
When gcc gives up in function vrp_meet, it executes following code to derive an
anti-range against zero:
give_up:
/* Failed to find an efficient meet. Before giving up and setting
the result to VARYING, see if we can at least derive a useful
anti-range. FIXME, all this nonsense about distinguishing
anti-ranges from ranges is necessary because of the odd
semantics of range_includes_zero_p and friends. */
if (!symbolic_range_p (vr0)
&& ((vr0->type == VR_RANGE && !range_includes_zero_p (vr0))
|| (vr0->type == VR_ANTI_RANGE && range_includes_zero_p (vr0)))
&& !symbolic_range_p (vr1)
&& ((vr1->type == VR_RANGE && !range_includes_zero_p (vr1))
|| (vr1->type == VR_ANTI_RANGE && range_includes_zero_p (vr1
{
set_value_range_to_nonnull (vr0, TREE_TYPE (vr0->min));
/* Since this meet operation did not result from the meeting of
two equivalent names, VR0 cannot have any equivalences. */
if (vr0->equiv)
bitmap_clear (vr0->equiv);
}
Here vr0 is for "x" in source code, while vr1 for "y" in source code, which is
a weak symbol.
function range_includes_zero_p check whether vr1 includes zero by calling
value_inside_range. The value_inside_range works well by returning -2, because
of the WEAK symbol. After that, range_includes_zero_p checks whether return
value of value_inside_range equals 1. Finally in vrp_meet, condition
"((vr1->type == VR_RANGE && !range_includes_zero_p (vr1))" holds, resulting in
gcc asserting cstore.6_9 non-zero.
Am I missing something?
[Bug c/53924] New: unhelpful diagnostic in invalid declaration list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53924 Bug #: 53924 Summary: unhelpful diagnostic in invalid declaration list Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ste...@gcc.gnu.org The C front end gives a really unhelpful error message for the most trivial mistakes. This is one example: $ cat t.c typedef void *tree; tree klass, tree cdecl, class_array_type; $ ./cc1 -quiet t.c t.c:2:18: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cdecl' tree klass, tree cdecl, class_array_type; ^ $ The parser should be able to recover from this error more gracefully.
[Bug c/53924] unhelpful diagnostic in invalid declaration list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53924 Steven Bosscher changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #1 from Steven Bosscher 2012-07-11 10:31:31 UTC --- Adding C front end maintainer to CC:
[Bug other/53925] New: dbgcnt.c:dbg_cnt_set_limit_by_index emits diagnostic via fprintf (stderr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53925
Bug #: 53925
Summary: dbgcnt.c:dbg_cnt_set_limit_by_index emits diagnostic
via fprintf (stderr
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
There is this code in dbgcnt.c
static void
dbg_cnt_set_limit_by_index (enum debug_counter index, int value)
{
limit[index] = value;
fprintf (stderr, "dbg_cnt '%s' set to %d\n", map[index].name, value);
}
If the user specifies -fdbg-cnt= that will trigger a diagnostic output.
IMO setting an option should not emit a diagnose, except in the case when the
user explicitly requests so, e.g. by means of -dbg-cnt-list, -print-multi-lib,
etc.
The fprintf (stderr should be removed or print to a dump file.
== Command line to reproduce ==
echo | gcc -fdbg-cnt=dce:0 -x c - -c
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 John David Anglin changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #1 from John David Anglin 2012-07-11 10:50:57 UTC --- Introduced in revision 188786.
[Bug c++/53926] New: g++ fails to compile valid template code with casting to QVariant and back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53926
Bug #: 53926
Summary: g++ fails to compile valid template code with casting
to QVariant and back
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a.matveya...@gmail.com
Trying to compile the following code:
#include
template
void bug (const T& default_value)
{
QSettings settings;
settings.value ("foo", default_value).value ();
}
results in compilation failure:
$ gcc -I/usr/include/qt4 -c gcc-bug.cpp
gcc-bug.cpp: In function ‘void bug(const T&)’:
gcc-bug.cpp:7:49: error: expected primary-expression before ‘>’ token
gcc-bug.cpp:7:52: error: expected primary-expression before ‘)’ token
The error can be reproduced in a small code piece without any includes:
class Variant
{
public:
Variant (int) { }
template
T value () const { return T (); }
};
template
Variant get_variant (const T& x)
{
return Variant (x);
}
template
void bug (const T& x)
{
get_variant (x).value ();
}
$ gcc -I/usr/include/qt4 -c gcc-bug.cpp
gcc-bug.cpp: In function ‘void bug(const T&)’:
gcc-bug.cpp:19:27: error: expected primary-expression before ‘>’ token
gcc-bug.cpp:19:30: error: expected primary-expression before ‘)’ token
Splitting the line
get_variant (x).value ();
into
Variant tmp = get_variant (x);
tmp.value ();
eliminates the error.
The error is reproducible in 4.2.4, 4.5.1, 4.6.3 and 4.8.1 prerelease versions.
ICC & MSVC compile these examples without errors or warnings.
[Bug c++/53926] g++ fails to compile valid template code with casting to QVariant and back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53926 --- Comment #1 from Jonathan Wakely 2012-07-11 11:36:09 UTC --- It's not valid code, you ned to say foo().template value() http://womble.decadent.org.uk/c++/template-faq.html#disambiguation
[Bug tree-optimization/53922] VRP: semantic conflict between range_includes_zero_p and value_inside_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922 Richard Guenther changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-11 Component|middle-end |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther 2012-07-11 11:36:09 UTC --- The issue is that range_includes_zero_p can not return "I don't know" and dependent on the use the conservative answer is wrong. Let me fix this.
[Bug c++/53926] g++ fails to compile valid template code with casting to QVariant and back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53926 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely 2012-07-11 11:38:40 UTC --- ICC probably only accepts it in MSVC-compatible mode. Try it at http://www.comeaucomputing.com/tryitout/ (the EDG front-end used by ICC, but in strict mode) or http://llvm.org/demo/ and you'll get the same error (but with clearer diagnostics than G++ gives)
[Bug c++/53926] g++ fails to compile valid template code with casting to QVariant and back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53926 Andrey Matveyakin changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #3 from Andrey Matveyakin 2012-07-11 11:49:56 UTC --- Thank you. Sorry for my mistake.
[Bug c++/53926] g++ fails to compile valid template code with casting to QVariant and back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53926 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely 2012-07-11 12:06:35 UTC --- .
[Bug tree-optimization/53922] VRP: semantic conflict between range_includes_zero_p and value_inside_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922 --- Comment #5 from Richard Guenther 2012-07-11 12:28:57 UTC --- Created attachment 27774 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27774 untested patch
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 --- Comment #17 from chrbr at gcc dot gnu.org 2012-07-11 12:35:32 UTC --- Created attachment 27775 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27775 plus add combine Here is the patch that I've been running since some time, it also use the same combine pattern matcher, but the goal of this patch was originally to fix up chains of multiple mult-add instructions. Optimizing the cst+reg addressing mode appears as a nice effects. Out of range indexes seems to be handled as afar as I can see. This brings a EEMBC telecom speedup of 10%.FFMPEG code size reduced to 30% on a few objects. Validated on whole linux distribution, with only improvements (few regression only bellow noise). This patch is only for comments/illustration. Need a few polishing before proposing. I'm having a look at your implementation to see how they compare and possibly combined together. Both approaches look interesting.
[Bug rtl-optimization/53908] [4.6/4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 H.J. Lu changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg00410.htm ||l --- Comment #9 from H.J. Lu 2012-07-11 12:38:16 UTC --- The fix is posted at http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00410.html
[Bug target/53689] [SH] GCC emits an invalid slot instruction for RTE (Return from Exception)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53689 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #2 from chrbr at gcc dot gnu.org 2012-07-11 12:59:06 UTC --- (In reply to comment #1) > (In reply to comment #0) > > Under target (sh-elf) big-endian SuperH-2 (SH7604) (options -m2 -mb > I've checked this case with SVN rev 189268 (GCC 4.8) and this problem is not > present. are you sure ? using sh-superh-elf-gcc -O2 a.c -S -fno-omit-frame-pointer I also see the frame pointer restored from the delay slot. Is it only a -m2 problem ?
[Bug target/53689] [SH] GCC emits an invalid slot instruction for RTE (Return from Exception)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53689 --- Comment #3 from Oleg Endo 2012-07-11 13:05:59 UTC --- (In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Under target (sh-elf) big-endian SuperH-2 (SH7604) (options -m2 -mb > > > I've checked this case with SVN rev 189268 (GCC 4.8) and this problem is not > > present. > > are you sure ? > > using sh-superh-elf-gcc -O2 a.c -S -fno-omit-frame-pointer > > I also see the frame pointer restored from the delay slot. Is it only a -m2 > problem ? I'm not sure how sh-superh-elf-gcc is configured. Does it use -m4 as default? If so, on SH4 it should be OK to do so, because the RTE instruction does only SSR -> SR, SPC -> PC and does not access or modify r15 / @r15.
[Bug debug/53927] New: wrong value for DW_AT_static_link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
Bug #: 53927
Summary: wrong value for DW_AT_static_link
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org
Compile this program with -g:
typedef int compute_function (int);
int nestee (compute_function *computer, int arg, int self_call)
{
int nested (int nested_arg)
{
return nested_arg + 23 + self_call;/* Break here */
}
if (self_call)
arg = nestee (nested, arg + 5, 0);
return computer (arg);
}
int misc (int arg)
{
return 0;
}
int main(int argc, char **argv)
{
nestee (misc, 5, 1);
return 0;
}
.debug_info says:
<2><8b>: Abbrev Number: 9 (DW_TAG_subprogram)
<8c> DW_AT_name: (indirect string, offset: 0xe6): nested
<90> DW_AT_decl_file : 1
<91> DW_AT_decl_line : 5
<92> DW_AT_prototyped : 1
<92> DW_AT_type: <0x47>
<96> DW_AT_low_pc : 0x4004b4
<9e> DW_AT_high_pc : 0x4004ca
DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
DW_AT_static_link : 1 byte block: 50 (DW_OP_reg0 (rax))
DW_AT_GNU_all_call_sites: 1
DW_AT_sibling : <0xcb>
That is, the static link is $rax.
In gdb I set a breakpoint at line 7 and ran the program. Then:
(gdb) p/x $rax
$8 = 0x7fffe400
Now I go up a couple of frames to the relevant (outermost) invocation
of nestee:
(gdb) p /x $pc
$9 = 0x40052c
And then from the frame info:
0080 001c 0084 FDE cie= pc=0040053c..0040054a
LOC CFA rbp ra
0040053c rsp+8u c-8
0040053d rsp+16 c-16 c-8
00400540 rbp+16 c-16 c-8
00400549 rsp+8c-16 c-8
So I think the CFA in this frame is $rsp+8.
But in gdb:
(gdb) p /x $rsp+8
$10 = 0x7fffe3f8
... which is different from the DW_AT_static_link.
nestee does specify that its frame base is the CFA:
<1><4e>: Abbrev Number: 6 (DW_TAG_subprogram)
<4f> DW_AT_external: 1
<4f> DW_AT_name: (indirect string, offset: 0xed): nestee
<53> DW_AT_decl_file : 1
<54> DW_AT_decl_line : 3
<55> DW_AT_prototyped : 1
<55> DW_AT_type: <0x47>
<59> DW_AT_low_pc : 0x4004ca
<61> DW_AT_high_pc : 0x40053c
<69> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
So, I think this is a GCC bug.
[Bug target/53689] [SH] GCC emits an invalid slot instruction for RTE (Return from Exception)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53689 --- Comment #4 from chrbr at gcc dot gnu.org 2012-07-11 13:21:22 UTC --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > (In reply to comment #0) > > > > Under target (sh-elf) big-endian SuperH-2 (SH7604) (options -m2 -mb > > > > > I've checked this case with SVN rev 189268 (GCC 4.8) and this problem is > > > not > > > present. > > > > are you sure ? > > > > using sh-superh-elf-gcc -O2 a.c -S -fno-omit-frame-pointer > > > > I also see the frame pointer restored from the delay slot. Is it only a -m2 > > problem ? > > I'm not sure how sh-superh-elf-gcc is configured. Does it use -m4 as default? > If so, on SH4 it should be OK to do so, because the RTE instruction does only > SSR -> SR, SPC -> PC and does not access or modify r15 / @r15. You are right, the sequence is valid for sh4, but not for sh2. I didn't check with -m2 so your checking was correct.
[Bug other/53928] New: use tar.xz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53928 Bug #: 53928 Summary: use tar.xz Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com xz has better compression than bz2 59740 kBgcc-4.7.1.tar.xz 80708 kBgcc-4.7.1.tar.bz2
[Bug other/53928] use tar.xz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53928 --- Comment #1 from Jonathan Wakely 2012-07-11 14:03:04 UTC --- c.f. http://gcc.gnu.org/ml/gcc/2012-03/msg00549.html
[Bug bootstrap/53912] [4.7 Regression] bootstrap fails at stage 2 with error: cast from 'void*' to 'long int' loses precision in ggc-common.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #1 from Rainer Emrich 2012-07-11 14:07:17 UTC --- Created attachment 27776 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27776 preprocessed source I assume for trunk there is the same issue, because ggc-common.c hasn't changed
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 --- Comment #18 from Oleg Endo 2012-07-11 15:09:02 UTC --- (In reply to comment #17) > Created attachment 27775 [details] > plus add combine > > Here is the patch that I've been running since some time, it also use the same > combine pattern matcher, but the goal of this patch was originally to fix up > chains of multiple mult-add instructions. > Optimizing the cst+reg addressing mode appears as a nice effects. Out of range > indexes seems to be handled as afar as I can see. > > This brings a EEMBC telecom speedup of 10%.FFMPEG code size reduced to 30% on > a > few objects. > Validated on whole linux distribution, with only improvements (few regression > only bellow noise). Interesting. BTW, do you happen to have any (runtime) numbers for GCC 4.7.x vs current GCC 4.8? > This patch is only for comments/illustration. Need a few polishing before > proposing. I'm having a look at your implementation to see how they compare > and > possibly combined together. Both approaches look interesting. I guess folding the mul-add sequences like you did should be more useful than just handling one mem:SI pattern. In any case, if you find my impl useful please let me know, because then I'd also pop in patterns for mem:QI and mem:HI patterns.
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 --- Comment #19 from chrbr at gcc dot gnu.org 2012-07-11 15:24:27 UTC --- (In reply to comment #18) > (In reply to comment #17) > > Created attachment 27775 [details] > > plus add combine > > > > Here is the patch that I've been running since some time, it also use the > > same > > combine pattern matcher, but the goal of this patch was originally to fix up > > chains of multiple mult-add instructions. > > Optimizing the cst+reg addressing mode appears as a nice effects. Out of > > range > > indexes seems to be handled as afar as I can see. > > > > This brings a EEMBC telecom speedup of 10%.FFMPEG code size reduced to 30% > > on a > > few objects. > > Validated on whole linux distribution, with only improvements (few > > regression > > only bellow noise). > > Interesting. > BTW, do you happen to have any (runtime) numbers for GCC 4.7.x vs current GCC > 4.8? > for now I only track the 4.6 and 4.7 branches. the 4.8 is moving too fast, but I could easily cheery-pick your the other SH changes (like your fix for PR53911) btw I only bench on the SH4 and SH4A. > > This patch is only for comments/illustration. Need a few polishing before > > proposing. I'm having a look at your implementation to see how they compare > > and > > possibly combined together. Both approaches look interesting. > > I guess folding the mul-add sequences like you did should be more useful than > just > handling one mem:SI pattern. In any case, if you find my impl useful please > let me know, > because then I'd also pop in patterns for mem:QI and mem:HI patterns. sure. by the way, my patch is not complete to fix the original problem. I need to extract other chunks that unleash it. Will post.
[Bug c/53929] New: Bug in the use of Intel asm syntax when a global is named "and"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
Bug #: 53929
Summary: Bug in the use of Intel asm syntax when a global is
named "and"
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: louis.granboulan.develo...@gmail.com
The bug is quite simple: when using -masm=intel and a global named "and", as
does not accept the output of the compiler.
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
preprocessed file is
--- cut begin ---
# 1 "a.c"
# 1 ""
# 1 ""
# 1 "a.c"
int and = 0;
int main()
{
return and;
}
--- cut end ---
compiler output is
--- cut begin ---
gcc -v -masm=intel -save-temps a.c
Utilisation des specs internes.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Modèle de thread: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-masm=intel' '-save-temps' '-mtune=generic'
'-march=i686'
/usr/lib/gcc/i686-linux-gnu/4.6/cc1 -E -quiet -v -imultilib . -imultiarch
i386-linux-gnu a.c -masm=intel -mtune=generic -march=i686 -fpch-preprocess
-fstack-protector -o a.i
le répertoire « /usr/local/include/i386-linux-gnu » est ignoré car inexistant
le répertoire «
/usr/lib/gcc/i686-linux-gnu/4.6/../../../../i686-linux-gnu/include » est ignoré
car inexistant
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:
/usr/lib/gcc/i686-linux-gnu/4.6/include
/usr/local/include
/usr/lib/gcc/i686-linux-gnu/4.6/include-fixed
/usr/include/i386-linux-gnu
/usr/include
Fin de la liste de recherche.
COLLECT_GCC_OPTIONS='-v' '-masm=intel' '-save-temps' '-mtune=generic'
'-march=i686'
/usr/lib/gcc/i686-linux-gnu/4.6/cc1 -fpreprocessed a.i -quiet -dumpbase a.c
-masm=intel -mtune=generic -march=i686 -auxbase a -version -fstack-protector -o
a.s
GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 09c248eab598b9e2acb117da4cdbd785
COLLECT_GCC_OPTIONS='-v' '-masm=intel' '-save-temps' '-mtune=generic'
'-march=i686'
as --32 -o a.o a.s
a.s: Assembler messages:
a.s:21: Error: invalid use of operator "and"
--- cut end ---
[Bug c++/53930] New: bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
Bug #: 53930
Summary: bug in linker
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bespalo...@gmail.com
Created attachment 2
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=2
archive with source files
I encounter it in number of versions, on number of platforms: 4.5.3 on gentoo,
4.6.2 on cygwin.
The problem's description: sequence of files listed in g++ as input file - does
matter. I have 2 cpps (file1 and file2), each has own implementation of struct
A. In main.cpp I call test1() from file1.cpp, which has following
implementation:
void test1()
{
A a;
}
The problem is that if I have following build command:
g++ -o test -I. main.cpp file2.cpp file1.cpp -Wall -Wextra
(take attention: file2.cpp precedes file1.cpp) - test1 actually gets A
implementation from test2.cpp.
If I change build command in way when file1.cpp precedes file2.cpp, test1 gets
own (right) implementation of A:
g++ -o test -I. main.cpp file1.cpp file2.cpp -Wall -Wextra
This is wrong, since order of cpp files in the input list of g++ should not
change the resulting code.
I've attached the sample. There is the following commands for build:
g++ -o test1 -I. main.cpp file2.cpp file1.cpp -Wall -Wextra
g++ -o test2 -I. main.cpp file1.cpp file2.cpp -Wall -Wextra
Although the files are same, test1 and test2 has different behavior.
platform:
uname -a
Linux SONY 3.3.8-gentoo #1 SMP Tue Jul 10 06:15:45 MSK 2012 x86_64 Intel(R)
Pentium(R) CPU B940 @ 2.00GHz GenuineIntel GNU/Linux
gcc --version
gcc (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Regards,
Dmitry.
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-07-11 19:16:24 UTC --- You are violating C++'s one definition rule. That is there is only one definition of the struct if they differ in implementation, the behavior is undefined.
[Bug c++/53921] [C++0x] ICE on lambda inside method of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53921 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-07-11 19:48:17 UTC --- The problem also exists in gcc 4.8.0 20120708 (experimental)
[Bug rtl-optimization/11708] [sh4-elf-gcc] Non-Optimal jump code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11708 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #7 from Oleg Endo 2012-07-11 20:56:00 UTC --- As of rev. 189427 this seems to have improved. At least I could not spot branch sequences such as ! basic block 1 cmp/pl r3 mov.w .L147,r1 bt .L3 <--- conditional branch C1 mov #0,r1 bra .L208 <--- Branch B1 mov r1,r3 <--- delay slot .L3: ! basic block 2 mov r1,r3 .L208: mov.w .L149,r2 mov.w .L150,r1 cmp/gt r1,r3 bt .L7 However, there are a couple of sequences such as: cmp/gtr2,r1 bt.L47 bra.L43 nop! 1189 .L47: mov.w.L105,r0 which would be better as: cmp/gtr2,r1 bt.L47 bra.L43 .L47: nop mov.w.L105,r0 to utilize zero-displacement branches.
[Bug c++/53931] New: [C++11] braced function style cast to reference should be prvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53931
Bug #: 53931
Summary: [C++11] braced function style cast to reference should
be prvalue
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
C++2011 5.2.3 [expr.type.conv] paragraph 3:
Similarly, a simple-type-specifier or typename-specifier followed by
a braced-init-list creates a temporary object of the specified type
direct-list-initialized (8.5.4) with the specified braced-init-list,
and its value is that temporary object as a prvalue.
In the case below, a braced function-style cast to an rvalue reference type
does not behave the same as a prvalue literal with GCC.
### Self-contained source (refBraceCast.cc):> cat refBraceCast.cc
typedef int &&ir;
void bar(int x) { const_cast(ir{x}); }
//void zip(int x) { const_cast(0); } // fails as expected
### Compiler invocation:
g++-4.7.0 -c -std=c++11 refBraceCast.cc; echo rc=$?
### Compiler output:
rc=0
### g++ -v output:> g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.7.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc
--program-suffix=-4.7.0 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --enable-shared --enable-__cxa_atexit
--enable-threads=posix --enable-languages=c,c++,fortran --with-mpfr=/usr/local/
--with-mpc=/usr/local/ --with-gmp=/usr/local/
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug target/51241] SH Target: Unnecessary sign/zero extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51241 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||olegendo at gcc dot gnu.org Resolution||WORKSFORME --- Comment #2 from Oleg Endo 2012-07-11 23:44:40 UTC --- As of rev 189427 this seems to be OK. Probably the described cases were side effects of other issues which have been solved.
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #2 from John David Anglin 2012-07-12 01:43:11 UTC --- This hunk of RTL was generated in .expand for function f: ;; D.1356_3 = D.1355_2 * 2863311531; (insn 9 8 10 (set (reg:SI 104) (subreg:SI (reg:DI 96 [ D.1355 ]) 4)) /test/gnu/gcc/gcc/gcc/testsuite/gc c.c-torture/execute/930921-1.c:4 -1 (nil)) (insn 10 9 11 (set (subreg:SI (reg:DI 97 [ D.1356 ]) 0) (ashift:SI (reg:SI 104) (const_int 31 [0x1f]))) /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:4 -1 (expr_list:REG_EQUAL (ashift:SI (subreg:SI (reg:DI 96 [ D.1355 ]) 4) (const_int 31 [0x1f])) (nil))) (insn 11 10 0 (set (subreg:SI (reg:DI 97 [ D.1356 ]) 4) (const_int 0 [0])) /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:4 -1 (nil)) Looks wrong to me. Fails when x=1.
[Bug c++/53932] New: [4.3 regression]C++ reference variable to member of anonymous union in global is error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932
Bug #: 53932
Summary: [4.3 regression]C++ reference variable to member of
anonymous union in global is error
Classification: Unclassified
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nuller0...@gmail.com
cat prog.cpp
static union { int i; };
int& r = i;
int main() { return r; }
g++ prog.cpp
/tmp/ccIAPctI.o::(.rdata+0x0): undefined reference to `_i'
collect2: ld returned 1 exit status
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Andrew Pinski 2012-07-12 03:25:12 UTC --- They are part of the specific release and not part of the web site. look inside the INSTALL directory in the toplevel directory.
[Bug c/53933] New: Register choosing error when inline assembly used at inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53933
Bug #: 53933
Summary: Register choosing error when inline assembly used at
inline function
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicejae...@gmail.com
Created attachment 27778
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27778
gcc -v verbose output and itermediate(*.i) file
1) the system type: arm cortex-a8 / linux-montavista
2) the options given when GCC was configured/built: -O3
3) the complete command line that triggers the bug: execute w/ no param
4) the compiler output (error messages, warnings, etc.): attached
It seems GCC picks wrong registers
when inline assembly is used at inline function.
Below clip_int32 function is in-lined at main function by -O3 option,
and GCC picked same register 'movlt ip, ip'
(it should have picked different register as instructed 'movlt %0, %2 ')
*code
int clip_int32(int a, int amin, int amax)
{
#if 1
asm volatile (
"mov %0, %1 \n\t"
"cmp %1, %2 \n\t"
"movlt %0, %2 \n\t"
"cmp %1, %3 \n\t"
"movgt %0, %3 \n\t"
: "=r"(a)
: "r"(a), "r"(amin), "r"(amax)
//: "r0", "r1", "r2"
);
return a;
#endif
#else
if (a < amin) return amin;
else if (a > amax) return amax;
else return a;
#endif
}
int main()
{
int ret[4];
ret[0] = clip_int32( -5, -1, 1 );
ret[1] = clip_int32( -5, -1, 1 );
ret[2] = clip_int32( -5, -1, 1 );
ret[3] = clip_int32( -5, -1, 1 );
printf("%d %d %d %d\n", ret[0], ret[1], ret[2], ret[3]);
return 0;
}
*disassembled executable
82c8 :
82c8: e52de004push{lr}; (str lr, [sp, #-4]!)
82cc: e3e4mvn r0, #4
82d0: e24dd00csub sp, sp, #12
82d4: e3e0c000mvn ip, #0
82d8: e3a0e001mov lr, #1
82dc: e1a01000mov r1, r0
82e0: e15ccmp r0, ip
82e4: b1a0100cmovlt r1, ip
82e8: e15ecmp r0, lr
82ec: c1a0100emovgt r1, lr
82f0: e1a02000mov r2, r0
82f4: e15ccmp r0, ip
82f8: b1a0200cmovlt r2, ip
82fc: e15ecmp r0, lr
8300: c1a0200emovgt r2, lr
8304: e1a03000mov r3, r0
8308: e15ccmp r0, ip
830c: b1a0300cmovlt r3, ip
8310: e15ecmp r0, lr
8314: c1a0300emovgt r3, lr
8318: e1a0c000mov ip, r0
831c: e15ccmp r0, ip
8320: b1a0c00cmovlt ip, ip (these register should not be the same!)
8324: e15ecmp r0, lr
8328: c1a0c00emovgt ip, lr
832c: e3080480movwr0, #33920 ; 0x8480
8330: e58dc000str ip, [sp]
8334: e340movtr0, #0
8338: ebd6bl 8298 <_init+0x20>
833c: e3a0mov r0, #0
8340: e28dd00cadd sp, sp, #12
8344: e8bd8000pop {pc}
the result was
-1, -1, -1, -1(wrong) for -O3 option, and
-1, -1, -1, -5(correct) for -O1 option.
[Bug c/53933] Register choosing error when inline assembly used at inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53933 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-07-12 06:55:21 UTC --- >1) the system type: arm cortex-a8 / linux-montavista We (MontaVista) does not provide a GCC 4.6.x. Anyways the problem is not related to GCC but rather your inline-asm is incorrect. You should mark the output constraint as an early clobber since you write to it before reading the input registers like so: asm volatile ( "mov %0, %1 \n\t" "cmp %1, %2 \n\t" "movlt %0, %2 \n\t" "cmp %1, %3 \n\t" "movgt %0, %3 \n\t" : "=&r"(a) : "r"(a), "r"(amin), "r"(amax) //: "r0", "r1", "r2" );
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
DmitryBespalov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #2 from DmitryBespalov 2012-07-12
06:59:09 UTC ---
Andrew, where I violating C++ rule? Did you check the code I've attached?
There is file1.cpp with struct A definition:
struct A
{
A() { std::cout << "file1.A::A()\n"; }
};
, and struct with same name in file2.cpp:
struct A
{
A() { std::cout << "file2.A::A()\n"; }
};
NOTE: none of them were declared in headers, so test1() from file1.cpp knows
nothing about struct A from file2.cpp.
So, why I get "file2.A::A()" printing while calling test1() from file1.cpp ?
