[Bug target/45731] gcc 4.5.1 -march=corei7 fails
--- Comment #2 from dcy665 at gmail dot com 2010-09-20 06:25 --- And yet, it does not help (with or without dashes) that corei7 is claimed to be supported and yet is not. Either --target-help should not report support or gcc should actually support it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45731
[Bug libfortran/45723] opening /dev/null for appending writes
--- Comment #3 from Joost dot VandeVondele at pci dot uzh dot ch 2010-09-20 06:30 --- (In reply to comment #2) Created an attachment (id=21841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21841action=view) [edit] Possible patch This patch passes regression testing. Don't seek if filesize is zero. seems like a clean solution... thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45723
[Bug tree-optimization/45714] [4.6 Regression] Vectorization of double pow function causes a segmentation fault
--- Comment #7 from irar at il dot ibm dot com 2010-09-20 06:43 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45714
[Bug target/45694] fortran host associated variables+optimization==failure?
--- Comment #2 from jpr at csc dot fi 2010-09-20 06:54 --- Created an attachment (id=21842) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21842action=view) somewhat reduced testcase Hi, I tried debugging this more. Attached is a somewhat reduced testcase. I also had a look at the assembler generated by x86_64-w64-mingw32-gfortran -save-temps -O1 fail1.f90. The loadinp looks like ... loadinp_: subq$56, %rsp movl$1952671091, 32(%rsp) movw$28521, 36(%rsp) movb$110, 38(%rsp) leaq32(%rsp), %r10 callparse_sect.1525 ... so it stores the 'section' string to stack and loads %r10 with the stack address and calls the parse_sect: parse_sect.1525: pushq %rdi pushq %rsi pushq %rbx movl$4032, %eax call___chkstk movq%r10, %rsi which then uses the stack address in %r10. The thing is that the __chkstk() call seems to change the contents of the %r10. At least doing ... movq %r10,%r12 call __chkstk movq %r12,%r10 ... seems to cure the example. What is really going on, anyone? Br, Juha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
Re: build gcc (c,c++,ada) for ia64-hp-hpux11.23 fails
Eric Botcazou-3 wrote: There is no full port of the Ada compiler to this platform in the FSF tree. You can only build a 64-bit Ada compiler with the unpatched sources. -- Eric Botcazou Thank you very much for your informations and sorry for the delay - I have been on vacation. Do you know if there is any configuration option to force build 64bit only? -- Birger Hoffmann -- View this message in context: http://old.nabble.com/build-gcc-%28c%2Cc%2B%2B%2Cada%29-for-ia64-hp-hpux11.23-fails-tp29612386p29756667.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #3 from rafael dot carre at gmail dot com 2010-09-20 07:24 --- I made a CVS checkout of binutils yesterday. You're right, MOVT is supported on ARMv7 because all ARMv7 supports Thumb2, http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf (It says All Thumb-2 versions of ARM v6 and above so I suppose some ARMv6 CPU supports it too) But this instruction is emitted when an ARMv4 (mcpu=arm9tdmi) or ARMv5 (mcpu=armv5tel) CPU is used. Do you confuse ARM7 and ARMv7 ? ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug rtl-optimization/45728] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-20 07:29 --- Created an attachment (id=21843) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21843action=view) gcc46-pr45728.patch Fix. Alternatively we could just change the == SUBREG condition to force_reg first to !REG_P !MEM_P. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45728
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #4 from rafael dot carre at gmail dot com 2010-09-20 07:47 --- Created an attachment (id=21844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21844action=view) Only emit MOVT when targetting Thumb2 Tentative patch. However as suggested by the original TARGET_32BIT, your comment, and the binutils message; MOVT might be valid as well when targetting ARM? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug fortran/45710] WRITE of NAMELIST group to internal file contains newline characters
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-20 07:56 --- (In reply to comment #0) In gfortran a WRITE of a NAMELIST group into an internal file appears to all go into the first record. [...] only major complaint with that is that I first guessed that your output into an internal file would be formatted just like it was to stdout. But gfortran output to stdout or to a file writes in a very different format, putting one keyword=value per line (which I like, but is also not required by any standard requirement I can find). If you use a scalar string, there is only a single record - thus gfortran has no choice then using only one record. You could instead use a character array, e.g. character(30) :: str(6) integer :: a, b, c, d namelist /nml/ a,b,c,d str = '' write(str,nml=nml) write(*,'(a)')str end From the F2008 standard: If the file is a scalar character variable, it consists of a single record whose length is the same as the length of the scalar character variable. If the file is a character array, it is treated as a sequence of character array elements. Each array element, if any, is a record of the file. (In reply to comment #4) This issue, line ending for namelist to character arrays, has come up before. I don't remember the outcome of that previous discussion. I will research a little. Well, in gfortran character arrays seem to do what urbanjost would like to have: A new record for each namelist element. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #5 from rafael dot carre at gmail dot com 2010-09-20 08:17 --- Created an attachment (id=21845) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21845action=view) Only emit MOVT when the targetted CPU is Thumb2-able -- rafael dot carre at gmail dot com changed: What|Removed |Added Attachment #21844|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug tree-optimization/45623] [4.5 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-09-20 08:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.5.1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45623] [4.5 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-09-20 08:34 --- Subject: Bug 45623 Author: rguenth Date: Mon Sep 20 08:33:46 2010 New Revision: 164430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164430 Log: 2010-09-20 Richard Guenther rguent...@suse.de PR tree-optimization/45623 * tree-ssa-structalias.c (get_constraint_for_ptr_offset): Adjust. (get_constraint_for_component_ref): If computing a constraint for the rhs handle type punning through unions. (get_constraint_for_address_of): Adjust. (get_constraint_for_1): Likewise. (get_constraint_for): Likewise. (get_constraint_for_rhs): New function. (do_structure_copy): Adjust. (make_constraint_to): Likewise. (handle_const_call): Likewise. (find_func_aliases): Likewise. * gcc.dg/torture/pr45623.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr45623.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-09-20 09:10 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-09-07 16:51:12 |2010-09-20 09:10:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45732] New: [4.6 Regression] ICE: in bit_value_unop, at tree-ssa-ccp.c:1861 at -O1
Compiler output: $ gcc -O testcase.c testcase.c: In function 'foo': testcase.c:8:1: internal compiler error: in bit_value_unop, at tree-ssa-ccp.c:1861 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r164287 - crash r163636 - crash r161659 - OK -- Summary: [4.6 Regression] ICE: in bit_value_unop, at tree-ssa- ccp.c:1861 at -O1 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45732
[Bug tree-optimization/45732] [4.6 Regression] ICE: in bit_value_unop, at tree-ssa-ccp.c:1861 at -O1
--- Comment #1 from zsojka at seznam dot cz 2010-09-20 09:23 --- Created an attachment (id=21846) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21846action=view) reduced testcase $ gcc -O pr45732.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45732
[Bug driver/45731] Header missing for assembler option help.
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-20 09:30 --- (In reply to comment #2) And yet, it does not help (with or without dashes) that corei7 is claimed to be supported and yet is not. --target-help is documented as alias for --help=target, but that doesn't print this help - which means that the 2nd half of --target-help is from the assembler and linker: -mveclibabi=Vector library ABI to use -mxop Support XOP built-in functions and code generation ... end of GCC options, assembler options starting: -Q ignored -V print assembler version number ... Linker options == Use -Wl,OPTION to pass OPTION to the linker. ... which means a proper header is missing for Assembler options. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |driver Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-20 09:30:32 date|| Summary|gcc 4.5.1 -march=corei7 |Header missing for assembler |fails |option help. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45731
[Bug middle-end/45730] Undefined symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::xsgetn(char*, long)
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-20 09:56 --- Thus, I would say middle-end? However, certainly doesn't happen on Linux, for some reason... Honza, in case please recategorize. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45730
[Bug fortran/45710] WRITE of NAMELIST group to internal file contains newline characters
--- Comment #6 from urbanjost at comcast dot net 2010-09-20 09:57 --- Subject: Re: WRITE of NAMELIST group to internal file contains newline characters That is the confusing part. The output only looks like it is multiple lines because a newline is placed between each name=value pair. The example is using an array; but the array is filled with an @ character and line numbers first so when it is printed you can see that only one line of the array was used by the WRITE. The definition for NAMELIST output says an arbitrary number of spaces and records can be used, but I don't think it intended newlines to be allowed in the output; unless the output is of type STREAM, perhaps. program oneline real :: a=1,b=2,c=3,d=4 NAMELIST /NL1/ a,b,c parameter(ilines=5) character(len=80) :: out(ilines) ! fill array OUT with @ do i=1,len(out) out(:)(i:i)='@' enddo ! put line number at beginning do j=1,ilines write(out(j)(1:5),'(i3.3,1x)')j enddo write(*,*)'BEFORE:' write(*,'(a)')out WRITE(out,NL1) write(*,*)'AFTER:' write(*,'(a)')out end program oneline ! BEFORE: !001 @@@ !002 @@@ !003 @@@ !004 @@@ !005 @@@ ! AFTER: !NL1 ! A= 1., ! B= 2.000, ! C= 3.000, / ! !002 @@@ !003 @@@ !004 @@@ !005 @@@ - Original Message - From: burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org To: urbanj...@comcast.net Sent: Monday, September 20, 2010 3:56 AM Subject: [Bug fortran/45710] WRITE of NAMELIST group to internal file contains newline characters --- Comment #5 from burnus at gcc dot gnu dot org 2010-09-20 07:56 --- (In reply to comment #0) In gfortran a WRITE of a NAMELIST group into an internal file appears to all go into the first record. [...] only major complaint with that is that I first guessed that your output into an internal file would be formatted just like it was to stdout. But gfortran output to stdout or to a file writes in a very different format, putting one keyword=value per line (which I like, but is also not required by any standard requirement I can find). If you use a scalar string, there is only a single record - thus gfortran has no choice then using only one record. You could instead use a character array, e.g. character(30) :: str(6) integer :: a, b, c, d namelist /nml/ a,b,c,d str = '' write(str,nml=nml) write(*,'(a)')str end From the F2008 standard: If the file is a scalar character variable, it consists of a single record whose length is the same as the length of the scalar character variable. If the file is a character array, it is treated as a sequence of character array elements. Each array element, if any, is a record of the file. (In reply to comment #4) This issue, line ending for namelist to character arrays, has come up before. I don't remember the outcome of that previous discussion. I will research a little. Well, in gfortran character arrays seem to do what urbanjost would like to have: A new record for each namelist element. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
Re: build gcc (c,c++,ada) for ia64-hp-hpux11.23 fails
Do you know if there is any configuration option to force build 64bit only? Try --disable-multilib. -- Eric Botcazou
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #6 from mikpe at it dot uu dot se 2010-09-20 10:29 --- Can you do a bisection to identify the exact commit responsible? Looking at the original commit that introduced the movt md pattern (139881) I see a TARGET_USE_MOVT guard in the C code that _should_ prevent it from being selected on non Thumb2-capable CPUs. If these guards are now broken then they need to be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug rtl-optimization/42775] [4.4 regression] GCC fails to rebuild itself with STAGE1_CFLAGS=-O1
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-09-20 10:31 --- Created an attachment (id=21847) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21847action=view) Semi-reduced testcase To be compiled at -O -mcpu=v8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42775
[Bug tree-optimization/45732] [4.6 Regression] ICE: in bit_value_unop, at tree-ssa-ccp.c:1861 at -O1
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-20 10:39 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-20 10:39:42 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45732
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #3 from jpr at csc dot fi 2010-09-20 11:05 ---
Even simpler testcase, now in C.
#include stdio.h
#include stdlib.h
void a()
{
char s[2];
void b() {
char p[4096];
if ( strcmp(s,s)!=0 ) abort();
strcpy( p,p);
}
strcpy( s,s );
b();
}
main()
{
a();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 11:07 ---
Whoops. Yeah, I only added x86_64-*-* to the vect_perm targets. Obviously,
as sse2 is active by default for the vectorizer testsuite I also need to
add the i?86-*-* targets. H.J., can you try with this patch on a native system
(so that we may see any possible fallout)?
Index: testsuite/lib/target-supports.exp
===
--- testsuite/lib/target-supports.exp (revision 164367)
+++ testsuite/lib/target-supports.exp (working copy)
@@ -2426,6 +2426,7 @@ proc check_effective_target_vect_perm {
set et_vect_perm_saved 0
if { [istarget powerpc*-*-*]
|| [istarget spu-*-*]
+|| [istarget i?86-*-*]
|| [istarget x86_64-*-*] } {
set et_vect_perm_saved 1
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #7 from rafael dot carre at gmail dot com 2010-09-20 11:08 --- I didn't bisect. Did you try r139881? If I download a checkout (I'm using a snapshot) to bisect I could use this as a working starting point. TARGET_USE_MOVT uses arm_arch_thumb2 just like my patch so it's not broken. I double checked by adding an abort() in the 2 points where TARGET_USE_MOVT is tested in arm.c BTW I remember seeing this error in 4.5.0 and/or 4.5.1 but I don't have the builds around to verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #4 from jpr at csc dot fi 2010-09-20 11:12 --- For the testcase in comment #3 the ___chkstk call is also generated with -O0 (and trying to use %r10 across the call...) Juha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #5 from jpr at csc dot fi 2010-09-20 11:36 ---
And still reduced testcase, fails at -O0.
void main()
{
char s;
void b() {
char p[4096];
if ( s!='s' ) abort();
}
s='s';
b();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #6 from t7 at gmail dot com 2010-09-20 11:41 ---
(In reply to comment #3)
Even simpler testcase, now in C.
#include stdio.h
#include stdlib.h
void a()
{
char s[2];
void b() {
char p[4096];
You deliberately use a very large storage for a very little data.
And it fails on m64 and not m32 which is rather weird and odd.
So I went to the bottom of this number which appears to be 3920.
3920 = ok
Any number beyond 3920 fails on m64 wtf?
I have no idea what is going on.
It just seems to me interesting to test out your case...
Yes O0 fails also... who knows...
if ( strcmp(s,s)!=0 ) abort();
strcpy( p,p);
}
strcpy( s,s );
b();
}
main()
{
a();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug tree-optimization/45733] New: [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call with -fstrict-overflow -ftree-vectorize
Compiler output:
$ gcc -O1 -fstrict-overflow -ftree-vectorize testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: error: invalid conversion in gimple call
vector(2) void *
vector(2) long long unsigned int
vect_var_.19_89 = __builtin_ia32_vec_perm_v2di_u (vect_var_.18_88,
vect_var_.18_88, { 1B, 0B });
testcase.c:4:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/ for instructions.
Tested revisions:
r164378 - crash
r164287 - OK
--
Summary: [4.6 Regression] ICE: verify_stmts failed: invalid
conversion in gimple call with -fstrict-overflow -ftree-
vectorize
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45733
[Bug tree-optimization/45733] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call with -fstrict-overflow -ftree-vectorize
--- Comment #1 from zsojka at seznam dot cz 2010-09-20 11:43 --- Created an attachment (id=21848) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21848action=view) reduced testcase $ gcc -O -fstrict-overflow -ftree-vectorize pr45733.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45733
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-20 11:45
---
namespace std {
typedef __SIZE_TYPE__ size_t;
}
inline void* operator new(std::size_t, void* __p) throw() {
return __p;
}
extern C void abort (void);
class Foo {
public:
virtual void test (void) { abort (); }
};
class Bar {
public:
virtual void test (void) { }
};
int main()
{
Foo f;
Bar *b;
b = new (f) Bar();
b-test();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #7 from jpr at csc dot fi 2010-09-20 11:46 ---
Hi,
yes the stack size is relevant here, because otherwise gcc does not
call ___chkstk(), which seems to be the trouble here. 4K stack usage
is not very big IMHO.
-Juha
(In reply to comment #6)
(In reply to comment #3)
Even simpler testcase, now in C.
#include stdio.h
#include stdlib.h
void a()
{
char s[2];
void b() {
char p[4096];
You deliberately use a very large storage for a very little data.
And it fails on m64 and not m32 which is rather weird and odd.
So I went to the bottom of this number which appears to be 3920.
3920 = ok
Any number beyond 3920 fails on m64 wtf?
I have no idea what is going on.
It just seems to me interesting to test out your case...
Yes O0 fails also... who knows...
if ( strcmp(s,s)!=0 ) abort();
strcpy( p,p);
}
strcpy( s,s );
b();
}
main()
{
a();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #8 from t7 at gmail dot com 2010-09-20 11:59 ---
(In reply to comment #7)
Hi,
yes the stack size is relevant here, because otherwise gcc does not
call ___chkstk(), which seems to be the trouble here. 4K stack usage
is not very big IMHO.
I went deeper... and found out with gcc-4.5-branch the number is different...
3952 = ok
Any number greater then 3952 fails on gcc-4.5...
And again this only applies to m64 not m32...
And very weird it seems that 3952 - 3920 = 32 ...
-Juha
(In reply to comment #6)
(In reply to comment #3)
Even simpler testcase, now in C.
#include stdio.h
#include stdlib.h
void a()
{
char s[2];
void b() {
char p[4096];
You deliberately use a very large storage for a very little data.
And it fails on m64 and not m32 which is rather weird and odd.
So I went to the bottom of this number which appears to be 3920.
3920 = ok
Any number beyond 3920 fails on m64 wtf?
I have no idea what is going on.
It just seems to me interesting to test out your case...
Yes O0 fails also... who knows...
if ( strcmp(s,s)!=0 ) abort();
strcpy( p,p);
}
strcpy( s,s );
b();
}
main()
{
a();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #8 from mikpe at it dot uu dot se 2010-09-20 12:02 --- r139881 is good. I'll start a bisection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-09-20 12:07 --- (In reply to comment #8) This issue is caused by the fact that __chkstk clobbers r10 (see its constrains), which is used here as argument-register for this nested function. So something is broken here about register-clobbering. I would welcome if my modified stack-allocation for windows would get reviewed and applied. This new implementation avoid this useless register-clobbering ... But well, this seems to me like a bug in interpretation of register clobbering here ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-20 12:15 --- I was having a second look to this issue, and noticed something more which I missed the first time: the Standard, *only* in the case of getline(char_type*, streamsize, char_type) explicitly says These conditions are tested in the order shown.. In my opinion that means that the get and ignore overloads using the famous any of the following occurs can in principle check the conditions in *any* implementation defined order and being conforming. Now, we have a case here where we have an additional underflow because in our implementation we uniformly insist on always checking whether end-of-file occurs in the sequence, thus setting eofbit (besides the special case of ignore(), as already noticed) in that case, like the above mentioned getline does, for example. I want to understand how critical this additional underflow is, performance-wise, which, as far as I can see normally can be triggered only by passing in_avail to ignore, because otherwise, frankly, I find our consistent implementation defined behavior across the various get, getline, ignore overloads pretty nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
[Bug tree-optimization/45733] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call with -fstrict-overflow -ftree-vectorize
--- Comment #2 from irar at il dot ibm dot com 2010-09-20 12:17 --- Looks like it is caused by revision 164367: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00661.html -- irar at il dot ibm dot com changed: What|Removed |Added CC||matz at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-20 12:17:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45733
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #17 from mikpe at it dot uu dot se 2010-09-20 12:40 --- expmed.c:expand_shift () is miscompiled: breaking that function out to a separate source file, compiling it with stage1/xgcc, and relinking stage2/cc1 I get 'lsls', compiling it with the bootstrap gcc and relinking stage2/cc1 I get 'adds'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug target/43088] [avr] Suspect optimizer missed code in gcc 4.4.3..
--- Comment #4 from eric dot weddington at atmel dot com 2010-09-20 12:58 --- (In reply to comment #3) It exits for the reported version (4.4.3) and as well as for trunk/4.6. Abnikant, could you also post the patch that fixes this problem? Thanks. -- eric dot weddington at atmel dot com changed: What|Removed |Added Known to fail||4.4.3 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43088
[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
--- Comment #3 from abel at gcc dot gnu dot org 2010-09-20 13:05 ---
We have the code like this:
if (...)
{
17 cx:DI=[`s2'] //comes from s2.vl += s1.vl;
...
}
27 dx:DI=[`s2'] //comes from s1 = s2;
When the scheduler tries to move insn 27 before if (...), it also unifies its
right-hand sides, as they seem equal. The scheduler wants to get:
27 dx:DI=[`s2']
if (...)
{
cx = dx
...
dx:DI=[`s2'] // bookkeeping
}
The insn 17 has its MEM with volatile bit set, the insn 27 has it unset. It so
happens that when gathering the available insn set and when moving the actually
selected insn, insns 17 and 27 got merged in the different order. First we
don't have the volatile bit on the resulting insn, thus we believe the load
does not trap and we move it up through a jump before the 'if'. Second we have
the bit and thus insn traps and we don't move it, then we hit the consistency
assert in the scheduler.
Now, I'm happy to implement the correct merging of the may_trap_p bit in the
scheduler which would fix this. However, looking at the original C code it
looks like both MEMs should have their volatile bit set. I can only say that
the original bits seem to come from expand, the addresses got propagated by
fwprop but this doesn't seem to be the issue.
--
abel at gcc dot gnu dot org changed:
What|Removed |Added
CC||abel at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
[Bug tree-optimization/45733] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call with -fstrict-overflow -ftree-vectorize
--- Comment #3 from irar at il dot ibm dot com 2010-09-20 13:08 --- For vector(2) void * we get vec_perm_v2di_u builtin declaration, because the mode of vector(2) void * is unsigned V2DI. I wonder if this can happen for every builtin call, and we should convert back to the original type everywhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45733
[Bug tree-optimization/45733] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call with -fstrict-overflow -ftree-vectorize
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 13:17 --- Yeah, probably some fold_convert is missing in reverse_vec_elements() in case the type of the args or the return type of the chosen builtin decl don't exactly match. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45733
[Bug rtl-optimization/45695] [4.5/4.6 Regression] -O1 wrong-code by cmove
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-20 13:24 --- Subject: Bug 45695 Author: jakub Date: Mon Sep 20 13:24:23 2010 New Revision: 164431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164431 Log: PR rtl-optimization/45695 * combine.c (try_combine): When splitting a two set pattern, make sure the pattern which will be put into i2 doesn't use REGs or MEMs set by insns in between i2 and i3. * gcc.c-torture/execute/pr45695.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr45695.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45695
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-20 13:54 ---
(In reply to comment #4)
Whoops. Yeah, I only added x86_64-*-* to the vect_perm targets. Obviously,
as sse2 is active by default for the vectorizer testsuite I also need to
add the i?86-*-* targets. H.J., can you try with this patch on a native
system
(so that we may see any possible fallout)?
Index: testsuite/lib/target-supports.exp
===
--- testsuite/lib/target-supports.exp (revision 164367)
+++ testsuite/lib/target-supports.exp (working copy)
@@ -2426,6 +2426,7 @@ proc check_effective_target_vect_perm {
set et_vect_perm_saved 0
if { [istarget powerpc*-*-*]
|| [istarget spu-*-*]
+|| [istarget i?86-*-*]
|| [istarget x86_64-*-*] } {
set et_vect_perm_saved 1
}
It works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-09-20 14:12 --- Subject: Bug 45706 Author: matz Date: Mon Sep 20 14:12:04 2010 New Revision: 164433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164433 Log: PR testsuite/45706 * lib/target-supports.exp (check_effective_target_vect_perm): Add i?86-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug testsuite/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-20 14:14 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|middle-end |testsuite Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-09-20 14:26 --- The fact that C++ vtables are weak or external should no longer bother us with const_decl_known flag. The problem is that array constructor provided by C++ frontend don't have explicit indexes and thus current folders ignore them. This is addresses by the long patch of mine using get_ref_base_and_extend I am just trying to break up ;) To get folding done I need 1) fixed array folding 2) tree-ssa-ccp patch to get rid of OBJ_TYPE_REF when constant operand is known and not get bothered by NOP_EXPRs we produce around. Still we usually need FRE to actually get into at vtable address (it is stored to memory and then read from it) so we actually fold only after inlining and then it is all (almost) pointless excercise. So we would also need 3) Do FRE in early passes (that would make sense now when we do have alias info, I plan to benchmark just moving the pass there) or to teach some other pass to copy propagate through memory Still I don't think low level folding should be the mechanizm we rely on when implementing devirtualization. It is way too low level and requires tracking of value stored to memory cross call boundaries that is hard. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug middle-end/45705] [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-20 14:40 --- Subject: Bug 45705 Author: rguenth Date: Mon Sep 20 14:40:10 2010 New Revision: 164434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164434 Log: 2010-09-20 Richard Guenther rguent...@suse.de PR tree-optimization/45705 * tree-ssa-dom.c (optimize_stmt): Perform redundant store elimination. * gcc.dg/tree-ssa/ssa-dom-dse-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-dse-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug testsuite/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-20 14:45 --- Subject: Bug 45706 Author: matz Date: Mon Sep 20 14:45:30 2010 New Revision: 164435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164435 Log: PR testsuite/45706 * gcc.dg/vect/pr43432.c: Don't override dg-options, defaults are enough. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr43432.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug middle-end/45705] [4.3/4.4/4.5 Regression] Useless store not optimized away
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-20 14:46 --- Fixed on trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.3/4.4/4.5/4.6 Regression]|[4.3/4.4/4.5 Regression] |Useless store not optimized |Useless store not optimized |away|away http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug tree-optimization/45734] New: [4.6 Regression] Devirtualization results in wrong-code
namespace std {
typedef __SIZE_TYPE__ size_t;
}
inline void* operator new(std::size_t, void* __p) throw() {
return __p;
}
extern C void abort (void);
class Foo {
public:
virtual void test (void) { abort (); }
};
class Bar {
public:
virtual void test (void) { }
};
int main()
{
Foo f;
Bar *b;
b = new (f) Bar();
b-test();
return 0;
}
--
Summary: [4.6 Regression] Devirtualization results in wrong-code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45734
[Bug tree-optimization/45734] [4.6 Regression] Devirtualization results in wrong-code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org, jamborm at gcc dot gnu ||dot org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45734
[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
--- Comment #4 from amonakov at gcc dot gnu dot org 2010-09-20 14:49
---
A small testcase to illustrate the problem with volatile fields.
//---8---
struct vv {volatile long a, b;} vv1, vv2;
int foo()
{
vv1 = vv2;
}
//---8---
gcc/cc1 -O2 -frename-registers -fschedule-insns2 vol.c
movqvv2+8(%rip), %rax
movqvv2(%rip), %rdx
movq%rax, vv1+8(%rip)
movq%rdx, vv1(%rip)
The compiler reorders accesses to volatile fields. As Andrey said, /v bits are
missing on MEMs even in the .expand dump.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-09-20 15:20 --- Must also be present (even if latent) on 4.5. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||assemble-failure, wrong-code Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-09-20 15:20:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-09-20 15:25 --- Subject: Bug 45726 Author: rearnsha Date: Mon Sep 20 15:25:44 2010 New Revision: 164436 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164436 Log: 2010-09-20 Rafael Carre rafael.ca...@gmail.com PR target/45726 * arm.md (arm_movtas_ze): Only enable on machine with MOVT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug tree-optimization/45734] [4.6 Regression] Devirtualization results in wrong-code
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-20 15:27 --- It is caused by revision 161655: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-20 15:27:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45734
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #11 from rearnsha at gcc dot gnu dot org 2010-09-20 15:27 --- Subject: Bug 45726 Author: rearnsha Date: Mon Sep 20 15:27:13 2010 New Revision: 164437 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164437 Log: 2010-09-20 Rafael Carre rafael.ca...@gmail.com PR target/45726 * arm.md (arm_movtas_ze): Only enable on machine with MOVT. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #12 from rearnsha at gcc dot gnu dot org 2010-09-20 15:36 --- Fixed in 4.5.3 and trunk. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #13 from rafael dot carre at gmail dot com 2010-09-20 15:46 --- Is there something wrong with the first hunk of the patch (arm_movt) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug tree-optimization/45734] [4.6 Regression] Devirtualization results in wrong-code
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-20 15:46 --- Of course it is ;) Before pointer-conversions became useless we didn't propagate the invariant address into the OBJ_TYPE_REF expression. We still have useful function-pointer conversions as well, because dropping them would wreck CALL_EXPRs, too (we need to preserve the original function type, similar to the alias-type on MEM_REFs). I suppose we could do the same for OBJ_TYPE_REFs that I plan(ned) for CALL_EXPRs - store the pointed-to type via a MEM_REF - thus a dereferenced address. You'd then have CALL_EXPR (MEM [fnptr], args ...) OBJ_TYPE_REF (MEM [fnptr], MEM [objptr], index) where both TREE_TYPE of the function and the object are kept like the FE specified them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45734
[Bug c++/45605] Missed devirtualization
--- Comment #20 from hubicka at gcc dot gnu dot org 2010-09-20 15:48 --- Subject: Bug 45605 Author: hubicka Date: Mon Sep 20 15:48:42 2010 New Revision: 164438 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164438 Log: PR tree-optimize/45605 * cgraph.h (const_value_known_p): Declare. (varpool_decide_const_value_known): Remove. * tree-ssa-ccp.c (get_base_constructor): Use it. * lto-cgraph.c (compute_ltrans_boundary): Likewise. * expr.c (string_constant): Likewise. * tree-ssa-loop-ivcanon.c (constant_after_peeling): Likewise. * ipa.c (ipa_discover_readonly_nonaddressable_var, function_and_variable_visibility): Likewise. * gimplify.c (gimplify_call_expr): Likewise. * gimple-fold.c (get_symbol_constant_value): Likewise. * varpool.c (varpool_decide_const_value_known): Replace by... (const_value_known_p): ... this one; handle other kinds of DECLs too and work for automatic vars. (varpool_finalize_decl): Use const_value_known_p. * lto.c (lto_promote_cross_file_statics): Use const_value_known_p. * g++.dg/tree-ssa/pr45605.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr45605.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/expr.c trunk/gcc/gimple-fold.c trunk/gcc/gimplify.c trunk/gcc/ipa.c trunk/gcc/lto-cgraph.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-loop-ivcanon.c trunk/gcc/varpool.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/41437] No access control for classes in template functions
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.6 4.4.3 4.5.2 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-09-20 15:53:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
[Bug c++/45605] Missed devirtualization
--- Comment #21 from hubicka at gcc dot gnu dot org 2010-09-20 15:53 --- OK, we now fold the testcase using obj_type_ref folding. We still should do it via vtable lookup and we don't but that is for other PR I guess. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/40843] access violation not detected for non dependent qualified enum value
--- Comment #5 from redi at gcc dot gnu dot org 2010-09-20 15:54 --- PR 41437 has a simpler testcase *** This bug has been marked as a duplicate of 41437 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40843
[Bug c++/41437] No access control for classes in template functions
--- Comment #2 from redi at gcc dot gnu dot org 2010-09-20 15:54 --- *** Bug 40843 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||sipych at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-20 15:54 --- Subject: Bug 45704 Author: rguenth Date: Mon Sep 20 15:54:03 2010 New Revision: 164439 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164439 Log: 2010-09-20 Richard Guenther rguent...@suse.de PR middle-end/45704 * gimplify.c (gimplify_modify_expr_rhs): Preserve volatileness. * gcc.dg/torture/pr45704.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr45704.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
--- Comment #5 from bonzini at gnu dot org 2010-09-20 16:01 --- Looks like a problem in expand. CCing Matz. -- bonzini at gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #14 from rearnsha at gcc dot gnu dot org 2010-09-20 16:13 --- (In reply to comment #13) Is there something wrong with the first hunk of the patch (arm_movt) ? Nothing really. I missed that bit. I think in practice the compiler will never end up matching that pattern (as lo_sum isn't something the compiler spontaneously generates -- it means different things on each architecture that supports it, so the generic parts of the compiler will only use it if they are transforming something that already uses it), but it should probably be on the trunk version as the current code is clearly too liberal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #15 from rearnsha at gcc dot gnu dot org 2010-09-20 16:22 --- Subject: Bug 45726 Author: rearnsha Date: Mon Sep 20 16:21:57 2010 New Revision: 164441 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164441 Log: 2010-09-20 Rafael Carre rafael.ca...@gmail.com PR target/45726 * arm.md (arm_movt): Only enable on machines with MOVT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug fortran/45438] [4.6 Regression] [OOP] ICE with -fcheck=pointer
--- Comment #3 from janus at gcc dot gnu dot org 2010-09-20 16:29 --- Here is a reduced test case: module base_mat_mod type :: base_sparse_mat contains procedure :: get_fmt end type contains function get_fmt(a) result(res) implicit none class(base_sparse_mat), intent(in) :: a character(len=5) :: res res = 'NULL' end function subroutine errlog(name) character(len=*) :: name end subroutine subroutine test (a) implicit none class(base_sparse_mat), intent(in) :: a call errlog(a%get_fmt()) end subroutine end module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #16 from mikpe at it dot uu dot se 2010-09-20 16:37 --- FWIW, exposed on trunk by r160462 (PR44423 fix), backported to 4.5 in r160775. But clearly the issue was latent since the movt patterns were added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug debug/45124] No DW_AT_accessibility for public DIEs in DW_TAG_class_type
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-20 16:48 --- Subject: Bug 45124 Author: jakub Date: Mon Sep 20 16:48:29 2010 New Revision: 164442 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164442 Log: PR debug/45124 * dwarf2out.c (add_accessibility_attribute): Assume DW_ACCESS_private as the default for dwarf_version 2 and DW_TAG_class_type parent. (gen_inheritance_die): Assume DW_ACCESS_public as the default for dwarf_version 2 and parent other than DW_TAG_class_type. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45124
[Bug debug/45124] No DW_AT_accessibility for public DIEs in DW_TAG_class_type
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-20 16:51 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45124
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Comment #10 from eric dot weddington at atmel dot com 2010-09-20 16:51 --- Closed as WONTFIX. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #13 from hjl dot tools at gmail dot com 2010-09-20 16:56 --- Here is the deal: 1. The linker default search paths are /lib, /usr/lib. 2. ld -r disables the linker default search paths. 3. Gcc always passes -Lmulti-lib-dir to ld when multi-lib is enabled. On Linux/ia32, gcc never passes -L/lib -L/usr/lib to linker. It works with the linker default search paths. But gcc -r disables the linker default search paths and gcc -r -lm doesn't work. On Linux/x86-64, gcc always passes -Lmulti-lib-dir to linker and gcc -r -lm works with -m32/-m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #14 from hjl dot tools at gmail dot com 2010-09-20 17:10 --- One solution is always pass -L to linker even if the directory is known to linker. Gcc always does that for multi-lib. This will make gcc more consistent. It may also allow using system linker with native sysroot toolchain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug target/43876] [avr] Improper updating of struct members when written out of order from struct definition
--- Comment #4 from eric dot weddington at atmel dot com 2010-09-20 17:14 --- AFAIK, fixed in the latest xmega patch, which is still not upstream. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43876
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- Comment #27 from paolo dot carlini at oracle dot com 2010-09-20 17:23 --- Unless somebody posts here over the next two/three days or so *concrete* ideas of a different sort, I'm going to simply work on a doubly linked list solution, along the lines of the section iterator here: http://www.drdobbs.com/184403822 Nothing new, therefore. All the operations on iterators will become faster, not just computing the iterator returned by erase, on the other hand two pointers instead of one will be used for each element. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||joaquin at tid dot es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-20 17:28 --- Ian, I suppose the iant cited by Andrew it's you: any more constructive tip? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- Comment #10 from rwild at gcc dot gnu dot org 2010-09-20 17:31 --- (In reply to comment #9) Ian, I suppose the iant cited by Andrew it's you: any more constructive tip? Come on, allow hobbyist helpers a day or two to fix a years-old issue, please. Thanks. -- rwild at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-20 17:31:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- Comment #28 from joaquin at tid dot es 2010-09-20 17:34 --- US 113, ES 2, US 118 / Issue 579 have been closed as NAD, thus let's figure out how best obtain O(1) in our implementation... Do you have a rationale for the closing of this NB comments? N3133 shows 579 unchanged. I was told that someone reported about the existence of a O(1) singly-linked list implementation in Rapperswil, but I don't have additional details. I'd wait to get the full picture before going to a doubly-linked list: the commitee had full info on the issue, so if they closed 579 as NAD they are supposed to be able to provide a rationale. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-20 17:35 --- I understand that some such hobbyists have a rather serious paid work ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug fortran/45438] [4.6 Regression] [OOP] ICE with -fcheck=pointer
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-20 17:41 --- Mine (have a patch). -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-08-28 10:27:07 |2010-09-20 17:41:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- Comment #29 from paolo dot carlini at oracle dot com 2010-09-20 17:41 --- I'm not aware of any singly linked list implementation, to be honest. I know that Dinkumware already uses doubly, and, if I'm not wrong, Howard just moved to it. I'll send you privately the rationale I have from the minutes, I'm also asking again Matt whether he has anything else to suggest, but frankly I'm rather fed up with this issue, I mean to implement something that *works*, is *conforming* and then test it in the field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug objc/45735] New: ICE in objc_add_method, at objc/objc-act.c:6941
seen in 4.3, 4.4, 4.5, 4.6, didn't find an existing report:
$ gcc -c Fraction.m
Fraction.m:9:29: error: expected identifier before ':' token
Fraction.m:9:29: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark' in objc_add_method, at
objc/objc-act.c:6941
Please submit a full bug report,
with preprocessed source if appropriate.
@interface Fraction {
int numaretor;
int denominator;
}
-(void) print;
-(void) setNumaretor: (int) :(int) ;
-(int) numaretor;
-(int) denominator;
@end
@implementation Fraction
-(void) print {
printf(%i/%i,numaretor,denominator);
}
-(void) setNumaretor: (int) n: (int) m {
numaretor = n;
denominator = m;
}
-(int) numaretor {
return numaretor;
}
-(int) denominator {
return denominator;
}
@end
--
Summary: ICE in objc_add_method, at objc/objc-act.c:6941
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45735
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
--- Comment #3 from zsojka at seznam dot cz 2010-09-20 18:00 --- Created an attachment (id=21849) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21849action=view) another testcase that doesn't need many flags to reproduce $ gcc -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -march=amdfam10 -O3 pr45352-5.c pr45352-5.c: In function 'foo': pr45352-5.c:22:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7077 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The failing assert is: gcc_assert (cost 0); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352
[Bug c/43082] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #7 from doko at ubuntu dot com 2010-09-20 18:01 --- trunk 20100918 fails with: gcc -g -O0 -c foo.c foo.c: In function 'main': foo.c:4:5: error: void value not ignored as it ought to be foo.c:4:5: error: void value not ignored as it ought to be foo.c:4:7: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in get_narrower, at tree.c:7856 Please submit a full bug report, with preprocessed source if appropriate. -- doko at ubuntu dot com changed: What|Removed |Added Known to fail|4.3.4 4.4.2 4.5.0 |4.3.5 4.4.4 4.5.1 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
[Bug tree-optimization/45572] [4.6 Regression] various ICEs with -finline-small-functions -findirect-inlining -finline-functions
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-20 18:51 --- Mine -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-20 18:51:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45572
[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
--- Comment #11 from pault at gcc dot gnu dot org 2010-09-20 18:55 --- Subject: Bug 45081 Author: pault Date: Mon Sep 20 18:55:12 2010 New Revision: 164448 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164448 Log: 2010-09-20 Paul Thomas pa...@gcc.gnu.org PR fortran/45081 * simplify.c (is_constant_array_expr): Allow structure array elements as well as constants. (gfc_simplify_pack, gfc_simplify_reshape, gfc_simplify_spread, gfc_simplify_transpose, gfc_simplify_unpack): Copy the derived type of source to the result. 2010-09-20 Paul Thomas pa...@gcc.gnu.org PR fortran/45081 * gfortran.dg/derived_array_intrinsics_1.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/derived_array_intrinisics_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- Comment #12 from rwild at gcc dot gnu dot org 2010-09-20 19:23 --- Please try the patch at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01600.html. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- Comment #13 from rwild at gcc dot gnu dot org 2010-09-20 19:33 --- Subject: Bug 45711 Author: rwild Date: Mon Sep 20 19:33:12 2010 New Revision: 164451 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164451 Log: Fix PR libstdc++/45711. libstdc++-v3/: PR libstdc++/45711 * src/Makefile.am (stamp-debug): Also adjust possibly-relative file names in MKDIR_P, and, for consistency, also top_build_prefix. * src/Makefile.in: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug lto/45736] New: [4.6 Regression] ICE: in cgraph_remove_unreachable_nodes, at ipa.c:245 with -flto and attribute((constructor))
Compiler output: $ gcc -r -nostdlib -O -flto testcase.c lto1: internal compiler error: in cgraph_remove_unreachable_nodes, at ipa.c:245 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-164287-lto-fortran-checking-yes-rtl-df/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status Tested revisions: r164287 - crash r163636 - crash r161659 - OK -- Summary: [4.6 Regression] ICE: in cgraph_remove_unreachable_nodes, at ipa.c:245 with -flto and attribute((constructor)) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45736
[Bug lto/45736] [4.6 Regression] ICE: in cgraph_remove_unreachable_nodes, at ipa.c:245 with -flto and attribute((constructor))
--- Comment #1 from zsojka at seznam dot cz 2010-09-20 19:46 --- Created an attachment (id=21850) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21850action=view) reduced testcase $ gcc -r -nostdlib -O -flto pr45736.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45736
[Bug tree-optimization/45733] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call with -fstrict-overflow -ftree-vectorize
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-20 19:50 --- (In reply to comment #2) Looks like it is caused by revision 164367: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00661.html Revision 164367 is the cause. Revision 164367 also caused PR 45720. Don't know if they are related. -- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45733
[Bug target/43746] -fmerge-constants and -fmerge-all-constants don't work at AVR target
--- Comment #3 from eric dot weddington at atmel dot com 2010-09-20 19:53 --- Reopening this enhancement request. Bug #21018, which this was marked a duplicate of, is now marked as WONTFIX. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|c++ |target GCC target triplet||avr Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746
[Bug fortran/45648] [4.6 regression] Unnecessary temporary for transpose calls as actual argument.
--- Comment #3 from pthaugen at gcc dot gnu dot org 2010-09-20 20:00 --- As Steven mentioned in the mailing list, this did introduce a degradation for cpu2000 benchmark galgel. I'm seeing about -10% on PowerPC. -- pthaugen at gcc dot gnu dot org changed: What|Removed |Added CC||pthaugen at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45648
[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
--- Comment #19 from hjl at gcc dot gnu dot org 2010-09-20 20:32 --- Subject: Bug 45234 Author: hjl Date: Mon Sep 20 20:32:41 2010 New Revision: 164453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164453 Log: Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. gcc/ 2010-09-20 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * calls.c (expand_call): Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. gcc/testsuite/ 2010-09-20 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * gcc.dg/torture/stackalign/alloca-5.c: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/stackalign/alloca-5.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/calls.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
[Bug rtl-optimization/45678] [4.4/4.5 Regression] crash on vector code with -m32 -msse
--- Comment #28 from jakub at gcc dot gnu dot org 2010-09-20 20:37 --- Subject: Bug 45678 Author: jakub Date: Mon Sep 20 20:37:10 2010 New Revision: 164454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164454 Log: PR middle-end/45678 * cfgexpand.c (expand_one_stack_var_at): Use crtl-max_used_stack_slot_alignment as max_align, instead of maximum of that and PREFERRED_STACK_BOUNDARY. Don't call update_stack_alignment. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
--- Comment #20 from hjl at gcc dot gnu dot org 2010-09-20 20:39 --- Subject: Bug 45234 Author: hjl Date: Mon Sep 20 20:39:18 2010 New Revision: 164455 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164455 Log: Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. gcc/ 2010-09-20 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * calls.c (expand_call): Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. gcc/testsuite/ 2010-09-20 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * gcc.dg/torture/stackalign/alloca-5.c: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/stackalign/alloca-5.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/calls.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
