[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888 --- Comment #15 from xuepeng guo xguo at gcc dot gnu.org 2012-07-11 06:02:17 UTC --- Author: xguo Date: Wed Jul 11 06:02:10 2012 New Revision: 189421 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189421 Log: 2012-07-11 Terry Guo terry@arm.com Backport r181685 from mainline 2011-11-24 Jakub Jelinek ja...@redhat.com PR bootstrap/50888 * prims.cc: Don't include ctype.h. (c_isspace): Define. (next_property_key, next_property_value): Use it instead of isspace. Added: branches/ARM/embedded-4_6-branch/libjava/ChangeLog.arm Modified: branches/ARM/embedded-4_6-branch/libjava/prims.cc
[Bug middle-end/53922] New: VRP: semantic conflict between range_includes_zero_p and value_inside_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922
Bug #: 53922
Summary: VRP: semantic conflict between range_includes_zero_p
and value_inside_range
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com
In tree-vrp.c
function value_inside_range returns:
1 if VAL is inside value range VR (VR-MIN = VAL = VR-MAX),
0 if VAL is not inside VR,
-2 if we cannot tell either way.
While in function range_includes_zero_p, it:
return (value_inside_range (zero, vr) == 1);
which is bogus.
Because when value_inside_range returns -2, there is the possibility that value
range includes zero.
For example:
int x(int a)
{
return a;
}
int y(int a) __attribute__ ((weak));
int (*scan_func)(int);
extern int g;
int g = 0;
int main()
{
if (g)
scan_func = x;
else
scan_func = y;
if (scan_func)
g = scan_func(10);
return 0;
}
compiled with command line:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -Os -S test.c -o test.S
-fdump-tree-all
The dump of vrp2 pass is:
main ()
{
int (*Tcc0) (int) cstore.6;
int g.2;
int g.0;
bb 2:
g.0_1 = g;
if (g.0_1 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
bb 4:
# cstore.6_9 = PHI x(3), y(2)
scan_func = cstore.6_9;
g.2_4 = cstore.6_9 (10);
g = g.2_4;
return 0;
}
Though the problem shows up with this case in gcc4.6 branch and -Os option on
arm, I think it exists in 4.7/4.8 too, just concealed by different gimple
statements.
I will work out a patch for this.
[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 hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-11 Ever Confirmed|0 |1 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-07-11 06:27:29 UTC --- It is fixed on trunk by revision 186159: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00108.html
[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 rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-11 Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 amker.cheng at gmail dot com 2012-07-11
08:03:11 UTC ---
Yes, the dump before pass vrp2 is like:
main ()
{
int (*Tcc0) (int) cstore.6;
int g.2;
int g.0;
bb 2:
g.0_1 = g;
if (g.0_1 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
bb 4:
# cstore.6_9 = PHI x(3), y(2)
scan_func = cstore.6_9;
if (cstore.6_9 != 0B)
goto bb 5;
else
goto bb 6;
bb 5:
g.2_4 = cstore.6_9 (10);
g = g.2_4;
bb 6:
return 0;
}
gcc parses # cstore.6_9 = PHI x(3), y(2) 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 hjl.tools at gmail dot com changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 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=gccview=revrev=189423 Log: 2012-07-10 Greta Yorsh greta.yo...@arm.com 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 gjl at gcc dot gnu.org 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 gjl at gcc dot gnu.org 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 mikpe at it dot uu.se 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 gjl at gcc dot gnu.org 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 amker.cheng at gmail dot com 2012-07-11
10:12:24 UTC ---
vrp processes PHI node # cstore.6_9 = PHI x(3), y(2) 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 steven at gcc dot gnu.org changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 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 danglin at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 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 QtCore/QSettings
template typename T
void bug (const T default_value)
{
QSettings settings;
settings.value (foo, default_value).value T ();
}
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 typename T
T value () const { return T (); }
};
template typename T
Variant get_variant (const T x)
{
return Variant (x);
}
template typename T
void bug (const T x)
{
get_variant (x).value T ();
}
$ 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 T ();
into
Variant tmp = get_variant (x);
tmp.value T ();
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 redi at gcc dot gnu.org 2012-07-11 11:36:09 UTC --- It's not valid code, you ned to say foo().template valueT() 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 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 a.matveyakin at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #3 from Andrey Matveyakin a.matveyakin at gmail dot com 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 redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg00410.htm ||l --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 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 olegendo at gcc dot gnu.org 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:
28b: 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
a6 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
a8 DW_AT_static_link : 1 byte block: 50 (DW_OP_reg0 (rax))
aa DW_AT_GNU_all_call_sites: 1
aa 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:
14e: 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 redi at gcc dot gnu.org 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 rai...@emrich-ebersheim.de 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 olegendo at gcc dot gnu.org 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 interne
# 1 command-line
# 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 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 daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 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 olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org 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_castint (ir{x}); }
//void zip(int x) { const_castint (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 olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||olegendo at gcc dot gnu.org Resolution||WORKSFORME --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 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 danglin at gcc dot gnu.org 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 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.
