[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions

2007-11-15 Thread reichelt at gcc dot gnu dot org


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103



[Bug c++/34102] New: [4.3 regression] ICE with invalid inheritance of variadic templates

2007-11-15 Thread reichelt at gcc dot gnu dot org
The following invalid testcase triggers an ICE on mainline:


struct A {};

templatetypename struct B : virtual A {};

templatetypename...T struct C : BT {};


bug.cc:5: error: parameter packs not expanded with `...':
bug.cc:5: note: 'T'
bug.cc: In instantiation of 'Bexpression error ':
bug.cc:5:   instantiated from here
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

The bug appeared between 2007-11-03 and 2007-11-06.


-- 
   Summary: [4.3 regression] ICE with invalid inheritance of
variadic templates
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102



[Bug c++/34102] [4.3 regression] ICE with invalid inheritance of variadic templates

2007-11-15 Thread reichelt at gcc dot gnu dot org


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102



[Bug fortran/34092] Should warn about unused private variables

2007-11-15 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-15 08:31 ---
Duplicate of PR 31124 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34092



[Bug c++/34100] [4.3 regression] ICE with vector attribute

2007-11-15 Thread reichelt at gcc dot gnu dot org


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34100



[Bug c++/34099] optimizer problem

2007-11-15 Thread rwgk at yahoo dot com


--- Comment #1 from rwgk at yahoo dot com  2007-11-15 06:56 ---
Created an attachment (id=14554)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14554action=view)
reproducer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug c++/34101] New: [4.3 regression] ICE with argument deduction of variadic template function

2007-11-15 Thread reichelt at gcc dot gnu dot org
The following valid testcase triggers an ICE on mainline:


templatetypename struct A {};

templatetemplatetypename class... struct B {};

templatetemplatetypename class T void foo(const BT);

void bar()
{
  foo(BA());
}


bug.cc: In function 'void bar()':
bug.cc:9: internal compiler error: in arg_assoc_type, at cp/name-lookup.c:4626
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3 regression] ICE with argument deduction of variadic
template function
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34101



[Bug c++/34101] [4.3 regression] ICE with argument deduction of variadic template function

2007-11-15 Thread reichelt at gcc dot gnu dot org


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34101



[Bug libstdc++/34105] New: [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread rguenth at gcc dot gnu dot org
For

#include vector
#include string

int main()
{
  std::vectorstd::string x;
  std::string s(hello);
  return std::find(x.begin(), x.end(), s) - x.begin();
}

we now get interesting linker errors with trunk:

 g++-4.3 -o t t.C
/tmp/cc3Vq2t8.o: In function `main':
t.C:(.text+0x65): undefined reference to
`__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar *, std::vectorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
std::allocatorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar
std::find__gnu_cxx::__normal_iteratorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar *,
std::vectorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar , std::allocatorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar, std::basic_stringchar,
std::char_traitschar, std::allocatorchar 
(__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar *, std::vectorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
std::allocatorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar,
__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar *, std::vectorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
std::allocatorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar, std::basic_stringchar, std::char_traitschar,
std::allocatorchar  const)'
collect2: ld returned 1 exit status

where it is not exactly obvious that just the #include algorithm is missing
here.  With 4.2 and 4.2 at least the program linked fine (I guess algorithm
was pulled in anyway).

Can we improve this situation by not making algorithm half-way available so
we can raise a meaningful error instead?


-- 
   Summary: [4.3 Regression] Confusing error message with missing
#include algorithm
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug c++/34104] New: auto_ptr error catching

2007-11-15 Thread dckorah+gcc at gmail dot com
#include memory
int main(int argc, char* argv[])
{
int* intptr;
std::auto_ptrint i;

i = std::auto_ptrint (intptr);

return 0;
}

- code above compiles but fails run 

~/tests$ g++ -Wall auto_ptr.cpp
~/tests$ ./a.out
*** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0x080485a9 ***
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7d2792b]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7eecd81]
./a.out[0x804857d]
./a.out[0x80484b3]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7cd0050]
./a.out[0x80483d1]
=== Memory map: 
08048000-08049000 r-xp  08:03 6389816/home/dkorah/tests/a.out
08049000-0804a000 rw-p  08:03 6389816/home/dkorah/tests/a.out
0804a000-0806b000 rw-p 0804a000 00:00 0  [heap]
b7cb9000-b7cba000 rw-p b7cb9000 00:00 0
b7cba000-b7dfe000 r-xp  08:01 32593 
/lib/tls/i686/cmov/libc-2.6.1.so
b7dfe000-b7dff000 r--p 00143000 08:01 32593 
/lib/tls/i686/cmov/libc-2.6.1.so
b7dff000-b7e01000 rw-p 00144000 08:01 32593 
/lib/tls/i686/cmov/libc-2.6.1.so
b7e01000-b7e04000 rw-p b7e01000 00:00 0
b7e04000-b7e0e000 r-xp  08:01 2394403/lib/libgcc_s.so.1
b7e0e000-b7e0f000 rw-p a000 08:01 2394403/lib/libgcc_s.so.1
b7e0f000-b7e1 rw-p b7e0f000 00:00 0
b7e1-b7e33000 r-xp  08:01 32597 
/lib/tls/i686/cmov/libm-2.6.1.so
b7e33000-b7e35000 rw-p 00023000 08:01 32597 
/lib/tls/i686/cmov/libm-2.6.1.so
b7e35000-b7f1d000 r-xp  08:01 1337854/usr/lib/libstdc++.so.6.0.9
b7f1d000-b7f2 r--p 000e8000 08:01 1337854/usr/lib/libstdc++.so.6.0.9
b7f2-b7f22000 rw-p 000eb000 08:01 1337854/usr/lib/libstdc++.so.6.0.9
b7f22000-b7f28000 rw-p b7f22000 00:00 0
b7f3c000-b7f3e000 rw-p b7f3c000 00:00 0
b7f3e000-b7f58000 r-xp  08:01 2394896/lib/ld-2.6.1.so
b7f58000-b7f5a000 rw-p 00019000 08:01 2394896/lib/ld-2.6.1.so
bf9f2000-bfa07000 rw-p bf9f2000 00:00 0  [stack]
e000-f000 r-xp  00:00 0  [vdso]
Aborted (core dumped)


-- 
   Summary: auto_ptr error catching
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dckorah+gcc at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34104



[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed

2007-11-15 Thread pault at gcc dot gnu dot org


--- Comment #3 from pault at gcc dot gnu dot org  2007-11-15 09:46 ---
The patch below fixes the reported bug.  I am going to check to see what needs
to be done to extend this to generic interfaces and operators.

Paul

Index: gcc/fortran/module.c
===
*** gcc/fortran/module.c(révision 130174)
--- gcc/fortran/module.c(copie de travail)
*** find_symtree_for_symbol (gfc_symtree *st
*** 3492,3497 
--- 3492,3522 
  }


+ /* A recursive function to look for a spefici symbol by name and by
+module.  Whilst several symtrees might point to one symbol, its
+is sufficient for the purposes here than one exist.  */
+ static gfc_symtree *
+ find_symbol (gfc_symtree *st, const char *name, const char *module)
+ {
+   int c;
+   gfc_symtree *retval;
+
+   if (st == NULL || st-n.sym == NULL)
+ return NULL;
+
+   c = strcmp (name, st-n.sym-name);
+   if (c == 0  strcmp (module, st-n.sym-module) == 0)
+ return st;
+
+   retval = find_symbol (st-left, name, module);
+
+   if (retval == NULL)
+ retval = find_symbol (st-right, name, module);
+
+   return retval;
+ }
+
+
  /* Read a module file.  */

  static void
*** read_module (void)
*** 3616,3621 
--- 3641,3655 
  continue;
}

+ /* If a symbol of the same name and module exists already,
+this symbol, which is not in an ONLY clause, must not be
+added to the namespace(11.3.2).  Note that find_symbol
+only returns the first occurrence that it finds.  */
+ if (p == name  strcmp (name, module_name) != 0
+find_symbol (gfc_current_ns-sym_root, name,
+   module_name))
+   continue;
+
  st = gfc_find_symtree (gfc_current_ns-sym_root, p);

  if (st != NULL)
*** read_module (void)
*** 3627,3632 
--- 3661,3674 
}
  else
{
+ st = gfc_find_symtree (gfc_current_ns-sym_root, name);
+
+ /* Make symtree inaccessible by renaming if the symbol has
+been added by a USE statement without an ONLY(11.3.2).  */
+ if (st  st-name == st-n.sym-name
+ strcmp (st-n.sym-module, module_name) == 0)
+   st-name = gfc_get_string (hidden.%s, name);
+
  /* Create a symtree node in the current namespace for this
 symbol.  */
  st = check_unique_name (p)
Index: gcc/testsuite/gfortran.dg/use_only_1.f90
===
*** gcc/testsuite/gfortran.dg/use_only_1.f90(révision 0)
--- gcc/testsuite/gfortran.dg/use_only_1.f90(révision 0)
***
*** 0 
--- 1,31 
+ ! { dg-do run }
+ ! { dg-options -O1 }
+ ! Checks the fix for PR33541, in which a requirement
+ ! of F95 11.3.2 was not being met: The local names
+ ! 'x' and 'y' coming from the USE statements without
+ ! an ONLY clause should not survive in the presence
+ ! of the locally renamed versions.
+ !
+ ! Reported by Reported by John Harper in
+ ! http://gcc.gnu.org/ml/fortran/2007-09/msg00397.html
+ !
+ MODULE xmod
+   integer(4) :: x = -666
+ END MODULE xmod
+
+ MODULE ymod
+   integer(4) :: y = -666
+ END MODULE ymod
+
+ PROGRAM test2uses
+   USE xmod
+   USE xmod, ONLY: xrenamed = x
+   USE ymod, ONLY: yrenamed = y
+   USE ymod
+   implicit integer(2) (a-z)
+   x = 666  ! These assignments should generate implicitly typed
+   y = 666  ! local variable 'x' and 'y'.
+   if (kind(xrenamed) == kind(x)) call abort ()
+   if (kind(yrenamed) == kind(y)) call abort ()
+ END PROGRAM test2uses
+ ! { dg-final { cleanup-modules xmod ymod } }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541



[Bug libstdc++/33491] parallel v3: add some documentation

2007-11-15 Thread singler at gcc dot gnu dot org


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |singler at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-19 16:58:05 |2007-11-15 10:05:14
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33491



[Bug libstdc++/34106] New: [parallel mode] Atomic operations compatibility layer needs cleanup

2007-11-15 Thread singler at gcc dot gnu dot org
In compatibility.h, there are a lot of compiler- and architecture dependent
switches. Relying on the GCC atomic operations would make this much cleaner.


-- 
   Summary: [parallel mode] Atomic operations compatibility layer
needs cleanup
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: singler at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106



[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope

2007-11-15 Thread singler at gcc dot gnu dot org


--- Comment #8 from singler at gcc dot gnu dot org  2007-11-15 10:10 ---
Closing this bug, the compatibility.h issues are tracked in PR 34106.


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892



[Bug libstdc++/34106] [parallel mode] Atomic operations compatibility layer needs cleanup

2007-11-15 Thread singler at gcc dot gnu dot org


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |singler at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 10:11:16
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106



[Bug libstdc++/33490] parallel v3: std::accumulate assumes iterators have std::iterator_traits declared

2007-11-15 Thread singler at gcc dot gnu dot org


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33490



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-15 10:21 ---
Confirmed.  Shorter testcase:

#include complex
#include iostream

typedef std::complexdouble NumType;

void
multiply(NumType a, NumType b, unsigned ac, NumType ab)
{
  NumType s;
  for (unsigned j=0; jac; j++)
s = a * b;
  ab = s;
}

int main()
{
  NumType a(1,2), b(3,-2), c;
  multiply(a, b, 1, c);
  std::cout  c  std::endl;
  return 0;
}

Looks like another SRA problem.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c++ |tree-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.3.0
  Known to work||4.2.2
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 10:21:31
   date||
Summary|optimizer problem   |[4.3 Regression] optimizer
   ||problem
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug fortran/34107] New: seg fault when writing into character variable when code compiled with -maling-double

2007-11-15 Thread j dot m dot h dot thomas at dl dot ac dot uk
I'm using the latest (precompiled) version of gfortran (GNU Fortran (GCC) 4.3.0
20071105 (experimental) [trunk revision 129892]). The following code:

program test
 integer :: pid
 character (len=10) :: chpid

 pid=12345

 write(chpid,'(i10)')pid
 write(*,*)chpid is ,chpid

end program test

when compiled with:

gfortran -o test.gfortran90 -g -malign-double  ./test.f90

on my ubuntu box (Ubuntu 6.06.1 LTS,  Intel(R) Pentium(R) 4 CPU 2.80GHz), seg
faults as shown below:

Program received signal SIGSEGV, Segmentation fault.
0xb7f86f46 in next_char (fmt=0x8050528, literal=0)
   at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:91
91  /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c: No such
file or directory.
   in /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c


(gdb) bt
#0  0xb7f86f46 in next_char (fmt=0x8050528, literal=0)
   at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:91
#1  0xb7f86fb1 in format_lex (fmt=0x8050528)
   at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:181
#2  0xb7f87c65 in *_gfortrani_parse_format (dtp=0xbfbc1aa8)
   at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:981
#3  0xb7f91e69 in data_transfer_init (dtp=0xbfbc1aa8, read_flag=0)
   at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/transfer.c:1802
#4  0x08048616 in test () at ./test.f90:7 

If I remove the -malign-double flag, the code runs fine. 

The same code in FORTRAN77 format works fine with g77 (with the -malign-double
flag), but also crashes gfortran.


-- 
   Summary: seg fault when writing into character variable when code
compiled with -maling-double
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j dot m dot h dot thomas at dl dot ac dot uk
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107



[Bug fortran/31124] Warn of unused PRIVATE module variables/procedures

2007-11-15 Thread terry at chem dot gu dot se


--- Comment #2 from terry at chem dot gu dot se  2007-11-15 10:19 ---
*** Bug 34092 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31124



[Bug fortran/34092] Should warn about unused private variables

2007-11-15 Thread terry at chem dot gu dot se


--- Comment #2 from terry at chem dot gu dot se  2007-11-15 10:19 ---
(In reply to comment #1)
 Duplicate of PR 31124 ?
 

Yar.  I was misled the last time by the fact that PR 31129 also existed.  The
parameter case has been fixed, but not the private case.


*** This bug has been marked as a duplicate of 31124 ***


-- 

terry at chem dot gu dot se changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34092



[Bug fortran/31124] Warn of unused PRIVATE module variables/procedures

2007-11-15 Thread terry at chem dot gu dot se


--- Comment #3 from terry at chem dot gu dot se  2007-11-15 10:27 ---
(In reply to comment #2)
 *** Bug 34092 has been marked as a duplicate of this bug. ***
 

So, to summarise:  Unused parameters have been fixed in general, but unused
private module entities remain undetected (as of 4.3.0 20071109).  (There must
surely be a piece of code excluding module variables from unused warnings? 
That needs to be taught about the private attribute.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31124



[Bug libstdc++/33893] [parallel mode] Algorithms rely on omp_set_dynamic(false)

2007-11-15 Thread singler at gcc dot gnu dot org


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |singler at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 10:11:43
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33893



[Bug c++/34100] [4.3 regression] ICE with vector attribute

2007-11-15 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-15 11:17 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 11:17:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34100



[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed

2007-11-15 Thread pault at gcc dot gnu dot org


--- Comment #4 from pault at gcc dot gnu dot org  2007-11-15 11:16 ---
(In reply to comment #3)

Bother, the patch causes some regressions (interface_[3-5].f90)...

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541



[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double

2007-11-15 Thread pault at gcc dot gnu dot org


--- Comment #3 from pault at gcc dot gnu dot org  2007-11-15 11:58 ---
(In reply to comment #2)
 -malign-double changes the ABI.  You need to rebuild libgfortran with that
 option.

Ah! Thanks, Richard.  For that, I'll take a look at achar_4.f90 for you:)

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread pcarlini at suse dot de


--- Comment #1 from pcarlini at suse dot de  2007-11-15 11:59 ---
Note that the issue is unrelated to the header optimization work: is caused by
algorithmfwd.h, added in the occasion of the parallel STL work. I'm going to
look a bit into it, anyway, if a simple solution I have in mind will not work,
will forward to Benjamin.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 11:59:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-15 Thread eres at il dot ibm dot com


--- Comment #5 from eres at il dot ibm dot com  2007-11-15 12:04 ---
It seems that verify_flow_info complains about the following note,
which is generated in the partitioning phase:

(note 234 232 172 11 NOTE_INSN_SWITCH_TEXT_SECTIONS)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085



[Bug fortran/34108] New: ICE: Segmentation fault occurs by write(*,0) statement

2007-11-15 Thread fujimura at giga dot it dot okayama-u dot ac dot jp
I use gfortran on cygwin.

% wget
http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.3-Cygwin-i686.tar.bz2
% tar fjx gfortran-4.3-Cygwin-i686.tar.bz2 -C /


I get a segmentation fault when compiling program contains a simple write
statement.

% cat zerolabel.f95
write(*,0)

% /usr/local/gfortran/bin/gfortran.exe -v zerolabel.f95
Driving: /usr/local/gfortran/bin/gfortran -v zerolabel.f95 -lgfortranbegin
-lgfortran
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc43/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran --disable-bootstrap --enable-threads=posix
--enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls
--disable-libmudflap --disable-shared --disable-win32-registry
--with-system-zlib --enable-checking=release --enable-werror
--without-included-gettext --without-x --enable-libgomp : (reconfigured)
../gcc43/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran
--disable-bootstrap --enable-threads=posix --enable-sjlj-exceptions
--enable-version-specific-runtime-libs --enable-nls --disable-libmudflap
--disable-shared --disable-win32-registry --with-system-zlib
--enable-checking=release --enable-werror --without-included-gettext
--without-x --enable-libgomp
Thread model: posix
gcc version 4.3.0 20071005 (experimental) [trunk revision 127783] (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic'
 /usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.3.0/f951.exe zerolabel.f95
-quiet -dumpbase zerolabel.f95 -mtune=generic -auxbase zerolabel -version
-fintrinsic-modules-path
/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.3.0/finclude -o /tmp/ccbbRPye.s
GNU F95 (GCC) version 4.3.0 20071005 (experimental) [trunk revision 127783]
(i686-pc-cygwin)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125), GMP version 4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
zerolabel.f95:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: ICE: Segmentation fault occurs by write(*,0) statement
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fujimura at giga dot it dot okayama-u dot ac dot jp
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34108



[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double

2007-11-15 Thread pault at gcc dot gnu dot org


--- Comment #1 from pault at gcc dot gnu dot org  2007-11-15 10:54 ---
Jens,

I cannot reproduce this bug, even with the same flags that you are using, under
Cygwin_NT and last night's build.  I will check on a Linux system tonight.

I have downrated the severity because critical refers to bugs that prevent
the gcc build.  I assure you that the gfortran maintainers will take the report
just as seriously.

Thanks for the report

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
   Severity|critical|normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107



[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-15 Thread steven at gcc dot gnu dot org


--- Comment #6 from steven at gcc dot gnu dot org  2007-11-15 12:21 ---
I can't reproduce this on x86*.
Again, please attach the profile information and state the exact compiler
revision you used to generate this profile information.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085



[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-15 Thread eres at il dot ibm dot com


--- Comment #7 from eres at il dot ibm dot com  2007-11-15 12:29 ---
(In reply to comment #6)
 I can't reproduce this on x86*.
 Again, please attach the profile information and state the exact compiler
 revision you used to generate this profile information.


Sorry - I am working on r129702.
What do you mean by profile information (a dump file)?

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085



[Bug fortran/33917] Rejects valid PROCEDURE declarations

2007-11-15 Thread patchapp at dberlin dot org


--- Comment #9 from patchapp at dberlin dot org  2007-11-15 12:35 ---
Subject: Bug number PR33917

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00842.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread pcarlini at suse dot de


--- Comment #5 from pcarlini at suse dot de  2007-11-15 13:10 ---
I meant bits/stl_algobase.h, of course.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-15 11:26 ---
-malign-double changes the ABI.  You need to rebuild libgfortran with that
option.


-- 

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



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread pcarlini at suse dot de


--- Comment #3 from pcarlini at suse dot de  2007-11-15 13:06 ---
Something like the attached (lightly tested) fixed the problem for normal mode,
the error becomes:

34105.cc: In function ‘int main()’:
34105.cc:8: error: ‘find’ is not a member of ‘std’

however, it doesn't for parallel mode. I think it's better if Benjamin looks
into those headers...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread pcarlini at suse dot de


--- Comment #4 from pcarlini at suse dot de  2007-11-15 13:09 ---
By the way, while we are talking about those QoI issues, I think it's in any
case better not including something like algorithmfwd.h in algobase.h: it's
relatively big and we are doing our best to keep algobase.h, the core
algorithmic facilities optimized for internal use, as minimal as possible.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug java/21206] gcj seems not to pass the option to ld correctly

2007-11-15 Thread tom_francen at midtechcorp dot com


--- Comment #18 from tom_francen at midtechcorp dot com  2007-11-15 13:46 
---
Subject: Re:  gcj seems not to pass the option to ld correctly


thank you wilson ... i just tried suggestion #6 ... and it WORKED!!  thank you
very much!!

tjf
---
Thomas James Francen
Midwest Technologies Corporation
http://www.midtechcorp.com - website

+1.303.898.6300 - Cell / Voicemail
+1.610.887.5155 - Fax

--- [EMAIL PROTECTED] wrote:

From: wilson at tuliptree dot org [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug java/21206] gcj seems not to pass the option to ld correctly
Date: 14 Nov 2007 23:46:07 -



--- Comment #17 from wilson at tuliptree dot org  2007-11-14 23:46 ---
Subject: Re:  gcj seems not to pass the option to ld
correctly

On Wed, 2007-11-14 at 23:16 +, tom_francen at midtechcorp dot com
wrote:
 i'm receiving a very similar error under solaris 2.10, binutils and core utils
 (latest versions), gnu make, etc.  gcc 4.1.2 built fine ... gcc 4.2.1 and 
 4.2.2
 fail with the same error below ... 

You can try the workaround I gave in comment #6.

Jim


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206



[Bug c++/34104] auto_ptr error catching

2007-11-15 Thread pcarlini at suse dot de


--- Comment #1 from pcarlini at suse dot de  2007-11-15 13:32 ---
intptr is not initialized: when i is destructed it calls delete on the owned
pointer, that is intptr, and anything can happen. Just initialize intptr to
zero or to a value returned by new.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34104



[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-15 Thread eres at il dot ibm dot com


--- Comment #8 from eres at il dot ibm dot com  2007-11-15 14:17 ---
When disabling rest_of_handle_reorder_blocks (bbro) the ICE disappears. (it
seems that it is not caused due to the partitioning - bbpart)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread pcarlini at suse dot de


--- Comment #2 from pcarlini at suse dot de  2007-11-15 13:04 ---
Created an attachment (id=14555)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14555action=view)
Draft patch for normal mode


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-15 Thread steven at gcc dot gnu dot org


--- Comment #9 from steven at gcc dot gnu dot org  2007-11-15 14:49 ---
I mean the files you generate with -fprofile-generate.

I expect this to be fully blamable on the partitioning code, and I would like
to work in fixing this.  But you have to attach the profile information you
have generated, or no-one can debug this unless he/she has access to POWER.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085



[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-15 Thread eres at il dot ibm dot com


--- Comment #11 from eres at il dot ibm dot com  2007-11-15 15:05 ---
Created an attachment (id=14556)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14556action=view)
File generated by -fprofile-generate


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2007-11-15 14:56 ---
Uhm, this goes wrong in CCP.  (w/o SRA the failure doesn't trigger though)

Before CCP we have:

void multiply(NumType, NumType, unsigned int, NumType) (a, b, ac, ab)
{ 
  double s$_M_value$real;
  double s$_M_value$imag;
  double b$_M_value$real;
  double b$_M_value$imag;
  double a$_M_value$imag;
  double a$_M_value$real;
  complex double __t;
  complex double D.26933;
  complex double D.26932;
  double D.26931;
  double D.26929;
  unsigned int j;

bb 2:
  # VUSE SFT.90_33(D)
  a$_M_value$real_21 = REALPART_EXPR a._M_value;
  # VUSE SFT.91_34(D)
  a$_M_value$imag_22 = IMAGPART_EXPR a._M_value;
  # VUSE SFT.93_35(D)
  b$_M_value$imag_23 = IMAGPART_EXPR b._M_value;
  # VUSE SFT.92_36(D)
  b$_M_value$real_24 = REALPART_EXPR b._M_value;
  s$_M_value$real_25 = 0.0;
  s$_M_value$imag_26 = 0.0;
  goto bb 4;

bb 3:
  D.26929_10 = IMAGPART_EXPR __t_6(D);
  __t_11 = COMPLEX_EXPR b$_M_value$real_24, D.26929_10;
  D.26931_13 = REALPART_EXPR __t_11;
  __t_14 = COMPLEX_EXPR D.26931_13, b$_M_value$imag_23;
  D.26932_15 = COMPLEX_EXPR a$_M_value$real_21, a$_M_value$imag_22;
  D.26933_16 = __t_14 * D.26932_15;
  s$_M_value$imag_17 = IMAGPART_EXPR D.26933_16;
  s$_M_value$real_18 = REALPART_EXPR D.26933_16;
  j_4 = j_1 + 1;

bb 4:
  # s$_M_value$real_20 = PHI s$_M_value$real_25(2), s$_M_value$real_18(3)
  # s$_M_value$imag_19 = PHI s$_M_value$imag_26(2), s$_M_value$imag_17(3)
  # j_1 = PHI 0(2), j_4(3)
  if (j_1  ac_3(D))
goto bb 3;
  else
goto bb 5;

bb 5:
  # SMT.98_38 = VDEF SMT.98_37(D)
  IMAGPART_EXPR ab_5(D)-_M_value = s$_M_value$imag_19;
  # SMT.98_39 = VDEF SMT.98_38
  REALPART_EXPR ab_5(D)-_M_value = s$_M_value$real_20;
  return;

} 

where I can see nothing wrong.  Now CCP propagates s$_M_value$real_25 and
s$_M_value$imag_26 into the PHI nodes, but somehow does not simulate BB3:

Visiting PHI node: s$_M_value$real_20 = PHI s$_M_value$real_25(2),
s$_M_value$real_18(3)
Argument #0 (2 - 4 executable)
s$_M_value$real_25  Value: CONSTANT 0.0

Argument #1 (3 - 4 executable)
s$_M_value$real_18  Value: UNDEFINED

PHI node value: CONSTANT 0.0


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at google dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed

2007-11-15 Thread pault at gcc dot gnu dot org


--- Comment #5 from pault at gcc dot gnu dot org  2007-11-15 15:19 ---
(In reply to comment #4)
 (In reply to comment #3)
 Bother, the patch causes some regressions (interface_[3-5].f90)...
 Paul

These were easily fixed - also nested_modules_1.f90 was not standard compliant
in this regard.  It now regtests with find_symbol modified to:

  c = strcmp (name, st-n.sym-name);
  if (c == 0  st-n.sym-module
 strcmp (module, st-n.sym-module) == 0)
return st;

Off to generics and operators now!

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541



[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)

2007-11-15 Thread burnus at gcc dot gnu dot org


--- Comment #3 from burnus at gcc dot gnu dot org  2007-11-15 15:10 ---
See also:
  http://gcc.gnu.org/ml/fortran/2007-11/msg00074.html
and for the patch:
  http://gcc.gnu.org/ml/fortran/2007-11/msg00093.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 15:10:33
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-15 15:08 ---
This looks like this old bug that evaluate_stmt() sets results to UNDEFINED. 
As
we visit

D.26933_16 = __t_14 * D.26932_15;

the result should become VARYING, but we make it UNDEFINED.  Because also
likely_value () returns UNDEFINED for it.  Because in the process of setting
__t we use undefined operands (but those get overwritten).

  D.26929_10 = IMAGPART_EXPR __t_6(D);
  __t_11 = COMPLEX_EXPR b$_M_value$real_24, D.26929_10;
  D.26931_13 = REALPART_EXPR __t_11;
  __t_14 = COMPLEX_EXPR D.26931_13, b$_M_value$imag_23;
  D.26932_15 = COMPLEX_EXPR a$_M_value$real_21, a$_M_value$imag_22;
  D.26933_16 = __t_14 * D.26932_15;

so at least

  has_constant_operand = false;
  FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE | SSA_OP_VUSE)
{
  prop_value_t *val = get_value (use);

  if (val-lattice_val == UNDEFINED)
return UNDEFINED; 

  if (val-lattice_val == CONSTANT)
has_constant_operand = true;
}

doesn't look conservatively correct, because we pro-actively prefer UNDEFINED
here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #8 from manu at gcc dot gnu dot org  2007-11-15 15:39 ---
What happened to this patch?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675



[Bug fortran/33917] Rejects valid PROCEDURE declarations

2007-11-15 Thread burnus at gcc dot gnu dot org


--- Comment #11 from burnus at gcc dot gnu dot org  2007-11-15 15:18 ---
FIXED on the trunk (4.3.0) [is not part of any branch].


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  GCC build triplet|x86_64-unknown-linux-gnu|
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2007-11-15 15:40 ---
That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
constraint that if one operand is UNDEFINED the result is UNDEFINED as well.

For example MIN_EXPR INT_MIN, UNDEFINED, or MAX_EXPR INT_MAX, UNDEFINED
are of such kind as well.  No idea if we want a white-list here instead.
BIT_AND_EXPR UNDEFINED, 0 is also not UNDEFINED.

(all of the above not with actual constants as defined arg, but VARYING ones)

I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-15 10:21:31 |2007-11-15 15:40:13
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenther at suse dot de


--- Comment #7 from rguenther at suse dot de  2007-11-15 15:51 ---
Subject: Re:  [4.3 Regression] optimizer problem

On Thu, 15 Nov 2007, ebotcazou at gcc dot gnu dot org wrote:

 --- Comment #6 from ebotcazou at gcc dot gnu dot org  2007-11-15 15:44 
 ---
  That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
  constraint that if one operand is UNDEFINED the result is UNDEFINED as well.
 
 Is the problem somehow related to PR middle-end/33088?

It looks like so, but I cannot reproduce the problem in PR33088.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double

2007-11-15 Thread jvdelisle at gcc dot gnu dot org


--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-11-15 14:57 
---
There is a good chance that if you try to build the runtime library with
malign-double that you will break it.  My recommendation is don't use
-malign-double for I/O related things.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107



[Bug middle-end/33088] [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-15 15:53 ---
I cannot reproduce this problem with any of 4.1, 4.2 or 4.3.  But the issues
raised look related the CCP problem in PR34099.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088



[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-15 Thread eres at il dot ibm dot com


--- Comment #10 from eres at il dot ibm dot com  2007-11-15 15:02 ---
(In reply to comment #9)
 I mean the files you generate with -fprofile-generate.
 I expect this to be fully blamable on the partitioning code, and I would like
 to work in fixing this.  But you have to attach the profile information you
 have generated, or no-one can debug this unless he/she has access to POWER.

Sure, I'll attached the gcno file.
Please let me know if you need more information to retore the ICE.

Thanks


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #8 from rguenth at gcc dot gnu dot org  2007-11-15 16:04 ---
Which doesn't work :(  Unassigning.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #9 from rguenth at gcc dot gnu dot org  2007-11-15 16:06 ---
Created an attachment (id=14557)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14557action=view)
broken patch

It miscompiles gengtype.  I remember problems with changing likely_value in
similar ways back in time.  The other option is to not ignore UNDEFINED lattice
values in ccp_lattice_meet but do

any  M UNDEFINED   = VARYING

instead of

any  M UNDEFINED   = any


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #10 from rguenth at gcc dot gnu dot org  2007-11-15 16:08 
---
Created an attachment (id=14558)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14558action=view)
new broken patch

Err, that was an old patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #14557|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug fortran/33917] Rejects valid PROCEDURE declarations

2007-11-15 Thread burnus at gcc dot gnu dot org


--- Comment #10 from burnus at gcc dot gnu dot org  2007-11-15 15:12 ---
Subject: Bug 33917

Author: burnus
Date: Thu Nov 15 15:12:03 2007
New Revision: 130202

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130202
Log:
2007-11-15  Tobias Burnus  [EMAIL PROTECTED]

PR fortran/33917
* decl.c (match_procedure_decl): Pre-resolve interface.
* resolve.c (resolve_symbol): Reject interfaces later
declared in procedure statements.

2007-11-15  Tobias Burnus  [EMAIL PROTECTED]

PR fortran/33917
* gfortran.dg/proc_decl_11.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_decl_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread ebotcazou at gcc dot gnu dot org


--- Comment #6 from ebotcazou at gcc dot gnu dot org  2007-11-15 15:44 
---
 That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
 constraint that if one operand is UNDEFINED the result is UNDEFINED as well.

Is the problem somehow related to PR middle-end/33088?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug bootstrap/34110] New: gcc fails to build on i686

2007-11-15 Thread us15 at os dot inf dot tu-dresden dot de
SVN head does not build due to a warning that is treated as error.

gcc.build.lnx/./prev-gcc/xgcc
-B/gcc-b98ac6987827a195a1492167a9a158bf/gcc.build.lnx/./prev-gcc/
-B/usr/i686-pc-linux-gnu/bin/ -c   -g -O2 -fomit-frame-pointer -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror-DHAVE_CONFIG_H -I. -I.
-I../../gcc-svn/gcc -I../../gcc-svn/gcc/. -I../../gcc-svn/gcc/../include
-I../../gcc-svn/gcc/../libcpp/include  -I../../gcc-svn/gcc/../libdecnumber
-I../../gcc-svn/gcc/../libdecnumber/bid -I../libdecnumber   
../../gcc-svn/gcc/regclass.c -o regclass.o
cc1: warnings being treated as errors
../../gcc-svn/gcc/reg-stack.c: In function 'swap_to_top':
cc1: error: array subscript is below array bounds
make[3]: *** [reg-stack.o] Error 1


-- 
   Summary: gcc fails to build on i686
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: us15 at os dot inf dot tu-dresden dot de
 GCC build triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34110



[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 16:19 ---
Is this still a valid bug?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018



[Bug c/34109] New: Incorrect code for tail calls with a structure as 4th argument

2007-11-15 Thread narge-gcc at derrin dot id dot au
In the following code, the tail call in g() is compiled incorrectly on ARM with
-O2 or higher (and -fno-inline):

#include stdio.h

struct s {
int x, y, z;
};

int f(int a, int b, int c, struct s d, int e) {
printf(%d %d %d\n, d.x, d.y, d.z);
return 0;
}

int g(int a, int b, int c, int d, struct s e, int h) {
return f(a, b, c, e, h);
}

int main(void) {
f(0, 0, 0, (struct s){ 42, 69, 105 }, 7);
g(0, 0, 0, 0, (struct s){ 42, 69, 105 }, 7);
return 0;
}

With -O1 and lower, the result is correct:

42 69 105
42 69 105

With -O2 and higher, it prints:

42 69 105
69 69 7

Inspecting the output of gcc -O3 -fno-inline -S shows that gcc is shifting the
arguments on the stack downwards for the tail call. However, it starts at the
top, rather than at the bottom. So it writes over two arguments (e.z and e.x)
before loading them.

This has been broken since 4.1.1 (possibly earlier), and is still broken in
4.2.2.


-- 
   Summary: Incorrect code for tail calls with a structure as 4th
argument
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: narge-gcc at derrin dot id dot au
GCC target triplet: arm-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34109



[Bug c++/21393] Internal error: Segmentation Fault (program cc1plus) on a very long cout ... command

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2007-11-15 16:39 ---
It also works in GCC 4.3.0. 

If you still experience this issue, please, don't hesitate to reopen the bug.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21393



[Bug c++/21146] unable to resolve visible symbol

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #4 from manu at gcc dot gnu dot org  2007-11-15 16:30 ---
So, is this a bug or not? Do we know how icc resolves the ambiguity?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
   Keywords||diagnostic


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21146



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2007-11-15 16:38 
---
Oh, trivial error.  Looking again tomorrow.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-15 15:40:13 |2007-11-15 16:38:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug c++/34111] New: new oveload resolution error

2007-11-15 Thread mueller at gcc dot gnu dot org
this used to work a few days ago still:


-- 
   Summary: new oveload resolution error
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111



[Bug driver/26016] using -S on a .S file does not work properly

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #1 from manu at gcc dot gnu dot org  2007-11-15 17:16 ---
Confirmed. Probably some issue with the default specs.


-- 

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 |2007-11-15 17:16:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26016



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #13 from rguenth at gcc dot gnu dot org  2007-11-15 17:17 
---
I think this has been caused by the fix for PR29738.

Author: rakdver
Date: Thu Nov  9 00:09:43 2006
New Revision: 118602

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118602
Log:
PR tree-optimization/29738
* tree-ssa-ccp.c: Remove UNKNOWN_VAL from comments.
(ccp_lattice_t): Remove UNKNOWN_VAL.
(dump_lattice_value, ccp_lattice_meet, ccp_visit_phi_node):
Do not handle UNKNOWN_VAL.
(get_default_value): Set initial value of virtual operands to
VARYING.
(get_value): Always use get_default_value on uninitialized
operands.
(set_value_varying, surely_varying_stmt_p): New functions.
(set_lattice_value): Do not pass argument to get_value.
Do not handle UNKNOWN_VAL.
(likely_value): Follow the semantics described in the comment.
(ccp_initialize): Use surely_varying_stmt_p.  Do not mark
phi nodes DONT_SIMULATE_AGAIN.
(ccp_fold): Do not pass argument to get_value.
(fold_const_aggregate_ref, visit_assignment): Ditto.  Do not
handle UNKNOWN_VAL.

* gcc.dg/tree-ssa/ssa-ccp-14.c: New test.
* gcc.dg/tree-ssa/ssa-ccp-15.c: New test.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||29738
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug c++/21361] sizeof() packed structs potential errors

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 16:45 ---
Closing then.

(The link you gave is broken. A more stable link is
 http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html
)


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21361



[Bug middle-end/21474] missed optimizations when comparing address to NULL

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2007-11-15 17:03 ---
I think it is odd that if you call subr(i,0), it doesn't crash, that is (p-a)
does not actually dereferences p. Nonetheless, I agree that the behaviour seems
inconsistent. A nice little project for someone. As they say, patches welcome!


-- 

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 |2007-11-15 17:03:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474



[Bug c++/21603] C++ front-end accepts new with VLAs

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 17:05 ---
This is confirmed.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 17:05:28
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21603



[BUG] GCC 4.1 bug - Optimization breaks variables of type double

2007-11-15 Thread Le Thanh Trung
Hi,

When I compile my program without optimization (-O2 or -O3), it works
normally. However when I compile the code with -O2 or -O3 (GCC version
4.1), my program output wrong data. In addition, I did not see this
problem when I used GCC 3.4.6.

Information regarding my GCC:
OS: Centos 5  (a clone of Redhat Enterprise 5)
GCC: 4.1.1 20070105 (Red Hat 4.1.1-52)

Command:
   gcc -g -Wall gensvmparams.c -lm -o gensvmparams
   gcc -g -Wall -O2 gensvmparams -c -lm -o gensvmparams
   
My code:
#include stdio.h
#include stdlib.h
#include math.h

int main()
{
  double g = pow(2, -7);
  double c = 2;
  double cc = 1;
  double gg = -7;
  double cMax;
  cMax = pow(2,5);
  cMax = cMax + 0.01;
  double gMax;
  gMax = pow(2,-3);
  gMax = gMax + 0.01;

  while (c  cMax)  //gcc -O2 change the cMax to something different
than 32
  {
gg = -7;
g = pow(2, -7);
while (g  gMax)
{
  printf(5 %lf %lf\n, c, g);
  gg = gg + 0.25; 
  g = pow(2, gg);
}
cc = cc + 0.25;
c = pow(2, cc);
  }
  return 0;
}

P.S: When I add volatile to the declaration of cMax and gMax, my
program works correctly for all cases.

Thanks,
Regards,
Le Thanh Trung




[Bug c++/34111] new oveload resolution error

2007-11-15 Thread mueller at gcc dot gnu dot org


--- Comment #1 from mueller at gcc dot gnu dot org  2007-11-15 16:55 ---
Created an attachment (id=14559)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14559action=view)
the preprocessed source

.ii file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111



[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)

2007-11-15 Thread patchapp at dberlin dot org


--- Comment #4 from patchapp at dberlin dot org  2007-11-15 15:10 ---
Subject: Bug number PR34079

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00851.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079



[Bug middle-end/20983] [4.0/4.1/4.2/4.3 Regression] varargs functions force va_list variable to stack unnecessarily

2007-11-15 Thread jakub at gcc dot gnu dot org


--- Comment #11 from jakub at gcc dot gnu dot org  2007-11-15 17:42 ---
Testing a patch which addresses the simple pointer va_list targets (i386,
non-v4-abi ppc{,64}, etc.).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-07-05 09:23:01 |2007-11-15 17:42:02
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983



[Bug fortran/34108] ICE: Segmentation fault occurs by write(*,0) statement

2007-11-15 Thread fxcoudert at gcc dot gnu dot org


--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-15 16:40 
---
Confirmed on x86_64-linux, where it triggers (with valgrind):

==2841== Conditional jump or move depends on uninitialised value(s)
==2841==at 0x43550B: next_char (io.c:141)
==2841==by 0x435616: next_char_not_space (io.c:183)
==2841==by 0x4356C1: format_lex (io.c:221)
==2841==by 0x435A5D: check_format (io.c:467)
==2841==by 0x4369B5: match_io (io.c:927)
==2841==by 0x44D8A9: match_word (parse.c:64)
==2841==by 0x44E078: decode_statement (parse.c:296)
==2841==by 0x44EA84: next_statement (parse.c:505)
==2841==by 0x451EC4: gfc_parse_file (parse.c:3320)
==2841==by 0x479B64: gfc_be_parse_file (f95-lang.c:258)
==2841==by 0x6E901C: toplev_main (toplev.c:1042)
==2841==by 0x4B3B4C9: (below main) (in /usr/lib/debug/libc-2.3.6.so)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|i686-pc-cygwin  |
   Keywords||ice-on-invalid-code
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 16:40:54
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34108



[Bug other/19180] How to Add New GCC option

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 17:41 ---
*** Bug 26168 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||phr-gcc at nightsong dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180



[Bug driver/26168] improve comment about adding command line options

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 17:41 ---


*** This bug has been marked as a duplicate of 19180 ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26168



[Bug driver/26016] using -S on a .S file does not work properly

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 17:35 ---
This patch is just a guess but it seems to fix this:

Index: gcc/gcc.c
===
--- gcc/gcc.c   (revision 130174)
+++ gcc/gcc.c   (working copy)
@@ -841,9 +841,9 @@

 static const char *invoke_as =
 #ifdef AS_NEEDS_DASH_FOR_PIPED_INPUT
-%{!S:-o %|.s |\n as %(asm_options) %|.s %A };
+%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n as %(asm_options) %|.s %A };
 #else
-%{!S:-o %|.s |\n as %(asm_options) %m.s %A };
+%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n as %(asm_options) %m.s %A };
 #endif

 /* Some compilers have limits on line lengths, and the multilib_select
@@ -1029,12 +1029,12 @@
 #ifdef AS_NEEDS_DASH_FOR_PIPED_INPUT
%(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\
   %{E|M|MM:%(cpp_debug_options)}\
-  %{!M:%{!MM:%{!E:%{!S:-o %|.s |\n\
+  %{!M:%{!MM:%{!E:%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n\
as %(asm_debug) %(asm_options) %|.s %A 
 #else
%(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\
   %{E|M|MM:%(cpp_debug_options)}\
-  %{!M:%{!MM:%{!E:%{!S:-o %|.s |\n\
+  %{!M:%{!MM:%{!E:%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n\
as %(asm_debug) %(asm_options) %m.s %A 
 #endif
, 0, 1, 0},


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26016



[Bug fortran/34112] Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL

2007-11-15 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-15 19:25 ---
For stdcall and @n decoration, see also PR 31073.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112



[Bug c/34113] New: ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

2007-11-15 Thread dirtyepic at gentoo dot org
while compiling xorg-server-1.4 with GCC trunk rev 130172.

 x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE
-DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE
-I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I../include -I../include
-I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
-I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -O2 -g
-march=native -fomit-frame-pointer -pipe -MT access.lo -MD -MP -MF
.deps/access.Tpo -c access.c  -fPIC -DPIC -o .libs/access.o
access.c: In function 'siHostnameAddrMatch':
access.c:2115: warning: assignment from incompatible pointer type
access.c: In function 'InvalidHost':
access.c:1767: warning: 'addr' may be used uninitialized in this function
access.c: In function 'DefineSelf':
access.c:718: internal compiler error: in get_addr_dereference_operands, at
tree-ssa-operands.c:1746
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[1]: *** [access.lo] Error 1


# gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.0_pre20071113/work/gcc-4.3.0-20071113/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.0-pre20071113
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-nls --with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-libunwind-exceptions --enable-multilib
--disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.3.0-pre20071113  (experimental) (GCC)


-- 
   Summary: ICE in get_addr_dereference_operands, at tree-ssa-
operands.c:1746
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirtyepic at gentoo dot org
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread pcarlini at suse dot de


--- Comment #8 from pcarlini at suse dot de  2007-11-15 19:07 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug bootstrap/34110] gcc fails to build on i686

2007-11-15 Thread mueller at gcc dot gnu dot org


--- Comment #1 from mueller at gcc dot gnu dot org  2007-11-15 18:21 ---
temp_stack.reg[i_90] is the access, compare_for_stack_reg is the function,
and i_90 has the VRP determined range [-1, 2147483646]. 

it shouldn't warn for that. I'll work on a patch. 


-- 

mueller at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 18:21:40
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34110



[Bug fortran/34112] New: Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL

2007-11-15 Thread burnus at gcc dot gnu dot org
32bit Windows uses a different calling convention (called procedure pops the
stack, not caller) with a symbol name _name@n, where n is the number of bytes
to pop off.

See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/19d77dfc75f8be58
http://gcc.gnu.org/ml/fortran/2007-11/msg00074.html

As the standard makes not provisions and !DEC$ (*DEC$, cDEC$) is widely used,
gfortran should accept the following:

  function CallWndRetProc(nCode, wParam, lParam)
  !DEC$ ATTRIBUTES STDCALL,DECORATE, ALIAS: 'CallWndRetProc' :: CallWndRetProc 
  end function

Documentation:
http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattcst.htm
http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattrib.htm

They seem to map to
(http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html):

STDCALL  -  __attribute__(stdcall)
ALIAS-  __attribute__(alias(name))
DECORATE - ?

The problem with decorate is that its meaning depends on the platform. It may
decorate the name of alias with a _ prefix and @n postfix or only with a
_ prefix. Maybe one should start with STDCALL and ALIAS.

For alias one should do something as in c-pragma.c's apply_pragma_weak:

decl_attributes (decl, build_tree_list (get_identifier (alias),
 build_tree_list (NULL, value)),
 0);


-- 
   Summary: Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
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=34112



[Bug c/34113] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

2007-11-15 Thread dirtyepic at gentoo dot org


--- Comment #1 from dirtyepic at gentoo dot org  2007-11-15 19:34 ---
Created an attachment (id=14560)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14560action=view)
access-min.i

preprocessed source reduced by delta.

# gcc -v -O2 access-min.i
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.0_pre20071113/work/gcc-4.3.0-20071113/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.0-pre20071113
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-nls --with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-libunwind-exceptions --enable-multilib
--disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.3.0-pre20071113  (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O2' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/cc1 -fpreprocessed
access-min.i -quiet -dumpbase access-min.i -mtune=generic -auxbase access-min
-O2 -version -o /tmp/cc45MInZ.s
GNU C (GCC) version 4.3.0-pre20071113  (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 4.3.0-pre20071113  (experimental), GMP
version 4.2.2, MPFR version 2.3.0-p3.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128180
Compiler executable checksum: bdea9186cf5370f8e72d4207bcebdb8c
access-min.i:38: warning: data definition has no type or storage class
access-min.i:152: warning: 'struct stat64' declared inside parameter list
access-min.i:152: warning: its scope is only this definition or declaration,
which is probably not what you want
access-min.i:155: warning: 'struct stat64' declared inside parameter list
access-min.i:183: warning: '__transparent_union__' attribute ignored
access-min.i:320: warning: 'struct cmsghdr' declared inside parameter list
access-min.i:322: warning: 'struct cmsghdr' declared inside parameter list
access-min.i:325: warning: 'struct cmsghdr' declared inside parameter list
access-min.i:355: warning: 'struct rpcent' declared inside parameter list
access-min.i:357: warning: 'struct rpcent' declared inside parameter list
access-min.i:381: warning: 'struct protoent' declared inside parameter list
access-min.i:405: warning: parameter names (without types) in function
declaration
access-min.i:483: warning: parameter names (without types) in function
declaration
access-min.i:502: warning: parameter names (without types) in function
declaration
access-min.i: In function 'ResetHosts':
access-min.i:610: warning: assignment makes pointer from integer without a cast
access-min.i:611: warning: assignment makes pointer from integer without a cast
access-min.i: In function 'siTypeAdd':
access-min.i:736: warning: incompatible implicit declaration of built-in
function 'strlen'
access-min.i: In function 'siCheckAddr':
access-min.i:747: warning: incompatible implicit declaration of built-in
function 'strlen'
access-min.i: In function 'siHostnameAddrMatch':
access-min.i:760: warning: assignment makes pointer from integer without a cast
access-min.i: In function 'siLocalCredGetId':
access-min.i:798: warning: initialization makes pointer from integer without a
cast
access-min.i:804: warning: initialization makes pointer from integer without a
cast
access-min.i: In function 'AccessUsingXdmcp':
access-min.i:560: internal compiler error: in get_addr_dereference_operands, at
tree-ssa-operands.c:1746
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113



[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

2007-11-15 Thread rguenth at gcc dot gnu dot org


--- Comment #12 from rguenth at gcc dot gnu dot org  2007-11-15 17:10 
---
Trivial testcase we get wrong with the current scheme:

int foo (int b, int c)
{
  int x;
  if (b)
return x  c;
  else
return 1;
}
extern void abort (void);
int main()
{
  if (foo(1, 0) != 0)
abort ();
  return 0;
}

because we say that x  c is UNDEFINED (and so ignore its value in the
otherwise CONSTANT PHI).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099



[Bug middle-end/26544] printf calls optimized at -O0

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 17:43 ---
This is either a bug or not. I think that if it is not mere constant folding
and it takes some effort, we should not do it. So let's decide so we can either
confirm it or close it as invalid.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26544



[Bug other/19180] How to Add New GCC option

2007-11-15 Thread manu at gcc dot gnu dot org


--- Comment #4 from manu at gcc dot gnu dot org  2007-11-15 17:40 ---
From bug 26168:

gcc/gcc.c has a comment at the top that's a guide to adding a command line
option.  It's incomplete: it should say to add the new option to c.opt and
rebuild the compiler, and then describe how the variable OPT_whatever gets
created by the awk scripts during the build process, so you can then check for
the option elsewhere in the compiler.  That mechanism doesn't appear documented
at all, and took me a while to figure out through code tracing.  Some
description in the comment would have been a big help.

Also, the comment at the top of the automatically-generated options.c file says
it's generated by opts.sh rather than by those awk scripts.  That's a minor
thing but updating it wouldn't hurt.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180



[Bug middle-end/34109] Incorrect code for tail calls with a structure as 4th argument

2007-11-15 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-15 18:53 ---
I think this is already fixed in 4.3.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||wrong-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34109



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread paolo at gcc dot gnu dot org


--- Comment #7 from paolo at gcc dot gnu dot org  2007-11-15 19:05 ---
Subject: Bug 34105

Author: paolo
Date: Thu Nov 15 19:05:17 2007
New Revision: 130207

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130207
Log:
2007-11-15  Paolo Carlini  [EMAIL PROTECTED]

PR libstdc++/34105
* include/bits/stl_algobase.h: Do not include bits/algorithmfwd.h.
(lexicographical_compare(const unsigned char*, const unsigned char*,
const unsigned char*, const unsigned char*),
lexicographical_compare(const char*, const char*, const char*,
const char*)): Move to namespace (std, _GLIBCXX_STD_P).
* include/parallel/algobase.h: Do not include bits/algorithmfwd.h.
(equal): Move after mismatch.
* include/bits/stl_heap.h (is_heap, is_heap_until): Reorder.
* include/bits/char_traits.h: Include bits/stl_algobase.h instead
of bits/algorithmfwd.h.
* include/bits/stl_algo.h: Include first bits/algorithmfwd.h.
* include/bits/algorithmfwd.h (lexicographical_compare): Do not
declare overloads.
* include/parallel/partition.h: Include parallel/random_number.h.
* testsuite/util/testsuite_abi.cc: Include algorithm.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/algorithmfwd.h
trunk/libstdc++-v3/include/bits/char_traits.h
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/bits/stl_algobase.h
trunk/libstdc++-v3/include/bits/stl_heap.h
trunk/libstdc++-v3/include/parallel/algobase.h
trunk/libstdc++-v3/include/parallel/partition.h
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug middle-end/23848] [4.0/4.1/4.2 Regression] stack deallocation can be more efficient

2007-11-15 Thread jakub at gcc dot gnu dot org


--- Comment #6 from jakub at gcc dot gnu dot org  2007-11-15 19:37 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression]
   |stack deallocation can be   |stack deallocation can be
   |more efficient  |more efficient


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23848



[Bug c/34114] New: Missed optimization: cannot determine loop termination

2007-11-15 Thread lloyd at randombit dot net
As far as I can see the loop in the function f() always terminates without the
loop counter overflowing, but GCC cannot tell that it does.

$ g++-4.3-20070907 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907
--enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt
Thread model: posix
gcc version 4.3.0 20070907 (experimental) (GCC) 

$ cat no_loop_opt.c 

void f(unsigned int in)
   {
   unsigned int rnd_to_2 = (in - (in % 2));
   unsigned int i;

   for(i = 0; i != rnd_to_2; i += 2)
  ;
   }

$ gcc-4.3-20070907 -O2 -Wall -Wextra -Wunsafe-loop-optimizations -c
no_loop_opt.c
no_loop_opt.c: In function ‘f’:
no_loop_opt.c:7: warning: cannot optimize loop, the loop counter may overflow


-- 
   Summary: Missed optimization: cannot determine loop termination
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114



[Bug c/34113] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

2007-11-15 Thread dirtyepic at gentoo dot org


--- Comment #2 from dirtyepic at gentoo dot org  2007-11-15 20:06 ---
Created an attachment (id=14561)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14561action=view)
access-mini.i

further reduced.


-- 

dirtyepic at gentoo dot org changed:

   What|Removed |Added

  Attachment #14560|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread pcarlini at suse dot de


--- Comment #6 from pcarlini at suse dot de  2007-11-15 18:14 ---
I'm finishing testing a complete patch.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug tree-optimization/34113] [4.3 Regression] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

2007-11-15 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE in  |[4.3 Regression] ICE in
   |get_addr_dereference_operand|get_addr_dereference_operand
   |s, at tree-ssa- |s, at tree-ssa-
   |operands.c:1746 |operands.c:1746
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113



[Bug c++/34094] Undefined static data member in anonymous namespace can acquire a definition anyway

2007-11-15 Thread simon_baldwin at yahoo dot com


--- Comment #3 from simon_baldwin at yahoo dot com  2007-11-15 19:55 ---
The definition's really there in 4.2.1, absent in 4.1.1:

$ 4.2.1/g++ -S ns1.cc  c++filt ns1.s | grep B::x
movl$0, (anonymous namespace)::B::x
.local  (anonymous namespace)::B::x
.comm   (anonymous namespace)::B::x,4,4

$ 4.1.1/g++ -S ns1.cc  c++filt ns1.s | grep B::x
movl$0, (anonymous namespace)::B::x


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094



[Bug target/11787] always call memcpy for block move in mips16

2007-11-15 Thread rsandifo at gcc dot gnu dot org


--- Comment #6 from rsandifo at gcc dot gnu dot org  2007-11-15 20:52 
---
Fixed on mainline, and not appropriate for backporting.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11787



[Bug middle-end/23848] [4.0/4.1/4.2/4.3 Regression] stack deallocation can be more efficient

2007-11-15 Thread jakub at gcc dot gnu dot org


--- Comment #5 from jakub at gcc dot gnu dot org  2007-11-15 19:03 ---
Subject: Bug 23848

Author: jakub
Date: Thu Nov 15 19:02:54 2007
New Revision: 130206

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130206
Log:
PR middle-end/23848
* tree-ssa-ccp.c (optimize_stack_restore): New function.
(execute_fold_all_builtins): Call optimize_stack_restore for
BUILT_IN_STACK_RESTORE.

* gcc.dg/tree-ssa/pr23848-1.c: New test.
* gcc.dg/tree-ssa/pr23848-2.c: New test.
* gcc.dg/tree-ssa/pr23848-3.c: New test.
* gcc.dg/tree-ssa/pr23848-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23848



[Bug c++/5310] Weird warnings about using (int)NULL

2007-11-15 Thread patchapp at dberlin dot org


--- Comment #8 from patchapp at dberlin dot org  2007-11-15 20:05 ---
Subject: Bug number PR c++/5310

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00865.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5310



[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm

2007-11-15 Thread bkoz at gcc dot gnu dot org


--- Comment #9 from bkoz at gcc dot gnu dot org  2007-11-15 21:54 ---

Awesome. Looks good. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105



[Bug c/34115] New: atomic builtins not supported on i686?

2007-11-15 Thread scovich at gmail dot com
Linking fails for the program below, with the error:

undefined reference to `___sync_val_compare_and_swap_4'

// gcc -Wall atomic.c
int main() {
  int *a, b, c;
  return __sync_val_compare_and_swap(a, b, c);
}

According to the atomic builtins docs (), Not all operations are supported by
all target processors. If a particular operation cannot be implemented on the
target processor, a warning will be generated and a call an external function
will be generated. The external function will carry the same name as the
builtin, with an additional suffix `_n' where n is the size of the data type.

If CAS is not supported, how come I don't get a warning? Why would i686 *not*
support compare and swap? The cmpxchg instruction has been around since 80486,
according to the intel IA-32 processor manual. 

Also, does an unsupported builtin mean the user is responsible to write that
function, or simply that the compiler must make a function call to synthesize
its behavior?

FWIW, my x86_64 cross-compile gcc 4.2.0 handles it fine, emitting a
lock+cmpxchg pair.


-- 
   Summary: atomic builtins not supported on i686?
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
  GCC host triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115



  1   2   >