[Bug middle-end/44554] Stack space after sigsetjmp is reused
--- Comment #10 from christian dot eggers at kathrein dot de 2010-09-09 06:17 --- (In reply to comment #9) I've submitted a patch solving PR40386. So now we can solve this problem by preventing slot sharing when setjmp is used. I'll send a patch soon. Could you please send me both patches? I would like to test whether both problems are solved (at least for me). regards Christian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554
[Bug c++/45609] New: 'is used uninitialized' becomes 'may be used uninitialized' on unrelated code changes (namespace addition)
(I looked for duplicate -Wuninitialized bugs but didn't see anything similar) In the attached minimized testcase I get a clear 'is used uninitialized' warning downgraded to a 'may be used uninitialized' warning on unrelated code changes. The program compiles correctly with the following flags: -O3 -Wall To move one function definition into a namespace, add -DBAD_NAMESPACE and get the wrong warning. Reordering/removing/adding/changing the sizes of local variables makes the warning restore to 'is used uninitialized', one example can be enabled by -DGOOD_ORDER This is a regression since 4.3 as 4.2 always gives a 'is used uninitialized' warning. I tested with the following compilers from SVN on amd64 and x86 architectures: g++-trunk (GCC) 4.6.0 20100901 (experimental) == BAD g++-4.5.x (GCC) 4.5.2 20100901 (prerelease) == BAD g++-4.4.x (GCC) 4.4.5 20100824 (prerelease) == BAD g++-4.3.x (GCC) 4.3.6 20100824 (prerelease) == BAD g++-4.2.x (GCC) 4.2.5 20090330 (prerelease) == OK + g++-4.5.x -std=c++0x -O3 -Wall -c PRmbuuitf.cpp PRmbuuitf.cpp: In function 'void test()': PRmbuuitf.cpp:66:25: warning: 'b$t$MBUUITF' is used uninitialized in this function PRmbuuitf.cpp:64:5: note: 'b$t$MBUUITF' was declared here + g++-4.5.x -std=c++0x -O3 -Wall -c PRmbuuitf.cpp -DBAD_NAMESPACE PRmbuuitf.cpp: In function 'void test()': vvv PRmbuuitf.cpp:66:25: warning: 'b$t$MBUUITF' may be used uninitialized in this function ^^^ PRmbuuitf.cpp:64:5: note: 'b$t$MBUUITF' was declared here + g++-4.5.x -std=c++0x -O3 -Wall -c PRmbuuitf.cpp -DBAD_NAMESPACE -DGOOD_ORDER PRmbuuitf.cpp: In function 'void test()': PRmbuuitf.cpp:66:25: warning: 'b$t$MBUUITF' is used uninitialized in this function PRmbuuitf.cpp:64:5: note: 'b$t$MBUUITF' was declared here + g++-4.2.x -O3 -Wall -c PRmbuuitf.cpp -DBAD_NAMESPACE PRmbuuitf.cpp: In function 'void test()': PRmbuuitf.cpp:66: warning: 'b.B::t.T::MBUUITF' is used uninitialized in this function PRmbuuitf.cpp:64: note: 'b.B::t.T::MBUUITF' was declared here -- Summary: 'is used uninitialized' becomes 'may be used uninitialized' on unrelated code changes (namespace addition) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at abeckmann dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45609
[Bug c++/8966] [Alpha OSF5.1] Lost exceptions across library boundaries
--- Comment #10 from mt at debian dot org 2010-09-09 06:23 --- I have tried to reproduce the problem with g++ 4.5 and couldn't make it fail anymore. The problem, however, is that I couldn't make it fail with g++ 4.4 either. Whatever the essential change might have been, the PPL instance of this problem seems to be fixed. Best, Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8966
[Bug c++/45609] 'is used uninitialized' becomes 'may be used uninitialized' on unrelated code changes (namespace addition)
--- Comment #1 from gcc at abeckmann dot de 2010-09-09 06:24 --- Created an attachment (id=21746) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21746action=view) minimized testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45609
[Bug c++/45588] unused-but-set-variable false trigger building gold
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-09 06:51 --- Subject: Bug 45588 Author: jakub Date: Thu Sep 9 06:50:56 2010 New Revision: 164051 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164051 Log: PR c++/45588 * pt.c (tsubst) case INTEGER_TYPE: Call mark_rvalue_use before calling fold_decl_constant_value. * g++.dg/warn/Wunused-var-15.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45588
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #2 from jobnoorman at gmail dot com 2010-09-09 07:11 --- (In reply to comment #1) Note, if you really need the name __cxa_guard_acquire to trigger the bug, which is in the implementor namespace, due to the double underscore in front, this is a low priority ICE on *illegal*. I first triggered this bug in a freestanding environment and it's not illegal there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45588] unused-but-set-variable false trigger building gold
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-09 07:16 --- 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=45588
[Bug c++/45601] explicit template instantiation problem
--- Comment #5 from stephane at magnenat dot net 2010-09-09 07:19 --- Thank you very much for these explanations, thanks to your pointer I managed to make a working version, which I will attach to this bug as reference. As a side-note, it is not easy to access C++ standard because the official ISO document is non free. While citing the section in the standard, did you refer to the N3092 draft (as linked from Wikipedia C++ page) or to the official ISO document? I found a draft of it at http://www.csci.csusb.edu/dick/c++std/cd2/template.html If I may suggest, it would be nice that g++ would be a bit more specific/clearer when reporting the error, because as there are few (if not none) freely available reference/documentation for complex templates processing, this would help users very much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-09 07:20 --- I first triggered this bug in a freestanding environment You need to include -fno-threadsafe-statics to disable the use of __cxa_guard_acquire. This functions is part of the normal C++ ABI we follow (the IA64 C++ ABI and it is included in the ARM C++ EABI too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #4 from jobnoorman at gmail dot com 2010-09-09 07:25 --- (In reply to comment #3) You need to include -fno-threadsafe-statics to disable the use of __cxa_guard_acquire. This functions is part of the normal C++ ABI we follow (the IA64 C++ ABI and it is included in the ARM C++ EABI too). Thanks! I can use that as a quick workaround but I'll eventually need __cxa_guard_acquire. -- jobnoorman at gmail dot com changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45601] explicit template instantiation problem
--- Comment #6 from stephane at magnenat dot net 2010-09-09 07:20 --- Created an attachment (id=21747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21747action=view) Working code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-09 07:27 --- I can use that as a quick workaround but I'll eventually need __cxa_guard_acquire. Then you should look into the ABI to see how it is defined. I think this ICE only happens when it is declared incorrectly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #6 from jobnoorman at gmail dot com 2010-09-09 07:35 --- (In reply to comment #5) Then you should look into the ABI to see how it is defined. I think this ICE only happens when it is declared incorrectly. According to the ABI, it should be declared as extern C int __cxa_guard_acquire(int64_t*); And this crashes all the same. -- jobnoorman at gmail dot com changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-09 07:45 --- That's because the compiler's expectation is that if you define __cxa_guard_acquire, you also define __cxa_guard_release and __cxa_guard_abort. And, they should be declared throw() as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #8 from jobnoorman at gmail dot com 2010-09-09 08:00 --- (In reply to comment #7) That's because the compiler's expectation is that if you define __cxa_guard_acquire, you also define __cxa_guard_release and __cxa_guard_abort. And, they should be declared throw() as well. I was just trying to provide a minimal reproducible crash. In my actual program, all three functions are, of course, defined and properly implemented and GCC also crashes. (BTW, where did you find that they should be declared throw()? Anyway, GCC also crashes if I declare them like that.) But let's stick to the point here: GCC crashes and it shouldn't, no matter what I do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45609] [Regression 4.3/4.4/4.5/4.6] 'is used uninitialized' becomes 'may be used uninitialized' on unrelated code changes (namespace addition)
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-09 08:00 --- In any case, this is a clear regression of the pretty printer. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-09 08:00:56 date|| Summary|'is used uninitialized' |[Regression 4.3/4.4/4.5/4.6] |becomes 'may be used|'is used uninitialized' |uninitialized' on unrelated |becomes 'may be used |code changes (namespace |uninitialized' on unrelated |addition) |code changes (namespace ||addition) Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45609
[Bug tree-optimization/41087] [4.5/4.6 Regression]: cris-elf gfortran.dg/zero_sized_3.f90 -O3 -funroll-loops execution
--- Comment #9 from hp at gcc dot gnu dot org 2010-09-09 08:11 --- Created an attachment (id=21748) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21748action=view) patch The simplest solution is to correct noce_get_condition to not follow its documentation and not allow conditions that aren't valid at JUMP rather than valid at EARLIEST, simply because we can't allow an additional side-effect. Maybe too simple for some, but simple and safe enough for a release-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41087
[Bug c++/45605] Missed devirtualization
--- Comment #2 from rguenther at suse dot de 2010-09-09 08:43 ---
Subject: Re: New: Missed devirtualization
On Thu, 9 Sep 2010, hubicka at gcc dot gnu dot org wrote:
The following testcase taken from testsuite (and many others):
// PR 14535
// { dg-do run }
// { dg-options -O -finline }
//
// Original test case failure required that Raiser constructor be inlined.
extern C void abort();
bool destructor_called = false;
struct B {
virtual void Run(){};
};
struct D : public B {
virtual void Run()
{
struct O {
~O() { destructor_called = true; };
} o;
struct Raiser {
Raiser() throw( int ) {throw 1;};
} raiser;
};
};
int main() {
try {
D d;
static_castB(d).Run();
} catch (...) {}
if (!destructor_called)
abort ();
}
leads to following in .optimized dump:
bb 2:
MEM[(struct B *)d]._vptr.B = _ZTV1B[2];
d.D.2108._vptr.B = _ZTV1D[2];
D.2210_2 = _ZTV1D[2];
OBJ_TYPE_REF(D.2210_2;d.D.2108-0) (d.D.2108);
Obviously OBJ_TYPE_REF can be optimized here since we know the
virtual table. Why it is missed?
I run into it because my new folding code is actually smart enough to lead to:
int (*__vtbl_ptr_type) (void)
void D::T400 (struct D *)
D.2210_2 = Run;
The error comes because we pick from initializer of VTBL the following
ADDR_EXPR:
addr_expr 0x77ec8b10
type pointer_type 0x76b7db28 __vtbl_ptr_type
type function_type 0x76b7da80 type integer_type 0x77edb498
int
type_6 QI
size integer_cst 0x77ec54d8 constant 8
unit size integer_cst 0x77ec5500 constant 1
align 8 symtab 0 alias set -1 canonical type 0x76b7da80
pointer_to_this pointer_type 0x76b7db28 __vtbl_ptr_type
unsigned type_6 DI
size integer_cst 0x77ec57d0 constant 64
unit size integer_cst 0x77ec57f8 constant 8
align 64 symtab 0 alias set -1 canonical type 0x76b7db28
pointer_to_this pointer_type 0x76b7dc78
constant
arg 0 function_decl 0x76b8e500 Run
type method_type 0x76b9b9d8 type void_type 0x77edbe70 void
type_6 QI size integer_cst 0x77ec54d8 8 unit size
integer_cst 0x77ec5500 1
align 8 symtab 0 alias set -1 canonical type 0x76b9b9d8 method
basetype record_type 0x76b9b7e0 D
arg-types tree_list 0x76b80af0 value pointer_type
0x76b9ba80
chain tree_list 0x77eed398 value void_type
0x77edbe70
void
pointer_to_this pointer_type 0x76bab150
addressable volatile asm_written used public static weak autoinline
virtual decl_5 QI file /home/jh/a.C line 15 col 18 align 16 context
record_type 0x76b9b7e0 D initial error_mark 0x77ecdb28
arguments parm_decl 0x77ece990 this type pointer_type
0x76b9bb28
readonly unsigned DI file /home/jh/a.C line 15 col 22 size
integer_cst 0x77ec57d0 64 unit size integer_cst 0x77ec57f8 8
align 64 context function_decl 0x76b8e500 Run
(reg/f:DI 62 [ this ]) arg-type pointer_type 0x76b9bb28
incoming-rtl (reg:DI 5 di [ this ])
result result_decl 0x77ed0380 D.2112 type void_type
0x77edbe70 void
ignored VOID file /home/jh/a.C line 16 col 7
align 8 context function_decl 0x76b8e500 Run
full-name virtual void D::Run()
pending-inline-info 0x76ba42a0
(mem:QI (symbol_ref/i:DI (_ZN1D3RunEv) [flags 0x1] function_decl
0x76b8e500 Run) [0 S1 A8])
Note the differece in between type of address and the method RUN. This is
what
makes verifier unhappy. How to fix this? Should FE put there some NOP_EXPR
somewhere? Still devirtualizing should realize this case a lot earlier.
Well - it's easy. Whoever does substitution needs to verify it can
do so. Which of course is tricky with the stupid way we do
substitute_and_fold ...
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug fortran/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
--- Comment #11 from burnus at gcc dot gnu dot org 2010-09-09 09:00 --- [Move comment from IRC #gcc to bugzilla] (In reply to comment #9) For what it is worth, on AMD Athlon 64 X2 4800+ / x86-64-linux, [...] That's a +16% increase in run-time with -fwhole-program. (In reply to comment #10) So hot-bb-frequency-fraction solves the whole regression? For me (cf. system above), --param hot-bb-frequency-fraction=2000 reduces the slow down due to -fwhole-program from 16% to 3%. (The LTO version with and without -fwhole-file is about 2% slower than the corresponding -fno-lto version.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
[Bug c++/45601] explicit template instantiation problem
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-09 09:16 --- The current ISO document, C++98 or C++03 which contains some rather small amendments: if C++0x were different it would show only when -std=c++0x is passed. In any case, it's unfortunate but we cannot do much about the cost of the document, if you are serious about C++ you should buy it as you buy books and everything else, is also rather cheap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45603] cc1plus crashes in build_addr_func
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #15 from paolo dot carlini at oracle dot com 2010-09-09 09:25 --- If you write a patch it would be of course looked at. But *please* try first something that doesn't break the ABI, because we have *no* idea when you changes would be applied otherwise. About the *_unlocked functions, we know those glibc extensions exist, but, as far as I can see would only change the complexity by a not so so small multiplicative constant and, after years and years of using everywhere the normal versions, I don't believe we should change just now the configuration on Linux only. But, as I said, provided you don't break the ABI (to be concrete) and the improvements are substantive, you are certainly welcome to submit patches to the libstdc++ mailing list. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-09 09:43 --- (In reply to comment #8) (BTW, where did you find that they should be declared throw()? If you open cxxabi.h, you can see _GLIBCXX_NOTHROW after release and abort. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45607] [4.3/4.4 Regression] Confusing error message
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-09 09:47 --- 4.5 prints t.C:2:13: error: 'A::A' has the same name as the class in which it is declared 3.4 t.C:2: error: `enum A::A' has the same name as the class in which it is declared which is nicest. 4.0 to 4.4 exhibit the behavior as described in this bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||3.4.6 4.5.1 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-09-09 09:47:36 date|| Summary|Inappropriate error message |[4.3/4.4 Regression] ||Confusing error message Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45607
[Bug testsuite/45604] [4.6 regression] New test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45604
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-09-09 09:51 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-09 09:51:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug middle-end/45589] [4.6 Regression] 200.sixtrack in SPEC CPU 2000 is miscompiled
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-09 09:52 --- Was a dup (fixed). *** This bug has been marked as a duplicate of 45578 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45589
[Bug tree-optimization/45578] [4.6 Regression] The polyhedron test mdbx is miscompiled with -O2 -ftree-vectorize at revision 163915
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-09-09 09:52 --- *** Bug 45589 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45578
[Bug c/45610] New: misleading warning when operator paired with a constant - is it operator precedence?
gcc --version gcc (GCC) 4.3.1 Copyright (C) 2008 Free Software Foundation, Inc. found in package cairo-1.9.14 and file test/cairo-test.c with critical line 1597: if (ctx-thread == 0 ! RUNNING_ON_VALGRIND) build outputs: warning: logical '' with non-zero constant will always evaluate as true from the used setup the VALGRIND macro is assumed to have a true value. (a code checker would probably suggest using round braces around the == part. the used default project tuning of gcc does not raise a warning on operator precedence.) whats the problem? a) if you use with a constant and something else then your result will always either be false (const=false) or something else (const=true). there is no case for the compiler seeing this as fixed to true. b) maybe its unintended operator precedence that makes the case behave strangely -- Summary: misleading warning when operator paired with a constant - is it operator precedence? Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexander dot stohr at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45610
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #7 from mikpe at it dot uu dot se 2010-09-09 10:21 ---
It's not a stage2/stage3 debug difference as far as I can tell. I've
recompiled every differing .o file with the stage 1/2/3 xgccs -fcompare-debug
without complaints.
The test case showing the different code generation is trivial (this is in the
objdir for a native bootstrap of r163951):
cat sreal.c
void normalize(unsigned long long *sreal_sig)
{
*sreal_sig = 1;
}
stage1-gcc/xgcc -Bstage1-gcc -O2 -c sreal.c; objdump -d sreal.o
sreal.o: file format elf32-littlearm
Disassembly of section .text:
normalize:
0: e1c020d0ldrdr2, [r0]
4: e0922002addsr2, r2, r2
8: e0a33003adc r3, r3, r3
c: e1c020f0strdr2, [r0]
10: e12fff1ebx lr
stage2-gcc/xgcc -Bstage2-gcc -O2 -c sreal.c ; objdump -d sreal.o
sreal.o: file format elf32-littlearm
Disassembly of section .text:
normalize:
0: e1c020d0ldrdr2, [r0]
4: e1b02082lslsr2, r2, #1
8: e0a33003adc r3, r3, r3
c: e1c020f0strdr2, [r0]
10: e12fff1ebx lr
stage3-gcc/xgcc -Bstage3-gcc -O2 -c sreal.c ; objdump -d sreal.o
sreal.o: file format elf32-littlearm
Disassembly of section .text:
normalize:
0: e1c020d0ldrdr2, [r0]
4: e1b02082lslsr2, r2, #1
8: e0a33003adc r3, r3, r3
c: e1c020f0strdr2, [r0]
10: e12fff1ebx lr
So stage1 chooses adds but stage2 and stage3 choose lsls for of the lower
half of a long long. Since the behaviour of a stageN xgcc depends on both the
gcc source code and the compiler used to build it, I have to suspect a source
code ambiguity (e.g. evaluation order dependence) that the bootstrap compiler
(gcc-4.4.4 in my case) resolves differently from post-r162417 4.6.
I've so far not been able to reproduce this difference in a cross from i686;
those cross compilers always seem to choose the adds form regardless of the
version of gcc I'm building with.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45611] New: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
Between rev 163993 and 164013, mainline bootstrap started failing on Solaris 2 SPARC. The stage2 libgcc fails to configure because the stage2 xgcc gets a SIGBUS for % ../../xgcc -B../../gcc/ -c -g -O2 conftest.c Bus Error Running xgcc under gdb, I find that the crash happens here: Program received signal SIGSEGV, Segmentation fault. generate_option_input_file (argc=value optimized out, argv=value optimized out, lang_mask=value optimized out, decoded_options=0xffbff394, decoded_options_count=0xffbff390) at /vol/gcc/src/hg/trunk/local/gcc/opts-common.c:750 1: x/i $pc = 0x28584 decode_cmdline_options_to_array+168: clrx [ %l0 + 0x18 ] %lo+0x18 isn't 8-byte aligned at that point. Comparing the assembler code between the working and failing versions, I find that the following change has happened: decode_cmdline_options_to_array+0xa4: c0 24 20 14 clr [%l0 + 0x14] -decode_cmdline_options_to_array+0xa8: c0 24 20 18 clr [%l0 + 0x18] -decode_cmdline_options_to_array+0xac: c0 24 20 1c clr [%l0 + 0x1c] -decode_cmdline_options_to_array+0xb0: c4 24 20 24 st%g2, [%l0 + 0x24] +decode_cmdline_options_to_array+0xa8: c0 74 20 18 clrx [%l0 + 0x18] +decode_cmdline_options_to_array+0xac: c4 24 20 24 st%g2, [%l0 + 0x24] i.e. two clr insns (which are ok with 4-byte alignment) have been replaced by a single clrx. I'll start a reghunt to find the culprit patch. -- Summary: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2* GCC host triplet: sparc-sun-solaris2* GCC target triplet: sparc-sun-solaris2* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug bootstrap/45612] New: [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC
Between 20100903 and 20100908, mainline bootstrap with Ada started failing when compiling the 32-bit g-debpoo.adb: % /var/gcc/gcc-4.6.0-20100908/11-gcc-gas/./gcc/xgcc -B/var/gcc/gcc-4.6.0-20100908/11-gcc-gas/./gcc/ -B/usr/local/sparc-sun-solaris2.11/bin/ -B/usr/local/sparc-sun-solaris2.11/lib/ -isystem /usr/local/sparc-sun-solaris2.11/include -isystem /usr/local/sparc-sun-solaris2.11/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg g-debpoo.adb -o g-debpoo.o -save-temps g-debpoo.s: Assembler messages: g-debpoo.s:5362: Error: undefined symbol `.LL363' in operation g-debpoo.s:5363: Error: undefined symbol `.LL363' in operation -- Summary: [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2* GCC host triplet: sparc-sun-solaris2* GCC target triplet: sparc-sun-solaris2* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-09 10:28 ---
templatetypename T
struct Singleton
{
static T* get()
{
static T instance;
return instance;
}
~Singleton() {}
};
struct Foo : SingletonFoo
{
};
#ifdef __ARM_EABI__
typedef int __guard;
#else
typedef int __guard __attribute__((mode(DI)));
#endif
extern C int __cxa_guard_acquire(__guard *)
{
}
extern C void __cxa_guard_release(__guard *) throw()
{
}
extern C void __cxa_guard_abort(__guard *) throw()
{
}
void foo()
{
Foo::get();
}
compiles just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC
--- Comment #1 from ro at gcc dot gnu dot org 2010-09-09 10:29 --- Created an attachment (id=21749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21749action=view) assembler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug libstdc++/45613] New: bits/random.h misses include guards
I just noticed that bits/random.h does not have include guards. -- Summary: bits/random.h misses include guards Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at abeckmann dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45613
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #16 from jakub at gcc dot gnu dot org 2010-09-09 10:33 --- The *_unlocked versions are faster a lot actually, at least for the one character ops, because no locking is performed and the calls are inlined. But the question is whether libstdc++ can use them, unless there is some restriction that would disallow several threads from using the same FILE * (including using STL APIs in one thread and C stdio APIs in another thread). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-09-09 10:38 --- Presumably 163997 then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #17 from paolo dot carlini at oracle dot com 2010-09-09 10:42 --- At some point I tried quickly replacing some getc, did notice an improvement of course, but of the order of magnitude I mentioned. Worth further investigating sure (and simple, just replace in stdio_sync_ and measure, on Linux). In terms of the C++ Standard, I think that C++98 would allow essentially *anything*, not so C++0x, and within C++98 too I'm afraid we can break code making already some assumptions about the thread safety, which we don't spell out anywhere as impl def behavior, still... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45613] bits/random.h misses include guards
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-09 10:44 --- You are right, random.tcc too actually. Should not be too risky because those are internal headers, not meant to be included directly by the users. Still, I'll fix momentarily, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-09 10:44:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45613
[Bug c++/45605] Missed devirtualization
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-09 11:02 ---
Hmm, is it?
C equivalent IMO is:
int a(void);
typedef void (*ptr) (void);
static const ptr array[1]={(ptr)a};
ptr t;
main()
{
t=array[0];
}
Here we have ctor represented as follows:
nop_expr 0x76b53f30
type pointer_type 0x76b383f0
type function_type 0x77eee690 type void_type 0x77ed9e70 void
QI
size integer_cst 0x77ec54d8 constant 8
unit size integer_cst 0x77ec5500 constant 1
align 8 symtab 0 alias set -1 canonical type 0x77eee690
arg-types tree_list 0x77ec5eb0 value void_type 0x77ed9e70
void
pointer_to_this pointer_type 0x76b383f0
unsigned DI
size integer_cst 0x77ec57d0 constant 64
unit size integer_cst 0x77ec57f8 constant 8
align 64 symtab 0 alias set -1 canonical type 0x76b383f0
pointer_to_this pointer_type 0x76b38738
constant
arg 0 addr_expr 0x76b53f00
type pointer_type 0x76b38bd0 type function_type 0x77eee888
unsigned DI size integer_cst 0x77ec57d0 64 unit size
integer_cst 0x77ec57f8 8
align 64 symtab 0 alias set -1 canonical type 0x76b38bd0
constant
arg 0 function_decl 0x76b37f00 a type function_type
0x77eee888
addressable used public external decl_5 QI file t.c line 1 col 5
align 8 chain var_decl 0x76b550a0 t
t.c:5:33
t.c:5:28
this gets into canonicalize_constructor_val and it does STRIP_NOPS so we
return addr_expr with different type than array_ref from
fold_const_aggregate_ref (this code is copied from old implementation, the
STRIP_NOPS there seemed bid odd to me originally) and this lands in ccp_fold
that is happy and CCP re-inserts the nop later.
I guess C++ FE is wrong to produce type mismatch in addr_expr? That should be
easy to fix.
I wonder about other users of fold_const_aggregate_ref. Shall they also work on
re-inserting the conversions to avoid possible type mismatch?
Obviously more worms...
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/19816] C++ front-end produces a cast instead of just a.b (empty base class)
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-09 11:05 --- Hmm, my system compiles (4.3.2) gets: _Z1fv: .LFB2: subq$24, %rsp .LCFI0: leaq23(%rsp), %rdi call_ZN4baseC2Ev addq$24, %rsp ret .LFE2: this seems OK to me? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19816
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-09-09 11:09 --- This compiled fine on 20100907 for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug libstdc++/45613] bits/random.h misses include guards
--- Comment #2 from paolo at gcc dot gnu dot org 2010-09-09 11:24 --- Subject: Bug 45613 Author: paolo Date: Thu Sep 9 11:23:39 2010 New Revision: 164074 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164074 Log: 2010-09-09 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/45613 * include/bits/random.tcc: Add missing include guards. * include/bits/random.h: Likewise. * include/tr1/random.tcc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/include/tr1/random.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45613
[Bug libstdc++/45613] bits/random.h misses include guards
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-09 11:25 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45613
[Bug c++/45605] Missed devirtualization
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-09 11:33 ---
testing the following fix:
Index: class.c
===
--- class.c (revision 163947)
+++ class.c (working copy)
@@ -7797,7 +7797,7 @@ build_vtbl_initializer (tree binfo,
{
fn = abort_fndecl;
if (abort_fndecl_addr == NULL)
- abort_fndecl_addr = build1 (ADDR_EXPR, vfunc_ptr_type_node,
fn);
+ fold_convert (vfunc_ptr_type_node, build_fold_addr_expr (fn));
init = abort_fndecl_addr;
}
else
@@ -7810,7 +7810,7 @@ build_vtbl_initializer (tree binfo,
}
/* Take the address of the function, considering it to be of an
appropriate generic type. */
- init = build1 (ADDR_EXPR, vfunc_ptr_type_node, fn);
+ init = fold_convert (vfunc_ptr_type_node, build_fold_addr_expr
(fn));
}
this solves the ICE, but won't get call devirtualized. We end up with:
MEM[(struct B *)d]._vptr.B = _ZTV1B[2];
d.D.2108._vptr.B = _ZTV1D[2];
D.2210_2 = (int (*__vtbl_ptr_type) (void)) Run;
OBJ_TYPE_REF(D.2210_2;d.D.2108-0) (d.D.2108);
It seems that forw-prop should be told that OBJ_TYPE_REF does not care about
nops on the operand and also fold_ccp can be told to call fold_obj_type_ref on
the substituted constant. Martin, can you take a look, please?
I am attaching current WIP version of my constructor folding that makes
D.2210_2 = (int (*__vtbl_ptr_type) (void)) Run; to happen.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/45605] Missed devirtualization
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-09-09 11:36 --- Created an attachment (id=21750) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21750action=view) WIP patch. Still misses some of Richi's earlier comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/45609] [4.3/4.4/4.5/4.6 Regression] 'is used uninitialized' becomes 'may be used uninitialized' on unrelated code changes (namespace addition)
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-09 11:56 --- I don't see any problem. All of current trunk, 4.5 and 4.4 print it as b.B::t.T::MBUUITF rather than b$t$MBUUITF and the other difference in the warning message is not caused by unrelated code changes, but actually very much related. With -UBAD_NAMESPACE ::f() function is defined in the current TU and thus the compiler knows it doesn't throw and that D::D() doesn't throw either, with -DBAD_NAMESPACE ::f() is only declared and so the compiler doesn't know it it throws or doesn't, and similarly for D::D(). The is used uninitialized warning is emitted only in basic blocks that are always executed (with -UBAD_NAMESPACE if A::A() is called, it will always pass the uninitialized var to C::g(int); with -DBAD_NAMESPACE if ::f() throws then that wouldn't happen. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45609
[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #8 from ro at gcc dot gnu dot org 2010-09-09 12:05 --- Unfortunately not: bootstrap still fails as of rev. 164013. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)
--- Comment #4 from mikpe at it dot uu dot se 2010-09-09 12:06 --- This ICEs for me with 4.4-20100907 and the 4.5.1 release (-m32 -mno-fpu), but not with 4.5-20100902 or 4.6-20100904. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664
[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-09-09 12:15 --- Unfortunately not: bootstrap still fails as of rev. 164013. Not very surprising given that we now have a SIGBUS on the SPARC as well... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug c/45610] misleading warning when operator paired with a constant - is it operator precedence?
--- Comment #1 from joseph at codesourcery dot com 2010-09-09 12:20 --- Subject: Re: New: misleading warning when operator paired with a constant - is it operator precedence? You don't give a self-contained testcase whose behavior with different versions can be compared, but the warnings now are if (or_op) warning_at (location, OPT_Wlogical_op, logical %or% applied to non-boolean constant); else warning_at (location, OPT_Wlogical_op, logical %and% applied to non-boolean constant); and the reason is /* Warn if /|| are being used in a context where it is likely that the bitwise equivalent was intended by the programmer. That is, an expression such as op MASK where op should not be any boolean expression, nor a constant, and mask seems to be a non-boolean integer constant. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45610
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-09 12:41 --- Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC --- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-09-09 10:38 --- Presumably 163997 then. Indeed: a C-only bootstrap on sparc-sun-solaris2.10 works as of rev 163996 and fails with 163997. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)
--- Comment #5 from mikpe at it dot uu dot se 2010-09-09 12:41 --- (In reply to comment #4) This ICEs for me with 4.4-20100907 and the 4.5.1 release (-m32 -mno-fpu), but not with 4.5-20100902 or 4.6-20100904. Oops, that was with a locally modified 4.5-20100902. A vanilla 4.5-20100902 still ICEs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #3 from ro at gcc dot gnu dot org 2010-09-09 12:43 --- Richard, could you please have a look? -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-09 12:43:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug rtl-optimization/45614] New: [4.6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1056 with -ftree-vectorize
Compiler output: $ gcc -O -ftree-vectorize testcase.c testcase.c: In function 'foo': testcase.c:11:1: internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1056 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. Tested revisions: r164069 - crash r163965 - OK -- Summary: [4.6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1056 with -ftree- vectorize Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-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=45614
[Bug rtl-optimization/45614] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1056 with -ftree-vectorize
--- Comment #1 from zsojka at seznam dot cz 2010-09-09 13:04 --- Created an attachment (id=21751) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21751action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45614
[Bug c/45610] misleading warning when operator paired with a constant - is it operator precedence?
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-09 13:15 --- We need a testcase http://gcc.gnu.org/bugs/minimize.html but I am pretty sure this is not warned anymore in GCC 4.6 (and probably GCC 4.4 and 4.5) -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45610
[Bug rtl-optimization/45614] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1056 with -ftree-vectorize
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-09 13:26 --- I think it is fixed by revision 164071: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00363.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45614
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27 --- (In reply to comment #3) Richard, could you please have a look? I don't have access to sparc-sun-solaris2*, so I can't bootstrap it (but at most build a cross cc1). So please attach a testcase (easiest is probably in a non-bootstrapped tree run make check and pick a simple one that fails from the C testsuite). Is sparc-sun-solaris2* a STRICT_ALIGNMENT target? What's the clr instruction? Is it a store or a load? The revision in question is supposed to make alignment less strict and I can't see how this can break anything. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug rtl-optimization/45614] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1056 with -ftree-vectorize
--- Comment #3 from zsojka at seznam dot cz 2010-09-09 13:40 --- Indeed, r164077 no longer crashes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45614
[Bug middle-end/40386] wrong code generation for several SPEC CPU2000 benchmarks (lucas, mgrid, face, applu, apsi) with -O1 -fno-ira-share-spill-slots
--- Comment #10 from vmakarov at gcc dot gnu dot org 2010-09-09 13:43
---
Subject: Bug 40386
Author: vmakarov
Date: Thu Sep 9 13:42:51 2010
New Revision: 164095
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164095
Log:
2010-09-08 Vladimir Makarov vmaka...@redhat.com
PR middle-end/40386
* ira.c (pseudo_for_reload_consideration_p): Don't use
flag_ira_share_spill_slots.
2010-09-08 Vladimir Makarov vmaka...@redhat.com
PR middle-end/40386
* gcc.c-torture/execute/{pr40386.c,pr40386.x}: New testcase.
Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr40386.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr40386.x
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ira.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug middle-end/40386] wrong code generation for several SPEC CPU2000 benchmarks (lucas, mgrid, face, applu, apsi) with -O1 -fno-ira-share-spill-slots
--- Comment #11 from vmakarov at gcc dot gnu dot org 2010-09-09 13:47
---
Subject: Bug 40386
Author: vmakarov
Date: Thu Sep 9 13:47:14 2010
New Revision: 164097
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164097
Log:
2010-09-08 Vladimir Makarov vmaka...@redhat.com
PR middle-end/40386
* ira.c (pseudo_for_reload_consideration_p): Don't use
flag_ira_share_spill_slots.
2010-09-08 Vladimir Makarov vmaka...@redhat.com
PR middle-end/40386
* gcc.c-torture/execute/{pr40386.c,pr40386.x}: New testcase.
Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr40386.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr40386.x
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/ira.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug middle-end/40386] wrong code generation for several SPEC CPU2000 benchmarks (lucas, mgrid, face, applu, apsi) with -O1 -fno-ira-share-spill-slots
--- Comment #12 from vmakarov at gcc dot gnu dot org 2010-09-09 13:51
---
Subject: Bug 40386
Author: vmakarov
Date: Thu Sep 9 13:51:25 2010
New Revision: 164100
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164100
Log:
2010-09-09 Vladimir Makarov vmaka...@redhat.com
PR middle-end/40386
* ira.c (pseudo_for_reload_consideration_p): Don't use
flag_ira_share_spill_slots.
2010-09-09 Vladimir Makarov vmaka...@redhat.com
PR middle-end/40386
* gcc.c-torture/execute/{pr40386.c,pr40386.x}: New testcase.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr40386.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr40386.x
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug middle-end/44554] Stack space after sigsetjmp is reused
--- Comment #11 from vmakarov at gcc dot gnu dot org 2010-09-09 13:54 --- Subject: Bug 44554 Author: vmakarov Date: Thu Sep 9 13:53:32 2010 New Revision: 164102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164102 Log: 2010-09-09 Vladimir Makarov vmaka...@redhat.com PR middle-end/44554 * ira.c (ira): Switch off sharing spill slots if setjmp is called. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554
[Bug middle-end/44554] Stack space after sigsetjmp is reused
--- Comment #12 from vmakarov at gcc dot gnu dot org 2010-09-09 13:56 --- Subject: Bug 44554 Author: vmakarov Date: Thu Sep 9 13:55:35 2010 New Revision: 164105 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164105 Log: 2010-09-09 Vladimir Makarov vmaka...@redhat.com PR middle-end/44554 * ira.c (ira): Switch off sharing spill slots if setjmp is called. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554
[Bug middle-end/44554] Stack space after sigsetjmp is reused
--- Comment #13 from vmakarov at gcc dot gnu dot org 2010-09-09 13:58 --- Subject: Bug 44554 Author: vmakarov Date: Thu Sep 9 13:58:24 2010 New Revision: 164107 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164107 Log: 2010-09-09 Vladimir Makarov vmaka...@redhat.com PR middle-end/44554 * ira.c (ira): Switch off sharing spill slots if setjmp is called. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554
[Bug rtl-optimization/45614] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1056 with -ftree-vectorize
--- Comment #4 from hjl dot tools at gmail dot com 2010-09-09 14:09 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45614
[Bug fortran/45277] make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
--- Comment #7 from philippe_scelers at mentor dot com 2010-09-09 14:10 --- Previous comments describe encountered issue, including gmp/mpfr/mpc version. Below a summary of successfull build on Solaris 10 standalone build/install for gmp/mpfr/mpc, ABI=32 is mandatory gcc --version gcc (GCC) 4.5.1 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. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/free/NEW_GNU_BUILD/devenv_g3_package/bundle_v1.0/sun4u/5.10/bin/../libexec/gcc/sparc-sun-solaris2.10/4.5.1/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /free/NEW_GNU_BUILD/devenv_g3_package/src/gcc-4.5.1/configure --prefix=/free/NEW_GNU_BUILD/devenv_g3_package/install/sun4u/5.10/gcc-4.5.1 --disable-nls --with-local-prefix=/u/gnu --enable-languages=c,c++,fortran --with-gnu-as --with-as=/free/NEW_GNU_BUILD/devenv_g3_package/install/sun4u/5.10/binutils-2.20.1/bin/as --with-gnu-ld --with-ld=/free/NEW_GNU_BUILD/devenv_g3_package/install/sun4u/5.10/binutils-2.20.1/bin/ld --with-gmp=/free/NEW_GNU_BUILD/devenv_g3_package/install/sun4u/5.10/gmp-4.3.2 --with-mpfr=/free/NEW_GNU_BUILD/devenv_g3_package/install/sun4u/5.10/mpfr-2.4.2 --with-mpc=/free/NEW_GNU_BUILD/devenv_g3_package/install/sun4u/5.10/mpc-0.8.1 Thread model: posix gcc version 4.5.1 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #18 from tstarling at wikimedia dot org 2010-09-09 14:12 --- Created an attachment (id=21752) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21752action=view) gprof output I haven't managed to get libstdc++ to compile with -pg, but compiling the test program with -static at least gives you a function breakdown. gprof output attached for 1 million lines, 500 bytes per line. To summarise: fgetc: 36.13% istream::getline: 18.01% ungetc: 16.70% _IO_sputbackc: 9.54% stdio_sync_filebuf::underflow: 5.66% stdio_sync_filebuf::uflow: 4.93% I should have spotted it from reading the code, it's not a loop of getc(), it's a loop of ungetc(getc()) getc(). It really demonstrates how poorly suited the streambuf interface is to unbuffered input. The virtual functions called by istream::getline() don't give much flexibility. So I still have no other ideas apart from breaking the ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #19 from tstarling at wikimedia dot org 2010-09-09 14:28
---
(In reply to comment #16)
The *_unlocked versions are faster a lot actually, at least for the one
character ops, because no locking is performed and the calls are inlined.
But the question is whether libstdc++ can use them, unless there is some
restriction that would disallow several threads from using the same FILE *
(including using STL APIs in one thread and C stdio APIs in another thread).
My current idea is to do:
flockfile(stdin);
while (!eof) {
c = getc_unlocked(stdin);
...
}
funlockfile(stdin);
This is not only much faster, it's an improvement to the current behaviour in
terms of locking and thread safety. The current behaviour, as I said in comment
#4, could cause data to be badly mangled if one thread uses stdio while another
uses cin.getline(). Using getc() in preference to getc_unlocked() does not
help.
And unlike getdelim(), the unlocked I/O functions are in POSIX.1-2001, says the
man page, so it's relatively portable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #20 from paolo dot carlini at oracle dot com 2010-09-09 14:53 --- Good about POSIX, we would add a configure time test with some hope to enable the mechanism outside Linux too. Anyway, I'm sure your kind of loop would improve the performance a lot - if only we could have it without breaking the ABI I would be in favor of having it immediately - still, we would still use a single char function, I think the complexity for long lines would still scale badly. As a matter of fact, I think the only completely satisfactory design would be that used by the old v2, with a low level libio layer, doing buffering and the low level operations, and used by the C and C++ libraries on top. Missing that, I don't think the C++ library, working purely on top of the Standard C library will ever be able to performe as well as C in the synced mode. The only hope could be exploiting, on Linux systems, a glibc *extension* (we do that in many other cases), like an fgetc not writing '\0' and newline, which the glibc people would essentially provide exactly to help the C++ library implementation. Anyway, sorry if I may have appeared a little too harsh in my first replies, the fact is I know the history of these facilities, I know all the effort other people besides me put to have a good overall compromise (eg, stdio_sync isn't mine and solved a *a lot* of problems), we are certainly open to improvements, but realistic ones, at least until we break all the ABIs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug c++/45615] New: -Wshadow doesn't report class member shadowing
The following simple test program when compiled with -Wshadow produces no
output. I'd expect to get warnings for both the x and y declaration in class B.
class A {
static int x;
int y;
};
class B : public A {
static int x;
int y;
};
int main()
{
B a;
return 0;
}
If this is intentional, perhaps another -W flag is appropriate. I spent about
an hour trying to figure out why an app broke when I change a static class
member declared in a class's header to instead be an anonymous global in that
class's source file, and it was because all of the source file's references to
the variable after the change went to a parent class variable of the same name
and type rather than the global.
--
Summary: -Wshadow doesn't report class member shadowing
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joseph dot h dot garvin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45615
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #21 from jakub at gcc dot gnu dot org 2010-09-09 15:07 ---
#if __GNUC__ = 3
# define _IO_BE(expr, res) __builtin_expect ((expr), res)
#else
# define _IO_BE(expr, res) (expr)
#endif
#define _IO_getc_unlocked(_fp) \
(_IO_BE ((_fp)-_IO_read_ptr = (_fp)-_IO_read_end, 0) \
? __uflow (_fp) : *(unsigned char *) (_fp)-_IO_read_ptr++)
...
__STDIO_INLINE int
getc_unlocked (FILE *__fp)
{
return _IO_getc_unlocked (__fp);
}
i.e. if getc_unlocked is called directly, it should be very fast, unless the
underlying stream is unbuffered. This is direct access to the buffer, just STL
getline couldn't use memchr.
Anyway, not sure which STL getline we are talking about here, because e.g.
src/istream.cc getline seems to access the stdio buffer directly:
streamsize __size = std::min(streamsize(__sb-egptr()
- __sb-gptr()),
streamsize(__n - _M_gcount
- 1));
if (__size 1)
{
const char_type* __p = traits_type::find(__sb-gptr(),
__size,
__delim);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug target/44606] Wrong SPE floating point during computation
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-09-09 15:28 --- The problem is in the register allocator. What happens is that after register allocation, we have something like: r27:DF = [r11:SI] ... r27:SI = 0 ... and then the first def gets deleted because it's obviously dead code. I don't know why the register allocator chooses r27 for the SImode pseudo. Scheduling is necessary to trigger the bug, but it's not the problem. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #36 from ibolton at gcc dot gnu dot org 2010-09-09 15:37 --- Fixed in 4.4, 4.5 and trunk. -- ibolton at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c/45616] New: internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243
Here is the log :
arm-oc8s-linux-gnueabi-gcc -Wall -std=gnu99 -mthumb -save-temps
-DDEFAULT_GPIO=4 -c -o chrono.o chrono.c
chrono.c: In function 'chrono_diff':
chrono.c:188:1: error: insn does not satisfy its constraints:
(insn 236 40 41 chrono.c:155 (set (reg:DF 63 s0)
(reg:DF 1 r1)) 184 {*thumb_movdf_insn} (nil))
chrono.c:188:1: internal compiler error: in note_invalid_constants, at
config/arm/arm.c:11243
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [chrono.o] Error 1
--
Summary: internal compiler error: in note_invalid_constants, at
config/arm/arm.c:11243
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul dot chavent at fnac dot net
GCC build triplet: i486-slackware-linux-gnu
GCC host triplet: i486-slackware-linux-gnu
GCC target triplet: arm-oc8s-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616
[Bug c/45616] internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243
--- Comment #1 from paul dot chavent at fnac dot net 2010-09-09 15:53 --- Created an attachment (id=21753) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21753action=view) the preprocessed file that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616
[Bug c/45616] internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243
--- Comment #2 from paul dot chavent at fnac dot net 2010-09-09 15:54 --- Created an attachment (id=21754) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21754action=view) the options given when GCC was configured/built -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616
[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)
--- Comment #6 from mikpe at it dot uu dot se 2010-09-09 15:57 --- This ICE stopped to appear on trunk with r162019: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00373.html http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00827.html Applying the generic bits of that to current 4.5 stops the ICE there too. I can't say if r162019 is a genuine bug fix or merely improves things a bit so that this test case no longer triggers the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #22 from paolo dot carlini at oracle dot com 2010-09-09 16:08 --- Jakub, when, by default, cin co boil down to stdio_sync_filebuf, the underlying basic_streambuf is unbuffered, everything is unbuffered in the C++ library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug c++/45615] -Wshadow doesn't report class member shadowing
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-09 16:31 --- I agree this would be useful, I've had problems with such shadowing when moving members higher in inheritance hierarchies and accidentally missing occurrences in some derived classes. 4.2 is unmaintained now, but current releases don't warn either. -- redi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-09-09 16:31:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45615
[Bug c++/45606] [4.5/4.6 Regresssion] match a method prototyped a typedef alias with the original type (using stdlib)
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to work||4.4.4 Last reconfirmed|-00-00 00:00:00 |2010-09-09 16:31:41 date|| Summary|match a method prototyped a |[4.5/4.6 Regresssion] match |typedef alias with the |a method prototyped a |original type (using stdlib)|typedef alias with the ||original type (using stdlib) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
[Bug c++/45606] [4.5/4.6 Regresssion] match a method prototyped a typedef alias with the original type (using stdlib)
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-09 16:56 --- H.J. can you do a binary search on this? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
[Bug target/45616] internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-09 17:00 --- --with-cpu=arm926ej-s --with-tune=arm926ej-s --with-arch=armv5te --with-fpu=vfp --with-float=hard Hmm, these default CPUs don't support vfp in thumb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616
[Bug target/42070] FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-09-09 17:19 --- Created an attachment (id=21755) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21755action=view) patch to prune bogus linker warnings from Xcode 3.2.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42070
[Bug rtl-optimization/45617] New: optimize bit shift+compare at RTL level
+++ This bug was initially created as a clone of Bug #20517 +++
From comment #4:
- testcase.c -
_Bool foo(unsigned i)
{
return (i 5) 10;
}
_Bool bar(unsigned i)
{
return i (10 5) + 31;
}
int fooi(unsigned i)
{
return (i 5) 10;
}
int bari(unsigned i)
{
return i (10 5) + 31;
}
--
Compiled with:
$ gcc-4.6.0-pre tst6.c -O3 -S -m32 -fomit-frame-pointer
(svn r162190)
Results in:
foo:
movl4(%esp), %eax
shrl$5, %eax
cmpl$10, %eax
seta%al
ret
bar:
cmpl$351, 4(%esp)
seta%al
ret
fooi:
movl4(%esp), %eax
shrl$5, %eax
cmpl$10, %eax
seta%al
movzbl %al, %eax
ret
bari:
xorl%eax, %eax
cmpl$351, 4(%esp)
seta%al
ret
--
Summary: optimize bit shift+compare at RTL level
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC target triplet: x86(_64)-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45617
[Bug rtl-optimization/45617] optimize bit shift+compare at RTL level
--- Comment #1 from zsojka at seznam dot cz 2010-09-09 17:51 --- Created an attachment (id=21756) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21756action=view) Jakub's patch from PR20517 comment #6 gcc bootstrapped fine The resulting code for foo() and fooi() is the same as for bar() and bari(), respectively. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45617
[Bug tree-optimization/20517] bit shift/mask optimization potential
--- Comment #7 from zsojka at seznam dot cz 2010-09-09 17:52 --- (In reply to comment #5) Yes, please, and assign to me (working on a simplify_comparison fix for that). Opened PR45617, attached your patch with results (bootstrapped fine, optimisation seems to work). Thank you for having a look! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
[Bug testsuite/45604] [4.6 regression] New test failures
--- Comment #1 from aoliva at gcc dot gnu dot org 2010-09-09 18:07 --- Mine, thanks, testing a patch. Sorry about the breakage, I seem to have compared test results with a baseline that already had the errors :-( -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-09 18:07:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45604
[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target
--- Comment #4 from doko at gcc dot gnu dot org 2010-09-09 18:23 --- Subject: Bug 43847 Author: doko Date: Thu Sep 9 18:22:48 2010 New Revision: 164113 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164113 Log: 2010-09-09 Matthias Klose d...@ubuntu.com PR bootstrap/43847 * configure.ac (--enable-plugin): Enhance for cross builds. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
[Bug c++/45606] [4.5/4.6 Regression] match a method prototyped a typedef alias with the original type (using stdlib)
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-09 18:23 --- It is caused by revision 156316: http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00784.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target
--- Comment #5 from doko at gcc dot gnu dot org 2010-09-09 18:25 --- Subject: Bug 43847 Author: doko Date: Thu Sep 9 18:25:26 2010 New Revision: 164114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164114 Log: 2010-09-09 Matthias Klose d...@ubuntu.com PR bootstrap/43847 * configure.ac (--enable-plugin): Enhance for cross builds. * configure: Regenerate. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/configure branches/gcc-4_5-branch/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
[Bug middle-end/45312] [4.4 Regression] GCC 4.4.4 miscompiles the Linux kernel
--- Comment #19 from vmakarov at gcc dot gnu dot org 2010-09-09 18:36 --- Subject: Bug 45312 Author: vmakarov Date: Thu Sep 9 18:36:26 2010 New Revision: 164116 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164116 Log: 2010-09-09 Vladimir Makarov vmaka...@redhat.com PR middle-end/45312 * reload1.c (merge_assigned_reloads): Remove. (reload_as_needed): Don't call it. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug middle-end/45312] [4.4 Regression] GCC 4.4.4 miscompiles the Linux kernel
--- Comment #20 from vmakarov at gcc dot gnu dot org 2010-09-09 18:37 --- Subject: Bug 45312 Author: vmakarov Date: Thu Sep 9 18:37:17 2010 New Revision: 164117 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164117 Log: 2010-09-09 Vladimir Makarov vmaka...@redhat.com PR middle-end/45312 * reload1.c (merge_assigned_reloads): Remove. (reload_as_needed): Don't call it. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug middle-end/45312] [4.4 Regression] GCC 4.4.4 miscompiles the Linux kernel
--- Comment #21 from vmakarov at gcc dot gnu dot org 2010-09-09 18:38 --- Subject: Bug 45312 Author: vmakarov Date: Thu Sep 9 18:37:58 2010 New Revision: 164118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164118 Log: 2010-09-09 Vladimir Makarov vmaka...@redhat.com PR middle-end/45312 * reload1.c (merge_assigned_reloads): Remove. (reload_as_needed): Don't call it. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg
--- Comment #6 from kargl at gcc dot gnu dot org 2010-09-09 19:02 --- Fixed in trunk. No plans for back port to 4.5.x branch. I'll open a bug report about intent(out) issues with dummy arguments. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45495
[Bug c++/45618] New: GCC 4.4.4 strstream and ios::internal flag
The following code can be compiled with either g++ (GCC) 4.1.2 or g++ (GCC)
4.4.4.
When running the executable with non-static library, it produces different
output.
The output linked with strstream on g++ (GCC) 4.4.4 seems to be incorrect.
CODE:
/* File name iosflag.C */
#include iostream
#include strstream
using namespace std;
int main()
{
char string[1024];
char out_buffer[1024];
strstream io(out_buffer, 1024, ios::in|ios::out);
io.ios::fill('@');
io.flags(ios::internal);
io.width( 10 );
io (void *) 123 ' ';
io string ;
cout String: string endl;
}
COMPILE:
g++ -o iosflag ./iosflag.C
RUN:
./iosflag
EXPECTED RESULTS:
String: @@0x7b
ACTUAL RESULTS:
String: 0x@@7b
NOTE: strstream on g++ (GCC) 4.1.2 produce correct result.
--
Summary: GCC 4.4.4 strstream and ios::internal flag
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anhtuyen at ca dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618
[Bug fortran/45619] New: intent(out) dummy arguements in specification statements
gfortran does not correctly check that an intent(out) dummy argument does not appear in a specification statement. The following code is invalid, yet gfortan compiles it without error. subroutine sub(n, s) integer, intent(out) :: n character(len=*), intent(out) :: s character(len=len(s)) :: a ! Valid even though s is intent(out) character(len=len(s(1:n))) :: b! Invalid because n is intent(out) n = 0 a = 'tobias' s = a b = a end subroutine See the discussion in http://gcc.gnu.org/ml/fortran/2010-09/msg00074.html for more details. -- Summary: intent(out) dummy arguements in specification statements Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45619
[Bug target/45616] internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243
--- Comment #4 from paul dot chavent at fnac dot net 2010-09-09 19:09 --- Subject: Re: internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243 Sorry to haven't checking that. Thank you. pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-09 17:00 --- --with-cpu=arm926ej-s --with-tune=arm926ej-s --with-arch=armv5te --with-fpu=vfp --with-float=hard Hmm, these default CPUs don't support vfp in thumb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616
