[Bug fortran/33375] [4.3 Regression] ICE (segfault) gfortran.dg/common_6.f90

[ubizjak at gmail dot com]

--- Comment #14 from ubizjak at gmail dot com  2008-01-18 08:05 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

--- Comment #29 from bkoz at gcc dot gnu dot org  2008-01-18 08:35 ---

I asked for two votes:

1) keep removal of pre-iso includes, (ie current sources). Majority approves.

2) reinstate just iostream.h and fstream.h. Majority declines.

Therefore, I am closing this as WONTFIX as per Richard's suggestion.

-benjamin


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX


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

[Bug target/27880] [4.2/4.3 regression] undefined reference to `_Unwind_GetIPInfo'

[bkoz at gcc dot gnu dot org]

--- Comment #20 from bkoz at gcc dot gnu dot org  2008-01-18 08:45 ---

This patch seems good to me. What's the delay here?


-- 


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

[Bug debug/34844] [4.3 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-01-18 08:58 ---
(In reply to comment #1)

> I think dwarf2out_switch_text_section() is defined if DWARF2_DEBUGGING_INFO
> is defined.  So, it appears the attached change will fix the problem.

No, dwarf2out_switch_text_section() has to go out of DWARF2_DEBUGGING_INFO. I
didn't notice the #ifdef in the twisted maze of #ifdefs in dwarf2out.c

I'll commit the patch ASAP.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-18 08:58:38
   date||


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

[Bug fortran/34838] Internal Error: Can't convert LOGICAL(1) to LOGICAL(1)

[manfred99 at gmx dot ch]

--- Comment #4 from manfred99 at gmx dot ch  2008-01-18 08:59 ---
I bisected it using the binaries of Tobias:

gcc-trunk-x86_64-2008-01-15-r131542.tar.gz works
gcc-trunk-x86_64-2008-01-16-r131566.tar.gz is broken

inbetween there exist mainly only 2 relevant commits:
- r131553 Th. Koenig, fiddling with _gfortran_any_l1 and *logical.m4
- r131566 T. Burnus

I doubt somehow that the patch for PR 34817 will help. I will not have time
to check it myself in the next days, though.


-- 


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

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[rguenther at suse dot de]

--- Comment #30 from rguenther at suse dot de  2008-01-18 09:14 ---
Subject: Re:  [4.3 Regression] Revision 129442 breaks
 libstc++ API

On Fri, 18 Jan 2008, bkoz at gcc dot gnu dot org wrote:

> --- Comment #29 from bkoz at gcc dot gnu dot org  2008-01-18 08:35 ---
> 
> I asked for two votes:
> 
> 1) keep removal of pre-iso includes, (ie current sources). Majority approves.
> 
> 2) reinstate just iostream.h and fstream.h. Majority declines.
> 
> Therefore, I am closing this as WONTFIX as per Richard's suggestion.

Thanks.

Richard.


-- 


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

[Bug fortran/34784] [Regression 4.2, 4.3] implicit character(s) hides type of selected_int_kind intrinsic

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2008-01-18 09:25 ---
Dang it!  I posted the fix for this one on PR34785.

It has to hold until the weekend for reasons described there.

Paul


-- 


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

[Bug fortran/34785] internal compiler error for array constructor for sequence type

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2008-01-18 09:22 ---
(In reply to comment #3)
> I have a fix for this that I will apply as "obvious" overnight (in the EU, 
> that
> is:))
> Paul
except that it caused a FAIL on one platform and, on another, the testsuite
hung!!!  Anyway, it's on the right track and I'll try and sort it out this
weekend:

gfc_check_constructor_type (gfc_expr *e)
{
  try t;

  cons_state = CONS_START;
  gfc_clear_ts (&constructor_ts);
  gfc_clear_ts (&e->ts);  /* Fixes this bug. */

  t = check_constructor_type (e->value.constructor);
  if (t == SUCCESS && e->ts.type == BT_UNKNOWN)
e->ts = constructor_ts;

  return t;
}

Paul


-- 


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

[Bug middle-end/34843] Missing overflow diagnostic for Python 2.5's unicodeobject.c

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||diagnostic


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

[Bug fortran/34785] internal compiler error for array constructor for sequence type

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2008-01-18 09:33 ---
(In reply to comment #4)
Sorry, the above is the fix for PR34784.

This one is fixed by:

In trans-array.c (gfc_add_loop_ss_code)

case GFC_SS_CONSTRUCTOR:
  if (ss->expr->ts.type == BT_CHARACTER
&& ss->string_length == NULL)
get_array_ctor_all_strlen (&loop->pre, ss->expr,
   &ss->string_length);
  gfc_trans_array_constructor (loop, ss);
  break;

Paul


-- 


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

[Bug c++/34846] [4.3 regression] ICE on STL container iterator copy

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-01-18 09:33 ---
Looks related to PR34573.

Backtrace:

#0  0x010bacb1 in htab_find_with_hash (htab=0x0, 
element=0x2b899b95a300, hash=863155296)
at /space/rguenther/src/svn/trunk/libiberty/hashtab.c:566
#1  0x0047b935 in retrieve_local_specialization (tmpl=0x2b899b95a300)
at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:980
#2  0x004bd664 in tsubst (t=0x2b899b95a3c0, args=0x2b899b95d8a0, 
complain=tf_none, in_decl=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8859
#3  0x004bd7a4 in tsubst (t=0x2b899b95a480, args=0x2b899b95d8a0, 
complain=tf_none, in_decl=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8879
#4  0x004bd7a4 in tsubst (t=0x2b899b95a840, args=0x2b899b95d8a0, 
complain=tf_none, in_decl=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8879
...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||34573
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-18 09:33:56
   date||


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

[Bug debug/34844] [4.3 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-01-18 11:53 ---
Author: uros
Date: Fri Jan 18 09:55:15 2008
New Revision: 131626

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131626
Log:
PR debug/34484
* dwarf2out.c (dwarf2out_switch_text_section): Do not guard with
DWARF2_DEBUGGING_INFO.
(dwarf2out_note_section_used): Ditto.  Add prototype.
(have_multiple_function_sections, text_section_used,
cold_text_section_used, *cold_text_sections): Move declarations
before their uses.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2008-01-18 11:56 ---
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing
structures

> --- Comment #8 from dtemirbulatov at gmail dot com  2008-01-17 18:34 
> ---
> This regression happens after the SSA was merged in to the mainline

Yes because of the gimplifier ...

-- Pinski


-- 


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

[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2008-01-18 11:54 ---
Sorry, wrong PR number in the ChangeLog.


-- 


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

[Bug fortran/34848] internal compiler error with optional argument of character type and array return type

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-01-18 11:48 ---
Reduced testcase:
module krmod
contains
 function doit()
   implicit none
real :: doit1(100)
real :: doit
doit1 = tm_doit()
   return
 end function doit
 function tm_doit(genloc)
   implicit none
   character, optional  :: genloc
   real :: tm_doit(100)
 end function tm_doit
end module krmod



The optional argument has to be a character type and the return type has to be
an array


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2008-01-18 11:48:37
   date||
Summary|internal compiler error:|internal compiler error with
   |Segmentation fault/optional |optional argument of
   |arguments   |character type and array
   ||return type


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

[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs

[uros at gcc dot gnu dot org]

--- Comment #6 from uros at gcc dot gnu dot org  2008-01-18 09:56 ---
Subject: Bug 34484

Author: uros
Date: Fri Jan 18 09:55:15 2008
New Revision: 131626

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131626
Log:
PR debug/34484
* dwarf2out.c (dwarf2out_switch_text_section): Do not guard with
DWARF2_DEBUGGING_INFO.
(dwarf2out_note_section_used): Ditto.  Add prototype.
(have_multiple_function_sections, text_section_used,
cold_text_section_used, *cold_text_sections): Move declarations
before their uses.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

[manu at gcc dot gnu dot org]

--- Comment #14 from manu at gcc dot gnu dot org  2008-01-18 09:47 ---
(In reply to comment #12)
> 
> - I do not think this is fine. As end user I want to see my errors the same
> way at any optimization level.
> 

We strive to for this when it is feasible and reasonable, but there is a
trade-off between functionality and compilation speed. Detecting some errors
requires analyzing the code and performing transformations. This is precisely
what optimisations do. The higher the optimisation level, the deeper the
analysis and the larger the transformations. Doing the maximum analysis and
transformations at -O0 and throwing away the results would be pointless. Would
you like if -O0 were to take more time than -O3? Most users won't.

> My expectations are that regardless of optimization level I'll get my program
> functioning the same way, but with different memory consumption/speed.

If you believe this, you are going to be deeply disappointed by reality. Apart
from the unavoidable fact that bugs in the code (like in this case), race
conditions and hardware problems may be more evident with one optimisation or
another, there are issues with floating point precision (PR323) and others.

> I am not talking about out of bounds indices and possible reshuffling of
> variables in memory, I'm talking about arithmetic/logic expressions, i.e.
> 
> printf("some_var=%g\n", some_var);
> 
> should always print the same.
> 

That can't be the case always. Arithmetic/logic expressions have precision
errors that are different depending on the order of operations. And altering
the order of operations is precisely what you are asking when you enable
optimizations. Anyway, this is not the place for such theoretical discussion

If "gcc -O2 -Wstrict-overflow=5" does not give a warning, we may have a bug (or
it may be a case too difficult to detect). Could you try that, please?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug c++/34486] [4.1/4.2/4.3 regression] ICE invalid using declaration

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2008-01-18 11:27 ---
This is fixed by the same patch which fixes c++/34766


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/34486] [4.1/4.2/4.3 regression] ICE invalid using declaration

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2008-01-18 11:34 ---
I meant c++/34776, sorry.


-- 


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

[Bug fortran/34848] New: internal compiler error: Segmentation fault/optional arguments

[krefson at googlemail dot com]

Gfortran version 4.3.0 20080117 (experimental) [trunk revision 131592] (GCC)
gives an ICE on the following program.

$ gfortran -c ia.f90
ia.f90: In function 'doit':
ia.f90:12: internal compiler error: Segmentation fault

---
module krmod
contains
  function doit(genloc,vloc,scheme)
implicit none
character(len=6), optional,   intent(in)  :: genloc
real,optional, dimension(:), intent(in)  :: vloc
character(len=2), optional,   intent(out) :: scheme
real :: doit(100)
!-!
if(present(genloc)) then
   doit = tm_doit(genloc=genloc)
   if(present(scheme)) scheme = 'tm'
else
   doit = tm_doit(vloc=vloc)
   if(present(scheme)) scheme = 'tm'
endif
return
  end function doit
  function tm_doit(genloc,vloc)
implicit none
character(len=6), optional,   intent(in)  :: genloc
real,optional, dimension(:), intent(in)  :: vloc
real :: tm_doit(100)
tm_doit = 1.0
  end function tm_doit
end module krmod


-- 
   Summary: internal compiler error: Segmentation fault/optional
arguments
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: krefson at googlemail dot com
  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=34848

[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-01-18 12:09 ---
(In reply to comment #1)
> This is also true for C++ unless -pedantic is specified (which is confusing
> since I thought -pedantic-errors was the default for C++, but apparently this
> changed at some point). Using '-Wall -Wextra -ansi -std=c++98' gives no
> warning.
> 

Jack, why would you use "-ansi -std=c++98" in the same command-line? From
reading the current manual (for example,
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/), what do you think that
combination achieves?

I am trying to improve this part of the manual. See my current patch at
http://gcc.gnu.org/ml/gcc-patches/2008-01/txt00033.txt


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[steven at gcc dot gnu dot org]

--- Comment #10 from steven at gcc dot gnu dot org  2008-01-18 12:04 ---
Re. comment 7:

What does the initial RTL look like with GCC 3.3 and with a post tree-ssa
compiler?


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-01-18 12:08 
---
For 3.3-hammer I get (x86_64):

;; Function f

(note 2 0 3 NOTE_INSN_DELETED)

(note 3 2 4 NOTE_INSN_FUNCTION_BEG) 

(note 4 3 5 NOTE_INSN_DELETED)

(note 5 4 6 NOTE_INSN_DELETED)

(note 6 5 8 NOTE_INSN_DELETED)

(insn 8 6 9 (nil) (set (reg/v:SI 58 [  ])
(const_int 0 [0x0])) -1 (nil)
(nil))

(insn 9 8 10 (nil) (set (strict_low_part (subreg:QI (reg/v:SI 58 [ 
]) 0))
(const_int 1 [0x1])) -1 (nil)
(nil))

(insn 10 9 11 (nil) (set (reg:DI 59)
(const_int 2 [0x2])) -1 (nil)
(expr_list:REG_EQUAL (const_int 2 [0x2])
(nil)))

(insn 11 10 13 (nil) (set (zero_extract:DI (subreg:DI (reg/v:SI 58 [
 ]) 0)
(const_int 8 [0x8])
(const_int 8 [0x8]))
(reg:DI 59)) -1 (nil)
(nil))

(insn 13 11 14 (nil) (parallel [
(set (reg/v:SI 58 [  ])
(and:SI (reg/v:SI 58 [  ])
(const_int -16711681 [0xff00])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

(insn 14 13 16 (nil) (parallel [
(set (reg/v:SI 58 [  ])
(ior:SI (reg/v:SI 58 [  ])
(const_int 196608 [0x3])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

(insn 16 14 17 (nil) (parallel [
(set (reg/v:SI 58 [  ])
(and:SI (reg/v:SI 58 [  ])
(const_int 16777215 [0xff])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

(insn 17 16 18 (nil) (parallel [
(set (reg/v:SI 58 [  ])
(ior:SI (reg/v:SI 58 [  ])
(const_int 67108864 [0x400])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

(insn 18 17 19 (nil) (set (mem/s:SI (symbol_ref:DI ("u")) [2 u+0 S4 A8])
(reg/v:SI 58 [  ])) -1 (nil)
(nil))

(note 19 18 21 NOTE_INSN_FUNCTION_END)

(code_label 21 19 0 1 "" [0 uses])


while on the trunk I see:


;; Function f (f)


;;
;; Full RTL generated for this function:
;;
(note 1 0 3 NOTE_INSN_DELETED)

;; Start of basic block ( 0) -> 2
;; Pred edge  ENTRY [100.0%]  (fallthru)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 3 4 2 NOTE_INSN_FUNCTION_BEG)
;; End of basic block 2 -> ( 3) 

;; Succ edge  3 [100.0%]  (fallthru)

;; Start of basic block ( 2) -> 3
;; Pred edge  2 [100.0%]  (fallthru)
(note 4 2 5 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 5 4 6 3 t.c:12 (set (reg/f:DI 58)
(symbol_ref:DI ("u") )) -1 (nil))

(insn 6 5 7 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 58) [0 u.a+0 S1 A8])
(const_int 1 [0x1])) -1 (nil))

(insn 7 6 8 3 t.c:12 (set (reg/f:DI 59)
(const:DI (plus:DI (symbol_ref:DI ("u") )
(const_int 1 [0x1] -1 (nil))

(insn 8 7 9 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 59) [0 u.b+0 S1 A8])
(const_int 2 [0x2])) -1 (nil))

(insn 9 8 10 3 t.c:12 (set (reg/f:DI 60)
(const:DI (plus:DI (symbol_ref:DI ("u") )
(const_int 2 [0x2] -1 (nil))

(insn 10 9 11 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 60) [0 u.c+0 S1 A8])
(const_int 3 [0x3])) -1 (nil))

(insn 11 10 12 3 t.c:12 (set (reg/f:DI 61)
(const:DI (plus:DI (symbol_ref:DI ("u") )
(const_int 3 [0x3] -1 (nil))

(insn 12 11 17 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 61) [0 u.d+0 S1 A8])
(const_int 4 [0x4])) -1 (nil))
;; End of basic block 3 -> ( 4)

;; Succ edge  4 [100.0%]  (fallthru)

;; Start of basic block ( 3) -> 4
;; Pred edge  3 [100.0%]  (fallthru)
(note 17 12 14 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(jump_insn 14 17 15 4 t.c:13 (set (pc)
(label_ref 16)) -1 (nil))
;; End of basic block 4 -> ( 6)

;; Succ edge  6 [100.0%] 

(barrier 15 14 13)

;; Start of basic block () -> 5
(code_label 13 15 18 5 1 "" [0 uses])

(note 18 13 16 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
;; End of basic block 5 -> ( 6) 

;; Succ edge  6 [100.0%]  (fallthru)

;; Start of basic block ( 4 5) -> 6
;; Pred edge  4 [100.0%]
;; Pred edge  5 [100.0%]  (fallthru)
(code_label 16 18 19 6 2 "" [1 uses])

(note 19 16 0 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
;; End of basic block 6 -> ( 1)

;; Succ edge  EXIT [100.0%]  (fallthru)


-- 


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

[Bug ada/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2008-01-18 12:35 ---
So 3.3 expanded the initializer into sets of the individual components, but
with ANDs and ORs and a single MEM store, instead of MEM stores to the
individual components.

It seems to me that this is not something you'd want to fix with a tree
optimizer.  Maybe some local (i.e. per basic block) RTL pass:
1. Collect all stores
2. Find related stores
3. Combine related stores where possible and cheaper

I don't think this is not fixable for GCC 4.3.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |ada


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

[Bug c++/34850] [4.3 Regression] Recursive BLOCK tree causes compilation to hang during diagnostics

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|Recursive BLOCK tree|[4.3 Regression] Recursive
   ||BLOCK tree causes
   ||compilation to hang during
   ||diagnostics
   Target Milestone|--- |4.3.0


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

[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type

[ian at gcc dot gnu dot org]

--- Comment #12 from ian at gcc dot gnu dot org  2008-01-18 15:25 ---
Subject: Bug 33407

Author: ian
Date: Fri Jan 18 15:25:02 2008
New Revision: 131629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131629
Log:
PR c++/33407
./:
* tree.h (DECL_IS_OPERATOR_NEW): Define.
(struct tree_function_decl): Add new field operator_new_flag.
* tree-inline.c (expand_call_inline): When inlining a call to
operator new, force the return value to go into a variable, and
set DECL_NO_TBAA_P on that variable.
* c-decl.c (merge_decls): Merge DECL_IS_OPERATOR_NEW flag.
cp/:
* decl.c (duplicate_decls): Copy DECL_IS_OPERATOR_NEW flag.
(grok_op_properties): For NEW_EXPR and VEC_NEW_EXPR set
DECL_IS_OPERATOR_NEW flag.
testsuite/:
* g++.dg/init/new26.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/new26.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree.h


-- 


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

[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2008-01-18 16:54 ---
Subject: Re:  [4.3 Regression] ICE on gcc.dg/pr34233.c for
 MIPS

On Fri, 18 Jan 2008, steven at gcc dot gnu dot org wrote:

> --- Comment #5 from steven at gcc dot gnu dot org  2008-01-18 16:50 
> ---
> Confirmed.
> 
> ignoring nonexistent directory
> "/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include"
> ignoring nonexistent directory
> "/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include-fixed"
> ignoring nonexistent directory
> "/usr/local/lib/../mipsel-unknown-linux-gnu/sys-include"
> ignoring nonexistent directory
> "/usr/local/lib/../mipsel-unknown-linux-gnu/include"
> #include "..." search starts here:
> #include <...> search starts here:
> End of search list.
> pr34233.c: In function 'foo':
> pr34233.c:7: error: unrecognizable insn:
> (insn 8 7 9 3 pr34233.c:6 (set (reg:DF 198)
> (div:DF (const_double:DF 1.0e+0 [0x0.8p+1])
> (reg:DF 196))) -1 (nil))
> pr34233.c:7: internal compiler error: in extract_insn, at recog.c:1990
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

Does

double foo(void)
{
  return 1.0/0.0;
}

build?


-- 


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

[Bug libstdc++/34480] Argument packs treat __null oddly

[dgregor at gcc dot gnu dot org]

--- Comment #5 from dgregor at gcc dot gnu dot org  2008-01-18 16:33 ---
Suspended for now. We'll pick up the library work again once the C++ committee
has resolved this issue. 


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
  Component|c++ |libstdc++


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

[Bug middle-end/34843] Missing overflow diagnostic for Python 2.5's unicodeobject.c

[ian at airs dot com]

--- Comment #2 from ian at airs dot com  2008-01-18 16:32 ---
When I compile this code with current mainline with -O3 -Wstrict-overflow=3 I
get the following warnings:

Objects/unicodeobject.c: In function ‘unicode_startswith’:
Objects/unicodeobject.c:6943: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c:6947: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c: In function ‘unicode_endswith’:
Objects/unicodeobject.c:6989: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c:6992: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c: In function ‘unicode_expandtabs’:
Objects/unicodeobject.c:5719: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c:5727: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c: In function ‘rsplit’:
Objects/unicodeobject.c:368: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c: In function ‘PyUnicodeUCS4_Join’:
Objects/unicodeobject.c:4659: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c: In function ‘PyUnicodeUCS4_Compare’:
Objects/unicodeobject.c:5376: warning: assuming signed overflow does not occur
when changing X +- C1 cmp C2 to X cmp C1 +- C2
Objects/unicodeobject.c:5376: warning: assuming signed overflow does not occur
when changing X +- C1 cmp C2 to X cmp C1 +- C2

The code you are talking about seems to be around line 5722, so this seems to
provide the warnings that you are looking for.

So: which compiler are you using?  What output do you see?


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-18 16:32:45
   date||


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

[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type

[ian at airs dot com]

--- Comment #14 from ian at airs dot com  2008-01-18 16:17 ---
This is now fixed.


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/34808] [4.3 Regression] ICE in prescan_insns_for_dce

[kkojima at gcc dot gnu dot org]

--- Comment #8 from kkojima at gcc dot gnu dot org  2008-01-18 16:15 ---
(In reply to comment #6)
> But I don't feel strong either way.  Your patch looks correct to me.

Thanks!  I'll test it with bootstrap®test on x86 and ppc.


-- 


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

[Bug fortran/34782] tab format failure to display properly (regression vs. g77)

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2008-01-18 16:10 ---
> Thanks - how does one get and install the patch ?

Well, that is difficult - he did not post it. It was probably neither in the
final shape nor regression tested to make sure it does not break something of
the test suite.

I think he will send the patch today (or tomorrow) to the mailing list, i.e.
http://gcc.gnu.org/ml/fortran/2008-01/. Then you can either apply the patch and
build GCC yourself or you wait a between 15min to 36h until it has been
committed. If you don't build GCC yourself, add additionally up to 24h until
the provided binaries contain the patch.


-- 


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

[Bug rtl-optimization/34808] [4.3 Regression] ICE in prescan_insns_for_dce

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2008-01-18 16:05 ---
I tried to avoid setting XEXP(note,0) twice (once directly and once through
gen_rtx_INSN_LIST.

But I don't feel strong either way.  Your patch looks correct to me.


-- 


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

[Bug c++/34853] c++ runtime of basic_string has a bug in certain case

[myan at microstrategy dot com]

--- Comment #3 from myan at microstrategy dot com  2008-01-18 15:35 ---
Created an attachment (id=14970)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14970&action=view)
Java application


-- 


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

[Bug middle-end/34852] New: [4.3 Regression] Revision 131576 miscompiled 178.galgel

[hjl dot tools at gmail dot com]

Revision 131576:

http://gcc.gnu.org/ml/gcc-cvs/2008-01/msg00337.html

miscompiled 178.galgel in SPEC CPU 2000 on Linux/ia32 with -O2 -ffast-math.
178.galgel went into a finite loop.


-- 
   Summary: [4.3 Regression]  Revision 131576 miscompiled 178.galgel
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
 GCC build triplet: hubicka
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/34853] New: c++ runtime of basic_string has a bug in certain case

[myan at microstrategy dot com]

The following change in basic_string.tcc is not valid in my usage. A java
application loads c++ jni shared library that is compiled with
-D_GLIBCXX_FULLY_DYNAMIC_STRING. Please see attached test files.

Revision 95358 - (view) (download) - [select for diffs] 
Modified Mon Feb 21 23:25:08 2005 UTC (2 years, 10 months ago) by paolo 
Original Path: trunk/libstdc++-v3/include/bits/basic_string.tcc 
File length: 33828 byte(s) 
Diff to previous 91466 (colored) 
2005-02-21  Paolo Carlini  <[EMAIL PROTECTED]>

* include/bits/basic_string.tcc (_Rep::_M_destroy): Don't
check for this == &_S_empty_rep, it's always false, here.


-- 
   Summary: c++ runtime of basic_string has a bug in certain case
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: myan at microstrategy dot com


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

[Bug libstdc++/34851] New: libstdc++ isn't parallel build safe

[hjl dot tools at gmail dot com]

With revision 131628, on Intel64 quad-core machine with "make -j 4", I got

/bin/sh: ./config.status: No such file or directory
make[4]: *** [Makefile] Error 127
make[4]: Leaving directory
`/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3'
make[3]: *** [all-target-libstdc++-v3] Error 2

It may be caused by

http://gcc.gnu.org/ml/libstdc++/2008-01/msg00059.html


-- 
   Summary: libstdc++ isn't parallel build safe
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
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=34851

[Bug c++/34850] [4.3 Regression] Recursive BLOCK tree causes compilation to hang during diagnostics

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-01-18 15:09 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-18 14:53:38 |2008-01-18 15:09:41
   date||


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

[Bug c++/34850] [4.3 Regression] Recursive BLOCK tree causes compilation to hang during diagnostics

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-01-18 14:53 ---
The recursion is created by set_block_origin_self (), called from

#0  set_block_origin_self (stmt=0x2b4ce448cd80)
at /space/rguenther/src/svn/trunk/gcc/integrate.c:105
#1  0x0098ca87 in set_decl_origin_self (decl=0x2b4ce4479680)
at /space/rguenther/src/svn/trunk/gcc/integrate.c:154
#2  0x00810f41 in gen_decl_die (decl=0x2b4ce4479680, 
context_die=0x2b4ce445e0c0)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13873
#3  0x008129d3 in dwarf2out_decl (decl=0x2b4ce4479680)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:14214
#4  0x008880c7 in rest_of_handle_final ()
at /space/rguenther/src/svn/trunk/gcc/final.c:4152

while we still (after that), try to emit diagnostics via

#0  0x0056ae92 in cp_print_error_function (context=0x15c5a60, 
diagnostic=0x7fffc70736b0)
at /space/rguenther/src/svn/trunk/gcc/cp/error.c:2426
#1  0x0056a9f4 in cp_diagnostic_starter (context=0x15c5a60, 
diagnostic=0x7fffc70736b0)
at /space/rguenther/src/svn/trunk/gcc/cp/error.c:2364
#2  0x007e2168 in diagnostic_report_diagnostic (context=0x15c5a60, 
diagnostic=0x7fffc70736b0)
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:421
#3  0x007e25e4 in warning (opt=0, 
gmsgid=0x112a8e8 "%Kcall to %qs declared with attribute warning: %s")
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:511
#4  0x00866d15 in expand_expr_real_1 (exp=0x2b4ce44e5230, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:8043
#5  0x0085ff13 in expand_expr_real (exp=0x2b4ce44e5230, 
target=0x2b4ce3a92400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:7094
#6  0x00a95a45 in expand_expr (exp=0x2b4ce44e5230, 
target=0x2b4ce3a92400, mode=VOIDmode, modifier=EXPAND_NORMAL)
at /space/rguenther/src/svn/trunk/gcc/expr.h:514
#7  0x00a977db in expand_expr_stmt (exp=0x2b4ce44e5230)
at /space/rguenther/src/svn/trunk/gcc/stmt.c:1361
#8  0x00fd8e9a in expand_gimple_basic_block (bb=0x2b4ce44c8f00)
at /space/rguenther/src/svn/trunk/gcc/cfgexpand.c:1609
#9  0x00fda700 in tree_expand_cfg ()
at /space/rguenther/src/svn/trunk/gcc/cfgexpand.c:1918

thus from expanding another function.

Bummer.


-- 

rguenth 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-01-18 14:53:38
   date||


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

[Bug c++/34850] Recursive BLOCK tree

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-18 14:44 ---
Created an attachment (id=14967)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14967&action=view)
reduced testcase


-- 


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

[manu at gcc dot gnu dot org]

-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|2008-01-18 14:49:09 |2008-01-18 14:49:26
   date||


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

[Bug fortran/34782] tab format failure to display properly (regression vs. g77)

[barry dot j dot mcinnes at noaa dot gov]

--- Comment #6 from barry dot j dot mcinnes at noaa dot gov  2008-01-18 
14:40 ---
Subject: Re:  tab format failure to display properly
 (regression vs. g77)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks - how does one get and install the patch ?

On 1/18/08 7:25 AM, jvdelisle at gcc dot gnu dot org wrote:
| --- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-01-18
14:25 ---
| Found it, Patch is on the way
|
|

- --
- ---
Barry McInnes
325 Broadway
Boulder CO 80304
(303)4976231
[EMAIL PROTECTED]
- ---
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHkLpGKoTeRnsNi5kRAi+6AJ9hIWsh8WlyybETu1i6RPxB1LCKkwCfZyFf
tRJSc6IX9rqPWESUc5IyJSQ=
=4/F4
-END PGP SIGNATURE-


-- 


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

[Bug c++/34850] New: Recursive BLOCK tree

[rguenth at gcc dot gnu dot org]

Compilation of the attached testcase hangs in 

0x0056aedc in cp_print_error_function (context=0x15c5a60, 
diagnostic=0x7fff955f6c30)
at /space/rguenther/src/svn/trunk/gcc/cp/error.c:2426
2426  while (TREE_CODE (ao) == BLOCK &&
BLOCK_ABSTRACT_ORIGIN (ao))
2427ao = BLOCK_ABSTRACT_ORIGIN (ao);

because BLOCK_ABSTRACT_ORIGIN (ao) == ao.

If you build with -O2 -g.  Building without -g fixes the problem
(possibly the BLOCK is thrown away as unused).


-- 
   Summary: Recursive BLOCK tree
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug rtl-optimization/34808] [4.3 Regression] ICE in prescan_insns_for_dce

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2008-01-18 14:42 ---
With the patch in #4, .166r.split1 looks like:

(insn:HI 100 103 179 15 xxx.c:74 (set (subreg:SI (reg:DI 198 [ regno ]) 0)
(reg/v:SI 159 [ regno ])) 172 {movsi_ie} (insn_list:REG_LIBCALL 180
(expr_list:REG_NO_CONFLICT (reg/v:SI 159 [ regno ])
(nil

(insn 179 100 180 15 xxx.c:74 (parallel [
(set (subreg:SI (reg:DI 198 [ regno ]) 4)
(ashift:SI (reg/v:SI 159 [ regno ])
(const_int 1 [0x1])))
(set (reg:SI 147 t)
(lt:SI (reg/v:SI 159 [ regno ])
(const_int 0 [0x0])))
]) -1 (nil))

(insn 180 179 106 15 xxx.c:74 (set (subreg:SI (reg:DI 198 [ regno ]) 4)
(neg:SI (reg:SI 147 t))) -1 (insn_list:REG_RETVAL 0 (nil)))

It should be REG_RETVAL 100 instead of REG_RETVAL 0, shouldn't be?
How does look the patch below?

--- ORIG/trunk/gcc/emit-rtl.c   2008-01-15 09:35:12.0 +0900
+++ LOCAL/trunk/gcc/emit-rtl.c  2008-01-18 21:12:39.0 +0900
@@ -3136,7 +3136,7 @@ try_split (rtx pat, rtx trial, int last)
   rtx before = PREV_INSN (trial);
   rtx after = NEXT_INSN (trial);
   int has_barrier = 0;
-  rtx tem, note_retval;
+  rtx tem, note_retval, note_libcall;
   rtx note, seq;
   int probability;
   rtx insn_last, insn;
@@ -3284,6 +3284,18 @@ try_split (rtx pat, rtx trial, int last)
  XEXP (note_retval, 0) = insn_last;
  break;

+   case REG_RETVAL:
+ /* Relink the insns with REG_RETVAL note and with REG_LIBCALL note
+after split.  */
+ REG_NOTES (insn_last) 
+   = gen_rtx_INSN_LIST (REG_RETVAL,
+XEXP (note, 0),
+REG_NOTES (insn_last)); 
+
+ note_libcall = find_reg_note (XEXP (note, 0), REG_LIBCALL, NULL);
+ XEXP (note_libcall, 0) = insn_last;
+ break;
+
default:
  break;
}


-- 


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

[Bug rtl-optimization/34849] Missed autoincrement oppurtunities thanks to a different basic block structure.

[ramana dot radhakrishnan at celunite dot com]

--- Comment #3 from ramana dot radhakrishnan at celunite dot com  
2008-01-18 14:37 ---
Add CC


-- 

ramana dot radhakrishnan at celunite dot com changed:

   What|Removed |Added

 CC||pranav dot bhandarkar at
   ||gmail dot com, dave at
   ||icerasemi dot com


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

[Bug rtl-optimization/34849] Missed autoincrement oppurtunities thanks to a different basic block structure.

[ramana dot radhakrishnan at celunite dot com]

--- Comment #2 from ramana dot radhakrishnan at celunite dot com  
2008-01-18 14:35 ---
(In reply to comment #1)
> Which optimization level?
-O2 . 

> 
> Why does cross-jumping not optimize this?
> 

Will check on cross-jumping and get back. 


-- 


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

[Bug rtl-optimization/34849] Missed autoincrement oppurtunities thanks to a different basic block structure.

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2008-01-18 14:26 ---
Which optimization level?

Why does cross-jumping not optimize this?


-- 


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

[Bug rtl-optimization/34849] New: Missed autoincrement oppurtunities thanks to a different basic block structure.

[ramana dot radhakrishnan at celunite dot com]

Whilst investigating a missed optimization oppurtunity in comparison to gcc 3.4
I came across this case. 

void foo (int n, int in[], int res[])
{
  int i;
  for (i=0; i:
  if (n > 0)
goto ;
  else
goto ;

:
  i = 0;
  ivtmp.19 = 0;

:
  if (MEM[base: in, index: ivtmp.19] != 0)
goto ;
  else
goto ;

:
  MEM[base: res, index: ivtmp.19] = 4660;
  goto ;

:
  MEM[base: res, index: ivtmp.19] = 39030;

:
  i = i + 1;
  ivtmp.19 = ivtmp.19 + 4;
  if (n > i)
goto ;
  else
goto ;

:
  return;

}

If you notice ivtmp.19 can be used for post-increment based addressing modes. 


Note that GCC 3.4 did not have another basic block for the else case, the basic
block for the else case got merged with the tail block of the loop and hence
auto-inc could get generated in the else case and not in the if side of things.
Can be reproduced with today's head of 4.3.0


-- 
   Summary: Missed autoincrement oppurtunities thanks to a different
basic block structure.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at celunite dot com
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: arm-none-eabi


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

[sergstesh at yahoo dot com]

--- Comment #15 from sergstesh at yahoo dot com  2008-01-18 14:08 ---
With CFLAGS='-O2 -Wstrict-overflow=5' still there is no warnings in
'make_check.log':

"

[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep -i warn make.log
sndfile.c:491: warning: the address of 'sf_error' will never be NULL
sndfile-play.c:292: warning: the address of ‘status’ will always
evaluate as ‘true’
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep -i warn make_check.log
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep -P '\-Wstrict-overflow=5' make.log | wc -l
341
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>  
",

so I think you are right there is a bug in gcc.

And there is apparently another bug.

If I do _not_ have "-Wstrict-overflow", I _do_ have these warnings during
compilation:

"
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep "comparison between signed and unsigned"
../../gcc-4.2.2-O1/libsndfile-1.0.17/make.log
floating_point_test.c:338: warning: comparison between signed and unsigned
floating_point_test.c:388: warning: comparison between signed and unsigned
floating_point_test.c:438: warning: comparison between signed and unsigned
floating_point_test.c:488: warning: comparison between signed and unsigned
floating_point_test.c:538: warning: comparison between signed and unsigned
floating_point_test.c:588: warning: comparison between signed and unsigned
floating_point_test.c:638: warning: comparison between signed and unsigned
floating_point_test.c:688: warning: comparison between signed and unsigned
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
".

If I have "-Wstrict-overflow", I do _not_ have the above warnings:

"
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep "comparison between signed and unsigned" make.log
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17> 
".

I believe I should have the warnings in both cases.

Folks, libsndfile is easy to compile - it has (kind of) no external 
dependencies, i.e. it depends only on basic libraries like libm, glibc, etc.,
so you can easily conduct such experiments yourselves - the the needed "beef",
including libsdnfile sources, is in the uploaded file.


-- 


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

[Bug rtl-optimization/34808] [4.3 Regression] ICE in prescan_insns_for_dce

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2008-01-18 14:03 ---
Created an attachment (id=14966)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14966&action=view)
Handle REG_RETVAL notes in try_split

Untested, etc.  But the ICE for the test case goes away.  This patch needs a
foster parent, I can't properly test it at the moment.

General notice: libcall notes must die.


-- 


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

[Bug middle-end/34801] [4.3 Regression] FAIL: gcc.dg/Warray-bounds.c

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-18 12:58 ---
Subject: Bug 34801

Author: rguenth
Date: Fri Jan 18 12:57:42 2008
New Revision: 131628

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

PR middle-end/34801
* gcc.dg/Warray-bounds.c: XFAIL two tests, remove one
redundant one.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds.c


-- 


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

[Bug debug/34844] [4.3 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-18 12:47 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-01-18 12:43 
---
The patch should indeed work and I suggest we go forward with it for 4.3.

For 4.4, can we use this sort of flag (name it no_tbaa_for_result) to handle
both the operator new and the placement new case where for the latter we
at the moment do the CHANGE_DYNAMIC_TYPE_EXPR thing?  After all, the
placement new also gets inlined from its libstdc++ implementation.


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-01-18 12:45 
---
Right.  You also need to watch for TBAA problems in the RTL you create.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|ada |middle-end


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

[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-01-18 12:45 ---
It's a regression - and I might be guilty of it with my Bind(C) patches...


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
Summary|internal compiler error with|[4.3 Regression] internal
   |optional argument of|compiler error with optional
   |character type and array|argument of character type
   |return type |and array return type


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

[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2008-01-18 16:53 ---
The offending insn is already produced in "expand".
GCC ICEs the first time it calls recog() on it.


-- 


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

[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2008-01-18 16:50 ---
Confirmed.

ignoring nonexistent directory
"/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/../mipsel-unknown-linux-gnu/sys-include"
ignoring nonexistent directory
"/usr/local/lib/../mipsel-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
pr34233.c: In function 'foo':
pr34233.c:7: error: unrecognizable insn:
(insn 8 7 9 3 pr34233.c:6 (set (reg:DF 198)
(div:DF (const_double:DF 1.0e+0 [0x0.8p+1])
(reg:DF 196))) -1 (nil))
pr34233.c:7: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

steven 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-01-18 16:50:04
   date||


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

[Bug middle-end/34843] Missing overflow diagnostic for Python 2.5's unicodeobject.c

[ismail at pardus dot org dot tr]

--- Comment #3 from ismail at pardus dot org dot tr  2008-01-18 16:41 
---
Looks like -Wall being at the end disables this warning uh oh. This is invalid,
sorry for taking your time.


-- 

ismail at pardus dot org dot tr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c++/34480] Argument packs treat __null oddly

[dgregor at gcc dot gnu dot org]

--- Comment #4 from dgregor at gcc dot gnu dot org  2008-01-18 16:32 ---
Confirmed. This is the right behavior according to the C++0x specification, but
the backward-compatibility issue with push_back is a problem. The C++ committee
is aware is the issue.


-- 

dgregor 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-01-18 16:32:16
   date||


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

[Bug c/34803] wrong code for dereferencing type-punned pointer

[gin at mo dot msk dot ru]

--- Comment #6 from gin at mo dot msk dot ru  2008-01-18 16:21 ---
Subject: Re:  wrong code for dereferencing type-punned pointer

> looks good for 4.2.

Can we see (assembler) output of that 4.2, with those same
`-fno-strict-aliasing -O3 -fno-strict-aliasing' optimization options,
for the same preprocessed input as posted in the initial bug
description,
?
Was that some recent snapshot from 4.2 version control branch, or what
is the version?


-- 


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

[Bug rtl-optimization/34808] [4.3 Regression] ICE in prescan_insns_for_dce

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2008-01-18 16:07 ---
Ah, and of course gen_rtx_INSN_LIST does not set XEXP(0) of the REG_LIBCALL
note.  Silly me ;-)


-- 


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

[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2008-01-18 16:56 ---
Subject: Re:  [4.3 Regression] ICE on gcc.dg/pr34233.c for
 MIPS

On Fri, 18 Jan 2008, steven at gcc dot gnu dot org wrote:

> --- Comment #6 from steven at gcc dot gnu dot org  2008-01-18 16:53 
> ---
> The offending insn is already produced in "expand".
> GCC ICEs the first time it calls recog() on it.

It is emitted from expand_builtin_pow():

 /* If the original exponent was negative, reciprocate the
 result.  */
  if (n < 0)
op = expand_binop (mode, sdiv_optab, CONST1_RTX (mode),
   op, NULL_RTX, 0, OPTAB_LIB_WIDEN);

I guess we have to force CONST1_RTX to a register instead?

Richard.


-- 


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

[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type

[ian at airs dot com]

--- Comment #13 from ian at airs dot com  2008-01-18 16:01 ---
I think you're right.  If the call to placement new is not inlined, and if we
don't know anything special about it (which we currently don't), then it seems
to me that everything is bound to work OK.  It is only the inlining that makes
a difference.

Pity we didn't realize that before.  Still, the heart of
CHANGE_DYNAMIC_TYPE_EXPR is compute_tbaa_pruning, and that will remain.  What
can be removed is the code in cp/init.c which creates CHANGE_DYNAMIC_TYPE_EXPR
and the code in find_func_aliases which sets the no_tbaa_pruning flag.

I have a vague memory that there was some weird test case in PR 29286 which we
would need to reconsider.  But I couldn't find it in a quick look, and I'm not
sure my memory is correct.


-- 


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

[Bug target/34831] ICE on gcc.dg/pr34233.c for MIPS

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2008-01-18 17:02 ---
Does not fail unless -march=sb1 is given.
Thus not a regression until proven that older GCCs did not fail with this
option.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3 Regression] ICE on |ICE on gcc.dg/pr34233.c for
   |gcc.dg/pr34233.c for MIPS   |MIPS


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

[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS

[daney at gcc dot gnu dot org]

--- Comment #11 from daney at gcc dot gnu dot org  2008-01-18 18:15 ---
It is a regression, this works:

$ mipsel-linux-gcc -march=sb1 -ffast-math -c pr34233.c
$ mipsel-linux-gcc --version
mipsel-linux-gcc (GCC) 3.4.3

This doesn't:

$ gcc -march=sb1 -ffast-math -c pr34233.c
pr34233.c: In function 'foo':
pr34233.c:7: error: unrecognizable insn:
(insn 8 7 9 3 pr34233.c:6 (set (reg:DF 198)
(div:DF (const_double:DF 1.0e+0 [0x0.8p+1])
(reg:DF 196))) -1 (nil))
pr34233.c:7: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ gcc --version
gcc (GCC) 4.3.0 20080111 (experimental) [trunk revision 131473]

Also note that it only fails at -O0.

My inclination is to blame r131318, although I have not tested that theory.


-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.0
Summary|ICE on gcc.dg/pr34233.c for |[4.3 Regression] ICE on
   |MIPS|gcc.dg/pr34233.c for MIPS


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

[Bug c++/34853] c++ runtime of basic_string has a bug in certain case

[myan at microstrategy dot com]

--- Comment #5 from myan at microstrategy dot com  2008-01-18 15:35 ---
Created an attachment (id=14972)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14972&action=view)
shell script to run the test case


-- 


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

[Bug bootstrap/33200] install fails when trying to install fix-header since fix-header wasn't built

[aldot at gcc dot gnu dot org]

--- Comment #2 from aldot at gcc dot gnu dot org  2008-01-18 18:06 ---
Confirmed.

# Install supporting files for fixincludes to be run later.
install-mkheaders: stmp-int-hdrs $(STMP_FIXPROTO) install-itoolsdirs \
  macro_list fixinc_list
[snip]
if [ x$(STMP_FIXPROTO) != x ] ; then \
  $(INSTALL_SCRIPT) $(srcdir)/fixproto $(DESTDIR)$(itoolsdir)/fixproto
; \
  $(INSTALL_PROGRAM) build/fix-header$(build_exeext) \
$(DESTDIR)$(itoolsdir)/fix-header$(build_exeext) ; \
else :; fi

As you can see, fix-header is never built.

For reference:
toolchain_build_sh4/gcc-4.3.0-final$ gcc/xgcc -v
Using built-in specs.
Target: sh4-linux-uclibc
Configured with: /there.sh/toolchain_build_sh4/gcc-4.3.0/configure
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=sh4-linux-uclibc --enable-languages=c,fortran
--with-sysroot=/there.sh/build_sh4/staging_dir
--with-build-time-tools=/there.sh/build_sh4/staging_dir/usr/sh4-linux-uclibc/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared
--with-gmp=/there.sh/toolchain_build_sh4/gmp
--with-mpfr=/there.sh/toolchain_build_sh4/mpfr --disable-nls --enable-threads
--disable-multilib --disable-libgomp --disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.3.0 20080118 (experimental) (GCC) 


Given that i don't build c++, should fix-headers be installed in the first
place (for use a different compiler, perhaps)?


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
  Component|other   |bootstrap
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-18 18:06:21
   date||


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

[Bug fortran/34854] New: Valid USE statement is rejected

[fxcoudert at gcc dot gnu dot org]

I think both testcases below are valid, but gfortran rejects the
second one. They only differ in the order of USE statements.

$ cat test.f90
module common_init_conf
 integer, allocatable, dimension(:,:) :: Nmoltype_phase
end module common_init_conf

subroutine read_initial_config_nml()
 use common_init_conf, nmoltype_phase_com => nmoltype_phase
 use common_init_conf
 implicit none
 integer :: nmoltype_phase
 namelist /confNmoltypePhase/ nmoltype_phase
end subroutine read_initial_config_nml

$ gfortran -c test.f90 && echo OK
OK

$ cat test2.f90
module common_init_conf
 integer, allocatable, dimension(:,:) :: Nmoltype_phase
end module common_init_conf

subroutine read_initial_config_nml()
 use common_init_conf
 use common_init_conf, nmoltype_phase_com => nmoltype_phase
 implicit none
 integer :: nmoltype_phase
 namelist /confNmoltypePhase/ nmoltype_phase
end subroutine read_initial_config_nml

$ gfortran -c test2.f90
test2.f90:9.27:

 integer :: nmoltype_phase
 1
Error: Symbol 'nmoltype_phase' at (1) already has basic type of INTEGER
test2.f90:10.45:

 namelist /confNmoltypePhase/ nmoltype_phase
   1
Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in
'nmoltype_phase' at (1)


-- 
   Summary: Valid USE statement is rejected
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug middle-end/34843] Missing overflow diagnostic for Python 2.5's unicodeobject.c

[ismail at pardus dot org dot tr]

--- Comment #4 from ismail at pardus dot org dot tr  2008-01-18 17:19 
---
Actually I am reopening this because after talking to Richi we agree that -Wall
should not reset -Wstrict-overflow. But of course final decision is up to iant.


-- 

ismail at pardus dot org dot tr changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug middle-end/34856] [4.3 Regression] ICE with some constant vectors

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-01-18 20:52 ---
On i686-apple-darwin9, I get:

pr34856.c: In function 'f1':
pr34856.c:16: error: invalid reference prefix
{(unsigned int) &g[16]}

pr34856.c:16: internal compiler error: verify_stmts failed


-- 


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

[Bug c/19541] need another option to support what -I- did just besides -iquote

[tromey at gcc dot gnu dot org]

--- Comment #8 from tromey at gcc dot gnu dot org  2008-01-18 21:52 ---
Changing component; the patch here doesn't touch the preprocessor at all.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
  Component|preprocessor|c


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

[Bug fortran/34860] New: -O3 optimization fails for simple fortran77 extrapolation routine

[jsoishi at gmail dot com]

The qdelg.f subroutine, a part of SciPy, fails to build if -O3 optimization is
turned on. The error given is 

[EMAIL PROTECTED] quadpack]$ gfortran -c -ffixed-form -fno-second-underscore 
-fPIC
-O3 -funroll-loops -c dqelg.f -o /tmp/dqelg.o  
dqelg.f: In function 'dqelg':
dqelg.f:1: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

If I use -O2 or lower, the file compiles fine. This occurs on an Intel Core2
duo based MacBook running OS X 10.4.10. gfortran info as follows:

[EMAIL PROTECTED] quadpack]$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: ../gcc-4.3-20070810/configure --enable-threads=posix
--enable-languages=fortran
Thread model: posix
gcc version 4.3.0 20070810 (experimental)

The source file I am trying to compile has no include files or external
dependencies and is copied in its entirety below.

  subroutine dqelg(n,epstab,result,abserr,res3la,nres)
c***begin prologue  dqelg
c***refer to  dqagie,dqagoe,dqagpe,dqagse
c***routines called  d1mach
c***revision date  830518   (yymmdd)
c***keywords  epsilon algorithm, convergence acceleration,
c extrapolation
c***author  piessens,robert,appl. math. & progr. div. - k.u.leuven
c   de doncker,elise,appl. math & progr. div. - k.u.leuven
c***purpose  the routine determines the limit of a given sequence of
capproximations, by means of the epsilon algorithm of
cp.wynn. an estimate of the absolute error is also given.
cthe condensed epsilon table is computed. only those
celements needed for the computation of the next diagonal
care preserved.
c***description
c
c   epsilon algorithm
c   standard fortran subroutine
c   double precision version
c
c   parameters
c  n  - integer
c   epstab(n) contains the new element in the
c   first column of the epsilon table.
c
c  epstab - double precision
c   vector of dimension 52 containing the elements
c   of the two lower diagonals of the triangular
c   epsilon table. the elements are numbered
c   starting at the right-hand corner of the
c   triangle.
c
c  result - double precision
c   resulting approximation to the integral
c
c  abserr - double precision
c   estimate of the absolute error computed from
c   result and the 3 previous results
c
c  res3la - double precision
c   vector of dimension 3 containing the last 3
c   results
c
c  nres   - integer
c   number of calls to the routine
c   (should be zero at first call)
c
c***end prologue  dqelg
c
  double precision abserr,dabs,delta1,delta2,delta3,dmax1,d1mach,
 *  epmach,epsinf,epstab,error,err1,err2,err3,e0,e1,e1abs,e2,e3,
 *  oflow,res,result,res3la,ss,tol1,tol2,tol3
  integer i,ib,ib2,ie,indx,k1,k2,k3,limexp,n,newelm,nres,num
  dimension epstab(52),res3la(3)
c
c   list of major variables
c   ---
c
c   e0 - the 4 elements on which the computation of a new
c   e1   element in the epsilon table is based
c   e2
c   e3 e0
ce3e1new
c  e2
c   newelm - number of elements to be computed in the new
cdiagonal
c   error  - error = abs(e1-e0)+abs(e2-e1)+abs(new-e2)
c   result - the element in the new diagonal with least value
cof error
c
c   machine dependent constants
c   ---
c
c   epmach is the largest relative spacing.
c   oflow is the largest positive magnitude.
c   limexp is the maximum number of elements the epsilon
c   table can contain. if this number is reached, the upper
c   diagonal of the epsilon table is deleted.
c
c***first executable statement  dqelg
  epmach = d1mach(4)
  oflow = d1mach(2)
  nres = nres+1
  abserr = oflow
  result = epstab(n)
  if(n.lt.3) go to 100
  limexp = 50
  epstab(n+2) = epstab(n)
  newelm = (n-1)/2
  epstab(n) = oflow
  num = n
  k1 = n
  do 40 i = 1,newelm
k2 = k1-1
k3 = k1-2
res = epstab(k1+2)
e0 = epstab(k3)
e1 = epstab(k2)
e2 = res
e1abs = dabs(e1)
delta2 = e2-e1
err2 = dabs(delta2)
tol2 = dmax1(dabs(e2),e1abs)*epmach
delta3 = e1-e0
err3 = dabs(delta3)
tol3 = dmax1(e1abs,dabs(e0))*epmach
if(err2.gt.tol2.or.err3.gt.tol3) go to 10
c
c   if e0, e1 and

[Bug fortran/34861] ICE in function with entry (and result?)

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-01-18 23:32 ---
Confirmed on i686-apple-darwin9, rev. 131629 (trunk) and gfortran 4.2.2.


-- 


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

[Bug fortran/34863] -O3 optimization fails for simple fortran77 extrapolation routine

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-01-18 23:54 ---


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


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/34838] [4.3 Regression] ICE: Can't convert LOGICAL(1) to LOGICAL(1)

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-18 23:57:49
   date||
Summary|Internal Error: Can't   |[4.3 Regression] ICE: Can't
   |convert LOGICAL(1) to   |convert LOGICAL(1) to
   |LOGICAL(1)  |LOGICAL(1)


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

[Bug fortran/34861] ICE in function with entry (and result?)

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.1.3 4.2.2 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-01-18 23:53:05
   date||


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

[Bug fortran/32616] "Too short actual argument" for array element storage sequence

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-01-18 23:49 ---
FIXED on the trunk (4.3.0).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

[manu at gcc dot gnu dot org]

--- Comment #20 from manu at gcc dot gnu dot org  2008-01-19 00:22 ---
There is a bug (PR32102) where -Wall after -Wstrict-overflow resets the latter
to its default value. I think this is why you didn't get the warning. Removing
-Wall or moving -Wstrict-overflow=5 after it should generate the warning.

Now, why the warnings from -Wsign-comparison appear and disappear? That I don't
know but I don't have more free time to investigate this. I hope someone can
look into it or, at least, find a reduced testcase.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-01-18 14:49:26 |2008-01-19 00:22:14
   date||


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

[Bug other/33768] splay-tree.c typo

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-01-19 00:39 ---
Subject: Bug 33768

Author: manu
Date: Sat Jan 19 00:39:08 2008
New Revision: 131650

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131650
Log:
2008-01-19  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR other/33768
* splay-tree.c (rotate_left): Fix minor typo in comment.
(rotate_right): Likewise.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/splay-tree.c


-- 


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

[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2008-01-19 00:50 ---
*** Bug 34807 has been marked as a duplicate of this bug. ***


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu dot org


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

[Bug c++/34859] g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes error

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-01-19 00:45 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868 .

Can you try a newer snapshot since I think this has changed back to a warning.


-- 


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[zadeck at gcc dot gnu dot org]

--- Comment #54 from zadeck at gcc dot gnu dot org  2008-01-19 00:39 ---
Subject: Bug 34400

Author: zadeck
Date: Sat Jan 19 00:38:34 2008
New Revision: 131649

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131649
Log:
2008-01-18  Kenneth Zadeck  <[EMAIL PROTECTED]>
Steven Bosscher  <[EMAIL PROTECTED]>

PR rtl-optimization/26854
PR rtl-optimization/34400
* df-problems.c (df_live_scratch): New scratch bitmap.
(df_live_alloc): Allocate df_live_scratch when doing df_live.
(df_live_reset): Clear the proper bitmaps.
(df_live_bb_local_compute): Only process the artificial defs once
since the order is not important.
(df_live_init): Init the df_live sets only with the variables
found live by df_lr.
(df_live_transfer_function): Use the df_lr sets to prune the
df_live sets as they are being computed.  
(df_live_free): Free df_live_scratch.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-problems.c


-- 


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

[Bug fortran/34860] -O3 optimization fails for simple fortran77 extrapolation routine

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-01-18 23:54 ---
*** Bug 34863 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/32616] "Too short actual argument" for array element storage sequence

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-01-18 23:46 ---
Subject: Bug 32616

Author: burnus
Date: Fri Jan 18 23:46:04 2008
New Revision: 131643

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131643
Log:
2008-01-18  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/32616
* interface.c (get_expr_storage_size): Return storage size
for array element designators.
(compare_actual_formal): Reject unequal string sizes for
assumed-shape dummy arguments. And fix error message for
array-sections with vector subscripts.

2008-01-18  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/32616
* gfortran.dg/argument_checking_15.f90: New.
* gfortran.dg/argument_checking_5.f90: Change TODO into
dg-warning.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/argument_checking_5.f90


-- 


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

[Bug fortran/34860] -O3 optimization fails for simple fortran77 extrapolation routine

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-01-18 23:36 ---
Works for me on i686-apple-darwin9 (Intel Core2Duo OSX 10.5.1), rev. 131629
(trunk) and gfortran 4.2.2.


-- 


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

[Bug fortran/34863] New: -O3 optimization fails for simple fortran77 extrapolation routine

[jsoishi at gmail dot com]

The qdelg.f subroutine, a part of SciPy, fails to build if -O3 optimization is
turned on. The error given is 

[EMAIL PROTECTED] quadpack]$ gfortran -c -ffixed-form -fno-second-underscore 
-fPIC
-O3 -funroll-loops -c dqelg.f -o /tmp/dqelg.o  
dqelg.f: In function 'dqelg':
dqelg.f:1: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

If I use -O2 or lower, the file compiles fine. This occurs on an Intel Core2
duo based MacBook running OS X 10.4.10. gfortran info as follows:

[EMAIL PROTECTED] quadpack]$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: ../gcc-4.3-20070810/configure --enable-threads=posix
--enable-languages=fortran
Thread model: posix
gcc version 4.3.0 20070810 (experimental)

The source file I am trying to compile has no include files or external
dependencies and is copied in its entirety below.

  subroutine dqelg(n,epstab,result,abserr,res3la,nres)
c***begin prologue  dqelg
c***refer to  dqagie,dqagoe,dqagpe,dqagse
c***routines called  d1mach
c***revision date  830518   (yymmdd)
c***keywords  epsilon algorithm, convergence acceleration,
c extrapolation
c***author  piessens,robert,appl. math. & progr. div. - k.u.leuven
c   de doncker,elise,appl. math & progr. div. - k.u.leuven
c***purpose  the routine determines the limit of a given sequence of
capproximations, by means of the epsilon algorithm of
cp.wynn. an estimate of the absolute error is also given.
cthe condensed epsilon table is computed. only those
celements needed for the computation of the next diagonal
care preserved.
c***description
c
c   epsilon algorithm
c   standard fortran subroutine
c   double precision version
c
c   parameters
c  n  - integer
c   epstab(n) contains the new element in the
c   first column of the epsilon table.
c
c  epstab - double precision
c   vector of dimension 52 containing the elements
c   of the two lower diagonals of the triangular
c   epsilon table. the elements are numbered
c   starting at the right-hand corner of the
c   triangle.
c
c  result - double precision
c   resulting approximation to the integral
c
c  abserr - double precision
c   estimate of the absolute error computed from
c   result and the 3 previous results
c
c  res3la - double precision
c   vector of dimension 3 containing the last 3
c   results
c
c  nres   - integer
c   number of calls to the routine
c   (should be zero at first call)
c
c***end prologue  dqelg
c
  double precision abserr,dabs,delta1,delta2,delta3,dmax1,d1mach,
 *  epmach,epsinf,epstab,error,err1,err2,err3,e0,e1,e1abs,e2,e3,
 *  oflow,res,result,res3la,ss,tol1,tol2,tol3
  integer i,ib,ib2,ie,indx,k1,k2,k3,limexp,n,newelm,nres,num
  dimension epstab(52),res3la(3)
c
c   list of major variables
c   ---
c
c   e0 - the 4 elements on which the computation of a new
c   e1   element in the epsilon table is based
c   e2
c   e3 e0
ce3e1new
c  e2
c   newelm - number of elements to be computed in the new
cdiagonal
c   error  - error = abs(e1-e0)+abs(e2-e1)+abs(new-e2)
c   result - the element in the new diagonal with least value
cof error
c
c   machine dependent constants
c   ---
c
c   epmach is the largest relative spacing.
c   oflow is the largest positive magnitude.
c   limexp is the maximum number of elements the epsilon
c   table can contain. if this number is reached, the upper
c   diagonal of the epsilon table is deleted.
c
c***first executable statement  dqelg
  epmach = d1mach(4)
  oflow = d1mach(2)
  nres = nres+1
  abserr = oflow
  result = epstab(n)
  if(n.lt.3) go to 100
  limexp = 50
  epstab(n+2) = epstab(n)
  newelm = (n-1)/2
  epstab(n) = oflow
  num = n
  k1 = n
  do 40 i = 1,newelm
k2 = k1-1
k3 = k1-2
res = epstab(k1+2)
e0 = epstab(k3)
e1 = epstab(k2)
e2 = res
e1abs = dabs(e1)
delta2 = e2-e1
err2 = dabs(delta2)
tol2 = dmax1(dabs(e2),e1abs)*epmach
delta3 = e1-e0
err3 = dabs(delta3)
tol3 = dmax1(e1abs,dabs(e0))*epmach
if(err2.gt.tol2.or.err3.gt.tol3) go to 10
c
c   if e0, e1 and

[Bug c++/34859] New: g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes error

[peeterj at ca dot ibm dot com]

Have a situation where some ugly make recursion is causing -D related cflags
for compilation to be duplicated (only for one file out of thousands)

When that duplication happens to include -D__STDC_LIMIT_MACROS the g++ 4.3
(using 20080111 snapshot) ends up with the following error:

: error: "__STDC_LIMIT_MACROS" redefined
: error: this is the location of the previous definition

Can reproduce this as follows:

rm -rf r.C
touch r.C
gcc-4.3-20080111/bin/g++ -c -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS r.C

Other -D values do not appear to cause any sort of trouble.  Example:

gcc-4.3-20080111/bin/g++ -c -D__BLAH -D__BLAH r.C
gcc-4.3-20080111/bin/g++ -c -DXXX -DXXX r.Cvim h

But it appears that duplicate -D statements for anything that starts with
-D__STDC_ causes this error (-D__STDC is okay).

Any explaination for the special casing of the flags that start with __STDC_?

This behaviour has not been observed with g++ 4.2 or lower.


-- 
   Summary: g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes
error
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peeterj at ca dot ibm 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=34859

[Bug fortran/34861] New: ICE in function with entry (and result?)

[dick dot hendrickson at gmail dot com]

The following generates:
i_1_mods_bug.f:10.72:

  END FUNCTION
   1
Internal Error at (1):
gfc_compare_array_spec(): Array spec clobbered

 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)

It works fine if I delete all 3 ENTRY statements.  I don't know if the
RESULT clause is necessary or not.

Dick Hendrickson



  FUNCTION I_IMFUD0 ( IDA2 , NDS4, NDS3) RESULT(I_IMFUDP)
  INTEGER  ::   NDS4, NDS3
  INTEGER  ::   IDA2(5,NDS4,NDS3,2)
  INTEGER  ::   I_IMFUDP(SIZE(IDA2,1), SIZE(IDA2,2),
 $  SIZE(IDA2,NF3), SIZE(IDA2,4))
  ENTRY I_IMFUDX (NDS4, NDS3, IDA2) RESULT(I_IMFUDP)
  ENTRY I_IMFUDY (NDS3, NDS4, IDA2) RESULT(I_IMFUDP)
  ENTRY I_IMFUDZ (NDS3, IDA2, NDS4) RESULT(I_IMFUDP)
  I_IMFUDP = 1-IDA2(:,:,:,::NDS4-NDS3)
  END FUNCTION


-- 
   Summary: ICE in function with entry (and result?)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x

[kkojima at gcc dot gnu dot org]

-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-19 00:56:22
   date||


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

[Bug c/19541] need another option to support what -I- did just besides -iquote

[ISPARRY at BROCADE dot COM]

--- Comment #9 from ISPARRY at BROCADE dot COM  2008-01-19 00:53 ---
(In reply to comment #8)
> Changing component; the patch here doesn't touch the preprocessor at all.
> 

If you are changing the component, would not a better choice be "driver" than
"c"? 

I agree the patch does not touch the preprocessor code, but from a user point
of view it is a preprocessor issue. The 4.2.2 manuals say in section 3.11 that
"The preprocessor's direct interface is undocumented and subject to change, so
whenever possible you should avoid using -Wp and let the driver handle the
options instead." A user could reasonably (but wrongly) assume that the driver
passes options like -I to the preprocessor.

If you are changing the component, then can you change the severity to
something more suitable than "enhancment" at the same time? Whilst I am all in
favour of emitting warnings about obsolete features, until there is a working
replacement for -I- it is a bug to complain that it is deprecated.


-- 


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

[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing

[aoliva at gcc dot gnu dot org]

--- Comment #30 from aoliva at gcc dot gnu dot org  2008-01-19 00:51 ---
I tried that myself (patch in comment #11) and got no regressions.  It's a
reasonable possibility, but isn't it a bit too early to close the bug? :-)


-- 


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

[Bug target/34807] SH4 �R0_REGS� spill failure when using asm

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2008-01-19 00:50 ---


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


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2008-01-19 00:54 ---
Created an attachment (id=14973)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14973&action=view)
reduced testcase

I think Richard's comment is the case.  Here is a reduced testcase.

The PIC memory access on SH4 makes register pressure on R0 high
and sometimes can't use with asm register statement using R0.
It seems that there is no easy way to fix this issue.  Currently,
it's a limitation of asm extensions on this target.
In the above testcase, the error will go away with adding
-fno-schedule-insns option, but the more complex cases like PR 34807
will fail even with that option.  You could avoid this problem
completely with isolating PIC accesses and asm statements.
For example, if the above reduced testcase is changed so to use
noinline attribute, that program

static __attribute__ ((__noinline__)) void *
_dl_mmap (void * start, int length, int prot, int flags, int fd,
  int offset)
{
  register long __sc3 __asm__ ("r3") = 90;
  register long __sc4 __asm__ ("r4") = (long) start;
  register long __sc5 __asm__ ("r5") = (long) length;
  register long __sc6 __asm__ ("r6") = (long) prot;
  register long __sc7 __asm__ ("r7") = (long) flags;
  register long __sc0 __asm__ ("r0") = (long) fd;
  register long __sc1 __asm__ ("r1") = (long) offset;
  __asm__ __volatile__ ("trapa  %1"
: "=z" (__sc0)
: "i" (0x10 + 6), "0" (__sc0), "r" (__sc4),
  "r" (__sc5), "r" (__sc6), "r" (__sc7),
  "r" (__sc3), "r" (__sc1)
: "memory" );
}

extern int _dl_pagesize;
void _dl_dprintf(int fd, const char *fmt, ...)
{
  static char *buf;
  buf = _dl_mmap ((void *) 0, _dl_pagesize, 0x1 | 0x2, 0x02 | 0x20, -1, 0);
}

will never hit this problem.


-- 


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

[sergstesh at yahoo dot com]

--- Comment #19 from sergstesh at yahoo dot com  2008-01-18 23:33 ---
Regarding "BTW, is your makefile adding -Wstrict-overflow after or before -Wall
-Wextra?".

Here is how the first action line in 'make.log' looks:

"
23  if /bin/sh ../../libtool --tag=CC --mode=compile
/maxtor5/sergei/AppsFromScratchWD/install/gcc-4.2.2/bin/gcc -DHAVE_CONFIG_H -I.
-I. -I../../src -O2 -Wstrict-overflow=5 -std=gnu99 -W -Wall
-Wdeclaration-after-statement -Wpointer-arith -Wstrict-prototypes
-Wmissing-prototypes -Waggregate-return -Wcast-align -Wcast-qual
-Wnested-externs -Wshadow -Wbad-function-cast -Wwrite-strings  -pipe  -MT
add.lo -MD -MP -MF ".deps/add.Tpo" -c -o add.lo add.c; \
24  then mv -f ".deps/add.Tpo" ".deps/add.Plo"; else rm -f
".deps/add.Tpo"; exit 1; fi
".

My understanding is that whatever is given to 'configure' as CFLAGS is inserted
before the flags 'configure' and friends put.


-- 


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

[Bug c++/34862] New: operator new placement varient with reference arg not accepted by g++ 4.3

[peeterj at ca dot ibm dot com]

Have a class that defines a placement new like varient that updates a pointer
to raw storage via a reference argument.  Here's a stripped down code fragment:

#include  // size_t

class T
{
public:

  void *operator new(size_t size, char *&p);

  T( int &rc);
} ;


void *T::operator new(size_t size, char *&p)
{
  void *o;

  o = (void *) p;

  p += size;

  return(o);
}

T * f ( char *& cur_vardatap )
{
   int rc ;

   T * subTypep = new((char *&)cur_vardatap)
  T( rc );

   return subTypep ;
}


If I build this code with GCC4.3 it doesn't want to generate code that calls
it:

r2.C: In function 'T* f(char*&)':
r2.C:29: error: no matching function for call to 'T::operator new(long unsigned
int, char*)'
r2.C:13: note: candidates are: static void* T::operator new(size_t, char*&)

This code seems a bit fishy to me (casting the input parameter to a reference
type seems odd, and I'm wondering if that cast was added because some other
compiler wouldn't call this operator new either).


This can be worked around this easily enough by changing the code in question
to call global placement new and then increment cur_vardatap by sizeof(T)
afterwards (this specialized new operator is only called in two places so in
all honesty I don't know why the original developer bothered doing all this).

However, regardless of whether this is recoded, is GCC4.3 is correct rejecting
this, or is this a GCC 4.3 regression?  GCC 4.2 and previous compilers accept
this syntax (as do a number of other compilers, IBM xlC, Sun WSPro, intel icpc,
msdev, ...)


-- 
   Summary: operator new placement varient with reference arg not
accepted by g++ 4.3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peeterj at ca dot ibm 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=34862

[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-01-18 23:16 
---
On x86-64:

==11867== 208 bytes in 26 blocks are definitely lost in loss record 1 of 5
==11867==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==11867==by 0xB4C018: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951)
==11867==by 0xB3BB6D: __gmpz_init_set (in /mnt/sdb2/obj43/gcc/f951)
==11867==by 0x4242A8: gfc_copy_shape (expr.c:339)
==11867==by 0x424309: gfc_copy_expr (expr.c:515)
==11867==by 0x426206: simplify_parameter_variable (expr.c:1524)
==11867==by 0x425F80: gfc_simplify_expr (expr.c:1638)
==11867==by 0x40B234: expand_constructor (array.c:1379)
==11867==by 0x40B4FC: gfc_get_array_element (array.c:1696)
==11867==by 0x40C78E: gfc_expand_constructor (array.c:1404)
==11867==by 0x45F7A4: gfc_resolve_expr (resolve.c:4320)
==11867==by 0x40C646: gfc_resolve_array_constructor (array.c:1514)


-- 


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

[Bug c/32102] -Wall stomps on -Wstrict-overflow

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-01-19 01:40 ---
(In reply to comment #6)
> 
> Your fix looks quite obvious, could you send it to gcc-patches so we can fix
> this before the freeze? Thanks for the quick fix btw.
> 

That fix is too simple. It doesn't handle -Wno-strict-overflow -Wall, for
example. It also needs testcases.

I am testing a better patch.


-- 


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

[Bug inline-asm/34830] rejects "i"(const_var) without -O1

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-01-19 01:05 ---
This is not a bug as const_var (in this case) is not an integal constant
expression in either C or C++.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/34782] tab format failure to display properly (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-01-18 22:23 
---
Subject: Bug 34782

Author: jvdelisle
Date: Fri Jan 18 22:22:21 2008
New Revision: 131641

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131641
Log:
2007-01-18  Jerry DeLisle  <[EMAIL PROTECTED]>

PR target/34782
* gfortran.dg/fmt_t_6.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_t_6.f
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/34563] noinline function call being removed

[jkenisto at us dot ibm dot com]

--- Comment #12 from jkenisto at us dot ibm dot com  2008-01-18 22:20 
---
(In reply to comment #11)
> (In reply to comment #9)
> > > Since this topic came up, I've seen various suggestions for how to 
> > > guarantee
> > that a function gets inlined -- e.g., make it a varargs function, or 
> > include an
> > empty asm statement.
> 
> I assume you're referring to the thread at
> ?  If it's elsewhere, I
> wouldn't count on it.

The varargs idea came from the Linux Kernel Mailing List thread I noted in
Comment #7.  The asm idea came from the gcc thread you started -- thanks. 
Plainly, once gcc folks settle on the One Correct Incantation, we'll use that.
(And we can throw out all the other inline-thwarting kludges if that
incantation happens to work for older gcc versions as well... but that's not
your problem.)


-- 


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