xiao...@gentux test $ cat unamed.c
struct test {
struct {
int a;
};
};
int main()
{
struct test t1;
t1.a = 0; /* it is OK */
struct test t2 = {.a = 0}; /* error */
return 0;
}
xiao...@gentux test $ gcc unamed.c
unamed.c: In
--- Comment #6 from janus at gcc dot gnu dot org 2009-07-06 07:37 ---
The TBP problem is fixed by r149262 (thanks, Paul) and only PPC-related issues
are left (cf. comment #2 and #4). I'll take over.
--
janus at gcc dot gnu dot org changed:
What|Removed
Compile following code with options -Os -mthumb -march=armv5te
extern void bar(int*);
int foo()
{
int x;
bar(x);
return x;
}
Gcc generates:
push{lr}
sub sp, sp, #12
add r0, sp, #4
bl bar
ldr r0, [sp, #4]
add sp, sp,
--- Comment #1 from carrot at google dot com 2009-07-06 08:16 ---
Created an attachment (id=18140)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18140action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
--- Comment #36 from dominiq at lps dot ens dot fr 2009-07-06 09:03 ---
Closing as fixed.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-06 09:13 ---
IIRC push-multiple and pop-multiple are not supported yet. Richard E.?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the following code snippet with g++ -m32 -S -Wall -O2 t.cc on a
64bit machine issues a warning
t.cc: In static member function 'static void
NewDelFunctionsTT::deleteArray_T(void*) [with T = EcalTPGLut]':
t.cc:12: warning: array subscript is below array bounds
This does not happen with
--- Comment #1 from mikpe at it dot uu dot se 2009-07-06 09:32 ---
Ditto here on powerpc64-unknown-linux-gnu. -m32 gives the warning, -m64 does
not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40658
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-06 09:54 ---
(In reply to comment #2)
IIRC push-multiple and pop-multiple are not supported yet. Richard E.?
I am not sure what you mean here. push and pop multiple are supported to the
best of the cases that GCC can detect
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-06 09:57
---
I'm afraid it's highly unlikely that this will be fixed in 4_3-branch... To the
best of my knowledge, fixing it involved a few rather invasive patches and the
branch is close to its end of life...
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-06 10:15 ---
Use
struct test t2 = { { .a = 0 } };
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-06 10:17 ---
Because you are doing ... copies!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-07-06 10:33 ---
(In reply to comment #5)
Perhaps there are two bugs, not one, as my more elaborate testcases show.
Though they are seemingly equivalent, one triggers the bug, while another
don't.
Ok, is the same issue
--- Comment #4 from florian at openwrt dot org 2009-07-06 10:38 ---
(In reply to comment #2)
Does -fno-ipa-cp fix it?
Unfortunately, no the problem is still there event with -fno-ipa-cp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
--- Comment #5 from florian at openwrt dot org 2009-07-06 10:39 ---
(In reply to comment #3)
Btw, with a cross I cannot seem to reproduce the problem. How do non-inlined
calls look like with mips?
Let me attach a file showing how it looks like.
--
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-06 10:43 ---
Ah, heh, so you're saying that pushing/popping registers you don't have to save
may be a size optimization? That's an interesting idea.
But how to do this in GCC... The push {lr} is never even in the RTL. Output
--- Comment #3 from gcc at axel-naumann dot de 2009-07-06 10:59 ---
OK, I didn't know that the branch is closed, nor that it involves extensive
changes. Sorry it took me so long to find this! I can of course use #pragma GCC
diagnostic ignored -Warray-bounds if needed.
--
--- Comment #4 from manu at gcc dot gnu dot org 2009-07-06 11:21 ---
This is FIXED in GCC 4.4. There may be a 4.3.4 release but this is not a
regression and nobody seems interested in investigating whether it can be fixed
with a minimal patch. So I am closing it as FIXED.
If you can
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
|
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
|
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-07-06 11:43
---
Confirmed. Just compile with -O --param hot-bb-frequency-fraction=0 :
==
void foo() {}
==
This happens since the introduction of hot-bb-frequency-fraction
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-07-06 11:54 ---
Ok, I think I found the issue. The following patch solved the ICE here. The ebx
register wasn't allowed for sibcall_1 in i386.md, but for fastcall it can be
used for sibcalling.
I have to do a regression test for
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2009-07-06 12:49
---
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 149152)
+++ config/i386/i386.md (working copy)
@@ -15536,7 +15536,7 @@
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-07-06 13:17 ---
(In reply to comment #8)
This cannot be correct in the general case as %ebx is call-saved, you cannot
clobber it through a function call. A solution could be to disparage the 'c'
alternative, but a x86 maintainer
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-06 13:19 ---
The root cause is a combination of inline and copy-rename. Copy rename has the
following code:
/* Never attempt to coalesce 2 user variables unless one is an inline
variable. */
if (!ign1 !ign2)
{
--- Comment #8 from kkojima at gcc dot gnu dot org 2009-07-06 13:28 ---
Subject: Bug 30807
Author: kkojima
Date: Mon Jul 6 13:28:22 2009
New Revision: 149282
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149282
Log:
PR rtl-optimization/30807
* postreload.c
This is not a bug.
In the man page of the isdigit:
These functions check whether c, which must have the value of an
unsigned char or EOF, falls into a certain character class according
to the current locale.
You should first test your value with a isascii if using isdigit.
Your code has a
dwarf2out.c (add_data_member_location_attribute) always generates a full dwarf
location expression even for simple struct member offsets. This results in
debug_info for structs that looks like this:
177: Abbrev Number: 7 (DW_TAG_structure_type)
78 DW_AT_name: (indirect string,
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-07-06 15:31
---
Well, why? For save or called saved registers the functions epilogue/prologue
takes care. The reason why gcc tries to choose ebx for call address register
here, is exactly this reason, as it can be sure that
Maybe this is a side effect of fixing a DWARF bug, but using GCC 4.5 with
gdb (GDB) SUSE (6.8.50.20090302-41.3) [contains Merge FC11 update 23] does
not work while with GCC 4.4 it does.
Example (compile with gfortran -g):
PROGRAM test
INTEGER, DIMENSION(3) :: a1,a2
a1 = 1
PRINT*, a1
a2 =
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-07-06 16:12 ---
(In reply to comment #10)
Well, why? For save or called saved registers the functions
epilogue/prologue
takes care. The reason why gcc tries to choose ebx for call address register
here, is exactly this
--- Comment #12 from ktietz at gcc dot gnu dot org 2009-07-06 16:13 ---
And this is pretty wrong :}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
--- Comment #13 from ktietz at gcc dot gnu dot org 2009-07-06 16:41 ---
By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that c
is last element, produced code is ok and no ICE I've seen. The ebx issue is
pretty wrong here.
Index: gcc/gcc/config/i386/i386.md
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-07-06 16:43
---
By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that c
is last element, produced code is ok and no ICE I've seen.
Disparaging it (s,!c,d,a) would be even more robust I think.
--
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-06 16:48 ---
We could add an OPT_Wdefault that replaces 0 in pedwarn(loc, 0, message),
then -Werror=default would turn all default warnings into errors. And
-Wno-default will turn off default warnings that cannot be currently
=== Begin complete code ===
#include stdio.h
static int y = -1234;
int main(void)
{
extern int y;
printf(%d\n, y);
return 0;
}
=== End complete code ===
command line: gcc -W -Wall test.c
Output:
test.c:3: warning:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-06 16:59 ---
This was fixed in 4.0.0, the c-decl rewrite was not completed until 4.0.0
really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from ktietz at gcc dot gnu dot org 2009-07-06 17:02 ---
(In reply to comment #14)
By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that
c
is last element, produced code is ok and no ICE I've seen.
Disparaging it (s,!c,d,a) would be even
--- Comment #6 from flameeyes at gentoo dot org 2009-07-06 17:03 ---
To be honest there are quite a few default warnings that I wouldn't want to
turn into errors, but it would still be better than having _no_ way to get this
into an error.
--
--- Comment #2 from MSHojatoleslami at Gmail dot com 2009-07-06 17:19
---
Thanks for your answer.
But there is no need to copy them always as you know:
// -- begin
#include iostream
class A
{
public :
A (int i)
{
std::cout Copy constructor is not used.
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-07-06 17:21
---
(In reply to comment #0)
// ERROR: How could i use the auto keyword which exist in GCC 4.4
auto a1 = A (5);
You need to use -std=c++0x to enable C++0x features.
--
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-07-06 17:34
---
See 8.5 [dcl.init] paragraph 12
The initialization that occurs in argument passing, function return, throwing
an exception (15.1), handling an exception (15.3), and brace-enclosed
initializer lists (8.5.1) is
When I compile and run the following program under gfortran 4.5 I get a
segfault. It does not segfault under gfortran 4.3 or 4.4. The problem occurs on
any platform.
PROGRAM astap
ARLXCA = 0.0
WRITE(6,40) ARLXCA
WRITE(6,40) ARLXCA
40FORMAT(T4,ARLXCA =
--- Comment #1 from dominiq at lps dot ens dot fr 2009-07-06 18:07 ---
This seems to be fixed by the patch in comment #33 of pr40330.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-07-06 18:12
---
Yes indeed it is fixed with my patch of this morning. This is the reduced test
case we can use for the test suite.
Thanks for the report Michael!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40662
--- Comment #3 from kargl at gcc dot gnu dot org 2009-07-06 18:18 ---
(In reply to comment #1)
This seems to be fixed by the patch in comment #33 of pr40330.
Removing the 1st occurrence of T27 in the format is sufficient to
remove the segfault.
--
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-06 18:18
---
Of course.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from MSHojatoleslami at Gmail dot com 2009-07-06 18:38
---
Thank you :)
I don't know what should i say, but it seems that this was my ... mistake!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40655
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-06 19:27 ---
I have not bootstrapped with GMP/MPFR in tree so I don't know if that works. I
always have a build of GMP and MPFR around so it does not compile GMP/MPFR
again when building GCC.
--
pinskia at gcc dot gnu dot
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-06 19:30 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-06 19:30 ---
Mark as a duplicate of bug 10676 which is still open by the way.
*** This bug has been marked as a duplicate of 10676 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-07-06 19:30
---
*** Bug 40656 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Tisztelt Cim!
Szeretnénk Önnek bemutatni 2009 Dijnyertes kemprogram alkalmazasat : A Real Spy
Monitor 2009 -t!
A szoftverunk segitsegevel On is konnyeden megfigyelheti titokban
szamitogepenek aktivitasat,
az azt hasznalok internetezesi szokasait.
- Megtudhatja hogy parja kivel MSN -ezik,
The following code fails to compile on GCC 4.3.3. It compiles on Intel C++ 11.1
and Comeau 4.3.10.1.
g++ -v -save-temps main.cpp
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-07-06 19:45
---
2 cents. Memory is cheap, very cheap. When you can buy a x86-64 based laptop
with 3 gig for under 500 dollars, it does not matter that much.
Now, if you are doing embedded systems, that may be a different tune
--- Comment #5 from jason at gcc dot gnu dot org 2009-07-06 20:45 ---
This is only known to be NULL if we know the dynamic type of p. Consider:
struct Foo: Base {};
struct Bar: Derived, Foo {};
Bar bar;
Base *p2 = (Foo*)bar;
A dynamic_cast to Derived from p2 should succeed. But it
--- Comment #6 from bangerth at gmail dot com 2009-07-06 20:56 ---
(In reply to comment #3)
I had to stare at the testcase in comment #3 for a little while and thought
others may have to as well: it fails because the inheritance from Base is
*private*, not because the dynamically
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-06 21:58 ---
Running
/Users/apinski/src/local/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp
...
ERROR: tcl error sourcing
/Users/apinski/src/local/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp.
Looks like the same
--- Comment #1 from zlynx at acm dot org 2009-07-06 22:33 ---
I agree. This would be very useful. I am trying to do this very thing and am
running into errors with missing typeinfo and other things.
--
zlynx at acm dot org changed:
What|Removed
--- Comment #1 from booleandomain at gmail dot com 2009-07-06 23:06 ---
Now I'm trying to compile gcc-4.4.0 configured as follows:
../gcc-4.4.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --enable-languages=c --disable-multilib
make
--- Comment #24 from bkoz at gcc dot gnu dot org 2009-07-06 23:49 ---
Closing due to lack of feedback
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-07-06 23:55 ---
Yes, I will look at this. I think Ben Elliston pointed this out right after
4.4.0 was released, along with some other uninitialized warnings that I then
fixed.
Apparently this is also visible on ppc.
--
bkoz at
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-07 00:58
---
Richard, any chance you can look a bit into this? Many thanks in advance.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Gcc became recently (4.4) very bad regarding false positive type-punned
warnings. In previous versions, the warnings could be suppressed by casting to
(void *), in 3.x and 4.1 it worked perfectly, in 4.3 it still worked somehow
(except in -Wstrict-aliasing=3 mode), in 4.4 there are cases where it
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 01:22 ---
Created an attachment (id=18145)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18145action=view)
a bug in -Wstrict-aliasing=3
This is an example of a flaw in -Wstrict-aliasing=3 (this
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 01:34 ---
Created an attachment (id=18146)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146action=view)
a bug in -Wstrict-aliasing=3
This is an example of a flaw in -Wstrict-aliasing=3 (this
../../xgcc -B../../ -c -O2 -O0 -g -W -Wall -Wwrite-strings
-Wstrict-prototypes
-Wmissing-prototypes -mdisable-indexing -gnatpg -gnata -I- -I../rts -I.
-I/mnt/
gnu/gcc/gcc/gcc/ada /mnt/gnu/gcc/gcc/gcc/ada/ali.adb -o ali.o
+===GNAT BUG
This is performance regression from 4.3 (which was better).
On i386, when -O2 -fomit-frame-pointer -mpreferred-stack-boundary=2 is used,
and function operates with long long values, stack frame is generated, although
it doesn't have to be.
Example:
int f(long long x);
int g(long long x)
{
Sent from my iPhone
On Jul 6, 2009, at 6:12 PM, mikulas at artax dot karlin dot mff dot
cuni dot cz gcc-bugzi...@gcc.gnu.org wrote:
Gcc became recently (4.4) very bad regarding false positive type-
punned
warnings. In previous versions, the warnings could be suppressed by
casting to
--- Comment #3 from pinskia at gmail dot com 2009-07-07 03:44 ---
Subject: Re: New: dereferencing type-punned pointer warnings cannot be
disabled
Sent from my iPhone
On Jul 6, 2009, at 6:12 PM, mikulas at artax dot karlin dot mff dot
cuni dot cz gcc-bugzi...@gcc.gnu.org wrote:
Sent from my iPhone
On Jul 6, 2009, at 6:34 PM, mikulas at artax dot karlin dot mff dot
cuni dot cz gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni
dot cz 2009-07-07 01:34 ---
Created an attachment (id=18146)
--
--- Comment #4 from pinskia at gmail dot com 2009-07-07 03:48 ---
Subject: Re: dereferencing type-punned pointer warnings cannot be disabled
Sent from my iPhone
On Jul 6, 2009, at 6:34 PM, mikulas at artax dot karlin dot mff dot
cuni dot cz gcc-bugzi...@gcc.gnu.org wrote:
Thus code is undefined you have an acess of a char array as a struct.
Yes you are only taking the address of an element but it is still
considered an acess by the standards.
Sent from my iPhone
On Jul 6, 2009, at 6:34 PM, mikulas at artax dot karlin dot mff dot
cuni dot cz
--- Comment #5 from pinskia at gmail dot com 2009-07-07 03:50 ---
Subject: Re: dereferencing type-punned pointer warnings cannot be disabled
Thus code is undefined you have an acess of a char array as a struct.
Yes you are only taking the address of an element but it is still
--- Comment #1 from pault at gcc dot gnu dot org 2009-07-07 05:01 ---
(In reply to comment #0)
The following program fails with:
procedure(sub), pointer :: pptr2
1
Error: Interface 'sub' of procedure 'pptr2' at (1) must be explicit
The
The following program should print 12345678. When it is built with -O2 -m64
or -O3 -fno-inline -m64 on sparc, it instead prints 0.
I ran this test with the command /opt/cfarm/release/4.4.0/bin/gcc -fno-inline
-O3 -m64 -g combined.c on gcc62 in the GCC compile farm.
--- Comment #1 from blp at cs dot stanford dot edu 2009-07-07 05:57 ---
Created an attachment (id=18147)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18147action=view)
preprocessed test input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
--- Comment #2 from blp at cs dot stanford dot edu 2009-07-07 05:58 ---
Created an attachment (id=18148)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18148action=view)
test program (before preprocessing)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
80 matches
Mail list logo
