[Bug fortran/40646] [F03] array-valued procedure pointer components

2009-07-06 Thread janus at gcc dot gnu dot org


--- 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

2009-07-06 Thread carrot at google dot com
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

2009-07-06 Thread carrot at google dot com


--- 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.

2009-07-06 Thread dominiq at lps dot ens dot fr


--- 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

2009-07-06 Thread steven at gcc dot gnu dot org


--- 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"

2009-07-06 Thread gcc at axel-naumann dot de
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"

2009-07-06 Thread mikpe at it dot uu dot se


--- 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

2009-07-06 Thread ramana at gcc dot gnu dot org


--- 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"

2009-07-06 Thread paolo dot carlini at oracle dot com


--- 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.

2009-07-06 Thread rguenth at gcc dot gnu dot org


--- 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!

2009-07-06 Thread rguenth at gcc dot gnu dot org


--- 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

2009-07-06 Thread ktietz at gcc dot gnu dot org


--- 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

2009-07-06 Thread florian at openwrt dot org


--- 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

2009-07-06 Thread florian at openwrt dot org


--- 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

2009-07-06 Thread steven at gcc dot gnu dot org


--- 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"

2009-07-06 Thread gcc at axel-naumann dot de


--- 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"

2009-07-06 Thread manu at gcc dot gnu dot org


--- 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

2009-07-06 Thread reichelt at gcc dot gnu dot org


-- 

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()

2009-07-06 Thread reichelt at gcc dot gnu dot org


-- 

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

2009-07-06 Thread reichelt at gcc dot gnu dot org


--- 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

2009-07-06 Thread ktietz at gcc dot gnu dot org


--- 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

2009-07-06 Thread ktietz at gcc dot gnu dot org


-- 

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

2009-07-06 Thread steven at gcc dot gnu 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 |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

2009-07-06 Thread ebotcazou at gcc dot gnu 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 @@
>[(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

2009-07-06 Thread ktietz at gcc dot gnu dot org


--- 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

2009-07-06 Thread manu at gcc dot gnu dot org


--- 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)

2009-07-06 Thread kkojima at gcc dot gnu dot org


--- 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.

2009-07-06 Thread Jean Christophe Beyler
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

2009-07-06 Thread mark at gcc dot gnu dot org
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

2009-07-06 Thread ebotcazou at gcc dot gnu dot org


--- 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

2009-07-06 Thread burnus at gcc dot gnu dot org
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

2009-07-06 Thread ktietz at gcc dot gnu dot org


--- 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

2009-07-06 Thread ktietz at gcc dot gnu dot org


--- 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

2009-07-06 Thread ktietz at gcc dot gnu dot org


--- 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

2009-07-06 Thread ebotcazou at gcc dot gnu dot org


--- 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=

2009-07-06 Thread manu at gcc dot gnu dot org


--- 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"

2009-07-06 Thread ahelm at gmx dot net
=== 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"

2009-07-06 Thread pinskia at gcc dot gnu dot org


--- 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

2009-07-06 Thread ktietz at gcc dot gnu dot org


--- 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=

2009-07-06 Thread flameeyes at gentoo dot org


--- 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!

2009-07-06 Thread MSHojatoleslami at Gmail dot com


--- 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!

2009-07-06 Thread jwakely dot gcc at gmail dot com


--- 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!

2009-07-06 Thread jwakely dot gcc at gmail dot com


--- 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

2009-07-06 Thread michael dot a dot richmond at nasa dot gov
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

2009-07-06 Thread dominiq at lps dot ens dot fr


--- 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

2009-07-06 Thread jvdelisle at gcc dot gnu dot org


--- 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

2009-07-06 Thread kargl at gcc dot gnu dot org


--- 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!

2009-07-06 Thread paolo dot carlini at oracle dot com


--- 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!

2009-07-06 Thread MSHojatoleslami at Gmail dot com


--- 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

2009-07-06 Thread pinskia at gcc dot gnu dot org


--- 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.

2009-07-06 Thread pinskia at gcc dot gnu dot org


--- 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.

2009-07-06 Thread pinskia at gcc dot gnu dot org


--- 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

2009-07-06 Thread pinskia at gcc dot gnu dot org


--- 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..

2009-07-06 Thread Kem Mester
   
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

2009-07-06 Thread trevor at scurrilous dot com
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

2009-07-06 Thread jvdelisle at gcc dot gnu dot org


--- 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.

2009-07-06 Thread jason at gcc dot gnu dot org


--- 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.

2009-07-06 Thread bangerth at gmail dot com


--- 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"

2009-07-06 Thread pinskia at gcc dot gnu dot org


--- 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

2009-07-06 Thread zlynx at acm dot org


--- 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

2009-07-06 Thread booleandomain at gmail dot com


--- 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

2009-07-06 Thread bkoz at gcc dot gnu dot org


--- 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

2009-07-06 Thread bkoz at gcc dot gnu dot org


--- 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

2009-07-06 Thread paolo dot carlini at oracle dot com


--- 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

2009-07-06 Thread mikulas at artax dot karlin dot mff dot cuni dot cz
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

2009-07-06 Thread mikulas at artax dot karlin dot mff dot cuni dot cz


--- 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

2009-07-06 Thread mikulas at artax dot karlin dot mff dot cuni dot cz


--- 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

2009-07-06 Thread danglin at gcc dot gnu dot org
../../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

2009-07-06 Thread mikulas at artax dot karlin dot mff dot cuni dot cz
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

2009-07-06 Thread Andrew Pinski



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

2009-07-06 Thread pinskia at gmail dot com


--- 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

2009-07-06 Thread Andrew Pinski



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

2009-07-06 Thread pinskia at gmail dot com


--- 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

2009-07-06 Thread Andrew Pinski
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

2009-07-06 Thread pinskia at gmail dot com


--- 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

2009-07-06 Thread pault at gcc dot gnu dot org


--- 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

2009-07-06 Thread blp at cs dot stanford dot edu
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

2009-07-06 Thread blp at cs dot stanford dot edu


--- 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

2009-07-06 Thread blp at cs dot stanford dot edu


--- 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

2009-07-06 Thread carrot at google dot com


--- 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