[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-04-21 07:11 ---
Confirmed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-21 07:11:35
   date||


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

[Bug target/35619] gcc-4.3.0 build fails in gfortran section centos-4.6

[ubizjak at gmail dot com]

--- Comment #15 from ubizjak at gmail dot com  2008-04-21 07:18 ---
Closed as invalid.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/26674] missed optimization / 128-bit arithmetic.

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-04-21 07:26 ---
Not a regression, so the fix won't be backported on release branches.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug target/31054] FLDx not emitted for 80387 constants in 64-bit mode.

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-04-21 07:28 ---
Not a regression on 4.2, so fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug target/35867] [4.4 Regression]: gcc.target/i386/addr-sel-1.c

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-04-21 07:31 ---
Fixed by the revert.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug objc/35996] New: ICE while building simple ObjC code with -fobjc-gc

[vapier at gentoo dot org]

this simple test code provided by Michael Arntzenius causes gcc to ICE when
built with -fobjc-gc.  happens with gcc 4.1/4.2/4.3 on x86_64.  x86 seems to
pass OK.

$ cat test.m
#import 
@interface Test: Object { int i; }
@end
Test *global_var;
@implementation Test
+initialize {
global_var = [Test new];
}
@end
$ gcc-4.3.0 -fobjc-gc test.m
test.m: In function ‘+[Test initialize]’:
test.m:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE while building simple ObjC code with -fobjc-gc
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vapier at gentoo dot org
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug target/21588] x86 machine builtins do not have any const/pure attributes set

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2008-04-21 08:07 ---
Fixed for 4.3.0 by:

Author: uros
Date: Sat Jul 14 13:46:40 2007
New Revision: 126639

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126639
Log:
* config/i386/i386.c (init_mmx_sse_builtins): Define all builtins
except __builtin_ia32_emms, __builtin_ia32_ldmxcsr,
__builtin_ia32_stmxcsr, __builtin_ia32_maskmovq,
__builtin_ia32_loadups,
__builtin_ia32_storeups, __builtin_ia32_loadhps,
__builtin_ia32_loadlps,
__builtin_ia32_storehps, __builtin_ia32_storelps,
__builtin_ia32_movntps, __builtin_ia32_movntq, __builtin_ia32_sfence,
__builtin_ia32_femms, __builtin_ia32_maskmovdqu,
__builtin_ia32_loadupd,
__builtin_ia32_storeupd, __builtin_ia32_loadhpd,
__builtin_ia32_loadlpd,
__builtin_ia32_movnti, __builtin_ia32_movntpd, __builtin_ia32_movntdq,
__builtin_ia32_clflush, __builtin_ia32_lfence, __builtin_ia32_mfence,
__builtin_ia32_loaddqu, __builtin_ia32_storedqu,
__builtin_ia32_monitor,
__builtin_ia32_mwait, __builtin_ia32_lddqu, __builtin_ia32_movntdqa,
__builtin_ia32_movntsd and __builtin_ia32_movntss as const builtins
using def_builtin_const.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug target/32301] int __attribute__((vector_size(8))) doesn't use %mm0, produces ugly code

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-04-21 08:21 ---
Duplicate of 14552.

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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/14552] compiled trivial vector intrinsic code is inefficient

[ubizjak at gmail dot com]

--- Comment #38 from ubizjak at gmail dot com  2008-04-21 08:21 ---
*** Bug 32301 has been marked as a duplicate of this bug. ***


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||tomash dot brechko at gmail
   ||dot com


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

[Bug target/21408] DAZ related macros are improperly guarded in pmmintrin.h

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-04-21 08:24 ---
I guess that H.J. will know what shall we do here.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug libstdc++/35968] nth_element fails to meet its complexity requirements

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2008-04-21 08:24 ---
Many thanks Roger for your further help on nth_element, excellent news.


-- 


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

[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-21 09:09 ---
Well, this bug needs proper analysis and a testcase, but yes, I also see this
slowdown.


-- 


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

[Bug middle-end/35992] [4.4 Regression] Linux kernel code fails to compile with -Os

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-21 09:27 ---
Btw, glibc build fails the same way.


-- 


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

[Bug testsuite/35981] FAIL: gcc.dg/utf-cvt.c (test for warnings, line 46/47) with -m64

[kris dot van dot hees at oracle dot com]

--- Comment #4 from kris dot van dot hees at oracle dot com  2008-04-21 
11:15 ---
Patch posted to gcc-patches:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01552.html


-- 


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

[Bug fortran/35997] New: Used function interface bug

[drewmccormack at mac dot com]

Code that has a function interface used from two modules can fail if one of the
modules renames the function interface. The example below fails to compile with
this message:

gfortran testfuncinterface.f90 
testfuncinterface.f90:21.7:

  if ( valid() ) then
  1
Error: IF clause at (1) requires a scalar LOGICAL expression


Source Code:

module funcinterfacemod

  interface
logical function valid()
end function
  end interface

end module

module secondmod
  use funcinterfacemod, valid2 => valid
end module

logical function valid()
  valid = .true.
end function

program main
  use secondmod
  use funcinterfacemod
  if ( valid() ) then
print *,'Is Valid'
  endif
end program


This example does compile is the order of the use statements is reversed. This
also compiles on earlier versions of gfortran (eg 4.3.0 20071114 (experimental)
(GCC))


-- 
   Summary: Used function interface bug
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drewmccormack at mac dot com
 GCC build triplet: 4.3.0 20080125 (experimental) (GCC)
  GCC host triplet: i386-apple-darwin8.11.1
GCC target triplet: i386-apple-darwin8.11.1


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

in the gcc sourcefiles: hp extension instead of hpp

[Jørgen Moth]

Hello
I always have to correct two mispelled file-extension names in the gcc 
tar-file. E.g. in the 4.3.0 fileset,


gcc-4.3.0/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hp
gcc-4.3.0/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hp

The extension name of these two files should be .hpp instead of .hp

Best regards
Jorgen Moth
UNI-C Lyngby
DTU Bldg. 304, DK-2800 Lyngby
+45 3587 8963
[EMAIL PROTECTED]
www.uni-c.dk 

[Bug c/28319] sentinel attribute should support non-NULL sentinels

[ludo at gnu dot org]

--- Comment #3 from ludo at gnu dot org  2008-04-21 12:14 ---
I proposed a patch, which awaits approval and copyright assignment:

  http://article.gmane.org/gmane.comp.gcc.patches/160923/focus=160991

Ludovic.


-- 


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

[Bug ada/35998] New: debug info invalid x86_64 DW_AT_byte_size 0xffffffff

[jan dot kratochvil at redhat dot com]

The source:

procedure AdaFF is
  type rec is
record
  null;
end record;
  X : rec;
begin
  null;
end AdaFF;

produces output by:
$ rm -f adaff{,.o,.ali};gnatmake -g adaff.adb ;readelf -a --debug-dump adaff |
grep 'DW_AT_byte_size.*0x'
<30b>   DW_AT_byte_size   : 0x  

 <1><306>: Abbrev Number: 20 (DW_TAG_structure_type)
<307>   DW_AT_name: (indirect string, offset: 0x3c8):
ada_main__main__TsehB___XUT
<30b>   DW_AT_byte_size   : 0x
<30f>   DW_AT_decl_file   : 1
<310>   DW_AT_decl_line   : 105
<311>   DW_AT_sibling : <0x33b>

A more complicated testcase
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.ada/packed_tagged/comp_bug.adb?rev=1.1&cvsroot=src
crashes GDB eating all the memory on `print x' there.


-- 
   Summary: debug info invalid x86_64 DW_AT_byte_size 0x
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
 GCC build triplet: x86_64-fedora-linux-gnu
  GCC host triplet: x86_64-fedora-linux-gnu
GCC target triplet: x86_64-fedora-linux-gnu


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

[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff

[jan dot kratochvil at redhat dot com]

--- Comment #1 from jan dot kratochvil at redhat dot com  2008-04-21 12:40 
---
Created an attachment (id=15503)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15503&action=view)
GDB workaround.


-- 


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

[Bug java/35999] New: GCJ Crash while compiling eclipse 64-bit on Ubuntu Hardy

[jorgen at fabeljet dot com]

[EMAIL PROTECTED]:~/tmp$ gcj -v -save-temps -shared -findirect-dispatch
-Wl,-Bsymbolic -fjni -fPIC
../eclipse-x86_64-gcj/plugins/org.eclipse.emf.mapping_2.3.0.v200802051830.jar 
Using built-in specs.
Reading specs from /usr/lib/gcc/x86_64-linux-gnu/4.2.3/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java
--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.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-java-awt=gtk --enable-gtk-cairo --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libmudflap
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu6)
 /usr/lib/gcc/x86_64-linux-gnu/4.2.3/jc1
../eclipse-x86_64-gcj/plugins/org.eclipse.emf.mapping_2.3.0.v200802051830.jar
-fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc
-fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase
org.eclipse.emf.mapping_2.3.0.v200802051830.jar -mtune=generic -auxbase
org.eclipse.emf.mapping_2.3.0.v200802051830 -g1 -version -findirect-dispatch
-fjni -fPIC -fbootclasspath=./:/usr/share/java/libgcj-4.2.jar -o
org.eclipse.emf.mapping_2.3.0.v200802051830.s
GNU Java version 4.2.3 (Ubuntu 4.2.3-2ubuntu6) (x86_64-linux-gnu)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu6).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Class path starts here:
./
./ (system)
/usr/share/java/libgcj-4.2.jar/ (system) (zip)
org/eclipse/emf/mapping/command/AddOverrideCommand.java:169: 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.
For Debian GNU/Linux specific bug reporting instructions,
see .


-- 
   Summary: GCJ Crash while compiling eclipse 64-bit on Ubuntu Hardy
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jorgen at fabeljet 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=35999

[Bug java/35999] GCJ Crash while compiling eclipse 64-bit on Ubuntu Hardy

[jorgen at fabeljet dot com]

--- Comment #1 from jorgen at fabeljet dot com  2008-04-21 12:52 ---
Created an attachment (id=15504)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15504&action=view)
Preprocessed output


-- 


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

[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2008-04-21 12:54 
---
(In reply to comment #3)
> in gthr-win32.h there seems to be a more serious bug. The cast of an integer
> with less size to a pointer can be seriously wrong.

I don't think it's an issue: the type objc_thread_t, which is used as a thread
identifier, it declared as (void *), so it's larger than the integer types that
are cast into it (which are DWORD). It's inelegant, but I think it cannot cause
bugs.

I suggest silencing the warning that way (in both libobjc/thr-win32.c and
gcc/thr-win32.c):

--- thr-win32.c.old 2008-04-21 14:53:42.0 +0200
+++ thr-win32.c 2008-04-21 14:53:35.0 +0200
@@ -70,7 +70,7 @@ __objc_thread_detach(void (*func)(void *
arg, 0, &thread_id)))
 thread_id = 0;

-  return (objc_thread_t)thread_id;
+  return (objc_thread_t)(INT_PTR)thread_id;
 }

 /* Set the current thread's priority. */
@@ -151,7 +151,7 @@ __objc_thread_exit(void)
 objc_thread_t
 __objc_thread_id(void)
 {
-  return (objc_thread_t)GetCurrentThreadId();
+  return (objc_thread_t)(INT_PTR)GetCurrentThreadId();
 }

 /* Sets the thread's local storage pointer. */


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

Getting the error for srand48 and drand48 with gcc 4.3.0

[Snehalatha Rao]

Hi, 

We are building a code having the call to the function srand48 and drand48. 
Using the older gcc versions which is 4.2.0 the code runs smoothly. However 
when compiled using the latest gcc version (4.3.0) it gives the following 
error. 

testTBuffer.cpp:24: error: ‘srand48’ was not declared in this scope 
testTBuffer.cpp:27: error: ‘drand48’ was not declared in this scope 

On including the header file stdlib.h the problem gets solved. What difference 
in header files between the two versions of the compiler is causing this 
problem? Is this a defect? Is there any workaound to this problem other than 
manipulating each and every file in the project? 

Sample program that will reproduce the problem: 
#include 
int main(void) 
{ 
printf("Hello World \n"); 
srand48(clock()+getpid()); 
} 

Awaiting your help in solving this problem, 
-- 
Thanks & Regards, 
Snehalatha 



  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32

[ktietz at gcc dot gnu dot org]

--- Comment #5 from ktietz at gcc dot gnu dot org  2008-04-21 13:03 ---
I agree, that this patch does not break things and the build for this target
gets more silent.


-- 


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

[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning

[manu at gcc dot gnu dot org]

--- Comment #25 from manu at gcc dot gnu dot org  2008-04-21 13:07 ---
Reopened per new testcase.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning

[pluto at agmk dot net]

--- Comment #26 from pluto at agmk dot net  2008-04-21 13:15 ---
and one more testcase, similar to c#24:

extern int i, j, k;
struct X { X(); ~X(); };
bool f()
{
  X x;
  if ( i && j )
if ( k < 0 ) return true; else return false;
  else
return false;
}

tested on gcc-4.3-svn20080417


-- 


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

[Bug target/21408] DAZ related macros are improperly guarded in pmmintrin.h

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-04-21 13:30 ---
pmmintrin.h is for SSE3. I don't see anything wrong here. If someone
wants to support SSE3 macros on some processors with SSE2, a new header
file may be used.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

--- Comment #40 from hjl dot tools at gmail dot com  2008-04-21 13:36 
---
The fix

  test -f $lt_prog-recursive && exec $scriptdir/../prev-$dir/$prog
${1+"$@"}

  touch $lt_prog-recursive
  $scriptdir/../$dir/$prog ${1+"$@"}
  result=$?
  rm -f $lt_prog-recursive
  exit $result

is parallel build safe. When as is invoked, it creates a $lt_prog-recursive.
Before it finishes, another as is invoked and detects $lt_prog-recursive
exist. Error.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||Joey dot ye at intel dot com
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #41 from bonzini at gnu dot org  2008-04-21 13:53 ---
Ralf, do you think it would be possible to create the script atomically in
ltmain.sh?


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

--- Comment #42 from hjl dot tools at gmail dot com  2008-04-21 14:01 
---
I think my original patch

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01827.html

is the simplest one since it calls the linker, the only tool which
suffers this bug, from previous stage only in linker directory which
is the only place where this problem exists.


-- 


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

[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.

[tromey at gcc dot gnu dot org]

--- Comment #5 from tromey at gcc dot gnu dot org  2008-04-21 14:02 ---
Fixed on trunk.
As I doubt this will be back-ported to 4.3.x, I am closing the bug.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.

[tromey at gcc dot gnu dot org]

--- Comment #6 from tromey at gcc dot gnu dot org  2008-04-21 14:02 ---
Subject: Bug 33415

Author: tromey
Date: Mon Apr 21 14:02:00 2008
New Revision: 134507

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134507
Log:
libcpp
PR libcpp/33415:
* charset.c (_cpp_convert_input): Add buffer_start argument.
Ignore UTF-8 BOM if seen.
* internal.h (_cpp_convert_input): Add argument.
* files.c (struct _cpp_file) : New field.
(destroy_cpp_file): Free buffer_start, not buffer.
(_cpp_pop_file_buffer): Likewise.
(read_file_guts): Update.
gcc/testsuite
PR libcpp/33415:
* gcc.dg/cpp/pr33415.c: New file.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/pr33415.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c
trunk/libcpp/files.c
trunk/libcpp/internal.h


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #43 from bonzini at gnu dot org  2008-04-21 14:07 ---
Yes, but your patch is, even if not wrong, unsatisfactory.  Even though only
one program suffers from this bug now, it is in general a problem that libtool
invokes some of the tools that are being built, and I want to fix it in a
general way.  You are fixing a symptom, but it is much better to fix the cause.

I think this is now a bug in libtool, and fixing it will benefit upstream too.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[Ralf dot Wildenhues at gmx dot de]

--- Comment #44 from Ralf dot Wildenhues at gmx dot de  2008-04-21 14:13 
---
It is probably possible to generate the wrapper script atomically.
But this solution can become ugly: on w32 we may generate also a wrapper
executable.

I still don't see a convincing argument why you don't use -no-fast-install.
If the problem is that you don't like the relink to happen at 'make install'
time, then why don't you generate two 'ld' programs, one for installation
and one for use uninstalled, with -no-fast-install, or even -no-install.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

--- Comment #45 from hjl dot tools at gmail dot com  2008-04-21 14:26 
---
(In reply to comment #43)
> Yes, but your patch is, even if not wrong, unsatisfactory.  Even though only
> one program suffers from this bug now, it is in general a problem that libtool
> invokes some of the tools that are being built, and I want to fix it in a
> general way.  You are fixing a symptom, but it is much better to fix the 
> cause.
> 
> I think this is now a bug in libtool, and fixing it will benefit upstream too.
> 

But this is a very unique relink and linker problem. It can only happen
to linker. Why make a simple problem more complicated than necessary?


-- 


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

[Bug c++/35987] [4.1/4.2/4.3/4.4 regression] ICE with invalid if-condition

[jakub at gcc dot gnu dot org]

-- 

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 |2008-04-21 14:10:41
   date||


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #46 from bonzini at gnu dot org  2008-04-21 14:38 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> But this is a very unique relink and linker problem. It can only happen
> to linker. Why make a simple problem more complicated than necessary?

First, the linker may in principle call again the assembler (LTO); the 
libtool wrapper calls gcc, not ld.

Second, even if we went with your patch the race in libtool ought to be 
analyzed (and IMO fixed but Ralf may convince me otherwise).

Paolo


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #47 from bonzini at gnu dot org  2008-04-21 14:39 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> It is probably possible to generate the wrapper script atomically.
> But this solution can become ugly: on w32 we may generate also a wrapper
> executable.

For win32 it suffices to:

1) create wrapper executable under random name
2) create wrapper script under random name
3) move wrapper script to correct name
4) move wrapper executable to correct name

If you invert 1 and 2, the patch is a mess because you have to move 
around a lot of code. :-)  If you invert 3 and 4, the executable may 
fail because of not finding a script -- this is actually another problem 
with the current code.

(BTW, were you libtool maintainers aware of this race/these races?)

> I still don't see a convincing argument why you don't use -no-fast-install.
> If the problem is that you don't like the relink to happen at 'make install'
> time, then why don't you generate two 'ld' programs, one for installation
> and one for use uninstalled, with -no-fast-install, or even -no-install.

The problem is that you want to make a combined tree with released gcc 
and binutils, and since this is arguably a gcc bug you want the latest 
gcc without the bug to compile a combined tree with any released 
binutils version.

At worse, we could just pass --disable-fast-install in the toplevel 
configure when gcc is present.  That could be a solution for 4.3 actually.


-- 


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

[Bug target/35982] [4.3 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-04-21 15:08 ---
This seems to be a vectorizer bug.
vectorizable_conversion is called on
 
unit size 
align 32 symtab 0 alias set 3 canonical type 0x2e9496c0
precision 32
pointer_to_this >
visited var  def_stmt

version 14>
arg 1 
arg 0 
visited var  def_stmt

version 13>>
pr35982.c:13:5>

vectype_in is __vector int (V4SFmode) and modifier is NONE.
targetm.vectorize.builtin_conversion (FLOAT_EXPR, <__vector int>) returns
__builtin_altivec_vcfsx, which converts V4SI argument to V4SF.  But what
vect_get_vec_defs actually returns in vec_oprnds0 is not V4SI, but V4SF.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||irar at gcc dot gnu dot org,
   ||dorit at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-21 15:08:02
   date||


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

--- Comment #48 from hjl dot tools at gmail dot com  2008-04-21 15:52 
---
(In reply to comment #46)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap with --enable-shared
> 
> 
> > But this is a very unique relink and linker problem. It can only happen
> > to linker. Why make a simple problem more complicated than necessary?
> 
> First, the linker may in principle call again the assembler (LTO); the 
> libtool wrapper calls gcc, not ld.
> 

I don't think it is a problem since this problem is limited to that the
new linker is used to relink itself, which leads to a infinite recursive
loop.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Last reconfirmed|2008-04-01 12:08:52 |2008-04-21 15:52:43
   date||


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

[Bug c++/35909] [4.3/4.4 Regression] ICE with bit-field and const references

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-04-21 15:58 ---
Introduced by PR35056, so it is not a regression against 4.3.0, but against
4.2.x.  The ICE is only present in ENABLE_CHECKING builds, otherwise
TARGET_EXPR
with incompatible type is created.
Why do you think the testcase is valid?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org


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

[Bug c++/35678] [4.3/4.4 Regression] partial template specialization ICE in dependent_type_p, at cp/pt.c:15539

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-04-21 16:00 ---
Subject: Bug 35678

Author: jason
Date: Mon Apr 21 15:59:36 2008
New Revision: 134515

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134515
Log:
PR c++/35678
* pt.c (template_template_parm_bindings_ok_p): Set
processing_template_decl while in this function.

Added:
trunk/gcc/testsuite/g++.dg/template/ttp27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35909] [4.3/4.4 Regression] ICE with bit-field and const references

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-04-21 16:04 ---
That explains why I didn't see it with my 4.3.0 build.  Lowering severity
again.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
   Keywords||ice-checking
   Priority|P1  |P2


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #49 from bonzini at gnu dot org  2008-04-21 16:05 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> I don't think it is a problem since this problem is limited to that the
> new linker is used to relink itself, which leads to a infinite recursive
> loop.

The same thing could happen when the new assembler is relinked itself, 
if the relink was actually an LTO pass (at the end you assemble the 
result of whole-program optimization, and reach an infinite loop).


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

--- Comment #50 from hjl dot tools at gmail dot com  2008-04-21 16:18 
---
(In reply to comment #49)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap with --enable-shared
> 
> 
> > I don't think it is a problem since this problem is limited to that the
> > new linker is used to relink itself, which leads to a infinite recursive
> > loop.
> 
> The same thing could happen when the new assembler is relinked itself, 
> if the relink was actually an LTO pass (at the end you assemble the 
> result of whole-program optimization, and reach an infinite loop).
> 

The sequence for LTO will be

1. Gcc calls ld for LTO.
2. ld calls as to assemble assembly code.
3. as calls ld to relink itself.
   3.1 ld calls the previous linker to relink itself to create lt-ld.
   3.2 lt-ld is used to relink as to create lt-as
   3.3 lt-as is used to assemble assembly code.
4. lt-ld is used to finish LTO.

Will LTO be applied on the fully linked linker in step 3.1? If yes, can we
disable LTO for step 3.1?


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #51 from bonzini at gnu dot org  2008-04-21 16:25 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared

> 3. as calls ld to relink itself.
>3.1 ld calls the previous linker to relink itself to create lt-ld.
> 
> Will LTO be applied on the fully linked linker in step 3.1?

I think yes, unless libtool is modified to invoke ld directly for the 
relink step.

> If yes, can we disable LTO for step 3.1?

I think no but anyway that would be hack after hack. :-(

Paolo


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

--- Comment #52 from hjl dot tools at gmail dot com  2008-04-21 16:40 
---
(In reply to comment #51)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap with --enable-shared
> 
> > 3. as calls ld to relink itself.
> >3.1 ld calls the previous linker to relink itself to create lt-ld.
> > 
> > Will LTO be applied on the fully linked linker in step 3.1?
> 
> I think yes, unless libtool is modified to invoke ld directly for the 
> relink step.
> 

I can extend my patch to as.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #53 from bonzini at gnu dot org  2008-04-21 17:02 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> I can extend my patch to as.

You surely can (and actually extend it to everything else that is 
invoked via exec-tool)...  but then you're never using the bootstrapped 
tools in a 2-stage bootstrap!  In a 3-stage bootstrap you will because 
you'll invoke stage2 tools, and stage2 must be the same as stage3.  But 
this would be very confusing for people debugging, and in the worst 
(very hypothetical, I admit) case, it could even cause comparison 
failures if the stage1 tools are wrong in some way.


-- 


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

[Bug fortran/35019] Gfortran does not support "-J " only "-J"

[dfranke at gcc dot gnu dot org]

--- Comment #7 from dfranke at gcc dot gnu dot org  2008-04-21 17:11 ---
Subject: Bug 35019

Author: dfranke
Date: Mon Apr 21 17:10:15 2008
New Revision: 134518

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134518
Log:
gcc:
2008-04-21  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/35019
* gcc.h: Added fortran options that take arguments to
DEFAULT_SWITCH_TAKES_ARG and DEFAULT_WORD_SWITCH_TAKES_ARG
macros.

gcc/fortran:
2008-04-21  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/35019
* gfortranspec.c (lookup_option): Properly handle separated arguments
in -J option, print missing argument message when necessary.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortranspec.c
trunk/gcc/gcc.h


-- 


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

[Bug fortran/35019] Gfortran does not support "-J " only "-J"

[dfranke at gcc dot gnu dot org]

--- Comment #8 from dfranke at gcc dot gnu dot org  2008-04-21 17:11 ---
Fixed on trunk. Closing.
Again.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug fortran/35019] Gfortran does not support "-J " only "-J"

[dfranke at gcc dot gnu dot org]

--- Comment #9 from dfranke at gcc dot gnu dot org  2008-04-21 17:12 ---
See comment #8.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

Re: Getting the error for srand48 and drand48 with gcc 4.3.0

[Andrew Pinski]

On Mon, Apr 21, 2008 at 5:56 AM, Snehalatha Rao <[EMAIL PROTECTED]> wrote:
>  On including the header file stdlib.h the problem gets solved. What 
> difference in header files between the two versions of the compiler is 
> causing this problem? Is this a defect? Is there any workaound to this 
> problem other than manipulating each and every file in the project?

Please read http://gcc.gnu.org/gcc-4.3/porting_to.html .

Thanks,
Andrew Pinski

[Bug c++/35325] [4.3/4.4 regression] ICE with fixed-point types in template parameter

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2008-04-21 17:59 ---
Subject: Bug 35325

Author: jason
Date: Mon Apr 21 17:58:53 2008
New Revision: 134519

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134519
Log:
PR c++/35325
* tree.c (cp_tree_equal): Handle FIXED_CST.

Added:
trunk/gcc/testsuite/g++.dg/ext/fixed1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35678] [4.3/4.4 Regression] partial template specialization ICE in dependent_type_p, at cp/pt.c:15539

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2008-04-21 18:03 ---
Subject: Bug 35678

Author: jason
Date: Mon Apr 21 18:02:26 2008
New Revision: 134520

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134520
Log:
PR c++/35325
* tree.c (cp_tree_equal): Handle FIXED_CST.

PR c++/35678
* pt.c (template_template_parm_bindings_ok_p): Set
processing_template_decl while in this function.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/fixed1.C
  - copied unchanged from r134519, trunk/gcc/testsuite/g++.dg/ext/fixed1.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/ttp27.C
  - copied unchanged from r134519,
trunk/gcc/testsuite/g++.dg/template/ttp27.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/cp/tree.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35325] [4.3/4.4 regression] ICE with fixed-point types in template parameter

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2008-04-21 18:03 ---
Subject: Bug 35325

Author: jason
Date: Mon Apr 21 18:02:26 2008
New Revision: 134520

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134520
Log:
PR c++/35325
* tree.c (cp_tree_equal): Handle FIXED_CST.

PR c++/35678
* pt.c (template_template_parm_bindings_ok_p): Set
processing_template_decl while in this function.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/fixed1.C
  - copied unchanged from r134519, trunk/gcc/testsuite/g++.dg/ext/fixed1.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/ttp27.C
  - copied unchanged from r134519,
trunk/gcc/testsuite/g++.dg/template/ttp27.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/cp/tree.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/26445] SSE byte-by-byte load instruction fails to compile

[uros at gcc dot gnu dot org]

--- Comment #8 from uros at gcc dot gnu dot org  2008-04-21 18:41 ---
Subject: Bug 26445

Author: uros
Date: Mon Apr 21 18:41:04 2008
New Revision: 134522

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134522
Log:
PR target/26445
* g++.dg/other/i386-4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/other/i386-4.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/26445] SSE byte-by-byte load instruction fails to compile

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2008-04-21 18:43 ---
This is fixed in mainline (and probably for 4.3.0 too).


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail|4.2.0 4.0.3 |4.2.0 4.0.3 4.1.2
  Known to work||4.3.0
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug target/29339] TImode ICE with -m32 -msse -mtune=i386

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-04-21 18:46 ---
This works with 4.3.0 and mainline.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/35968] nth_element fails to meet its complexity requirements

[sjhowe at dial dot pipex dot com]

--- Comment #4 from sjhowe at dial dot pipex dot com  2008-04-21 18:51 
---
Yes. You want a partition that is O(1) that each time round eliminates N/2
elements (bearing in mind the post-condition for nth_element where iterators
greater than the kth iterator have elements that are >= the kth element and
iterators less than the kth iterator have elements that are <= the kth element)
So median-of-3 or for large N is a must. And this is run for 3/2 * log2(N)
steps.

If it has not converged by end of steps (so it has been a bad run) or new N is
< some constant (making binary insertion sort worthwhile) then at that point
you want the cheapest approximate median algorithm that is _guaranteed_ O(N).
The algorithm is still O(N) as the choosing median and partitioning is occuring
in serial. In this case, it is minimising the constant factor that matters. 
The median-of-median of 5 is well known
But this approximate median is less well known.
So it is the combination of
   (i) guaranteed O(N) partitioning
   (ii) cheapest constant factor (so minimising iterator traversal, copy ctor,
swapping, comparing etc)
I have not yet checked median of median-of-5 against this, but I believe (ii)
works out cheaper.
And if it works that there exists an even cheaper guranteed O(N) partitioning
that finds an approximate median, gcc should use that. It does not matter if
the exact median is found each time round just as long as N/2 elements are
reduced each time round. 

I have also been alerted to a intraselect variation of nth_element() that looks
promising. It is this:
   If you wanted the iterator that was 20% in from the start and you sampled
elements to choose a partition element, instead of choosing an approximate
median, choose the element that is 20%. So if the sample was 5 elements, choose
the 2nd element. Now if partitioning was lop-sided but you reduced the number
of elements drastically leaving a tiny amount as candidates, you have massively
reduced the problem. This is brand new research in nth_element but I have not
yet seen much analysis.

Stephen Howe


-- 


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

[Bug ada/36001] New: $(GNATMAKE) not defined with 'cd gcc && make'

[rwild at gcc dot gnu dot org]

A rebuild after changing some files in an up to date tree
shows that $(GNATMAKE) is not properly defined if make is
started from gcc/ instead of the top level:

$ cd gcc && make
C -nostdinc -I- -I. -Iada -I../../gcc/gcc/ada -o ada/b_gnatb.c ada/gnatbind.ali
make: C: Command not found
make: [ada/b_gnatb.c] Error 127

What's more, without the patch from
,
this failure is silent even.


-- 
   Summary: $(GNATMAKE) not defined with 'cd gcc && make'
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwild at gcc dot gnu dot org


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

[Bug c++/36002] New: Error messages report wrong, invalid function type.

[gcc-bugzilla at contacts dot eelis dot net]

Consider the following invalid code:

  template  void f() { T::bla; }
  void g() { f(); }

g++ emits:

  t.cpp: In function ‘void f() [with T = void ()()]’:
  t.cpp:2:   instantiated from here
  t.cpp:1: error: ‘bla’ is not a member of ‘void ()()’

The error should say "void ()", not "void ()()". The latter is not even a valid
C++ type, as can be seen by doing:

  template  void f();
  void g() { f(); }

resulting in:

  error: ‘type name’ declared as function returning a function


-- 
   Summary: Error messages report wrong, invalid function type.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug ada/35576] Ada HW Interrupt Task Enhancement

[joel at gcc dot gnu dot org]

--- Comment #4 from joel at gcc dot gnu dot org  2008-04-21 22:37 ---
Created an attachment (id=15505)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15505&action=view)
Updated to 4.4.0 20080421 (experimental) [trunk revision 134514]

Requires patch in http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01581.html to
even compile Ada targeting RTEMS on the trunk.  


-- 


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

[Bug ada/35576] Ada HW Interrupt Task Enhancement

[joel at gcc dot gnu dot org]

--- Comment #5 from joel at gcc dot gnu dot org  2008-04-21 22:39 ---
Tested against this GCC using gcc-ada-hwint-20080421.diff and patch in 
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01581.html 

sparc-rtems4.9-gcc (GCC) 4.4.0 20080421 (experimental) [trunk revision 134514]


-- 


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

[Bug fortran/35997] [4.3/4.4 regression]Used function interface bug

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-04-22 01:19 
---
Confirmed.  Works for me on 4.2.4, Fails on 4.3.1


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.1 4.4.0
  Known to work||4.2.4
   Last reconfirmed|-00-00 00:00:00 |2008-04-22 01:19:55
   date||
Summary|Used function interface bug |[4.3/4.4 regression]Used
   ||function interface bug


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

[Bug middle-end/36003] New: df-byte-scan.c changes broke cris-elf compiling libgcc

[hp at gcc dot gnu dot org]

Build worked with revision 134517.  Build was broken with 134530 on, as
follows:
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include -g -O2 -march=v10
-mbest-lib-options -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
 -isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc 
-I. -I. -I../../.././gcc -I/tmp/hpautotest-gcc1/gcc/libgcc
-I/tmp/hpautotest-gcc1/gcc/libgcc/. -I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc
-I/tmp/hpautotest-gcc1/gcc/libgcc/../include  -DHAVE_CC_TLS -o _mul_df.o -MT
_mul_df.o -MD -MP -MF _mul_df.dep -DFINE_GRAINED_LIBRARIES -DL_mul_df -c
../../.././gcc/dp-bit.c
In file included from ../../.././gcc/dp-bit.c:46:
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/config/fp-bit.h:391: warning: 'packed'
attribute ignored for field of type 'fractype'
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/config/fp-bit.h:392: warning: 'packed'
attribute ignored for field of type 'unsigned int'
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/config/fp-bit.h:393: warning: 'packed'
attribute ignored for field of type 'unsigned int'
../../.././gcc/dp-bit.c:144: warning: conflicting types for built-in function
'nan'
../../.././gcc/dp-bit.c: In function '__muldf3':
../../.././gcc/dp-bit.c:965: internal compiler error: in
df_compute_accessed_bytes_extract, at df-byte-scan.c:79

(gdb) p m1_size
$1 = 8

The breaking insn is:
(insn:QI 214 213 215 25 ../../.././gcc/dp-bit.c:902 (set (cc0)
(zero_extract:DI (subreg:SI (reg/v:DI 38 [ high ]) 0)
(const_int 1 [0x1])
(const_int 0 [0x0]))) 16 {*btst} (nil))

for some reason, the zero_extract has gained DImode, while the subreg is in
SImode.

It has been argued that cris.md is wrong for having no mode for the
zero_extract:
(define_insn "*btst"
  [(set (cc0)
(zero_extract
 (match_operand:SI 0 "nonmemory_operand" "r,r,r,r,r,r,n")
 (match_operand:SI 1 "const_int_operand" "K,n,K,n,K,n,n")
 (match_operand:SI 2 "nonmemory_operand" "M,M,K,n,r,r,r")))]
...
but there's nothing inherently wrong in that:
"If @var{loc} is in a register, the mode to use is specified by the
operand of the @code{insv} or @code{extv} pattern
(@pxref{Standard Names}) and is usually a full-word integer mode,
which is the default if none is specified." says rtl.texi about sign_extract,
to which the zero_extract doc refers, making the modelessness a special-case.

This is the canonical btst pattern, see the m68k port.  Compares don't have a
mode either, for cc0 ports, though test insns (compare to 0) do.  Admittedly,
the cc0 ports are a mixed bunch, some specifying a mode for the zero_extract
expressions. 

This /might/ be fixable by change the documentation (and all backends) to
require an explicit mode for all zero_extract/sign_extract expressions, but I'm
not sure.  It's probably just a bug: there should never have been any DImode
operand generated in the first place, or perhaps some bug added it to the
zero_extract expression.

I haven't checked how this insn looked with 134517.
I'll attach dp-bit.i


-- 
   Summary: df-byte-scan.c changes broke cris-elf compiling libgcc
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug middle-end/36003] df-byte-scan.c changes broke cris-elf compiling libgcc

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-04-22 03:48 ---
Created an attachment (id=15506)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15506&action=view)
compile with cc1 -fpreprocessed dp-bit.i -O2

Preprocessed dp-bit.c


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[Ralf dot Wildenhues at gmx dot de]

--- Comment #54 from Ralf dot Wildenhues at gmx dot de  2008-04-22 05:27 
---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc +
binutils source tree doesn't bootstrap with --enable-shared

* bonzini at gnu dot org wrote on Mon, Apr 21, 2008 at 04:39:20PM CEST:
> For win32 it suffices to:
> 
> 1) create wrapper executable under random name
> 2) create wrapper script under random name
> 3) move wrapper script to correct name
> 4) move wrapper executable to correct name

Probably.  Libtool 2.2.2 has things changed there, and a couple of
issues still, so I need to look at this anyway.

> (BTW, were you libtool maintainers aware of this race/these races?)

I wasn't.  But I don't think we guarantee atomic creation of output.
Take the trivial case: program needs no relink.  In that case, it's
up to the compiler/linker whether the program is created atomically.
GCC doesn't do it.  :-)

So I'm not yet convinced this particular race to be a Libtool bug.

> The problem is that you want to make a combined tree with released gcc 
> and binutils, and since this is arguably a gcc bug you want the latest 
> gcc without the bug to compile a combined tree with any released 
> binutils version.

Ah ok.

> At worse, we could just pass --disable-fast-install in the toplevel 
> configure when gcc is present.  That could be a solution for 4.3 actually.

But then you may not strictly install ld-new, as it may not work on some
systems.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #55 from bonzini at gnu dot org  2008-04-22 06:27 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


>> (BTW, were you libtool maintainers aware of this race/these races?)
> 
> I wasn't.  But I don't think we guarantee atomic creation of output.
> Take the trivial case: program needs no relink.  In that case, it's
> up to the compiler/linker whether the program is created atomically.
> GCC doesn't do it.  :-)
> 
> So I'm not yet convinced this particular race to be a Libtool bug.

... but you can assume it "is created once and for all" after it is 
built (something you can guarantee with Makefile rules).  That's an 
invariant that libtool's relinking breaks, and that atomic operation 
would restore.

Another possibility would be to force libtool to relink at linking time, 
i.e. keep the fast install, but do the relinking even before the program 
is invoked (and the wrapper script installed).  But I assume it is a mess?

Paolo


-- 


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

[Bug c++/35909] [4.3/4.4 Regression] ICE with bit-field and const references

[aoliva at gcc dot gnu dot org]

--- Comment #8 from aoliva at gcc dot gnu dot org  2008-04-22 06:27 ---
Mine


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/35909] [4.3/4.4 Regression] ICE with bit-field and const references

[aoliva at gcc dot gnu dot org]

--- Comment #9 from aoliva at gcc dot gnu dot org  2008-04-22 06:28 ---
Created an attachment (id=15507)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15507&action=view)
Patch that fixes the bug, under test

Here's a patch that I've come up with that fixes this bug.  I've just started
testing it.


-- 


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

[Bug target/31486] ICE with vector code when -mno-sse2 on amd64

[uros at gcc dot gnu dot org]

--- Comment #1 from uros at gcc dot gnu dot org  2008-04-22 06:49 ---
Subject: Bug 31486

Author: uros
Date: Tue Apr 22 06:48:48 2008
New Revision: 134549

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134549
Log:
PR target/31486
* gcc.target/i386/pr31486.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr31486.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/31486] ICE with vector code when -mno-sse2 on amd64

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-04-22 06:54 ---
Fixed in 4.3.0.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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