[Bug c/47599] -fno-short-wchar does not force long wchar

[roucaries.bastien+bugs at gmail dot com]

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

--- Comment #2 from Bastien ROUCARIES  
2011-02-04 08:21:20 UTC ---
I disagree

wchar_t is a building type. Indeed L"aa" should expand to 16 bits packed char
with short wchar and 32 bits with no-short-wchar.

Due to the LNaaN constant specification wchar_t is more than a typedef stuff.

Bastien

[Bug c/47599] -fno-short-wchar does not force long wchar

[roucaries.bastien+bugs at gmail dot com]

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

--- Comment #3 from Bastien ROUCARIES  
2011-02-04 08:27:40 UTC ---
BTW i have checked the source code, and if my memory is correct wchar_t is
defined as
MODIFIED_WCHAR_T = fshortwchar ? "Short int" : WCHAR_T

Where wchar_t is defined by the architecture config.

The problem is under arch where WCHAR_T is "short int" this flag have no
effect. This flag should behave as short-enum where arch specify a default that
could be overwritten

Bastien

[Bug c/47599] -fno-short-wchar does not force long wchar

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2011-02-04 
08:33:03 UTC ---
It is a builtin type (for C++ it is exposed as the keyword, wchar_t). For C,
the headers define the type, see the preprocessed source to show that is the
case.

[Bug middle-end/47602] Permit inline asm to clobber PIC register

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #9 from Eric Botcazou  2011-02-04 
08:48:46 UTC ---
> I'm suggesting saving and restoring it around the asm statement itself, not in
> the prologue and epilogue.

Although the error was primarily RTH's idea, I still think it's very
reasonable.
When you write inline asm, you're expecting a certain degree of control over
the generated code; knowing that you're clobbering the PIC register can be
useful, especially on a register-starved architecture like the x86.  If you
stand by your clobbering, then writing the conditional save-and-restore code is
trivial.

[Bug c/47599] -fno-short-wchar does not force long wchar

[roucaries.bastien+bugs at gmail dot com]

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

--- Comment #5 from Bastien ROUCARIES  
2011-02-04 09:25:36 UTC ---
ok thanks it is defined in the header and in this case they are two bugs.

Try the following program

#include 
typedef __WCHAR_TYPE__ wchar_t;
wchar_t a[] = L"aa";
int s  = sizeof(wchar_t);

void main()
{
  printf("%i\n",s);
}

under linux it output 4
under linux with -fno-short-char it output 4
under linux with -fshort-char it output 2

under cygwin it output 2
nder linux with -fno-short-char it output 2 (BUG here)
under linux with -fshort-char it output 2

[Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  2011-02-04 09:32:01 
UTC ---
(In reply to comment #5)
> Realloc-on-assign for scalars was implemented in r169356.
> 
> Paul, what does it take to make this work for polymorphic scalars?

Not a lot, I think.  If you take a look in gfc_trans_allocate, there is a bit
that I think that you must have written, which initialises CLASS variables.  I
would have thought that this can be lifted and deposited wholesale in
trans_assignment1 and gfc_trans_allocate reconfigured to use the assignement.

I am taking a look at gfc_trans_allocate this lunchtime; there's something not
quite right structurally with it.  I attempted to add a patch of code to have a
single evaluation of the SOURCE expression and wound up displacing unrelated
declarations, when I added the se.post to the end of the main block. gimple did
not like it at all :-(  I'll come back to you.

Cheers

Paul

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

[ktietz at gcc dot gnu.org]

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

--- Comment #4 from Kai Tietz  2011-02-04 09:33:58 
UTC ---
Could you please check if this patch solves the issue for multilib? (It treats
multilib scenario like cross for installation of dll files).

Index: config.gcc
===
--- config.gcc  (revision 169824)
+++ config.gcc  (working copy)
@@ -1489,7 +1489,19 @@
fi
# Shared libgcc DLL install dir depends on cross/native build.
if test x${host} = x${target} ; then
-   tmake_dlldir_file="i386/t-dlldir"
+   # Are we building multilib version?
+   if test x$enable_targets = xall; then
+   case ${target} in
+   *-w64-*)
+   tmake_dlldir_file="i386/t-dlldir-x"
+   ;;
+   *)
+   tmake_dlldir_file="i386/t-dlldir"
+   ;;
+   esac
+   else
+   tmake_dlldir_file="i386/t-dlldir"
+   fi
else
tmake_dlldir_file="i386/t-dlldir-x"
fi

[Bug c/47599] -fno-short-wchar does not force long wchar

[roucaries.bastien+bugs at gmail dot com]

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

--- Comment #6 from Bastien ROUCARIES  
2011-02-04 09:39:02 UTC ---
I have checked with gcc -E the following program:

typedef __WCHAR_TYPE__ wchar_t;

under linux it output typedef int wchar_t
under linux with -fno-short-char it output typedef int wchar_t
under linux with -fshort-char it output typedef short unsigned int wchar_t

under cygwin it output typedef short unsigned int wchar_t
nder linux with -fno-short-char it output typedef short unsigned int wchar_t
(BUG)
under linux with -fshort-char it output typedef short unsigned int wchar_t

Bastien

[Bug c/47599] -fno-short-wchar does not force long wchar

[roucaries.bastien+bugs at gmail dot com]

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

--- Comment #7 from Bastien ROUCARIES  
2011-02-04 09:41:04 UTC ---
Sorry replace the last linux by cygwin

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

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

--- Comment #49 from Iain Sandoe  2011-02-04 10:21:27 
UTC ---
(In reply to comment #38)

> This would avoid the need for reverting r163267.

I'd rather not revert r163267 because of the behavior described in comment #35.

However, I think that libgcc_s.10.5.dylib must be interposed for the
-flat_namespace case, as described above. (i.e. patch in comment #24 +
Zforce_flat_namespace).

>  ps If I recall correctly, the Apple developers told me that they do 
> eventually
> intend to get rid of the linkage on -lgcc. Maybe that will happen in 10.7.

I intend to get rid of it ASAP - it is only used for eprintf on x86 and eprintf
+ FP saves on PPC. 
 -- I have patches to do this (but not for 4.6).

in test, is a patch that produces the library ordering per clang/4.2.1 for 10.6
- will post later.

[ you might want to re-check
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html would work with
-flat_namespace - it's not obvious how it resolves that issue].

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #3 from Mikael Pettersson  2011-02-04 
10:35:43 UTC ---
It's caused by 150953:

Author: ramana
Date: Thu Aug 20 08:09:29 2009
New Revision: 150953

URL: http://gcc.gnu.org/viewcvs?root=3Dgcc&view=3Drev&rev=3D150953
Log:
Fix twolf ICE for ARM

2009-08-19  Ramana Radhakrishnan  
Richard Earnshaw  

* config/arm/arm.c (arm_emit_movpair): Handle CONST_INT.
* config/arm/arm.md (*arm_movtas_ze): New pattern for
movt.

You're missing an "#:upper16:" annotation in the *arm_movtas_ze pattern, c.f.
the *arm_movt pattern.

(Not posting a patch since my renewed attempt to get a copyright assignment
seems to have ended up in /dev/null over at the FSF.)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

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

--- Comment #50 from Iain Sandoe  2011-02-04 10:52:38 
UTC ---
(In reply to comment #49)
> (In reply to comment #38)
> 
> [ you might want to re-check
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html would work with
> -flat_namespace - it's not obvious how it resolves that issue].

scratch that - I see it effectively does %L %G %L (which would be a more
conventional way to do what you've posted).  i.e. the patch in comment #17
(with no other changes).

*sigh*. if %L %G %L now apparently works - without Java regressions, then all
the effort to sort out pruning of early links to libSystem should be
irrelevant.  I guess bugs have been fixed in the 10.6.{5,6} releases.  

the (alternate) patch below produces (on 10.6.6):

$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/linkage.c -o tt -v
...
... -lgcc_ext.10.5 -no_compact_unwind -lSystem -lgcc -v

$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/linkage.c -o tt -v -flat_namespace
...
...  -lgcc_s.10.5 -lgcc_ext.10.5 -no_compact_unwind -lSystem -lgcc -v

$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/linkage.c -o tt -v
-mmacosx-version-min=10.5
...
... -macosx_version_min 10.5 ... -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lSystem -v

It seems to be OK on 10.6 for c++ tests.

*** However, if the patch at comment #17 works for all langs incl. Java *and*
-flat_namespace without regressions, then it is probably a better solution.  


Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h(revision 169811)
+++ gcc/config/darwin.h(working copy)
@@ -327,15 +332,19 @@ extern GTY(()) int darwin_ms_struct;
"%{static-libgcc|static: -lgcc_eh -lgcc;   \
   shared-libgcc|fexceptions|fgnu-runtime:   \
%:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)   \
-   %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+   %{Zflat_namespace|Zforce_flat_namespace:   \
+ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5);   \
+:%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
%:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)   \
%:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)   \
-   -lgcc ;   \
+   %:version-compare(< 10.6 mmacosx-version-min= -lgcc) ;   \
   :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
-   %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+   %{Zflat_namespace|Zforce_flat_namespace:   \
+ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5);   \
+:%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
%:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)   \
%:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)   \
-   -lgcc }"
+   %:version-compare(< 10.6 mmacosx-version-min= -lgcc) }"

 /* We specify crt0.o as -lcrt0.o so that ld will search the library path.

Index: gcc/config/darwin10.h
===
--- gcc/config/darwin10.h(revision 169811)
+++ gcc/config/darwin10.h(working copy)
@@ -21,5 +21,13 @@ along with GCC; see the file COPYING3.  If not see
 /* Fix PR41260 by passing -no_compact_unwind on darwin10 and later until
 unwinder in libSystem is fixed to digest new epilog unwinding notes. */

+/* Also ensure that the FSF static libgcc is linked last (unless the user
+   has specified -static-libgcc, in which case it will be linked earlier
+   by the REAL_LIBGCC_SPEC).  */
+
 #undef LIB_SPEC
-#define LIB_SPEC "%{!static:-no_compact_unwind -lSystem}"
+#define LIB_SPEC \
+"%{!static:\
+%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind)  \
+-lSystem \
+%:version-compare(>= 10.6 mmacosx-version-min= -lgcc) }"

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

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

--- Comment #51 from Iain Sandoe  2011-02-04 10:57:39 
UTC ---
(In reply to comment #37)
> Let me know when the dust settles and you guys agree on the path forward and I
> will decloak... I've been trying to avoid reading/understanding the issue...

yeah.. we'll get there - just a moderate number of permutations to cover.

In the end there might be a 'style call' required ;)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

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

--- Comment #52 from Jack Howarth  2011-02-04 
11:02:02 UTC ---
ain,
I think the key misassumption you are making is that the internal linker
and dyld behavior for 10.5 is valid under 10.6. Remember that unlike under
Leopard, where /usr/lib/libgcc_s.1.dylib is still a physically unique file...

[MacPro:Leopard HD/usr/lib] howarth% ls -l libgcc*
lrwxr-xr-x  1 howarth  howarth  16 Jul 24  2009 libgcc_s.1.0.dylib ->
libgcc_s.1.dylib
-rw-r--r--  1 howarth  howarth  264016 Oct  6  2007 libgcc_s.1.dylib
-rw-r--r--  1 howarth  howarth   33256 Feb 19  2008 libgcc_s.10.4.dylib
-rw-r--r--  1 howarth  howarth   33620 Feb 19  2008 libgcc_s.10.5.dylib
lrwxr-xr-x  1 howarth  howarth  16 Jul 24  2009 libgcc_s_ppc64.1.dylib ->
libgcc_s.1.dylib
lrwxr-xr-x  1 howarth  howarth  16 Jul 24  2009 libgcc_s_x86_64.1.dylib ->
libgcc_s.1.dylib

under 10.6, it is only a symlink for libSystem itself...

[MacPro:/usr/lib] howarth% ls -l libgcc*
lrwxr-xr-x  1 root  wheel 17 Nov  4 19:37 libgcc_s.1.dylib ->
libSystem.B.dylib
lrwxr-xr-x  1 root  wheel 19 Nov  4 20:32 libgcc_s.10.4.dylib ->
libgcc_s.10.5.dylib
-rwxr-xr-x  1 root  wheel  40668 Apr 23  2010 libgcc_s.10.5.dylib

So under -mmacosx-version-min=10.6, the linker and dyld only have to use the
magic symbols to properly disregard the duplicate symbols in the
libgcc_s.*.dylib symlinks. When these changes were designed, Apple likely
didn't consider that someone would come along with an additional
libgcc_s.1.dylib and start linking that in as well. We need to treat the
linkage of -lgcc_ext.10.5 under -mmacosx-version-min=10.6 as in the same
category as the linkage of -lgcc and wrapper it with -lSystem as well,

[Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2

[patrick.marlier at gmail dot com]

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

   Summary: [trans-mem] internal compiler error in expand_block_tm
with O2
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: r...@gcc.gnu.org, al...@gcc.gnu.org


Created attachment 23243
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23243
old testcase flavoured

I wanted to reopen this old bug but I can't since I am not the creator:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

Anyway, here a test case that raised again this with O2:
$ g++ -fgnu-tm -S -O2 -Wfatal-errors ICE_expand_block_tm.i 
ICE_expand_block_tm.i: In member function ‘void sp_counted_impl_p::dispose()
[with X = GradientInfo]’:
ICE_expand_block_tm.i:31:15: internal compiler error: in expand_block_tm, at
trans-mem.c:2323
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

It seems that even if the function atomic_exchange_and_add is declared
transaction_pure, gcc complains about the GIMPLE_ASM statement in
expand_block_tm.

Patrick Marlier.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

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

--- Comment #53 from Iain Sandoe  2011-02-04 11:26:14 
UTC ---
(In reply to comment #52)
> ain,
> I think the key misassumption you are making is that the internal linker
> and dyld behavior for 10.5 is valid under 10.6. Remember that unlike under
> Leopard, where /usr/lib/libgcc_s.1.dylib is still a physically unique file...
> 
> [MacPro:Leopard HD/usr/lib] howarth% ls -l libgcc*
> lrwxr-xr-x  1 howarth  howarth  16 Jul 24  2009 libgcc_s.1.0.dylib ->
> libgcc_s.1.dylib
> -rw-r--r--  1 howarth  howarth  264016 Oct  6  2007 libgcc_s.1.dylib
> -rw-r--r--  1 howarth  howarth   33256 Feb 19  2008 libgcc_s.10.4.dylib
> -rw-r--r--  1 howarth  howarth   33620 Feb 19  2008 libgcc_s.10.5.dylib
> lrwxr-xr-x  1 howarth  howarth  16 Jul 24  2009 libgcc_s_ppc64.1.dylib ->
> libgcc_s.1.dylib
> lrwxr-xr-x  1 howarth  howarth  16 Jul 24  2009 libgcc_s_x86_64.1.dylib ->
> libgcc_s.1.dylib
> 
> under 10.6, it is only a symlink for libSystem itself...

No, don't think I'm missing this ... if you read back through the comments, you
will see that I've already made the point ;)

> [MacPro:/usr/lib] howarth% ls -l libgcc*
> lrwxr-xr-x  1 root  wheel 17 Nov  4 19:37 libgcc_s.1.dylib ->
> libSystem.B.dylib
> lrwxr-xr-x  1 root  wheel 19 Nov  4 20:32 libgcc_s.10.4.dylib ->
> libgcc_s.10.5.dylib
> -rwxr-xr-x  1 root  wheel  40668 Apr 23  2010 libgcc_s.10.5.dylib
> 
> So under -mmacosx-version-min=10.6, the linker and dyld only have to use the
> magic symbols to properly disregard the duplicate symbols in the
> libgcc_s.*.dylib symlinks. When these changes were designed, Apple likely
> didn't consider that someone would come along with an additional
> libgcc_s.1.dylib and start linking that in as well. We need to treat the
> linkage of -lgcc_ext.10.5 under -mmacosx-version-min=10.6 as in the same
> category as the linkage of -lgcc and wrapper it with -lSystem as well,

well the 'magic symbols' are AFAICT undocumented.

However, the behaviors of two-level namespace and -flat_namespace are
documented.

Whilst it is quite possible that Apple were not expecting someone to add
libgcc_ext - it is no different than any other case where potential duplicates
are involved.  

Since 'magic symbols' are undocumented and we are speculating, my view is that
they are there so that, when you link -mmacosx-version-min=10.5 on a 10.6 box,
the result contains a reference to /usr/lib/libgcc_s.1.dylib for the Unwinder
symbols (because they do not exist in libSystem before 10.6).

(I suggest that we take any more discussion of magic symbols off-line since we
have no factual basis to decide at the moment)

[Bug lto/47607] New: FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

[amodra at gmail dot com]

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

   Summary: FAIL: gcc.c-torture/execute/builtins/abs-2.c
execution,  -O2 -flto
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com


Created attachment 23244
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23244
compile with -w -O2 -m32 -flto abs-2.i abs-2-lib.i main.i -lm

Fails due to "bl main_test" branching to a bogus location.  This is because the
only definition for main_test is one from the IR file, and ld doesn't check
that the symbol has been replaced with a real one.  With the patch in
http://sourceware.org/ml/binutils/2011-02/msg00037.html we get a linker error.

Reversing the order of inputs..
../gcc/xgcc -B ../gcc/ -w -O2 -m32 -flto main.i abs-2.i abs-2-lib.i -lm
lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:305

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

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

--- Comment #54 from Jack Howarth  2011-02-04 
12:02:18 UTC ---
Test results for proposed patch in Comment 45 at
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00416.html.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

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

--- Comment #55 from Jack Howarth  2011-02-04 
12:31:28 UTC ---
Moved conversation upstream for definitive answer from the Apple linker
developer...

http://lists.apple.com/archives/darwin-dev//2011/Feb/msg0.html

[Bug lto/47607] FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-02-04 
13:23:34 UTC ---
Do you have http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169785
fix in your tree (or tree later than that revision)?

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

[dongsheng.song at gmail dot com]

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

--- Comment #5 from Dongsheng Song  2011-02-04 
13:29:09 UTC ---
(In reply to comment #4)
> Could you please check if this patch solves the issue for multilib? (It treats
> multilib scenario like cross for installation of dll files).
> 
> Index: config.gcc
> ===
> --- config.gcc  (revision 169824)
> +++ config.gcc  (working copy)
> @@ -1489,7 +1489,19 @@
> fi
> # Shared libgcc DLL install dir depends on cross/native build.
> if test x${host} = x${target} ; then
> -   tmake_dlldir_file="i386/t-dlldir"
> +   # Are we building multilib version?
> +   if test x$enable_targets = xall; then
> +   case ${target} in
> +   *-w64-*)
> +   tmake_dlldir_file="i386/t-dlldir-x"
> +   ;;
> +   *)
> +   tmake_dlldir_file="i386/t-dlldir"
> +   ;;
> +   esac
> +   else
> +   tmake_dlldir_file="i386/t-dlldir"
> +   fi
> else
> tmake_dlldir_file="i386/t-dlldir-x"
> fi

Since the cross compiler building is OK, so I only tried the native compiler
building. I got the same wrong results.

My next complete building will be started at 23:50 PM(UTC), if I got different
answer, I will inform you.

[Bug pch/47584] [4.6 regression] internal compiler error: sigsegv in libcpp/line-map.c:285

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2011-02-04 
13:45:32 UTC ---
If this is an old problem, is it really a regression then?

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

[patrick.marlier at gmail dot com]

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

--- Comment #10 from Patrick Marlier  
2011-02-04 13:54:30 UTC ---
(In reply to comment #8)
> I will tackle the ECF_MALLOC comment separately.

Should I open up a new bug report for this? or is it already on your TODO list?

Patrick Marlier.

[Bug middle-end/47602] Permit inline asm to clobber PIC register

[ian at airs dot com]

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

--- Comment #10 from Ian Lance Taylor  2011-02-04 14:16:32 
UTC ---
What advantage do we bring to our users by requiring them to be aware of the
details of the PIC register when writing inline asm code?  Again, those who
*are* aware of the PIC register have complete control.  But many people are
able to write assembler code but have no idea what the PIC register is.  In
what way are we helping them by forcing them to know about it?  How does that
help them write inline assembler which, e.g., uses the cpuid instruction, or
makes a kernel system call which passes a parameter in %ebx?

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

[dongsheng.song at gmail dot com]

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

--- Comment #6 from Dongsheng Song  2011-02-04 
14:26:44 UTC ---
(In reply to comment #5)
> My next complete building will be started at 23:50 PM(UTC), if I got different
> answer, I will inform you.

OOPS, libgcc_s_sjlj-1.dll installed OK. But the other files installation is
wrong. 

oracle@vc:~/gcc-4.6-windows$ find . -name *.dll | grep -v pthread | sort
./bin/libgfortran-3.dll
./bin/libgomp-1.dll
./bin/libobjc-3.dll
./bin/libquadmath-0.dll
./bin/libssp-0.dll
./bin/libstdc++-6.dll
./lib64/libgcc_s_sjlj-1.dll
./lib/libgcc_s_sjlj-1.dll

PS: For windows users, I think 32bit DLLs should go to bin/, and 64bit DLLs
should
go to bin/64/ .

[Bug middle-end/47602] Permit inline asm to clobber PIC register

[sch...@linux-m68k.org]

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

--- Comment #11 from Andreas Schwab  2011-02-04 14:28:00 
UTC ---
If you are writing assembler code you need to know your ABI in and out.

[Bug lto/47607] FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Alan Modra  2011-02-04 14:28:21 
UTC ---
No, I was on 169779.  Updating to 169827 gives me a compiler that passes this
test.

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  2011-02-04 14:39:37 
UTC ---
Created attachment 23245
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23245
Next ICE

With your patch, the build fails earlier.  

$ m32c-rtems4.11-gcc  -mcpu=m32cm -g -O1 -c pr.c

$ m32c-rtems4.11-gcc  -mcpu=m32cm -g -O2 -c pr.c
pr.c: In function '_Heap_Initialize':
pr.c:4300:1: error: unable to find a register to spill in class 'A_REGS'
pr.c:4300:1: error: this is the insn:
(insn 119 118 120 12 (set (mem/s:SI (subreg:PSI (reg/f:SI 30 [ first_block.3 ])
0) [3 first_block.3_22->prev_size+0 S4 A8])
(reg/v:SI 28 [ heap_area_end ])) pr.c:4260 98 {movsi_24}
 (nil))
pr.c:4300:1: internal compiler error: in spill_failure, at reload1.c:2105
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #21 from dave at hiauly1 dot hia.nrc.ca 2011-02-04 14:42:39 UTC ---
> Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html
> 
> This is my previous janitorial patch, + a kludge which I believe should fix 
> the
> issue on HP-UX and other targets that support weak references but not weak
> undefined references.

Fixes build error on HP-UX.

Dave

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

[dj at redhat dot com]

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

DJ Delorie  changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #3 from DJ Delorie  2011-02-04 14:59:08 UTC 
---
That's odd.  Could you take my patch back out, and verify the problem goes back
to the original one?  My patch shouldn't be able to affect anything earlier...

[Bug middle-end/47602] Permit inline asm to clobber PIC register

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  2011-02-04 15:01:56 
UTC ---
(In reply to comment #10)
>
> what way are we helping them by forcing them to know about it?  How does that
> help them write inline assembler which, e.g., uses the cpuid instruction, or

Use  provided by gcc.

> makes a kernel system call which passes a parameter in %ebx?

You can use syscall () or take a look at the C library source
to see how system call is inlined.

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

[joel at gcc dot gnu.org]

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

--- Comment #4 from Joel Sherrill  2011-02-04 15:10:00 
UTC ---
(In reply to comment #3)
> That's odd.  Could you take my patch back out, and verify the problem goes 
> back
> to the original one?  My patch shouldn't be able to affect anything earlier...

Still fails with your patch backed out. Do you want to commit your patch and
let me file another pr for this one?

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

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

--- Comment #56 from Jack Howarth  2011-02-04 
15:11:29 UTC ---
The following works as a testcase for PR47558

test_main.c
--
void main (void)
{
extern int unwindcall(void);
int i;
i=unwindcall();
}
--

test_call.c
---
int unwindcall (void)
{
static __thread i; 
  i+i; 
  _Unwind_Resume ((void *)0); 
  return i;
}


./dist/bin/gcc -dynamiclib -o libtestcall.dylib -flat_namespace -undefined
suppress -single_module test_call.c
./dist/bin/gcc -o PR47558.exe test_main.c ./libtestcall.dylib

otool -L PR47558.exe
PR47558.exe:
libtestcall.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)

./PR47558.exe 
Abort

 gdb ./PR47558.exe 
GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Wed Sep 22 02:45:02 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries  done

(gdb) r
Starting program: /Users/howarth/PR47558.exe 
Reading symbols for shared libraries +++. done

Program received signal SIGABRT, Aborted.
0x7fff87c05616 in __kill ()
(gdb) bt
#0  0x7fff87c05616 in __kill ()
#1  0x7fff87ca5cca in abort ()
#2  0x0001000147a6 in uw_init_context_1 (context=0x7fff5fbfe5d0,
outer_cfa=0x7fff5fbfe800, outer_ra=0x13f75) at
../../../gcc/libgcc/../gcc/unwind-dw2.c:1265
(gdb)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

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

--- Comment #57 from Jack Howarth  2011-02-04 
15:16:42 UTC ---
For the testcase in Comment 56 using my proposed patch from Comment 45...

gcc-4 -dynamiclib -o libtestcall.dylib -flat_namespace -undefined suppress
-single_module test_call.c
gcc-4 -o PR47558.exe test_main.c ./libtestcall.dylib

otool -L ./PR47558.exe 
./PR47558.exe:
libtestcall.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.10)
/sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)

gdb ./PR47558.exe
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0010
0x7fff839d3c35 in _Unwind_Resume ()
(gdb) bt
#0  0x7fff839d3c35 in _Unwind_Resume ()
#1  0x00013f75 in unwindcall ()
#2  0x00010f7b in main ()

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

[dj at redhat dot com]

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

--- Comment #5 from DJ Delorie  2011-02-04 15:21:40 UTC 
---
See if one of these other changes caused the problem.  If so, yeah, I'll check
this one in and we'll work on the other one separately.  The new error you're
seeing is one I've seen on and off for years.

* config/m32c/m32c.h (PTRDIFF_TYPE): Remove extra definition.

* config/m32c/m32c.c (m32c_regno_reg_class): Return smallest reg
class for A0/A1.

[Bug middle-end/47602] Permit inline asm to clobber PIC register

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  2011-02-04 
15:23:22 UTC ---
> In what way are we helping them by forcing them to know about it?  How does
> that help them write inline assembler which, e.g., uses the cpuid instruction,
> or makes a kernel system call which passes a parameter in %ebx?

In these cases, that won't probably help them indeed.  But, in other cases,
like someone wanting to write very efficiently a hot loop in asm for a library,
making it explicit that the %ebx register is not freely available like the
others might help him to find the most efficient approach.  Maybe we could just
warn though.

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

[aldyh at gcc dot gnu.org]

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

--- Comment #11 from Aldy Hernandez  2011-02-04 
15:31:14 UTC ---
Patrick.  It's already on my TODO.  I'm working on it.

[Bug tree-optimization/43695] [4.5 Regression] ICE: verify_flow_info failed: BB 2 is missing an EH edge with -fipa-cp-clone

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[4.5/4.6 Regression] ICE:   |[4.5 Regression] ICE:
   |verify_flow_info failed: BB |verify_flow_info failed: BB
   |2 is missing an EH edge |2 is missing an EH edge
   |with -fipa-cp-clone |with -fipa-cp-clone

--- Comment #6 from Jakub Jelinek  2011-02-04 
15:31:37 UTC ---
Can't reproduce with r158250 or anything newer.

[Bug tree-optimization/43695] [4.5 Regression] ICE: verify_flow_info failed: BB 2 is missing an EH edge with -fipa-cp-clone

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2011-02-04 15:36:05 
UTC ---
We should add this testcase.

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

[jakub at gcc dot gnu.org]

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

--- Comment #47 from Jakub Jelinek  2011-02-04 
15:50:58 UTC ---
Author: jakub
Date: Fri Feb  4 15:50:51 2011
New Revision: 169831

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169831
Log:
PR inline-asm/23200
* tree-ssa-ter.c (is_replaceable_p): Add TER argument.  Don't
do bb, locus and block comparison and disallow loads if it is
not set.
(stmt_is_replaceable_p): New function.
(process_replaceable, find_replaceable_in_bb): Adjust is_replaceable_p
callers.
* expr.c (expand_expr_real_1) : If
get_gimple_for_ssa_name try for EXPAND_INITIALIZER harder to use
SSA_NAME_DEF_STMT.
* tree-flow.h (stmt_is_replaceable_p): New prototype.

* gcc.dg/pr23200.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr23200.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-flow.h
trunk/gcc/tree-ssa-ter.c

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Known to work||4.6.0
Summary|[4.3/4.4/4.5/4.6|[4.3/4.4/4.5 Regression]
   |Regression] rejects |rejects "i"(&var + 1)
   |"i"(&var + 1)   |
  Known to fail||4.3.5, 4.4.5, 4.5.2

--- Comment #48 from Jakub Jelinek  2011-02-04 
15:53:27 UTC ---
Fixed onthe trunk.

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

[ktietz at gcc dot gnu.org]

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

--- Comment #7 from Kai Tietz  2011-02-04 15:54:10 
UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > My next complete building will be started at 23:50 PM(UTC), if I got 
> > different
> > answer, I will inform you.
> 
> OOPS, libgcc_s_sjlj-1.dll installed OK. But the other files installation is
> wrong. 
> 
> oracle@vc:~/gcc-4.6-windows$ find . -name *.dll | grep -v pthread | sort
> ./bin/libgfortran-3.dll
> ./bin/libgomp-1.dll
> ./bin/libobjc-3.dll
> ./bin/libquadmath-0.dll
> ./bin/libssp-0.dll
> ./bin/libstdc++-6.dll
> ./lib64/libgcc_s_sjlj-1.dll
> ./lib/libgcc_s_sjlj-1.dll

Hmm, did you rebuild target libraries, or did you reused existing build-tree?

> PS: For windows users, I think 32bit DLLs should go to bin/, and 64bit DLLs
> should
> go to bin/64/ .

No. As agreement it is ok to install for a none-multilib native build the host
DLLs into bin. But for multilib it should go into lib. I dislike the feature of
installing host DLLs into bin folder pretty much.

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

[dongsheng.song at gmail dot com]

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

--- Comment #8 from Dongsheng Song  2011-02-04 
16:05:13 UTC ---
On Fri, Feb 4, 2011 at 23:54, ktietz at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142
>
> --- Comment #7 from Kai Tietz  2011-02-04 15:54:10 
> UTC ---
>> OOPS, libgcc_s_sjlj-1.dll installed OK. But the other files installation is
>> wrong.
>>
>> oracle@vc:~/gcc-4.6-windows$ find . -name *.dll | grep -v pthread | sort
>> ./bin/libgfortran-3.dll
>> ./bin/libgomp-1.dll
>> ./bin/libobjc-3.dll
>> ./bin/libquadmath-0.dll
>> ./bin/libssp-0.dll
>> ./bin/libstdc++-6.dll
>> ./lib64/libgcc_s_sjlj-1.dll
>> ./lib/libgcc_s_sjlj-1.dll
>
> Hmm, did you rebuild target libraries, or did you reused existing build-tree?
>

I rebuild gcc-4.6-windows, remove gcc build-tree, then configure and building.

PS: I preform the rebuilding ahead of time, remove the cross compiler,
third-party software, and native compiler,
a really fresh building, no good news.

[Bug target/31782] Invalid assembly code on initial dollar signs

[funto66 at gmail dot com]

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

funto66 at gmail dot com changed:

   What|Removed |Added

 CC||funto66 at gmail dot com

--- Comment #5 from funto66 at gmail dot com 2011-02-04 16:42:33 UTC ---
I think this is the same bug that I got :
- this code compiles :
#include 
int main(int argc, char* argv[])
{
int $a = 0;
for($a = 0 ; $a < 10 ; $a++)
printf("%d\n", $a);

return 0;
}


- this one doesn't :
#include 
int main(int argc, char* argv[])
{
static const char* $tr = "Hello World !\n";
int i=0;

for(;$tr[i] != '\0' ; i++)
fputc($tr[i], stdout);

return 0;
}

Version used: gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

[Bug tree-optimization/43695] [4.5 Regression] ICE: verify_flow_info failed: BB 2 is missing an EH edge with -fipa-cp-clone

[hjl at gcc dot gnu.org]

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

--- Comment #8 from hjl at gcc dot gnu.org  2011-02-04 
17:23:34 UTC ---
Author: hjl
Date: Fri Feb  4 17:23:30 2011
New Revision: 169835

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169835
Log:
Add a testcase for PR tree-optimization/43695.

2011-02-04  H.J. Lu  

PR tree-optimization/43695
* g++.dg/ipa/pr43695.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr43695.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/47608] New: libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly)

[ossman at cendio dot se]

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

   Summary: libstdc++ links to bad libgcc_s on OS X (libgcc_s
rebuilt needlessly and incorrectly)
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oss...@cendio.se


The problem I'm seeing is this:

/usr/lib/gcc/i686-apple-darwin9/4.4.3/../../../../i686-apple-darwin9/bin/ld:
warning can't open dynamic library:
/usr/i686-apple-darwin9/sys-root/libgcc_s.1.dylib referenced from:
/usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.dylib (checking for undefined
symbols may be affected) (No such file or directory, errno = 2)

If you notice the path to libgcc_s.1.dylib, you see that it is directly in the
sys-root. This is of course wrong, and we can see why by examining
libstdc++.dylib:

$ strings
/opt/cendio-build/arch/osx32/usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.dylib
| grep dylib
/usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.6.dylib
/usr/lib/libSystem.B.dylib
/libgcc_s.1.dylib
/usr/lib/libSystem.B.dylib
__mh_dylib_header

As you can see, it expects a path of / to libgcc_s. This is not however the
path stored in the installed libgcc_s:

strings
/opt/cendio-build/arch/osx32/usr/lib/gcc/i686-apple-darwin9/4.4.3/libgcc_s.1.dylib
| grep dylib
/usr/lib/gcc/i686-apple-darwin9/4.4.3/libgcc_s.1.dylib
/usr/lib/libSystem.B.dylib
__mh_dylib_header

After digging around in the gcc build system, I noticed that libgcc_s.1.dylib
is built twice. Once with the proper path (the one which gets installed), and
once with the broken path (the one that libstdc++.dylib seems to link against).
They end up in i686-apple-darwin9/libgcc/libgcc_s.1.dylib and
gcc/libgcc_s.1.dylib respectively in the build tree.

Digging further I believe I found the cause, and it is two-fold:

1.

The darwin specific SHLIB_LINK outputs libgcc_s.1.dylib.tmp (and eventually
libgcc_s.1.dylib also gets created). But the target for libgcc_s expects
libgcc_s.dylib to be created. From libgcc/Makefile.in:

libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts)
# @multilib_flags@ is still needed because this may use
# $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
$(mkinstalldirs) $(MULTIDIR)
$(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \
@multilib_dir@,$(MULTIDIR),$(subst \
@shlib_objs@,$(objects),$(subst \
@shlib_base_name@,libgcc_s,$(subst \
@shlib_map_file@,$(mapfile),$(subst \
@shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
@shlib_slibdir@,$(shlib_slibdir),$(SHLIB_LINK

2.

The rule for libgcc_s.dylib specifies $(extra-parts), which can resolve to
nothing or one of two phony targets. In the latter case (which I'm hitting),
make will always assume that things need to be rebuilt.


Because of either of the above bugs, the recipe will be executed once more when
this target hits:

all: all-multi
# Now that we have built all the objects, we need to copy
# them back to the GCC directory.  Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
$(MAKE) install-leaf DESTDIR=$(gcc_objdir) \
  slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)

In other words, libgcc_s.1.dylib will be recreated instead of just copied,
which I assume was the purpose of the above target. And it will be recreated
incorrectly as slibdir affects how the library is constructed.

(Bug 28910 might also be caused by this)

[Bug tree-optimization/46728] [4.6 Regression] GCC no longer generates fmadd for pow (x, 0.75)+y on powerpc

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  2011-02-04 
18:11:09 UTC ---
When the initial changes for bug 42694 was added that optimizes pow (x, 0.75)
into sqrt(sqrt(x))*sqrt(x) under fast math, there was a desire to move this RTL
optimization into the tree level.  Ideally it should before the vectorization
of math functions and FMA (floating point multiplication and add) passes.

Here is the discussion about the changes in April 2010:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00788.html

Presumably most of the optimizations done in expand_builtin_pow,
expand_builtin_powi and expand_builtin_pow_root in the builtins.c file should
be moved to a tree pass.

[Bug target/47608] libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly)

[ossman at cendio dot se]

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

--- Comment #1 from Pierre Ossman  2011-02-04 18:12:26 
UTC ---
Created attachment 23246
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23246
Hackish workaround

This is what I've done here to workaround the problem. Compiles fine, but I
haven't used to compiler enough to see if I caused any new bugs.

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  2011-02-04 18:30:41 
UTC ---
(In reply to comment #5)
> See if one of these other changes caused the problem.  If so, yeah, I'll check
> this one in and we'll work on the other one separately.  The new error you're
> seeing is one I've seen on and off for years.
> 
> * config/m32c/m32c.h (PTRDIFF_TYPE): Remove extra definition.
> 
> * config/m32c/m32c.c (m32c_regno_reg_class): Return smallest reg
> class for A0/A1.

It I back them off, I am back to the original ICE.

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

[aldyh at gcc dot gnu.org]

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

--- Comment #12 from Aldy Hernandez  2011-02-04 
18:40:09 UTC ---
Patrick, the reason memory allocated by the C++ new operator does not get
optimized by the TM-memopt pass is not because of a missing ECF_MALLOC
attribute, but because the alias oracle in GCC considers the chunk of memory as
possibly able to escape from the current function.

That is, the following hunk of code returns true in the TM-memopt pass:

  if (ptr_deref_may_alias_global_p (x))

Apparently, since new/delete operators may be overridden by class specific
hooks, the memory must be considered escaped.

So, this is not a TM bug, but a "feature" of the alias oracle in GCC.

[Bug target/47609] New: libstdc++ depends on libgcc_s.10.5 but gets linked to libgcc_s.10.4

[ossman at cendio dot se]

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

   Summary: libstdc++ depends on libgcc_s.10.5 but gets linked to
libgcc_s.10.4
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oss...@cendio.se


Not sure what's going on here, but I get this problem linking C++ programs:

/usr/lib/gcc/i686-apple-darwin9/4.4.3/../../../../i686-apple-darwin9/bin/ld:
Undefined symbols:
__Unwind_GetIPInfo
collect2: ld returned 1 exit status

Telling g++ to be verbose, I can see that it specifies -macosx_version_min 10.4
by default. Examining the different libgcc_s libraries though, I can see that
the 10.4 version doesn't include Unwind_GetIPInfo, only the 10.5 version does.

I'm not sure why the inconcistency here. The darwin9 target means 10.5, so that
might be why libstdc++ assumes it has access to Unwind_GetIPInfo. But then the
question is why 10.4 is still the default with the corresponding gcc/g++.

[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Depends on|35722   |

--- Comment #5 from Dodji Seketeli  2011-02-04 
19:53:24 UTC ---
Actually my previous analysis wasn't quite right. Rather, the
substitution of the fixed up U into std::remove_reference::type...,
fails. It fails because we fail to compare the fixed up U with the
non-fixed up U. And after that the sky falls.

So this has nothing to do with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722, luckily. Pheew.

A candidate patch was sent to to
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00295.html along with a
smaller reproducer.

[Bug middle-end/47610] New: [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[danglin at gcc dot gnu.org]

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

   Summary: [4.6 Regression] cp-demangle.c:1970:1: error:
cplus_demangle_builtin_types causes a section type
conflict
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
CC: ja...@redhat.com
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11


if [ x"-fPIC" != x ]; then \
  /test/gnu/gcc/objdir/./prev-gcc/xgcc
-B/test/gnu/gcc/objdir/./prev-gcc
/ -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.6.0
/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/lib/
-i
system /opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/
gcc/gcc-4.6.0/hppa64-hp-hpux11.11/sys-include-c -DHAVE_CONFIG_H -g -O2  -I.
-I../../gcc/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict
-prototypes -pedantic  -fPIC ../../gcc/libiberty/md5.c -o pic/md5.o; \
else true; fi
../../gcc/libiberty/cp-demangle.c:1970:1: error: cplus_demangle_builtin_types
ca
uses a section type conflict
make[3]: *** [cp-demangle.o] Error 1

# ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa64-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/opt/gnu64/gcc/gcc-4.6.0 --build=hppa64-hp-hpux11.11
--enable-threads=posix --disable-nls --with-gmp=/opt/gnu64/gcc/gcc-4.6.0
--with-libelf=/opt/gnu64 --enable-languages=c,c++,objc,obj-c++,fortran,lto
Thread model: posix
gcc version 4.6.0 20110204 (experimental) [trunk revision 169834] (GCC)

[Bug other/47554] [trans-mem] expand_expr_addr_expr_1 ICE

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Aldy Hernandez  2011-02-04 
20:10:12 UTC ---
Awaiting approval:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00296.html

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

[patrick.marlier at gmail dot com]

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

--- Comment #13 from Patrick Marlier  
2011-02-04 20:13:04 UTC ---
Hi Aldy,

On Fri, Feb 4, 2011 at 7:40 PM, aldyh at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941
>
> --- Comment #12 from Aldy Hernandez  2011-02-04
> 18:40:09 UTC ---
> Patrick, the reason memory allocated by the C++ new operator does not get
> optimized by the TM-memopt pass is not because of a missing ECF_MALLOC
> attribute, but because the alias oracle in GCC considers the chunk of
> memory as
> possibly able to escape from the current function.
>
>
I have added the "malloc" attribute to the declaration of the new operator
and it worked so I though this was it. After this I found a discussion about
adding malloc attribute to new operator...


> That is, the following hunk of code returns true in the TM-memopt pass:
>
>  if (ptr_deref_may_alias_global_p (x))
>
> Apparently, since new/delete operators may be overridden by class specific
> hooks, the memory must be considered escaped.
>

Hum I see. But if the new/delete operators are not overridden then the
returned memory could be marked as transaction local, right?
Otherwise at least a comment somewhere is welcome to be aware of this
behavior.


> So, this is not a TM bug, but a "feature" of the alias oracle in GCC.


Actually, this was not a bug but an improvement (why using costly write
barriers on transaction local memory).

As usual, thanks ;)

Patrick.

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

[aldyh at gcc dot gnu.org]

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

--- Comment #14 from Aldy Hernandez  2011-02-04 
20:16:07 UTC ---
Yes, this is an improvement, because once has to figure out why the unadultered
new operator is not handled specially by the alias oracle.  You are welcome to
file a PR as an enhancement request, but honestly I won't get to it anytime
soon, because of the other critical problems with the toolchain.

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.04 20:19:37
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-02-04 
20:19:37 UTC ---
Please provide preprocessed source, so I can try to reproduce it with a cross
compiler.

[Bug c++/47611] New: [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local

[patrick.marlier at gmail dot com]

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

   Summary: [trans-mem] memory allocated by default new/new_vec
operator can be considered as transaction local
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: r...@gcc.gnu.org, al...@gcc.gnu.org


This is an improvement with a *LOW* priority. Only if spare time (hey could be
a nice homework).

See comments in 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-02-04 20:28:03 UTC ---
On Fri, 04 Feb 2011, jakub at gcc dot gnu.org wrote:

> Please provide preprocessed source, so I can try to reproduce it with a cross
> compiler.

Attached.

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

[patrick.marlier at gmail dot com]

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

--- Comment #15 from Patrick Marlier  
2011-02-04 20:30:15 UTC ---
Filled a enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611

Yeah don't lose time of
this!


On Fri, Feb 4, 2011 at 9:16 PM, aldyh at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941
>
> --- Comment #14 from Aldy Hernandez  2011-02-04
> 20:16:07 UTC ---
> Yes, this is an improvement, because once has to figure out why the
> unadultered
> new operator is not handled specially by the alias oracle.  You are welcome
> to
> file a PR as an enhancement request, but honestly I won't get to it anytime
> soon, because of the other critical problems with the toolchain.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug tree-optimization/46886] [4.5/4.6 Regression] gfortran.dg/array_constructor_9.f90 FAILs with -ftree-parallelize-loops -fstrict-overflow -fno-tree-ch

[sebpop at gmail dot com]

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

--- Comment #4 from sebpop at gmail dot com  
2011-02-04 20:30:46 UTC ---
On Tue, Jan 18, 2011 at 11:00, jakub at gcc dot gnu.org
 wrote:
> Seems one extra incorrect iteration is added after GOMP_parallel_end:

That extra iteration is added by this call:

  /* Ensure that the exit condition is the first statement in the loop.  */
  transform_to_exit_first_loop (loop, reduction_list, nit);


/* Moves the exit condition of LOOP to the beginning of its header, and
   duplicates the part of the last iteration that gets disabled to the
   exit of the loop.  NIT is the number of iterations of the loop
   (used to initialize the variables in the duplicated part).

   TODO: the common case is that latch of the loop is empty and immediately
   follows the loop exit.  In this case, it would be better not to copy the
   body of the loop, but only move the entry of the loop directly before the
   exit check and increase the number of iterations of the loop by one.
   This may need some additional preconditioning in case NIT = ~0.
   REDUCTION_LIST describes the reductions in LOOP.  */

static void
transform_to_exit_first_loop (struct loop *loop, htab_t
reduction_list, tree nit)

[Bug rtl-optimization/47612] New: RTL crash when cc0 setter moved away from cc0 user

[ian at airs dot com]

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

   Summary: RTL crash when cc0 setter moved away from cc0 user
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@airs.com


Consider this C file:

extern void e (int) __attribute__ ((noreturn));
void
f (char *p, int a, int b, int c)
{
  int i, j;

  j = 0;
  for (i = 0; i < 10; ++i)
{
  switch (a)
{
case 0:
  p[i] = 0;
  break;
case 1:
  if (c == 1)
{
  if (j < 0 | b <= j)
e (0);
  p[j] = 0;
}
  else
{
  if (j < 0 | b <= j)
e (0);
  p[j] = 0;
}
  j++;
}
}
}

When I use a compiler built for the m68k-rtems4.11 target, the compiler crashes
when I compile this file with the options -O2 -mcpu=5206 -fwrapv.

/home/iant/gcc/m68k-rtems-objdir/./gcc/xgcc
-B/home/iant/gcc/m68k-rtems-objdir/./gcc/ -O2 -mcpu=5206 -S -fwrapv foo.c
foo.c: In function 'f':
foo.c:31:1: internal compiler error: in maybe_add_or_update_dep_1, at
sched-deps.c:845
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I will describe what I think is happening, although I have not proved it.  The
crash occurs because try_head_merge_bb in cfgcleanup.c moves a CC0-setter away
from the CC0-user.  It finds a common sequence in two basic blocks--I believe
it is the finding of this common sequence which makes this test requires the
-mcpu=5206 -fwrapv options.  Finding the common sequence respects CC0
requirements.  However, it then calls can_move_insns_across.  That returns
false, because there is a register conflict--d0 is used by the predecessor
block and the common sequence.  However, can_move_insns_across also returns
move_upto, indicating which insns may be moved.  can_move_insns_across does not
check for cc0 when setting move_upto, and try_head_merge_bb doesn't check for
it when using move_upto.  The effect is that the cc0 setter is moved, leaving
the cc0 user behind.  This leads to the later crash.

[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.04 20:45:46
  Known to work||4.3.2, 4.4.5, 4.5.2
 Ever Confirmed|0   |1

--- Comment #1 from Joel Sherrill  2011-02-04 20:45:46 
UTC ---
Just a note that it happens with revision 169771.

This is a regression as it works with 4.5.2, 4.4.5, 4.3.2

[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||http://gcc.gnu.org/bugzilla
   ||/show_bug.cgi?id=47459

--- Comment #2 from Andrew Pinski  2011-02-04 
20:59:39 UTC ---
Related to PR 47459.

[Bug fortran/47613] New: [4.6 Regression] namelist read with -static

[janus at gcc dot gnu.org]

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

   Summary: [4.6 Regression] namelist read with -static
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


Consider the following test case:


program test
  implicit none
  integer :: numEnsembles,ios
  NAMELIST /input/ numEnsembles
  read (20, nml=input, IOSTAT=ios)
  print *,ios, is_iostat_end(ios)
end program


This attempts to read a namelist from an empty file. When compiled with 4.5 or
trunk, the output is

  -1 T


When compiling with "gfortran-4.6 -static", the output is:

5010 F

[Bug other/47554] [trans-mem] expand_expr_addr_expr_1 ICE

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

[Bug c++/47611] [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.04 21:11:43
 Ever Confirmed|0   |1

--- Comment #1 from Aldy Hernandez  2011-02-04 
21:11:43 UTC ---
Bringing in a note from the other PR...

The reason memory allocated by the C++ new operator does not get
optimized by the TM-memopt pass is not because of a missing ECF_MALLOC
attribute, but because the alias oracle in GCC considers the chunk of memory as
possibly able to escape from the current function.

That is, the following hunk of code returns true in the TM-memopt pass:

  if (ptr_deref_may_alias_global_p (x))

Apparently, since new/delete operators may be overridden by class specific
hooks, the memory must be considered escaped.

[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  2011-02-04 21:27:40 
UTC ---
It's similar to PR 46878 in that this is also CC0 related, but it is different
code that is splitting up the CC0 setter and the CC0 user.  My sources do
include the patch for PR 46878.

[Bug target/46997] new ia64 vector instructions are broken on HP-UX (big-endian)

[sje at gcc dot gnu.org]

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

--- Comment #4 from Steve Ellcey  2011-02-04 21:46:50 
UTC ---
Author: sje
Date: Fri Feb  4 21:46:45 2011
New Revision: 169840

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169840
Log:
2011-02-04  Richard Henderson  
Steve Ellcey  

PR target/46997
* config/ia64/predicates.md (mux1_brcst_element): New.
* config/ia64/ia64-protos.h (ia64_unpack_assemble): New.
* config/ia64/ia64.c (ia64_unpack_assemble): New.
(ia64_unpack_sign): New.
(ia64_expand_unpack): Rewrite using new routines.
(ia64_expand_widen_sum): Ditto.
(ia64_expand_dot_prod_v8qi): Ditto.
* config/ia64/vect.md (mulv8qi3): Rewrite to use new
routines, add endian check.
(pmpy2_even): Rename from pmpy2_r, add endian check.
(pmpy2_odd): Rename from pmpy2_l, add endian check.
(vec_widen_smult_lo_v4hi): Rewrite using new routines.
(vec_widen_smult_hi_v4hi): Ditto.
(vec_widen_umult_lo_v4hi): Ditto.
(vec_widen_umult_hi_v4hi): Ditto.
(mulv2si3): Change endian checks.
(sdot_prodv4hi): Rewrite with new calls.
(udot_prodv4hi): New.
(vec_pack_ssat_v4hi): Add endian check.
(vec_pack_usat_v4hi): Ditto.
(vec_pack_ssat_v2si): Ditto.
(max1_even): Rename from max1_r, add endian check.
(max1_odd): Rename from max1_l, add endian check.
(*mux1_rev): Format change.
(*mux1_mix): Ditto.
(*mux1_shuf): Ditto.
(*mux1_alt): Ditto.
(*mux1_brcst_v8qi): Use new predicate.
(vec_extract_evenv8qi): Remove endian check.
(vec_extract_oddv8qi): Ditto.
(vec_interleave_lowv4hi): Format change.
(vec_interleave_highv4hi): Ditto.
(mix2_even): Rename from mix2_r, add endian check.
(mix2_odd): Rename from mux2_l, add endian check.
(*mux2): Fix mask setting for TARGET_BIG_ENDIAN.
(vec_extract_evenodd_helper): Format change.
(vec_extract_evenv4hi): Remove endian check.
(vec_extract_oddv4hi): Remove endian check.
(vec_interleave_lowv2si): Format change.
(vec_interleave_highv2si): Format change.
(vec_initv2si): Remove endian check.
(vecinit_v2si): Add endian check.
(reduc_splus_v2sf): Add endian check.
(reduc_smax_v2sf): Ditto.
(reduc_smin_v2sf): Ditto.
(vec_initv2sf): Remove endian check.
(fpack): Add endian check.
(fswap): Add endian check.
(vec_interleave_highv2sf): Add endian check.
(vec_interleave_lowv2sf): Add endian check.
(fmix_lr): Add endian check.
(vec_setv2sf): Format change.
(*vec_extractv2sf_0_be): Use shift to extract operand.
(*vec_extractv2sf_1_be): New.
(vec_pack_trunc_v4hi): Add endian check.
(vec_pack_trunc_v2si): Format change.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64-protos.h
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/ia64/predicates.md
trunk/gcc/config/ia64/vect.md

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-02-04 21:57:11 UTC ---
I don't see this problem on FreeBSD.

troutmask:sgk[207] gfc4x -o z lo.f90
troutmask:sgk[208] ./z
  -1 T
troutmask:sgk[209] gfc4x -o z lo.f90 -static
troutmask:sgk[210] ./z
  -1 T

troutmask:sgk[211] gfc45 -o z lo.f90
troutmask:sgk[212] ./z
  -1 T
troutmask:sgk[213] gfc45 -o z lo.f90 -static
troutmask:sgk[214] ./z
  -1 T

troutmask:sgk[215] gfc4x --version
GNU Fortran (GCC) 4.6.0 20110204 (experimental)
troutmask:sgk[216] gfc45 --version
GNU Fortran (GCC) 4.5.3 20110131 (prerelease)

So, this is target specific.  What target are 
you using?

I'll also note that in ios = -1 and 5010 are

  LIBERROR_END = -1,/* End of file, must be negative.  */
  LIBERROR_READ_VALUE,

which are both possible errors for reading from an
unconnected number.

[Bug rtl-optimization/47614] New: cpu2000 benchmark 301.apsi fails with revision 169782

[pthaugen at gcc dot gnu.org]

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

   Summary: cpu2000 benchmark 301.apsi fails with revision 169782
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: aol...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Created attachment 23248
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23248
testcase

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|hppa64-hp-hpux11.11 |hppa*-*-*
   Host|hppa64-hp-hpux11.11 |hppa*-*-*
  Build|hppa64-hp-hpux11.11 |hppa*-*-*

--- Comment #3 from John David Anglin  2011-02-04 
22:40:30 UTC ---
Same error on linux.

[Bug rtl-optimization/47614] cpu2000 benchmark 301.apsi fails with revision 169782

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||meissner at gcc dot
   ||gnu.org, wschmidt at gcc
   ||dot gnu.org

--- Comment #1 from Pat Haugen  2011-02-04 
22:47:57 UTC ---
Premature bug creation before...

301.apsi started failing on PowerPC with r169782. Attatched testcase was
compiled with 'gfortran -S -m64 -mcpu=power7 -O3 -funroll-loops -ffast-math'.
Following is good/bad snippet of the assembler.

r169781:

xsmaxdp 0,0,11
ble 7,.L2
mr 10,5
addi 0,7,-2
lfdu 5,8(10)
rlwinm 8,0,0,29,31
li 9,1
xscmpudp 0,0,5
ble 0,.L2


r169782:
xsmaxdp 0,0,11
ble 7,.L2
xscmpudp 0,0,11
addi 0,7,-2
mr 10,5
rlwinm 8,0,0,29,31
li 9,1
ble 0,.L2

Note in the new version that the lfdu instruction is gone. This doesn't affect
the compare since the memory value in f11 is still valid, the problem is that
elminating the lfdu instruction elminates the increment of r10 which causes
problems later on when it is used in subsequent loads (and is pointing at the
wrong location).

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Jakub Jelinek  2011-02-04 
23:08:21 UTC ---
Created attachment 23249
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23249
gcc46-pr47610.patch

Untested fix.  varasm.c sometimes calls get_named_section (NULL,
".data.rel.ro{,.local}", {1,3}) and in that case SECTION_RELRO wasn't being
set.

[Bug middle-end/38878] [4.4/4.5/4.6/4.7 Regression] gcc.dg/tree-ssa/foldaddr-1.c XFAILed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-02/msg00236.htm
   ||l
 CC||jakub at gcc dot gnu.org
   Target Milestone|4.4.6   |4.7.0
Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5/4.6/4.7
   |gcc.dg/tree-ssa/foldaddr-1. |Regression]
   |c XFAILed   |gcc.dg/tree-ssa/foldaddr-1.
   ||c XFAILed

--- Comment #2 from Jakub Jelinek  2011-02-04 
23:10:26 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00236.html

Deferring for 4.7 stage 1.

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Target Milestone|--- |4.6.0

[Bug target/47596] internal compiler error: in print_reg, at config/i386/i386.c:10894

[jmichae3 at yahoo dot com]

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

--- Comment #5 from Jim Michaels  2011-02-04 
23:12:20 UTC ---
unfortunately, a release of later versions of gcc in a personal sezero build
are not available.

[Bug lto/47607] FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #3 from Peter Bergner  2011-02-04 
23:18:09 UTC ---
Confirmed.  With Jakub's GCC patch and Alan's ld patch, a huge number (> 500)
of previously failing lto test suite failures now pass.  Excellent!

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-02-05 01:03:51 UTC ---
On Fri, 04 Feb 2011, jakub at gcc dot gnu.org wrote:

> --- Comment #4 from Jakub Jelinek  2011-02-04 
> 23:08:21 UTC ---
> Created attachment 23249
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23249
> gcc46-pr47610.patch

Patch fixes build error.  Doing full test.

Thanks,
Dave

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  2011-02-05 
01:32:42 UTC ---
For this special case:

  print "(F1.0)", 0.0   ! => 0 expected *

Up to now, we have interpreted the last sentence in F95 10.5.1.2.1 F95 10.2.1.1
to require this to print '0'.

"Leading zeros are not permitted except for an optional zero immediately to the
left of the decimal symbol if the magnitude of the value in the output field is
less than one. The optional zero shall appear if there would otherwise be no
digits in the output field."

F2008 draft has the same wording.  Of course this is a little bit in
contradiction with another requirement that the decimal point be shown.  I can
easily change this to output the '*', but thought I would mention that what we
have now was done on purpose and is even commented so in the code.

I have all other test examples listed here fixed in a patch at this point.

[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops

[spop at gcc dot gnu.org]

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

--- Comment #11 from Sebastian Pop  2011-02-05 
01:39:23 UTC ---
Author: spop
Date: Sat Feb  5 01:39:20 2011
New Revision: 169847

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169847
Log:
Fix PR46194: fix the computation of distance vectors.

2011-02-04  Sebastian Pop  

PR tree-optimization/46194
* tree-data-ref.c (analyze_miv_subscript): Remove comment.
(build_classic_dist_vector_1): Do not represent classic distance
vectors when the access functions are variating in different loops.

* gcc.dg/autopar/pr46194.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr46194.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

  Known to work||4.6.0
  Known to fail|4.6.0   |

--- Comment #12 from Sebastian Pop  2011-02-05 
01:41:41 UTC ---
Fixed on trunk.
Should I backport this patch to 4.5?

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  2011-02-05 
02:10:39 UTC ---
With:

print "(F0.0)", 0.001 ! => 0.
print "(F0.0)", 0.01  ! => 0.
print "(F0.0)", 0.1   ! => 0.
print "(F1.0)", -0.0  ! => 0
print "(F1.0)", 0.001 ! => *
print "(F1.0)", 0.01  ! => *
print "(F1.0)", 0.1   ! => *
print "(F2.0)", -0.001! => **
print "(F2.0)", -0.01 ! => **
print "(F2.0)", -0.1  ! => **
print "(F0.0)", 0.0   ! => 0
print "(F0.1)", 0.0   ! => .0
print "(F0.2)", 0.0   ! => .00
print "(F0.3)", 0.0   ! => .000
print "(F0.4)", 0.0   ! => .
print "(F2.0)", 0.0   ! => 0.
print "(F2.0)", 0.001 ! => 0.
print "(F2.0)", 0.01  ! => 0.
print "(F2.0)", 0.1   ! => 0.
end

I currently get, as patched:

$ ./a.out 
0.
0.
0.
0
*
*
*
**
**
**
0
.0
.00
.000
.
0.
0.
0.
0.

Looks reasonable to me. Any other opinions?

[Bug tree-optimization/47615] New: [4.6 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: too deep recursion in
phi_translate/phi_translate_1 with -ftree-pre
-fno-tree-fre -fno-tree-sra
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23250
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23250
auto-reduced testcase

Compiler output:
$ gcc -O -fstrict-aliasing -ftree-pre -fno-tree-fre -fno-tree-sra testcase.C
gcc: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  0x7643711c in _int_malloc () from /lib/libc.so.6
#1  0x764399d0 in malloc () from /lib/libc.so.6
#2  0x011f9c40 in xrealloc (oldmem=, size=152) at
/mnt/svn/gcc-trunk/libiberty/xmalloc.c:177
#3  0x00bea372 in vec_heap_o_reserve_1 (vec=0x0, reserve=, vec_offset=, 
elt_size=, exact=) at
/mnt/svn/gcc-trunk/gcc/vec.c:321
#4  0x00b1b800 in VEC_vn_reference_op_s_heap_copy (expr=0x197b120,
set1=0x197e0c8, set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.h:86
#5  phi_translate_1 (expr=0x197b120, set1=0x197e0c8, set2=0x0,
pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1623
#6  0x00b1bc8c in phi_translate (expr=0x197b120, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1858
#7  phi_translate (expr=0x197b120, set1=0x197e0c8, set2=0x0,
pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1835
#8  0x00b1b8e9 in phi_translate_1 (expr=0x197c030, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1570
#9  0x00b1bc8c in phi_translate (expr=0x197c030, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1858
#10 phi_translate (expr=0x197c030, set1=0x197e0c8, set2=0x0,
pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1835
#11 0x00b1b8e9 in phi_translate_1 (expr=0x197b120, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1570
#12 0x00b1bc8c in phi_translate (expr=0x197b120, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1858
#13 phi_translate (expr=0x197b120, set1=0x197e0c8, set2=0x0,
pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1835
#14 0x00b1b8e9 in phi_translate_1 (expr=0x197c030, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1570
#15 0x00b1bc8c in phi_translate (expr=0x197c030, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1858
#16 phi_translate (expr=0x197c030, set1=0x197e0c8, set2=0x0,
pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1835
#17 0x00b1b8e9 in phi_translate_1 (expr=0x197b120, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1570
#18 0x00b1bc8c in phi_translate (expr=0x197b120, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1858
#19 phi_translate (expr=0x197b120, set1=0x197e0c8, set2=0x0,
pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1835
#20 0x00b1b8e9 in phi_translate_1 (expr=0x197c030, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1570
#21 0x00b1bc8c in phi_translate (expr=0x197c030, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1858
#22 phi_translate (expr=0x197c030, set1=0x197e0c8, set2=0x0,
pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1835
#23 0x00b1b8e9 in phi_translate_1 (expr=0x197b120, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)
at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:1570
#24 0x00b1bc8c in phi_translate (expr=0x197b120, set1=0x197e0c8,
set2=0x0, pred=0x75a484e0, phiblock=0x75a48548)

Tested revisions:
r169824 - crash
4.5.2 - OK

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  2011-02-05 
06:22:03 UTC ---
Created attachment 23251
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23251
A proposed patch

This patch regression tests OK and gives the results shown in my last comment.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #6 from Thomas Henlich  
2011-02-05 07:40:49 UTC ---
(In reply to comment #3)
> For this special case:
> 
>   print "(F1.0)", 0.0   ! => 0 expected *
> 
> Up to now, we have interpreted the last sentence in F95 10.5.1.2.1 F95 
> 10.2.1.1
> to require this to print '0'.
> 
> "Leading zeros are not permitted except for an optional zero immediately to 
> the
> left of the decimal symbol if the magnitude of the value in the output field 
> is
> less than one. The optional zero shall appear if there would otherwise be no
> digits in the output field."
> 
> F2008 draft has the same wording.  Of course this is a little bit in
> contradiction with another requirement that the decimal point be shown.  I can
> easily change this to output the '*', but thought I would mention that what we
> have now was done on purpose and is even commented so in the code.

Regardless of this choice, the following should all print the same result,
which they currently don't.

print "(F1.0)", 0.0  ! => 0
print "(F1.0)", 0.001 ! => *
print "(F1.0)", 0.01  ! => *
print "(F0.0)", 0.0   ! => 0
print "(F0.0)", 0.001 ! => *
print "(F0.0)", 0.01  ! => *

I don't see anything in the standard which suggests that the exact internal
value 0.0 is to be treated differently from a positive internal value which is
rounded to 0.0 on output, and I don't see a valid reason for doing so.

In extension, the following should also print the same result:

print "(F1.0)", 0.0  ! => 0
print "(F1.0)", 1.0  ! => *
print "(F1.0)", 2.0  ! => *

In all these cases, there is the same issue, that "the decimal point be shown",
but doesn't fit.

Again, I don't see anything in the standard which suggests that the internal
value 0.0 is to be treated differently from a positive internal value which is
rounded to an integer number on output.

And in my opinion, the rule "optional zero shall appear" is not a contradiction
to "the decimal point be shown". Both are required, and the output just doesn't
fit the field, hence the field shall be filled with asterisks.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #7 from Thomas Henlich  
2011-02-05 07:45:57 UTC ---
(In reply to comment #6)
> Regardless of this choice, the following should all print the same result,
> which they currently don't.
> 
> print "(F1.0)", 0.0  ! => 0
> print "(F1.0)", 0.001 ! => *
> print "(F1.0)", 0.01  ! => *
> print "(F0.0)", 0.0   ! => 0
> print "(F0.0)", 0.001 ! => *
> print "(F0.0)", 0.01  ! => *

Sorry, but what I meant was that the following should print the same:
print "(F1.0)", 0.0  ! => 0
print "(F1.0)", 0.001 ! => *
print "(F1.0)", 0.01  ! => *

And the following should print the same:
print "(F0.0)", 0.0   ! => 0
print "(F0.0)", 0.001 ! => *
print "(F0.0)", 0.01  ! => *

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #8 from Thomas Henlich  
2011-02-05 07:53:40 UTC ---
(In reply to comment #6)
> In extension, the following should also print the same result:
> 
> print "(F1.0)", 0.0  ! => 0
> print "(F1.0)", 1.0  ! => *
> print "(F1.0)", 2.0  ! => *

What I meant here was they should all either print * or 0, 1, 2