[Bug testsuite/38864] Fixed-point tests under gcc.target/mips are missing the fixed_point target check

[nemet at gcc dot gnu dot org]

--- Comment #7 from nemet at gcc dot gnu dot org  2009-01-27 07:46 ---
Fixed.


-- 

nemet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/38864] Fixed-point tests under gcc.target/mips are missing the fixed_point target check

[nemet at gcc dot gnu dot org]

--- Comment #6 from nemet at gcc dot gnu dot org  2009-01-27 07:42 ---
Subject: Bug 38864

Author: nemet
Date: Tue Jan 27 07:41:46 2009
New Revision: 143694

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143694
Log:
PR testsuite/38864
* gcc.target/mips/fixed-vector-type.c: Add { target { fixed_point} }
to dg-do compile.
* gcc.target/mips/fixed-scalar-type.c: Likewise.
* gcc.target/mips/dpaq_sa_l_w.c: Likewise.
* gcc.target/mips/dpsq_sa_l_w.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/dpaq_sa_l_w.c
trunk/gcc/testsuite/gcc.target/mips/dpsq_sa_l_w.c
trunk/gcc/testsuite/gcc.target/mips/fixed-scalar-type.c
trunk/gcc/testsuite/gcc.target/mips/fixed-vector-type.c


-- 


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

[Bug driver/38864] Fixed-point tests under gcc.target/mips are missing the fixed_point target check

[nemet at gcc dot gnu dot org]

--- Comment #5 from nemet at gcc dot gnu dot org  2009-01-27 07:25 ---
Adjust the summary.


-- 

nemet at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Incorrect interaction   |Fixed-point tests under
   |between --with-arch=native  |gcc.target/mips are missing
   |and -mARCH  |the fixed_point target check


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

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-01-27 07:02 ---
I saw this once even during gcc profiledbootstrap, so I agree the error should
go for 4.4.


-- 


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

[Bug other/38983] New: GPL version 3 transition incomplete

[bkoz at redhat dot com]

GPL version 3 was released by the FSF on June 29, 2007, and some (but not all)
GCC sources were updated for trunk and active releases starting with GCC 4.2.2.
Here are some o the patches.

Changing top level files and include/ files over to GPLv3
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00600.html

RFA: Add GPLv3 COPYING files
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01341.html

RFA: GPLv3: treelang
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01503.html

RFA: GPLv3: gcc files
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01570.html

RFA: GPLv3: testsuite
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01896.html

RFA: GPLv3: gcc/cp
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01898.html

RFA: GPLv3: gcc/fortran
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01905.html

RFA: GPLv3: gcc/objc
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01922.html

RFA: GPLv3: gcc/objcp
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01925.html

RFA: GPLv3: gcc/java
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02093.html

RFA: GPLv3: gcc/ada
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02096.html

RFA: GPLv3: gcc/config
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02146.html

However, the following directories still use GPL version 2, or GPL version to
variants like the GPL version 2 with a runtime exception:

libgcc
libstdc++
libgfortran
libssp
libcpp
libobjc
libgomp
libdecnumber
libiberty
libmudflap

And another library does not specify a GPL version:
libjava (see LIBGCJ_LICENSE)

The reason given for this partial transition is that the FSF is/was trying to
unify the license used (the GPL 2 variants + runtime exception) such that all
libraries could use the same wording, based off of the GPL version 3 text. It
was assumed that at some point, the FSF legal team would produce finalized
wording that the GCC team could then use for the remaining libraries.

We are still waiting for this finalized text. In fact, the libstdc++
maintainers have been waiting for clarification on this issue since 1998. The
preliminary wording was subject to draft review on April 30, 2008, but we've
seen little since then.

This bug is to track this effort, and hopefully add a bit of transparency to
the process.


-- 
   Summary: GPL version 3 transition incomplete
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at redhat dot com


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

[Bug fortran/31243] truncating strings longer than 2**32 characters

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2009-01-27 05:00 
---
I am going to look at this for a bit.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-03-28 22:50:08 |2009-01-27 05:00:27
   date||


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

[Bug libstdc++/22388] When cross-compiling libstdc++ for mingw, enable large file support (LFS)

[bkoz at gcc dot gnu dot org]

--- Comment #5 from bkoz at gcc dot gnu dot org  2009-01-27 04:30 ---

I see: 

# For LFS support.
GLIBCXX_CHECK_LFS

as part of the generic libstdc++ configuration in configure.ac for gcc trunk.
Therefore, LFS config is the same codepath for cross and native. Thus, if
mingw32 supports LFS, then this should be working for both native and crosses.

This is new for gcc-4.4.0. Yay!

Due the current state of sources, and the length of time this has been
inactive, I'm going to close this bug as FIXED and set the target milestone for
4.4.0. It can be considered WONTFIX for previous releases of gcc. 


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2009-01-27 04:23 ---

This seems like a template linkage bug specific to the powerpc-darwin8.5.0
target, probably related to simulated/incomplete support of comdat and weak
linkage on that platform via coalesced symbols. It seems unlikely to be fixed,
although I suppose miracles happen every day.

I do not believe this is specific to libstdc++, IMHO. That it does not happen
on other architectures of darwin (ie x86) or on non-darwin hosts make me leery
of adding this workaround to the docs. 

What is the link to the Apple bug report?

I see this on x86/linux for your code sample:

%eu-readelf -s 2weak.o | grep Rep
  109:  32 OBJECT  WEAK   DEFAULT  120
_ZNSbIN9__gnu_cxx9characterIti11__mbstate_tEESt11char_traitsIS2_ESaIS2_EE4_Rep20_S_empty_rep_storageE

both with and without -fno-weak. 

This seems to be another instance of gcc/28017: I would like to close this as a
duplicate of that bug report, if the bug reporter is agreeable. 


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||28017
   Keywords||documentation


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

[Bug libstdc++/35424] deallocate_local_thread-5.cc and deallocate_local_thread-7.cc fails on darwin

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2009-01-27 04:04 ---
Fixed


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/35424] deallocate_local_thread-5.cc and deallocate_local_thread-7.cc fails on darwin

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2009-01-27 04:03 ---
Fixed on trunk and gcc-4.3.4


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Component|target  |libstdc++
   Last reconfirmed|2008-12-07 20:32:40 |2009-01-27 04:03:48
   date||
   Target Milestone|--- |4.3.4


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

[Bug libstdc++/7439] C99 compat: Can't use the name INFINITY in an enum.

[gdr at integrable-solutions dot net]

--- Comment #8 from gdr at integrable-solutions dot net  2009-01-27 03:34 
---
Subject: Re:  C99 compat: Can't use the name INFINITY in 
an enum.

On Mon, Jan 26, 2009 at 6:19 PM, bkoz at gcc dot gnu dot org

> Thus, I am going to close this as WONTFIX. For C++0x, the case is INVALID, and
> for open gcc branches the bug status is FIXED.
>
> Gaby, if I'm off on this please re-open.
>
> -benjamin

I fully agree with your resolution.


-- 


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

[Bug bootstrap/38981] internal compiler error

[kamaraju at gmail dot com]

--- Comment #7 from kamaraju at gmail dot com  2009-01-27 02:00 ---
I can't believe I am so dense... I installed bison, removed /usr/ccs/bin from
the PATH. But I forgot to recompile gcc with the new update. I was still trying
to bootstrap from the old compiler. Let me recompile gcc (with bison) and see
if the problem goes away. It usually takes one day to finish...

raju


-- 


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

[Bug ada/38982] New: FAIL: gnat.dg/rep_clause2.adb (test for excess errors)

[danglin at gcc dot gnu dot org]

Executing on host: /home/dave/gnu/gcc-4.4/objdir/gcc/gnatmake
-I/home/dave/gnu/g
cc-4.4/objdir/gcc/ada/rts --GCC=/home/dave/gnu/gcc-4.4/objdir/gcc/xgcc
--GNATBIND=/home/dave/gnu/gcc-4.4/objdir/gcc/gnatbind
--GNATLINK=/home/dave/gnu/gcc-4.4/o
bjdir/gcc/gnatlink -cargs -B/home/dave/gnu/gcc-4.4/objdir/gcc -largs
--GCC=/home
/dave/gnu/gcc-4.4/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4.4/objdir/gcc -margs -q
-f /home/dave/gnu/gcc-4.4/gcc/gcc/testsuite/gnat.dg/rep_clause2.adb  -c
-I/home/dave/gnu/gcc-4.4/objdir/gcc/ada/rts -S  -o rep_clause2.s(timeout =
300)/home/dave/gnu/gcc-4.4/gcc/gcc/testsuite/gnat.dg/rep_clause2.ads:11: note:
Offset of packed bit-field 'N' has changed in GCC 4.4output
is:/home/dave/gnu/gcc-4.4/gcc/gcc/testsuite/gnat.dg/rep_clause2.ads:11: note:
Offse
t of packed bit-field 'N' has changed in GCC 4.4
FAIL: gnat.dg/rep_clause2.adb (test for excess errors)


-- 
   Summary: FAIL: gnat.dg/rep_clause2.adb (test for excess errors)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug libstdc++/21321] [4.2/4.3/4.4 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2009-01-27 01:48 ---
I'll try to fit in to check this weekend, thanks for asking.


-- 


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

[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES

[bkoz at gcc dot gnu dot org]

--- Comment #22 from bkoz at gcc dot gnu dot org  2009-01-27 01:41 ---

waiting for feedback on a current release branch (4.3) or trunk.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|WAITING
   Target Milestone|--- |4.4.0


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

[Bug libstdc++/21321] [4.2/4.3/4.4 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test

[bkoz at gcc dot gnu dot org]

--- Comment #6 from bkoz at gcc dot gnu dot org  2009-01-27 01:30 ---

Hey HP, is this still an issue? Don't see test results for this target for any
currently-open gcc branches. Update please.


-- 


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

[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables

[mmlr at mlotz dot ch]

--- Comment #4 from mmlr at mlotz dot ch  2009-01-27 01:23 ---
Created an attachment (id=17189)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17189&action=view)
Proposed fix with conditional use of stat based on HAVE_SYS_STAT_H

This only conditionally uses stat() if HAVE_SYS_STAT_H is defined. Not sure
about the indentation style at all, sorry.


-- 

mmlr at mlotz dot ch changed:

   What|Removed |Added

  Attachment #17181|0   |1
is obsolete||


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

[Bug libstdc++/15088] 27_io/ostream_inserter_arith test05/06 failures

[bkoz at gcc dot gnu dot org]

--- Comment #7 from bkoz at gcc dot gnu dot org  2009-01-27 01:22 ---

This could be fixed via a dg-skip-if embedded target type thing. 

I don't remember seeing this fail in recent arm-elf crosses. Is this still an
active issue?


-- 


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

[Bug bootstrap/38981] internal compiler error

[kamaraju at gmail dot com]

--- Comment #6 from kamaraju at gmail dot com  2009-01-27 01:20 ---
Is there anyway to figure out if my gcc is still using yacc and not bison?


-- 


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

[Bug bootstrap/38981] internal compiler error

[kamaraju at gmail dot com]

--- Comment #5 from kamaraju at gmail dot com  2009-01-27 01:14 ---
My initial guess was that it is a bug in yacc. But now I do not think so. I
have compiled bison (which supersedes yacc). I still see this bug with bison
(and no yacc).


-- 


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

[Bug libstdc++/17755] Can't compile djgpp cross-compiler

[bkoz at gcc dot gnu dot org]

--- Comment #8 from bkoz at gcc dot gnu dot org  2009-01-27 01:12 ---

Closing due to inactivity. If this is still a problem on a release branch (ie,
gcc-4.3.x and above), please re-open and provide details.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||3.4.3 4.0.2
 Resolution||WORKSFORME


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

[Bug bootstrap/38981] internal compiler error

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-27 01:08 ---
So if I am reading this thread correctly this is really a bug in Solaris's
yacc?


-- 


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

[Bug middle-end/38981] internal compiler error

[kamaraju at gmail dot com]

--- Comment #3 from kamaraju at gmail dot com  2009-01-27 01:05 ---
Created an attachment (id=17188)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17188&action=view)
preprocessed source code

produced by using
gcc -E ice.c > ice.c.ppd


-- 


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

[Bug libstdc++/18571] document wstring/wfilebuf code conversions

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2009-01-27 01:03 ---
Add documentation keyword


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||documentation


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

[Bug libstdc++/17789] [4.2/4.3/4.4 Regression] Cannot 'make check' inside libstdc++-v3

[bkoz at gcc dot gnu dot org]

--- Comment #14 from bkoz at gcc dot gnu dot org  2009-01-27 01:02 ---

Fixed as of gcc-4.2.x.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/38981] internal compiler error

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-27 01:01 ---
Can you provide the preprocessed source?


-- 


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

[Bug c/38981] internal compiler error

[kamaraju at gmail dot com]

--- Comment #1 from kamaraju at gmail dot com  2009-01-27 01:00 ---
Created an attachment (id=17187)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17187&action=view)
code to reproduce the internal compiler error


-- 


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

[Bug c/38981] New: internal compiler error

[kamaraju at gmail dot com]

Consider the attached code ice.c . When compiled, it is giving an internal
compiler error. I was not able to reduce it any further. Would appreciate if
someone can reduce it further.

> gcc -c ice.c 
ice.c: In function 'd_substitution':
ice.c:23: internal compiler error: Bus Error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

> gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /home/kkusuman/software/unZipped/gcc-4.4-20090109/configure
--enable-languages=c,c++,fortran
--prefix=/home/kkusuman/software/myroot/gcc-4.4-20090109 --with-gnu-as
--with-as=/home/kkusuman/software/myroot/bin/as --with-gnu-ld
--with-ld=/home/kkusuman/software/myroot/bin/ld
Thread model: posix
gcc version 4.4.0 20090109 (experimental) (GCC) 



Here is the gdb backtrace

> gdb 
> /home/kkusuman/software/myroot/gcc-4.4-20090109/libexec/gcc/sparc-sun-solaris2.8/4.4.0/cc1
>  
GNU gdb 6.8.0.20090120
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run ice.c 
Starting program:
/home/kkusuman/software/myroot/gcc-4.4-20090109/libexec/gcc/sparc-sun-solaris2.8/4.4.0/cc1
ice.c
 d_substitution
Analyzing compilation unit
Performing interprocedural optimizations
Assembling
functions:
 d_substitution
Program received signal SIGSEGV, Segmentation fault.
0x0040bea8 in compare_pairs (p1=0x8469e0, p2=0x8469ec) at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/tree-ssa-coalesce.c:318
318   result = (* pp2)->cost - (* pp1)->cost;
(gdb) bt
#0  0x0040bea8 in compare_pairs (p1=0x8469e0, p2=0x8469ec) at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/tree-ssa-coalesce.c:318
#1  0xff1cb8d0 in qsort () from /usr/lib/libc.so.1
#2  0x0040f8d8 in coalesce_ssa_name () at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/tree-ssa-coalesce.c:434
#3  0x003c6528 in rewrite_out_of_ssa () at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/tree-outof-ssa.c:1353
#4  0x002a99c8 in execute_one_pass (pass=0x79d30c) at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/passes.c:1279
#5  0x002a9c58 in execute_pass_list (pass=0x79d30c) at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/passes.c:1328
#6  0x003c1d08 in tree_rest_of_compilation (fndecl=0xfefb6280) at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/tree-optimize.c:419
#7  0x0053a37c in cgraph_expand_function (node=0xfef0ec00) at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/cgraphunit.c:1047
#8  0x0053a624 in cgraph_output_in_order () at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/cgraphunit.c:1195
#9  0x0053c768 in cgraph_optimize () at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/cgraphunit.c:1306
#10 0x000265d0 in c_write_global_declarations () at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/c-decl.c:8074
#11 0x0036a6a8 in toplev_main (argc=, argv=) at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/toplev.c:981
#12 0x00012780 in _start () at
/home/kkusuman/software/unZipped/gcc-4.4-20090109/gcc/config/sparc/sol2-c1.asm:106



Initially, I asked this question on gcc-help
http://gcc.gnu.org/ml/gcc-help/2009-01/msg00109.html . I narrowed down the
problem further and reporting it here.

thanks
raju


-- 
   Summary: internal compiler error
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kamaraju at gmail dot com


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

[Bug target/38959] Additional switches to disallow processor supplementary instructions

[markhobley at yahoo dot co dot uk]

--- Comment #2 from markhobley at yahoo dot co dot uk  2009-01-27 00:36 
---
Subject: Re:  Additional switches to disallow processor supplementary
instructions


> --- Comment #1 from pinskia at gcc dot gnu dot org 
> 2009-01-26 19:15 ---
> I think this is a bad idea.  Also most if not all x86 CPUs
> released in the last
> 10 years support these instructions

These instructions make the binaries non-portable, The switches aid
portability. You do not have to apply these. If the switches are not applied,
the compiler behaves exactly as it does now, so the compiled code remains the
same, if required.

The advantage of the switches is that they can be used to enable system
builders to trap invalid instructions at compile time, rather than waiting for
reports of system crashes at runtime.

Applying the fix has no detrimental effects to anyone, since the compiler
behaves as it does now. However the fix does benefit people wanting to produce
portable code.

Mark.


-- 


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

[Bug testsuite/38820] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2009-01-27 00:29 ---
It's not a bug that GCC EXEC_PREFIX is defined when the testsuite is run, as
explained in these patches:

  http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html
  http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01493.html

When testing in the build tree the compiler is invoked with -B, which takes
precendence over GCC_EXEC_PREFIX.  That allows getting start files from
GCC_EXEC_PREFIX while the GCC support itself comes from the build tree.  It
doesn't matter if $GCC_EXEC_PREFIX contains an old installation.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI

[bkoz at gcc dot gnu dot org]

--- Comment #9 from bkoz at gcc dot gnu dot org  2009-01-27 00:26 ---
Update summary.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|parse error before numeric  |_GNU_SOURCE vs. M_PI
   |constant |


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

[Bug libstdc++/11074] libstdc++ fails to build due to gettext issue

[bkoz at gcc dot gnu dot org]

--- Comment #19 from bkoz at gcc dot gnu dot org  2009-01-27 00:23 ---

Fixed by 4.3.2


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.2


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

[Bug libstdc++/7439] C99 compat: Can't use the name INFINITY in an enum.

[bkoz at gcc dot gnu dot org]

--- Comment #7 from bkoz at gcc dot gnu dot org  2009-01-27 00:19 ---

Updating this bug report. 

This specific test case can no longer be reproduced as of gcc-4.0.x (and
continuing to 4.1.x, 4.2.x, 4.3.x, and today's trunk.) 

This appears to be as a result of -std=gnu99 being required for these macros
visible. 

However, the issue returns for c++0x, as -std=gnu++0x makes these macros
visible by design, making the code ill-formed. This is confirmed by the
numerics parts of N2798, Table 113 where cmath has the following macros:

FP_FAST_FMA
FP_FAST_FMAF
FP_FAST_FMAL
FP_ILOGB0
FP_ILOGBNAN
FP_INFINITE
FP_NAN
FP_NORMAL
FP_SUBNORMAL
FP_ZERO
HUGE_VAL
HUGE_VALF
HUGE_VALL
INFINITY
NAN
MATH_ERRNO
MATH_ERREXCEPT
math_errhandling

Thus, I am going to close this as WONTFIX. For C++0x, the case is INVALID, and
for open gcc branches the bug status is FIXED.

Gaby, if I'm off on this please re-open. 

-benjamin


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   GCC host triplet||i686-pc-linux-gnu
  Known to work||4.0.4 4.1.2 4.2.4
 Resolution||WONTFIX


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

[Bug target/38952] [4.4 Regression] EH does not work.

[hjl at gcc dot gnu dot org]

--- Comment #23 from hjl at gcc dot gnu dot org  2009-01-26 23:39 ---
Subject: Bug 38952

Author: hjl
Date: Mon Jan 26 23:39:02 2009
New Revision: 143689

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143689
Log:
2009-01-26  H.J. Lu  

PR target/38952
* g++.dg/torture/stackalign/test-unwind.h (main): Also return 0
if __USING_SJLJ_EXCEPTIONS__ is defined.

* g++.dg/torture/stackalign/unwind-0.C (foo): Don't define if
__USING_SJLJ_EXCEPTIONS__ is defined.
* g++.dg/torture/stackalign/unwind-1.C (foo): Likewise.
* g++.dg/torture/stackalign/unwind-2.C (foo): Likewise.
* g++.dg/torture/stackalign/unwind-3.C (foo): Likewise.
* g++.dg/torture/stackalign/unwind-4.C (foo): Likewise.
* g++.dg/torture/stackalign/unwind-5.C (foo): Likewise.
* g++.dg/torture/stackalign/unwind-6.C (foo): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h
trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-0.C
trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-1.C
trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-2.C
trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-3.C
trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-4.C
trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-5.C
trunk/gcc/testsuite/g++.dg/torture/stackalign/unwind-6.C


-- 


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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[bkoz at gcc dot gnu dot org]

--- Comment #30 from bkoz at gcc dot gnu dot org  2009-01-26 23:31 ---

This appears to have been fixed in the gcc-4.3.0 time frame. At least,
gcc-4.2.4 has:

dependency_libs='
-L/mnt/share/bld/gcc-4.2.4/x86_64-unknown-linux-gnu/libstdc++-
v3/src
-L/mnt/share/bld/gcc-4.2.4/x86_64-unknown-linux-gnu/libstdc++-v3/src/.lib
s -lm -lm -lm -L/mnt/share/bld/gcc-4.2.4/./gcc -L/lib/../lib64
-L/usr/lib/../lib
64 -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc -lgcc_s  '

while gcc-4.3.x/4.4.x/trunk have:

dependency_libs=' -lm'

So, I'm changing to "FIXED" with a target milestone of 4.3.0.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/35022] [4.3/4.4 regression] ICE with parameter pack in template constant parameter

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-01-26 23:25 
---
I see, thanks for the missing pointer.


-- 


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

[Bug fortran/38914] ICE with array inquiry functions above contains in parameter expression

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2009-01-26 22:50 ---
> Here's something that at least passes all the *bound* tests.

Regression test passed - formal submission of the patch tomorrow,
probably. 


-- 


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

[Bug c++/35022] [4.3/4.4 regression] ICE with parameter pack in template constant parameter

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2009-01-26 22:31 ---
I approved that patch back in March, but it turned out not to be the right fix:
see

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


-- 


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

[Bug target/38952] [4.4 Regression] EH does not work.

[hjl dot tools at gmail dot com]

--- Comment #22 from hjl dot tools at gmail dot com  2009-01-26 22:29 
---
(In reply to comment #18)
> Created an attachment (id=17183)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183&action=view) [edit]
> Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE.
> 
> Now testing this patch which should fix setjmp calculations of the frame base
> pointer without affecting the way ordinary stack local variable slots are
> computed.
> 

I investigated C++ failures with --enable-sjlj-exceptions on Linux/Intel64

http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02626.html

All of them are expected. This looks good to me.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com


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

[Bug c++/35022] [4.3/4.4 regression] ICE with parameter pack in template constant parameter

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-01-26 21:12 
---
Jason, can you maybe review Doug's patch linked in Comment #2? Thanks!


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug fortran/38914] ICE with array inquiry functions above contains in parameter expression

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2009-01-26 21:04 ---
Created an attachment (id=17186)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17186&action=view)
patch

Here's something that at least passes all the *bound* tests.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug testsuite/38949] Link failures in new stackalign tests

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2009-01-26 20:34 ---
Subject: Bug 38949

Author: hjl
Date: Mon Jan 26 20:34:09 2009
New Revision: 143684

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143684
Log:
2009-01-26  Danny Smith  

PR testsuite/38949
* g++.dg/torture/stackalign/test-unwind.h (ASMNAME): Define.
Use instead of C name in asm statements.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h


-- 


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

[Bug c++/38980] New: missing -Wformat warning on const char format string

[sebor at roguewave dot com]

When compiled with gcc 3.4.6 with -m32 on x86_64 Linux the compiler flags lines
7, 10, and 13 as expected. But when compiled with gcc 4.3.1, only line 7 is
diagnosed.

$ cat -n t.cpp && g++ -dumpversion && g++ -Wformat -m32 -c t.cpp
 1  #include 
 2
 3  void foo (size_t n)
 4  {
 5  char buf [32];
 6
 7  sprintf (buf, "%" "l" "u", n);
 8
 9  static const char fmt0[] = "%" "l" "u";
10  sprintf (buf, fmt0, n);
11
12  const char fmt1[] = "%" "l" "u";
13  sprintf (buf, fmt1, n);
14
15  static char fmt2[] = "%" "l" "u";
16  sprintf (buf, fmt2, n);
17
18  char fmt3[] = "%" "l" "u";
19  sprintf (buf, fmt3, n);
20  }
3.4.6
t.cpp: In function `void foo(size_t)':
t.cpp:7: warning: long unsigned int format, size_t arg (arg 3)
t.cpp:10: warning: long unsigned int format, size_t arg (arg 3)
t.cpp:13: warning: long unsigned int format, size_t arg (arg 3)
$
$ g++ -dumpversion && g++ -Wformat -m32 -c  t.cpp
4.3.1
t.cpp: In function 'void foo(size_t)':
t.cpp:7: warning: format '%lu' expects type 'long unsigned int', but argument 3
has type 'size_t'
$


-- 
   Summary: missing -Wformat warning on const char format string
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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

[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables

[dj at redhat dot com]

--- Comment #3 from dj at redhat dot com  2009-01-26 19:46 ---
Subject: Re:   New: libiberty make_relative_prefix_1 mistakes directories for
executables


Your code conditionally includes  but doesn't
conditionally enable the other code.  If sys/stat.h isn't found,
perhaps the code could revert to the old access() code?


-- 


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

[Bug other/38920] dw2 exceptions don't work.

[pluto at agmk dot net]

--- Comment #8 from pluto at agmk dot net  2009-01-26 19:31 ---
(In reply to comment #7)
> AFAICT DW2 unwind has never worked on x86_64-mingw32, which is why Kai made
> sjlj the default EH model for that target.
> http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00273.html

ok, with sjlj and shared libgcc exceptions seem to work across dlls.


-- 


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

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-26 19:28 ---
! Test XFAILed on these platforms because the system's printf() lacks
! proper support for denormalized long doubles. See PR24685


Looks like this testcase should be xfailed on solaris also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|fortran |testsuite


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

[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used uninitialized' warning (CCP)

[pinskia at gcc dot gnu dot org]

--- Comment #21 from pinskia at gcc dot gnu dot org  2009-01-26 19:27 
---
*** Bug 38945 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fredrik at hederstierna dot
   ||com


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

[Bug c/38945] No warning when using uninitialized variable

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-26 19:27 ---
Yes this is a dup of bug 18501.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-26 19:23 ---
*** Bug 37995 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mvanier at cs dot caltech
   ||dot edu


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

[Bug c/37995] using fails if gcc invoked in a directory which has a subdirectory called "gcc"

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2009-01-26 19:23 
---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/38959] Additional switches to disallow processor supplementary instructions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-26 19:15 ---
I think this is a bad idea.  Also most if not all x86 CPUs released in the last
10 years support these instructions


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|inline-asm  |target


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

[Bug c++/38962] using declaration doesn't control accessibility in template

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-26 19:13 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/30195] Using declaration doesn't work in template.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-26 19:13 ---
*** Bug 38962 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jm at bourguet dot org


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

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-01-16 19:23:08 |2009-01-26 19:10:35
   date||


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

[Bug middle-end/38972] Failed constant folding and propagation in arithmetic expression.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-26 19:09 ---
To mark as fixed for 4.0.0.  This has been fixed for a while now.  Most likely
the gimplifier fixes it.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
   Keywords||wrong-code
  Known to work||4.0.1
 Resolution||FIXED
   Target Milestone|4.3.0   |4.0.0


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

[Bug libstdc++/38916] auto_ptr_ref conversion incorrectly releases ownership

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-01-26 19:08 
---
Ok, take your time. For the reasons we already discussed we don't want to rush
on this, in the meanwhile I will also try to collect more information.


-- 


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

[Bug c/38972] Failed constant folding and propagation in arithmetic expression.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-26 19:06 ---
Reopening to ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug target/38952] [4.4 Regression] EH does not work.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #21 from dave dot korn dot cygwin at gmail dot com  2009-01-26 
19:03 ---
  Hi Joey, thanks for helping look at this bug.

  If you catch up with all the comments, you'll see that it's not just Cygwin,
SjLj was broken on Linux too; the mechanism works the same way on both, but
only Cygwin uses it as the default EH mechanism, so it doesn't get as much
testing!

  I'm fairly confident I've analyzed the problem correctly and that the patch
I'm testing (attached, and submitted to gcc-patches at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01258.html) is the right solution
to the problem, and my PC is running through all the regression tests now, so
what would help most is if you could just look over my analysis and tell me if
you think I've got the right understanding of your code and the loophole that
caused the bug.

  cheers,
DaveK


-- 


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

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-01-26 18:50 ---
*** Bug 38947 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matevz dot tadel at cern dot
   ||ch


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

[Bug fortran/38947] Request for extension allowing usage of equivalence statement for threadprivate data

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-01-26 18:50 ---
Closing this as dupe as the other PR has the same plus additional information.

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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
 Resolution||DUPLICATE


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

[Bug target/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

[dave dot korn dot cygwin at gmail dot com]

--- Comment #8 from dave dot korn dot cygwin at gmail dot com  2009-01-26 
18:49 ---
Oh, bah, I misread the Host field for Target!

Guess it probably won't be TARGET_BUILTIN_SETJMP_FRAME_VALUE then.  You only
need it if your stack frames have unpredicatable gaps in them so that you can't
eliminate one reg against another that points the other side of the gap because
the offset isn't known.  Unless you've got those on CRIS, I've probably just
been dangling a red herring under your nose, sorry!


-- 


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

[Bug libstdc++/38916] auto_ptr_ref conversion incorrectly releases ownership

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2009-01-26 18:42 ---
Paolo, the person who reported the problem to me is no longer with IBM.  I've
asked others in the same group to provide information about the origins of the
test and what implementations are known to pass it, but it might take a long
time to get that info.


-- 


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

[Bug fortran/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[mikael at gcc dot gnu dot org]

--- Comment #4 from mikael at gcc dot gnu dot org  2009-01-26 18:42 ---
(In reply to comment #3)
> This is not so much an error in Fortran than it is an error in the
> scripting and it's ability to add it's own LD_LIBRARY_PATH components.
No. The current linking scheme links to the just-built libgfortran, not to the
system libgfortran. This is fine, because it is the newly built library that we
want to test. 

> They worked last week.
Sure, this is a regression. 

> Here is my most recent test. Above you ask "Could you try before/after this"
> do you mean compile and run the Testuite on bothboth "r143461" and "r143463"?
Yes. But to save time you can update only fortran or libgfortran and narrow the
testsuite run to the failing tests using the RUNTESTFLAGS variable as explained
here http://gcc.gnu.org/wiki/TestCaseWriting
Furthermore, as your tests show that the failure is in the libgfortran, there
is only one commit in that area in the window you gave (r143454-r143562): 


r143541 | domob | 2009-01-21 14:34:55 +0100 (mer. 21 janv. 2009) | 29 lines

I don't know though how this could cause system-dependent failures :-(. Daniel?

> Thanks for fixing this,
Thanks for helping to fix this. 


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gcc trunk 143562 - Testsuite|[trunk regression] gcc trunk
   |- gfortran failing tests|143562 - Testsuite -
   |that worked previously  |gfortran failing tests that
   ||worked previously


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

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-01-26 18:42 ---
Note: The standard does not allow this, see
http://www.openmp.org/mp-documents/spec30.pdf, page 94: Section "2.9.2
threadprivate Directive" has under "Restrictions":

"A variable can only appear in a threadprivate directive in the scope in which
it is declared. It must not be an element of a common block or appear in an 
EQUIVALENCE statement."

I don't see any fundamental problem with allowing it thus simply removing the
check should work - but I have not tested it.

I think one should not silently accept it; as there is no -fopenmp-std=legacy
option, I think the easiest would be to generate a warning such as:

  Warning: OpenMP extension: THREADPRIVATE for EQUIVALENCEd variable


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|OpenMP extension:   |OpenMP extension:
   ||THREADPRIVATE for
   ||EQUIVALENCEd symbols


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

[Bug fortran/38979] New: OpenMP extension:

[burnus at gcc dot gnu dot org]

See also:
http://gcc.gnu.org/ml/fortran/2009-01/msg00308.html

Seemingly, a lot of the OpenMP-supporting compilers support THREADPRIVATE for
EQUIVALENCEd symbols; at least Intel's ifort, SUN's sunf95, Open64's openf95,
Pathscale's pathf95 and Portland's pgf95 compile the program listed at

gfortran rejects it with:
  Error: EQUIVALENCE attribute conflicts with THREADPRIVATE attribute

!-
c
  subroutine strainx(x,volo,v,lft,llt,volf,vlim)
c
c

  dimension x1(1), vx1(1)
  integer nlq
  parameter (nlq=544)
  integer nnlq,lq9,lq0,lq1
  common/newnlq/nnlq,lq9,lq0,lq1
  common/aux33loc/ix1(nlq),ix2(nlq),ix3(nlq),ix4(nlq),ix5(nlq),
 1 ix6(nlq),ix7(nlq),ix8(nlq),mxt(nlq)
c
  dimension x(3,*),v(3,*),volo(nlq),volf(*),vlim(*)
  dimension ixx(nlq,8),posn(nlq,8,3),posv(nlq,8,3)
  equivalence (ixx(1,1),ix1(1)),(posn(1,1,1),x1(1))
 &  ,(posv(1,1,1),vx1(1))
c
c   Gather xJ,yJ,zJ(J=1,8)
c$omp thread private (/aux33loc/)
  do node=1,8
  do i=lft,llt
  posn(i,node,1)=x(1,ixx(i,node))
  posn(i,node,2)=x(2,ixx(i,node))
  posn(i,node,3)=x(3,ixx(i,node))
  enddo
  enddo
c
  return
  end


-- 
   Summary: OpenMP extension:
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  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=38979

[Bug c++/23287] [4.2/4.3 regression] Explicitly invoking destructor of template class in a template and is dependent

[jason at gcc dot gnu dot org]

--- Comment #24 from jason at gcc dot gnu dot org  2009-01-26 18:24 ---
Subject: Bug 23287

Author: jason
Date: Mon Jan 26 18:24:45 2009
New Revision: 143682

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143682
Log:
PR c++/23287
* parser.c (cp_parser_unqualified_id): In a template,
accept ~identifier.
* typeck.c (lookup_destructor): Handle IDENTIFIER_NODE.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/dtor5.C
  - copied unchanged from r143502,
trunk/gcc/testsuite/g++.dg/template/dtor5.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/cp/typeck.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/38646] [4.3/4.4 regression] ICE with invalid specialization of variadic template

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-01-26 18:20 
---
I'm having a look into this one...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-12-27 23:36:15 |2009-01-26 18:20:47
   date||


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl at gcc dot gnu dot org]

--- Comment #31 from hjl at gcc dot gnu dot org  2009-01-26 18:14 ---
Subject: Bug 36443

Author: hjl
Date: Mon Jan 26 18:13:58 2009
New Revision: 143681

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143681
Log:
2009-01-26  H.J. Lu  

Backport from mainline:
2008-07-17  H.J. Lu  

PR testsuite/36443
* objc.dg/gnu-encoding/gnu-encoding.exp: Temporarily unset
GCC_EXEC_PREFIX from environment when running $HOSTCC.

Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp


-- 


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

[Bug rtl-optimization/38969] [4.3/4.4 Regression] -foptimize-sibling-calls generates wrong code on alpha

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-01-26 17:22 ---
This is generic RTL optimization problem.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

  Component|c   |rtl-optimization


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

[Bug c/38969] [4.3/4.4 Regression] -foptimize-sibling-calls generates wrong code on alpha

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-01-26 17:20 ---
Following patch fixes this problem:

--cut here--
Index: calls.c
===
--- calls.c (revision 143671)
+++ calls.c (working copy)
@@ -992,7 +992,6 @@ initialize_argument_information (int num
&& targetm.calls.split_complex_arg (argtype))
  {
tree subtype = TREE_TYPE (argtype);
-   arg = save_expr (arg);
args[j].tree_value = build1 (REALPART_EXPR, subtype, arg);
j += inc;
args[j].tree_value = build1 (IMAGPART_EXPR, subtype, arg);
--cut here--

This testcase triggered sibcall_failure in the loop inside expand_call
function. We expanded complex argument during sibcall sequence expansion and
due to sibcall_failure, we throw produced sequence away.

Since the complex argument was wrapped in SAVE_EXPR, we were not able to
correctly expand function argument during second pass. The argument was already
expanded to a temporary, but the initialization of a temporary was discarded...

This worked in gcc-4.2 (it produces the same initial RTL sequence as unpatched
gcc-4.3/gcc-4.4) since no later pass initializes unintialized registers to
zero. This functionality was introduced by dataflow merge and this bug was
_exposed_ by the merge.

Regression test is in progress...


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

Summary|-foptimize-sibling-calls|[4.3/4.4 Regression] -
   |generates wrong code on |foptimize-sibling-calls
   |alpha   |generates wrong code on
   ||alpha
   Target Milestone|--- |4.3.4


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

--- Comment #8 from bonzini at gnu dot org  2009-01-26 16:48 ---
I disagree with this:

> working around these issues where they pop up is the way
> to go in the near future.

I think we need to be a bit more ambitious, and that does not mean separating
overflow/non-overflow tree codes.  For example in Eric's testcase, the way to
go would have been not to reassociate if there was a TREE_OVERFLOW on resulting
constant operands.  It might even be as easy as

  if (con0 && TREE_OVERFLOW (con0))
return NULL_TREE;

(search for "con0 =" in fold-const.c to get the context).

For 4.5, I suggest applying Jakub's patch very early and fixing bugs that
result.  If it turns out it's a huge Pandora's box, we can always re-revert the
patch.


-- 


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

[Bug inline-asm/23200] [4.2/4.3/4.4 Regression] rejects "i"(&var + 1)

[amacleod at redhat dot com]

--- Comment #40 from amacleod at redhat dot com  2009-01-26 16:16 ---
Created an attachment (id=17185)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17185&action=view)
possible patch

The problem is due to a check that was added to is_replaceable_p() in
tree-ssa-ter.c.  I presume this was added by Honza back in

2008-07-19  Jan Hubicka  
  (is_replaceable_p): Check that locations match; when aliasing
is missing be conservative about loads.

The check is:

   if (!optimize
  && ((locus1 && locus1 != locus2) || (block1 && block1 != block2)))
return false;

The locus's do not compare equal. This is presumably due to Aldy's enhanced
column information which can easily create different locus's for things that
are on the same line.

I presume this check is an attempt to preserve debug information at some level
by not merging expressions from different lines?   Honza will have to verify
this assumption.  I'm also unsure about why blocks for the locus's are compared
at the end of the expression.  There is a check to make sure the 2 expressions
are in the same block a few lines above, so why the locus block check as well? 
Shouldn't just locus comparing be sufficient?

In any case, if the locus block's are not checked, and the locus line numbers
are compared if *both* are valid, then the test case work.  With -ftree-ter of
course.

Honza will have to comment on the intent and rationale however, there may be
other reasons for that code.

A secondary question, why is TER turned off by default with this check in
place? It shouldn't destroy any critical debug info if only things that
originated on the same line are merged...   And on that note, I've added making
TER not lose locus's high on my todo list. There is nothing inherent in it that
would lose locus info, so I'm presuming there is an oversight in there
somewhere.  IS that the only problem with TER as far as -O0 goes?


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2009-01-26 16:07 ---
Subject: Re:  [4.3/4.4 Regression] ICE in set_value_range,
 at tree-vrp.c:398

On Mon, 26 Jan 2009, jakub at gcc dot gnu dot org wrote:

> --- Comment #6 from jakub at gcc dot gnu dot org  2009-01-26 16:02 ---
> That brings us back to http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00532.html
> If the gimplifier shouldn't drop TREE_OVERFLOW bits from the IL, then it is
> valid to have TREE_OVERFLOWs set and tree-vrp.c needs to deal with it (use
> VARYING range or something similar).

Not exactly.  Your patch was correct in principle but exposed latent
bugs elsewhere.  Difficult ones, because fold is shared between FEs
and the middle-end and fold and the FEs _do_ care about TREE_OVERFLOW.

...

So indeed, working around these issues where they pop up is the way
to go in the near future.

(this doesn't mean a TREE_OVERFLOW in the IL is valid ...)

Richard.


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-01-26 16:02 ---
That brings us back to http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00532.html
If the gimplifier shouldn't drop TREE_OVERFLOW bits from the IL, then it is
valid to have TREE_OVERFLOWs set and tree-vrp.c needs to deal with it (use
VARYING range or something similar).


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[rguenther at suse dot de]

--- Comment #5 from rguenther at suse dot de  2009-01-26 15:57 ---
Subject: Re:  [4.3/4.4 Regression] ICE in set_value_range,
 at tree-vrp.c:398

On Mon, 26 Jan 2009, bonzini at gnu dot org wrote:

> --- Comment #4 from bonzini at gnu dot org  2009-01-26 15:56 ---
> > This only happens with 32bit HWI.
> 
> Does this mean it is a front-end bug that TREE_OVERFLOW is set?

Yes.  In general TREE_OVERFLOW leaking into the IL is always a bug.

Richard.


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2009-01-26 15:56 ---
> This only happens with 32bit HWI.

Does this mean it is a front-end bug that TREE_OVERFLOW is set?


-- 


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

[Bug middle-end/38932] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

--- Comment #19 from bonzini at gnu dot org  2009-01-26 15:54 ---
fixed on 4.3 branch too.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.2.3 4.4.0 |4.2.3 4.4.0 4.3.4
 Resolution||FIXED


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

[Bug middle-end/38932] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gcc dot gnu dot org]

--- Comment #18 from bonzini at gnu dot org  2009-01-26 15:54 ---
Subject: Bug 38932

Author: bonzini
Date: Mon Jan 26 15:54:18 2009
New Revision: 143677

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143677
Log:
gcc:
2008-01-26  Paolo Bonzini  

PR tree-optimization/38932
* fold-const.c (fold_unary_ignore_overflow): New.
* tree.h (fold_unary_ignore_overflow): Declare.
* tree-ssa-ccp.c (ccp_fold): Use fold_unary_ignore_overflow.
* tree-ssa-sccvn.c (simplify_unary_expression): Likewise.

gcc/testsuite:
2008-01-26  Paolo Bonzini  

PR tree-optimization/38932
* gcc.dg/pr38932.c: New.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr38932.c
  - copied unchanged from r143588, trunk/gcc/testsuite/gcc.dg/pr38932.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-ccp.c
branches/gcc-4_3-branch/gcc/tree-ssa-sccvn.c
branches/gcc-4_3-branch/gcc/tree.h


-- 


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

[Bug middle-end/38978] [4.4 Regression] g++.dg/torture/pr36191.C

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-26 15:51 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/38978] New: [4.4 Regression] g++.dg/torture/pr36191.C

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 143673 gave:

FAIL: g++.dg/torture/pr36191.C  -O2  (internal compiler error)
FAIL: g++.dg/torture/pr36191.C  -O2  (test for excess errors)
FAIL: g++.dg/torture/pr36191.C  -O3 -fomit-frame-pointer  (internal compiler
error)
FAIL: g++.dg/torture/pr36191.C  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: g++.dg/torture/pr36191.C  -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr36191.C  -O3 -g  (test for excess errors)

Revision 143664 is OK. It is caused by either revision 143672:

http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00685.html

or revision 143673:

http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00686.html


-- 
   Summary: [4.4 Regression]  g++.dg/torture/pr36191.C
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2009-01-26 15:03 
---
Subject: Bug 38745

Author: rguenth
Date: Mon Jan 26 15:03:30 2009
New Revision: 143676

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143676
Log:
2009-01-26  Richard Guenther  

PR tree-optimization/38745
* tree-ssa-alias.c (update_alias_info_1): Exclude RESULT_DECL
from special handling.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-alias.c


-- 


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

[Bug tree-optimization/38968] Complex matrix product is not vectorized

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2009-01-26 14:23 ---
Subject: Re:  Complex matrix product is not
 vectorized

On Mon, 26 Jan 2009, howarth at nitro dot med dot uc dot edu wrote:

> --- Comment #5 from howarth at nitro dot med dot uc dot edu  2009-01-26 
> 14:21 ---
> Is the fix for this PR targeted for gcc 4.4.0 or gcc 4.5 stage 1?

stage1, it is an enhancement.

Richard.


-- 


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

[Bug tree-optimization/38968] Complex matrix product is not vectorized

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2009-01-26 
14:21 ---
Is the fix for this PR targeted for gcc 4.4.0 or gcc 4.5 stage 1?


-- 


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

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug c/38976] /pub/gcc/releases/gcc-4.3.3/md5.sum does not contain the md5sums for most of the bz2 archives

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-26 14:03:39
   date||


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

[Bug c/38976] /pub/gcc/releases/gcc-4.3.3/md5.sum does not contain the md5sums for most of the bz2 archives

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-26 13:58 ---
Interesting.  I have no idea who generates this md5.sum file.


-- 


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

[Bug tree-optimization/38968] Complex matrix product is not vectorized

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-26 13:25 ---
Patch posted.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||01/msg01271.html


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

[Bug tree-optimization/38968] Complex matrix product is not vectorized

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2009-01-26 13:09 ---
(In reply to comment #2)
> Now, I wonder why we do not just use alignment + misalign in that case.

I think you are right.


-- 


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

[Bug tree-optimization/38977] New: [4.4 Regression] bash no longer builds with profile-feedback

[rguenth at gcc dot gnu dot org]

I see

jobs.c: In function 'make_child':
jobs.c:4121: error: corrupted profile info: profile data is not flow-consistent
jobs.c:4121: error: corrupted profile info: number of executions for edge 10-11
thought to be -1726
jobs.c:4121: error: corrupted profile info: number of executions for edge 10-12
thought to be 1745
jobs.c:4121: error: corrupted profile info: number of iterations for basic
block 11 thought to be -120

this error did not exist in GCC 4.3.  In 4.4 -fprofile-correction was
introduced (not enabled by default) guarded with a new check in profile.c:

  /* Check for inconsistent basic block counts */
  inconsistent = is_inconsistent ();

  if (inconsistent)
   {
 if (flag_profile_correction)
   {
...
   }
 else
   error ("corrupted profile info: profile data is not flow-consistent");
   }

so we now unconditionally throw an error on something we ignored before.

IMHO we should either enable flag_profile_correction by default or
remove this error again.


-- 
   Summary: [4.4 Regression] bash no longer builds with profile-
feedback
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: major
  Priority: P3
 Component: tree-optimization
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=38977

[Bug target/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2009-01-26 12:46 ---
(In reply to comment #6)
>   Sounds like this could maybe be a dup of bug 38952, where the frame pointer
> is incorrectly calculated when setjmp saves it in the jmp_buf, and therefore
> restored to an incorrect value by longjmp.  For a quick test without 
> rebuilding
> your compiler, see if "-mpreferred-stack-boundary=2" or "-mno-stackrealign"
> fixes the failure in built-in-setjmp.c; if so there's a patch in the PR that
> should help.

I don't have those options :) and the stack-alignment options I have make no
difference - but I think you might on the right track.  I'll investigate
whether
this is just a sign of CRIS suffering from lack of
TARGET_BUILTIN_SETJMP_FRAME_VALUE.

Can't be a dup though, same target bug but different targets.
Fixing one won't fix the other. :)  Right, changing component to target.

Thanks!


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Component|middle-end  |target
   Last reconfirmed|2008-12-23 22:17:16 |2009-01-26 12:46:38
   date||


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

[Bug bootstrap/38971] RFE - Cloog .git is version "0.14.0" but gcc requires "0.15.0" (and our other problems with the cloog trunk)

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2009-01-26 12:36 ---
I was just going to post this and got a mid-air:

It is possible (and would be unfortunate) that gcc will only build with 
a 'special edition' cloog-ppl from: ftp://gcc.gnu.org/pub/gcc/infrastructure/ .

Thanks, if you can fix it so the '.git.' will work I am willing to test.

Rob


-- 


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

[Bug c/38976] New: /pub/gcc/releases/gcc-4.3.3/md5.sum does not contain the md5sums for most of the bz2 archives

[michael dot a dot richmond at nasa dot gov]

/pub/gcc/releases/gcc-4.3.3/md5.sum does not contain the md5sums for most of
the bz2 archives


-- 
   Summary: /pub/gcc/releases/gcc-4.3.3/md5.sum does not contain the
md5sums for most of the bz2 archives
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug ada/38975] New: deferred constants of not null access types are not possible

[Artem dot Andreev at oktetlabs dot ru]

The following does not compile:

package Test is
type X is new Positive;
type X_Access is not null access constant X;

Y : constant X_Access;
private
Y_Val : aliased constant X := 1;
Y : constant X_Access := Y_Val'Access;
end Test;

with the following diagnostics:
test.ads:6:09: warning: (Ada 2005) null-excluding objects must be initialized
test.ads:6:09: warning: "Constraint_Error" will be raised at run time
test.ads:11:09: "Y" conflicts with declaration at line 6

If "not null" modifier is removed, everything is fine.

As I can see from the following code, the semantic analyzer sees a deferred
constant and (erroneously) assumes that it's an uninitialized object. It then
inserts an implicit null initialization. And when it comes to a full definition
of the constant, the compiler thinks it has been already defined:

(gcc/ada/checks.adb, procedure Null_Exclusion_Static_Checks, line 2728):
 if K = N_Object_Declaration
and then No (Expression (N))
and then not No_Initialization (N)
  then
 --  Add an expression that assigns null. This node is needed by
 --  Apply_Compile_Time_Constraint_Error, which will replace this with
 --  a Constraint_Error node.

 Set_Expression (N, Make_Null (Sloc (N)));
 Set_Etype (Expression (N), Etype (Defining_Identifier (N)));

 Apply_Compile_Time_Constraint_Error
   (N  => Expression (N),
Msg=> "(Ada 2005) null-excluding objects must be initialized?",
Reason => CE_Null_Not_Allowed);
  end if;

The code can be traced back to at least gcc 4.1.2


-- 
   Summary: deferred constants of not null access types are not
possible
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Artem dot Andreev at oktetlabs dot ru


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

[Bug ada/38974] New: functions with controlling result do not work with synchronized interfaces

[Artem dot Andreev at oktetlabs dot ru]

The following example:

package Test is
   type X is limited interface;
   function Return_X return X is abstract;

   task type Y is new X with 
   end Y;
   overriding function Return_X return Y;
end Test;

does not compile with the following message:
test.ads:9:20: subprogram "Return_X" is not overriding.

As far as I can judge, it because of the following check in
gcc/ada/sem_util.adb (function Find_Overridden_Synchronized_Primitive,
line 3070):
...
   and then Etype (Result_Definition (Parent (Def_Id))) =
Etype (Result_Definition (Parent (Subp)))
...
(the code can be traced back to at least gcc 4.1.2)

I am not sure that this is indeed a bug in the compiler and not some obscure
feature of the standard, though I failed to find in the ARM any explicit
prohibition for controlling-result functions of synchronized types.


-- 
   Summary: functions with controlling result do not work with
synchronized interfaces
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Artem dot Andreev at oktetlabs dot ru


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

[Bug target/38952] [4.4 Regression] EH does not work.

[Joey dot ye at intel dot com]

--- Comment #20 from Joey dot ye at intel dot com  2009-01-26 11:49 ---
(In reply to comment #10)
> This is caused by stack alignment change, revision 138335. Joey and
> Xuepeng will look into it after holiday, Feb. 1.
This must be stack alignment change. Looks we didn't handle stack unwinding on
Cygwin correctly.

Dave, comparing the the EH mechanism in Linux, what's the difference of SjLj EH
in Cygwin? Answer to this question might help solving the problem sooner.

Thanks - Joey


-- 


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

[Bug web/38973] Missing feature documentation

[piotr dot wyderski at gmail dot com]

--- Comment #2 from piotr dot wyderski at gmail dot com  2009-01-26 11:30 
---
The website includes feature descriptions of the 4.4 mainline and even of some
branches (lambda, concepts). I consider this C++0x extension to be extremelly
useful, so IMHO the website should indicate at least partial support of it in
order to allow others start their experiments with it.


-- 


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

[Bug tree-optimization/38968] Complex matrix product is not vectorized

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-26 11:15 ---
This happens because ivcanon introduces an induction variable that counts
from 2000 to 1.  This "confuses" data-ref analysis and we get

base_address: a_24(D)
offset from base address: ()
(() pretmp.28_148 * 16000)
constant offset from base address: -15996
step: 8
aligned to: 128
base_object: IMAGPART_EXPR <(*a_24(D))[0]>
symbol tag: SMT.12

notice the negative constant offset from base address.  This in turn
confuses the vectorizer alignment analysis - but only because the alignment
of the base object is known.  We hit (with misalign == -15996, alignment == 16)

  /* Modulo alignment.  */
  misalign = size_binop (TRUNC_MOD_EXPR, misalign, alignment);

  if (!host_integerp (misalign, 1))
{
  /* Negative or overflowed misalignment value.  */
  if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, "unexpected misalign value");
  return false;
}

and the modulo is -12.

Now, I wonder why we do not just use alignment + misalign in that case.

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|2009-01-25 17:33:10 |2009-01-26 11:15:23
   date||


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

[Bug web/38973] Missing feature documentation

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-26 11:12 ---
Subject: Re:   New: Missing feature documentation



Sent from my iPhone

On Jan 26, 2009, at 2:35 AM, "piotr dot wyderski at gmail dot com"
 wrote:

> The website
>
> http://gcc.gnu.org/projects/cxx0x.html
>
> claims that the "New character types N2249"
> C++0x extension is not supported by any
> version of GCC. But GCC 4.4.0 supports the
> u8, u and U string prefixes. :-)
>
Well 4.4 has not been released yet so ...


>



> -- 
>   Summary: Missing feature documentation
>   Product: gcc
>   Version: 4.4.0
>Status: UNCONFIRMED
>  Severity: minor
>  Priority: P3
> Component: web
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: piotr dot wyderski at gmail dot com
>  GCC host triplet: GCC-4.4.0, Cygwin, Windows XP
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38973
>


-- 


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

[Bug c++/38064] [c++0x] operator== doesn't work for enum classes

[piotr dot wyderski at gmail dot com]

--- Comment #3 from piotr dot wyderski at gmail dot com  2009-01-26 10:48 
---
The bug is definitely confirmed and it still happens on GCC-4.4.0 trunk
(revision 143673).


-- 

piotr dot wyderski at gmail dot com changed:

   What|Removed |Added

 CC||piotr dot wyderski at gmail
   ||dot com


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

[Bug web/38973] New: Missing feature documentation

[piotr dot wyderski at gmail dot com]

The website

http://gcc.gnu.org/projects/cxx0x.html

claims that the "New character types N2249"
C++0x extension is not supported by any
version of GCC. But GCC 4.4.0 supports the
u8, u and U string prefixes. :-)


-- 
   Summary: Missing feature documentation
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
  GCC host triplet: GCC-4.4.0, Cygwin, Windows XP


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