[Bug rtl-optimization/323] optimized code gives strange floating point results

[David dot Monniaux at imag dot fr]

--- Comment #124 from David dot Monniaux at imag dot fr  2008-11-11 07:46 
---
Vincent Lefèvre is right: the issue is quite subtle. (I should mention that
Vincent is an expert in computer arithmetics, which I'm not.)

As he rightly points, conformance to IEEE-754 should be evaluated for a whole
software/hardware system - it is possible to have a IEEE-754 system entirely
implemented in software.

It seems like the C99 standard prohibits double rounding, and prohibits having
values depend on the vagaries of register spilling. Except that this
prohibition is explicit only in non-normative sections. "Language lawyers" have
sent me justifications that this prohibition is implied by various normative
prescriptions of the standard.

I think that in any case we should not spend too much energy trying to assign
blame (who conforms to the standard) but rather try to find solutions.

The short answer is that no compiler, be it gcc, will be modified so that
complex sequences of operations are used for floating-point operations in lieu
of directly using x87 instructions! At least for two reasons:
* x87 is now fading away (its use is deprecated on x86-64, it's not used by
default on Intel Macintosh...)
* Most people don't want to pay the performance hit.

In addition, I think there are more urgent things to fix in gcc's
floating-point system, such as support for #pragma STDC FENV ACCESS

Now for some additional facts:
* It is possible to force the x87 to use reduced precision for the mantissa
(with inline asm or even now with gcc options).
* This setting does not affect the range of exponents. so you can still have
surprises if a very tiny nonzero value is kept in a register then is rounded to
zero when spilled to memory.
* In some rare cases, you can have "double rounding on underflow": you get a
different result by computing on SSE in double precision mode on the one hand,
and by computing on x87 in "double precision" then writing to a double variable
in memory.


-- 


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

[Bug tree-optimization/38079] gcc segfaults when using -ftree-vectorizer-verbose=9

[David dot Monniaux at imag dot fr]

--- Comment #1 from David dot Monniaux at imag dot fr  2008-11-11 07:00 
---
Created an attachment (id=16649)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16649&action=view)
gcc -c -O3 -ftree-vectorizer-verbose=9 set_str.i segfaults

This code comes from GNU MP 4.2.4.


-- 


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

[Bug tree-optimization/38079] New: gcc segfaults when using -ftree-vectorizer-verbose=9

[David dot Monniaux at imag dot fr]

$ gcc -O3 -ftree-vectorizer-verbose=9 -c set_str.i
(lots of blah-blah)
set_str.c:326: note: get vectype with 4 units of type const unsigned char
set_str.c:326: note: vectype: const vector unsigned char
set_str.c:326: note: set_str.c: In function ‘__gmpn_set_str’:
set_str.c:54: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)


-- 
   Summary: gcc segfaults when using -ftree-vectorizer-verbose=9
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: David dot Monniaux at imag dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-11-11 06:49 ---
The current patch is at

http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2008-   |patches/2008-
   |11/msg00130.html|11/msg00180.html


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

[Bug c++/15795] No way to teach operator new anything about alignment requirements

[David dot Monniaux at imag dot fr]

--- Comment #40 from David dot Monniaux at imag dot fr  2008-11-11 06:24 
---
Yes, at least the manual should be updated to reflect this non-obvious
behavior.

Possible fixes for the programmer:
1) Overload operators new. new[] for a class wrapping the vector datatypes. It
works as long as you allocate memory through explicit new, however it fails for
buffers allocated by STL's default allocator.
2) Overload the allocators for a wrapper class and select a specific allocator
for STL arrays etc. of that class. Haven't tried that yet.
3) Replace the global ::new and ::new[] by something calling memalign instead
of malloc.


-- 


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

[Bug target/38054] Assertion failed in change_decl_assembler_name()

[dannysmith at users dot sourceforge dot net]

--- Comment #5 from dannysmith at users dot sourceforge dot net  2008-11-11 
06:27 ---
(In reply to comment #3)
> Patch at:
> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html
> 

That patch also fixes the FAIL of testsuite\g++.old-deja\g++.dg\other>g++
pr35504.C .  Currently it fails on mingw32 and cygwin with:

Warning: resolving non-virtual thunk to c3::method5()@4 by linking to
non-virtual thunk to c3::method5()
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
c:\tmp/ccisCRqc.o:pr35504.C:(.rdata$_ZTV2c3[vtable for c3]+0x44): undefined
reference to [EMAIL PROTECTED]@4'
collect2: ld returned 1 exit status 


-- 


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

[Bug middle-end/31029] Fold does not fold C - a == a

[jv244 at cam dot ac dot uk]

--- Comment #8 from jv244 at cam dot ac dot uk  2008-11-11 06:00 ---
(In reply to comment #7)
> Actually we can fold C - a == a only for odd C.
> But more generally a +- b == a to b == 0.
> 
right... that works as well for this optimization. 

The original argument was on the range of a and thus C-a. Which allows also
folding C - a == a for non-odd values of C.


-- 


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

[Bug fortran/37999] Fortran shape and kind intrinsic

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-11-11 05:28 
---
Closing, not a bug any more.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug c++/38068] Friend Functions of the Base accessing Derived Class Members

[anubhav dot saxena at wipro dot com]

--- Comment #2 from anubhav dot saxena at wipro dot com  2008-11-11 01:48 
---
(In reply to comment #1)
> *** Bug 38078 has been marked as a duplicate of this bug. ***

I had only logged 38068. I am not sure how and why 38078 came into picture.
Also I am unable to figure out if this is confirmed to be a bug, or is this a
RESOLVED bug?


-- 


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

[Bug c++/38078] Friend Functions of the Base accessing Derived Class Members

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-11-11 01:33 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/38068] Friend Functions of the Base accessing Derived Class Members

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-11-11 01:33 ---
*** Bug 38078 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/38078] New: Friend Functions of the Base accessing Derived Class Members

[anubhav dot saxena at wipro dot com]

struct aderived;
struct aderived2;

struct abase{
abase() : pblc(0), prtd(0), prvt(0){}
public:
int pblc;
protected:
int prtd;
private:
int prvt;

friend void frb(abase *pb, aderived *pd);
};

struct aderived : protected abase{
void fn(abase *pb, aderived* pd, aderived2 *pd2);
friend void frd(abase *pb, aderived *pd, aderived2 *pd2);
};

struct aderived2 : aderived{};

void frb(abase *pb, aderived *pd){
pb->pblc++;
pb->prtd++;
pb->prvt++;

pd->pblc++;
pd->prtd++;
pd->prvt++;
}

int main(){}

This code gives the following compilation error:

j.cpp: In function void frb(abase*, aderived*):
j.cpp:16: error: int abase::prvt is private
j.cpp:35: error: within this context

However Visual Studio 2008 and Comeau Online Compiler give error in all the
three statements

a) pd->pblc++;
b) pd->prtd++;
c) pd->prvt++;


"ComeauTest.c", line 28: error: member "abase::pblc" (declared at line 7) is
  inaccessible
pd->pblc++;
^

"ComeauTest.c", line 29: error: member "abase::prtd" (declared at line 9) is
  inaccessible
pd->prtd++;
^

"ComeauTest.c", line 30: error: member "abase::prvt" (declared at line 11) is
  inaccessible
pd->prvt++;


-- 
   Summary: Friend Functions of the Base accessing Derived Class
Members
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anubhav dot saxena at wipro dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug other/38077] New: strict aliasing is not controllable via the option pragma or is not documented that way

[pinskia at gcc dot gnu dot org]

When I was helping someone with a strict aliasing issue, I noticed that since
the fix for PR 37106, the option pragma cannot control strict aliasing.  This
is not documented at all but I think it would be a good idea to be able to
control this option also.


-- 
   Summary: strict aliasing is not controllable via the option
pragma or is not documented that way
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug tree-optimization/37955] [4.4 Regression] internal compiler error: in vectorizable_store, at tree-vect-transform.c:5447

[hp at gcc dot gnu dot org]

--- Comment #10 from hp at gcc dot gnu dot org  2008-11-11 01:00 ---
Is this now a duplicate of PR37742, which according to the reporter still fails
for the original test-case?


-- 


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

[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278

[pinskia at gcc dot gnu dot org]

--- Comment #19 from pinskia at gcc dot gnu dot org  2008-11-11 00:52 
---
Blah, turning on/off strict aliasing via the option pragma would be a good
idea.


-- 


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

[Bug rtl-optimization/37397] IRA performance impact on SPEC CPU 2K/2006

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2008-11-11 00:03 ---
Subject: Bug 37397

Author: hjl
Date: Tue Nov 11 00:02:20 2008
New Revision: 141757

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141757
Log:
2008-11-10  Vladimir Makarov  <[EMAIL PROTECTED]>

PR rtl-optimization/37397
* ira-int.h (struct ira_allocno): New member bad_spill_p.
(ALLOCNO_BAD_SPILL_P): New macro.

* ira-color.c (push_allocnos_to_stack): Check ALLOCNO_BAD_SPILL_P.

* ira-build.c (ira_create_allocno): Initialize
ALLOCNO_BAD_SPILL_P.
(create_cap_allocno, propagate_allocno_info,
remove_unnecessary_allocnos): Set up or update
ALLOCNO_BAD_SPILL_P.
(update_bad_spill_attribute): New function.
(ira_build): Call it.

* ira-costs.c (record_reg_classes): Set up ALLOCNO_BAD_SPILL_P.

Modified:
branches/ira-merge/gcc/ChangeLog.ira
branches/ira-merge/gcc/ira-build.c
branches/ira-merge/gcc/ira-color.c
branches/ira-merge/gcc/ira-costs.c
branches/ira-merge/gcc/ira-int.h


-- 


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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code

[hjl at gcc dot gnu dot org]

--- Comment #10 from hjl at gcc dot gnu dot org  2008-11-11 00:01 ---
Subject: Bug 37948

Author: hjl
Date: Mon Nov 10 23:59:57 2008
New Revision: 141756

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141756
Log:
2008-11-10  H.J. Lu  <[EMAIL PROTECTED]>

Backport from mainline:
2008-11-10  Vladimir Makarov  <[EMAIL PROTECTED]>

PR rtl-optimizations/37948
* ira-int.h (struct ira_allocno_copy): New member constraint_p.
(ira_create_copy, ira_add_allocno_copy): New parameter.

* ira-conflicts.c (process_regs_for_copy): New parameter.  Pass it
to ira_add_allocno_copy.
(process_reg_shuffles, add_insn_allocno_copies): Pass a new
parameter to process_regs_for_copy.
(propagate_copies): Pass a new parameter to ira_add_allocno_copy.
Fix typo in passing second allocno to ira_add_allocno_copy.

* ira-color.c (update_conflict_hard_regno_costs): Use head of
coalesced allocnos list.
(assign_hard_reg): Ditto.  Check that assigned allocnos are not in
the graph.
(add_ira_allocno_to_bucket): Rename to add_allocno_to_bucket.
(add_ira_allocno_to_ordered_bucket): Rename to
add_allocno_to_ordered_bucket.
(push_ira_allocno_to_stack): Rename to push_allocno_to_stack.  Use
head of coalesced allocnos list.
(push_allocnos_to_stack): Remove calculation of ALLOCNO_TEMP.
Check that it is aready calculated.
(push_ira_allocno_to_spill): Rename to push_ira_allocno_to_spill.
(setup_allocno_left_conflicts_num): Use head of coalesced allocnos
list.
(coalesce_allocnos): Do extended coalescing too.

* ira-emit.c (add_range_and_copies_from_move_list): Pass a new
parameter to ira_add_allocno_copy.

* ira-build.c (ira_create_copy, ira_add_allocno_copy): Add a new
parameter.
(print_copy): Print copy origination too.

* ira-costs.c (scan_one_insn): Use alloc_pref for load from
equivalent memory.

Modified:
branches/ira-merge/gcc/ChangeLog.ira
branches/ira-merge/gcc/ira-build.c
branches/ira-merge/gcc/ira-color.c
branches/ira-merge/gcc/ira-conflicts.c
branches/ira-merge/gcc/ira-costs.c
branches/ira-merge/gcc/ira-emit.c
branches/ira-merge/gcc/ira-int.h


-- 


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

[Bug tree-optimization/38072] [4.3 Regression] ICE during inlining of valid code

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-11-10 23:57 ---
Confirmed, still fails today on 4.3 branch.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.0 4.3.3
  Known to work||4.4.0 4.1.1
   Last reconfirmed|-00-00 00:00:00 |2008-11-10 23:57:21
   date||
Summary|ICE during inlining of valid|[4.3 Regression] ICE during
   |code|inlining of valid code
   Target Milestone|--- |4.3.3


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

[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2008-11-10 
23:52 ---
Subject: Re:  [4.4 Regression] FAIL:
26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at
tree-cfg.c:3962

> Can you attach preprocessed source, if it is still reproduceable?

Attached.

Dave


--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2008-11-10 
23:52 ---
Created an attachment (id=16648)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16648&action=view)


-- 


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

[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2008-11-10 23:25 ---
Currently worked around with the patch in #4.


-- 


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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code

[vmakarov at gcc dot gnu dot org]

--- Comment #9 from vmakarov at gcc dot gnu dot org  2008-11-10 23:23 
---
Subject: Bug 37948

Author: vmakarov
Date: Mon Nov 10 23:21:45 2008
New Revision: 141753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141753
Log:
2008-11-07  Vladimir Makarov  <[EMAIL PROTECTED]>

PR rtl-optimizations/37948
* ira-int.h (struct ira_allocno_copy): New member constraint_p.
(ira_create_copy, ira_add_allocno_copy): New parameter.

* ira-conflicts.c (process_regs_for_copy): New parameter.  Pass it
to ira_add_allocno_copy.
(process_reg_shuffles, add_insn_allocno_copies): Pass a new
parameter to process_regs_for_copy.
(propagate_copies): Pass a new parameter to ira_add_allocno_copy.
Fix typo in passing second allocno to ira_add_allocno_copy.

* ira-color.c (update_conflict_hard_regno_costs): Use head of
coalesced allocnos list.
(assign_hard_reg): Ditto.  Check that assigned allocnos are not in
the graph.
(add_ira_allocno_to_bucket): Rename to add_allocno_to_bucket.
(add_ira_allocno_to_ordered_bucket): Rename to
add_allocno_to_ordered_bucket.
(push_ira_allocno_to_stack): Rename to push_allocno_to_stack.  Use
head of coalesced allocnos list.
(push_allocnos_to_stack): Remove calculation of ALLOCNO_TEMP.
Check that it is aready calculated.
(push_ira_allocno_to_spill): Rename to push_ira_allocno_to_spill.
(setup_allocno_left_conflicts_num): Use head of coalesced allocnos
list.
(coalesce_allocnos): Do extended coalescing too.

* ira-emit.c (add_range_and_copies_from_move_list): Pass a new
parameter to ira_add_allocno_copy.

* ira-build.c (ira_create_copy, ira_add_allocno_copy): Add a new
parameter.
(print_copy): Print copy origination too.

* ira-costs.c (scan_one_insn): Use alloc_pref for load from
equivalent memory.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-build.c
trunk/gcc/ira-color.c
trunk/gcc/ira-conflicts.c
trunk/gcc/ira-costs.c
trunk/gcc/ira-emit.c
trunk/gcc/ira-int.h


-- 


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

[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2008-11-10 23:11 ---
Subject: Bug 37514

Author: kkojima
Date: Mon Nov 10 23:10:10 2008
New Revision: 141752

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141752
Log:
PR rtl-optimization/37514
* config/sh/sh.h (OPTIMIZATION_OPTIONS): Set
flag_ira_share_spill_slots to 2 if it's already non-zero.
(OVERRIDE_OPTIONS): Clear flag_ira_share_spill_slots if
flag_ira_share_spill_slots is 2.
* gcc.target/sh/pr37514.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr37514.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/38052] [4.4 Regression] genautomata segfaults when -O2 is enabled

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target
   Keywords||build, wrong-code
Summary|genautomata segfaults when -|[4.4 Regression] genautomata
   |O2 is enabled   |segfaults when -O2 is
   ||enabled
   Target Milestone|--- |4.4.0


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

[Bug c++/38076] New: FAIL: g++.dg/other/anon5.C

[dominiq at lps dot ens dot fr]

In 32 bit mode the failure is:

/var/tmp//ccPCZsXJ.s:44:non-relocatable subtraction expression,
"__ZN12_GLOBAL__N_11c1tE" minus "L001$pb"
/var/tmp//ccPCZsXJ.s:44:symbol: "__ZN12_GLOBAL__N_11c1tE" can't be undefined in
a subtraction expression

In 64 bit mode, the failure is 

Undefined symbols:
  "(anonymous namespace)::c::t", referenced from:
  f()in ccUXilTp.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

and would probably require the same fix as for *-*-hpux* *-*-solaris2.* (see
pr35245).


-- 
   Summary: FAIL: g++.dg/other/anon5.C
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
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=38076

[Bug tree-optimization/37433] [4.4 Regression] tree check: expected function_decl, have string_cst in ccp_fold, at tree-ssa-ccp.c:1050

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-11-10 22:39 
---
(In reply to comment #10)
> on arm I get 
> 

That is a target issue, please file it as a separate bug.


-- 


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

[Bug c++/15795] No way to teach operator new anything about alignment requirements

[pinskia at gcc dot gnu dot org]

--- Comment #39 from pinskia at gcc dot gnu dot org  2008-11-10 22:33 
---
*** Bug 38063 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||David dot Monniaux at imag
   ||dot fr


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

[Bug c++/38063] C++ operator new returns misaligned address

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-11-10 22:33 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/38068] Friend Functions of the Base accessing Derived Class Members

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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

[Bug java/38075] New: Scanner(System.in) causes next*() to behave incorrectly

[gcc-bugzilla at gcc dot gnu dot org]

When the below code (see How-To-Repeat) is compiled and run, the
program waits for input after initializing the Scanner. That input is
then returned to the first input.next() call, and each input.next()
call returns the user input given during the previous call.

Environment:
System: Linux hybrid 2.6.27-zen3-4.2.0 #2 SMP Sat Oct 25 12:29:11 EDT
2008 x86_64 GNU/Linux 
host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ../trunk/configure --program-suffix=-svn 
--enable-languages=c,c++,java --with-x --enable-java-awt=xlib

How-To-Repeat:
Compile and run a file containing the following code:

import java.util.Scanner;

public class Test {
public static void main(String argv[]) {
Scanner input = new Scanner(System.in);

System.out.print("Enter a string: ");
String foo = input.next();
System.out.println(foo);

System.out.print("Enter a string: ");
foo = input.next();
System.out.println(foo);

input.close();
}
}


-- 
   Summary: Scanner(System.in) causes next*() to behave incorrectly
   Product: gcc
   Version: 4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jre21 at case dot edu
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/36089] [4.2/4.3/4.4 Regression] Funny rejects valid with constant integral expression

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||11/msg00383.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-16 19:36:23 |2008-11-10 21:20:03
   date||


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

[Bug middle-end/38074] New: [4.4 Regression] missed inlining since IRA merge on Core2 Duo

[dominiq at lps dot ens dot fr]

With gfortran 4.3.2 the functions ddx and ddy in the channel.90 polyhedron test
with:

gfortran -S -m64 -O3 -ffast-math -finline-limit=312 channel.f90

but not for -finline-limit=311.

Since the IRA merge, this is no longer the case even if I use
-finline-limit=6000. This causes a ~5% increase in the execution time (~2.4s
compared to ~2.3s, small but noticeable).

I suspect the same is true for the fatigue.f90 test.


-- 
   Summary: [4.4 Regression] missed inlining since IRA merge on
Core2 Duo
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
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=38074

[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables

[pault at gcc dot gnu dot org]

-- 

pault 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-11-10 19:46:00
   date||


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

[Bug middle-end/38073] [graphite] ICE: Segmentation fault

[mitul dot thakkar at amd dot com]

--- Comment #1 from mitul dot thakkar at amd dot com  2008-11-10 19:41 
---
Created an attachment (id=16647)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16647&action=view)
Reduced Test Case


-- 


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

[Bug middle-end/38073] New: [graphite] ICE: Segmentation fault

[mitul dot thakkar at amd dot com]

gcc -c -O3 -fgraphite-identity test_seg.c

test_seg.c: In function 'test_seg':
test_seg.c:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



GDB is giving following message

Program received signal SIGSEGV, Segmentation fault.
find_uses_to_rename_use (bb=0x2adb75d73c00, use=0x0, use_blocks=0x100e8d0,
need_phis=0xfec758) at ../../graphite/gcc/tree-ssa-loop-manip.c:238
238   if (TREE_CODE (use) != SSA_NAME)
(gdb) bt
#0  find_uses_to_rename_use (bb=0x2adb75d73c00, use=0x0, use_blocks=0x100e8d0,
need_phis=0xfec758) at ../../graphite/gcc/tree-ssa-loop-manip.c:238
#1  0x007a7525 in find_uses_to_rename_bb (bb=0x2adb75d73c00,
use_blocks=0x100e8d0, need_phis=0xfec758)
at ../../graphite/gcc/tree-ssa-loop-manip.c:297
#2  0x007a7abe in rewrite_into_loop_closed_ssa (changed_bbs=, update_flag=2048) at
../../graphite/gcc/tree-ssa-loop-manip.c:327
#3  0x00abb9c9 in gloog (scop=0xffe020, stmt=) at
../../graphite/gcc/graphite.c:4410
#4  0x00abcf15 in graphite_transform_loops () at
../../graphite/gcc/graphite.c:5287
#5  0x007b0d07 in graphite_transforms () at
../../graphite/gcc/tree-ssa-loop.c:298
#6  0x0063d408 in execute_one_pass (pass=0xf22da0) at
../../graphite/gcc/passes.c:1279
#7  0x0063d645 in execute_pass_list (pass=0xf22da0) at
../../graphite/gcc/passes.c:1327
#8  0x0063d65d in execute_pass_list (pass=0xf22b00) at
../../graphite/gcc/passes.c:1328
#9  0x0063d65d in execute_pass_list (pass=0xf21fc0) at
../../graphite/gcc/passes.c:1328
#10 0x00731b5c in tree_rest_of_compilation (fndecl=0x2adb75d5de00) at
../../graphite/gcc/tree-optimize.c:418
#11 0x008a7414 in cgraph_expand_function (node=0x2adb75d5df00) at
../../graphite/gcc/cgraphunit.c:1038
#12 0x008a91e5 in cgraph_optimize () at
../../graphite/gcc/cgraphunit.c:1097
#13 0x00417593 in c_write_global_declarations () at
../../graphite/gcc/c-decl.c:8073
#14 0x006e326f in toplev_main (argc=, argv=) at ../../graphite/gcc/toplev.c:979
#15 0x2adb7556d184 in __libc_start_main () from /lib64/libc.so.6
#16 0x004050b9 in _start ()


-- 
   Summary: [graphite] ICE: Segmentation fault
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mitul dot thakkar at amd dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/38072] ICE during inlining of valid code

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-11-10 19:27 ---
Still happens on the 4.3 branch as of 4.3.3 20080918.  Building a new compiler.


-- 


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

[Bug tree-optimization/38072] ICE during inlining of valid code

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-11-10 19:20 ---
Here is a better backtrace:
#0  remap_ssa_name (name=0xb7d3c000, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:192
#1  0x08127db4 in copy_body_r (tp=0xb7d3dc28, walk_subtrees=0xbfd9fc78,
data=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:599
#2  0x083f195b in walk_tree_1 (tp=0xb7d3dc28, func=0x8127a90 ,
data=0xbfda005c, pset=0x0, lh=0) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree.c:8618
#3  0x083f1a95 in walk_tree_1 (tp=0xb7d2ce1c, func=0x8127a90 ,
data=0xbfda005c, pset=0x0, lh=0) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree.c:8857
#4  0x0812735d in remap_type_1 (type=0xb7d2cb60, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:403
#5  0x08127517 in remap_type (type=0xb7d2cb60, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:430
#6  0x0812743e in remap_type_1 (type=0xb7d2cc40, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:311
#7  0x08127517 in remap_type (type=0xb7d2cc40, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:430
#8  0x08126f97 in remap_decl (decl=0xb7d35720, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:262
#9  0x081278d7 in remap_ssa_name (name=0xb7d3c2a4, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:176
#10 0x08127db4 in copy_body_r (tp=0xb7d3e0a0, walk_subtrees=0xbfd9fe48,
data=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:599
#11 0x083f195b in walk_tree_1 (tp=0xb7d3e0a0, func=0x8127a90 ,
data=0xbfda005c, pset=0x0, lh=0) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree.c:8618
#12 0x083f1a95 in walk_tree_1 (tp=0xbfd9ff0c, func=0x8127a90 ,
data=0xbfda005c, pset=0x0, lh=0) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree.c:8857
#13 0x08128e59 in copy_bb (id=0xbfda005c, bb=0xb7d36168,
frequency_scale=-1210851216, count_scale=1) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:826
#14 0x0812979f in copy_cfg_body (id=0xbfda005c, count=,
frequency=0, entry_block_map=0xb7d36fb4, exit_block_map=0xb7d367bc)
at /home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:1367

--- CUT ---
And a reduced testcase:
typedef __SIZE_TYPE__ size_t;
inline void* operator new[](unsigned, void* __p) throw() {  return __p;  }
void *malloc(size_t);
template   inline   void ConstructRawArray(DataT *data,unsigned
size) {
 new(data) DataT[size];
}
template   struct SingleBufferBodyC  
{
  DataT *buff;
  void *operator new(size_t s,void *mem){   }
  inline unsigned Size() const  {}
  SingleBufferBodyC(unsigned nsize)
  {
  ConstructRawArray(this->buff,this->Size());  
  }
};
template   struct SingleBufferC   
{
  SingleBufferC(unsigned size) 
  {
 SingleBufferBodyC *ret = reinterpret_cast
*> (malloc(8)) ;   
 new(ret) SingleBufferBodyC(size);
  }
};
struct TestObjC {
 TestObjC()   { }
 int val;
 };
int TestSingleBuffer() {
   SingleBufferC buff3(100);
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|i686-apple-darwin9  |
   GCC host triplet|i686-apple-darwin9  |
 GCC target triplet|i686-apple-darwin9  |
   Keywords||ice-on-valid-code
Summary|ICE on valid code.  |ICE during inlining of valid
   ||code


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

[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning

[jamborm at gcc dot gnu dot org]

-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-10-30 18:43:24 |2008-11-10 18:39:51
   date||


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

[Bug middle-end/38070] ICE in compare_values_warnv

[rakdver at gcc dot gnu dot org]

--- Comment #3 from rakdver at gcc dot gnu dot org  2008-11-10 18:32 ---
> It might be that only number_of_iterations_lt_to_ne needs to be changed,
> I looked at other uses of fold_build* in tree-ssa-loop-niter.c and quite
> some others also look at least fishy (at least those generating compares),
> but they usually only set assumptions, so they might be fine for now.

no, they could not.  Any comparison of wrong-type operands is a problem.

> In any case, this seems to work for me:

Probably a more thorough fix of the type problems in tree-ssa-loop-niter.c
would be better.


-- 


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

[Bug middle-end/38070] ICE in compare_values_warnv

[matz at gcc dot gnu dot org]

--- Comment #2 from matz at gcc dot gnu dot org  2008-11-10 18:08 ---
Well, the invalid {LE,GT}_EXPRs trees are build right there in the patched
function, which is also the one that introduces the use of sizetype at all
(since the POINTER_PLUS_EXPR merge it seems, from 2007-06-15).


-- 


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

[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||11/msg00366.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-11-08 21:46:55 |2008-11-10 18:05:45
   date||


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

[Bug tree-optimization/38072] ICE on valid code.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-11-10 17:48 ---
It was ICEing in
0x002084ac in remap_ssa_name (name=0x18e9c40, id=0xb4cc) at
/Users/apinski/src/local/gcc/gcc/tree-inline.c:192


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |tree-optimization


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

[Bug middle-end/38070] ICE in compare_values_warnv

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-11-10 17:46 ---
I think the problem is likely in the SCEV code again.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/38072] ICE on valid code.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-11-10 17:44 ---
Works on the trunk.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |target


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

[Bug c++/38072] ICE on valid code.

[c dot galambos at omniperception dot com]

--- Comment #1 from c dot galambos at omniperception dot com  2008-11-10 
17:39 ---
Created an attachment (id=16646)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16646&action=view)
Preprocessor output .


-- 


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

[Bug c++/38072] New: ICE on valid code.

[c dot galambos at omniperception dot com]

ICE on what I believe to be valid code.  I've seen this happen on
all 4.3.x variants I've tired, but works fine with earlier versions gcc.  The
error disappears when optimisation is not used.  The following is the setup
I've used for the report:

'g++ -v' gives:

Using built-in specs.  Target: i686-apple-darwin9 Configured with:
../gcc-4.3.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.3
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --build=i686-apple-darwin9 --with-gmp=/sw
--with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib Thread model: posix gcc version 4.3.2 (GCC)

Command line:

  g++-4 -c -O testBugE.cc

Error message:

Users/charlesgalambos/src/active/Ravl/Core/Container/Buffer/SingleBuffer.hh:
In static member function ‘static RavlN::SingleBufferBodyC*
RavlN::SingleBufferC::AllocBody(RavlN::SizeT) [with DataT =
TestObjC]’:
/Users/charlesgalambos/src/active/Ravl/Core/Container/Buffer/SingleBuffer.hh:217:
internal compiler error: Bus error Please submit a full bug report,

(I assume bugzilla will give me a chance to submit an attachment when
I've committed the report ??)


-- 
   Summary: ICE on valid code.
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: c dot galambos at omniperception dot com
 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=38072

[Bug middle-end/38070] New: ICE in compare_values_warnv

[matz at gcc dot gnu dot org]

This is similar to PR36817, but has different reasons.

% cat x.c
void fail (void)
{
  unsigned int w[5], *wi;

  wi = &w[2];
  do {
  unsigned int x = wi[-2];
  *wi = x;
  } while (++wi < w+5);
}

% ./gcc/cc1 -O3 -quiet x.c
x.c: In function ‘fail’:
x.c:2: internal compiler error: in compare_values_warnv, at tree-vrp.c:772

I think the reason is that # of iterations analysis puts type-incorrect
compares into iter->may_be_zero, which is a problem because (unlike
->assumptions) this is used later by loop-unrolling to generate code
(to guard against a non-looping loop).

In this case it generates this:

Analyzing # of iterations of loop 1
  exit condition [&w[3], + , 4](no_overflow) < &w + 20
  bounds on difference of bases: -4294967275 ... 4294967295
  result:
zero if &w[3] > (unsigned int) (&w + 20)
# of iterations 2, bounded by 1073741823

Note the "&w[3] > (unsigned int) (&w + 20)" which has mismatching types.

It might be that only number_of_iterations_lt_to_ne needs to be changed,
I looked at other uses of fold_build* in tree-ssa-loop-niter.c and quite
some others also look at least fishy (at least those generating compares),
but they usually only set assumptions, so they might be fine for now.

In any case, this seems to work for me:
Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c   (revision 141741)
+++ tree-ssa-loop-niter.c   (working copy)
@@ -710,7 +710,7 @@ number_of_iterations_lt_to_ne (tree type
noloop = boolean_false_node;
   else
noloop = fold_build2 (GT_EXPR, boolean_type_node,
- iv0->base,
+ fold_convert (type1, iv0->base),
  fold_build2 (PLUS_EXPR, type1,
   iv1->base, tmod));
 }
@@ -734,7 +734,7 @@ number_of_iterations_lt_to_ne (tree type
noloop = fold_build2 (GT_EXPR, boolean_type_node,
  fold_build2 (MINUS_EXPR, type1,
   iv0->base, tmod),
- iv1->base);
+ fold_convert (type1, iv1->base));
 }

   if (!integer_nonzerop (assumption))

I haven't checked other versions of the compiler, but trunk at least still
has the same code.


-- 
   Summary: ICE in compare_values_warnv
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org


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

[Bug c++/38069] function pointer exception specification not checked during assignment

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-11-10 17:09 
---
*** Bug 38071 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/38071] function pointer exception specification not checked during assignment

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-11-10 17:09 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug c++/38071] New: function pointer exception specification not checked during assignment

[yacwroy at gmail dot com]

According to the spec, you can't assign the value of a less-restrictive
function pointer to a more-restrictive function pointer.

Relevant C++ Spec section: 15.4 -3- (except.spec)
==
Code below taken directly from the C++ spec above.
==
class A { /* ... */ };
void (*pf1)();  //  no exception specification
void (*pf2)() throw(A);

void f()
{
pf1 = pf2;  //  OK:  pf1  is less restrictive
pf2 = pf1;  //  error:  pf2  is more restrictive
}
==
this compiles OK - it shouldn't.

the line marked
//  error:
does not produce an error.
==

I ran through g++ under kdbg on a 1-line file:
void (*fp)() throw(int);

I'm not sure if I read it right but it seems that gcc just ignores function
pointer exception specifications altogether.

in gcc/cp/decl.c, in the behemoth that is grokdeclarator() which builds the
declarator.
there's this "tree" called "raises" that gets passed the exception spec, but
it's only used to check for errors, it's not embedded into the newly built
declarator. 

gcc/cp/decl.c :: grokdeclarator() ::
===
~8100: raises = declarator->u.function.exception_specification;
raises gets passed the spec.

~9172: decl = grokvardecl(.);
. (nothing important).
~9225: return decl;
grokvardecl builds the decl that's returned, but it's not passed "raises".
===

"tree"'s are still confusing me so I'm not sure if it's possible to embed this
into the decl without breaking anything, but that'd be where I'd start (after I
was sure it wasn't already in there).


when -fdumping-tree-original, there's no exception spec for the function ptr,
but I guess it could've been stripped.


(checked buglist for "function pointer exception specification", didn't see any
dupes)


-- 
   Summary: function pointer exception specification not checked
during assignment
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yacwroy at gmail dot com
 GCC build triplet:  x86_64-linux-gnu
  GCC host triplet:  x86_64-linux-gnu
GCC target triplet:  x86_64-linux-gnu


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

[Bug c++/38069] function pointer exception specification not checked during assignment

[yacwroy at gmail dot com]

--- Comment #1 from yacwroy at gmail dot com  2008-11-10 16:35 ---


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


-- 

yacwroy at gmail dot com changed:

   What|Removed |Added

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


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

[Bug c++/12255] exception-specifications unchecked during assignment of pointer to function

[yacwroy at gmail dot com]

--- Comment #5 from yacwroy at gmail dot com  2008-11-10 16:35 ---
*** Bug 38069 has been marked as a duplicate of this bug. ***


-- 

yacwroy at gmail dot com changed:

   What|Removed |Added

 CC||yacwroy at gmail dot com


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

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #5 from nickc at redhat dot com  2008-11-10 16:22 ---
Oops - almost forgot - the bug needs a testcase for the g++ testsuite, so I
have uploaded a patch to add that as well.

Cheers
  Nick


-- 


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

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #4 from nickc at redhat dot com  2008-11-10 16:22 ---
Created an attachment (id=16645)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16645&action=view)
Testcase for the bug


-- 


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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code

[vmakarov at redhat dot com]

--- Comment #8 from vmakarov at redhat dot com  2008-11-10 16:12 ---
  H.J., thanks for finding the problem and reducing the test case.

  The problem could be solved by using extended register coalescing.  Now IRA
coalesces only move insns (-fira-coalesce).  But unfortunately usage of
-fira-coalesce makes worse code in general case.  Register preferencing based
on hard register costs works generally better in IRA.

  Therefore I've tried to find what is wrong with the hard register cost
calculation.  Why loading register from its equivalent memory location and 3
usages of the register in the loop of 36.c is cheaper than 1 def and 1 usage of
another pseudo-register (that is major difference from the old register
allocator).  The problem is in usage GENERAL_REGS class to calculate saving
from loading pseudo from the equivalent memory instead of pseudo cover class
(SSE_REGS).  It gives from cost 12 instead of 6 which results in wrong choice
for spilling and worse code.

  I'll send a patch fixing this problem a bit later today.


-- 


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

[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time

[kargl at gcc dot gnu dot org]

--- Comment #12 from kargl at gcc dot gnu dot org  2008-11-10 15:01 ---
(In reply to comment #11)
> (In reply to comment #10)
> > Admitted, it does not say SIZE = 8, because this value may be
> > compiler- and system-dependent (may also be 12 for gfortran on some
> > platforms), which is why the standard provides the SIZE argument in
> > the first place.
> > 
> > I fail to see the problem - could you clarify?
> > 
> 
> A default integer on i386 is 4 bytes. The instruction "print sizeof(size)"
> prints 4. I assume it should also print 4 if I use:
> 
> CALL Random_Seed(size=size)
>   print *, size
> 

'SIZE' is the number of elements in the array that you need
to use with PUT= and GET=

   program a
   integer, allocatable :: seeds(:)
   integer n
   call random_seed(size = n)
   allocate(seeds(n))
   call random_seed(get = seeds)
   print*, seeds
   deallocate(seeds)
   end program

It seems you need to revisit Metcalf and Reid or the Standard.


-- 


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

[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2008-11-10 
14:54 ---
Subject: Re:  [4.4 Regression] __builtin_apply failures

> Created an attachment (id=16639)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16639&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16639&action=view)
> gcc44-pr37323.patch
> 
> I guess the following patch should fix it.  The question is if it doesn't 
> break
> other targets...

The patch fixes the PR, and there were no new regressions with the change
on hppa64-hp-hpux11.11 or hppa-unknown-linux-gnu.

Dave


-- 


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

[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-11-10 14:52 ---
Can you attach preprocessed source, if it is still reproduceable?


-- 


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

[Bug c++/38069] New: function pointer exception specification not checked during assignment

[yacwroy at gmail dot com]

According to the spec, you can't assign the value of a less-restrictive
function pointer to a more-restrictive function pointer.

Relevant C++ Spec section: 15.4 -3- (except.spec)
==
Code below taken directly from the C++ spec above.
==
class A { /* ... */ };
void (*pf1)();  //  no exception specification
void (*pf2)() throw(A);

void f()
{
pf1 = pf2;  //  OK:  pf1  is less restrictive
pf2 = pf1;  //  error:  pf2  is more restrictive
}
==
this compiles OK - it shouldn't.

the line marked
//  error:
does not produce an error.
==

I ran through g++ under kdbg on a 1-line file:
void (*fp)() throw(int);

I'm not sure if I read it right but it seems that gcc just ignores function
pointer exception specifications altogether.

in gcc/cp/decl.c, in the behemoth that is grokdeclarator() which builds the
declarator.
there's this "tree" called "raises" that gets passed the exception spec, but
it's only used to check for errors, it's not embedded into the newly built
declarator. 

gcc/cp/decl.c :: grokdeclarator() ::
===
~8100: raises = declarator->u.function.exception_specification;
raises gets passed the spec.

~9172: decl = grokvardecl(.);
. (nothing important).
~9225: return decl;
grokvardecl builds the decl that's returned, but it's not passed "raises".
===

"tree"'s are still confusing me so I'm not sure if it's possible to embed this
into the decl without breaking anything, but that'd be where I'd start (after I
was sure it wasn't already in there).


when -fdumping-tree-original, there's no exception spec for the function ptr,
but I guess it could've been stripped.


(checked buglist for "function pointer exception specification", didn't see any
dupes)


-- 
   Summary: function pointer exception specification not checked
during assignment
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yacwroy at gmail dot com
 GCC build triplet:  x86_64-linux-gnu
  GCC host triplet:  x86_64-linux-gnu
GCC target triplet:  x86_64-linux-gnu


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

[Bug c++/38068] New: Friend Functions of the Base accessing Derived Class Members

[anubhav dot saxena at wipro dot com]

struct aderived;
struct aderived2;

struct abase{
abase() : pblc(0), prtd(0), prvt(0){}
public:
int pblc;
protected:
int prtd;
private:
int prvt;

friend void frb(abase *pb, aderived *pd);
};

struct aderived : protected abase{
void fn(abase *pb, aderived* pd, aderived2 *pd2);
friend void frd(abase *pb, aderived *pd, aderived2 *pd2);
};

struct aderived2 : aderived{};

void frb(abase *pb, aderived *pd){
pb->pblc++;
pb->prtd++;
pb->prvt++;

pd->pblc++;
pd->prtd++;
pd->prvt++;
}

int main(){}

This code gives the following compilation error:

j.cpp: In function void frb(abase*, aderived*):
j.cpp:16: error: int abase::prvt is private
j.cpp:35: error: within this context

However Visual Studio 2008 and Comeau Online Compiler give error in all the
three statements

a) pd->pblc++;
b) pd->prtd++;
c) pd->prvt++;


"ComeauTest.c", line 28: error: member "abase::pblc" (declared at line 7) is
  inaccessible
pd->pblc++;
^

"ComeauTest.c", line 29: error: member "abase::prtd" (declared at line 9) is
  inaccessible
pd->prtd++;
^

"ComeauTest.c", line 30: error: member "abase::prvt" (declared at line 11) is
  inaccessible
pd->prvt++;


-- 
   Summary: Friend Functions of the Base accessing Derived Class
Members
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anubhav dot saxena at wipro dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug c++/36478] [4.3/4.4 regression] warning not emitted when code expanded from macro

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-11-10 13:53 ---
Patch posted.


-- 

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 |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||11/msg00361.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-06-10 09:50:40 |2008-11-10 13:53:26
   date||


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

[Bug middle-end/35314] [4.2/4.3 regression] ICE with __builtin_setjmp and -fmudflap

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-11-10 13:52 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.4.0
Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE
   |with __builtin_setjmp and - |with __builtin_setjmp and -
   |fmudflap|fmudflap


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

[Bug c++/38021] [4.4 Regression] C++ hang for new keywords

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-11-10 13:50 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Priority|P3  |P2
 Resolution||FIXED
Summary|C++ hang for new keywords   |[4.4 Regression] C++ hang
   ||for new keywords
   Target Milestone|--- |4.4.0


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

[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time

[michael dot a dot richmond at nasa dot gov]

--- Comment #11 from michael dot a dot richmond at nasa dot gov  2008-11-10 
13:50 ---
(In reply to comment #10)
> Admitted, it does not say SIZE = 8, because this value may be
> compiler- and system-dependent (may also be 12 for gfortran on some
> platforms), which is why the standard provides the SIZE argument in
> the first place.
> 
> I fail to see the problem - could you clarify?
> 

A default integer on i386 is 4 bytes. The instruction "print sizeof(size)"
prints 4. I assume it should also print 4 if I use:

CALL Random_Seed(size=size)
  print *, size


-- 


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

[Bug middle-end/35314] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and -fmudflap

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-11-10 13:49 ---
Subject: Bug 35314

Author: jakub
Date: Mon Nov 10 13:48:06 2008
New Revision: 141741

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141741
Log:
PR middle-end/35314
* tree-mudflap.c (mf_build_check_statement_for): Split then_block
after __mf_check call if the call must end a bb.

* testsuite/libmudflap.c/pass67-frag.c: New test.

Added:
trunk/libmudflap/testsuite/libmudflap.c/pass67-frag.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-mudflap.c
trunk/libmudflap/ChangeLog


-- 


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

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #3 from nickc at redhat dot com  2008-11-10 13:49 ---
Hi Guys,

  I have uploaded a potential patch for the problem.  It fixes the testcase
originally provided and does not introduce any regressions into the g++
testsuite for an i686-pc-linux-gnu toolchain.  

That's the good news.  The bad news is that I am not sure if the patch will be
acceptable since I am not a C++ expert.  The problem I believe is that the
status of the cp_id_kind enum which is computed by
cp_parser_postfix_dot_deref_expression() when it is parsing "A::get" is not
passed back to cp_parse_primary_expression() which is currently parsing
"(p->A::get)".  So it goes with its default value, which allows overloading of
virtual functions, and so the wrong member function is selected.

The patch attempts to fix this problem by allowing the cp_id_kind enum computed
in cp_parser_postfix_dot_deref_expression to be passes back, via a long chain
of intermediary functions, to cp_parser_primary_expression.  My concern is that
I am not familiar enough with the C++ parser to tell if the patch breaks some
other parser requirement.  (One that is not tested by the g++ testsuite).

So - is this patch acceptable ?

Cheers
  Nick


-- 

nickc at redhat dot com changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug libstdc++/38067] monetary_members.cc: 4 * call to wrong C++ delete

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-11-10 13:49 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/38067] monetary_members.cc: 4 * call to wrong C++ delete

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2008-11-10 13:48 ---
Subject: Bug 38067

Author: paolo
Date: Mon Nov 10 13:47:12 2008
New Revision: 141740

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141740
Log:
2008-11-10  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/38067
* config/locale/gnu/monetary_members.cc (moneypunct<>::
_M_initialize_moneypunct(__c_locale, const char*)): Use correct vector
delete for __wcs_ps and __wcs_ns.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/locale/gnu/monetary_members.cc


-- 


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

[Bug c++/38021] C++ hang for new keywords

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-11-10 13:43 ---
Subject: Bug 38021

Author: jakub
Date: Mon Nov 10 13:41:37 2008
New Revision: 141739

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141739
Log:
PR c++/38021
* parser.c (cp_parser_enum_specifier): After parsing :,
parse definitely.  Don't return early if type specifier
is erroneous.

* g++.dg/cpp0x/enum1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/enum1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #2 from nickc at redhat dot com  2008-11-10 13:36 ---
Created an attachment (id=16644)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16644&action=view)
Allow postfix parser to pass cp_id_kind information back to the primary parser


-- 


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

[Bug libstdc++/38067] monetary_members.cc: 4 * call to wrong C++ delete

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-11-10 13:34 
---
Confirmed, I'll fix it momentarily. Thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
  Component|c++ |libstdc++
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-11-10 13:34:10
   date||


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

[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time

[dennis dot wassel at googlemail dot com]

--- Comment #10 from dennis dot wassel at googlemail dot com  2008-11-10 
13:32 ---
Subject: Re:  RANDOM_SEED: PUT= check array size at compile time

> The documentation says only that the size argument has to be an integer. See
> http://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fSEED.html

On the contrary: The documentation clearly and concisely states

SIZE(Optional) Shall be a scalar and of type default INTEGER, with
INTENT(OUT). It specifies the minimum size of the arrays used with the
PUT and GET arguments.

Admitted, it does not say SIZE = 8, because this value may be
compiler- and system-dependent (may also be 12 for gfortran on some
platforms), which is why the standard provides the SIZE argument in
the first place.

I fail to see the problem - could you clarify?


-- 


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

[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions

[ams at gcc dot gnu dot org]

--- Comment #9 from ams at gcc dot gnu dot org  2008-11-10 13:01 ---
> > This tst instruction is unneeded as the LSR is setting the flags correctly
> > already.
> 
> This is NOT correct. LSL does write to the condition codes, but not all of it.
> In particular, the bit involved in the not-equal test is not set.

Hmm, on re-reading the manual, I seem to have misunderstood this. The
description of the instruction states certain bits are set, but then, on the
next page the table shows all the bits being updated.

I'm going to need to think about this one some more.

Sorry for the noise :(

Andrew


-- 


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

[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time

[michael dot a dot richmond at nasa dot gov]

--- Comment #9 from michael dot a dot richmond at nasa dot gov  2008-11-10 
12:59 ---
(In reply to comment #8)
> If you check, the minimum size of count is 8 as returned by the size= argument
> if you use it. Try this. size is intent OUT.

The documentation says only that the size argument has to be an integer. See
http://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fSEED.html


-- 


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

[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions

[gunnar at greyhound-data dot com]

--- Comment #8 from gunnar at greyhound-data dot com  2008-11-10 12:54 
---
(In reply to comment #7)
> (In reply to comment #4)
> > There are two causes where GCC generates unneeded TST instructions.
> > A) General arithmetic 
> >  lsr.l #1,D0 
> >  tst.l d0
> >  jbne ...
> >
> > This tst instruction is unneeded as the LSR is setting the flags correctly
> > already.
> 
> This is NOT correct. LSL does write to the condition codes, but not all of it.
> In particular, the bit involved in the not-equal test is not set.
> 
> This TST *is* required.

What you is say is not correct.

The bit involved in the not-eval test is the "Z-Bit"
Both the LSR and TST do set the Z-Bit, 100% equally.

The TST instruction in the example is 100% unneeded and NOT required.

Please check the official 68K documentation for the which flags the conditinal
branch instruction BCC tests (in this case BNE), and verify the behavior of TST
and LSR in regards of setting these bits.

Best Regards
Gunnar von Boehn


-- 

gunnar at greyhound-data dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions

[ams at gcc dot gnu dot org]

--- Comment #7 from ams at gcc dot gnu dot org  2008-11-10 12:29 ---
(In reply to comment #4)
> There are two causes where GCC generates unneeded TST instructions.
> A) General arithmetic 
>  lsr.l #1,D0 
>  tst.l d0
>  jbne ...
>
> This tst instruction is unneeded as the LSR is setting the flags correctly
> already.

This is NOT correct. LSL does write to the condition codes, but not all of it.
In particular, the bit involved in the not-equal test is not set.

This TST *is* required.

> B) subq.l #1,D1
>   tst.l d1
>   jbne ...
> 
> This unneeded TST is related to the compile option used.
> If you compile the source with "-O2" then the second unneeded TST instructions
> are not included in the source.

Please check the code mode carefully. This TST is not related to the SUBQ
instruction. This TST is related to the LSL instruction - the TST is a branch
target.

The compiler has combined the initial and subsequent loop condition tests into
one test, thus saving space, as per the -Os requirements. In this case there is
an alternative, more speed efficient solution, but that is a separate problem,
and not a misuse of the TST instruction.

As you say, the compiler gets it right at -O2, so the machine description is
clearly correct, in this respect.


-- 

ams at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/37807] Exponential compile time with MMX builtins.

[ubizjak at gmail dot com]

--- Comment #15 from ubizjak at gmail dot com  2008-11-10 12:24 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37809] [4.2/4.3 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2008-11-10 12:24 ---
Fixed everywhere.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37809] [4.2/4.3 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi

[uros at gcc dot gnu dot org]

--- Comment #10 from uros at gcc dot gnu dot org  2008-11-10 12:22 ---
Subject: Bug 37809

Author: uros
Date: Mon Nov 10 12:20:55 2008
New Revision: 141737

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141737
Log:
Backport from mainline:
2008-11-10  Ralph Loader  <[EMAIL PROTECTED]>

PR middle-end/37807
PR middle-end/37809
* combine.c (force_to_mode): Do not process vector types.

* rtlanal.c (nonzero_bits1): Do not process vector types.
(num_sign_bit_copies1): Likewise.

testsuite/ChangeLog:

Backport from mainline:
2008-11-10  Ralph Loader  <[EMAIL PROTECTED]>

PR middle-end/37807
PR middle-end/37809
* gcc/testsuite/gcc.target/i386/mmx-8.c: New test.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/mmx-8.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/combine.c
branches/gcc-4_2-branch/gcc/rtlanal.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37807] Exponential compile time with MMX builtins.

[uros at gcc dot gnu dot org]

--- Comment #14 from uros at gcc dot gnu dot org  2008-11-10 12:22 ---
Subject: Bug 37807

Author: uros
Date: Mon Nov 10 12:20:55 2008
New Revision: 141737

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141737
Log:
Backport from mainline:
2008-11-10  Ralph Loader  <[EMAIL PROTECTED]>

PR middle-end/37807
PR middle-end/37809
* combine.c (force_to_mode): Do not process vector types.

* rtlanal.c (nonzero_bits1): Do not process vector types.
(num_sign_bit_copies1): Likewise.

testsuite/ChangeLog:

Backport from mainline:
2008-11-10  Ralph Loader  <[EMAIL PROTECTED]>

PR middle-end/37807
PR middle-end/37809
* gcc/testsuite/gcc.target/i386/mmx-8.c: New test.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/mmx-8.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/combine.c
branches/gcc-4_2-branch/gcc/rtlanal.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/33304] Bootstrap failure on solaris2 using cc due to empty macro arguments

[aph at gcc dot gnu dot org]

--- Comment #4 from aph at gcc dot gnu dot org  2008-11-10 12:10 ---
Subject: Bug 33304

Author: aph
Date: Mon Nov 10 12:08:55 2008
New Revision: 141735

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141735
Log:
2008-11-10  Andrew Haley  <[EMAIL PROTECTED]>

Backport from mainline:

PR bootstrap/33304
* vec.h (VEC_TA): New.
(DEF_VEC_I, DEF_VEC_P, DEF_VEC_ALLOC_I, DEF_VEC_ALLOC_P,
DEF_VEC_O, DEF_VEC_ALLOC_O: Use VEC_TA.
* c-common.c (C_COMMON_FIXED_TYPES_SAT): New macro.
(C_COMMON_FIXED_MODE_TYPES_SAT): New macro.
(C_COMMON_FIXED_TYPES): Remove first arg.
(C_COMMON_FIXED_MODE_TYPES): Likewise.
* tree.c (MAKE_FIXED_TYPE_NODE): Break into two macros,
MAKE_FIXED_TYPE_NODE and MAKE_FIXED_TYPE_NODE_WIDTH in order
not to use empty macro arguments.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/c-common.c
branches/gcc-4_3-branch/gcc/tree.c
branches/gcc-4_3-branch/gcc/vec.h


-- 


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

[Bug c++/38067] New: monetary_members.cc: 4 * call to wrong C++ delete

[dcb314 at hotmail dot com]

I just had a look at some of the source code of the compiler
gcc version 4.4.0 snapshot 20081107.

$ egrep "new|delete" libstdc++-v3/config/locale/gnu/monetary_members.cc | fgrep
__wcs_ps
  __wcs_ps = new wchar_t[__len];
  delete __wcs_ps;
  __wcs_ps = new wchar_t[__len];
  delete __wcs_ps;

The two calls to delete look wrong to me. Maybe delete [] was intended ?

Similar fun & games at

$ egrep "new|delete" libstdc++-v3/config/locale/gnu/monetary_members.cc | fgrep
__wcs_ns
  __wcs_ns = new wchar_t[__len];
  delete __wcs_ns;
  __wcs_ns = new wchar_t[__len];
  delete __wcs_ns;

Again, maybe delete [] was intended ?


-- 
   Summary: monetary_members.cc: 4 * call to wrong C++ delete
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com


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

[Bug middle-end/37809] [4.2/4.3 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi

[uros at gcc dot gnu dot org]

--- Comment #9 from uros at gcc dot gnu dot org  2008-11-10 10:45 ---
Subject: Bug 37809

Author: uros
Date: Mon Nov 10 10:43:35 2008
New Revision: 141734

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141734
Log:
PR middle-end/37807
PR middle-end/37809
* combine.c (force_to_mode): Do not process vector types.

* rtlanal.c (nonzero_bits1): Do not process vector types.
(num_sign_bit_copies1): Likewise.

testsuite/ChangeLog:

PR middle-end/37807
PR middle-end/37809
* gcc/testsuite/gcc.target/i386/mmx-8.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/mmx-8.c
  - copied unchanged from r141732,
trunk/gcc/testsuite/gcc.target/i386/mmx-8.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/combine.c
branches/gcc-4_3-branch/gcc/rtlanal.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37807] Exponential compile time with MMX builtins.

[uros at gcc dot gnu dot org]

--- Comment #13 from uros at gcc dot gnu dot org  2008-11-10 10:45 ---
Subject: Bug 37807

Author: uros
Date: Mon Nov 10 10:43:35 2008
New Revision: 141734

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141734
Log:
PR middle-end/37807
PR middle-end/37809
* combine.c (force_to_mode): Do not process vector types.

* rtlanal.c (nonzero_bits1): Do not process vector types.
(num_sign_bit_copies1): Likewise.

testsuite/ChangeLog:

PR middle-end/37807
PR middle-end/37809
* gcc/testsuite/gcc.target/i386/mmx-8.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/mmx-8.c
  - copied unchanged from r141732,
trunk/gcc/testsuite/gcc.target/i386/mmx-8.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/combine.c
branches/gcc-4_3-branch/gcc/rtlanal.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36478] [4.3/4.4 regression] warning not emitted when code expanded from macro

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-11-10 10:15 ---
2 locations won't help you either.
void foo ()
{
#define EMPTY
  while (0)EMPTY;
}
won't warn when compiled with g++ -Wempty-body -O2, but will with
g++ -Wempty-body -O2 -save-temps (i.e. ccache etc.).  I think it is unfortunate
this -Wempty-body extension was accepted for 4.3, and if we want to make it
work, we really have to handle it at the preprocessor level.


-- 


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

[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning

[jamborm at gcc dot gnu dot org]

--- Comment #8 from jamborm at gcc dot gnu dot org  2008-11-10 10:06 ---
The previous patch resulted into a regression on m32c-unknown-elf and
thus I prepared a less intrusive one below.  See also:

* http://gcc.gnu.org/ml/gcc/2008-11/msg00058.html and
* http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00353.html

The patch is pending approval in the mailing list.

2008-11-07  Martin Jambor  <[EMAIL PROTECTED]>

* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not check
for INDIRECT_REFs.
(forward_propagate_addr_into_variable_array_index): Check that the
offset is not computed from a MULT_EXPR, use is_gimple_assign rather
than the gimple code directly.


Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 141673)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -613,19 +613,27 @@ forward_propagate_addr_into_variable_arr
   tree index;
   gimple offset_def, use_stmt = gsi_stmt (*use_stmt_gsi);

-  /* Try to find an expression for a proper index.  This is either
- a multiplication expression by the element size or just the
- ssa name we came along in case the element size is one.  */
+  /* Get the offset's defining statement.  */
+  offset_def = SSA_NAME_DEF_STMT (offset);
+
+  /* Try to find an expression for a proper index.  This is either a
+ multiplication expression by the element size or just the ssa name we
came
+ along in case the element size is one. In that case, however, we do not
+ allow multiplications because they can be computing index to a higher
+ level dimension (PR 37861). */
   if (integer_onep (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (def_rhs)
-index = offset;
-  else
 {
-  /* Get the offset's defining statement.  */
-  offset_def = SSA_NAME_DEF_STMT (offset);
+  if (is_gimple_assign (offset_def)
+ && gimple_assign_rhs_code (offset_def) == MULT_EXPR)
+   return false;

+  index = offset;
+}
+  else
+{
   /* The statement which defines OFFSET before type conversion
  must be a simple GIMPLE_ASSIGN.  */
-  if (gimple_code (offset_def) != GIMPLE_ASSIGN)
+  if (!is_gimple_assign (offset_def))
return false;

   /* The RHS of the statement which defines OFFSET must be a
@@ -802,9 +810,6 @@ forward_propagate_addr_expr_1 (tree name
   array_ref = TREE_OPERAND (def_rhs, 0);
   if (TREE_CODE (array_ref) != ARRAY_REF
   || TREE_CODE (TREE_TYPE (TREE_OPERAND (array_ref, 0))) != ARRAY_TYPE
-  /* Avoid accessing hidden multidimensional arrays in this way or VRP
-might give out bogus warnings (see PR 37861) */
-  || TREE_CODE (TREE_OPERAND (array_ref, 0)) == INDIRECT_REF
   || !integer_zerop (TREE_OPERAND (array_ref, 1)))
 return false;



-- 


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

[Bug middle-end/37807] Exponential compile time with MMX builtins.

[uros at gcc dot gnu dot org]

--- Comment #12 from uros at gcc dot gnu dot org  2008-11-10 09:09 ---
Subject: Bug 37807

Author: uros
Date: Mon Nov 10 09:08:15 2008
New Revision: 141732

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141732
Log:
PR middle-end/37807
PR middle-end/37809
* combine.c (force_to_mode): Do not process vector types.

* rtlanal.c (nonzero_bits1): Do not process vector types.
(num_sign_bit_copies1): Likewise.

testsuite/ChangeLog

PR middle-end/37807
PR middle-end/37809
* gcc/testsuite/gcc.target/i386/mmx-8.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/mmx-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi

[uros at gcc dot gnu dot org]

--- Comment #8 from uros at gcc dot gnu dot org  2008-11-10 09:09 ---
Subject: Bug 37809

Author: uros
Date: Mon Nov 10 09:08:15 2008
New Revision: 141732

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141732
Log:
PR middle-end/37807
PR middle-end/37809
* combine.c (force_to_mode): Do not process vector types.

* rtlanal.c (nonzero_bits1): Do not process vector types.
(num_sign_bit_copies1): Likewise.

testsuite/ChangeLog

PR middle-end/37807
PR middle-end/37809
* gcc/testsuite/gcc.target/i386/mmx-8.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/mmx-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog


-- 


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