--- 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
(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:
--- 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
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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++
--- 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
--- 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
--- 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.
--
--- 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
--- 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.
--
--- 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
--- 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
--- 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
--- 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
--- 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 #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
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
--- 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
--- 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.
--
--- 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
--
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
--- 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
--- 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
--- 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
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
--- 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
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
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/
--- 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
--- 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
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++
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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?
--- 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
--- 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
--- 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
--- 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 @@
--- 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.
--
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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++
--- 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
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;
--- 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)
--- 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
--- 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
--
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
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))
--- 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
--- 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
--- 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
--- 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.
--
--- 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
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- 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
--- 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
--- 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.
--
+++ 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)
{
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
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
--- 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
1 - 100 of 148 matches
Mail list logo
