[Bug fortran/40646] [F03] array-valued procedure pointer components
--- 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 |Added AssignedTo|pault at gcc dot gnu dot org|janus at gcc dot gnu dot org Summary|ICE assigning array return |[F03] array-valued procedure |value from type-bound |pointer components |procedure | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40646
[Bug target/40657] New: allocate local variables with fewer instructions
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, #12
@ sp needed for prologue
pop {pc}
A better code sequence could be:
push{r1-r3,lr}
add r0, sp, #4
bl bar
ldr r0, [sp, #4]
@ sp needed for prologue
pop {r1-r3, pc}
The local variable allocation and deallocation can be merged into the push/pop
instruction, so we can avoid the extra sub/add instructions and reduce two
instructions.
--
Summary: allocate local variables with fewer instructions
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug target/40657] allocate local variables with fewer instructions
--- 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=18140&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug target/40657] allocate local variables with fewer instructions
--- 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 CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-06 09:13:55 date|| Summary|allocate local variables|allocate local variables |with fewer instructions |with fewer instructions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug c++/40658] New: spurious warning "array subscript is below array bounds"
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
NewDelFunctionsT::deleteArray_T(void*) [with T = EcalTPGLut]':
t.cc:12: warning: array subscript is below array bounds
This does not happen with 4.4.
t.cc:
class EcalTPGLut {
public:
~EcalTPGLut() ;
private:
unsigned int lut_[1024];
};
template
struct NewDelFunctionsT {
static void
deleteArray_T(void* p) { delete[] (T*) p; }
};
typedef void (*DelArrFunc_t)(void*);
DelArrFunc_t method_newdel_98() {
return NewDelFunctionsT< ::EcalTPGLut >::deleteArray_T;
}
--
Summary: spurious warning "array subscript is below array bounds"
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at axel-naumann dot de
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40658
[Bug c++/40658] spurious warning "array subscript is below array bounds"
--- 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
[Bug target/40657] allocate local variables with fewer instructions
--- 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 them. since load and store multiple are not first class citizens, the ARM backend attempts to detect them in the form of peephole2's and peephole's. However this case isn't to do with push or pop multiple but to do with saving space in the thumb prologue and epilogue by emitting push and pop multiple instructions instead of explicit instructions to manipulate the stack. Notice that r2 and r3 are not used in the code that Carrot is proposing in comment #1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug c++/40658] spurious warning "array subscript is below array bounds"
--- 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... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40658
[Bug c/40656] Can't initial the fields of unamed struct/union.
--- 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
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40656
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40655
[Bug target/38900] ICE: unable to find a register to spill
--- 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 occurring, when the attributes are set separately in different __attribute__ statements? Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug c/40641] gcc-4.4.0 does not honor the alway_inline attribute when using -Os
--- 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
[Bug c/40641] gcc-4.4.0 does not honor the alway_inline attribute when using -Os
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
[Bug target/40657] allocate local variables with fewer instructions
--- 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
with same options + "-dAP":
foo:
push{lr}
@ basic block 2
@(insn/f 20 2 21 t.c:3 (set (reg/f:SI 13 sp)
@(plus:SI (reg/f:SI 13 sp)
@(const_int -12 [0xfff4]))) 5 {*thumb1_addsi3} (nil))
@ 0x
sub sp, sp, #12 @ 20*thumb1_addsi3/7[length = 2]
@(insn 6 21 7 t.c:5 (set (reg:SI 0 r0)
@(plus:SI (reg/f:SI 13 sp)
@(const_int 4 [0x4]))) 5 {*thumb1_addsi3} (expr_list:REG_EQUAL
(plus:SI (reg/f:SI 13 sp)
@(const_int 4 [0x4]))
@(nil)))
@ 0x0002
add r0, sp, #4 @ 6 *thumb1_addsi3/6[length = 2]
@(call_insn 7 6 13 t.c:5 (parallel [
@(call (mem:SI (symbol_ref:SI ("bar") [flags 0x41] ) [0 S4 A32])
@(const_int 0 [0x0]))
@(use (const_int 0 [0x0]))
@(clobber (reg:SI 14 lr))
@]) 253 {*call_insn} (expr_list:REG_DEAD (reg:SI 0 r0)
@(nil))
@(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
@(nil)))
@ 0x0004
bl bar @ 7 *call_insn [length = 4]
@(insn 13 7 22 t.c:7 (set (reg/i:SI 0 r0)
@(mem/c/i:SI (plus:SI (reg/f:SI 13 sp)
@(const_int 4 [0x4])) [2 x+0 S4 A32])) 167 {*thumb1_movsi_insn}
(nil))
@ 0x0008
ldr r0, [sp, #4]@ 13*thumb1_movsi_insn/7[length = 2]
@(insn 23 22 16 t.c:7 (set (reg/f:SI 13 sp)
@(plus:SI (reg/f:SI 13 sp)
@(const_int 12 [0xc]))) 5 {*thumb1_addsi3} (nil))
@ 0x000a
add sp, sp, #12 @ 23*thumb1_addsi3/7[length = 2]
@(insn 24 16 25 t.c:7 (unspec:SI [
@(reg/f:SI 13 sp)
@] 6) 339 {prologue_use} (nil))
@ 0x000c
@ sp needed for prologue@ 24prologue_use[length = 0]
@(jump_insn 25 24 26 t.c:7 (unspec_volatile [
@(return)
@] 1) 321 {*epilogue_insns} (nil))
@ 0x000c
pop {pc}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug c++/40658] spurious warning "array subscript is below array bounds"
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40658
[Bug c++/40658] spurious warning "array subscript is below array bounds"
--- 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 reproduce it with GCC 4.5, please reopen. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40658
[Bug c++/40633] [c++0x] ICE with scoped enum inside a template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-07-06 11:23:50 date|| Summary|ICE with scoped enum inside |[c++0x] ICE with scoped enum |a template |inside a template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40633
[Bug rtl-optimization/40519] [4.5 Regression] ICE with -O2 -ftracer __builtin_unreachable()
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-07-06 11:33:34 date|| Summary|ICE with -O2 -ftracer |[4.5 Regression] ICE with - |__builtin_unreachable() |O2 -ftracer ||__builtin_unreachable() Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40519
[Bug middle-end/40119] ICE with --param hot-bb-frequency-fraction=0
--- 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 in GCC 3.3.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2009-07-06 11:43:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40119
[Bug target/38900] ICE: unable to find a register to spill
--- 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 it, but it seems to work well.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 149152)
+++ config/i386/i386.md (working copy)
@@ -15536,7 +15536,7 @@
[(set_attr "type" "call")])
(define_insn "*sibcall_1"
- [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a"))
+ [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a,b"))
(match_operand 1 "" ""))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
@@ -22183,7 +22183,7 @@
(define_insn "*sibcall_value_1"
[(set (match_operand 0 "" "")
- (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a"))
+ (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a,b"))
(match_operand:SI 2 "" "")))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2009-05-13 20:04:31 |2009-07-06 11:54:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
-- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-06 11:54:21 |2009-07-06 12:38:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug middle-end/40119] ICE with --param hot-bb-frequency-fraction=0
-- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-06 11:43:49 |2009-07-06 12:48:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40119
[Bug target/38900] ICE: unable to find a register to spill
--- 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 @@
>[(set_attr "type" "call")])
>
> (define_insn "*sibcall_1"
> - [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a"))
> + [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a,b"))
> (match_operand 1 "" ""))]
>"SIBLING_CALL_P (insn) && !TARGET_64BIT"
> {
> @@ -22183,7 +22183,7 @@
>
> (define_insn "*sibcall_value_1"
>[(set (match_operand 0 "" "")
> - (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a"))
> + (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a,b"))
> (match_operand:SI 2 "" "")))]
>"SIBLING_CALL_P (insn) && !TARGET_64BIT"
> {
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 will know better.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- 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 will know better. > 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 after the sibcall, the register is still valid. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug c/40635] bogus name and location in 'may be used uninitialized' warning
--- 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)
{
if (DECL_FROM_INLINE (root2))
ign2 = true;
else if (DECL_FROM_INLINE (root1))
ign1 = true;
else
{
if (debug)
fprintf (debug, " : 2 different USER vars. No coalesce.\n");
return false;
}
}
/* If both values have default defs, we can't coalesce. If only one has a
tag, make sure that variable is the new root partition. */
if (gimple_default_def (cfun, root1))
{
if (gimple_default_def (cfun, root2))
{
if (debug)
fprintf (debug, " : 2 default defs. No coalesce.\n");
return false;
}
else
{
ign2 = true;
ign1 = false;
}
}
else if (gimple_default_def (cfun, root2))
{
ign1 = true;
ign2 = false;
}
The net result is that when it combines sockt_rd with s42, it favours s42. This
is the reason it prints s42. However, the location printed corresponds to the
statement:
if (sockt_rd < 0)
return -1;
Then, warn_uninit is not able to detect that this comes from some inlined
thing. If we do this:
- location = (context != NULL && gimple_has_location (context))
+ location = (!DECL_FROM_INLINE (var) && context != NULL
+ && gimple_has_location (context))
? gimple_location (context)
-: DECL_SOURCE_LOCATION (var);
+: DECL_SOURCE_LOCATION (DECL_ORIGIN (var));
Then we get the right location (line, column) but still the wrong function. I
am not sure how to force the diagnostics machinery to display the correct
function.
--
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 |2009-07-06 13:19:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)
--- 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=gcc&view=rev&rev=149282 Log: PR rtl-optimization/30807 * postreload.c (reload_combine): For every new use of REG_SUM, record the use of BASE. Modified: trunk/gcc/ChangeLog trunk/gcc/postreload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
Re: segmentation fault isdigit() cuasing the problem.
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 major memory overflow risk:
scanf("%d", &devisor);
1) Your test is wrong:
while(isdigit(devisor)); does not do what you think.
When you are giving it 21, it takes that code and says : the ASCII
code 22 is not a digital value in the ASCII table.
2) scanf is really a dangerous function, because of this overflow
issue, bad error handling.
- better is scanf with a %s in a buffer that you parse
afterwards with strtol for example (good for error testing)
- even better, fgets which allows to minimize the bugs of your
code by allowing error management.
Jc
On Thu, Jul 2, 2009 at 1:55 AM, vartan wrote:
> dear maintainer:
> the fallowing is a small sample of the code that contains all the info
> to reproduce the problem.
> the C library function isdigit() fails and causes segmention fault when
> the input is is not numeric like xx.
>
> COMPILE COMMAND : >> gcc -ansi --version -Wall -o ch2-13.out -lm
> ch2-13.c
> gcc (Debian 4.3.2-1.1) 4.3.2
> Copyright (C) 2008 Free Software Foundation, Inc
>
[Bug debug/40659] New: A simple struct member offset doesn't need a full dwarf location expression
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:
<1><77>: Abbrev Number: 7 (DW_TAG_structure_type)
<78> DW_AT_name: (indirect string, offset: 0x64): mystruct
<7c> DW_AT_byte_size : 40
<7d> DW_AT_decl_file : 1
<7e> DW_AT_decl_line : 5
<7f> DW_AT_sibling : <0xc0>
<2><83>: Abbrev Number: 8 (DW_TAG_member)
<84> DW_AT_name: n
<86> DW_AT_decl_file : 1
<87> DW_AT_decl_line : 6
<88> DW_AT_type: <0xc0>
<8c> DW_AT_data_member_location: 2 byte block: 23 0
(DW_OP_plus_uconst: 0)
<2><8f>: Abbrev Number: 8 (DW_TAG_member)
<90> DW_AT_name: c
<92> DW_AT_decl_file : 1
<93> DW_AT_decl_line : 7
<94> DW_AT_type: <0x6a>
<98> DW_AT_data_member_location: 2 byte block: 23 8
(DW_OP_plus_uconst: 8)
<2><9b>: Abbrev Number: 8 (DW_TAG_member)
<9c> DW_AT_name: i
<9e> DW_AT_decl_file : 1
<9f> DW_AT_decl_line : 8
DW_AT_type: <0x57>
DW_AT_data_member_location: 2 byte block: 23 10
(DW_OP_plus_uconst: 16)
The dwarf spec says:
"If a data member is defined in a structure, union or class, the corresponding
member entry has a DW_AT_data_member_location attribute whose value describes
the location of that member relative to the base address of the structure,
union, or class that most closely encloses the member declaration. If that
value is a constant, it is the offset in bytes from the beginning of the
innermost enclosing structure, union or class to the beginning of the data
member. Otherwise, the value must be a location description."
So if we only have a simple constant offset it seems more space efficient to
output the offset as a constant instead of a location expression using
DW_OP_plus_uconst.
A suggested patch might be the following (still building/testing against gdb
and stap - gdb should work, systemtap will need some adjusting):
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 149279)
+++ gcc/dwarf2out.c (working copy)
@@ -11475,8 +11475,6 @@
if (! loc_descr)
{
- enum dwarf_location_atom op;
-
/* The DWARF2 standard says that we should assume that the structure
address is already on the stack, so we can specify a structure field
address by using DW_OP_plus_uconst. */
@@ -11485,12 +11483,16 @@
/* ??? The SGI dwarf reader does not handle the DW_OP_plus_uconst
operator correctly. It works only if we leave the offset on the
stack. */
+ enum dwarf_location_atom op;
+
op = DW_OP_constu;
+ loc_descr = new_loc_descr (op, offset, 0);
#else
- op = DW_OP_plus_uconst;
+ /* Don't need an whole location expression, just a constant offset. */
+ add_AT_int (die, DW_AT_data_member_location, offset);
+ return;
#endif
- loc_descr = new_loc_descr (op, offset, 0);
}
add_AT_loc (die, DW_AT_data_member_location, loc_descr);
That will simplify the debug_info for structs so it reads:
<1><77>: Abbrev Number: 7 (DW_TAG_structure_type)
<78> DW_AT_name: (indirect string, offset: 0x3d): mystruct
<7c> DW_AT_byte_size : 40
<7d> DW_AT_decl_file : 1
<7e> DW_AT_decl_line : 4
<7f> DW_AT_sibling : <0xb6>
<2><83>: Abbrev Number: 8 (DW_TAG_member)
<84> DW_AT_name: n
<86> DW_AT_decl_file : 1
<87> DW_AT_decl_line : 6
<88> DW_AT_type: <0xb6>
<8c> DW_AT_data_member_location: 0
<2><8d>: Abbrev Number: 8 (DW_TAG_member)
<8e> DW_AT_name: c
<90> DW_AT_decl_file : 1
<91> DW_AT_decl_line : 7
<92> DW_AT_type: <0x6a>
<96> DW_AT_data_member_location: 8
<2><97>: Abbrev Number: 8 (DW_TAG_member)
<98> DW_AT_name: i
<9a> DW_AT_decl_file : 1
<9b> DW_AT_decl_line : 8
<9c> DW_AT_type: <0x57>
DW_AT_data_member_location: 16
--
Summary: A simple struct member offset doesn't need a full dwarf
location expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40659
[Bug target/38900] ICE: unable to find a register to spill
--- 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 after the sibcall, the > register is still valid. What's the assembly code generated with your patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug debug/40660] New: [4.5 Regression] Wierd break points with 4.5, works with 4.4
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 = 2 end program test GCC 4.4 with gdb: (gdb) b 3 Breakpoint 1 at 0x4007a7: file test.f90, line 3. (gdb) run Starting program: /dev/shm/a.out Breakpoint 1, test () at test.f90:3 3 a1 = 1 Current language: auto; currently fortran (gdb) n 4 PRINT*, a1 (gdb) pt a1 type = integer(kind=4) (3) (gdb) p a1 $1 = (1, 1, 1) (gdb) n 1 1 1 5 a2 = 2 GCC 4.5 with gdb: (gdb) b 3 Breakpoint 1 at 0x400738: file test.f90, line 3. (gdb) run Starting program: /dev/shm/a.out Breakpoint 1, test () at test.f90:3 3 a1 = 1 Current language: auto; currently fortran (gdb) p a1 $1 = (8, 0, -1417923840) (gdb) n 1 1 1 0x2b48ca4d in __libc_start_main () from /lib64/libc.so.6 -- Summary: [4.5 Regression] Wierd break points with 4.5, works with 4.4 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
[Bug target/38900] ICE: unable to find a register to spill
--- 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 reason, as it can be sure that after the sibcall, the > > register is still valid. > > What's the assembly code generated with your patch? > Compiling the test case with -O2 .file "c_impfast.c" .text .p2align 4,,15 .globl _f .def_f; .scl2; .type 32; .endef _f: pushl %ebp movl$2, %ecx movl%esp, %ebp pushl %ebx subl$4, %esp movl__i...@h@4, %ebx call*%ebx addl$4, %esp movl$1, %ecx popl%ebx popl%ebp jmp *%ebx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- 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
[Bug target/38900] ICE: unable to find a register to spill
--- 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
===
--- gcc.orig/gcc/config/i386/i386.md2009-07-06 18:14:36.15567 +0200
+++ gcc/gcc/config/i386/i386.md 2009-07-06 18:36:54.453670100 +0200
@@ -15536,7 +15536,7 @@
[(set_attr "type" "call")])
(define_insn "*sibcall_1"
- [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a"))
+ [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,d,a,c"))
(match_operand 1 "" ""))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
@@ -22183,7 +22183,7 @@
(define_insn "*sibcall_value_1"
[(set (match_operand 0 "" "")
- (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a"))
+ (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,d,a,c"))
(match_operand:SI 2 "" "")))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug c/37866] "passing argument from incompatible pointer type" warning cannot be passed to -Werror=
--- 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 controlled. Diego, would that satisfy you? If we want further fine control, we would need to add further -Wxxx options for specific default warnings. -- 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 |2009-07-06 16:48:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37866
[Bug c/40661] New: Incorrect warning "defined but not used"
=== Begin complete code ===
#include
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: 'y' defined but not used
As you can see "y" is defined (in line 3), then declared in line 7
and used in line 8. The program also executes correctly.
The use of an "extern" storage class specifier is a bit unusual
but perfectly legal (See ISO/IEC 9899:1999 chapter 6.2.2, paragraph 4).
If anything a warning about this slightly obscure construct might be in OK,
but not about an unused variable.
I would have liked to verify with a newer GCC version but haven't
got any available here, sorry.
--
Summary: Incorrect warning "defined but not used"
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ahelm at gmx dot net
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40661
[Bug c/40661] Incorrect warning "defined but not used"
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40661
[Bug target/38900] ICE: unable to find a register to spill
--- 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 more robust I think.
>
yeah, this works, too. But the d needs the !, too. As when I alter my testcase
by giving the dllimport'ed fastcall a second argument, it ICEs again.
$ /usr/local/bin/i686-pc-mingw32-gcc.exe -o t.s -S c_impfast2.c -O2
c_impfast2.c: In function 'f':
c_impfast2.c:7:1: error: unable to find a register to spill in class 'DREG'
c_impfast2.c:7:1: error: this is the insn:
(call_insn/j 12 10 13 2 c_impfast2.c:6 (call (mem:QI (reg/f:SI 3 bx [58]) [0 S1
A8])
(const_int 0 [0x0])) 462 {*sibcall_1} (expr_list:REG_DEAD (reg/f:SI 3
bx [58])
(expr_list:REG_DEAD (reg:SI 2 cx)
(expr_list:REG_DEAD (reg:SI 1 dx)
(nil
(expr_list:REG_DEP_TRUE (use (reg:SI 2 cx))
(expr_list:REG_DEP_TRUE (use (reg:SI 1 dx))
(nil
c_impfast2.c:7:1: internal compiler error: in spill_failure, at reload1.c:2094
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
So with both c and d changed to !c and !d for sibcall_1 and sibcall_value_1 it
translates without ICE to:
.file "c_impfast2.c"
.text
.p2align 4,,15
.globl _f
.def_f; .scl2; .type 32; .endef
_f:
pushl %ebp
movl$1, %edx
movl%esp, %ebp
movl$2, %ecx
pushl %ebx
subl$4, %esp
movl__i...@h@8, %ebx
call*%ebx
addl$4, %esp
movl$2, %edx
movl$1, %ecx
movl%ebx, %eax
popl%ebx
popl%ebp
jmp *%eax
New patch for i386.md (and you are right the !c,!d is more robust here) is:
Index: gcc/gcc/config/i386/i386.md
===
--- gcc.orig/gcc/config/i386/i386.md2009-07-06 18:14:36.15567 +0200
+++ gcc/gcc/config/i386/i386.md 2009-07-06 18:53:10.459670100 +0200
@@ -15536,7 +15536,7 @@
[(set_attr "type" "call")])
(define_insn "*sibcall_1"
- [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a"))
+ [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,!c,!d,a"))
(match_operand 1 "" ""))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
@@ -22183,7 +22183,7 @@
(define_insn "*sibcall_value_1"
[(set (match_operand 0 "" "")
- (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a"))
+ (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,!c,!d,a"))
(match_operand:SI 2 "" "")))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug c/37866] "passing argument from incompatible pointer type" warning cannot be passed to -Werror=
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37866
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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
class A
{
public :
A (int i)
{
std::cout << "Copy constructor is not used." << std::endl;
}
};
int main ()
{
auto a1 = A (5); // Straight Construction
A a2[3] = { A (0), A (1), A (2) }; // Straight Construction
}
// -- end
So, why copy constructor needed to be public, although it's not used!?
Excuse me, If i insist on it. Because i really don't know why it's not a bug,
Specially for "auto" keyword.
There is XFC classes (XFC toolkit that wraps Gtk+) that their copy constructors
are private for some reason, and now, there is no way to use "auto" keyword to
initialize them. Instead, i must to initialize them with the old ways of
standard C++03.
--
MSHojatoleslami at Gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40655
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40655
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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 called copy-initialization and is equivalent to the form T x = a; and 12.8 [class.copy] paragraphs 14 and 15 A program is ill-formed if the copy constructor or the copy assignment operator for an object is implicitly used and the special member function is not accessible ... When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. Your code is invalid, this is not a bug in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40655
[Bug fortran/40662] New: gfortran 4.5 segfaults when specific FORMAT is invoked twice
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 = ",1PG13.6,T27,"ARLXCC = ",G13.6,T53, ."ATMPCA = ",G13.6,T79,"ATMPCC = ",G13.6,T105, ."BACKUP = ",G13.6,/, . T4,"CSGFAC = ",G13.6,T27,"CSGMAX = ",G13.6,T53, ."CSGMIN = ",G13.6,T79,"DRLXCA = ",G13.6,T105, ."DRLXCC = ",G13.6,/, . T4,"DTIMEH = ",G13.6,T27,"DTIMEI = ",G13.6,T53, ."DTIMEL = ",G13.6,T79,"DTIMEU = ",G13.6,T105, ."DTMPCA = ",G13.6,/, . T4,"DTMPCC = ",G13.6,T27,"EBALNA = ",G13.6,T53, ."EBALNC = ",G13.6,T79,"EBALSA = ",G13.6,T105, ."EBALSC = ",G13.6) END PROGRAM astap -- Summary: gfortran 4.5 segfaults when specific FORMAT is invoked twice Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40662
[Bug fortran/40662] gfortran 4.5 segfaults when specific FORMAT is invoked twice
--- 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 CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40662
[Bug fortran/40662] gfortran 4.5 segfaults when specific FORMAT is invoked twice
--- 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
[Bug fortran/40662] gfortran 4.5 segfaults when specific FORMAT is invoked twice
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40662
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40655
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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
[Bug bootstrap/40650] gcc-4.5-20090702 won't build on OS X 10.5 with GMP/MPFR in-tree
--- 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 org changed: What|Removed |Added Component|c |bootstrap Summary|gcc-4.5-20090702 won't build|gcc-4.5-20090702 won't build |on OS X 10.5|on OS X 10.5 with GMP/MPFR ||in-tree http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40650
[Bug c/40656] Can't initial the fields of unamed struct/union.
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40656
[Bug c/40656] Can't initial the fields of unamed struct/union.
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40656
[Bug c/10676] Using unnamed fields in initializers
--- 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 CC||xiaosuo at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
A dijnyertes jelszo lopo mar nalunk is..
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, levelezik. - Akar minden karakter leutest lenaplozhat, automatikus kepernyomentest keszit. - Titokban menti a beszelgeteseket, es naplozza a meglatogatott weboldalakat. - Hatekony iWiW, MyVip, MSN, GMail, Freemail (TESZTELVE!) stb. oldalak jelszavanak megszerzesere. Tovabbi informacioert kerjuk latogasson el weboldalunkra, most ajandekban reszesitjuk! Weboldalunk cime http://citomsk.ru/spy/ Tovabbi szep estet kivanunk Gabor Sandor Real Spy Monitor Department.
[Bug c++/40664] New: Parse error declaring friend class using dependent template instance
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'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.3.3/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -o main.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.3
/usr/include/c++/4.3/x86_64-linux-gnu
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.3/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.3.3/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -auxbase main -version -fstack-protector -o
main.s
GNU C++ (Ubuntu 4.3.3-5ubuntu4) version 4.3.3 (x86_64-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d9dd67dcc191271ac69fd2c05266cf9c
main.cpp:22: error: expected identifier before ; token
main.cpp:22: error: friend declaration does not name a class or function
main.cpp: In member function T Base::InnerBase::baseImpl() [with D =
Derived::InnerDerived, T = int]:
main.cpp:27: instantiated from T Derived::InnerDerived::operation() [with
T = int]
main.cpp:45: instantiated from here
main.cpp:31: error: T Derived::InnerDerived::derivedHelper() [with T =
int] is private
main.cpp:11: error: within this context
main.cpp:
template
class Base
{
protected:
template
class InnerBase
{
protected:
T baseImpl()
{
return static_cast(this)->derivedHelper();
}
};
};
template
class Derived : public Base
{
public:
class InnerDerived : public Base::template InnerBase
{
friend class Base::template InnerBase; // <--- error:
expected identifier before ; token
public:
T operation()
{
return this->baseImpl();
}
private:
T derivedHelper()
{
return T(42);
}
};
InnerDerived makeInner() const
{
return InnerDerived();
}
};
int main(int argc, char* argv[])
{
return Derived().makeInner().operation();
}
--
Summary: Parse error declaring friend class using dependent
template instance
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trevor at scurrilous dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40664
[Bug target/34764] A Flame About 64-bit Pointers
--- 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 and a small model may be the ticket. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
[Bug c++/12277] Warn on dynamic casts with known NULL results.
--- 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 still seems
reasonable to give a warning for pinskia's testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277
[Bug c++/12277] Warn on dynamic casts with known NULL results.
--- 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 created object is not derived a Derived object at all. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277
[Bug testsuite/40625] [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp"
--- 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 issue too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
[Bug c++/34331] __attribute((externally_visible))) should work on class declaration
--- 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 |Added CC||zlynx at acm dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34331
[Bug c/40602] crti.o: No such file
--- 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 fails with the same error message.
crti.o is located at /usr/lib64/crti.o
this is the output of cat LOG | grep crti.o | grep ENOENT | grep lib64 after
having issued strace -f make 2> LOG:
[pid 32046]
access("/sources/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/crti.o",
R_OK) = -1 ENOENT (No such file or directory)
[pid 32046]
access("/sources/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crti.o",
R_OK) = -1 ENOENT (No such file or directory)
[pid 32046] access("/lib/../lib64/crti.o", R_OK) = -1 ENOENT (No such file or
directory)
[pid 32046] access("/usr/lib/../lib64/crti.o", R_OK) = -1 ENOENT (No such file
or directory)
As you can see it tries to access /usr/lib64/crti.o, but inexplicably it can't
find it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40602
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- 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 Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug libstdc++/40654] atomic.cc: 'd' is used uninitialized warning
--- 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 gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-06 23:55:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40654
[Bug libstdc++/37477] std::uncaught_exception() returns wrong value after entering terminate() in some cases
--- 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 CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37477
[Bug regression/40665] New: dereferencing type-punned pointer warnings cannot be disabled
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 doesn't
work at all.
I don't want to completely disable the warnings with -Wno-strict-aliasing (this
could leave bugs unnotified), but I need a method to disable them on
case-by-case basis once I verified that the code in question is correct.
Simple example, compile with -O2 -Wall:
extern int c;
int a(void)
{
return *(short *)(void *)&c;
}
In 4.4 the warning can't be disabled at all! The (void *) cast doesn't suppress
the warning and none of three options to -Wstrict-aliasing helps. In 4.3 the
cast to (void *) suppressed the warning in -Wstrict-aliasing 1,2 modes (and
didn't suppress it in the default mode 3), in 4.4 the warning can't be
suppressed at all.
Gcc developers tried to made these warnings more "intelligent" with less false
positives, but unfortunatelly they completely broke the method to disable them
in the specific case. For me, false positives are not a major problem --- when
I get a false positive, I just read the code, check it and if I conclude that
it's OK, I disable the warning with (void *).
But if there's no way to disable false positives, it makes the warnings
completely useless.
--
Summary: dereferencing type-punned pointer warnings cannot be
disabled
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- 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=18145&action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces "type-punned" warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- 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=18146&action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces "type-punned" warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug debug/40666] New: [4.4.1 Regression] Ada rts build failure
../../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 DETECTED==+ | 4.4.1 20090705 (prerelease) [gcc-4_4-branch revision 149265] (hppa2.0w-hp-hpux 11.11) GCC error:| | in dbxout_symbol, at dbxout.c:2766 | | Error detected around /mnt/gnu/gcc/gcc/gcc/ada/ali.adb:679 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /mnt/gnu/gcc/gcc/gcc/ada/ali.adb /mnt/gnu/gcc/gcc/gcc/ada/ali.ads /mnt/gnu/gcc/gcc/gcc/ada/casing.ads /mnt/gnu/gcc/gcc/gcc/ada/types.ads /mnt/gnu/gcc/gcc/gcc/ada/gnatvsn.ads /mnt/gnu/gcc/gcc/gcc/ada/namet.ads /mnt/gnu/gcc/gcc/gcc/ada/alloc.ads /mnt/gnu/gcc/gcc/gcc/ada/table.ads /mnt/gnu/gcc/gcc/gcc/ada/hostparm.ads /mnt/gnu/gcc/gcc/gcc/ada/rident.ads /mnt/gnu/gcc/gcc/gcc/ada/butil.ads /mnt/gnu/gcc/gcc/gcc/ada/debug.ads /mnt/gnu/gcc/gcc/gcc/ada/fname.ads /mnt/gnu/gcc/gcc/gcc/ada/opt.ads /mnt/gnu/gcc/gcc/gcc/ada/osint.ads /mnt/gnu/gcc/gcc/gcc/ada/output.ads /mnt/gnu/gcc/gcc/gcc/ada/table.adb /mnt/gnu/gcc/gcc/gcc/ada/tree_io.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424 make[3]: *** [ali.o] Error 1 make[3]: Leaving directory `/mnt/gnu/gcc/objdir/gcc/ada/tools' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/mnt/gnu/gcc/objdir/gnattools' Breakpoint 1, dbxout_symbol (decl=0x7acbe5f0, local=2060183024) at ../../gcc/gcc/dbxout.c:2766 2766 gcc_unreachable (); (gdb) p debug_tree (decl) unit size align 8 symtab 324 alias set -1 canonical type 7b028340 precision 8 min max values value chain value chain value chain value RM size > unsigned QI file /mnt/gnu/gcc/gcc/gcc/ada/ali.adb line 230 col 10 size unit size align 8 context arg-type unit size align 32 symtab 3 alias set -1 canonical type 7af3a2d8 precision 32 min max pointer_to_this > value-expr addressable used unsigned ignored QI file /mnt/gnu/gcc/gcc/gcc/ada/ali.adb line 230 col 10 size unit size align 64 context (mem/c/i:QI (plus:SI (reg/f:SI 3 %r3) (const_int 16 [0x10])) [0 ref+0 S1 A64]) chain > chain > $2 = void (gdb) bt #0 dbxout_symbol (decl=0x7acbe5f0, local=2060183024) at ../../gcc/gcc/dbxout.c:2766 #1 0x0037476c in dbxout_syms (syms=0x7acbe5f0) at ../../gcc/gcc/dbxout.c:3275 #2 0x003748d8 in dbxout_block (block=0x7ac9d850, depth=0, args=0x0) at ../../gcc/gcc/dbxout.c:3605 #3 0x003749bc in dbxout_block (block=0x7ac9d818, depth=1, args=0x7aca9910) at ../../gcc/gcc/dbxout.c:3632 #4 0x00374a78 in dbxout_function_decl (decl=0x7acb4680) at ../../gcc/gcc/dbxout.c:1332 #5 0x0055f56c in rest_of_handle_final () at ../../gcc/gcc/final.c:4200 #6 0x0042ea5c in execute_one_pass (pass=0x40038f4c) at ../../gcc/gcc/passes.c:1277 #7 0x0042ed08 in execute_pass_list (pass=0x40038f4c) at ../../gcc/gcc/passes.c:1326 #8 0x0042ed1c in execute_pass_list (pass=0x40031a04) at ../../gcc/gcc/passes.c:1327 #9 0x0042ed1c in execute_pass_list (pass=0x400319d0) at ../../gcc/gcc/passes.c:1327 #10 0x0063b268 in tree_rest_of_compilation (fndecl=0x7acb4680) at ../../gcc/gcc/tree-optimize.c:420 #11 0x004a44e4 in cgraph_expand_function (node=0x7acc0380) at ../../gcc/gcc/cgraphunit.c:1047 #12 0x004a4768 in cgraph_output_in_order () at ../../gcc/gcc/cgraphunit.c:1195 ---Type to continue, or q to quit--- #13 0x004a5f28 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1306 #14 0x0004a13c in gnat_write_global_declarations () at ../../gcc/gcc/ada/gcc-interface/utils.c:4831 #15 0x0044bd04 in toplev_main (argc=1073748592, argv=0x404e4cb0) at ../../gcc/gcc/toplev.c:981 #16 0x0033b1f4 in main (argc=2060183024, argv=0x7acbe5f0) at ../../gcc/gcc/main.c:35 case PARM_DECL: /* Parm decls go in their own separate chains and are output by dbxout_reg_parms and dbxout_parms. */ gcc_unreachable (); # ./xgcc -B./ -v Reading specs from ./specs Target: hppa2.0w-hp
[Bug regression/40667] New: Performance regression: stack frames are generated even with -fomit-frame-pointer
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)
{
f(x);
return 0;
}
Generated code:
.text
.p2align 4,,15
.globl g
.type g, @function
g:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movl8(%ebp), %eax
movl12(%ebp), %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
callf
xorl%eax, %eax
leave
ret
.size g, .-g
Gcc 4.3 didn't generate stack frame in this case. On i386, spurious stack frame
is especially bad because there are few registers and one register is lost for
the stack frame. One my program doing heavy 64-bit math shows almost 1% code
size increase because of these unneeded frames.
--
Summary: Performance regression: stack frames are generated even
with -fomit-frame-pointer
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
Re: [Bug regression/40665] 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" 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
(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 doesn't
work at all.
I don't want to completely disable the warnings with -Wno-strict-
aliasing (this
could leave bugs unnotified), but I need a method to disable them on
case-by-case basis once I verified that the code in question is
correct.
Simple example, compile with -O2 -Wall:
extern int c;
int a(void)
{
return *(short *)(void *)&c;
}
This is a very bad example of a false positive as you are acessing an
int as a short; that is undefined. I will look at your code later on,
my laptop for home is currently broken.
In 4.4 the warning can't be disabled at all! The (void *) cast
doesn't suppress
the warning and none of three options to -Wstrict-aliasing helps. In
4.3 the
cast to (void *) suppressed the warning in -Wstrict-aliasing 1,2
modes (and
didn't suppress it in the default mode 3), in 4.4 the warning can't be
suppressed at all.
Gcc developers tried to made these warnings more "intelligent" with
less false
positives, but unfortunatelly they completely broke the method to
disable them
in the specific case. For me, false positives are not a major
problem --- when
I get a false positive, I just read the code, check it and if I
conclude that
it's OK, I disable the warning with (void *).
But if there's no way to disable false positives, it makes the
warnings
completely useless.
--
Summary: dereferencing type-punned pointer warnings cannot
be
disabled
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- 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" 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
> (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 doesn't
> work at all.
>
> I don't want to completely disable the warnings with -Wno-strict-
> aliasing (this
> could leave bugs unnotified), but I need a method to disable them on
> case-by-case basis once I verified that the code in question is
> correct.
>
> Simple example, compile with -O2 -Wall:
>
> extern int c;
> int a(void)
> {
>return *(short *)(void *)&c;
> }
This is a very bad example of a false positive as you are acessing an
int as a short; that is undefined. I will look at your code later on,
my laptop for home is currently broken.
>
> In 4.4 the warning can't be disabled at all! The (void *) cast
> doesn't suppress
> the warning and none of three options to -Wstrict-aliasing helps. In
> 4.3 the
> cast to (void *) suppressed the warning in -Wstrict-aliasing 1,2
> modes (and
> didn't suppress it in the default mode 3), in 4.4 the warning can't be
> suppressed at all.
>
> Gcc developers tried to made these warnings more "intelligent" with
> less false
> positives, but unfortunatelly they completely broke the method to
> disable them
> in the specific case. For me, false positives are not a major
> problem --- when
> I get a false positive, I just read the code, check it and if I
> conclude that
> it's OK, I disable the warning with (void *).
>
> But if there's no way to disable false positives, it makes the
> warnings
> completely useless.
>
>
> --
> Summary: dereferencing type-punned pointer warnings cannot
> be
>disabled
> Product: gcc
> Version: 4.4.1
>Status: UNCONFIRMED
> Severity: major
> Priority: P3
> Component: regression
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
> GCC build triplet: i686-pc-linux-gnu
> GCC host triplet: i686-pc-linux-gnu
> GCC target triplet: i686-pc-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
Re: [Bug regression/40665] 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" 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) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces "type- punned" warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- 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" 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) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) > a bug in -Wstrict-aliasing=3 > > This is an example of a flaw in -Wstrict-aliasing=3 (this mode is > very bad, > produces many false positives on my project and I'm wondering why is > it > default?) > > Gcc man page says that -Wstrict-aliasing=3 produces less false > positives than > -Wstrict-aliasing=2. This is counterexample, it produces "type- > punned" warning > in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. > I added > (void *) casts everywhere, but they don't quash the warning. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
Re: [Bug regression/40665] 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 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" 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) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces "type- punned" warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- 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 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" 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) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) > a bug in -Wstrict-aliasing=3 > > This is an example of a flaw in -Wstrict-aliasing=3 (this mode is > very bad, > produces many false positives on my project and I'm wondering why is > it > default?) > > Gcc man page says that -Wstrict-aliasing=3 produces less false > positives than > -Wstrict-aliasing=2. This is counterexample, it produces "type- > punned" warning > in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. > I added > (void *) casts everywhere, but they don't quash the warning. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- 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 question is whether it is valid or not. As both NAG f95 and ifort reject > it > (g95 accepts it), it might be invalid. Although I can find nowhere in the standards that says that it is valid, I believe that by the normal rules of host association of procedures, it must be. gfortran accepts it if 'test' and 'sub' are interchanged. I have put it on my todo list. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-07 05:01:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug target/40668] New: 64-bit sparc miscompiles memcpy of argument inside switch
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.
--
"/opt/cfarm/release/4.4.0/bin/gcc -v" prints:
Using built-in specs.
Target: sparc64-unknown-linux-gnu
Configured with: ../gcc-4.4.0/configure
--enable-languages=c,c++,fortran,ada --prefix=/opt/cfarm/release/4.4.0
--enable-__cxa_atexit --enable-threads=posix --disable-nls
--with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-cpu=v8
Thread model: posix
gcc version 4.4.0 (GCC)
--
#include
#include
#include
/* Stores 32-bit unsigned integer X at P,
which need not be aligned. */
static void
put_uint32 (uint32_t x, void *p)
{
memcpy (p, &x, sizeof x);
}
void
store_12345678 (int type, void *number)
{
switch (type)
{
case 1:
printf ("got here\n");
put_uint32 (0x12345678, number);
break;
case 7:
put_uint32 (0, number);
break;
case 8:
put_uint32 (0, number);
break;
case 9:
put_uint32 (0, number);
break;
}
}
int
main (void)
{
uint32_t x;
store_12345678 (1, &x);
printf ("%x\n", (unsigned int) x);
return 0;
}
--
Summary: 64-bit sparc miscompiles memcpy of argument inside
switch
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: blp at cs dot stanford dot edu
GCC build triplet: sparc64-unknown-linux-gnu
GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- 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=18147&action=view) preprocessed test input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- 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=18148&action=view) test program (before preprocessing) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug target/40657] allocate local variables with fewer instructions
--- Comment #5 from carrot at google dot com 2009-07-07 06:44 --- Could we do the optimization in function thumb1_expand_prologue? If we find this opportunity in function thumb1_expand_prologue, we can remove the sp manipulations from prologue and epilogue. We also should add extra registers to push/pop operands. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
