[Bug c/35505] New: builtins.c: 5 * set but not used

[dcb314 at hotmail dot com]

I just applied Intel C to a bootstrap build of GNU
C version 4.4 snapshot 20080229.

The Intel compiler said

../../src/gcc-4.4-20080229/gcc/builtins.c(2868): remark #593: variable "val"
was set but never used
../../src/gcc-4.4-20080229/gcc/builtins.c(5152): remark #593: variable "c" was
set but never used
../../src/gcc-4.4-20080229/gcc/builtins.c(11777): remark #593: variable "dest"
was set but never used
../../src/gcc-4.4-20080229/gcc/builtins.c(11777): remark #593: variable "flag"
was set but never used
../../src/gcc-4.4-20080229/gcc/builtins.c(1195): remark #593: variable
"apply_args_reg_offset" was set but never used

I've just manually checked each of these five and
I agree with the Intel C compiler.

Suggest delete these four dead local variables
and one dead static variable.


-- 
   Summary: builtins.c: 5 * set but not used
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-03-08 07:48 ---
The reason why the old code without the right shift almost worked is that
for the 4 byte aligned 16-bit vars each loop was executed usually twice.
.L6:
lha 0,0(27)
lhz 8,2(26)
.align 4
.L4:
sync
add 9,8,0
rlwinm 10,0,0,0x
rlwinm 9,9,0,0x
slw 11,10,31
slw 9,9,31
.L11:
lwarx 7,0,29
and 0,7,28
cmpw 0,0,11
bne- 0,.L12
andc 7,7,28
or 7,7,9
stwcx. 7,0,29
bne- 0,.L11
isync
.L12:
!   srw 0,0,31  ! This insn was added by this patch
rlwinm 0,0,0,0x
cmpw 7,0,10
extsh 0,0
bne 7,.L4
The first time usually the atomic instruction succeeded, but r0 after rlwinm
was 0, so most often different from r10.  This means the code then jumped to
.L4, with r0 = 0 as the expected value of e[0]. r10 then becomes 0 as new
expected value, lwarx reads the new actual value of e[0], which will be
different from
the expected 0.  So it jumps to .L12, r0 now contains the e[0] value in upper
half and 0 in lower half and r10 is 0, so in the second big loop nothing is
changed and the loop exits.  This is what happens if there is no contention. 
If there is contention though, the first loop doesn't compare and swap anything
and 
as shown above, the second loop iteration won't change anything unless e[0] is
0.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-03-08 07:37 ---
Subject: Bug 35498

Author: jakub
Date: Sat Mar  8 07:36:35 2008
New Revision: 133025

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133025
Log:
PR target/35498
* config/rs6000/rs6000.c (rs6000_expand_compare_and_swapqhi): Shift
wdst back after sync_compare_and_swapqhi_internal.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c


-- 


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

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-03-08 07:31 ---
Subject: Bug 35498

Author: jakub
Date: Sat Mar  8 07:30:55 2008
New Revision: 133024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133024
Log:
PR target/35498
* config/rs6000/rs6000.c (rs6000_expand_compare_and_swapqhi): Shift
wdst back after sync_compare_and_swapqhi_internal.

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


-- 


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

[Bug target/25277] missed optimization for simple mmx code.

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-03-08 07:29 ---
Duplicate of PR 14552.

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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

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

[ubizjak at gmail dot com]

--- Comment #22 from ubizjak at gmail dot com  2008-03-08 07:29 ---
*** Bug 25277 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/22076] Strange code for MMX register moves

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2008-03-08 07:23 ---
Fixed for real.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/22152] Poor loop optimization when using mmx builtins

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2008-03-08 07:22 ---
Fixed for real.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug target/22152] Poor loop optimization when using mmx builtins

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2008-03-08 07:21 ---
For updated testcase:

typedef int __m64 __attribute__ ((__vector_size__ (8)));
typedef long long __v1di __attribute__ ((__vector_size__ (8)));

__m64
unsigned_add3 (const __m64 * a, const __m64 * b, unsigned long count)
{
  __m64 sum;
  unsigned int i;

  for (i = 1; i < count; i++)
sum = (__m64) __builtin_ia32_paddq ((__v1di) a[i], (__v1di) b[i]);

  return sum;
}

we now generate:

.L3:
addl$1, %eax
movq(%edx), %mm0
addl$8, %edx
paddq   (%ecx), %mm0
addl$8, %ecx
cmpl%eax, %ebx
ja  .L3

and adding -mno-ivopts we are back to optimal code:

.L3:
movq(%ebx,%eax,8), %mm0
paddq   (%ecx,%eax,8), %mm0
addl$1, %eax
cmpl%eax, %edx
ja  .L3

So, fixed.


-- 


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

[Bug target/22152] Poor loop optimization when using mmx builtins

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2008-03-08 07:09 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00517.html.

New asm for the original testcase is now much better [see patch post].


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||03/msg00517.html


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

[Bug target/22152] Poor loop optimization when using mmx builtins

[uros at gcc dot gnu dot org]

--- Comment #5 from uros at gcc dot gnu dot org  2008-03-08 07:00 ---
Subject: Bug 22152

Author: uros
Date: Sat Mar  8 06:59:33 2008
New Revision: 133023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133023
Log:
2008-03-08  Uros Bizjak  <[EMAIL PROTECTED]>

PR target/22152
* config/i386/i386-modes.def (V1DI): New vector mode.
* config/i386/i386.h (VALID_MMX_REG_MODE): Add V1DImode.
* config/i386/mmx.md (MMXMODEI8): New mode iterator.
(MMXMODE248): Ditto.
(MMXMODE): Add V1DI mode.
(mmxvecsize): Change DI mode to V1DI mode.
("mov): Use MMXMODEI8 mode iterator.
("*mov_internal_rex64"): Ditto.
("*mov_internal"): Ditto.
("mmx_add3"): Ditto.  Handle V1DImode for TARGET_SSE2.
("mmx_sub3"): Ditto.
("mmx_adddi3"): Remove insn pattern.
("mmx_subdi3"): Ditto.
("mmx_ashr3"): Use SImode and "yN" constraint for operand 2.
("mmx_lshr3"): Ditto. Use MMXMODE248 mode iterator.
("mmx_ashl3"): Ditto.
("mmx_lshrdi3"): Remove insn pattern.
("mmx_ashldi3"): Ditto.
* config/i386/i386.c (classify_argument): Handle V1DImode.
(function_arg_advance_32): Ditto.
(function_arg_32): Ditto.
(struct builtin_description) [IX86_BUILTIN_PADDQ]: Use
mmx_addv1di3 insn pattern.
[IX86_BUILTIN_PSUBQ]: Use mmx_subv1di3 insn pattern.
[IX86_BUILTIN_PSLL?, IX86_BUILTIN_PSRL?, IX86_BUILTIN_PSRA?,
IX86_BUILTIN_PSLL?I, IX86_BUILTIN_PSRL?I, IX86_BUILTIN_PSRA?I,
IX86_BUILTIN_PSLL?I128, IX86_BUILTIN_PSRL?I128,
IX86_BUILTIN_PSRA?I128]:
Remove definitions of built-in functions.
(V1DI_type_node): New node.
(v1di_ftype_v1di_int): Ditto.
(v1di_ftype_v1di_v1di): Ditto.
(v2si_ftype_v2si_si): Ditto.
(v4hi_ftype_v4hi_di): Remove node.
(v2si_ftype_v2si_di): Ditto.
(ix86_init_mmx_sse_builtins): Handle V1DImode.
(__builtin_ia32_psll?, __builtin_ia32_psrl?, __builtin_ia32_psra?):
Redefine builtins using def_builtin_const with *_ftype_*_int node.
(__builtin_ia32_psll?i, __builtin_ia32_psrl?i, __builtin_ia32_psra?i):
Add new builtins using def_builtin_const.
(ix86_expand_builtin) [IX86_BUILTIN_PSLL?, IX86_BUILTIN_PSRL?,
IX86_BUILTIN_PSRA?, IX86_BUILTIN_PSLL?I, IX86_BUILTIN_PSRL?I,
IX86_BUILTIN_PSRA?I]: Handle builtin definitions.
* config/i386/mmintrin.h (__v1di): New typedef.
(_mm_add_si64): Cast arguments to __v1di type.
(_mm_sub_si64): Ditto.
(_mm_sll_pi16): Cast __count to __v4hi type.
(_mm_sll_pi32): Cast __count to __v2si type.
(_mm_sll_si64): Cast arguments to __v1di type.
(_mm_srl_pi16): Cast __count to __v4hi type.
(_mm_srl_pi32): Cast __count to __v2si type.
(_mm_srl_si64): Cast arguments to __v1di type.
(_mm_sra_pi16): Cast __count to __v4hi type.
(_mm_sra_pi32): Cast __count to __v2si type.
(_mm_slli_pi16): Use __builtin_ia32_psllwi.
(_mm_slli_pi32): Use __builtin_ia32_pslldi.
(_mm_slli_si64): Use __builtin_ia32_psllqi. Cast __m to __v1di type.
(_mm_srli_pi16): Use __builtin_ia32_psrlwi.
(_mm_srli_pi32): Use __builtin_ia32_psrldi.
(_mm_srli_si64): Use __builtin_ia32_psrlqi. Cast __m to __v1di type.
(_mm_srai_pi16): Use __builtin_ia32_psrawi.
(_mm_srai_pi32): Use __builtin_ia32_psradi.
* config/i386/i386.md (UNSPEC_NOP): Remove unspec definition.
* doc/extend.texi (X86 Built-in Functions) [__builtin_ia32_psll?,
__builtin_ia32_psrl?, __builtin_ia32_psra?, __builtin_ia32_psll?i,
__builtin_ia32_psrl?i, __builtin_ia32_psra?i]: Add new builtins.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-modes.def
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/mmintrin.h
trunk/gcc/config/i386/mmx.md
trunk/gcc/doc/extend.texi


-- 


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

[Bug c++/35159] g++ and gfortran inoperable with no error message

[jvdelisle at gcc dot gnu dot org]

--- Comment #20 from jvdelisle at gcc dot gnu dot org  2008-03-08 06:06 
---
This looks like bad stuff.  See my separate note to see if I can get to a point
of reproducing this.


-- 


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

[Bug target/35504] incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2008-03-08 04:55 ---
Created an attachment (id=15280)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15280&action=view)
a patch for the bug

A patch for gcc 4.3.0. When the function returns an aggregate value:
--- in fastcall mode, adjust %EDX, not %ECX
--- in regparm(1) mode, adjust 4(%ESP), not %EAX
--- in regparm(2) and regparm(3) mode, adjust %EDX, not %EAX


-- 


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

[Bug target/35504] incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2008-03-08 04:51 ---
Created an attachment (id=15279)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15279&action=view)
A testcase for the bug

A testcase for thunk functions with all calling conventions. It fails with
regparm(1), regparm(2), regparm(3) and fastcall conventions.


-- 


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

[Bug target/35504] New: incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions

[mikulas at artax dot karlin dot mff dot cuni dot cz]

Hi

When GCC generates virtual methods for objects with multiple inheritance, it
creates special "thunk" functions that adjust this pointer and jump to an
original method.

When a member function returns a structure, the first argument is a pointer
where return structure should be placed, the second argument is "this" pointer
and additional arguments are arguments of the member function. When using
regparm 2 or 3, the first argument (ptr to return structure) is in EAX, the
second argument (this) is in EDX and additional arguments are in ECX and on the
stack.

The thunking function is generated incorrectly and always tries to adjust EAX,
causing corruption to this pointer and to the return value.

Similarly, when using fastcall convention, the pointer to return structure is
in ECX and this is in EDX, however thunking function adjusts ECX.

This bug is present in all GCC releases.


-- 
   Summary: incorrect code generated on i386 for C++ multiple
inheritance, large return structures and regparm or
fastcall calling conventions
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug ada/35503] New: Warning about restricted pointers?

[samuel dot thibault at ens-lyon dot org]

I've again seen some code like this:  sprintf(buf, "%s-%s", buf, to_add);  and
gcc doesn't complain, even though the declaration of sprintf is  extern int
sprintf (char *__restrict __s, __const char *__restrict __format, ...); 
Wouldn't it be possible for gcc to check the enforcement of restricted pointer,
at least in the trivial cases like this one?


-- 
   Summary: Warning about restricted pointers?
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: samuel dot thibault at ens-lyon dot org


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

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[brian at dessent dot net]

--- Comment #5 from brian at dessent dot net  2008-03-07 23:48 ---
Subject: Re:  Documentation for -fPIC/-fpic/-fpie is not clear

> I am still learning about linking and loading and I can't guess why non-PIC
> DSOs would work on x86 but not on x86_64. Could you please explain briefly.
> 
> This is all very useful information that I couldn't find anywhere else (I 
> guess
> I could always look at gcc code :) ). Can the following be added to
> documentation?

PIC is always required for DSOs, at least on unix/ELF-like targets. 
It's just that one platform in particular lets you get away with linking
non-PIC code into a .so, namely x86.  All (?) other architectures will
give a link time error if you try to do this.  So it's horribly
non-portable and it really just works by accident.  And it loses most of
the advantages of shared libraries to put non-PIC code in a .so: text
relocs.  This prevents sharing of code pages between processes, so
really the .so is no longer shared from a memory footprint standpoint
since each process will have its own dedicated copy as the .text section
needs to be modified (relocated).  This also has a startup cost.

This kind of thing can't really be easily documented in the gcc manual
because it's platform specific.  gcc is not just a compiler for x86 or
Linux, it supports dozens and dozens of platforms/targets and they each
have different semantics of how shared libraries work -- if they even
have shared libraries.  For example there might be x86 platforms that
don't even have shared libraries, like bare metal or a.out targets, so
you can't even make any definitive statements about x86.  So while "x86
linux" may be common it is most certainly not the only thing gcc is used
with.


-- 


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

[Bug debug/35502] -Wall should include -Wswitch-default

[jeff at schwabcenter dot com]

--- Comment #7 from jeff at schwabcenter dot com  2008-03-07 23:43 ---
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html does not list
-Wswitch-default being enabled by -Wall.


-- 

jeff at schwabcenter dot com changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug debug/35502] -Wall should include -Wswitch-default

[jeff at schwabcenter dot com]

--- Comment #6 from jeff at schwabcenter dot com  2008-03-07 23:42 ---
> Is there any particular reason for changing the docs, rather than the code? 

Kindly disregard that question.  I have just been informed by a co-worker that
some of our third-party library headers include switch statements without
default cases, so adding -Wswitch-default to -Wall would make our lives more
difficult, anyway. :(


-- 


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

[Bug debug/35502] -Wall should include -Wswitch-default

[jeff at schwabcenter dot com]

--- Comment #5 from jeff at schwabcenter dot com  2008-03-07 23:38 ---
Thanks for the quick response and the links.  FYI, the latter link seems to be
broken:

http://archives.free.net.ph/message/20071001.204624.0ca57fae.de.html

Is there any particular reason for changing the docs, rather than the code? 
Include Wswitch-default in Wall is intuitive to me, and avoiding the warning is
straight-forward (if not trivial).


-- 


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

[Bug debug/35502] -Wall should include -Wswitch-default

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-03-07 23:31 ---
See http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01761.html and
http://archives.free.net.ph/message/20071001.204624.0ca57fae.de.html

.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/35502] -Wall should include -Wswitch-default

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-07 23:26 ---
This is a documentation fix which has already happened, see
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html .
-Wall
This enables all the warnings about constructions that some users consider
questionable, and that are easy to avoid (or modify to prevent the warning),
even in conjunction with macros. This also enables some language-specific
warnings described in C++ Dialect Options and Objective-C and Objective-C++
Dialect Options.
-Wall turns on the following warning flags:

  -Waddress   
  -Warray-bounds (only with -O2)  
  -Wc++0x-compat  
  -Wchar-subscripts  
  -Wimplicit-int  
  -Wimplicit-function-declaration  
  -Wcomment  
  -Wformat   
  -Wmain (only for C/ObjC and unless -ffreestanding)  
  -Wmissing-braces  
  -Wnonnull  
  -Wparentheses  
  -Wpointer-sign  
  -Wreorder   
  -Wreturn-type  
  -Wsequence-point  
  -Wsign-compare (only in C++)  
  -Wstrict-aliasing  
  -Wstrict-overflow=1  
  -Wswitch  
  -Wtrigraphs  
  -Wuninitialized (only with -O1 and above)  
  -Wunknown-pragmas  
  -Wunused-function  
  -Wunused-label 
  -Wunused-value 
  -Wunused-variable  
  -Wvolatile-register-var 



-- 


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

[Bug debug/35502] -Wall should include -Wswitch-default

[jeff at schwabcenter dot com]

--- Comment #2 from jeff at schwabcenter dot com  2008-03-07 23:24 ---
Created an attachment (id=15278)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15278&action=view)
Fix for this bug

Setting warn_switch_default = value in the OPT_Wall case of
c_common_handle_option (in gcc/c-opts.c) fixes the problem.


-- 


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

[Bug debug/35502] -Wall should include -Wswitch-default

[jeff at schwabcenter dot com]

--- Comment #1 from jeff at schwabcenter dot com  2008-03-07 23:21 ---
Created an attachment (id=15277)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15277&action=view)
Preprocessed sample code

Compiling the attached file with g++ -Wall should produce "warning: switch
missing default case".


-- 


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

[Bug debug/35502] New: -Wall should include -Wswitch-default

[jeff at schwabcenter dot com]

The g++ man page says -Wall is equivalent to "All of the above -W
options combined."  The -Wswitch-default option should therefore be included in
-Wall, but currently is not.

The correct solution IMO is to add -Wswitch-default to -Wall in c-opts.c. 
Please see the attached patch.

Script started on Fri Mar  7 12:16:38 2008
~$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++
--prefix=/export/home/jeff/opt/gcc
Thread model: posix
gcc version 4.2.4 20080214 (prerelease)
~$ g++ -Wall -Wswitch-default main.cc
main.cc: In function 'int main(int, char**)':
main.cc:1: warning: switch missing default case
~$ g++ -Wall main.cc -save-temps
~$ cat main.ii
# 1 "main.cc"
# 1 ""
# 1 ""
# 1 "main.cc"
int main(int argc, char** argv) { switch (argc) { } }
Script done on Fri Mar  7 12:17:25 2008


-- 
   Summary: -Wall should include -Wswitch-default
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at schwabcenter dot com


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

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

[hsteinhaus at gmx dot de]

--- Comment #2 from hsteinhaus at gmx dot de  2008-03-07 20:59 ---
version 4.2.1 seems to be affected as well:


[EMAIL PROTECTED]:~/scratch$ cat foo.cpp
#include 

const int foobar1 = 42;
int foobar2 = 42;
const int PROGMEM foobar3 = 42;
int PROGMEM foobar4 = 42;

[EMAIL PROTECTED]:~/scratch$ avr-g++ -Wall -mmcu=atmega1281 -c foo.cpp
foo.cpp:5: warning: only initialized variables can be placed into program
memory area
foo.cpp:6: warning: only initialized variables can be placed into program
memory area
[EMAIL PROTECTED]:~/scratch$ avr-g++ --version
avr-g++ (GCC) 4.2.1 (SUSE Linux)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


-- 


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

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[ddenisen at altera dot com]

--- Comment #4 from ddenisen at altera dot com  2008-03-07 20:11 ---
I am still learning about linking and loading and I can't guess why non-PIC
DSOs would work on x86 but not on x86_64. Could you please explain briefly.

This is all very useful information that I couldn't find anywhere else (I guess
I could always look at gcc code :) ). Can the following be added to
documentation?

(for -fpic): PIC is required for DSOs on x86_64 platform but not for x86.
(for -fpie): One example of using -PIE is security: text section of
position-independent executable can be located at different addresses for each
invocation.


-- 


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

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-07 19:47 ---
(In reply to comment #2)
> But DSOs still work if I don't use PIC. Why is that?

Depends on the target :).  If this is x86, then you can guess why.  In fact
x86_64 errors out when linking if you did not use -fPIC (or -fpic).

> Why would anybody want to create position-independent executable? What are the
> advantages and disadvantages?

Security, random addresses for the text section.


-- 


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

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[ddenisen at altera dot com]

--- Comment #2 from ddenisen at altera dot com  2008-03-07 19:45 ---
But DSOs still work if I don't use PIC. Why is that?

Why would anybody want to create position-independent executable? What are the
advantages and disadvantages?


-- 


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

[Bug c++/35499] Symbol resolution optimization should be separately controlled from -fPIC

[ddenisen at altera dot com]

--- Comment #3 from ddenisen at altera dot com  2008-03-07 19:43 ---
I did read "How to write Shared Libraries" and re-read PIC section a couple of
times. Could you please clarify what am I missing here?

If symbol resolution is already controlled separately, what's the flag? I
couldn't find anything in the documentation.


-- 


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

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-07 19:39 ---
DSO requires PIC code.

PIC means is it produces position independent code.
PIE means it produces code for position independent executable, not DSOs
though.


-- 


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

[Bug c++/35499] Symbol resolution optimization should be separately controlled from -fPIC

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-07 19:37 ---
Already controlled separately really so closing as such.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/35499] Symbol resolution optimization should be separately controlled from -fPIC

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #1 from belyshev at depni dot sinp dot msu dot ru  2008-03-07 
19:25 ---
You need to study http://people.redhat.com/drepper/dsohowto.pdf carefully.


-- 


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

[Bug tree-optimization/35501] New: Wrong value returned from const int

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] gcc]$ cat x.i
const int conststaticvariable = 3;

int f(void)
{
  return conststaticvariable;
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O2 x.i -S -fPIC -m32
[EMAIL PROTECTED] gcc]$ cat x.s
.file   "x.i"
.text
.p2align 4,,15
.globl f
.type   f, @function
f:
pushl   %ebp
movl$3, %eax
movl%esp, %ebp
popl%ebp
ret

We can't return 3 when PIC is used since conststaticvariable may
be resolved to another definition at run-time.


-- 
   Summary: Wrong value returned from const int
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=35501

[Bug c++/35500] New: Documentation for -fPIC/-fpic/-fpie is not clear

[ddenisen at altera dot com]

Documentation for -fpic and family is not clear. Here are the points I would
like clarified:
   - Does pic required for SOs (No)? 
   - What are the upsides/downsides of using pic (faster SO loading vs run-time
hit, others?)?
   - Why would anybody want to create a PIE?


-- 
   Summary: Documentation for -fPIC/-fpic/-fpie is not clear
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ddenisen at altera dot com


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

[Bug c++/35499] New: Symbol resolution optimization should be separately controlled from -fPIC

[ddenisen at altera dot com]

I'm working on a large non-UI C++ program on Linux. It consists of hundreds of
SOs and takes a long time to run (hours). I'm seeing about 10% speedup if I do
*not* use -fPIC for some SOs (the executable never uses -fPIC of -fPIE) and,
since run-time is very important to me, I want to not use -fPIC for these SOs.

I noticed that besides not generating position-independent code, the way global
symbols are resolved also changes (a symbol that used to be resolved to a SO
where it is defined with -fPIC is resolved to the executable when I omit -fPIC
for that SO). That caused a breakage which is not hard to fix once I know which
symbol is affected. The problem is that the program has thousands of other
symbols and I don't know, without exhaustive testing, if any other symbol will
get broken.

It would be really nice if symbol resolution and position-independence were
controlled by separate flags.


-- 
   Summary: Symbol resolution optimization should be separately
controlled from -fPIC
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ddenisen at altera dot com


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug tree-optimization/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2008-03-07 18:28 
---
> I think the Ada front-end has TREE_CONSTANT and TREE_READONLY definition
> swapped around:
> 
>   /* Whether we will make TREE_CONSTANT the DECL we produce here, in which
>  case the initializer may be used in-lieu of the DECL node (as done in
>  Identifier_to_gnu).  This is useful to prevent the need of elaboration
>  code when an identifier for which such a decl is made is in turn used
>  an initializer.  We used to rely on CONST vs VAR_DECL for this purpose,
>  but extra constraints apply to this choice (see below) and are not
>  relevant to the distinction we wish to make. */ 
>   bool constant_p = const_flag && init_const;
> 
>   TREE_READONLY (var_decl) = const_flag;
>   DECL_EXTERNAL (var_decl) = extern_flag;
>   TREE_PUBLIC   (var_decl) = public_flag || extern_flag;
>   TREE_CONSTANT (var_decl) = constant_p;

This doesn't seem to be the case according to
  http://gcc.gnu.org/ml/gcc/2005-08/msg00686.html


-- 


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

[Bug c++/35350] FAIL: gcc.target/i386/isa-10.c execution test

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-03-07 17:00 ---
A patch is posted at

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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||03/msg00480.html


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

[Bug tree-optimization/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2008-03-07 16:46 
---
Based on Andreas' latest comment.  The Ada FE may need inspection though.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|ada |tree-optimization
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-07 16:46:14
   date||


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

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-03-07 16:33 ---
Patch:
2008-03-07  Jakub Jelinek  <[EMAIL PROTECTED]>

PR target/35498
* config/rs6000/rs6000.c (rs6000_expand_compare_and_swapqhi): Shift
wdst back after sync_compare_and_swapqhi_internal.

--- gcc/config/rs6000/rs6000.c.jj   2008-02-29 09:11:54.0 +0100
+++ gcc/config/rs6000/rs6000.c  2008-03-07 17:22:27.0 +0100
@@ -13858,6 +13858,9 @@ rs6000_expand_compare_and_swapqhi (rtx d
   emit_insn (gen_sync_compare_and_swapqhi_internal (wdst, mask,
oldval, newval, mem));

+  /* Shift the result back.  */
+  emit_insn (gen_lshrsi3 (wdst, wdst, shift));
+
   emit_move_insn (dst, gen_lowpart (mode, wdst));
 }


will test it now and if successfull, post.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-07 16:33:42
   date||


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

--- Comment #10 from purnnam1 at naver dot com  2008-03-07 16:15 ---
Thanks to Brian's kind comment, I have knew that the exact mechanism.
In my understannding, the conclusion is as follows;

1. GCC 3.x doesn't generate any codes for 80-bit precision. 
   the FPU h/w just uses the 80-bit internal format.

2. The double rounding (80-bit rounding in the calculation and then 64-bit
rounding in doing FST instruction) inside the FPU (not gcc generated codes)
causes this issue.

3. GCC 4.x can add an initialization code to change the default precision of
FPU.

I really appreciate that I have learned many things from this issue from many
great experts in the world.


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[bergner at gcc dot gnu dot org]

--- Comment #13 from bergner at gcc dot gnu dot org  2008-03-07 15:44 
---
(In reply to comment #11)
> Is there a reason why you don't use GET_MODE_SIZE (mode) != N in the
> expression?

Well, the T[IFD]mode don't allow reg+reg addressing, but other 8 byte modes
do (eg, V4SImode).


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[bergner at gcc dot gnu dot org]

--- Comment #12 from bergner at gcc dot gnu dot org  2008-03-07 15:21 
---
Subject: Bug 35373

Author: bergner
Date: Fri Mar  7 15:20:31 2008
New Revision: 133008

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133008
Log:
PR target/35373
* config/rs6000/rs6000.c (rs6000_legitimize_address): Don't generate
reg+const addressing for Altivec modes.  Don't generate reg+reg
addressing for TFmode or TDmode quantities.

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


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2008-03-07 15:20 ---
Subject: Re:  [4.4 Regression]: Revision 132991
 breaks 483.xalancbmk

On Fri, 7 Mar 2008, hjl dot tools at gmail dot com wrote:

> 
> 
> --- Comment #8 from hjl dot tools at gmail dot com  2008-03-07 14:56 
> ---
> Another testcase in C:
> 
> ---
> const int conststaticvariable;
> 
> int f(void)
> {
>   return conststaticvariable;
> }
> ---
> 
> Can we assume conststaticvariable will be 0?

No.


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2008-03-07 15:17 ---
A patch is posted at

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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||03/msg00466.html


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

[Bug target/35498] New: libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

[jakub at gcc dot gnu dot org]

/* { dg-do run } */
/* { dg-options "-fopenmp -O2" } */

extern int omp_get_num_threads (void);
extern void abort (void);

short e[64];
int num_threads;
int g;
_Complex double d, f;

__attribute__((noinline)) void
foo (int x, long long y)
{
#pragma omp parallel num_threads (4)
  {
int i;
#pragma omp barrier
for (i = 0; i < 2400; i++)
  {
if (i == 0)
  num_threads = omp_get_num_threads ();
#pragma omp atomic
  e[0] += x;
  }
  }
}

int
main (void)
{
  int i;
  foo (3, 3LL);
  if (e[0] != 3 * 2400 * num_threads)
abort ();
  return 0;
}

as well as atomic-3.c fails on ppc-linux.
In *.optimized dump the atomic operation is:
  D.1288 = (short unsigned int) .omp_data_i->x;
  D.1290 = e[0];

:
  D.1294 = __sync_val_compare_and_swap_2 (&e, D.1290, (short int) ((short
unsigned int) D.1290 + D.1288));
  D.1295 = D.1290;
  D.1290 = D.1294;
  if (D.1294 != D.1295)
goto ;
  else
goto ;
which looks correct.


-- 
   Summary: libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-
linux
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: ppc-linux


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

[Bug ada/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

[schwab at suse dot de]

--- Comment #4 from schwab at suse dot de  2008-03-07 14:59 ---
The patch in  works here
as well.


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2008-03-07 14:56 ---
Another testcase in C:

---
const int conststaticvariable;

int f(void)
{
  return conststaticvariable;
}
---

Can we assume conststaticvariable will be 0?


-- 


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

[Bug c++/35497] New: Compiling error with template part. spec. involving function call and >>

[rodolfo at rodsoft dot org]

The following code gives a compiling error with gcc-4.3.0 with -std=c++0x:

template  class A {};
template  class B {};
template  class A> {};

main.cpp:3: error: a function call cannot appear in a constant-expression

While if we use > > (instead of >>) in the class specialization, it compiles
fine, as in:

template  class A {};
template  class B {};
template  class A > {};


-- 
   Summary: Compiling error with template part. spec. involving
function call and >>
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2008-03-07 14:39 ---
My patch works on 483.xalancbmk with test input. I am running with
ref input.


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-03-07 14:24 ---
This patch

--- tree-ssa-ccp.c.local2008-03-06 14:18:27.0 -0800
+++ tree-ssa-ccp.c  2008-03-07 06:21:57.0 -0800
@@ -306,9 +306,10 @@ get_symbol_constant_value (tree sym)
   if (val
  && ccp_decl_initial_min_invariant (val))
return val;
-  /* Variables declared 'const' without an initializer
+  /* Local variables declared 'const' without an initializer
 have zero as the intializer.  */
   if (!val
+ && !TREE_PUBLIC (sym)
   && (INTEGRAL_TYPE_P (TREE_TYPE (sym))
   || SCALAR_FLOAT_TYPE_P (TREE_TYPE (sym
 return fold_convert (TREE_TYPE (sym), integer_zero_node);

works on small C++ testcase. I will try 483.xalancbmk next.


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[rguenther at suse dot de]

--- Comment #5 from rguenther at suse dot de  2008-03-07 14:22 ---
Subject: Re:  [4.4 Regression]: Revision 132991
 breaks 483.xalancbmk

On Fri, 7 Mar 2008, hjl dot tools at gmail dot com wrote:

> --- Comment #4 from hjl dot tools at gmail dot com  2008-03-07 14:03 
> ---
> (In reply to comment #1)
> > Subject: Re:   New: [4.4 Regression]: Revision 132991 breaks 483.xalancbmk
> > 
> > This is most likely the c++ front-end setting readonly when it should  
> > not.
> > 
> 
> I think you should check a symbol is both readonly and local.
> conststaticvariable in
> 
> ---
> class bar
> {
> public:
>   static const int conststaticvariable;
> };
> ---
> 
> is global, not local.

Yep, and yes, the example was valid.

Richard.


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-03-07 14:03 ---
(In reply to comment #1)
> Subject: Re:   New: [4.4 Regression]: Revision 132991 breaks 483.xalancbmk
> 
> This is most likely the c++ front-end setting readonly when it should  
> not.
> 

I think you should check a symbol is both readonly and local.
conststaticvariable in

---
class bar
{
public:
  static const int conststaticvariable;
};
---

is global, not local.


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-03-07 13:54 ---
Are

bash-3.2$ cat y.cc
class bar
{
public:
  static const int conststaticvariable;
};


int f(void)
{
  return bar::conststaticvariable;
}
bash-3.2$ cat z.cc
extern int foo (void);

class bar
{
public:
  static const int conststaticvariable;
};


const int bar::conststaticvariable = foo ();
bash-3.2$ 

valid C++ program?


-- 


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

[Bug target/35496] New: [4.4 Regression] test failures between revs. 132950 and 132974

[dominiq at lps dot ens dot fr]

On i686-apple-darwin9 with rev. 132974, I see the following regressions (not in
rev. 132950):

FAIL: gcc.dg/bf-ms-layout-2.c execution test
FAIL: gcc.dg/bf-ms-layout.c execution test

FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/array_constructor_12.f90  -O3 -g  execution test

The failures of gfortran.dg/array_constructor_12.f90 result from a segmentation
fault. All failures disappear with -m64. Between the two builds I have replaced
the first patch (comment #3) for PR33642 by the second one (comment #4).


-- 
   Summary: [4.4 Regression] test failures between revs. 132950 and
132974
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug c++/35244] Broken diagnostic: 'type_decl' not supported by dump_expr

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-03-07 13:16 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #16 from belyshev at depni dot sinp dot msu dot ru  2008-03-07 
12:47 ---
(In reply to comment #15)
> This bug was about an infinite loop.
Okay.


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
   Keywords|ice-on-valid-code   |wrong-code
  Known to work|4.3.0   |
 Resolution||FIXED
Summary|[4.4 Regression] -frtl- |-frtl-abstract-sequences
   |abstract-sequences causes an|causes an infinite loop
   |ICE |


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

[Bug rtl-optimization/33009] [4.4 Regression] -frtl-abstract-sequences causes an ICE

[loki at gcc dot gnu dot org]

--- Comment #15 from loki at gcc dot gnu dot org  2008-03-07 12:33 ---
(In reply to comment #14)
> It is now broken on trunk on x86_64-linux with -m32 -fPIC:
> 
> pr11832.c: In function 'foo':
> pr11832.c:30: error: unrecognizable insn:
> (insn 216pr11832.c:30: internal compiler error: Segmentation fault

Truly, I do not understand why this bug had to be renamed and reopened!
As I wrote in comment #9 the 'unrecognizable insn' case should belong to
PR33642.
This bug was about an infinite loop.


-- 


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

[Bug ada/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Assert_Failure  |[4.4 Regression]
   |uintp.adb:1593  |Assert_Failure
   ||uintp.adb:1593
   Target Milestone|--- |4.4.0


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

[Bug ada/35493] Assert_Failure uintp.adb:1593

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-07 12:05 ---
I think the Ada front-end has TREE_CONSTANT and TREE_READONLY definition
swapped around:

  /* Whether we will make TREE_CONSTANT the DECL we produce here, in which
 case the initializer may be used in-lieu of the DECL node (as done in
 Identifier_to_gnu).  This is useful to prevent the need of elaboration
 code when an identifier for which such a decl is made is in turn used as
 an initializer.  We used to rely on CONST vs VAR_DECL for this purpose,
 but extra constraints apply to this choice (see below) and are not
 relevant to the distinction we wish to make. */ 
  bool constant_p = const_flag && init_const;

  TREE_READONLY (var_decl) = const_flag;
  DECL_EXTERNAL (var_decl) = extern_flag;
  TREE_PUBLIC   (var_decl) = public_flag || extern_flag;
  TREE_CONSTANT (var_decl) = constant_p;



READ_ONLY means it is only read and not written to at all and the initializer
is valid.


-- 


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

[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-03-07 12:03 
---
(In reply to comment #0)
> - openf95 and sunf95 reject it
> - ifort, gfortran, NAG f95, and g95 accept it
> Bill Long writes that he tested two non-Sun compilers, of which two gave an
> error and two did not.

For what it's worth, the IBM compiler also accepts it. (Now, which is the
second non-Sun compiler that rejects it?)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug ada/35493] Assert_Failure uintp.adb:1593

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-07 11:59 ---
This has to be a bug in the Ada front-end because all the rest of the
middle-end assumes that if DECL_INITIAL is NULL, the value is going to be zero.
 I might be the case where TREE_READONLY is being set and it should not be as
the variable is not readonly.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |ada


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

[Bug fortran/35478] [4.2 regression] internal compiler error: Segmentation fault

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2008-03-07 11:57 
---
Confirmed on i686-linux; it is a 4.2 regression, as it used to work with 4.0.4
and 4.1.2. It was fixed in 4.3 and 4.4, and it's an ICE on invalid code, so
chances that we fix it are really close to zero. (I actually think we should
close this as WONTFIX.)

PS: I've also checked that mainline does not give any warning with valgrind on
this testcase, nor on a modified, valid-code testcase.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.2.3
  Known to work||4.0.4 4.1.2 4.3.0 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-03-07 11:57:30
   date||
Summary|internal compiler error:|[4.2 regression] internal
   |Segmentation fault  |compiler error: Segmentation
   ||fault


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

[Bug fortran/35423] Implement OpenMP workshare

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-07 11:48:45
   date||


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

[Bug c++/35049] [4.3 Regression] g++.dg/conversion/simd3.C:12: error: invalid operands to binary + (have 'float __vector__' and 'int __vector__')

[bonzini at gcc dot gnu dot org]

--- Comment #15 from bonzini at gnu dot org  2008-03-07 11:48 ---
Subject: Bug 35049

Author: bonzini
Date: Fri Mar  7 11:47:20 2008
New Revision: 133007

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133007
Log:
cp:
2008-03-07  Paolo Bonzini  <[EMAIL PROTECTED]>

Revert:

2008-02-06  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/35049
PR c++/35096
* typeck.c (structural_comptypes): Call cp_comptypes.
(comptypes): New; called from the C/C++ common bits to perform
strict checks.
(cp_comptypes): Renamed from comptypes, which is already used,
with a different signature, by the C++ front end.
(build_reinterpret_cast_1): Call cp_comptypes.
(ptr_reasonably_similar): Ditto.
* decl.c (decls_match): Ditto.
* cvt.c (convert_to_reference): Ditto.
* cp-tree.h (same_type_p): Ditto.
(same_or_base_type_p): Ditto.
(comptypes): Rename to cp_comptypes.
* pt.c (canonical_type_parameter): Call cp_comptypes.

objcp:
2008-03-07  Paolo Bonzini  <[EMAIL PROTECTED]>

Revert:

2008-02-07  Andreas Tobler  <[EMAIL PROTECTED]>
Douglas Gregor  <[EMAIL PROTECTED]>

PR bootstrap/35115
* objcp-decl.c (objcp_comptypes): Call cp_comptypes, not comptypes.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-decl.c


-- 


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

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

[bonzini at gcc dot gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2008-03-07 11:48 ---
Subject: Bug 35115

Author: bonzini
Date: Fri Mar  7 11:47:20 2008
New Revision: 133007

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133007
Log:
cp:
2008-03-07  Paolo Bonzini  <[EMAIL PROTECTED]>

Revert:

2008-02-06  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/35049
PR c++/35096
* typeck.c (structural_comptypes): Call cp_comptypes.
(comptypes): New; called from the C/C++ common bits to perform
strict checks.
(cp_comptypes): Renamed from comptypes, which is already used,
with a different signature, by the C++ front end.
(build_reinterpret_cast_1): Call cp_comptypes.
(ptr_reasonably_similar): Ditto.
* decl.c (decls_match): Ditto.
* cvt.c (convert_to_reference): Ditto.
* cp-tree.h (same_type_p): Ditto.
(same_or_base_type_p): Ditto.
(comptypes): Rename to cp_comptypes.
* pt.c (canonical_type_parameter): Call cp_comptypes.

objcp:
2008-03-07  Paolo Bonzini  <[EMAIL PROTECTED]>

Revert:

2008-02-07  Andreas Tobler  <[EMAIL PROTECTED]>
Douglas Gregor  <[EMAIL PROTECTED]>

PR bootstrap/35115
* objcp-decl.c (objcp_comptypes): Call cp_comptypes, not comptypes.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-decl.c


-- 


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

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

[bonzini at gcc dot gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2008-03-07 11:48 ---
Subject: Bug 35096

Author: bonzini
Date: Fri Mar  7 11:47:20 2008
New Revision: 133007

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133007
Log:
cp:
2008-03-07  Paolo Bonzini  <[EMAIL PROTECTED]>

Revert:

2008-02-06  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/35049
PR c++/35096
* typeck.c (structural_comptypes): Call cp_comptypes.
(comptypes): New; called from the C/C++ common bits to perform
strict checks.
(cp_comptypes): Renamed from comptypes, which is already used,
with a different signature, by the C++ front end.
(build_reinterpret_cast_1): Call cp_comptypes.
(ptr_reasonably_similar): Ditto.
* decl.c (decls_match): Ditto.
* cvt.c (convert_to_reference): Ditto.
* cp-tree.h (same_type_p): Ditto.
(same_or_base_type_p): Ditto.
(comptypes): Rename to cp_comptypes.
* pt.c (canonical_type_parameter): Call cp_comptypes.

objcp:
2008-03-07  Paolo Bonzini  <[EMAIL PROTECTED]>

Revert:

2008-02-07  Andreas Tobler  <[EMAIL PROTECTED]>
Douglas Gregor  <[EMAIL PROTECTED]>

PR bootstrap/35115
* objcp-decl.c (objcp_comptypes): Call cp_comptypes, not comptypes.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-decl.c


-- 


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

[Bug tree-optimization/35493] Assert_Failure uintp.adb:1593

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-03-07 10:48 ---
This was caused by this change:

2008-03-06  Andrew Pinski  <[EMAIL PROTECTED]>

   PR tree-opt/35402
   * tree-ssa-ccp.c (get_symbol_constant_value): Handle
   integral and scalar float variables which have a
   NULL DECL_INITIAL.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 CC||schwab at suse dot de,
   ||pinskia at gcc dot gnu dot
   ||org
  Component|ada |tree-optimization
  GCC build triplet|i686-apple-darwin9  |
   GCC host triplet|i686-apple-darwin9  |
 GCC target triplet|i686-apple-darwin9  |


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

[Bug tree-optimization/35472] [4.3 Regression] tree DSE is broken

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-03-07 09:49 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.3.0
 Resolution||FIXED


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

[Bug tree-optimization/35472] [4.3 Regression] tree DSE is broken

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-03-07 09:47 ---
Subject: Bug 35472

Author: rguenth
Date: Fri Mar  7 09:47:06 2008
New Revision: 133004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133004
Log:
2008-03-07  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/35472
* tree-ssa-dse.c (dse_optimize_stmt): Do not delete a store
whose single use_stmt has a overlapping set of loaded and
stored symbols as that use_stmt might be a noop assignment then.

* gcc.c-torture/execute/pr35472.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr35472.c
  - copied unchanged from r132899,
trunk/gcc/testsuite/gcc.c-torture/execute/pr35472.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-dse.c


-- 


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

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-03-07 09:08 ---
Will probably happen in cases like

static const int i = foo();

?


-- 


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

[Bug rtl-optimization/17236] inefficient code for long long multiply on x86

[bonzini at gnu dot org]

-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


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

[Bug rtl-optimization/17236] inefficient code for long long multiply on x86

[bonzini at gnu dot org]

--- Comment #29 from bonzini at gnu dot org  2008-03-07 08:26 ---
ira branch produces the same code as with my patch.


-- 


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